[coreboot] Help with boot block problem

[Jordan Crouse]

Myles Watson wrote:
> I'm porting a board from v2->v3, and I'm running out of space in the
> bootblock, even though it doesn't seem like I should.
> 
> Snippet of broken coreboot.initram.map:
> 
> ffffe3f3 A stage0_rawpnp_exit_ext_func_mode
> ffffe3fc A stage0_rawpnp_set_logical_device
> ffffe41f A stage0_rawpnp_set_iobase
> ffffe448 A stage0_rawpnp_set_enable
> ffffe470 A stage0_protected_stage0
> ffffe47f A stage0___protected_stage0
> ffffe5e8 A stage0__stage0
> ffffe630 A stage0_gdtptr
> fffff960 A stage0_option_table
> fffffff0 A stage0__resetjump
> fffffff0 A stage0__ROMTOP
> 
> Notice that stage0_gdtptr takes fffff960 - ffffe630 = 0x1966
> 
> And working coreboot.initram.map:
> 
> ffffe687 A stage0_rawpnp_read_config
> ffffe69f A stage0_rawpnp_exit_ext_func_mode
> ffffe6a8 A stage0_rawpnp_set_logical_device
> ffffe6cb A stage0_rawpnp_set_iobase
> ffffe6f4 A stage0_rawpnp_set_enable
> ffffe71c A stage0_protected_stage0
> ffffe72b A stage0___protected_stage0
> ffffe894 A stage0__stage0
> ffffe8dc A stage0_gdtptr
> fffff720 A stage0_option_table
> fffffe10 A stage0__estage0_1
> fffffff0 A stage0__resetjump
> fffffff0 A stage0__ROMTOP
> 
> Notice that stage0_gdtptr takes fffff720 - ffffe8dc = 0xe44
> 
> The broken one's gdtptr takes about twice as much?
>
> This might not be the problem, but I don't know where else to look.

Total shot in the dark without looking at code - but a doubling in size 
may indicate a 32 bit vs 64 bit issue.  Did you compile on different 
architectures?

Jordan