[U-Boot] armv8 relocation questions

Wolfgang Denk wd at denx.de
Fri May 16 22:28:25 CEST 2014


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 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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"UNIX was not designed to stop you from doing stupid things,  because
that would also stop you from doing clever things."       - Doug Gwyn


More information about the U-Boot mailing list