On Fri, Sep 03, 2021 at 11:19:28AM +0100, Peter Hoyes wrote: > > Hi, > > On 03/09/2021 00:49, Tom Rini wrote: > > On Fri, Sep 03, 2021 at 12:07:20AM +0100, Andre Przywara wrote: > > > On Thu, 2 Sep 2021 18:42:05 -0400 > > > Tom Rini <tr...@konsulko.com> wrote: > > > > > > Hi Tom, > > > > > > > On Thu, Aug 19, 2021 at 04:53:13PM +0100, Peter Hoyes wrote: > > > > > > > > > From: Peter Hoyes <peter.ho...@arm.com> > > > > > > > > > > Use the environment variable armv8_switch_to_el1 to determine whether > > > > > to switch to EL1 at runtime. This is an alternative to the > > > > > CONFIG_ARMV8_SWITCH_TO_EL1 compile-time option. > > > > > > > > > > The environment variable will be ineffective if the ARMV8_MULTIENTRY > > > > > config is used. > > > > > > > > > > This is required by the Armv8r64 architecture, which must be able to > > > > > boot at S-EL1 for Linux but may need to boot at other ELs for other > > > > > systems. > > > > > > > > > > Signed-off-by: Peter Hoyes <peter.ho...@arm.com> > > > > Applied to u-boot/next, thanks! > > > Sorry for keeping silent on this, we had some internal discussions > > > here, and we don't think this is the right approach. > > Well, oops on my part too. > Oops here too. > > > > > This whole CONFIG_ARMV8_SWITCH_TO_EL1 solution is actually already > > > questionable, as it goes somewhat against the PSCI spec, which requires > > > secondaries to enter in the highest non-secure exception level (Section > > > 6.1.3: "... As described in Figure 6, the return Exception level for a > > > CPU_ON call is the highest Non secure Exception level implemented.") > > > > > > In any case the primary core must enter an the same exception level as > > > the secondaries, or all hell breaks loose. The current code violates > > > this bluntly when the dynamic method is used (as the spin table code > > > doesn't know about this variable). > > > > > > So can you please revert this patch? We are looking into a different > > Should I undo just this, or the whole vexpress_aemv8r series? > > > We are still discussing how to support v8-R internally and it'll probably > take a while to resolve. > > Please can you revert the wholeseries apart from patch 1, which isn't > actually specific to the v8-R. (If preferable,I can submit a "v3" to > clarify this).
OK, I'll revert everything except the first patch. For the next go-round, I had fixed up that the defconfig wasn't listed in the board MAINTAINERS, and there was a typo in the docs that checkpatch also spotted. -- Tom
signature.asc
Description: PGP signature
