Hi folks,
something I've been thinking back and forth about since the hackathon a week ago: Should we give people who promote coreboot something to refer to, something that more clearly states, what coreboot is?
I know, some of you who know me might feel the urge to check if it isn't April the 1st. Nico suggesting a spec? What's happening here? I've always neglected the idea. Probably because I was too focused on fellow developers. But coreboot is not only discussed by develo- pers anymore. And we all know too well, developers don't make all the decisions. I believe having a document that basically says "that's coreboot, that's what people ask for" might help in, well, higher-level discussions.
So what do I suggest? To have some high-level description of what coreboot does, where it starts, where it ends. And also, to be com- prehensive, the things that are set in stone: cb-tables, SELF for the payload. It's in C header files. But I guess the information could be imported for the last chapters. Overall, the spec should not be long. I imagine something like 2~4 pages plus the cb-tables.
About the high-level part: Generally, I don't want to rush this. But I'll draft some things below that I already have on my mind. My current thoughts are mostly motivated by the "new bootflow for ARM64" thread[1] and Martin's excellent idea to rather call that "with coreboot technology" than "coreboot". Many people seem to agree. I guess, because it's not what we usually do. But what do we usually do? Shouldn't we write that down?
coreboot boot process ---------------------
coreboot's bootstrapping usually happens in two phases: 1. When a DRAM controller is part of the platform, it will be configured by coreboot to allow access to the main memory. 2. When the main memory is available, the platform is further initialized into an abstract state that allows generic opera- ting systems to run.
(some simple picture here; it's too late in the evening for ascii-art on my end)
coreboot starts with the first instruction on the main application processor (AP), or earlier when another processor runs platform initialization code from writable memory before the AP starts.
Exceptions are made, when * the first instructions run from a boot ROM, or * the first instructions are pre-defined by the silicon vendor and the hardware doesn't allow execution of other code, i.e. due to cryptographic signature checks. In this case, coreboot starts with the first instruction from writable memory that can be controlled by the platform owner. Future hardware iterations should strive to allow coreboot to run earlier.
After the hardware initialization, coreboot will write tables (cbtables, ACPI, SMBIOS and alike) with chip- and board-specific information. With this information, a generic operating system should be able to run without any further, board-specific know- ledge.
Finally, coreboot loads and executes an embedded payload program from the same memory that holds coreboot. If possible, coreboot will cease all other execution at this point. It is the payload program's responsibility to continue the boot strapping on its own, without relying on any services provided by coreboot but the in-memory tables.
Cheers, Nico
[1] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/BRW3Z...