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 discussionWhich 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