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. KM -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
