Re: trouble with 2.6.6 (or: Penguin problem?)
> > > CTS> ...The mac had a problem with backwards seeking when loading the kernel,
> > > CTS> I think I read something about this here before. Has there been a solution,
> > > CTS> ie some fix in the binutils or something? I didn't find this again with
> > > CTS> google...
> > >
> > > Some binutils (or gcc?) change caused the order of segments in vmlinux
> > > to change from being sorted by address. This breaks Penguin. No known
> > > progress on this one, neither from finding out what binutils/gcc change
> > > broke it nor from fixing penguin to work with these kind on binaries.
> >
> > It's binutils. But it's not simply the order.
> >
> > [snip]
> >
> > However, if I use m68k-linux-ld from binutils 2.9.5.0.37 to perform the final
> > linking step of vmlinux, I can boot the kernel fine under UAE (until it hangs
>
> And binutils 2.13.90.0.10 is OK as well.
I've had the same problem with binutils 2.14 and 2.15. Penguin barfs on
the third segment in the kernel image (backward seek).
$ m68k-unknown-linux-gnu-objdump -p -f vmlinux-2.4.26
vmlinux-2.4.26: file format elf32-m68k
architecture: m68k, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x00002000
Program Header:
LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**13
filesz 0x00194a4c memsz 0x001c52a4 flags rwx
LOAD off 0x001952b0 vaddr 0x001c52b0 paddr 0x001c52b0 align 2**13
filesz 0x00014d50 memsz 0x00014d50 flags rwx
STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
filesz 0x00000000 memsz 0x00000000 flags rwx
private flags = 0:
I suspect the best fix is for the bootloader to ignore zero length
segments (or is binutils actually broken?). In the meantime, a workaround
is to set the segment count in the ELF header to 2, by piping the
uncompressed kernel image through this perl script:
#!/usr/bin/perl
system( "dd", "bs=1", "count=45" );
print pack( "C", 2 );
system( "dd", "bs=1", "count=1", "of=/dev/null" );
system( "dd" )
Ulgy, but It Works For Me.
-F
Reply to: