Dear Scott Wood,
In message <20100909173735.503c4...@schlenkerla.am.freescale.net> you wrote:
>
> It actually can load an ELF file, but it doesn't currently support
> passing a device tree to it (only argc/argv text arguments, or some
> vxworks stuff).
I see no problems to extend U-Boot such that we support booting Linux
kernel images in form of ELF files. Ideally these should be wrapped
into FIT images to allow for easy combination of kernel and FDT into a
single file (useful for netboot).
> > I've never understood the reasoning for that uImage wrapper
> > thingy. Definitely causes more problems than it solves in my experience.
>
> Wolfgang was just defending it on the U-Boot list the past couple
> days... seems like the main thing in its favor is the CRC, especially
> as a final check before reflashing an image.
The additional file header serves a number of purposes; even if they
seem of little use to a developer they are really helpful in
production and maintenance/repair.
Assume you were to find out why a system (returned from a customer)
does not boot any more. Being able to identify the kernel image in
flash, with information about version (name string), image build time
and size is really, really helpful then. Of course it's also helpful
to be able to check if the image is OK or for example has been
(partially) overwritten.
The checksum protection is indeed a VERY useful thing.
If we hade similar checksum protection on the device tree we would
have been able to recognize the memory corruption that triggered this
thread MUCH easier.
Acutally this is my biggest critique on the FDT blob: that we cannot
detect corruptions like this.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It is a good thing for an uneducated man to read books of quotations.
- Sir Winston Churchill _My Early Life_ ch. 9
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
