Enable Windows 10 IoT Core on i.MX6 and i.MX7

From: Henry Beberman <[email protected]>

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.

-----Original Message-----
From: Trent Piepho <[email protected]>
Sent: Monday, July 16, 2018 10:17 AM
To: Henry Beberman <[email protected]>; u-
boot at lists.denx.de
Cc: trini at konsulko.com; fabio.estevam at nxp.com
Subject: Re: [U-Boot] [PATCH 01/11] imx: Add bootcmd to load and run UEFI from mmc

Quoted 5 lines · Henry Beberman

From: Henry Beberman <[email protected]>

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.

Is there a reason to force the first partition instead of using the EFI partition code to select which partition to boot?

I also wonder, on a Linux system, is there a reason the EFI partition must use FAT?

Hi Trent,

Quoted 16 lines

-----Original Message-----
From: Trent Piepho <[email protected]>
Sent: Monday, July 16, 2018 10:17 AM
To: Henry Beberman <[email protected]>; u-
boot at lists.denx.de
Cc: trini at konsulko.com; fabio.estevam at nxp.com
Subject: Re: [U-Boot] [PATCH 01/11] imx: Add bootcmd to load and run UEFI from mmc

Quoted 5 lines · Henry Beberman

From: Henry Beberman <[email protected]>

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.

Quoted 5 lines

Is there a reason to force the first partition instead of using the EFI partition code to select which partition to boot?

I also wonder, on a Linux system, is there a reason the EFI partition must use FAT?

I need to revise the commit message for this patch. The script is not fixed to the first partition of the selected MMC, it scans the disk for partitions marked bootable, then checks each one of those until it finds the imxboard_efi.fd binary.

We could switch over to using the generic load from CONFIG_CMD_FS_GENERIC if there's demand for non-FAT filesystems. We're currently using fatload because the EFI partitions in our Windows images are always FAT formatted.

-----Original Message-----
From: Trent Piepho <[email protected]>
Sent: Monday, July 16, 2018 3:45 PM
To: Henry Beberman <[email protected]>; u-
boot at lists.denx.de
Cc: trini at konsulko.com; fabio.estevam at nxp.com
Subject: Re: [U-Boot] [PATCH 01/11] imx: Add bootcmd to load and run UEFI from mmc

Quoted 18 lines · Henry Beberman

Hi Trent,

Quoted 16 lines

-----Original Message-----
From: Trent Piepho <[email protected]>
Sent: Monday, July 16, 2018 10:17 AM
To: Henry Beberman <[email protected]>; u- boot at lists.denx.de
Cc: trini at konsulko.com; fabio.estevam at nxp.com
Subject: Re: [U-Boot] [PATCH 01/11] imx: Add bootcmd to load and run UEFI from mmc

Quoted 5 lines · Henry Beberman

From: Henry Beberman <[email protected]>

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.

Quoted 7 lines

Quoted 5 lines

Is there a reason to force the first partition instead of using the EFI partition code to select which partition to boot?

I also wonder, on a Linux system, is there a reason the EFI partition must use FAT?

I need to revise the commit message for this patch. The script is not fixed

to the first partition of the selected MMC, it scans the disk for partitions marked bootable, then checks each one of those until it finds the imxboard_efi.fd binary.

That is indeed very different from first FAT partition. Does bootable only apply legacy MBR partition tables? I didn't think bootable was typically used with GPT tables. There is a bit, but it's not used to mark EFI partitions.

Which brings me back to the partition type. Isn't that the right way to find the EFI?

Quoted 2 lines

We could switch over to using the generic load from

CONFIG_CMD_FS_GENERIC if there's demand for non-FAT filesystems. We're currently using fatload because the EFI partitions in our Windows images are always FAT formatted.

You're original search method required the partition be FAT.

Quoted 12 lines

Quoted 3 lines

I need to revise the commit message for this patch. The script is not fixed

to the first partition of the selected MMC, it scans the disk for partitions marked bootable, then checks each one of those until it finds the imxboard_efi.fd binary.

That is indeed very different from first FAT partition. Does bootable only apply legacy MBR partition tables? I didn't think bootable was typically used with GPT tables. There is a bit, but it's not used to mark EFI partitions.

Quoted 2 lines

Which brings me back to the partition type. Isn't that the right way to find the EFI?

The is_bootable function in disk/part_efi.c marks a partition as bootable if the partition_type_guid on disk matches the EFI PARTITION_SYSTEM_GUID. The part command with the -bootable flag will return the EFI partition on both GPT and MBR partition schemes. This method is also used by config_distro_bootcmd.h

Quoted 7 lines

Quoted 1 line

We could switch over to using the generic load from

CONFIG_CMD_FS_GENERIC if there's demand for non-FAT filesystems. We're currently using fatload because the EFI partitions in our Windows images are always FAT formatted.

