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

[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
>> > 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
>>
>>
>
> 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.
>
> SOUTHBRIDGE_AMD_CS5535
> SOUTHBRIDGE_AMD_CS5536
> SOUTHBRIDGE_INTEL_I3100
> SOUTHBRIDGE_INTEL_I82801AX
> SOUTHBRIDGE_INTEL_I82801EX
> SOUTHBRIDGE_INTEL_I82801GX
> SOUTHBRIDGE_INTEL_I82870
> SOUTHBRIDGE_RICOH_RL5C476
> SOUTHBRIDGE_TI_PCI7420
> SOUTHBRIDGE_VIA_K8T890
> SOUTHBRIDGE_VIA_VT8237R
>
> It appears all but the two below already have an implementation with
> tiny bootblock on some other mainboard:
>
> SOUTHBRIDGE_AMD_CS5535
> SOUTHBRIDGE_AMD_CS5536
>
> 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.

marc

http://se-eng.com