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.
Thanks, Myles
can you send me the full build log?
ron
On Wed, Dec 31, 2008 at 12:33 PM, ron minnich rminnich@gmail.com wrote:
can you send me the full build log?
Sure.
Thanks, Myles
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
-----Original Message----- From: Jordan Crouse [mailto:jordan@cosmicpenguin.net] Sent: Thursday, January 01, 2009 8:30 PM To: Myles Watson Cc: Coreboot Subject: Re: [coreboot] Help with boot block problem
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?
Good thought. Unfortunately no. It's the same machine, back to back compiles with a make clean and make menuconfig in between.
Thanks, Myles
-
Jordan Crouse -
Myles Watson -
ron minnich