[coreboot] Future coreboot phases?
kevin at koconnor.net
Sat Jan 9 23:31:03 CET 2010
There are a bunch of changes under way in coreboot-v2. Because of
these changes and because of the many differences in operation between
boards already in v2, it can be somewhat difficult to figure out what
a board should be doing.
I think some documentation on where functionality in coreboot should
be located would be helpful for developers. I put together some notes
(see below) on what I've gathered from my understanding of the code
and from various emails.
This is just a starting point for discussion. There's a good chance
I've gotten some things wrong. The idea is to document where things
are heading instead of how exactly they are today.
There are four major phases to coreboot execution: bootblock,
romstage, coreboot_ram, and payload.
The purpose of the bootblock is to enable full access to flash and to
detect and enable fallback booting in necessary. It also does basic
CPU initialization (clears caches and enables 32bit mode). The
objective is to make this code as small and isolated as possible so
that one can deploy new "normal" images without needing to reflash the
bootblock (or the "fallback" image).
* Located at end of 32bit ram so that it runs when CPU first starts
executing (at 0xfffffff0).
* Code runs XIP in rom.
* Debugging is generally accomplished via 0x80 ioport (post codes)
* Code is a mixture of assembler and romcc compiled C code. The code
will not attempt to access any RAM memory.
* Full rom mapping and fallback/normal switch can be board specific,
but most of the other code is standard.
* Last step is to jump into "romstage". For the handoff, %eax will
contain the BIST code, the cpu will be in 32bit flat mode, caches
will be disabled, and no stale data will be in the cache.
The purpose of the romstage is to enable RAM.
* Code runs XIP in rom. The code location is determined at compile
time and is fixed (the code is not PIC and can not be relocated
* The system will generally enable CAR. This will result in CPU
caches being enabled, variable MTRR for the XIP romstage region
being enabled, and all other variable MTRRs cleared.
* Code uses gcc (CAR) or romcc (non-CAR) compiled C code. In general,
care must be taken to limit memory usage so that storage overflows
don't occur. (As an exception, the last step of decompressing and
launching "coreboot_ram" occurs after memory is initialized and it
uses regular memory and regular gcc compiled code.)
* Early debugging is enabled - debugging is generally accomplished
either via a serial port or via an EHCI debug port.
* Code will enable memory and basic northbridge/cpu/memory controller
* Last step is to decompress and run "coreboot_ram". For the handoff,
caching will be enabled, memory from 0 - CONFIG_RAMTOP will be fully
mapped and cached, and the entire flash chip will be cached. If CAR
was enabled it is completely torn down. There will be no stale data
in cache. Additional information may be passed from romstage to
coreboot_ram - the information and mechanism is board specific.
The purpose of coreboot_ram is to enable system devices and do
motherboard specific hardware initialization. It also sets up the
coreboot table and various other legacy BIOS tables (eg, ACPI, PIR,
mptable, smbios). The goal is to perform the motherboard specific
initialization so that the payload can be mostly board independent.
* Runs from RAM. It is generally stored compressed in the rom. This
code is standard gcc compiled C code - no special tricks for memory
* Does PCI enumeration and PCI config space initialization.
* If legacy VGA is enabled, the corresponding PCI config settings are
enabled and 0xa0000-0xc0000 is unmapped and made uncached.
* Builds legacy BIOS tables.
* May emulate vga roms.
* Last step is to decompress and run the "payload". For the handoff,
all MTRRs are initialized, caching is enabled, and the entire flash
chip is cached. There will be no stale data in cache. No specific
information is passed during payload execution, but the payload may
locate the coreboot table and other BIOS tables at standard
The purpose of the payload is to load and run the operating system (or
occasionally to be the operating system). It will also initialize
generic hardware that typical operating systems expect to be
initialized before execution.
* Stored in flash. Generally stored compressed.
* may use CBFS.
* Generally needs to be aware of hardware still "spinning up".
At what point do the non-BP cpus get shutdown? What phases will use
How is S3 resume handled?
More information about the coreboot