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

[Steve Rae]

On 14-06-10 01:35 PM, Wolfgang Denk wrote:
> Dear Steve,
>
> In message <53975EC2.1080209 at broadcom.com> you wrote:
>>
>>> 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 ?
>>
>> Wolfgang et al.
>>
>> I agree that they do not need to be the same...
>> So our issue is that basically "for every ARMv7 board in the company",
>> we are currently maintaining our own modified/customized version of
>> "arch/arm/cpu/armv7/start.S" in order to add the appropriate 32 byte
>> header...
>
> There should be more clever ways to implement this.  If nothing else
> comes to mind, an #ifdef in "arch/arm/cpu/armv7/start.S" should be
> sufficient to condistionally insert / adjust any offset that might be
> needed for a specific board.
>
>> And we could choose to do it using other methods, but they all require
>> us to maintain a customized version of linker scripts, or some other
>> code, or ....
>
> ... or a CONFIG setting in your board config file resp. your board's
> defconfig.
>
>> The request here is that with the addition of some relatively
>> straightforward (upstreamed) code, then this can be handled
>> automatically by a post-processing step and we would be able to use a
>> pristine version of the upstreamed code...
>
> I'm sorry, but I disagree especially on the "straightforward" part.
> Also, I see no reason to make the existing code unnecessarily complex,
> and add more disadvantages (like increased meory footprint etc.) when
> the same purpose can be implemented without adding any special code at
> all.
>
>> Our desire is to get this into the beginnings of the "ARMv8" boards, so
>> that we can avoid the maintenance issues we have with the current ARMv7
>> boards.
>>
>> We appreciate your consideration of this request.
>
> These are two different things: implementing a clean and easy way to
> support a necessary feature is one thing; to do it in the suggested
> way by adding code where none is needed is another thing.
>
> I'm all for adding support for any features that are useful, even if
> only for a single user, as long as they don't hurt other users.  All
> I'm asking is to chose another way to implement this feature.  So far,
> I did not see any arguments that my alternative proposals would cause
> any problems to you?
>

OK - I think that one of the alternate proposals would be to 
conditionally reserve a "32 byte block" prior to the _start symbol (in 
"arch/arm/cpu/armv8/start.S") which would then be filled in by a 
post-processing step... This could be implemented by:

diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index 4b11aa4..8fd72f1 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -18,6 +18,10 @@
   *
 
*************************************************************************/

+#ifdef CONFIG_CUSTOM_HEADER_RESERVED_BYTES
+	.skip CONFIG_CUSTOM_HEADER_RESERVED_BYTES
+#endif
+
  .globl	_start
  _start:
  	b	reset

And then in our board config file:
#define CONFIG_CUSTOM_HEADER_RESERVED_BYTES 32

And we could implement a similar algorithm in the armv7/start.S as you 
stated above.

Are we understanding your proposals properly? Would this be an 
acceptable solution?
Thanks, Steve

> Best regards,
>
> Wolfgang Denk
>