Dear Darwin,
In message 53763B78.6030801@broadcom.com you wrote:
- 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 guess i give up 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?
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?
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.
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