From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Rae Date: Tue, 10 Jun 2014 17:14:34 -0700 Subject: [U-Boot] [PATCH] arm: Allow u-boot to run from offset base address In-Reply-To: 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> Message-ID: <53979F6A.90607@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 02:20 PM, Albert ARIBAUD wrote: > Hi Steve, > > On Tue, 10 Jun 2014 12:38:42 -0700, Steve Rae wrote: > >> >> >> On 14-06-10 11:13 AM, Wolfgang Denk wrote: >>> 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 ? >> >> 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... > > That is not a good approach -- and I should know, as there are boards > out there which already insist on having a header (mind you, a simple > 4-byte constant) in start.S, and I am already trying to tackle this > out of start.S. > > Your 32-byte header should not be in start.S, it should be linked in > before start.o in the linker script. Then you would only have one > start.S file and as many headers as you require. > >> 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 .... > > Not necessarily. You'll need to configure your target, that's sure, > because I guess different targets will have different (values in > the bytes of their) headers, but you don't need to have different > start.S files. > >> 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... >> 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. >> Thanks, Steve > > I (believe I) understand the problem, and I am discussing here because I > too want it solved. On the one hand I do agree with Wolfgang here: > >>> No, I do not see a good reason to add such code. > > ... because I don't want to allow a feature that is designed to counter > a problem; but on the other hand I want the problem fixed. So Darwin, > in order to find a satisfactory solution, let me try to recap the > situation and then ask a few questions. > > Recap: > > 1. A typical ARM binary image is linked to a base address, defined by > preprocessor macro (aka U-Boot config option) CONFIG_SYS_TEXT_BASE. OK > > 2. A typical ARM target defines CONFIG_SYS_TEXT_BASE so that the image, > and especially its exception vectors table, is properly aligned upon > loading the image in RAM. Nope, the vectors respect the .align directive independent of the CONFIG_SYS_TEXT_BASE setting. > > 3. When the ARM image relocates itself, it does so to a destination > address which is computed so that the image and its vectors table > are still properly aligned after relocation. Almost: the computed destination address is aligned on a 0x1000 byte boundary, so if the CONFIG_SYS_TEXT_BASE is also a multiple of 0x1000 bytes, then this statement is true. > > 4. Some targets require that the image stored in MMC be prepended with > a 32-byte header (and aligned to a sector-related boundary). OK > > 5. For some targets (if not all) the header is not separate from the > image, i.e., it will also be copied from MMC to RAM. Such headers > must be prepended at the link stage or earlier, so that the > link-time and run-time values of all image symbols are consistent. Yes - copied from MMC to RAM, but not really necessary to do this at "link stage or earlier" (we do it with a post-processing tool to prepend a header onto 'u-boot.bin') > > 6. However, because the header is put at the start of the image before > the vectors table, the image is still properly aligned but th > vectors tabled is not any more, both when the image is loaded from > MMC to RAM, and when it is relocated. Because we set the CONFIG_SYS_TEXT_BASE to 0xXXXX0020, the image is properly aligned, if CONFIG_SYS_TEXT_BASE is 0xXXXX0000, then the "before" image would not be properly aligned.... > > 7. This mis-alignment issue does not only affect the vectors table; it > also affects any location addressed using adrp instructions (if I > did correctly understand Jeroen, Cc:). Agree - it affects all of the "align" directives, in the code and the linker script file, and all instructions which assume alignment.... > > This is my understanding of the issue. If it is correct, then I > believe the following solves the issue without changing anything to > the current code: > > Instead of prepending a 32-byte header to the image, prepend the header > then a block of 2048-32 bytes. This way, the MMC image base address > (the header address) is aligned, and the alignment of any address in > the image itself is preserved. Yes - if the header is an exact multiple of 0x1000 (4096), it will work correctly without any code modifications... (not certain about 2048...) > > If for some reason it is impossible to pad the header (such as, the > header is actually prepended by a closed-source tool which takes the > 'raw' image in and spits the 'MMC image' out), then the raw image > should be prepended with 2048-32 bytes beforehand, so that the 32 > header bytes make up a whole 2048-bytes block, and the image remains > aligned. > > However, I guess that you, Darwin and Steve, probably have thought of > this already and dismissed it for a reason. If so, please explain > what this reason is. We wanted to implement a forward looking solution that worked for any size of prepended header, and which removed the constraint for the CONFIG_SYS_TEXT_BASE to be an exact multiple of 0x1000 (4096). However, since this solution does not look like it will succeed, in a parallel thread, we are pursuing an alternate proposal to conditionally reserve space for the header in u-boot.bin (which is "link stage or earlier"!!!), which would then be modified by a post-processing tool. So please review that proposal. Thanks, Steve > > Amicalement, >