You're original search method required the partition be FAT.

I'm happy to switch from the fatload command over to the load command if it will make CONFIG_UEFI_BOOT more widely useful.

-----Original Message-----
From: Trent Piepho <[email protected]>
Sent: Tuesday, July 17, 2018 10:24 AM
To: Henry Beberman <[email protected]>; u-
boot at lists.denx.de
Cc: trini at konsulko.com; fabio.estevam at nxp.com
Subject: Re: [U-Boot] [PATCH 01/11] imx: Add bootcmd to load and run UEFI from mmc

Quoted 5 lines · Henry Beberman

Quoted 5 lines

Quoted 4 lines

I need to revise the commit message for this patch. The script is not fixed

Quoted 7 lines

Quoted 7 lines

to the first partition of the selected MMC, it scans the disk for partitions marked bootable, then checks each one of those until it finds the imxboard_efi.fd binary.

That is indeed very different from first FAT partition. Does bootable only apply legacy MBR partition tables? I didn't think bootable was typically used with GPT tables. There is a bit, but it's not

used to mark EFI partitions.

Quoted 5 lines

Quoted 3 lines

Which brings me back to the partition type. Isn't that the right way to find the EFI?

The is_bootable function in disk/part_efi.c marks a partition as bootable if

the partition_type_guid on disk matches the EFI PARTITION_SYSTEM_GUID.

Quoted 3 lines

The part command with the -bootable flag will return the EFI partition on both GPT and MBR partition schemes. This method is also used by config_distro_bootcmd.h

But it also finds any partitions with the legacy bios bootable flag set in a GPT table or the active partition bit set in a MBR table, or any future reason a partition might be considered bootable. Someone trying to add a new type of bootable partition to distro bootcmd will be forced to deal with your windows nt boot command as it tries to boot any bootable partition, even ones it can't boot.

The distro boot command is designed to boot anything, so it searches for partitions beyond EFI. But what you've done is just for EFI. That's why it's different.

Quoted 5 lines · Henry Beberman

From: Henry Beberman <[email protected]>

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.

-----Original Message-----
From: Fabio Estevam <[email protected]>
Sent: Tuesday, July 17, 2018 10:09 AM
To: Trent Piepho <[email protected]>
Cc: Henry Beberman <[email protected]>; u-
boot at lists.denx.de; fabio.estevam at nxp.com; trini at konsulko.com
Subject: Re: [U-Boot] [PATCH 01/11] imx: Add bootcmd to load and run UEFI from mmc

Hi Henry,

Quoted 3 lines · Trent Piepho

Quoted 2 lines · Henry Beberman

From: Henry Beberman <[email protected]>

Quoted 3 lines

Quoted 3 lines

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.

Have you subscribed to the U-Boot list?

I don't see this series in the list archives, only on my NXP account.

From: Henry Beberman <[email protected]>

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 <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Fabio Estevam <[email protected]>

Cc Tom Rini <[email protected]>

---
 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

arch/arm/mach-imx/Makefile +1 -0

index 733c308670..a81af51f03 100644
@@ -42,6 +42,7 @@ endif
 obj-$(CONFIG_SATA) += sata.o
 obj-$(CONFIG_SECURE_BOOT)    += hab.o
 obj-$(CONFIG_SYSCOUNTER_TIMER) += syscounter.o
+obj-$(CONFIG_UEFI_BOOT) += boot.o
 endif
 ifeq ($(SOC),$(filter $(SOC),mx7ulp))
 obj-y  += cache.o

arch/arm/mach-imx/boot.c new file +19 -0

new file mode 100644
index 0000000000..457a323fa2
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Microsoft Corporation
+ */
+
+#include <common.h>
+#include <command.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#if defined(CONFIG_UEFI_BOOT)
+unsigned long do_go_exec(ulong (*entry)(int, char * const []), int argc,
+			 char * const argv[])
+{
+	cleanup_before_linux();
+
+	return entry(argc, argv);
+}
+#endif /* CONFIG_UEFI_BOOT */

common/Kconfig +17 -0

index 4c7a1a9af8..35362b629c 100644
@@ -217,6 +217,23 @@ config BOOTCOMMAND
 	  This is the string of commands that will be used as bootcmd and if
 	  AUTOBOOT is set, automatically run.
 
+config UEFI_BOOT
+	bool "Boot a UEFI firmware loaded from the first FAT partition on the mmc"
+	default n
+	help
+	  Override the CONFIG_BOOTCOMMAND to load a UEFI firmware image from the
+	  first FAT partition on the mmc. Override the go command to make it disable
+	  interrupts and flush the cache before jumping to the specified address.
+
+config UEFI_LOAD_ADDR
+	hex "Load address for the UEFI image"
+	depends on UEFI_BOOT
+	help
+	  CONFIG_UEFI_BOOT uses this as the address to load the UEFI image.
+	  The uefi_bootcmd script in the environment will fatload efi from the mmc
+	  to this location, then use an overridden go command to disable caches and
+	  interrupts then jump to this location.
+
 menu "Console"
 
 config MENU

