> -----Original Message----- > From: Alexander Graf <ag...@suse.de> > Sent: Tuesday, August 7, 2018 6:46 AM > To: Tom Rini <tr...@konsulko.com> > Cc: Stefano Babic <sba...@denx.de>; Henry Beberman > <henry.beber...@microsoft.com>; u-boot@lists.denx.de; Fabio Estevam > <fabio.este...@nxp.com> > Subject: Re: [PATCH 01/11] imx: Add bootcmd to load and run UEFI from > mmc > > > > > Am 07.08.2018 um 12:16 schrieb Tom Rini <tr...@konsulko.com>: > > > >> On Tue, Aug 07, 2018 at 01:11:11PM +0200, Stefano Babic wrote: > >> Hi Henry, > >> > >>> On 14/07/2018 02:11, Henry Beberman wrote: > >>> From: Henry Beberman <henry.beber...@microsoft.com> > >>> > >>> This patch enables i.MX platforms to easily add a boot script to > >>> their U-Boot Proper environment to automatically load and execute an > >>> EFI firmware from the first FAT partition of an MMC device. > >>> > >>> This is a portion of enabling the Windows 10 IoT Core boot path. > >>> > >>> The go command is overridden when CONFIG_UEFI_BOOT is specified. > >>> This new go will perform a cache flush/disable, disable interrupts, > >>> then jump to the address where UEFI was loaded. > >>> > >>> This patch adds two new Kconfig options: > >>> CONFIG_UEFI_BOOT: Selects the UEFI bootcmd and overrides go to > flush > >>> caches and disable interrupts. > >>> CONFIG_UEFI_LOAD_ADDR: Specifies the load address for the UEFI > image > >>> > >>> Signed-off-by: Henry Beberman <henry.beber...@microsoft.com> > >>> Cc: Stefano Babic <sba...@denx.de> > >>> Cc: Fabio Estevam <fabio.este...@nxp.com> > >>> Cc: Tom Rini <tr...@konsulko.com> > >>> --- > >>> arch/arm/mach-imx/Makefile | 1 + > >>> arch/arm/mach-imx/boot.c | 19 +++++++++++++++++++ > >>> common/Kconfig | 17 +++++++++++++++++ > >>> include/config_uefi_bootcmd.h | 29 > +++++++++++++++++++++++++++++ > >>> 4 files changed, 66 insertions(+) > >>> create mode 100644 arch/arm/mach-imx/boot.c create mode 100644 > >>> include/config_uefi_bootcmd.h > >>> > >> > >> I am really missing why we need this specially for i.MX. There is > >> nothing special to i.MX, and if this command is necessary, we should > >> put it in common code. > >> > >> Anyway, should we not try to merge it with the general support for > >> UEFI in U-Boot ? We have already a "bootefi" command (aarch64 and > >> x86, currently). > > > > Agreed, this should be folded in with our existing UEFI support, thanks! > > Yes, please just use distro boot. Bootefi (which distro boot calls) already > supports running UEFI binaries for real even on armv7. > > > Alex >
Running Windows directly on U-Boot through bootefi is definitely appealing, but we're dependent on a number of features provided by our full UEFI firmware. * Several ACPI tables that are unimplemented in U-Boot: CSRT, DBG2, SPCR, TPM2, GTDT * Some DSDT elements that require the Microsoft ASL compiler (for now) * UEFI Authenticated Variables that are writeable at runtime. * UEFI Secure Boot * Launching and communicating with a Firmware TPM running as an OP-TEE Trusted Application I'd be happy to break down this patch's changes into more generic steps rather than creating confusion by adding CONFIG_UEFI_BOOT. I can move the UEFI binary into our FIT to eliminate the custom binary load script. How should I cleanly add an alternate CONFIG_BOOTCOMMAND to an existing board.h file? Where is the best place to define an alternate do_go_exec that calls cleanup_before_linux() before jumping? Thanks, Henry _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot