public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tolunay Orkun <listmember@orkun.us>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] RFC:new multi image format
Date: Thu, 15 Mar 2007 02:17:41 -0500	[thread overview]
Message-ID: <45F8F315.4000902@orkun.us> (raw)
In-Reply-To: <20070313082500.A2EA73525D8@atlas.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

  reply	other threads:[~2007-03-15  7:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-13  2:59 [U-Boot-Users] RFC:new multi image format Kumar Gala
2007-03-13  8:25 ` Wolfgang Denk
2007-03-15  7:17   ` Tolunay Orkun [this message]
2007-03-22  1:38   ` Kumar Gala
2007-03-15  7:07 ` Tolunay Orkun
2007-03-19 16:16 ` Daniel Hobi
2007-03-19 18:43   ` Wolfgang Denk
2007-03-19 23:02     ` John Rigby
2007-03-19 23:39       ` Wolfgang Denk

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=45F8F315.4000902@orkun.us \
    --to=listmember@orkun.us \
    --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