[coreboot] [RFC]What to do with TINY_BOOTBLOCK?
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
>>>> 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.
>>> 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?
>> 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:
>> 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.
>> 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.
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
More information about the coreboot