Hi Wolfgang,
thanks for your reply.
Wolfgang Denk wrote:
Are you sure it is only an issue of gzip compression, and not for example of image sizes?
The "gzip -8" compressed kernel, which does work, is obviously bigger (vmlinux.bin.gz=1717766 (i.s.o. 1717544). Uncompressed size is unchanged of course (vmlinux.bin=3646004)).
I have another "gzip -9" kernel which is smaller compressed (vmlinux.bin.gz=1716893, vmlinux.bin=3646004). This one does work.
To be more sure I did some more tests:
I extended the working "gzip -9" kernel with dummy bytes, recompressed it with "gzip -9" (now vmlinux.bin.gz=1717607, vmlinux.bin=3660385) and it still works.
I added misc binary support to the problematic kernel, the resulting image size are: vmlinux.bin.gz=1720890 vmlinux.bin=3654196. Now the problem is gone.
I removed misc binary support from the above kernel, the resulting image sizes are (again) vmlinux.bin.gz=1717544, vmlinux.bin=3646004. The problem is there.
As far as I know my start/load memory addresses are ok.
Are you sure?
no, therefore I included more details.
=> run tird
<sarcasm> Excellent information. Now we all know *exactly* which commands you might be running :-( </sarcasm>
tird=tftp 2000000 uImage;tftp 1000000 initramfs.igz.uboot;tftp 400000 mpc8313erdb.dtb;bootm 2000000 1000000 400000
Filename 'uImage'. Load address: 0x2000000 Loading: ################################################################# ##################################################### done Bytes transferred = 1717604 (1a3564 hex)
...
## Booting kernel from Legacy Image at 02000000 ... Image Name: Linux-2.6.28wa2 Created: 2009-01-19 11:36:09 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1717540 Bytes = 1.6 MB
So your compressed image is 1717540 bytes or 1.64 MB...
## Flattened Device Tree blob at 00400000 Booting using the fdt blob at 0x400000 of_flat_tree at 0x00400000 size 0x00002b7a Uncompressing Kernel Image ...
And your device tree is at 4 MB. If compresses better than some 40% than the uncompressed size of the kernel will exceed the 4 MB limit, thus overwriting your device tree blob.
Are you *really* sure that your addresses are OK? What happens when you move the DTB to a much higher address?
The uncompressed size of the kernel is 3646004 bytes. I should have mentioned that. So vmlinux.bin.gz=1717540 and vmlinuz.bin=3646004
Notice that in my new tests (see above) the vmlinux.bin.gz ends up 4 bytes more (1717544 bytes).
If the DTB is loaded at 600000 (6M) there's no difference.
In fact, if I load no DTB nor ramdisk the same problem occurs.
Regards, Norbert.