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?