From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Rae Date: Tue, 10 Jun 2014 16:15:37 -0700 Subject: [U-Boot] [PATCH] arm: Allow u-boot to run from offset base address In-Reply-To: <20140610203500.0D37038131B@gemini.denx.de> References: <1400105145-6628-1-git-send-email-drambo@broadcom.com> <1400107265.16796.8.camel@yellow> <5374CD55.3010703@broadcom.com> <20140515152119.9939F38047D@gemini.denx.de> <5374E64B.1060104@broadcom.com> <20140515191957.74A853804B6@gemini.denx.de> <538367B7.5090108@broadcom.com> <538D18C5.206@broadcom.com> <53961CFE.4090106@broadcom.com> <539746C4.9040004@broadcom.com> <20140610181341.7E10138131B@gemini.denx.de> <53975EC2.1080209@broadcom.com> <20140610203500.0D37038131B@gemini.denx.de> Message-ID: <53979199.5010100@broadcom.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.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 >