Category: coreboot

GSoC2011(Week 1): Analysis of U-boot ARM boot code

This is such a busy week. At the end of last week, I have just ordered my OpenRD-Ultimate box but sadly it will be delivered at the end of June. So if I just wait for that box, I will not be able to test my code. That’s terrible! After talking with my mentor, I decided first porting coreboot to RealView Versatile/PB926EJ-S board then to OpenRD-Ultimate. Since qemu can emulate PB926EJ-S, I can test my code on it quickly and freely. After this work, the basic layout, libs and headers for ARM are ready to use. So I can start to port coreboot to OpenRD-Ultimate then.
Continue reading GSoC2011(Week 1): Analysis of U-boot ARM boot code

GSoC 2011: Coreboot Spice Payload

This year I was accepted on gsoc – and I`m excited – to work in a project to make corebook a spice client. The idea is to use buildrom to pack everything.

Once buildrom has been unmaintained for quite some time now I`ll need to work around it before working on the spice bits.

 

Spice

Yeah! when I say spice I mean the remote and virtualized desktop protocol, originally developed by Qumranet now acquired by Red Hat.
The basic idea is to make a client run from a minimal environment. We`ll be working on a LAB(Linux as bootloader) solution.

 

Initial steps

As I said above, we need some work around buildrom system, the coreboot buildsystem has migrated to kbuild on the stable code and lots of things have changed with it.
Both buildrom and coreboot work with kbuild with that I`m writing a small python piece of code to parse coreboot`s Kconfig files and then arrange it into buildrom source code. I also need to 1) monitor the coreboot Kconfig files changes so I run the parser again and 2) change the coreboot build calls.
With all the kconfig arranged the buildrom user needs just to set the rom properties including the coreboot options(since those options are passed to coreboot build).

The kernel configs also need some attention it`s statically set for each board, I haven`t come with a better solution for this till now.

 

Hardware and new toys

I have ordered an ALIX.3D3, a flexyICE and a new desktop computer. The first 2 are comming from EU and will be dispatched later on May. The new desktop computer I get till the end of the week(before the gsoc bonding period end).

 

Now, let`s rock.

GSoC2011 Project: Porting coreboot to ARM architecture

I am so excited that my idea on porting coreboot to ARM architecture has been accepted by GSoC project this year. First, let me introduce myself to you all. I am now a junior student at Hebei University of Technology, People’s Republic of China. My major is Computer Science and Technology. Although my courses are almost focus on high-level software development like database system and software engineering, I am a fan of low-level development. I taught myself IA32 and ARM architecture last year. And during this summer, we will porting coreboot to ARM and make it a new bootloader for ARM.

Those days, I am studying the building system of coreboot deeply, and I am trying to add cross-compile toolchain support to it. Developers has created such a great system and I want to make it greater. 🙂

Thanks for reading my project and any comment is welcome.

GSoC project: Coreboot panic room. Diagnostics (also remote flashing)

I’m very excited to announce my GSoC project which is intended to bring some light for coreboot users. To begin with, I would like to introduce myself. I’m 20 years old student living in Lithuania. I’m studying Informatics Engineering at Kaunas University of Technology. This year we have two interesting modules here: one about operating systems and the other is introduction to computer architecture, which is crucial for learning coreboot. Some time ago I have played with avr microcontrollers, so I have good soldering skills. One day during my free time I thought:

What the hell my old computer’s bios is so badly written that it can’t boot from usb flash and it can’t suspend correctly on Linux? I have a laptop that is running bios stuff more time than the old computer. I thought I can’t live with that and then I found coreboot 🙂 I was very excited that it was so configurable, so open alternative 🙂

Not to waste time on cheap talks, here is my project:

To help developing coreboot code, we have to set-up remote diagnostics (also flashing) interface in coreboot. We will be a able to renew bricked board through serial port or even do some research through registers in case of panic(). This will enable easier development of CAR, chipset, payloads code.

Abbreviations used later:
TARGET – machine running coreboot;
HOST – machine running serial port application, connected to TARGET through serial port
The platform that I will use for development is traditional x86. In case coreboot is supported on ARM, I will be hapy to buy one board to make my code working on both platforms.

 

There will be a diagnostics shell, similar to Serial ICE (or LLshell). Invocation of the shell may occur at any time (when we have (cache or ram) memory or not). It would be invoked by (we should discuss this):
1) serial port data received interrupt (HOST triggers diagnostics mode)
2) if user specified it in code (we may add something like checkpoints in coreboot’s code where TARGET will send command through serial port to HOST and if receives the answer – it enters diagnostics mode)
3) in case of panic() invocation (or something like die())

 

In that shell’s loop we will be able:
1) to run the code instructed through serial port (like Serial ICE): manage register contents, do some research or even like Carl-Daniel suggested to initialise CAR
2) to flash memory through serial port, when we have some memory (CAR or RAM) initialised. Some generic flashing code will be pumped through serial port to memory and then executed.

 

Some small specific goals:
1) analyse different code handling schemes in cases of memory we have (no memory, CAR, RAM)
2) define how Serial ICE will be integrated to coreboot
3) integrate defined Serial ICE stuff to coreboot as our new shell
4) add memory handling funcions to our new shell (for checking how much memory we have, and if we have – for uploading code to memory)
—
5) analyse flashing protocols
6) develop uniform flashing scheme (for SPI, parralel flash…) define what commands are required, where these commands should reside.
7) make serial port application for HOST (maybe we will use flashrom’s serprog code, it might require enhancing)

 

These are just milestones, some points may change after deeper investigation, when we will have something done.
We may experience the risk of problems in different operating modes when having different memory (no memory, CAR, RAM).

 

