On Mon, Oct 24, 2011 at 12:37 PM, Kyösti Mälkki <[email protected]> wrote: > On Mon, 2011-10-24 at 10:22 -0600, Marc Jones wrote: >> On Mon, Oct 24, 2011 at 4:15 AM, Patrick Georgi <[email protected]> >> 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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
