Re-organize linker layouts
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 7 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 7 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/7] Re-organize linker layouts
Quoted 12 lines · Russell King - ARM Linux
Quoted 10 lines · Nicolas Pitre
Quoted 4 lines · Russell King - ARM Linux
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.
Quoted 6 lines
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).
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.
Signature · 2 lines
Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.