include/config_uefi_bootcmd.h new file +19 -0

new file mode 100644
index 0000000000..03903abf8f
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2018 Microsoft Corporation
+ */
+
+#ifndef _CONFIG_UEFI_BOOTCMD_H
+#define _CONFIG_UEFI_BOOTCMD_H
+
+#define BOOTENV \
+	"uefi_image_name=imxboard_efi.fd\0" \
+	"uefi_addr=" __stringify(CONFIG_UEFI_LOAD_ADDR) "\0" \
+	"uefi_bootcmd=" \
+		"part list mmc ${mmcdev} -bootable devplist; " \
+		"env exists devplist || setenv devplist 1; " \
+		"for bootpart in ${devplist}; do " \
+			"if fatload mmc ${mmcdev}:${bootpart} " \
+			"${uefi_addr} ${uefi_image_name}; then " \
+				"echo \"Jumping to ${uefi_image_name} at " \
+				"${uefi_addr}\"; " \

Hi Henry,

Quoted 21 lines · Henry Beberman

From: Henry Beberman <[email protected]>

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 <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Fabio Estevam <[email protected]>

Cc Tom Rini <[email protected]>

Quoted 9 lines

---
 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).

Quoted 92 lines

arch/arm/mach-imx/Makefile +1 -0

index 733c308670..a81af51f03 100644
@@ -42,6 +42,7 @@ endif
 obj-$(CONFIG_SATA) += sata.o
 obj-$(CONFIG_SECURE_BOOT)    += hab.o
 obj-$(CONFIG_SYSCOUNTER_TIMER) += syscounter.o
+obj-$(CONFIG_UEFI_BOOT) += boot.o
 endif
 ifeq ($(SOC),$(filter $(SOC),mx7ulp))
 obj-y  += cache.o

arch/arm/mach-imx/boot.c new file +19 -0

new file mode 100644
index 0000000000..457a323fa2
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Microsoft Corporation
+ */
+
+#include <common.h>
+#include <command.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#if defined(CONFIG_UEFI_BOOT)
+unsigned long do_go_exec(ulong (*entry)(int, char * const []), int argc,
+			 char * const argv[])
+{
+	cleanup_before_linux();
+
+	return entry(argc, argv);
+}
+#endif /* CONFIG_UEFI_BOOT */

common/Kconfig +17 -0

index 4c7a1a9af8..35362b629c 100644
@@ -217,6 +217,23 @@ config BOOTCOMMAND
 	  This is the string of commands that will be used as bootcmd and if
 	  AUTOBOOT is set, automatically run.
 
+config UEFI_BOOT
+	bool "Boot a UEFI firmware loaded from the first FAT partition on the mmc"
+	default n
+	help
+	  Override the CONFIG_BOOTCOMMAND to load a UEFI firmware image from the
+	  first FAT partition on the mmc. Override the go command to make it disable
+	  interrupts and flush the cache before jumping to the specified address.
+
+config UEFI_LOAD_ADDR
+	hex "Load address for the UEFI image"
+	depends on UEFI_BOOT
+	help
+	  CONFIG_UEFI_BOOT uses this as the address to load the UEFI image.
+	  The uefi_bootcmd script in the environment will fatload efi from the mmc
+	  to this location, then use an overridden go command to disable caches and
+	  interrupts then jump to this location.
+
 menu "Console"
 
 config MENU

include/config_uefi_bootcmd.h new file +19 -0

new file mode 100644
index 0000000000..03903abf8f
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2018 Microsoft Corporation
+ */
+
+#ifndef _CONFIG_UEFI_BOOTCMD_H
+#define _CONFIG_UEFI_BOOTCMD_H
+
+#define BOOTENV \
+	"uefi_image_name=imxboard_efi.fd\0" \
+	"uefi_addr=" __stringify(CONFIG_UEFI_LOAD_ADDR) "\0" \
+	"uefi_bootcmd=" \
+		"part list mmc ${mmcdev} -bootable devplist; " \
+		"env exists devplist || setenv devplist 1; " \
+		"for bootpart in ${devplist}; do " \
+			"if fatload mmc ${mmcdev}:${bootpart} " \
+			"${uefi_addr} ${uefi_image_name}; then " \
+				"echo \"Jumping to ${uefi_image_name} at " \
+				"${uefi_addr}\"; " \

include/config_uefi_bootcmd.h line 29

Quoted 10 lines

include/config_uefi_bootcmd.h new file +10 -0

+				"go ${uefi_addr}; " \
+			"fi; " \
+		"done; " \
+		"echo \"Could not find ${uefi_image_name} on mmc ${mmcdev}\";\0"
+
+#ifdef CONFIG_UEFI_BOOT
+#define CONFIG_BOOTCOMMAND "run uefi_bootcmd"
+#endif
+
+#endif  /* _CONFIG_UEFI_BOOTCMD_H */

Best regards,
Stefano Babic

Signature · 5 lines

=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

Am 07.08.2018 um 12:16 schrieb Tom Rini <[email protected]>:

Quoted 39 lines · Stefano Babic

Hi Henry,

Quoted 22 lines · Henry Beberman

From: Henry Beberman <[email protected]>

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 <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Fabio Estevam <[email protected]>

Cc Tom Rini <[email protected]>

Quoted 9 lines

---

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.

Quoted 3 lines

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!

-----Original Message-----
From: Alexander Graf <[email protected]>
Sent: Tuesday, August 7, 2018 6:46 AM
To: Tom Rini <[email protected]>
Cc: Stefano Babic <[email protected]>; Henry Beberman <[email protected]>; u-boot at lists.denx.de; Fabio Estevam <[email protected]>
Subject: Re: [PATCH 01/11] imx: Add bootcmd to load and run UEFI from mmc

Quoted 20 lines

Am 07.08.2018 um 12:16 schrieb Tom Rini <[email protected]>:

Quoted 18 lines · Stefano Babic

Hi Henry,

Quoted 15 lines · Henry Beberman

From: Henry Beberman <[email protected]>

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

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

caches and disable interrupts.
CONFIG_UEFI_LOAD_ADDR: Specifies the load address for the UEFI

image

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Signed-off-by Henry Beberman <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Fabio Estevam <[email protected]>

Cc Tom Rini <[email protected]>

---

arch/arm/mach-imx/Makefile    |  1 +
arch/arm/mach-imx/boot.c      | 19 +++++++++++++++++++
common/Kconfig                | 17 +++++++++++++++++
include/config_uefi_bootcmd.h | 29

+++++++++++++++++++++++++++++

Quoted 13 lines

Quoted 12 lines

Quoted 4 lines

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).

Quoted 1 line

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

Quoted 58 lines

-----Original Message-----
From: Alexander Graf <[email protected]>
Sent: Tuesday, August 7, 2018 6:46 AM
To: Tom Rini <[email protected]>
Cc: Stefano Babic <[email protected]>; Henry Beberman <[email protected]>; u-boot at lists.denx.de; Fabio Estevam <[email protected]>
Subject: Re: [PATCH 01/11] imx: Add bootcmd to load and run UEFI from mmc

Quoted 20 lines

Am 07.08.2018 um 12:16 schrieb Tom Rini <[email protected]>:

Quoted 18 lines · Stefano Babic

Hi Henry,

Quoted 15 lines · Henry Beberman

From: Henry Beberman <[email protected]>

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

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

caches and disable interrupts.
CONFIG_UEFI_LOAD_ADDR: Specifies the load address for the UEFI

image

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Signed-off-by Henry Beberman <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Fabio Estevam <[email protected]>

Cc Tom Rini <[email protected]>

---

arch/arm/mach-imx/Makefile    |  1 +
arch/arm/mach-imx/boot.c      | 19 +++++++++++++++++++
common/Kconfig                | 17 +++++++++++++++++
include/config_uefi_bootcmd.h | 29

+++++++++++++++++++++++++++++

Quoted 11 lines

Quoted 11 lines

Quoted 4 lines

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).

Quoted 7 lines

Quoted 1 line

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?

From: Henry Beberman <[email protected]>

This patch is part of the i.MX Windows 10 IoT Core boot flow.

It adds a modified linker script for SPL to keep all segments in on-chip ram. This is to harden the device against potential leaks of device secrets by keeping them out of DRAM.

Additionally if CONFIG_SYS_SPL_MALLOC_START is defined, it will override the CONFIG_SPL_SYS_MALLOC_SIMPLE and allocate space in DRAM instead of on-chip ram. This patch prevents the definition of those values for i.MX6 and i.MX7 SPL if CONFIG_OPTEE_SPL_BOOT is selected.

-----Original Message-----
From: Trent Piepho <[email protected]>
Sent: Monday, July 16, 2018 10:33 AM
To: Henry Beberman <[email protected]>; u-
boot at lists.denx.de
Cc: fabio.estevam at nxp.com
Subject: Re: [U-Boot] [PATCH 04/11] spl: imx: Add optional lds to keep SPL entirely in on-chip RAM

Quoted 10 lines · Henry Beberman

From: Henry Beberman <[email protected]>

This patch is part of the i.MX Windows 10 IoT Core boot flow.

It adds a modified linker script for SPL to keep all segments in on-chip ram. This is to harden the device against potential leaks of device secrets by keeping them out of DRAM.

Additionally if CONFIG_SYS_SPL_MALLOC_START is defined, it will override the CONFIG_SPL_SYS_MALLOC_SIMPLE and allocate space in

