Am 15.06.2018 um 15:01 schrieb Mark Kettenis <mark.kette...@xs4all.nl>:
>> From: Alexander Graf <ag...@suse.de> >> Date: Fri, 15 Jun 2018 12:49:48 +0200 >> >>> On 15.06.18 05:39, Heinrich Schuchardt wrote: >>> On 06/14/2018 10:50 PM, Mark Kettenis wrote: >>>>> From: Heinrich Schuchardt <xypron.g...@gmx.de> >>>>> Date: Thu, 14 Jun 2018 19:55:51 +0200 >>>>> >>>>>> On 06/14/2018 12:41 AM, Mark Kettenis wrote: >>>>>> This series makes it possible to run EFI applications in non-secure >>>>>> mode. It allows me to run OpenBSD on the Technexion PICO-PI-IMX7 and >>>>>> Banana Pi boards using the PSCI implementation provided by U-Boot. >>>>>> >>>>>> The second version avoids using r3 to pass the original stack pointer. >>>>>> For some reason that register gets clobbered on the Banana Pi. Instead >>>>>> this version just migrates SP_svc to SP_hyp. >>>>>> >>>>>> This third version avoids saving r3 on the stack and fixes an include >>>>>> guard as suggested by Alexander Graf. >>>>>> >>>>>> Mark Kettenis (3): >>>>>> ARM: HYP/non-sec: migrate stack >>>>>> efi_loader: ARM: run EFI payloads non-secure >>>>>> Revert "efi_loader: no support for ARMV7_NONSEC=y" >>>>>> >>>>>> arch/arm/cpu/armv7/nonsec_virt.S | 2 ++ >>>>>> cmd/bootefi.c | 32 ++++++++++++++++++++++++++++++++ >>>>>> doc/README.uefi | 2 -- >>>>>> lib/efi_loader/Kconfig | 2 -- >>>>>> 4 files changed, 34 insertions(+), 4 deletions(-) >>>>>> >>>>> Hello Mark, >>>>> >>>>> with this patch series running bootefi hello twice in sequence fails on >>>>> the BananaPi. >>>>> >>>>> => bootefi hello >>>>> Scanning disk m...@01c0f000.blk... >>>>> Found 3 disks >>>>> WARNING: booting without device tree >>>>> ## Starting EFI application at 42000000 ... >>>>> WARNING: using memory device/image path, this may confuse some payloads! >>>>> Hello, world! >>>>> Running on UEFI 2.7 >>>>> Have SMBIOS table >>>>> Load options: earlyprintk nosmp >>>>> ## Application terminated, r = 0 >>>>> => bootefi hello >>>>> WARNING: booting without device tree >>>>> ## Starting EFI application at 42000000 ... >>>>> WARNING: using memory device/image path, this may confuse some payloads! >>>>> <!-- no output after the preceding line --> >>>> >>>> Yeah. Trying to enter non-secure mode when we're already in >>>> non-secure mode doesn't really work. We should skip the switching >>>> code in that case. Now checking whether we are in non-secure mode >>>> isn't really possible. But I guess we can set a variable and check it >>>> before we go down the switching codepath. With that in I can exit the >>>> OpenBSD bootloader and then reload and run it again. I'll include >>>> that fix in the next respin. >>> >>> Hello Mark, >>> >>> you might move the call to switch to non-secure mode to efi_init_obj_list(). >> >> I would actually prefer to keep it where it is. That way we have the >> option to move the object initialization to a different stage later on. > > Also I'd rather not touch the aarch64 code in this series and I think > it makes sense to keep the switching in the same place for aarch32 and > aarch64. > >> The only thing missing is really a check which level we're on. The >> aarch64 code does this with a current_el() == 3 condition. > > As I replied to Heinrich, checking whether we're secure or not isn't > simple as reading the SCR.NS bit will trap if we're in non-secure > mode. But using a global variable to remember the state we're in, > works and isn't too ugly. Can you figure out something else? Like whether you're in SVC? > I'm going to look into enabling the MMU for HYP over the weekend. > I'll do another respin once I've figured that issue out. It might just be as simple as depending on LPAE in Kconfig when NS is set :) Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
