[coreboot] Weirdness with lzma setting in v3

Myles Watson myles at pel.cs.byu.edu
Mon Feb 11 19:13:59 CET 2008 

On Feb 11, 2008 10:45 AM, Myles Watson <myles at pel.cs.byu.edu> wrote:
> 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
>

Here's the output from lar -v when trying to parse stage2:

  LAR     build/coreboot.rom
rm -f /home/myles/buildrom/try/buildrom/buildrom-devel/work/coreboot-v3/svn/build/coreboot.rom
cd /home/myles/buildrom/try/buildrom/buildrom-devel/work/coreboot-v3/svn/build/lar.tmp
&& ../util/lar/lar -v -e -C lzma -c \
                ../coreboot.rom \
                nocompress:normal/initram normal/stage2
nocompress:normal/option_table \
                -s 262144 -b
/home/myles/buildrom/try/buildrom/buildrom-devel/work/coreboot-v3/svn/build/coreboot.bootblock
Type 2 machine 3 version 1 entry 0x2000 phoff 52 shoff 38520 flags 0
hsize 52 phentsize 32 phnum 3 s_hentsize 40 s_shnum 9
output_elf_segments: header 0x2aaaaab0c000 #headers 3
Dropping non SHT_NOBITS section
Dropping non SHT_NOBITS section
Dropping non SHT_NOBITS section
Dropping non SHT_NOBITS section
New section addr 0xa1c0 size 0x2ed30
(cleaned up) New section addr 0xa1c0 size 0x0x2ed30
Dropping non SHT_NOBITS section
Dropping non SHT_NOBITS section
Dropping non SHT_NOBITS section
Dropping non SHT_NOBITS section
New segment addr 0x8192lx size 0x28084lx offset 0x4096lx filesize 0x28084lx
(cleaned up) New segment addr 0x2000 size 0x0x6db4 offset 0x1000
Copy to 0x2000 from 0x2aaaaab0d000 for 28084 bytes
entry 8192x loadaddr 8192x
New segment addr 0x36864lx size 0x196336lx offset 0x32768lx filesize 0x4540lx
(cleaned up) New segment addr 0x9000 size 0x0x11bc offset 0x8000
Copy to 0x9000 from 0x2aaaaab14000 for 4540 bytes
entry 8192x loadaddr 36864x
Dropping non PT_LOAD segment
Type 2 machine 3 version 1 entry 0x42 phoff 52 shoff 660 flags 0 hsize
52 phentsize 32 phnum 2 s_hentsize 40 s_shnum 9
output_elf_segments: header 0x2aaaaab19000 #headers 2
Dropping non SHT_NOBITS section
Dropping non SHT_NOBITS section
Dropping non SHT_NOBITS section
Dropping non SHT_NOBITS section
Dropping non SHT_NOBITS section
Dropping non SHT_NOBITS section
Dropping non SHT_NOBITS section
Dropping non SHT_NOBITS section
Dropping non SHT_NOBITS section
New segment addr 0x0lx size 0x432lx offset 0x116lx filesize 0x432lx
(cleaned up) New segment addr (nil) size 0x0x1b0 offset 0x74
Copy to (nil) from 0x2aaaaab19074 for 432 bytes
entry 66x loadaddr 0x
Dropping non PT_LOAD segment
# QEMU wants bios.bin:
# Run "qemu -L build/ -serial stdio -hda /dev/zero".
printf "  CP      build/bios.bin\n"
  CP      build/bios.bin

Myles

More information about the coreboot mailing list