[U-Boot-Users] RFC:new multi image format
listmember at orkun.us
Thu Mar 15 08:17:41 CET 2007
Wolfgang Denk wrote:
> Dear Kumar,
> in message <D87DF9BC-1392-42F1-8642-D3D9D80D646E at kernel.crashing.org> you wrote:
>> The current multi image format doesn't really provide any information
>> about what the images contained inside the multi image are.
>> I'm suggesting we add a new ih_type, IH_TYPE_MULTI_V2 in which we
>> have an expanded header for each 'sub image' to describe more details
>> about it.
> I'd like to take a more generic approach, as we see other areas where
> additional header information is needed.
>> Are other fields useful or should we just duplicate the image_header
> Yes. Please see my posting 'RFC: extended image formats' of
> 27 Feb 2007:
> I think both topics are similar enough. Like in your suggestion, my
> current thinking is about using a new image type which alows us to
> include a second image header.
> Then hesitation starts - shall we really use a simple binary data
> structure again which will sooner or later crerate all the hassles
> the bd_info structure gave us in the Linux kernel, or is it enough to
> add a version field and allow for growing this structure by appending
> new fields at the end, or should we go for something like ATAGs or
> bi_records or ...
> Best regards,
> Wolfgang Denk
If we are going to do some more drastic changes perhaps we can take the
approach of Java .jar files. These are basically ZIP compressed files
but manifest and signatures are included as files.
In other words, one of the images in the archive could hold additional
information regarding the other images. We could use Java JAR files but
it does not have to be complex.
Instead of binary fields we could use key/value pairs in text. An
extension would be XML but it would require an XML parser (expat for
example) to be incorporated to U-Boot making the size grow unnecessarily.
More information about the U-Boot