[coreboot] [RFC]What to do with TINY_BOOTBLOCK?
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.
> - one flag less to care about
> - more uniform feature set (big bootblock didn't support any fallback
> - more opportunities to clean out and simplify the build system and code
> - there are some crude workarounds to make both mechanisms work
> - 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.
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... ;)
More information about the coreboot