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

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

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?

> Best regards,
> Darwin

Amicalement,
-- 
Albert.