[U-Boot-Users] RFC: New U-boot image format
Wolfgang Denk
wd at denx.de
Tue Dec 11 23:23:20 CET 2007
In message <475EE3AE.6060102 at ge.com> you wrote:
>
> Q for Jon L: This would require an extension to the dtc to "include" a
> raw file into the blob? I'm presuming that we don't want to take a
> binary (ELF) file, turn it into ASCII bytes, include it into a dts, and
> then use dtc to compile it back into binary.
Correct. We want a binary include feature here :-)
> > - 'component' subnode shall support:
> > - label property
> > - type property
> > - hash properties (crc32, md5, sha1, etc.)
>
> Would hash be two entries (type and value), or would it be just the type
> and use conventions for where the value is stored (i.e. last /n/ bytes
> of the image)? I would vote for (type and value) if this were a democracy.
Me too :-)
> Are image hashes to validate what is stored in the blob (compressed) or
> to validate what is in memory after decompressing? (Ability to support
> both options would be very good IMHO.)
Good point.
So far, we always verify the (compressed) blob - both for security
(don't even load a compromised image) and speed - checking the
compressed image is much faster, obviously.
But your request is perfectly reasonable.
> > os type, cpu architecture properties
> > data load address
> > entry points for executable images
> >
> > Note: the above list is considered *draft* and open to discussion
>
> Which properties are new inventions? Data compression, timestamps, OS
> Type, CPU arch, data load address, and entry point? Not a bad thing,
> just trying to understand how much we are extending.
All of this already exists, but in a static way.
New is: ability to chose checksum method; ability to compine several
blobs into one image in a structured way, so building and booting the
equivalent of a multifile image with any combination of kernel,
ramdisk and dtb blobs can be done in a clean way.
> I presume...
> imls == image list (overlaps with "fdt l /", no?)
> iminfo == image info? What does it do more than imls?
It lists any image the address of which you pass it. "imls"
only does a limited scan, checking sector boundaries in NOR
flash only.
> imxtract == image extract?
> * Does what?
Extract a blob from an image?
> * Somebody buy that man a vowl ;-)
:-)
> > - command syntax (especially 'bootm') will need to be extended to
> > include 'new image' format related uses cases
>
> Should we create a new command rather than trying to create yet another
> bootm extension (YABE), or is that too disruptive? If not, bootfdt?
My preference would be to add it to bootm ... (I've been typing this
for too long now).
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: wd at denx.de
Looks clean and obviously correct to me, but then _everything_ I
write always looks obviously correct to me. - Linus Torvalds in
<Pine.LNX.4.10.10012090054360.791-100000 at penguin.transmeta.com>
More information about the U-Boot
mailing list