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

[Marc Jones]

On Mon, Oct 24, 2011 at 4:15 AM, Patrick Georgi <patrick at georgi-clan.de> 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?
>

Hi Patrick,

I think that this makes sense. It seems like the change would improve
the build and standardize early coreboot. I think that we can support
developers in the porting for those platforms when they come up. The
ROM decode is a typically a southbridge setting, so do you know what
southbridges would be untested?

Marc




-- 
http://se-eng.com