On 03/09/2020 14:35, Michal Simek wrote: > > > On 02. 09. 20 18:34, Stephen Warren wrote: >> On 9/2/20 5:15 AM, Michal Simek wrote: >>> From: "Edgar E. Iglesias" <edgar.igles...@xilinx.com> >>> >>> 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. >> >>> diff --git 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 */ >> >> There are likely a bunch of other places in the code that need updating >> too; take a look at commit 49e93875a62f "arm64: support running at addr >> other than linked to" (which introduced the code above) to find other >> places with similar instruction sequences that almost certainly need >> updating. >> > > I didn't hit any issue to have a need to update them. Definitely worth > to check that locations too.
So I thought the same, so I checked at least this file. And while there are other "adr" instructions, they only go to nearby labels, so don't need to be pumped up. But I will try to grep for more cases as well. Cheers, Andre
