i.MX consolidation patches

[s.hauer@pengutronix.de (Sascha Hauer)]

On Thu, Jun 02, 2011 at 05:46:59PM +0200, Wolfgang Denk wrote:
> Dear Matt,
> 
> In message <BANLkTi=HqEBRzyU4_HXnNHTeOPL9vPW8PA@mail.gmail.com> you wrote:
> >
> > In this case, just a load address in the uImage header of 0 (or some
> > other totally-impossible value like 0xffffffff
> > in case 0 is perfectly valid somewhere) and then just jump to the
> > entry point by deriving the value from the
> > header size - based on the fact that ARM images are PIC and the Linux
> > kernel always puts the entry point
> > at 0 offset - to the address of the uImage header + size of the uImage
> > header (which U-Boot knows already
> > from parsing the header).
> 
> I'm not a friend of using magic values that are "totally-impossible".
> This is confusing, and here it is not needed.

I find using a field labelled 'entry point' and 'load address' as
absolute addresses or offsets into sdram depending on some flag
also quite confusing. btw how do you want to decide whether the
fields are offsets or absolute addresses? I see no flags field in
the uImage format.

> 
> If we could agree to interpret load address and entry point as
> offsets, the only remaining problem is to find out if we can use a
> common offset.

The zImages encapsulated in uImages are relocatable. So pick any offset
between 32k and 128MB into sdram like Russell explained. Higher values
are not desirable as this would break boards with less sdram.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |