On 14-05-15 08:21 AM, Wolfgang Denk wrote:
Dear Darwin,
In message 5374CD55.3010703@broadcom.com you wrote:
Do you really want to check a define at runtime? Placement is typically at the end of RAM and allocation goes down, not up as in this patch. Aren't you overlapping memory here?
Yes, I wanted the runtime check since the adjustment to the relocation address is also done at runtime.
This makes no sense to me. CONFIG_SYS_TEXT_BASE is a compile time constant. So the result of all this is always known at compile time, too. I feel you misunderstand that CONFIG_SYS_TEXT_BASE is just the start address of the text segment. If you want to offset this by a specific amount, you can just define this as needed.
May I respectfully ask that you please bear with me a just a bit longer so I can try to explain things better?
CONFIG_SYS_TEXT_BASE is also used by the relocation calculations at runtime to determine the relocation offset, which is also used for the symbol fixup logic. It is known at compile time, but is used at runtime by the stock u-boot code to determine the relocation offset. I am doing nothing more than existing code in this regard.
If I set it to 0x88000020, then the code crashes because the symbol fixup depends on the relocation offset which is now wrong. The reason is that the relocation offset calculated in the code doesn't account for this offset. If we adjust the relocation address, then the relocation offset is now correct and the symbol fixups work perfectly.
Here's an example: CONFIG_SYS_TEXT_BASE = 0x88000020 relocated address = 0xfffa8000 (This 4K alignment assumption breaks the relocation) relocation offset = 0x77fa7fe0 (This is now wrong and the relocation breaks)
My patch does the following: CONFIG_SYS_TEXT_BASE = 0x88000020 relocated address = 0xfffa8020 relocation offset = 0x77fa8000 (symbol fixups now work)
So this patch just gives us a way to run u-boot at text sections with smaller alignments. In the past I never really understood why CONFIG_SYS_TEXT_BASE had to be on specific alignments like XXXXX000 for our architecture and the symbol fixup issue helps to explain this.
I know this is not the normal use case but it does fix the crash in the symbol relocation with arm64 and allows u-boot to be more flexible in it's text alignment requirements.
Thanks.
Best regards, Darwin
There is no overlap here. The reason is that the original masking operation to mask to a 4K boundary removed the small offset and backed up too far. So adding the lost offset is guaranteed to not overlap, and furthermore, correct the relocation offset so that arm64 images can run at smaller alignments than we normally use. This might even be a generic fix but can't be tested easily by me.
Argh... This is black magic depending on specific properties of your process (which you don;t really explain). Sorry, but this is a full NAK for code that is build on sand like this.
Best regards,
Wolfgang Denk