From mboxrd@z Thu Jan 1 00:00:00 1970 From: Darwin Rambo Date: Mon, 2 Jun 2014 17:37:25 -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> Message-ID: <538D18C5.206@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-02 12:26 AM, Albert ARIBAUD wrote: > Hi Darwin, > > On Mon, 26 May 2014 09:11:35 -0700, Darwin Rambo > wrote: > >> Hi Albert, >> >> The previous stage bootloader (which I had no control over) wanted it's >> header to be aligned to a 512 byte MMC block boundary, presumably since >> this allowed DMA operations without copy/shifting. At the same time, I >> didn't want to hack a header into start.S because I didn't want to carry >> another downstream patch. So I investigated if I could shift u-boot's >> base address as a feature that would allow an aligned header to be used >> without the start.S patch. >> >> I know that a custom header patch to start.S would work, and that a >> header plus padding will also work. But I found out that you can align >> the base on certain smaller offsets if you keep the relocation offset at >> nice boundaries like 0x1000 and if the relocation offset is a multiple >> of the maximum alignment requirements of the image. >> >> The original patch I submitted didn't handle an end condition properly, >> was ARM64-specific (wasn't tested on other architectures), and because >> the patch was NAK'd, I didn't bother to submit a v2 patch and consider >> the idea to be dead. I'm happy to abandon the patch. I hope this helps. > > Thanks. > > If I understand correctly, your target has a requirement for storing > the image on a 512-byte boundary. But how does this affect the loading > of the image into RAM, where the requirement is only that the vectors > table be 32-bytes aligned? I mean, if you store the image in MMC at > offset 0x200 (thus satisfying the 512-byte boundary requirement) and > load it to, say, offset 0x10020 in RAM, how is it a problem for > your target? > > If my example above inadequately represents the issue, then can you > please provide a similar but adequate example, a failure case scenario, > so that I can hve a correct understanding of the problem? Hi Albert, The constraints I have that I can't change, are that - the 32 byte header is postprocessed and prepended to the image after the build is complete - the header is at a 512 byte alignment in MMC - the header and image are copied to SDRAM to an alignment like 0x88000000. Thus the u-boot image is linked at and starts at 0x88000020. - the vectors need to be 0x800 aligned for armv8 (.align 11 directive) So the failure case is that when the relocation happens, it relocates to a 0x1000 alignment, say something like 0xffffa000. The relocation offset is not a multiple of 0x1000 (0xffffa000 - 0x88000020) and the relocation fails. Adjusting the relocation offset to a multiple of 0x1000 (by making the relocation address end in 0xNNNNN020) fixes the issues and allows u-boot to relocate and run from this address without failing. I hope this helps explain it a bit better. Best regards, Darwin > >> Best regards, >> Darwin > > Amicalement, >