public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] RFC: New U-boot image format
Date: Tue, 11 Dec 2007 23:23:20 +0100	[thread overview]
Message-ID: <20071211222320.B7DB1246C2@gemini.denx.de> (raw)
In-Reply-To: Your message of "Tue, 11 Dec 2007 14:23:26 EST." <475EE3AE.6060102@ge.com>

In message <475EE3AE.6060102@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@penguin.transmeta.com>

  reply	other threads:[~2007-12-11 22:23 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-11 16:18 [U-Boot-Users] RFC: New U-boot image format Marian Balakowicz
2007-12-11 16:32 ` [U-Boot-Users] RFC: New U-boot image format - open issues Marian Balakowicz
2007-12-11 19:23 ` [U-Boot-Users] RFC: New U-boot image format Jerry Van Baren
2007-12-11 22:23   ` Wolfgang Denk [this message]
2007-12-12 12:38     ` Jerry Van Baren
2007-12-13 22:59       ` Marian Balakowicz
2007-12-13 22:41   ` Marian Balakowicz
2007-12-14  6:17     ` Wolfgang Denk
2007-12-14 21:44     ` T Ziomek
2007-12-19 14:26     ` Marian Balakowicz
2007-12-20  0:50       ` David Gibson
2007-12-20 16:41         ` Scott Wood
2007-12-20 22:25           ` Marian Balakowicz
2007-12-20 22:39             ` Scott Wood
2007-12-21  0:17               ` David Gibson
2007-12-18 15:17 ` Timur Tabi
2007-12-18 15:33   ` Jerry Van Baren
2007-12-18 15:36     ` Timur Tabi
2007-12-18 16:12   ` Wolfgang Denk
2007-12-18 16:17     ` Timur Tabi
2007-12-18 19:42       ` Wolfgang Denk
2007-12-18 19:47         ` Timur Tabi
2007-12-18 20:11           ` Wolfgang Denk
2007-12-18 20:18             ` Timur Tabi
2007-12-19 14:07   ` Marian Balakowicz
2007-12-20 19:42     ` Wolfgang Denk
2007-12-21 15:04       ` Marian Balakowicz
2007-12-21 15:17         ` Wolfgang Denk
2007-12-21 15:39           ` Marian Balakowicz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071211222320.B7DB1246C2@gemini.denx.de \
    --to=wd@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox