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
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
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
On 10/24/11 3:15 AM, Patrick Georgi wrote:
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).
I like the idea, but I would suggest the following:
We create an deprecated_boards_201110 branch which holds e.g. all romcc boards, and drop them from the most current tree. The code is still there, so we don't have to worry about removing supported boards (or breaking them by accident), and if someone has such a board and wants to bring it over, they're welcome to send a patch to fix it.
Stefan
On Mon, 24 Oct 2011 18:06:54 -0700, Stefan Reinauer wrote:
We create an deprecated_boards_201110 branch which holds e.g. all romcc boards, and drop them from the most current tree.
If we go down this road, the tree easily shrinks to the 20-or-so boards that are actually in use/worked on. Maybe that's the right thing to do, not sure.
Patrick
On Mon, 2011-10-24 at 12:15 +0200, Patrick Georgi wrote:
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.
I already commented that this would boot. Well it does get me up to the point that it loads payload. But then it restarts once and halts on the second run of fallback/coreboot_ram.
So this is ROMCC with TINY_BOOTBLOCK, fixed to "fallback".
Cold boot :
coreboot-4.0-1793-g3e53815-dirty Tue Oct 25 15:13:50 EEST 2011 starting... SMBus controller enabled Ram1.00 Ram2.00 Ram3 Ram4 SDRAM is up. Loading image. Searching for fallback/coreboot_ram Check fallback/romstage Check fallback/coreboot_ram Stage: loading fallback/coreboot_ram @ 0x100000 (311296 bytes), entry @ 0x100000 Stage: done loading. Jumping to image. POST: 0x80 POST: 0x39 coreboot-4.0-1793-g3e53815-dirty Tue Oct 25 15:13:50 EEST 2011 booting... POST: 0x40 clocks_per_usec: 3202 Enumerating buses... Show all devs...Before device enumeration. Root Device: enabled 1 PCI_DOMAIN: 0000: enabled 1
-- a lot of PCI & APIC and microcode here, nothing unusual
POST: 0x9e 0. FREE SPACE cfffe000 00002000 1. GDT cfff0200 00000200 2. ACPI cfff0400 0000b400 3. SMBIOS cfffb800 00000800 4. COREBOOT cfffc000 00002000 Searching for fallback/payload Check fallback/romstage Check fallback/coreboot_ram Check fallback/payload Got a payload Loading segment from rom address 0xfffb3878 data (compression=0) New segment dstaddr 0x0 memsize 0x194cc srcaddr 0xfffb38b0 filesize 0x194cc (cleaned up) New segment addr 0x0 size 0x194cc offset 0xfffb38b0 filesize 0x194cc Loading segment from rom address 0xfffb3894 Entry Point 0x000fc8e4 Payload is overwriting coreboot tables. Loading Segment: addr: 0x0000000000000000 memsz: 0x00000000000194cc filesz: 0x00000000000194cc lb: [0x0000000000100000, 0x000000000014c000) Post relocation: addr: 0x0000000000000000 memsz: 0x00000000000194cc filesz: 0x00000000000194cc it's not compressed! [ 0x00000000, 000194cc, 0x000194cc) <- fffb38b0 dest 00000000, end 000194cc, bouncebuffer cff58000 Loaded segments Jumping to boot code at 0 POST: 0xf8 entry = 0x00000000 lb_start = 0x00100000 lb_size = 0x0004c000 adjust = 0xcfea4000 buffer = 0xcff58000 elf_boot_notes = 0x00123f58 adjusted_boot_notes = 0xcffc7f58
-- at this point it resets
coreboot-4.0-1793-g3e53815-dirty Tue Oct 25 15:13:50 EEST 2011 starting... SDRAM is up. Loading image. Searching for fallback/coreboot_ram Check fallback/romstage Check fallback/coreboot_ram Stage: loading fallback/coreboot_ram @ 0x100000 (311296 bytes), entry @ 0x100000 Stage: done loading. Jumping to image. POST: 0x80 POST: 0x39 coreboot-4.0-1793-g3e53815-dirty Tue Oct 25 15:13:50 EEST 2011 booting... POST: 0x40 clocks_per_usec: 3202 Enumerating buses... Show all devs...Before device enumeration. Root Device: enabled 1 PCI_DOMAIN: 0000: enabled 1
-- a lot a PCI scan here again
scan_static_bus for PCI: 00:1f.0 done PCI: pci_scan_bus returning with max=005 POST: 0x55 scan_static_bus for Root Device done done POST: 0x66 Allocating resources... Reading resources... Root Device read_resources bus 0 link: 0 PCI_DOMAIN: 0000 read_resources bus 0 link: 0 PCI: 00:01.0 read_cl
-- and it halts here without any further reset
Any suggestions where to look?
KM
-
Kyösti Mälkki -
Marc Jones -
Patrick Georgi -
Stefan Reinauer