Future coreboot phases? - coreboot

9 Jan 2010


      Hi,
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.
Thoughts?
-Kevin
There are four major phases to coreboot execution: bootblock,
romstage, coreboot_ram, and payload.
bootblock:
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).
Basic attributes:
* 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.
romstage:
The purpose of the romstage is to enable RAM.
Basic attributes:
* 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
  without recompiling).
* 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
  settings.
* 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.
coreboot_ram:
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.
Basic attributes:
* Runs from RAM.  It is generally stored compressed in the rom.  This
  code is standard gcc compiled C code - no special tricks for memory
  are needed.
* 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
  locations.
payload:
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.
Basic attributes:
* Stored in flash.  Generally stored compressed.
* may use CBFS.
* Generally needs to be aware of hardware still "spinning up".
Open questions:
At what point do the non-BP cpus get shutdown?  What phases will use
multiple processors?
How is S3 resume handled?