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

Wolfgang Denk
2014-06-10T18:13:41Z

Dear Steve,

In message <539746C4.9040004@broadcom.com> you wrote:
>
> There could be "many" reasons why the CONFIG_SYS_TEXT_BASE is not
> aligned on a 0x1000 byte boundary (Darwin has attempted to document his
> particular use-case...)

We should be more precise here and ask for any _good_ reasons.

I can think of many good reasons to keep the text base aligned. As
for the reasons to use an unaligned address that were brought up here,
I still think that it would have been better to use an aligned taxe
base and do the rest with a customized linker script.

> But we think that the solution to support this is relatively
> straightforward:
> (1) after determining the "relocation address" (which will be on a
> 0x1000 byte boundary),
> (2) add "CONFIG_SYS_TEXT_BASE % 4096" to that "relocation address"
> (which effectively makes the "relocation offset" a multiple of 0x1000
> too...)
> So, in the scenario #1, (CONFIG_SYS_TEXT_BASE % 4096) = 0, so this
> algorithm changes nothing.
> And in scenario #2, (CONFIG_SYS_TEXT_BASE % 4096) = 0x20, therefore, we
> would now get the following:
> the relocation offset is: 0x77f9b000
> therefore, after relocation:
> _start symbol is at 0xfff9b020 (0x88000020+0x77f9b000)
> vectors symbol is at 0xfff9b800 (0x88000800+0x77f9b000)

I still cannot understand why _start and CONFIG_SYS_TEXT_BASE would
have to be the same. There is no such requirement. What exactly
prevents you from assigning _start a location at offset 0x20 to the
start of the text segment, i. e. CONFIG_SYS_TEXT_BASE ?

Then everything should be still the same for you, and no voodoo coding
would be needed.

> (3) HOWEVER, shifting the address UP may cause the end of the relocated
> code to run past the end of the available memory... So we could:

This problem is void if you just use a poperly aligned text base in
combination with a prope start.S resp. linker script to make sure
_start is where you want it.

> I trust that everyone will find this explanation acceptable...

No, I do not see a good reason to add such code.

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
Let the programmers be many and the managers few -- then all will be
productive. -- Geoffrey James, "The Tao of Programming"