On Feb 11, 2008 10:28 AM, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote: > On 11.02.2008 18:08, Myles Watson wrote: > > On Feb 10, 2008 5:07 AM, Carl-Daniel Hailfinger > > <[EMAIL PROTECTED]> 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 -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
