[coreboot] Weirdness with lzma setting in v3
myles at pel.cs.byu.edu
Mon Feb 11 18:08:55 CET 2008
On Feb 10, 2008 5:07 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at 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.
> >> 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.
> > 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.
> 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
I didn't use buildrom at all for this, and I used the default (make
menuconfig; exit) config.
Thanks for the lar -l suggestion.
Here's the URL to the failing ROM:
normal/option_table (932 bytes @0x50);loadaddress 0x0 entry 0x0
normal/stage2/segment0 (191792 bytes, lzma compressed to 110 bytes
@0x450);loadaddress 0x0xa1c0 entry 0x0x2000
normal/stage2/segment1 (28084 bytes, lzma compressed to 14976 bytes
@0x510);loadaddress 0x0x2000 entry 0x0x2000
normal/stage2/segment0 (4540 bytes, lzma compressed to 316 bytes
@0x3fe0);loadaddress 0x0x9000 entry 0x0x2000
normal/initram/segment0 (432 bytes @0x4170);loadaddress 0x0 entry 0x0x42
bootblock (20480 bytes @0x3b000)
More information about the coreboot