[coreboot] [RFC]What to do with TINY_BOOTBLOCK?
marcj303 at gmail.com
Mon Oct 24 21:53:24 CEST 2011
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
>> > 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?
> 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.
More information about the coreboot