From: Steve Rae <srae@broadcom.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] arm: Allow u-boot to run from offset base address
Date: Tue, 10 Jun 2014 16:15:37 -0700 [thread overview]
Message-ID: <53979199.5010100@broadcom.com> (raw)
In-Reply-To: <20140610203500.0D37038131B@gemini.denx.de>
On 14-06-10 01:35 PM, Wolfgang Denk wrote:
> Dear Steve,
>
> In message <53975EC2.1080209@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
>
next prev parent reply other threads:[~2014-06-10 23:15 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-14 22:05 [U-Boot] [PATCH] arm: Allow u-boot to run from offset base address Darwin Rambo
2014-05-14 22:41 ` Jeroen Hofstee
2014-05-15 14:21 ` Darwin Rambo
2014-05-15 15:21 ` Wolfgang Denk
2014-05-15 16:07 ` Darwin Rambo
2014-05-15 19:19 ` Wolfgang Denk
2014-05-26 9:50 ` Albert ARIBAUD
2014-05-26 16:11 ` Darwin Rambo
2014-06-02 7:26 ` Albert ARIBAUD
2014-06-03 0:37 ` Darwin Rambo
2014-06-09 10:23 ` Albert ARIBAUD
2014-06-09 20:45 ` Steve Rae
2014-06-09 20:56 ` Jeroen Hofstee
2014-06-10 5:16 ` Albert ARIBAUD
2014-06-10 17:56 ` Steve Rae
2014-06-10 18:13 ` Wolfgang Denk
2014-06-10 19:38 ` Steve Rae
2014-06-10 20:35 ` Wolfgang Denk
2014-06-10 23:15 ` Steve Rae [this message]
2014-06-11 4:49 ` Wolfgang Denk
2014-06-11 6:45 ` Albert ARIBAUD
2014-06-11 18:56 ` Steve Rae
2014-06-11 21:16 ` Wolfgang Denk
2014-06-25 12:52 ` Albert ARIBAUD
2014-06-10 21:20 ` Albert ARIBAUD
2014-06-11 0:14 ` Steve Rae
2014-06-11 5:02 ` Wolfgang Denk
2014-06-11 4:38 ` Wolfgang Denk
2014-05-15 4:26 ` Wolfgang Denk
2014-05-15 14:16 ` Darwin Rambo
2014-05-15 15:16 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53979199.5010100@broadcom.com \
--to=srae@broadcom.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox