[U-Boot] [RESEND PATCH] ARMv8: PSCI: Fix PSCI_TABLE relocation issue
Lars.Povlsen at microchip.com
Lars.Povlsen at microchip.com
Mon Apr 8 07:27:40 UTC 2019
> From: Ang, Chee Hong <chee.hong.ang at intel.com>
> Sent: Monday, April 8, 2019 05:10
> To: Lars Povlsen - M31675 <Lars.Povlsen at microchip.com>;
> trini at konsulko.com; u-boot at lists.denx.de; macro.wave.z at gmail.com;
> albert.u.boot at aribaud.net; york.sun at nxp.com
> Subject: Re: [RESEND PATCH] ARMv8: PSCI: Fix PSCI_TABLE relocation issue
>
> On Thu, 2019-04-04 at 14:38 +0200, Lars Povlsen wrote:
> > This fixes relaction isses with the PSCI_TABLE entries in
> > the psci_32_table and psci_64_table.
> >
> > When using 32-bit adress pointers relocation was not being applied to
> > the tables, causing PSCI handlers to point to the un-relocated code
> > area. By using 64-bit data relocation is properly applied. The
> > handlers are thus in the "secure data" area, which is protected by
> > /memreserve/ in the FDT.
> >
> > Signed-off-by: Lars Povlsen <lars.povlsen at microchip.com>
> > ---
> > arch/arm/cpu/armv8/psci.S | 13 ++++++-------
> > 1 file changed, 6 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm/cpu/armv8/psci.S b/arch/arm/cpu/armv8/psci.S
> > index 358df8fee9..b4568cf053 100644
> > --- a/arch/arm/cpu/armv8/psci.S
> > +++ b/arch/arm/cpu/armv8/psci.S
> > @@ -19,8 +19,8 @@
> >
> > /* PSCI function and ID table definition*/
> > #define PSCI_TABLE(__id, __fn) \
> > - .word __id; \
> > - .word __fn
> > + .quad __id; \
> > + .quad __fn
> >
> > .pushsection ._secure.text, "ax"
> >
> > @@ -132,16 +132,15 @@ PSCI_TABLE(0, 0)
> > /* Caller must put PSCI function-ID table base in x9 */
> > handle_psci:
> > psci_enter
> > -1: ldr x10, [x9] /* Load PSCI function
> > table */
> > - ubfx x11, x10, #32, #32
> > - ubfx x10, x10, #0, #32
> > +1: ldr x10, [x9] /* Load PSCI function
> > table */
> > cbz x10, 3f /* If reach the
> > end, bail out */
> > cmp x10, x0
> > b.eq 2f /* PSCI function found
> > */
> > - add x9, x9, #8 /* If not match, try
> > next entry */
> > + add x9, x9, #16 /* If not match, try
> > next entry */
> > b 1b
> >
> > -2: blr x11 /* Call PSCI
> > function */
> > +2: ldr x11, [x9, #8] /* Load PSCI
> > function */
> > + blr x11 /* Call PSCI function
> > */
> > psci_return
> >
> > 3: mov x0, #ARM_PSCI_RET_NI
>
> Hmmm...I presumed you made these changes because your relocation
> address for "secure" section is beyond 32bits (4GB). How your page
> table for MMU is being setup ? Why do you need such large address space
> (beyond 4GB) ?
No, as I tried to describe in the log message, the relocation was simply
not being applied. Changing the offsets to 64-bit fixed this. The .text base
was 0x80000000 and the relocation was done in a 2Gb window (so somewhere ~ 0xfff.....)
Never the less, I assume a 64-bit target should not be constrained to 32-bit addresses?
When debugging the code, I noticed my debugger was able to match the original symbols
even though relocation was done. That’s how I became aware. I could see that the vector table
and the first level code *was* relocated, but the individual handlers not.
---Lars
More information about the U-Boot
mailing list