From: Heinrich Schuchardt xypron.glpk@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 mmc@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.
Please, keep in mind that we expect multiple EFI binaries to be executed in sequence. E.g. the first binary installs a driver. The second is the application using it.
Running iPXE's snp.efi binary shows changed behavior on the console. New characters are displayed in "slow motion" (3 characters per second). Setting up the network interface fails in iPXE.
The same happens on my Banana Pi. But not on the imx7 board.