[U-Boot] [PATCH] arm: Allow u-boot to run from offset base address

[Darwin Rambo <drambo@broadcom.com>]

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
>