DRAM

Quoted 2 lines

instead of on-chip ram. This patch prevents the definition of those values for i.MX6 and i.MX7 SPL if CONFIG_OPTEE_SPL_BOOT is selected.

Is booting SPL from entirely from SRAM only useful in concert with OPTEE?

For instance, if I'm building a device that doesn't use OPTEE and yet want it to be secure, would I want to keep the SPL entirely in SRAM?

From: Henry Beberman <[email protected]>

This patch is part of the i.MX Windows 10 IoT Core boot flow.

It adds a modified linker script for SPL to keep all segments in on-chip ram. This is to harden the device against potential leaks of device secrets by keeping them out of DRAM.

Additionally if CONFIG_SYS_SPL_MALLOC_START is defined, it will override the CONFIG_SPL_SYS_MALLOC_SIMPLE and allocate space in DRAM instead of on-chip ram. This patch prevents the definition of those values for i.MX6 and i.MX7 SPL if CONFIG_OPTEE_SPL_BOOT is selected.

Signed-off-by Henry Beberman <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Fabio Estevam <[email protected]>

---
 arch/arm/mach-imx/u-boot-spl-sram.lds | 59 +++++++++++++++++++++++++++++++++++
 include/configs/imx6_spl.h            |  2 ++
 include/configs/imx7_spl.h            |  2 ++
 3 files changed, 63 insertions(+)
 create mode 100644 arch/arm/mach-imx/u-boot-spl-sram.lds

arch/arm/mach-imx/u-boot-spl-sram.lds new file +49 -0

new file mode 100644
index 0000000000..dfbb4aef5d
@@ -0,0 +1,59 @@
+/*
+ * (C) Copyright 2002
+ * Gary Jennejohn, DENX Software Engineering, <[email protected]>
+ *
+ * (C) Copyright 2010
+ * Texas Instruments, <www.ti.com>
+ *	Aneesh V <[email protected]>
+ *
+ * (C) Copyright 2018 Microsoft Corporation
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+MEMORY { .sram : ORIGIN = CONFIG_SPL_TEXT_BASE,\
+		LENGTH = CONFIG_SPL_MAX_SIZE }
+
+OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
+OUTPUT_ARCH(arm)
+ENTRY(_start)
+SECTIONS
+{
+	.text      :
+	{
+		__start = .;
+		*(.vectors)
+		arch/arm/cpu/armv7/start.o	(.text*)
+		*(.text*)
+	} >.sram
+
+	. = ALIGN(4);
+	.rodata : { *(SORT_BY_ALIGNMENT(.rodata*)) } >.sram
+
+	. = ALIGN(4);
+	.data : { *(SORT_BY_ALIGNMENT(.data*)) } >.sram
+
+	. = ALIGN(4);
+	.u_boot_list : {
+		KEEP(*(SORT(.u_boot_list*)));
+	} >.sram
+
+	. = ALIGN(4);
+	__image_copy_end = .;
+
+	.end :
+	{
+		*(.__end)
+	}
+
+	_image_binary_end = .;

include/configs/imx6_spl.h +2 -0

index 720ff045a7..4088e8a936 100644
@@ -51,6 +51,7 @@
 # endif
 #endif
 
+#ifndef CONFIG_OPTEE_SPL_BOOT
 #if defined(CONFIG_MX6SX) || defined(CONFIG_MX6SL) || \
 	defined(CONFIG_MX6UL) || defined(CONFIG_MX6ULL)
 #define CONFIG_SPL_BSS_START_ADDR      0x88200000

@@ -63,6 +64,7 @@
 #define CONFIG_SYS_SPL_MALLOC_START	0x18300000
 #define CONFIG_SYS_SPL_MALLOC_SIZE	0x100000	/* 1 MB */
 #endif
+#endif /* !CONFIG_OPTEE_SPL_BOOT */
 #endif
 
 #endif

include/configs/imx7_spl.h +0 -0

index 1eb6cd894d..5dd4aed652 100644
@@ -46,10 +46,12 @@
 # endif

-----Original Message-----
From: Stefano Babic <[email protected]>
Sent: Tuesday, August 7, 2018 5:17 AM
To: Henry Beberman <[email protected]>; u-
boot at lists.denx.de
Cc: Stefano Babic <[email protected]>; Fabio Estevam <[email protected]>
Subject: Re: [PATCH 04/11] spl: imx: Add optional lds to keep SPL entirely in on-chip RAM

Hi Henry,

Quoted 10 lines · Henry Beberman

From: Henry Beberman <[email protected]>

This patch is part of the i.MX Windows 10 IoT Core boot flow.

It adds a modified linker script for SPL to keep all segments in on-chip ram. This is to harden the device against potential leaks of device secrets by keeping them out of DRAM.

