[coreboot] [RFC]What to do with TINY_BOOTBLOCK?

Patrick Georgi patrick at georgi-clan.de
Mon Oct 24 12:15:53 CEST 2011


Hi all,

as you may be aware, coreboot has two different ROM layouts so far.

The older one is derived from what we did before CBFS, and has all code 
that does RAM init (our "romstage") in the bootblock (up to 64k at the 
top end of the image). This worked for a long time, but required some 
hackery for supporting dual-image scenarios (like fallback/normal, where 
we normal passed control to fallback by jumping to start-8 bytes), and 
it also broke when AMD's RAM setup became so complicated that it doesn't 
fit in 64k anymore.
Those 64k are mandated by ROM mappings of various chipsets which, by 
default, only provide access to the upper 64k.

The newer one, created after the CBFS switch and exploiting its 
features, has a tiny bootblock (hence the name), often less than 1k, 
which implements some policy: By default, it simply looks up 
"fallback/romstage" in CBFS and executes it. Our other policy does the 
old fallback/normal routine (using a counter in nvram), but executing 
files in CBFS as well, instead of jumping into the void and hoping that 
there's code there.

The problem with the new approach is that it requires full ROM mapping 
rather early. Boards whose romstage fit in the 64k were free to defer 
setting up mapping to whereever it is convenient inside the romstage, so 
it's not all that easy to identify without means to test it. 
Unfortunately, this is a runtime problem, not a build problem, so it's 
hard to test all our 160 boards. For this reason, we kept both 
mechanisms in the tree, under the monikers BIG_BOOTBLOCK and TINY_BOOTBLOCK.

Some chipsets that are in common use were converted rather early, so by 
now, 100 boards use tiny bootblock, while 60 use the old method.
Since then - not much happened.

Kyösti Mälkki recently brought this issue up again (thanks!), and 
proposes to invert the flags, making tiny bootblock the default, so 
"big" bootblock has to be requested explicitely and also adding some 
"maybe" flag for boards that might just work. This is quite a large 
change, but I fear it'll bring relatively little progress - people will 
just copy the TINY_NO_BOOTBLOCK (or what it's called in the latest patch 
iteration) flag and move on.

Therefore, I propose (http://review.coreboot.org/#change,320) to get rid 
of the "big bootblock" variant altogether. This might break some boards 
(silently: they still build, but they fail on boot), but at least it 
forces action to fix them.

Advantages:
- one flag less to care about
- more uniform feature set (big bootblock didn't support any fallback 
mechanism)
- more opportunities to clean out and simplify the build system and code 
- there are some crude workarounds to make both mechanisms work

Disadvantages:
- Boards might be broken for a long time until someone tries them again. 
The visible result is that the boot fails early (ie. no error signalling 
at all, the system simply hangs, nothing visible).

It's possible to determine all boards that _might_ be affected (those 
that use a big bootblock now), so I could add that list to the commit 
message, hopefully helping whoever stumbles over this issue.

Comments?


Patrick




More information about the coreboot mailing list