On 12/26/18 8:42 AM, Alexander Graf wrote: > > > On 26.12.18 03:02, Heinrich Schuchardt wrote: >> On 12/25/18 1:39 PM, Mark Kettenis wrote: >>>> From: Heinrich Schuchardt <xypron.g...@gmx.de> >>>> Date: Tue, 25 Dec 2018 09:26:57 +0100 >>>> >>>> Refactor the switch from supervisor to hypervisor to a new function called >>>> at >>>> the beginning of do_bootefi(). >>>> >>>> Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de> >>>> --- >>>> With this patch I am just moving around the switch from supervisor to >>>> hypervisor mode within the EFI subsystem. Similar switching also occurs >>>> in all other boot commands (cf. arch/arm/lib/bootm.c). >>> Never been a huge fan of setjmp/longjmp, but I can see what you're >>> doing here. This is tricky code though, so I think this needs to be >>> tested on armv7 systems that support virtualisation (Cortex-A7) and >>> systems that don't (Cortex-A9). >> >> For >> >>> >>>> Why are we running the U-Boot console in supervisor mode at all? Wouldn't >>>> it be advisable for security reasons to switch to hypervisor mode before >>>> entering the console? >>> On some boards there are commands that access secure devices. So >>> those commands would no longer work. Obviously that is already the >>> case when an EFI payload returns to the U-Boot command prompt. >>> >> >> Thanks Mark for pointing this out. >> >> We have some major differences between bootm and bootefi: >> >> - Bootefi does not support CONFIG_ARMV8_SWITCH_TO_EL1 used by some >> Xilinx boards. > > Yeah, mostly because I really dislike boards that simply switch to EL1 > for no good reason ;). > >> - It ignores CONFIG_ARMV8_PSCI. > > What exactly should it honor here?
Call armv8_setup_psci() and possibly smp_kick_all_cpus(). Regards Heinrich > >> - Update_os_arch_secondary_cores() is not called (needed for preparing >> SMP on several NXP platforms). I think these are maintained by York. >> >> So uniting the code might be advisable. > > Well, bootm assumes that there is a single big step from U-Boot into > payload (exiting U-Boot). With UEFI we have this long phase in between > where we're in UEFI land, but still need full access to all U-Boot > device infrastructure. > > So I'm not quite sure how to unify that easily. > > > Alex > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
