On Mon, 2011-10-24 at 12:15 +0200, Patrick Georgi 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? > > > Patrick >
My latest patchset compile failed for only one board. For those already using Cache-As-Ram but with big bootblock, can flip the menuconfig to expert mode and choose "Switch to tiny bootblock (experimental)". For those without Cache-As-Ram. I could have a go on the about 10 boards with MPGA604 socket, but would have to do that blind-folded. At first sight, it seems it can be handled with few ifdef's in the mainboard romstage.c! At least I got the intel/xe7501devkit to compile very easily, using the tyan/s2735 as a reference. I still think there was a problem with the toolchain... ;) Regards, KM -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
