[U-Boot] armv8 relocation questions

[Darwin Rambo]

On 14-05-16 01:28 PM, Wolfgang Denk wrote:
> Dear Darwin,
>
> In message <53763B78.6030801 at broadcom.com> you wrote:
>>
>> 3. Fixed offset case:
>> CONFIG_SYS_TEXT_BASE = 0x88000020
>
> You completely fail to respond to my repeated statement that a
> CONFIG_SYS_TEXT_BASE like this is bogus.
I want to set it this way to avoid carrying a downstream patch in 
start.S if the header is added by a post processing step. I understand 
that I can put a custom header inside start.S but wanted a different 
solution that keeps the code with less patches.
>
> I guess i give up on this.
I'm sorry we couldn't converge on this.
>
>> Any section in the image that requires a particular alignment must have
>> that alignment respected after relocation. You cannot relocate to an
>> arbitrary address if it breaks the maximum image alignment requirement
>> after relocation.
>
> Who was it who asked why we had such unreasonable strict alignment
> requirements for the relocation address?
The relocation address isn't unreasonably strict. I am happy with the 
0x1000 alignment. What was breaking was the relocation offset which 
needs to have an alignment equal to or greater than the section 
alignments inside the image so that the symbols get relocated correctly.
>
>> But if for some reason, the hardware ever required a 0x2000 (.align 13)
>> alignment, then the generic code's 0x1000 (.align 12) relocation
>> alignment would not work because the alignment after relocation would
>> not respect the .align 13 directive. We just haven't run into this issue
>
> Is this a theoretical or a practical question?  Where exactly do you
> have such a use case?
This is a theoretical statement, just to try to demonstrate that the 4K 
page alignment is itself subject to future breakage if new hardware has 
alignment requirements that are greater than 4K. For example, if some 
new architecture had to have vectors on a 0x2000 alignment, and we put 
them on a 0x1000 alignment after relocation, the vector table would be 
corrupted.
>
>> yet and may never do so, but it is important to understand the
>> limitations of relocation relative to image alignment requirements. The
>> current hardcoded 4096 (0x1000) image relocation alignment just happens
>> to work and looks nice, that's all, but not by consideration of image
>> alignment.
>
> Ummm... experience from 15 years of PPCBoot / U-Boot history don't
> count here, I guess?
>
>> And if any text base alignment is less than the image's maximum
>> alignment requirement, the load will fail, and then we likely scratch
>> our heads and set the CONFIG_SYS_TEXT_BASE alignment higher until it works.
>
> CONFIG_SYS_TEXT_BASE should always be reasonable aligned.  There is no
> good reason to add arbitrary small offsets like you do.  I've
> explained to you a feww times before that you should include your
> header into the text segment, and the problem would be just gone.
I agree that is a solution, but I didn't want to carry a downstream 
patch when the issue with relocation and alignment is understood and 
fixable. I thought it might be an interesting discussion, I guess we 
certainly got that. :)  Thanks again.

Best regards,
Darwin
>
>> But since most people just use higher alignments naturally, this issues
>> remain mostly hidden I think.
>
> Not hidden, they don't exist.  Non-random sig this time.
>
> Best regards,
>
> Wolfgang Denk
>