Hi Marek,
On Tue, Mar 13, 2012 at 3:50 PM, Marek Vasut marex@denx.de wrote:
Dear Wolfgang Denk,
Dear Marek Vasut,
In message 201203130113.19092.marex@denx.de you wrote:
- zi = (struct zimage_header *)images->ep;
- if (zi->zi_magic != LINUX_ARM_ZIMAGE_MAGIC) {
This gave me an idea ... this might be how to check for zImage inside bootm and be done with it. Simply squash those two together.
Hm... but this must not be the only test, then, or you will run the risk of false positives...
Certainly.
Do we have to care about endianess here?
We should make bootz arm-specific until more people (with different arches) step up and verify it works for them.
NAK. Please implement in an architecture independent way right from the beginning.
Can someone tell if the the zImage format differs per-arch or is it the same? Graeme, what is it about that x86 stuff?
Do you really want to know? How long have you got ;)
There are three options: 1 Keep the kernel packaged up in the bzImage 2 Extract the 'header' externally to U-Boot and put it, the corresponding vmlinux (compressed) and an initrd (compressed) in a uImage 3 Extract the 'header' and vmlinux from a bzImage within U-Boot
Option 1 means I have to keep the crappy 16-bit Real Mode BIOS stub in U-Boot which is a PITA. It also means more memory copy operations to get the kernel up and running - I've spoken to Gabe Black who did the coreboot patches for U-Boot and he is fine with us dropping this (his patches added code to bypass it anyway)
Option 2 is messy
Option 3 is nice - If you have enough onboard NAND flash, you can but the bzImage there and decompress it straight to its 'in RAM' resting place. Boot times are brutal!
I may be wrong, but I zImages are generally a header followed by a compressed vmlinux (x86 has a built-in decompression stub). So if the U-Boot zImage code called an arch-specific function that passed in the location of the (b)zImage and reference variables for the:
- Location of the compressed vmlinux - Compression algorith used to compress vmlinux (although U-Boot could figure this out from the first few bytes) - Length of the compressed data - Length of the decompressed data (if known)
And a functions to process the header, command line, initrd etc I think we would have an arch-neutral way forward
Regards,
Graeme