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

[Wolfgang Denk]

Dear Steve,

In message <539746C4.9040004 at 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"