On Mon, 2011-10-24 at 10:22 -0600, Marc Jones wrote:
On Mon, Oct 24, 2011 at 4:15 AM, Patrick Georgi patrick@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.
KM
On Mon, Oct 24, 2011 at 12:37 PM, Kyösti Mälkki kyosti.malkki@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@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
asus/a8v-e_deluxe asus/a8v-e_se
I can test/fix on a8v-e_se, plus I have the VT8237R datasheet so I can re-check if whole rom mapping needs something else or not. Most likely not, because it does work on VT8237S :)
R.
-
Kyösti Mälkki -
Marc Jones -
Rudolf Marek