Additionally if CONFIG_SYS_SPL_MALLOC_START is defined, it will override the CONFIG_SPL_SYS_MALLOC_SIMPLE and allocate space in

DRAM

Quoted 3 lines

instead of on-chip ram. This patch prevents the definition of those values for i.MX6 and i.MX7 SPL if CONFIG_OPTEE_SPL_BOOT is selected.

I guess there should be some kind of restrictions to be set according to the i.MX6 variant. I have already had some projects where I get rid of all space available on OCRAM. The smaller i.MX6 has just 64KB of RAM - have you tested also on them ? I wonder if there is enough space for all i.MX variants, specially if some other options are enabled.

Quoted 6 lines

Signed-off-by Henry Beberman <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Fabio Estevam <[email protected]>

---
 arch/arm/mach-imx/u-boot-spl-sram.lds | 59

+++++++++++++++++++++++++++++++++++

Quoted 12 lines

 include/configs/imx6_spl.h            |  2 ++
 include/configs/imx7_spl.h            |  2 ++
 3 files changed, 63 insertions(+)
 create mode 100644 arch/arm/mach-imx/u-boot-spl-sram.lds

arch/arm/mach-imx/u-boot-spl-sram.lds new file +0 -0

new file mode 100644
index 0000000000..dfbb4aef5d

arch/arm/mach-imx/u-boot-spl-sram.lds line 6

Quoted 6 lines

arch/arm/mach-imx/u-boot-spl-sram.lds new file +6 -0

@@ -0,0 +1,59 @@
+/*
+ * (C) Copyright 2002
+ * Gary Jennejohn, DENX Software Engineering, <[email protected]>
+ *
+ * (C) Copyright 2010
+ * Texas Instruments,

<https://na01.safelinks.protection.outlook.com/?url=www.ti.com&amp;dat
a=02%7C01%7CHenry.Beberman%40microsoft.com%7Cd96d8086ca0a4fd87d 5308d5fc5fb1db%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6366 92410300862003&amp;sdata=RFzlv9uQ5%2BBDtudKWw4aacKgE4B%2Bn1ENE xvM9v2ANew%3D&amp;reserved=0>

Quoted 51 lines

arch/arm/mach-imx/u-boot-spl-sram.lds new file +51 -0

+ *	Aneesh V <[email protected]>
+ *
+ * (C) Copyright 2018 Microsoft Corporation
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+MEMORY { .sram : ORIGIN = CONFIG_SPL_TEXT_BASE,\
+		LENGTH = CONFIG_SPL_MAX_SIZE }
+
+OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm",
+"elf32-littlearm")
+OUTPUT_ARCH(arm)
+ENTRY(_start)
+SECTIONS
+{
+	.text      :
+	{
+		__start = .;
+		*(.vectors)
+		arch/arm/cpu/armv7/start.o	(.text*)
+		*(.text*)
+	} >.sram
+
+	. = ALIGN(4);
+	.rodata : { *(SORT_BY_ALIGNMENT(.rodata*)) } >.sram
+
+	. = ALIGN(4);
+	.data : { *(SORT_BY_ALIGNMENT(.data*)) } >.sram
+
+	. = ALIGN(4);
+	.u_boot_list : {
+		KEEP(*(SORT(.u_boot_list*)));
+	} >.sram
+
+	. = ALIGN(4);
+	__image_copy_end = .;
+
+	.end :
+	{
+		*(.__end)
+	}
+
+	_image_binary_end = .;
+
+	.bss :
+	{
+		. = ALIGN(4);
+		__bss_start = .;
+		*(.bss*)
+		. = ALIGN(4);

arch/arm/mach-imx/u-boot-spl-sram.lds line 59

Quoted 3 lines

arch/arm/mach-imx/u-boot-spl-sram.lds new file +3 -0

+		__bss_end = .;
+	} >.sram
+}

This is more or less a copy of the armv8 version + bss in sram instead of sdram. In any case, mach-imx is not the right place because it is quite SOC independent. The whole i.MX do not use own lds but they are using the general scripts from ARM 32bit.

Quoted 26 lines

include/configs/imx6_spl.h +2 -0

index 720ff045a7..4088e8a936 100644
@@ -51,6 +51,7 @@
 # endif
 #endif
 
+#ifndef CONFIG_OPTEE_SPL_BOOT
 #if defined(CONFIG_MX6SX) || defined(CONFIG_MX6SL) || \
 	defined(CONFIG_MX6UL) || defined(CONFIG_MX6ULL)
 #define CONFIG_SPL_BSS_START_ADDR      0x88200000

@@ -63,6 +64,7 @@
 #define CONFIG_SYS_SPL_MALLOC_START	0x18300000
 #define CONFIG_SYS_SPL_MALLOC_SIZE	0x100000	/* 1 MB */
 #endif
