*** PROBABLY SPAM *** [PATCH 06/12] reimplement uImage code

[Jean-Christophe PLAGNIOL-VILLARD]

On 16:27 Thu 15 Dec     , Sascha Hauer wrote:
> On Thu, Dec 15, 2011 at 02:33:17PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 11:30 Thu 15 Dec     , Sascha Hauer wrote:
> > > Provide a new API for accessing uImages which makes it easy
> > > for commands to open images, verify them, load to (free) sdram
> > > regions and show information about uImages.
> > > 
> > > - We now do not load the image to malloced space anymore.
> > > - The data in the header is now stored in cpu native endianess
> > >   after uimage_open which makes it easy to access the header data.
> > > - uImage can be loaded to dynamically allocated sdram regions.
> > > 
> > > Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
> > I was more think of a filesystem
> > 
> > so we can execute an embedded script
> 
> You can still do with "uimage -e script myimage; ./script"
> 
> I thought about the filesystem approach and I came to the conclusion
> that this is not really what we want for booting. While it definitely
> has charm when we can mount a uImage and just work on the included file
> we would loose the meta data in this case. We could create the metadata
> in form of files, maybe like this:
> 
> # mount uImage uimage /mnt
> # ls /mnt
> /mnt/image0
> /mnt/image1
> /mnt/entrypoint
> /mnt/loadaddress
> 
> But these files would be hard to work on and also would not have
> the 'uImage is just another image handled by bootm' facility.
I get a first patch that do this but not finished

no my idea why a new falicity as all the image could be mouted in my mind

and maybe use an ioctl to get the metadata

and we could map it

Best Regrds,
J.