From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tolunay Orkun <listmember@orkun.us>
Date: Thu, 15 Mar 2007 02:17:41 -0500
Subject: [U-Boot-Users] RFC:new multi image format
In-Reply-To: <20070313082500.A2EA73525D8@atlas.denx.de>
References: <20070313082500.A2EA73525D8@atlas.denx.de>
Message-ID: <45F8F315.4000902@orkun.us>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Wolfgang Denk wrote:
> Dear Kumar,
>
> in message <D87DF9BC-1392-42F1-8642-D3D9D80D646E@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  
>> completely?
>>     
>
> Yes. Please see my posting 'RFC: extended image formats' of
> 27 Feb 2007:
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/26641
>
> 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.

http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html

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.

Best regards,
Tolunay