[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