+#endif /* !CONFIG_OPTEE_SPL_BOOT */
 #endif
 
 #endif

include/configs/imx7_spl.h +0 -0

index 1eb6cd894d..5dd4aed652 100644

include/configs/imx7_spl.h line 53

Quoted 8 lines

include/configs/imx7_spl.h +1 -0

@@ -46,10 +46,12 @@
 # endif
 #endif
 
+#ifndef CONFIG_OPTEE_SPL_BOOT
 #define CONFIG_SPL_BSS_START_ADDR      0x88200000
 #define CONFIG_SPL_BSS_MAX_SIZE        0x100000		/* 1 MB */
 #define CONFIG_SYS_SPL_MALLOC_START    0x88300000
 #define CONFIG_SYS_SPL_MALLOC_SIZE     0x100000		/* 1

MB */

include/configs/imx7_spl.h line 56

Quoted 3 lines

include/configs/imx7_spl.h +1 -0

+#endif /* !CONFIG_OPTEE_SPL_BOOT */
 
 #endif /* CONFIG_SPL */

Best regards,
Stefano Babic

--
==========================================================
===========
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
==========================================================
===========

From: Henry Beberman <[email protected]>

This patch adds a new bootable configuration for Windows 10 IoT Core on the i.MX7 Dual Sabre board.

It enables SPL on the i.MX7 Sabre in order to support the FIT load of OP-TEE and U-Boot proper.

drivers/gpio/Makefile +0 -0

index f186120684..3fb9b72703 100644

-----Original Message-----
From: Trent Piepho <[email protected]>
Sent: Monday, July 16, 2018 11:22 AM
To: Henry Beberman <[email protected]>; u- boot at lists.denx.de
Cc: fabio.estevam at nxp.com; adrian.alonso at nxp.com
Subject: Re: [U-Boot] [PATCH 06/11] mx7dsabresd: Add Windows boot support for iMX7 Sabre

Quoted 21 lines · Henry Beberman

From: Henry Beberman <[email protected]>

This patch adds a new bootable configuration for Windows 10 IoT Core on the i.MX7 Dual Sabre board.

It enables SPL on the i.MX7 Sabre in order to support the FIT load of OP-TEE and U-Boot proper.

drivers/gpio/Makefile index renamed from drivers/gpio/Makefile +0 -0

f186120684..3fb9b72703 100644

drivers/gpio/Makefile +2 -0

@@ -7,10 +7,13 @@ ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_DWAPB_GPIO)	+= dwapb_gpio.o
 obj-$(CONFIG_AXP_GPIO)		+= axp_gpio.o
 endif
+
+ifeq ($(CONFIG_$(SPL_TPL_)DM),y)
 obj-$(CONFIG_DM_GPIO)		+= gpio-uclass.o
 

drivers/gpio/Makefile ifndef CONFIG_SPL_BUILD · line 16

Quoted 3 lines

drivers/gpio/Makefile +1 -0

 obj-$(CONFIG_DM_PCA953X)	+= pca953x_gpio.o
 obj-$(CONFIG_DM_74X164)		+= 74x164_gpio.o
+endif

It doesn't look like this patch is specific to mx7 or Windows. Perhaps it should be in a different commit?

Also, the help text for SPL_DM says it turns on basic DM support in SPL. But not any specific hardware drivers. Those all have additional config options to turn them on. It doesn't seems right to bundle a selection of GPIO drivers along with CONFIG_SPL_DM.

Quoted 30 lines

-----Original Message-----
From: Trent Piepho <[email protected]>
Sent: Monday, July 16, 2018 11:22 AM
To: Henry Beberman <[email protected]>; u- boot at lists.denx.de
Cc: fabio.estevam at nxp.com; adrian.alonso at nxp.com
Subject: Re: [U-Boot] [PATCH 06/11] mx7dsabresd: Add Windows boot support for iMX7 Sabre

Quoted 20 lines · Henry Beberman

From: Henry Beberman <[email protected]>

This patch adds a new bootable configuration for Windows 10 IoT Core on the i.MX7 Dual Sabre board.

It enables SPL on the i.MX7 Sabre in order to support the FIT load of OP-TEE and U-Boot proper.

drivers/gpio/Makefile index renamed from drivers/gpio/Makefile +0 -0

f186120684..3fb9b72703 100644

drivers/gpio/Makefile +2 -0

@@ -7,10 +7,13 @@ ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_DWAPB_GPIO)	+= dwapb_gpio.o
 obj-$(CONFIG_AXP_GPIO)		+= axp_gpio.o
 endif
+
+ifeq ($(CONFIG_$(SPL_TPL_)DM),y)
 obj-$(CONFIG_DM_GPIO)		+= gpio-uclass.o
 

Quoted 6 lines

drivers/gpio/Makefile ifndef CONFIG_SPL_BUILD · line 16

Quoted 3 lines

