In the last mail Timothy Baldwin said:
> In message <[EMAIL PROTECTED]>
> Russell King - ARM Linux Admin <[EMAIL PROTECTED]> wrote:
>
> [snip]
>
> > binutils-2.9.1.0.19a is acquitted of causing this malevolent behaviour.
>
> What did you compile binutils-2.9.1.0.19a with, and which library did
> you link it against? And which kernel are you running it under?
>
> linux/arch/arm/boot/compressed/piggy.o contains a valid gzip file, but
> linux/arch/arm/boot/compressed/vmlinux and linux/arch/arm/boot/zImage do
> not, therefore arm-linux-ld is a likely suspect. This is with
> binutils-2.9.1.0.19a statically or dynamically linked against
> libc 4.6.27, compiled with binutils-2.9.1.0.19a and egcs-2.91.57 19980901
> (egcs-1.1 release). I am currently running kernel 2.0.36 patched with
I find that vmlinux and zImage contain a valid gzip file around offset
460000 (ish). I've even checked the zImage file I've copied over to
RISC OS and it's still a valid gzip file in there. Howver, bootloader
loads zImage, starts uncompression code which finishes with err=1 at
DEBG("dyn3 "). So somewhere between ADFS and memory my zImage would
appear to be becoming garbled. (dyn3 appears to be after a dynamicly
deflated block has been read and the huffman tree successfully
constructed, so self-decompression code would appear to be finding
some valid gzip data.)
I'm stumped as to how to proceed from here.
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
