From mboxrd@z Thu Jan 1 00:00:00 1970 From: Edgar E. Iglesias Date: Wed, 2 Sep 2020 16:53:19 +0200 Subject: [PATCH] arm64: Add support for bigger u-boot when CONFIG_POSITION_INDEPENDENT=y In-Reply-To: <67147ba5-4bcc-2f2d-d979-17d4798198e0@arm.com> References: <8438394ae435af2b900b965622969dce96701b88.1599045314.git.michal.simek@xilinx.com> <67147ba5-4bcc-2f2d-d979-17d4798198e0@arm.com> Message-ID: <20200902145319.GX14249@toto> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, Sep 02, 2020 at 03:43:08PM +0100, Andr? Przywara wrote: > On 02/09/2020 12:15, Michal Simek wrote: > > Hi, Hi Andre, > > > From: "Edgar E. Iglesias" > > > > When U-Boot binary exceeds 1MB with CONFIG_POSITION_INDEPENDENT=y > > compilation error is shown: > > /mnt/disk/u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation > > truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end' > > defined in .bss_start section in u-boot. > > > > It is caused by adr instruction which permits the calculation of any byte > > address within +- 1MB of the current PC. > > Because U-Boot is bigger then 1MB calculation is failing. > > > > The patch is using adrp/add instructions where adrp shifts a signed, 21-bit > > immediate left by 12 bits (4k page), adds it to the value of the program > > counter with the bottom 12 bits cleared to zero. Then add instruction > > provides the lower 12 bits which is offset within 4k page. > > These two instructions together compose full 32bit offset which should be > > more then enough to cover the whole u-boot size. > > > > Signed-off-by: Edgar E. Iglesias > > Signed-off-by: Michal Simek > > It's a bit scary that you need more than 1MB, but indeed what you do > below is the canonical pattern to get the full range of PC relative > addressing (this is used heavily in Trusted Firmware, for instance). > > The only thing to keep in mind is that this assumes that the load > address of the binary is 4K aligned, so that the low 12 bits of the > symbol stay the same. I wonder if we should enforce this somehow? But > the load address is not controlled by the build process (the whole > purpose of PIE), so that's not doable just in the build system? There shouldn't be any need for 4K alignment. Could you elaborate on why you think there is? Perhaps the commit message is a little confusing. The toolchain will compute the pc-relative offset from this particular location to the symbol and apply the relocations accordingly. Best regards, Edgar > > Shall we at least document this? I guess typical load address are > actually quite well aligned, so it might not be an issue in practice. > > Cheers, > Andre > > > --- > > > > arch/arm/cpu/armv8/start.S | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S > > index 002698b501c3..52cf1230c205 100644 > > --- a/arch/arm/cpu/armv8/start.S > > +++ b/arch/arm/cpu/armv8/start.S > > @@ -67,8 +67,10 @@ pie_fixup: > > adr x0, _start /* x0 <- Runtime value of _start */ > > ldr x1, _TEXT_BASE /* x1 <- Linked value of _start */ > > sub x9, x0, x1 /* x9 <- Run-vs-link offset */ > > - adr x2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */ > > - adr x3, __rel_dyn_end /* x3 <- Runtime &__rel_dyn_end */ > > + adrp x2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */ > > + add x2, x2, #:lo12:__rel_dyn_start > > + adrp x3, __rel_dyn_end /* x3 <- Runtime &__rel_dyn_end */ > > + add x3, x3, #:lo12:__rel_dyn_end > > pie_fix_loop: > > ldp x0, x1, [x2], #16 /* (x0, x1) <- (Link location, fixup) */ > > ldr x4, [x2], #8 /* x4 <- addend */ > > >