[coreboot] [RFC]What to do with TINY_BOOTBLOCK?

[Kyösti Mälkki]

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