[PATCH 0/7] Re-organize linker layouts

[Nicolas Pitre]

On Fri, 8 Jul 2011, Stephen Boyd wrote:

> On 7/8/2011 9:03 AM, Russell King - ARM Linux wrote:
> > On Fri, Jul 08, 2011 at 09:46:42AM -0400, Nicolas Pitre wrote:
> >> On Fri, 8 Jul 2011, Russell King - ARM Linux wrote:
> >>
> >>> There's also platforms where the zImage is loaded at some predetermined
> >>> offset into RAM to give the decompressor room to directly place the
> >>> kernel in its final location too, which will be buggered by
> >>> AUTO_ZRELADDR.
> >>
> >> How so?  Loading that zImage at the same predetermined offset will still 
> >> have the same desired effect.  As long as the offset is within 128MB of 
> >> the start of RAM.
> >
> > You just said it...
> >
> > Given that it's 128MB, Stephen shouldn't have a problem with loading the
> > zImage at 0xN0208000, but he said it doesn't work.  I think there's some
> > work to be done there to figure out if Stephen really has a problem, and
> > what that problem is.
> 
> My problem is due to how the zreladdr is calculated. Our ram starts at
> 0xN0200000 and loading the zImage at 0xN0208000 works fine, but then
> when zreladdr is calculated it essentially aligns PC to 128MB and then
> my kernel is loaded at 0xN0008000. I've lost the 2. It looks like other
> machines are in a similar situation (or their zImage is loaded somewhere
> beyond 128MB and it never works).

No, it works.  It is just that everyone else has their RAM always 
aligned to something much greater than 2 MB.  In fact, the 128 MB value 
was selected because it was the smallest aligment of RAM placement found 
amongst all the machines in the tree at the time.

> Why can't this work via atags (or DT for that matter)? atags have always
> said where ram starts and we should be able to write some code that
> parses the atags/DT and figures out the final resting place of the
> decompressed image.

Possibly.  But that would be an MSM special case.


Nicolas