I have two coreboot trees. As far as I can tell they're identical. One produces working ROM images, and the other reboots when it jumps to the payload.
These are the only differences from the .map files:
Broken: 0000b03d A _binary_coreboot_ram_rom_size 0010b03d A _eiseg fffeb03d A _x fffeb03d D _binary_coreboot_ram_rom_end fffeb03d D _eliseg fffeb03d D _eram
Works: 0000b222 A _binary_coreboot_ram_rom_size 0010b222 A _eiseg fffeb222 A _x fffeb222 D _binary_coreboot_ram_rom_end fffeb222 D _eliseg fffeb222 D _eram
The broken one has a path of: /home/myles/try/buildrom-devel/work/coreboot/svn/ The working one's path is: /home/myles/buildrom-devel/work/coreboot/svn/
They were both working until yesterday. I've tried everything I can think of. I've removed the non-functional one's build directory completely. The payloads are bit-for-bit identical.
The only difference in the boot log before the reboot is this line: Works: Wrote coreboot table at: 00000500 - 00000788 checksum 5385
Broken: Wrote coreboot table at: 00000500 - 0000076c checksum 4fd2
diffing the hexdump of the ROM files shows that the payload is identical.
Any ideas?
It is true that I have a working tree, but if I didn't I'd be hosed so I'd like to know the real cause.
Thanks, Myles
how do you know it's rebooting when it jumps to payload, and it's not the payload panicing?
ron
On Wed, Mar 18, 2009 at 10:16 AM, ron minnich rminnich@gmail.com wrote:
how do you know it's rebooting when it jumps to payload, and it's not the payload panicing?
I don't know that for sure. Here's the last of the log:
elfboot: Attempting to load payload. rom_stream: 0xfff00000 - 0xfffdffff Found ELF candidate at offset 0 header_offset is 0 Try to load at offset 0x0 New segment addr 0xf0000 size 0x10000 offset 0x1000 filesize 0x10000 (cleaned up) New segment addr 0xf0000 size 0x10000 offset 0x1000 filesize 0x10000 Dropping non PT_LOAD segment Loading Segment: addr: 0x00000000000f0000 memsz: 0x0000000000010000 filesz: 0x0000000000010000 Jumping to boot code at 000f93f0
INIT detected from --- { APICID = 00 NODEID = 00 COREID = 00} ---
Issuing SOFT_RESET...
I'm trying to track down the difference in the coreboot tables now.
Thanks, Myles
On Tue, Mar 17, 2009 at 3:27 PM, Myles Watson mylesgw@gmail.com wrote:
I have two coreboot trees. As far as I can tell they're identical. One produces working ROM images, and the other reboots when it jumps to the payload.
These are the only differences from the .map files:
Broken: 0000b03d A _binary_coreboot_ram_rom_size 0010b03d A _eiseg fffeb03d A _x fffeb03d D _binary_coreboot_ram_rom_end fffeb03d D _eliseg fffeb03d D _eram
Works: 0000b222 A _binary_coreboot_ram_rom_size 0010b222 A _eiseg fffeb222 A _x fffeb222 D _binary_coreboot_ram_rom_end fffeb222 D _eliseg fffeb222 D _eram
The broken one has a path of: /home/myles/try/buildrom-devel/work/coreboot/svn/ The working one's path is: /home/myles/buildrom-devel/work/coreboot/svn/
They were both working until yesterday. I've tried everything I can think of. I've removed the non-functional one's build directory completely. The payloads are bit-for-bit identical.
The only difference in the boot log before the reboot is this line: Works: Wrote coreboot table at: 00000500 - 00000788 checksum 5385
Broken: Wrote coreboot table at: 00000500 - 0000076c checksum 4fd2
diffing the hexdump of the ROM files shows that the payload is identical.
Any ideas?
It is true that I have a working tree, but if I didn't I'd be hosed so I'd like to know the real cause.
That was the key. I hadn't done a make clean in the working tree. Rev 4000 broke it for me, but I'm still not sure why. Once I was doing make clean every time I could find the revision that was breaking. It looks like Rev 4000 changed the compile flags, so that's where I'm going next. Everything else in 4000 looks innocuous to me.
Thanks, Myles
On Wed, Mar 18, 2009 at 12:17 PM, Myles Watson mylesgw@gmail.com wrote:
On Tue, Mar 17, 2009 at 3:27 PM, Myles Watson mylesgw@gmail.com wrote:
I have two coreboot trees. As far as I can tell they're identical. One produces working ROM images, and the other reboots when it jumps to the payload.
That was the key. I hadn't done a make clean in the working tree. Rev 4000 broke it for me, but I'm still not sure why. Once I was doing make clean every time I could find the revision that was breaking. It looks like Rev 4000 changed the compile flags, so that's where I'm going next. Everything else in 4000 looks innocuous to me.
The question is why these compiler flags for coreboot make SeaBIOS panic. I'm still trying to narrow it down, but if you spot it first that would be great!
Thanks, Myles
Modified: trunk/coreboot-v2/src/config/Config.lb =================================================================== --- trunk/coreboot-v2/src/config/Config.lb 2009-03-13 00:44:09 UTC (rev 3999) +++ trunk/coreboot-v2/src/config/Config.lb 2009-03-13 15:42:27 UTC (rev 4000) @@ -10,7 +10,7 @@ makedefine GCC_INC_DIR := $(shell LC_ALL=C $(GCC) -print-search-dirs | sed -ne "s/install: (.*)/\1include/gp")
makedefine CPPFLAGS := -I$(TOP)/src/include -I$(TOP)/src/arch/$(ARCH)/include -I$(GCC_INC_DIR) $(CPUFLAGS) -makedefine CFLAGS := $(CPU_OPT) $(DISTRO_CFLAGS) $(CPPFLAGS) -Os -nostdinc -nostdlib -fno-builtin -Wall +makedefine CFLAGS := $(CPU_OPT) $(DISTRO_CFLAGS) $(CPPFLAGS) -Os -nostdinc -nostdlib -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -Werror-implicit-function-declaration -Wstrict-aliasing -Wshadow -fno-common -ffreestanding -fno-builtin -fomit-frame-pointer
if ASSEMBLER_DEBUG makedefine DEBUG_CFLAGS := -g -dA -fverbose-asm
On Wed, Mar 18, 2009 at 12:38:34PM -0600, Myles Watson wrote:
On Wed, Mar 18, 2009 at 12:17 PM, Myles Watson mylesgw@gmail.com wrote:
On Tue, Mar 17, 2009 at 3:27 PM, Myles Watson mylesgw@gmail.com wrote:
I have two coreboot trees. As far as I can tell they're identical. One produces working ROM images, and the other reboots when it jumps to the payload.
That was the key. I hadn't done a make clean in the working tree. Rev 4000 broke it for me, but I'm still not sure why. Once I was doing make clean every time I could find the revision that was breaking. It looks like Rev 4000 changed the compile flags, so that's where I'm going next. Everything else in 4000 looks innocuous to me.
The question is why these compiler flags for coreboot make SeaBIOS panic. I'm still trying to narrow it down, but if you spot it first that would be great!
FWIW, I'm seeing the exact same thing (reboot when jump to payload) with a filo payload and the latest coreboot tree (patched for m2a-vm):
========================================================================== Loading Segment: addr: 0x0000000000100000 memsz: 0x000000000039c550 filesz: 0x00 Clearing Segment: addr: 0x0000000000114e00 memsz: 0x0000000000387750 Loading Segment: addr: 0x000000000049c550 memsz: 0x0000000000000048 filesz: 0x08 Jumping to boot code at 00100090
INIT detected from --- { APICID = 00 NODEID = 00 COREID = 00} ---
Issuing SOFT_RESET...
coreboot-2.0.0 Wed Mar 18 15:05:31 EDT 2009 starting... bsp_apicid=0x0 core0 started: ===========================================================================
Full boot log at
http://ward.vandewege.net/coreboot/m2a-vm/m2a-vm-cb4017-resets.cap
Thanks, Ward.
On Wed, Mar 18, 2009 at 1:31 PM, Ward Vandewege ward@gnu.org wrote:
On Wed, Mar 18, 2009 at 12:38:34PM -0600, Myles Watson wrote:
On Wed, Mar 18, 2009 at 12:17 PM, Myles Watson mylesgw@gmail.com wrote:
On Tue, Mar 17, 2009 at 3:27 PM, Myles Watson mylesgw@gmail.com wrote:
I have two coreboot trees. As far as I can tell they're identical. One produces working ROM images, and the other reboots when it jumps to the payload.
That was the key. I hadn't done a make clean in the working tree. Rev 4000 broke it for me, but I'm still not sure why. Once I was doing make clean every time I could find the revision that was breaking. It looks like Rev 4000 changed the compile flags, so that's where I'm going next. Everything else in 4000 looks innocuous to me.
The question is why these compiler flags for coreboot make SeaBIOS panic. I'm still trying to narrow it down, but if you spot it first that would be great!
FWIW, I'm seeing the exact same thing (reboot when jump to payload) with a filo payload and the latest coreboot tree (patched for m2a-vm):
Thanks! That helps to know it's not just seabios. If you remove -fno-frame-pointer it should work again.
Myles
On Wed, Mar 18, 2009 at 01:42:56PM -0600, Myles Watson wrote:
On Wed, Mar 18, 2009 at 1:31 PM, Ward Vandewege ward@gnu.org wrote:
On Wed, Mar 18, 2009 at 12:38:34PM -0600, Myles Watson wrote:
On Wed, Mar 18, 2009 at 12:17 PM, Myles Watson mylesgw@gmail.com wrote:
On Tue, Mar 17, 2009 at 3:27 PM, Myles Watson mylesgw@gmail.com wrote:
I have two coreboot trees. As far as I can tell they're identical. One produces working ROM images, and the other reboots when it jumps to the payload.
That was the key. I hadn't done a make clean in the working tree. Rev 4000 broke it for me, but I'm still not sure why. Once I was doing make clean every time I could find the revision that was breaking. It looks like Rev 4000 changed the compile flags, so that's where I'm going next. Everything else in 4000 looks innocuous to me.
The question is why these compiler flags for coreboot make SeaBIOS panic. I'm still trying to narrow it down, but if you spot it first that would be great!
FWIW, I'm seeing the exact same thing (reboot when jump to payload) with a filo payload and the latest coreboot tree (patched for m2a-vm):
Thanks! That helps to know it's not just seabios. If you remove -fno-frame-pointer it should work again.
Confirmed, removing -fomit-frame-pointer fixes the boot with FILO.
Thanks! Ward.
On Wed, Mar 18, 2009 at 12:48 PM, Ward Vandewege ward@gnu.org wrote:
Confirmed, removing -fomit-frame-pointer fixes the boot with FILO.
so you might want to look at the filo entry point and see if it expecting some reasonable value in %ebp. If so, we can probably fix the boot code to always set something sane in %ebp, no matter how coreboot is compiled.
Really, though, I don't think coreboot runs for a long enough time that omitting frame pointers is a huge performance win. It would just be nice to confirm WHY this is happening.
ron
On 18.03.2009 21:08 Uhr, ron minnich wrote:
On Wed, Mar 18, 2009 at 12:48 PM, Ward Vandewege ward@gnu.org wrote:
Confirmed, removing -fomit-frame-pointer fixes the boot with FILO.
so you might want to look at the filo entry point and see if it expecting some reasonable value in %ebp. If so, we can probably fix the boot code to always set something sane in %ebp, no matter how coreboot is compiled.
Really, though, I don't think coreboot runs for a long enough time that omitting frame pointers is a huge performance win. It would just be nice to confirm WHY this is happening.
ron
I think we're doing this because of code size rather than speed.
-fomit-frame-pointer Don't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions. [...] Enabled at levels -O, -O2, -O3, -Os.
The reason I brought this into v2 is that the "so much cooler" v3 has been using it for quite a while ;-)
On 18.03.2009 20:42 Uhr, Myles Watson wrote:
On Wed, Mar 18, 2009 at 1:31 PM, Ward Vandewege ward@gnu.org wrote:
On Wed, Mar 18, 2009 at 12:38:34PM -0600, Myles Watson wrote:
On Wed, Mar 18, 2009 at 12:17 PM, Myles Watson mylesgw@gmail.com wrote:
On Tue, Mar 17, 2009 at 3:27 PM, Myles Watson mylesgw@gmail.com wrote:
I have two coreboot trees. As far as I can tell they're identical. One produces working ROM images, and the other reboots when it jumps to the payload.
That was the key. I hadn't done a make clean in the working tree. Rev 4000 broke it for me, but I'm still not sure why. Once I was doing make clean every time I could find the revision that was breaking. It looks like Rev 4000 changed the compile flags, so that's where I'm going next. Everything else in 4000 looks innocuous to me.
The question is why these compiler flags for coreboot make SeaBIOS panic. I'm still trying to narrow it down, but if you spot it first that would be great!
FWIW, I'm seeing the exact same thing (reboot when jump to payload) with a filo payload and the latest coreboot tree (patched for m2a-vm):
Thanks! That helps to know it's not just seabios. If you remove -fno-frame-pointer it should work again.
Now, let's find out what causes this.. What compiler version are you guys using, and what distribution?
Now, let's find out what causes this.. What compiler version are you guys using, and what distribution?
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12) Ubuntu 8.10
Thanks, Myles
On Wed, Mar 18, 2009 at 11:28:00PM +0100, Stefan Reinauer wrote:
On 18.03.2009 20:42 Uhr, Myles Watson wrote:
On Wed, Mar 18, 2009 at 1:31 PM, Ward Vandewege ward@gnu.org wrote:
On Wed, Mar 18, 2009 at 12:38:34PM -0600, Myles Watson wrote:
On Wed, Mar 18, 2009 at 12:17 PM, Myles Watson mylesgw@gmail.com wrote:
On Tue, Mar 17, 2009 at 3:27 PM, Myles Watson mylesgw@gmail.com wrote:
I have two coreboot trees. As far as I can tell they're identical. One produces working ROM images, and the other reboots when it jumps to the payload.
That was the key. I hadn't done a make clean in the working tree. Rev 4000 broke it for me, but I'm still not sure why. Once I was doing make clean every time I could find the revision that was breaking. It looks like Rev 4000 changed the compile flags, so that's where I'm going next. Everything else in 4000 looks innocuous to me.
The question is why these compiler flags for coreboot make SeaBIOS panic. I'm still trying to narrow it down, but if you spot it first that would be great!
FWIW, I'm seeing the exact same thing (reboot when jump to payload) with a filo payload and the latest coreboot tree (patched for m2a-vm):
Thanks! That helps to know it's not just seabios. If you remove -fno-frame-pointer it should work again.
Now, let's find out what causes this.. What compiler version are you guys using, and what distribution?
Ubuntu 8.10, 32 bit
gcc (Ubuntu 4.3.2-1ubuntu12) 4.3.2
Thanks, Ward.
-
Myles Watson -
ron minnich -
Stefan Reinauer -
Ward Vandewege