On 11.02.2008 18:08, Myles Watson wrote:
On Feb 10, 2008 5:07 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 10.02.2008 05:15, Myles Watson wrote:
On 08.02.2008 20:08, Myles Watson wrote:
Sorry in advance that I only have time to report the problem. If no one beats me to it I'll look into it a little more on Monday.
Something goes wrong when lzma is enabled (which it is by default)
I'm attaching my config which succeeds (nolzma.config), and the serial output from qemu using lzma and not. For some reason, segment0 gets found twice when lzma is used? Anyway, it doesn't find the devices it should and dies.
Very weird. It worked for me, but I always issue a make distclean before configuring.
I was removing the directory every time, but if it were a makefile issue it would still be an important bug to me.
The build/ directory in coreboot or the whole coreboot directory? Removing the build/ directory is not equivalent to a make distclean. Simply copying defconfig to .config will cause build errors, btw. You have to make oldconfig after copying over the defconfig (bug?).
I just tried the default coreboot config again (make distclean; make menuconfig; (exit and save)) and my log (with lzma) looks exactly (except for different compression) like your working log (without lzma). Having the failing .config would help a lot. The failing ROM would also be interesting (please don't send that to the list, upload it somewhere instead).
The failing .config is in mainboard/emulation/qemu-x86/defconfig
Boot log with defconfig attached. Works for me.
I guess it must be another tool issue.
Yes.
It's the same (except for ROM Size) as the one you got (hopefully.)
I'll put the ROM somewhere else if it still fails for me on Monday. It's possible that it's buildrom's problem. I haven't tried the ROM without adding the payload.
I usually don't use buildrom for my tests and I don't specify a payload. That saves a lot of time for the stuff I'm working on.
I can see why you would save time testing that way, but coreboot without a payload is only of academic interest. There should be some testing with a payload.
Actually, coreboot with a payload is of lesser prcatical interest than coreboot without a payload, unless the interested person is an end-user or wants to debug IRQ issues.
If you manage to reproduce with a non-buildrom coreboot build with only a single instance of make (no "make -j"), we should indeed investigate. Right now I'd say the archive is corrupted/contains garbage. This should be verifiable with "lar -l coreboot.rom". The next step would be to find out how the archive ended up that way. Multiple lar instances working on the same archive at the same time? Parallelization issues? RAM/disk corruption?
I tried it again with the latest from svn. Here's the output from lar -l. lzma is achieving some amazing compression, and there are two normal/stage2/segment0.
I didn't use buildrom at all for this, and I used the default (make menuconfig; exit) config.
Thanks for the lar -l suggestion.
You're welcome.
Here's the URL to the failing ROM: http://www.pel.cs.byu.edu/~myles/failing.lzma.rom.tar.gz
Myles
normal/option_table (932 bytes @0x50);loadaddress 0x0 entry 0x0
OK
normal/stage2/segment0 (191792 bytes, lzma compressed to 110 bytes @0x450);loadaddress 0x0xa1c0 entry 0x0x2000
That's bss.
normal/stage2/segment1 (28084 bytes, lzma compressed to 14976 bytes @0x510);loadaddress 0x0x2000 entry 0x0x2000
That's code.
normal/stage2/segment0 (4540 bytes, lzma compressed to 316 bytes @0x3fe0);loadaddress 0x0x9000 entry 0x0x2000
Now that one should be data.
normal/initram/segment0 (432 bytes @0x4170);loadaddress 0x0 entry 0x0x42 bootblock (20480 bytes @0x3b000)
OK
Please upload build/lar.tmp/normal/stage2. It seems the lar utility is parsing the file incorrectly and I want to know if this is a toolchain interaction problem or a lar issue.
Regards, Carl-Daniel