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

Kyösti Mälkki kyosti.malkki at gmail.com
Mon Oct 24 12:40:34 CEST 2011

On Mon, 2011-10-24 at 12:15 +0200, Patrick Georgi wrote:
> 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

My latest patchset compile failed for only one board. For those already
using Cache-As-Ram but with big bootblock, can flip the menuconfig to
expert mode and choose "Switch to tiny bootblock (experimental)".

For those without Cache-As-Ram. I could have a go on the about 10 boards
with MPGA604 socket, but would have to do that blind-folded. At first
sight, it seems it can be handled with few ifdef's in the mainboard

At least I got the intel/xe7501devkit to compile very easily, using
the tyan/s2735 as a reference.

I still think there was a problem with the toolchain... ;)

Regards, KM

More information about the coreboot mailing list