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

[Darwin Rambo <drambo@broadcom.com>]

On 14-06-02 12:26 AM, Albert ARIBAUD wrote:
> Hi Darwin,
>
> On Mon, 26 May 2014 09:11:35 -0700, Darwin Rambo <drambo@broadcom.com>
> wrote:
>
>> Hi Albert,
>>
>> The previous stage bootloader (which I had no control over) wanted it's
>> header to be aligned to a 512 byte MMC block boundary, presumably since
>> this allowed DMA operations without copy/shifting. At the same time, I
>> didn't want to hack a header into start.S because I didn't want to carry
>> another downstream patch. So I investigated if I could shift u-boot's
>> base address as a feature that would allow an aligned header to be used
>> without the start.S patch.
>>
>> I know that a custom header patch to start.S would work, and that a
>> header plus padding will also work. But I found out that you can align
>> the base on certain smaller offsets if you keep the relocation offset at
>> nice boundaries like 0x1000 and if the relocation offset is a multiple
>> of the maximum alignment requirements of the image.
>>
>> The original patch I submitted didn't handle an end condition properly,
>> was ARM64-specific (wasn't tested on other architectures), and because
>> the patch was NAK'd, I didn't bother to submit a v2 patch and consider
>> the idea to be dead. I'm happy to abandon the patch. I hope this helps.
>
> Thanks.
>
> If I understand correctly, your target has a requirement for storing
> the image on a 512-byte boundary. But how does this affect the loading
> of the image into RAM, where the requirement is only that the vectors
> table be 32-bytes aligned? I mean, if you store the image in MMC at
> offset 0x200 (thus satisfying the 512-byte boundary requirement) and
> load it to, say, offset 0x10020 in RAM, how is it a problem for
> your target?
>
> If my example above inadequately represents the issue, then can you
> please provide a similar but adequate example, a failure case scenario,
> so that I can hve a correct understanding of the problem?

Hi Albert,

The constraints I have that I can't change, are that
- the 32 byte header is postprocessed and prepended to the image after 
the build is complete
- the header is at a 512 byte alignment in MMC
- the header and image are copied to SDRAM to an alignment like 
0x88000000. Thus the u-boot image is linked at and starts at 0x88000020.
- the vectors need to be 0x800 aligned for armv8 (.align 11 directive)

So the failure case is that when the relocation happens, it relocates to 
a 0x1000 alignment, say something like 0xffffa000. The relocation offset 
is not a multiple of 0x1000 (0xffffa000 - 0x88000020) and the relocation 
fails. Adjusting the relocation offset to a multiple of 0x1000 (by 
making the relocation address end in 0xNNNNN020) fixes the issues and 
allows u-boot to relocate and run from this address without failing. I 
hope this helps explain it a bit better.

Best regards,
Darwin

>
>> Best regards,
>> Darwin
>
> Amicalement,
>