[U-Boot-Users] RFC:new multi image format

[U-Boot-Users] RFC:new multi image format

[Kumar Gala]

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 wanted to see what information people felt was important to keep  
track of for the 'sub images'.

struct sub_image_header {
	uint32_t	ih_type;	/* sub image type */
	uint32_t	ih_size;	/* sub image size *
	uint32_t	ih_comp;	/* compress type */
	uint64_t	ih_load;	/* Data  Load  Address */
	uint64_t	ih_ep;		/* entry point */
	uint8_t         ih_name[IH_NMLEN];
}

Are other fields useful or should we just duplicate the image_header  
completely?

- k

[U-Boot-Users] RFC:new multi image format

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Swap read error.  You lose your mind.

[U-Boot-Users] RFC:new multi image format

[Tolunay Orkun]

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

[U-Boot-Users] RFC:new multi image format

[Kumar Gala]

On Mar 13, 2007, at 3:25 AM, 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
>> 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 ...

I haven't looked at ATAGs but from what I hear its similar to  
bi_records.  Are there any tools we could leverage code from with ATAGs?

I think something like that would be the most flexible w/o too much  
complexity.

- k

[U-Boot-Users] RFC:new multi image format

[Tolunay Orkun]

Kumar Gala 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 wanted to see what information people felt was important to keep  
> track of for the 'sub images'.
>
> struct sub_image_header {
> 	uint32_t	ih_type;	/* sub image type */
> 	uint32_t	ih_size;	/* sub image size *
> 	uint32_t	ih_comp;	/* compress type */
> 	uint64_t	ih_load;	/* Data  Load  Address */
> 	uint64_t	ih_ep;		/* entry point */
> 	uint8_t         ih_name[IH_NMLEN];
> }
>
> Are other fields useful or should we just duplicate the image_header  
> completely?
>
> -

I agree something like (per image header) is needed. I would take this 
an opportunity to add a uint8_t[] field to add version information that 
could be filled by an build script if desired. In my previous work, we 
needed a version field to display/verify before allowing the update in 
Linux based software update (and making sure the image for board A was 
not being attempted for board B). We abused the name/description field 
for this purpose which was not the ideal solution.

I think we can incorporate this additional header so that if the new 
image is fed to an old u-boot it would still be acceptable. Perhaps we 
can group sub-image headers after the offset table but before the actual 
images.

Best regards,
Tolunay

[U-Boot-Users] RFC:new multi image format

[Daniel Hobi]

On 13.03.2007 03:59, Kumar Gala wrote:
> The current multi image format doesn't really provide any information
> about what the images contained inside the multi image are.
> 
> [...]
> 
> Are other fields useful or should we just duplicate the image_header
> completely?

If the fields of the current image header suffice to describe the images 
contained in a multi-image, you can just wrap each sub-image with a 
image header. That is, first create a number of (single-image) uImages, 
then create a multi-image out of these uImages.

Best Regards,
Daniel

[U-Boot-Users] RFC:new multi image format

[Wolfgang Denk]

In message <45FEB74E.5020106@gmx.net> you wrote:
>
> > Are other fields useful or should we just duplicate the image_header
> > completely?
> 
> If the fields of the current image header suffice to describe the images 
> contained in a multi-image, you can just wrap each sub-image with a 

They don;t. As mentioned before, I have a  customer  requirement  for
MD5  /  SHA1 checksums for the images, and I don't want to misuse (or
lose) other existing fields like the name string for this.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is a human characteristic to love little  animals,  especially  if
they're attractive in some way.
	-- McCoy, "The Trouble with Tribbles", stardate 4525.6

[U-Boot-Users] RFC:new multi image format

[John Rigby]

How about a cpio archive?  While the cpio command is a mind
boggler for me the file format itself is very simple, which
is why it was chosen for initramfs images.  The content files
could have self documenting names and the MD5 or SHA1 sums
could go in .md5 and .sha1 files.

On 3/19/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <45FEB74E.5020106@gmx.net> you wrote:
> >
> > > Are other fields useful or should we just duplicate the image_header
> > > completely?
> >
> > If the fields of the current image header suffice to describe the images
> > contained in a multi-image, you can just wrap each sub-image with a
>
> They don;t. As mentioned before, I have a  customer  requirement  for
> MD5  /  SHA1 checksums for the images, and I don't want to misuse (or
> lose) other existing fields like the name string for this.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
> Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> It is a human characteristic to love little  animals,  especially  if
> they're attractive in some way.
>         -- McCoy, "The Trouble with Tribbles", stardate 4525.6
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>

[U-Boot-Users] RFC:new multi image format

[Wolfgang Denk]

In message <4b73d43f0703191602r53474db4vf366502110f9c306@mail.gmail.com> you wrote:
> How about a cpio archive?  While the cpio command is a mind
> boggler for me the file format itself is very simple, which
> is why it was chosen for initramfs images.  The content files
> could have self documenting names and the MD5 or SHA1 sums
> could go in .md5 and .sha1 files.

Argh... no, please, not. Each entry requires a 76 byte  header,  with
90% of it completely useless information for us.

I don't think that matches our problem.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I know engineers. They love to change things.             - Dr. McCoy