| Message ID | 20180613224108.13372-1-kettenis@openbsd.org |
|---|---|
| Headers | show |
| Series | efi_loader: ARM: add support for ARMV7_NONSEC=y | expand |
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. Looks great to me, but I'd like to see at least Heinrich give his reviewed-by before I pull it in :). Alex
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 --> 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. Best regards Heinrich
On 14.06.18 19:55, Heinrich Schuchardt wrote: > 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 --> > > 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). Cache disabled maybe? Alex > Setting up the network interface fails in iPXE. > > Best regards > > Heinrich >
> 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.
On 06/14/2018 10:50 PM, Mark Kettenis wrote: >> 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. Hello Mark, you might move the call to switch to non-secure mode to efi_init_obj_list(). Best regards Heinrich > >> 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. >
On 15.06.18 05:39, Heinrich Schuchardt wrote: > On 06/14/2018 10:50 PM, Mark Kettenis wrote: >>> 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. > > 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. The only thing missing is really a check which level we're on. The aarch64 code does this with a current_el() == 3 condition. Alex
> From: Alexander Graf <agraf@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.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. > > > > 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. 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.
Am 15.06.2018 um 15:01 schrieb Mark Kettenis <mark.kettenis@xs4all.nl>: >> From: Alexander Graf <agraf@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.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. >>> >>> 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
> From: Alexander Graf <agraf@suse.de> > Date: Fri, 15 Jun 2018 15:12:31 +0200 > > Am 15.06.2018 um 15:01 schrieb Mark Kettenis <mark.kettenis@xs4all.nl>: > > >> From: Alexander Graf <agraf@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.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. > >>> > >>> 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? Unfortunately not. On hardware with security extensions, but without virtualization extensions, we'll start out in secure SVC before running the first EFI payload and in non-secure SVC afterwards. > > 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 :) Indeed.
On 06/14/2018 10:50 PM, Mark Kettenis wrote: >> From: Heinrich Schuchardt <xypron.glpk@gmx.de> >> 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. > Just for reference run the Banana Pi with only patch 3 (w/o patch 1 and 2) and you will see adequate speed in iPXE. And if you specify setenv bootargs nosmp you will be able to boot Linux via GRUB from your iSCSI drive. So this is not a deficiency of the board. Regards Heinrich
> From: Heinrich Schuchardt <xypron.glpk@gmx.de> > Date: Fri, 15 Jun 2018 22:35:58 +0200 > > On 06/14/2018 10:50 PM, Mark Kettenis wrote: > >> From: Heinrich Schuchardt <xypron.glpk@gmx.de> > >> 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. > > > > Just for reference run the Banana Pi with only patch 3 (w/o patch 1 and > 2) and you will see adequate speed in iPXE. And if you specify > > setenv bootargs nosmp > > you will be able to boot Linux via GRUB from your iSCSI drive. So this > is not a deficiency of the board. The update series I just posted makes things fast again. So far I haven't been able to build an iPXE EFI binary so that remains untested. Would be great if you could do that for me. But even if iPXE still doesn't work, I'd argue that efi_loader support for armv7 that works in the most common case of booting an OS using an EFI bootloader is better than having no efi_loader support at all... Cheers, Mark