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