Hi Marek,
On Tue, Mar 13, 2012 at 3:50 PM, Marek Vasut <ma...@denx.de> wrote:
> Dear Wolfgang Denk,
>
>> Dear Marek Vasut,
>>
>> In message <201203130113.19092.ma...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
