Column 7: The art of not locking yourself out. (2011-08-10)
When running Coreboot on QEMU, nothing bad could happen. If a
particular version did not work, you could just try another ROM image
file or you could fall back to an old version or even the original
non-Coreboot BIOS of QEMU. This is all easy with emulated hardware,
but on real machines this is very different.
The barrier of entry for Coreboot on real hardware is really much
higher than that on QEMU. If you just flash a Coreboot image to your
motherboard BIOS ROM and you make a mistake, you will not be able to use this
board until you get the correct code in flash again. The motherboard
is said to be "bricked" (a devices is bricked if it is as useless as a
brick). It is absolutely essential that you prepare carefully, so you
know how to get the bricked motherboard back to life.
How to proceed
these are the steps to become a successful Coreboot developer:
- First get yourself completely familiar with Coreboot on QEMU. How
to compile the desired payloads? How to configure a kernel so it can
be stored into flash?
- Still using QEMU, prepare yourself for a system without
VGA. Configure Coreboot, your payload and the OS that you intend to
run for use with a serial port. Even though it is possible to use
Coreboot with VGA on real hardware, configuring it properly (and
using the correct VGA BIOS) is always an extra step.
- Obtain a null-modem cable and try to run a terminal program (such
as minicom) on the host PC and try to run Linux with a serial
console on a second PC. This means you will have a known working
null-modem cable, a known working host PC and a known working
terminal program. It also teaches you how to use real hardware and
the importance of selecting the same baud rate on both ends. The
host PC does not need to have a real serial port, it may also be
used with a USB to serial adapter.
- Select a motherboard for which Coreboot is already ported and get
Coreboot going on that. Take an old PC that you can get cheaply or
that is about to be trashed. When selecting a suitable machine,
observe the following:
- Use a motherboard that is fully supported by Coreboot. First
get yourself familiar with a system that is known to work before
trying to port Coreboot to new hardware
- Use a system with a (true) serial port.
- Use a system with a socketed BIOS chip.
- Check that the system is supported by the flashrom utility,
unless you plan to use an external programmer.
- Try to lay your hands on two specimens of the same
motherboard. According to Murphy's law a motherboard will probably
break just when you are almost there. At least the additional
motherboard has a good BIOS chip.
- Try to lay your hands on additional flash chips of the same
type as the motherboard's BIOS chip. You can buy them new or
salvage them from old motherboards.
- Once you selected a motherboard, pick a programming strategy. Buy
any required additional hardware (such as PROM programmers). Verify
that you can program the original BIOS into a flash chip and that
the board can boot with the newly programmed chip.
- Get Coreboot running on the selected motherboard. No code needs
to be developed as Coreboot was already ported.
- Get VGA and/or ACPI working on the board.
It is always best not to use the target machine (the one you are trying
to run Coreboot on) for production work and use a separate PC as a
build PC.
Programming strategies
There are several ways to program the BIOS flash chip in your
motherboard. For more details
see the
hardware tools page on the Coreboot website
- Use a professional programmer. Professional programmers are very
expensive and they are no viable option for a hobbyist. If you work
at an institution that has such a programmer, you can use it. New
flash chips are introduced often, so a professional programmer can
be out of data very soon, unless it can be upgraded with new socket
adapters and programming algorithms.
- Use low cost programming hardware. If you only need to program
one type of chip, building custom programming hardware for just
that type of chip is fairly straightforward. Flash chips do not
need exotic voltages to be programmed (as opposed to old-style
EPROMs) and timing is only critical if you want to program them
fast (you can run most chips at arbitrarily low clock
frequencies). Several low-cost programmers are available.
- Use in-system programming with switchable flash chips. Use
special hardware to switch between two identical flash chips on the
motherboard. One such hardware device is the BIOS Savior, a small
daughterboard with two flash sockets and a switch. Boot the
board with the original BIOS, then switch to
the other flash chip. Program that other flash chip with Coreboot
(using the flashrom utility) and try to boot with that. Once you
have booted into Linux (or another modern operating system), your
computer will no longer need its BIOS ROM and you can pull it out
while your machine keeps running. Then you can put an empty flash
chip in its place. Instead of pulling the chip out, you can use a
switch to route the chip select signal to a different flash chip.
A great
advantage is that you do not have to remove flash chips from the
board and reinsert them later, which reduces wear and tear on the
flash sockets and reduces the risk on inserting a chip the wrong
way around. Worst case this ruins both the flash chip and the
motherboard.
- Use in-system programming with hot-swapping. Logically this is
the same as the previous one. Instead of flipping the switch to
select the other flash chip, just pull one out and insert the other
one. This is much more dangerous to your hardware though. It
requires no additional hardware, apart from an additional flash chip.
- Use a ROM emulator. The ROM emulator goes into the flash socket
and emulates the function of the BIOS ROM. On the other end there
is a cable to program it from another PC. This method can have a
lower turnaround time than any other method and a ROM emulator may
provide (limited) debug functionality as well.
Ad disadvantage of the in-system strategies is that it is nearly
impossible to prevent overwriting the "known good" original BIOS chip
by accident. For the in-system programming strategies you will need
(at least) three identical flash chips.
- The first chip is the one you will write the new Coreboot image
to.
- The second chip contains the original BIOS of the motherboard. It will
never be overwritten.
- The third chip contains the original BIOS as well. Keep it in a
safe place. It will come in handy if you (can happen means will
happen according to Murphy's law) accidentally overwrite the second
chip.
The flashrom utility
The flashrom utility is
a separate program from Coreboot itself, yet it is maintained by the
same people. The focus of flashrom is the ability to program a BIOS
chip in-system, but some external programmers are also
supported. Access to the BIOS flash chip is usually provided by the
southbridge and there are several different hardware interfaces (FWH,
LPC and SPI).
Read access to the flash chip is usually straightforward. For one
thing this has to be working just after a hardware reset, otherwise
the CPU could not run its ROM code. It may be less straightforward to
enable access to all of the flash chip, which Coreboot will need to
access its CBFS files.
Write access is harder still. Not only is this very dependent on the
exact southbridge chip, but some motherboards have special
write-protect circuits that have to be disabled first.
Flashrom supports a very large number of motherboards.
Flashrom must be run under an operating system (e.g. Linux), so it
does not depend on special boot diskettes. It is
also possible to compile it as a payload under Coreboot.