From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ang, Chee Hong Date: Mon, 8 Apr 2019 09:00:25 +0000 Subject: [U-Boot] [RESEND PATCH] ARMv8: PSCI: Fix PSCI_TABLE relocation issue In-Reply-To: References: <20190404123849.21633-1-lars.povlsen@microchip.com> <1554693002.41402.6.camel@intel.com> Message-ID: <1554714024.43255.17.camel@intel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de On Mon, 2019-04-08 at 07:27 +0000, Lars.Povlsen at microchip.com wrote: > > > > From: Ang, Chee Hong > > Sent: Monday, April 8, 2019 05:10 > > To: Lars Povlsen - M31675 ; > > 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 > > > --- > > >  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 CONFIG_ARMV8_SECURE_BASE defines the target relocation address for the PSCI code and the table. I just checked the PSCI handler addresses in the PSCI table entry (_psci_32_table & _psci_64_table) of my uboot, they point to the relocated address without using the 64bits size.