Yesterday I was looking at flashrom sources. People have done very good job in preparation for porting it to libpayload. Maybe I should concern making a complete flashrom port on libpayload?
Anyway, thanks for reading about my project. You are welcome to post some comments (maybe on the mailinglist). Your experience would be helpful.
Thanks to our mentors for their patience 🙂

AMD commits to coreboot

Kevin Tanguay at AMD writes about AMD’s focus on coreboot.

 

Finally, AMD is now committed to support coreboot for all future products on the roadmap starting next with support for the upcoming “Llano” APU.  AMD has come to realize that coreboot is useful in a myriad of applications and markets, even beyond what was originally considered.  Consequently, AMD plans to continue building its support of coreboot in both features and roadmap for the foreseeable future.

 

This is great news for coreboot and I hope to see some announcements from other vendors on their coreboot offerings later this year.

FOSDEM 2011 photos

I just found out that nobody wrote a few lines about this year’s FOSDEM 2011. This year we had a booth (aka a “table”) in one of the buildings. We had total 4 speeches. I did one lightning talk about the coreboot and x86 init (video) and a lecture about coreboot and its speed. Carl-Daniel Hailfinger had lightning talk (video) and a talk about RAM Cold Boot Attacks The talks had a great success and a lot people attended. Continue reading FOSDEM 2011 photos

u-boot as coreboot payload

U-boot is bootloader on ARMs, PowerPCs and other platforms, it has a nice set of commands and in general it feels like a small operating system. I’m not certainly sure if it is good direction, please feel free to compare with UEFI 😉 but I simply miss it on x86. I work at SYSGO with u-boot in daily basis and even port it to different boards/platforms. The x86 is no easy to init and I think this is the reason why there is only one x86 board in whole u-boot tree. This board is called eNET and it has a AMD ELAN SC520 SOC. But luckily, with coreboot we can init much more x86 boards and this leads to natural conclusion to have the u-boot as the coreboot payload. I would like to share with you part of this “fantastic” hacking journey to make it happen. Continue reading u-boot as coreboot payload

openbiosprog-spi, a DIY Open Hardware and Free Software USB-based SPI BIOS chip flasher using flashrom

openbiosprog-spi device

If you're following me on identi.ca you probably already know that I've been designing a small PCB for a USB-based SPI chip programmer named openbiosprog-spi.

The main use-case of the device is to help you recover easily from a failed BIOS upgrade (either due to using an incorrect BIOS image, due to power outages during the flashing progress, or whatever). The device only supports SPI chips, as used in recent mainboards (in DIP-8 form factor, or via manual wiring possibly also soldered-in SO-8 variants). It can identify, read, erase, or write the chips.

Of course the whole "toolchain" of software tools I used for creating the hardware is open-source, and the hardware itself (schematics and PCB layouts) are freely released under a Creative Commons license (i.e., it's an "Open Hardware" device). The user-space source code is part of flashrom (GPL, version 2), the schematics and PCB layouts are licensed under the CC-BY-SA 3.0 license and were created using the open-source Kicad EDA suite (GPL, version 2).

openbiosprog-spi schematics
openbiosprog-spi Kicad PCB layout

The schematics, PCB layouts, and other material is available from gitorious:

  $ git clone git://gitorious.org/openbiosprog/openbiosprog-spi.git

You can also download the final Gerber files (ZIP) for viewing them, or sending them to a PCB manufacturer.

Some more design notes:

  • The device uses the FTDI FT2232H chip as basis for USB as well as for handling the actual SPI protocol in hardware (MPSSE engine of the FT2232H).
  • Attaching the SPI chip:
    • There's a DIP-8 socket on the device so you can easily insert the SPI chip you want to read/erase/program.
    • Optionally, if you don't want a DIP-8 socket, you can solder in a pin-header with 8 pins, which allows you to connect the individual pins to the SPI chip via jumper wires or grippers/probes.
  • The PCB board dimensions are 44mm x 20mm, and it's a 2-layer board using mostly 0603 SMD components.

Basic usage example of the device on Linux (or other OSes supported by flashrom):

  $ flashrom -p ft2232_spi:type=2232H,port=A -r backup.bin (reads the current chip contents into a file)

openbiosprog-spi PCBs
openbiosprog-spi parts list

Over at the main projects page of openbiosprog-spi at

  http://randomprojects.org/wiki/Openbiosprog-spi

I have put up a lot more photos and information such as the bill of materials, the Kicad settings I used for creating the PCBs, the Gerber files and the Excellon drill files and so on.

The first few prototype boards I ordered at PCB-POOL.COM (but you can use any other PCB manufacturer of course), the bill of materials (BOM) lists the Mouser and CSD electronics part numbers and prices, but you can also buy the stuff elsewhere, of course (Digikey, Farnell, whatever).

I already hand-soldered one or two prototypes and tested the device. Both hardware and software worked fine basically, you just need a small one-liner patch to fix an issue in flashrom, but that should be merged upstream soonish.

In order to make it easy for interested users to get the PCBs I'll probably make them available in the BatchPCB Market Place soonish, so you can easily order them from there (you do still need to solder the components though). Note: I'm not making any money off of this, this is a pure hobby project.

All in all I have to say that this was a really fun little project, and a useful one too. This was my first hardware project using Kicad (I used gEDA/PCB, also an open-source EDA toolsuite, for another small project) and I must say it worked very nicely. I didn't even have to read any manual really, it was all pretty intuitive. Please consider not using Eagle (or other closed-source PCB software) for your next Open Hardware project, there are at least two viable open-source options (Kicad, gEDA/PCB) which both work just fine.