[coreboot] Weirdness with lzma setting in v3

[Myles Watson]

On Feb 11, 2008 10:28 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 11.02.2008 18:08, Myles Watson wrote:
> > 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.
> >
>
> 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.
>
http://www.pel.cs.byu.edu/~myles/build.lar.tmp.normal.stage2.tar.gz

Myles