On 14-05-14 09:26 PM, Wolfgang Denk wrote:
Dear Darwin Rambo,
In message 1400105145-6628-1-git-send-email-drambo@broadcom.com you wrote:
If an earlier loader stage requires an image header and a specific offset, then u-boot's base address (CONFIG_SYS_TEXT_BASE) may be advanced beyond an aligned address. In this case the relocation
Sorry, I cannot parse that. CONFIG_SYS_TEXT_BASE is a compile time constant, it cannot be "advanced" by a loader. Do you mean that some loader loads U-Boot to an incorrect address? Well, in this case the loader should be fixed, or?
Thank you for your comments.
I mean that the loader loads u-boot to it's correct address, which is offset by a small amount because of a previous header requiring alignment. Here's an example. u-boot is compiled to run at 0x88000020 because we want to put a small header in front of the image, which starts at 0x88000000 and needs to be aligned for its own reasons. Now for arm64, I believe that u-boot cannot normally be positioned at any alignment less than 0x800 hex. So u-boot would normally run at addresses like 0x88000000, 0x88000800, 0x88001000, etc. And in these cases the relocation works fine. But if we want to position u-boot at a smaller offset than 0x800, the symbol relocation breaks for arm64. It turns out that there is a trivial fix so that u-boot can run at smaller offset addresses, which I have provided here, is tested, and solves our problem nicely, but only for arm64 right now.
This change is done under CONFIG_ARM64 conditional compilation because it has only been tested there and may not be appropriate for other architectures.
In any case, any such changes (if there should be agreement that they are actually useful) should be done in an architecture-neutral way. Implementing it for one specific architecture only is wrong.
Yes, I agree, but I am not sure if this is a arm64-only problem or not. Armv7 doesn't show this problem, and I can't test other architectures for their alignment issues. So I thought that I would at least show the fix for arm64 so we can decide if and how to proceed. Any suggestions you can provide on how to proceed would be appreciated. And if the fix is not suitable for upstreaming, then we should know it.
Is there a way to have architecture specific hooks like this called from the generic common/board_f.c? The fix is also in arch/arm/lib/board.c but it sounds like that file might be disappearing.
Also there might be a generic fix possible that works for all architectures (by removing the ifdef CONFIG_ARM64), but I don't have the resources to test them. Maybe it would be best to decide if we want to support this feature or not first. Thanks!
Regards, Darwin
Best regards,
Wolfgang Denk