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
next prev parent 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