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

Patrick Georgi patrick at georgi-clan.de
Mon Oct 24 22:02:33 CEST 2011

Am Montag, 24. Oktober 2011 21:53:24 schrieb Marc Jones:
> On Mon, Oct 24, 2011 at 12:37 PM, Kyösti Mälkki<kyosti.malkki at gmail.com>  wrote:
>> On Mon, 2011-10-24 at 10:22 -0600, Marc Jones wrote:
>>> 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
>>>> 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
>> Hello Marc
>> I am glad this topic brings up discussion.
>> List of mainboards that currently do not select TINY_BOOTBLOCK
>> and do not select ROMCC in Kconfig:
>> aaeon/pfm-540i_revb
>> amd/db800
>> amd/norwich
>> amd/rumba
>> artecgroup/dbe61
>> asus/a8v-e_deluxe
>> asus/a8v-e_se
>> asus/mew-am
>> asus/mew-vm
>> bcom/winnetp680
>> digitallogic/msm800sev
>> ecs/p6iwp-fe
>> hp/e_vectra_p2706t
>> iei/pcisa-lx-800-r10
>> intel/eagleheights
>> intel/mtarvon
>> jetway/j7f24
>> lenovo/x60
>> lippert/frontrunner
>> lippert/hurricane-lx
>> lippert/literunner-lx
>> lippert/roadrunner-lx
>> lippert/spacerunner-lx
>> mitac/6513wu
>> msi/ms6178
>> nec/powermate2000
>> pcengines/alix1c
>> pcengines/alix2d
>> roda/rk886ex
>> traverse/geos
>> tyan/s2735
>> via/epia-cn
>> via/epia-m700
>> via/pc2500e
>> winent/pl6064
>> wyse/s50
>> List of southbridges on those mainboards, as taken from the
>> mainboard/Kconfig files.
>> It appears all but the two below already have an implementation with
>> tiny bootblock on some other mainboard:
>> It may be that the only reason BIG_BOOTBLOCK gets dragged along, is that
>> there has been no clear migration path away from it. I think there now
>> exists a better choice, pushing the choice in menuconfig.
>> http://review.coreboot.org/333
>> As a side note. I did not realise it was possible to have TINY_BOOTBLOCK
>> without Cache-As-Ram. There was no such implementation (besides QEMU).
>> I thought that tiny bootblock would also move memory controller
>> initialisation away from romstage (so it could be compiled with gcc) and
>> then utilise cache for its stack.
> i think that the change for 5535/5536 should be fine. There is a SB
> rom decode register that has to be written, but that should be it.
Sounds simple.

A side note: In my drop-tinybootblock patch, I changed the MTRR 
behaviour of romcc boards to not require the XIP_ROM_BASE, but to 
calculate it from current EIP and XIP_ROM_SIZE instead. This should be 
safe, unless XIP_ROM_SIZE doesn't cover the entire code section, which 
would be a problem with the AUTO_XIP_ROM_BASE trick, too. I'll split 
this in a separate patch again (tomorrow), but other than that:
Shall we go that route with the various CAR setups, too? It eliminates 
the link-twice trick we use, and should have no negative impact.
Essentially, the AUTO_XIP_ROM_BASE code is replaced by
   movl dummyname, %eax;
   andl CONFIG_XIP_ROM_SIZE, %eax;
   orl MTRR_something, %eax; // as usual

It's all based on that MTRR configuration is defined to match:
addr & mtrr_size = mttr_base & mtrr_size (as taken from the intel 

That is, MTRRs always cover a power-of-two sized area (size = x) with 
alignment x.


More information about the coreboot mailing list