On 14-05-16 01:28 PM, Wolfgang Denk wrote:
Dear Darwin,
In message <53763b78.6030...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