drivers/gpio/Makefile +1 -0

 obj-$(CONFIG_DM_PCA953X)	+= pca953x_gpio.o
 obj-$(CONFIG_DM_74X164)		+= 74x164_gpio.o
+endif

It doesn't look like this patch is specific to mx7 or Windows. Perhaps it should be in a different commit?

I agree that this change probably belongs in its own patch.
I've left it in this patch so far because it's required to build the new mx7dsabresd_nt_defconfig.

Quoted 4 lines

Also, the help text for SPL_DM says it turns on basic DM support in SPL. But not any specific hardware drivers. Those all have additional config options to turn them on. It doesn't seems right to bundle a selection of GPIO drivers along with CONFIG_SPL_DM.

This issue has cropped up because this patch adds SPL support to mx7dsabresd, but intentionally does not enable SPL_DM.
The defconfig contains CONFIG_DM_74X164 for use in U-Boot Proper, but because drivers/gpio/Makefile also runs during the SPL portion of the build that config still pulls in the 74X164 driver which fails to build due to missing dependencies.

Wrapping the DM objects in CONFIG_$(SPL_TPL_)DM ensures that DM is actually enabled for the current portion of the build when deciding to build the DM drivers.

-----Original Message-----
From: Trent Piepho <[email protected]>
Sent: Tuesday, July 17, 2018 10:03 AM
To: Henry Beberman <[email protected]>; u- boot at lists.denx.de
Cc: fabio.estevam at nxp.com; adrian.alonso at nxp.com
Subject: Re: [U-Boot] [PATCH 06/11] mx7dsabresd: Add Windows boot support for iMX7 Sabre

Quoted 37 lines · Henry Beberman

Quoted 30 lines

-----Original Message-----
From: Trent Piepho <[email protected]>
Sent: Monday, July 16, 2018 11:22 AM
To: Henry Beberman <[email protected]>; u- boot at lists.denx.de
Cc: fabio.estevam at nxp.com; adrian.alonso at nxp.com
Subject: Re: [U-Boot] [PATCH 06/11] mx7dsabresd: Add Windows boot support for iMX7 Sabre

Quoted 20 lines · Henry Beberman

From: Henry Beberman <[email protected]>

This patch adds a new bootable configuration for Windows 10 IoT Core on the i.MX7 Dual Sabre board.

It enables SPL on the i.MX7 Sabre in order to support the FIT load of OP-TEE and U-Boot proper.

drivers/gpio/Makefile index renamed from drivers/gpio/Makefile +0 -0

f186120684..3fb9b72703 100644

drivers/gpio/Makefile +2 -0

@@ -7,10 +7,13 @@ ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_DWAPB_GPIO)	+= dwapb_gpio.o
 obj-$(CONFIG_AXP_GPIO)		+= axp_gpio.o
 endif
+
+ifeq ($(CONFIG_$(SPL_TPL_)DM),y)
 obj-$(CONFIG_DM_GPIO)		+= gpio-uclass.o
 

Quoted 6 lines

drivers/gpio/Makefile ifndef CONFIG_SPL_BUILD · line 16

Quoted 3 lines

drivers/gpio/Makefile +1 -0

 obj-$(CONFIG_DM_PCA953X)	+= pca953x_gpio.o
 obj-$(CONFIG_DM_74X164)		+= 74x164_gpio.o
+endif

It doesn't look like this patch is specific to mx7 or Windows. Perhaps it should be in a different commit?

Quoted 2 lines

I agree that this change probably belongs in its own patch. I've left it in this patch so far because it's required to build the new

mx7dsabresd_nt_defconfig.

Easy enough to split out and put first. The person on different hardware trying to figure out the u-boot build spaghetti it's helped much knowing the person who added it was working on windows 10 support, but nothing about the reason for this change.

Quoted 6 lines

Quoted 4 lines

Also, the help text for SPL_DM says it turns on basic DM support in SPL. But not any specific hardware drivers. Those all have additional config options to turn them on. It doesn't seems right to bundle a selection of GPIO drivers along with CONFIG_SPL_DM.

This issue has cropped up because this patch adds SPL support to

mx7dsabresd, but intentionally does not enable SPL_DM.

Quoted 1 line

The defconfig contains CONFIG_DM_74X164 for use in U-Boot Proper, but

because drivers/gpio/Makefile also runs during the SPL portion of the build that config still pulls in the 74X164 driver which fails to build due to missing dependencies.

Quoted 2 lines

Wrapping the DM objects in CONFIG_$(SPL_TPL_)DM ensures that DM is

actually enabled for the current portion of the build when deciding to build the DM drivers.

But isn't it odd that not a single other driver is wrapped this way? What's special here?

I think the underlying flaw is the the kbuild system doesn't support the concept of building multiple times in different modes, e.g. main, SPL, TPL. And rather than design something, one gets layers of board specific hacks.