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