* [PATCH v6 0/9] Add falcon support for am62a, 62p and 62x
@ 2025-04-28 14:12 Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 1/9] spl: Kconfig: allow K3 devices to use falcon mode Anshul Dalal
` (8 more replies)
0 siblings, 9 replies; 20+ messages in thread
From: Anshul Dalal @ 2025-04-28 14:12 UTC (permalink / raw)
To: u-boot; +Cc: Anshul Dalal, vigneshr, trini, afd, m-chawdhry, n-francis, b-liu
This patch set adds support for falcon boot on AM62a, 62p and 62x by
bypassing A53 SPL and U-boot.
Existing Boot flow:
R5 SPL -> ATF -> A53 SPL -> U-Boot -> Linux Kernel
Updated flow:
R5 SPL -> ATF -> Linux Kernel
U-boot's falcon flow expects the jump from SPL to kernel to happen on
the same core which is not directly applicable for our heterogeneous
platforms since ATF, OPTEE and other non SPL binaries from tispl.bin
should be loaded before the kernel by the R5 SPL.
So we have to use a non std flow to bypass A53 SPL and U-Boot, we first
load the newly added tispl_falcon.bin instead of tispl.bin which lacks
u-boot-spl.bin (A53's SPL) and the corresponding fdt. This sets up dm,
tifs, optee and atf. Once loaded, we load the kernel and the dtb (with
fixups) at ATF's PRELOADED_BL33_BASE and K3_HW_CONFIG_BASE.
NOTE:
Since we're now using the SPL to load the kernel and kernel expects a
2MiB aligned load address, the existing PRELOADED_BL33_BASE has to be
changed for ATF to 0x82000000 with K3_HW_CONFIG_BASE set to
0x88000000 for the DTB.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
Changes in v6:
* Added A53 build steps in docs
* Had git add SVGs as text instead of blob
* Added memory map for standard boot flow
v5: https://lore.kernel.org/u-boot/20250425145644.2228186-1-anshuld@ti.com/
Changes in v5:
* Added documentation
* Moved address for kernel and dtb to 0x82000000 and 0x88000000 respectively
v4: https://lore.kernel.org/u-boot/20250416074515.1452854-1-anshuld@ti.com/
Changes in v4:
* Move emmc boot fixes to saperate patch
* Update load address for kernel to 0x82200000
* Add jump_stub config
v3: https://lore.kernel.org/u-boot/20250403215910.1292922-1-anshuld@ti.com/
Changes in v3:
* Make tifs load and entry address consistent with tispl for am62a and 62p
* Update loadables order to be same as tispl.bin
* Use rootfs for boot instead of boot partition
* Disable SPL_HAS_BOOTZ to save space
* Add default dtbs for each board in Kconfig
* Fix fdt totalsize in the header before applying fixups
* Update Makefile to clean tispl_falcon.bin on `make clean`
v2: https://lore.kernel.org/u-boot/20250311095758.3383047-1-anshuld@ti.com/
Changes in v2:
* Move to CONFIG_SYS_SPI_*
* Remove the need for CMD_BOOTI
v1: https://lore.kernel.org/u-boot/20250307075541.2571104-1-anshuld@ti.com/
Andreas Dannenberg (1):
arch: arm: mach-k3: r5: am62ax: Update SoC auto-gen data to enable
CPSW boot
Anshul Dalal (1):
spl: Kconfig: allow K3 devices to use falcon mode
Daniel Schultz (1):
arch: arm: dts: k3-am62a7-phyboard-lyra-rdk-u-boot: Disable Ethernet2
Nathan Morrisson (2):
arch: arm: mach-k3: am62a7: Probe CPSW NUSS in board_init_f()
board: phytec: phycore_am62ax: Share ethernet resources with boot r5
core
Wadim Egorov (4):
arm: dts: k3-am625-phyboard-lyra-rdk: Add boot phase tag to
phy_gmii_sel
configs: Add phycore_am62x_r5_ethboot_defconfig
configs: phycore_am62x_a53_defconfig: Update for ethernet boot
configs: Add phycore_am62ax_r5_ethboot_defconfig
--
2.49.0
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH v6 1/9] spl: Kconfig: allow K3 devices to use falcon mode
2025-04-28 14:12 [PATCH v6 0/9] Add falcon support for am62a, 62p and 62x Anshul Dalal
@ 2025-04-28 14:12 ` Anshul Dalal
2025-05-06 14:33 ` Andrew Davis
2025-04-28 14:12 ` [PATCH v6 2/9] mach-k3: fix reading size and addr from fdt on R5 Anshul Dalal
` (7 subsequent siblings)
8 siblings, 1 reply; 20+ messages in thread
From: Anshul Dalal @ 2025-04-28 14:12 UTC (permalink / raw)
To: u-boot; +Cc: Anshul Dalal, vigneshr, trini, afd, m-chawdhry, n-francis, b-liu
Falcon mode was disabled for TI_SECURE_DEVICE at commit e95b9b4437bc
("ti_armv7_common: Disable Falcon Mode on HS devices") for older 32-bit
HS devices and can be enabled on K3 devices.
For secure boot, the kernel with x509 headers can be packaged in a fit
container (fitImage) signed with TIFS keys for authentication.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
common/spl/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index c08045f9c8d..68e900e9b91 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -1165,7 +1165,7 @@ config SPL_ONENAND_SUPPORT
config SPL_OS_BOOT
bool "Activate Falcon Mode"
- depends on !TI_SECURE_DEVICE
+ depends on !TI_SECURE_DEVICE || ARCH_K3
help
Enable booting directly to an OS from SPL.
for more info read doc/README.falcon
--
2.49.0
^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PATCH v6 2/9] mach-k3: fix reading size and addr from fdt on R5
2025-04-28 14:12 [PATCH v6 0/9] Add falcon support for am62a, 62p and 62x Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 1/9] spl: Kconfig: allow K3 devices to use falcon mode Anshul Dalal
@ 2025-04-28 14:12 ` Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 3/9] arch: arm: k3-binman: add fit for falcon boot Anshul Dalal
` (6 subsequent siblings)
8 siblings, 0 replies; 20+ messages in thread
From: Anshul Dalal @ 2025-04-28 14:12 UTC (permalink / raw)
To: u-boot; +Cc: Anshul Dalal, vigneshr, trini, afd, m-chawdhry, n-francis, b-liu
fdtdec_get_addr_size uses architecture dependent datatypes which causes
the 32-bit R5 to fail when reading the 64-bit size and addr fields of
reg nodes from the fdt.
This changes it to a common api for both 64 and 32 bit platforms.
Now fdt fixups can be applied to the fdt from R5.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
arch/arm/mach-k3/common_fdt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-k3/common_fdt.c b/arch/arm/mach-k3/common_fdt.c
index 361b0c0b31b..c227743f9f8 100644
--- a/arch/arm/mach-k3/common_fdt.c
+++ b/arch/arm/mach-k3/common_fdt.c
@@ -137,7 +137,9 @@ int fdt_fixup_reserved(void *blob, const char *name,
return -EINVAL;
if (!strncmp(node_name, name, strlen(name))) {
/* Read out old size first */
- addr = fdtdec_get_addr_size(blob, subnode, "reg", &size);
+ addr = fdtdec_get_addr_size_fixed(
+ blob, subnode, "reg", 0, 8 / sizeof(fdt32_t),
+ 8 / sizeof(fdt32_t), &size, false);
if (addr == FDT_ADDR_T_NONE)
return -EINVAL;
new_size = size;
--
2.49.0
^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PATCH v6 3/9] arch: arm: k3-binman: add fit for falcon boot
2025-04-28 14:12 [PATCH v6 0/9] Add falcon support for am62a, 62p and 62x Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 1/9] spl: Kconfig: allow K3 devices to use falcon mode Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 2/9] mach-k3: fix reading size and addr from fdt on R5 Anshul Dalal
@ 2025-04-28 14:12 ` Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 4/9] mach-k3: sysfw-loader: update img_hdr for falcon Anshul Dalal
` (5 subsequent siblings)
8 siblings, 0 replies; 20+ messages in thread
From: Anshul Dalal @ 2025-04-28 14:12 UTC (permalink / raw)
To: u-boot; +Cc: Anshul Dalal, vigneshr, trini, afd, m-chawdhry, n-francis, b-liu
This adds creation of tispl_falcon.bin for the am62a, 62p and 62x.
The contents are the same as the existing tispl.bin but A53's spl and
the fdt have been removed as they are not needed in falcon boot.
This reduces boot time since the payload size is smaller and we also
aren't authenticating the spl and fdt in secure boot.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
arch/arm/dts/k3-am625-sk-binman.dtsi | 64 ++++++++++++++++++++++++++++
arch/arm/dts/k3-am62a-sk-binman.dtsi | 64 ++++++++++++++++++++++++++++
arch/arm/dts/k3-am62p-sk-binman.dtsi | 51 ++++++++++++++++++++++
arch/arm/dts/k3-binman.dtsi | 54 +++++++++++++++++++++++
4 files changed, 233 insertions(+)
diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi b/arch/arm/dts/k3-am625-sk-binman.dtsi
index 534eb14795b..5ca1a4b28e8 100644
--- a/arch/arm/dts/k3-am625-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am625-sk-binman.dtsi
@@ -219,6 +219,70 @@
};
};
+ ti-falcon {
+ insert-template = <&ti_falcon_template>;
+
+ fit {
+ images {
+ tifsstub-hs {
+ description = "TIFSSTUB";
+ type = "firmware";
+ arch = "arm32";
+ compression = "none";
+ os = "tifsstub-hs";
+ load = <0x9dc00000>;
+ entry = <0x9dc00000>;
+ blob-ext {
+ filename = "tifsstub.bin_hs";
+ };
+ };
+ tifsstub-fs {
+ description = "TIFSSTUB";
+ type = "firmware";
+ arch = "arm32";
+ compression = "none";
+ os = "tifsstub-fs";
+ load = <0x9dc00000>;
+ entry = <0x9dc00000>;
+ blob-ext {
+ filename = "tifsstub.bin_fs";
+ };
+ };
+ tifsstub-gp {
+ description = "TIFSSTUB";
+ type = "firmware";
+ arch = "arm32";
+ compression = "none";
+ os = "tifsstub-gp";
+ load = <0x9dc00000>;
+ entry = <0x9dc00000>;
+ blob-ext {
+ filename = "tifsstub.bin_gp";
+ };
+ };
+ dm {
+ ti-secure {
+ content = <&dm_falcon>;
+ keyfile = "custMpk.pem";
+ };
+ dm_falcon: ti-dm {
+ filename = "ti-dm.bin";
+ };
+ };
+ };
+
+ configurations {
+ default = "conf-0";
+ conf-0 {
+ description = "k3-am625-sk-falcon";
+ firmware = "atf";
+ loadables = "tee", "tifsstub-hs", "tifsstub-fs",
+ "tifsstub-gp", "dm";
+ };
+ };
+ };
+ };
+
ti-spl {
insert-template = <&ti_spl_template>;
diff --git a/arch/arm/dts/k3-am62a-sk-binman.dtsi b/arch/arm/dts/k3-am62a-sk-binman.dtsi
index 2a8c260387b..bb1514c9d60 100644
--- a/arch/arm/dts/k3-am62a-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am62a-sk-binman.dtsi
@@ -211,6 +211,70 @@
};
};
+ ti-falcon {
+ insert-template = <&ti_falcon_template>;
+
+ fit {
+ images {
+ tifsstub-hs {
+ description = "TIFSSTUB";
+ type = "firmware";
+ arch = "arm32";
+ compression = "none";
+ os = "tifsstub-hs";
+ load = <0x9ca00000>;
+ entry = <0x9ca00000>;
+ blob-ext {
+ filename = "tifsstub.bin_hs";
+ };
+ };
+ tifsstub-fs {
+ description = "TIFSSTUB";
+ type = "firmware";
+ arch = "arm32";
+ compression = "none";
+ os = "tifsstub-fs";
+ load = <0x9ca00000>;
+ entry = <0x9ca00000>;
+ blob-ext {
+ filename = "tifsstub.bin_fs";
+ };
+ };
+ tifsstub-gp {
+ description = "TIFSSTUB";
+ type = "firmware";
+ arch = "arm32";
+ compression = "none";
+ os = "tifsstub-gp";
+ load = <0x9ca00000>;
+ entry = <0x9ca00000>;
+ blob-ext {
+ filename = "tifsstub.bin_gp";
+ };
+ };
+ dm {
+ ti-secure {
+ content = <&dm_falcon>;
+ keyfile = "custMpk.pem";
+ };
+ dm_falcon: ti-dm {
+ filename = "ti-dm.bin";
+ };
+ };
+ };
+
+ configurations {
+ default = "conf-0";
+ conf-0 {
+ description = "k3-am62a7-sk-falcon";
+ firmware = "atf";
+ loadables = "tee", "dm", "tifsstub-hs", "tifsstub-fs",
+ "tifsstub-gp";
+ };
+ };
+ };
+ };
+
ti-spl {
insert-template = <&ti_spl_template>;
diff --git a/arch/arm/dts/k3-am62p-sk-binman.dtsi b/arch/arm/dts/k3-am62p-sk-binman.dtsi
index 797644a7e0d..19c249bcfbc 100644
--- a/arch/arm/dts/k3-am62p-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am62p-sk-binman.dtsi
@@ -173,6 +173,57 @@
};
+ ti-falcon {
+ insert-template = <&ti_falcon_template>;
+
+ fit {
+ images {
+ tifsstub-hs {
+ description = "TIFSSTUB";
+ type = "firmware";
+ arch = "arm32";
+ compression = "none";
+ os = "tifsstub-hs";
+ load = <0x9ca00000>;
+ entry = <0x9ca00000>;
+ blob-ext {
+ filename = "tifsstub.bin_hs";
+ };
+ };
+ tifsstub-fs {
+ description = "TIFSSTUB";
+ type = "firmware";
+ arch = "arm32";
+ compression = "none";
+ os = "tifsstub-fs";
+ load = <0x9ca00000>;
+ entry = <0x9ca00000>;
+ blob-ext {
+ filename = "tifsstub.bin_fs";
+ };
+ };
+ dm {
+ ti-secure {
+ content = <&dm_falcon>;
+ keyfile = "custMpk.pem";
+ };
+ dm_falcon: ti-dm {
+ filename = "ti-dm.bin";
+ };
+ };
+ };
+
+ configurations {
+ default = "conf-0";
+ conf-0 {
+ description = "k3-am62p5-sk-falcon";
+ firmware = "atf";
+ loadables = "tee", "dm", "tifsstub-hs", "tifsstub-fs";
+ };
+ };
+ };
+ };
+
ti-spl {
insert-template = <&ti_spl_template>;
diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
index 5163161b94d..a678379dae9 100644
--- a/arch/arm/dts/k3-binman.dtsi
+++ b/arch/arm/dts/k3-binman.dtsi
@@ -489,6 +489,60 @@
end_address = <0x0 0x9fffffff>;
};
+ ti_falcon_template: template-9 {
+ filename = "tispl_falcon.bin";
+ pad-byte = <0xff>;
+
+ fit {
+ description = "Configuration without SPL and FDT";
+ #address-cells = <1>;
+
+ images {
+ atf {
+ description = "ARM Trusted Firmware";
+ type = "firmware";
+ arch = "arm64";
+ compression = "none";
+ os = "arm-trusted-firmware";
+ load = <CONFIG_K3_ATF_LOAD_ADDR>;
+ entry = <CONFIG_K3_ATF_LOAD_ADDR>;
+ ti-secure {
+ content = <&atf_falcon>;
+ keyfile = "custMpk.pem";
+ };
+ atf_falcon: atf-bl31 {
+ };
+ };
+ tee {
+ description = "OP-TEE";
+ type = "tee";
+ arch = "arm64";
+ compression = "none";
+ os = "tee";
+ load = <CONFIG_K3_OPTEE_LOAD_ADDR>;
+ entry = <CONFIG_K3_OPTEE_LOAD_ADDR>;
+ ti-secure {
+ content = <&tee_falcon>;
+ keyfile = "custMpk.pem";
+ };
+ tee_falcon: tee-os {
+ optional;
+ };
+ };
+ dm {
+ description = "DM binary";
+ type = "firmware";
+ arch = "arm32";
+ compression = "none";
+ os = "DM";
+ load = <0x89000000>;
+ entry = <0x89000000>;
+ };
+
+ };
+ };
+ };
+
};
#endif
--
2.49.0
^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PATCH v6 4/9] mach-k3: sysfw-loader: update img_hdr for falcon
2025-04-28 14:12 [PATCH v6 0/9] Add falcon support for am62a, 62p and 62x Anshul Dalal
` (2 preceding siblings ...)
2025-04-28 14:12 ` [PATCH v6 3/9] arch: arm: k3-binman: add fit for falcon boot Anshul Dalal
@ 2025-04-28 14:12 ` Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 5/9] config: add falcon boot config fragment for am62x Anshul Dalal
` (4 subsequent siblings)
8 siblings, 0 replies; 20+ messages in thread
From: Anshul Dalal @ 2025-04-28 14:12 UTC (permalink / raw)
To: u-boot; +Cc: Anshul Dalal, vigneshr, trini, afd, m-chawdhry, n-francis, b-liu
The returned legacy_img_hdr is used by booti_setup to compute the load
address for the kernel image.
This change ensures the kernel load address is CONFIG_SYS_LOAD_ADDR in
falcon boot.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
arch/arm/mach-k3/r5/sysfw-loader.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-k3/r5/sysfw-loader.c b/arch/arm/mach-k3/r5/sysfw-loader.c
index 188731e673d..19607606965 100644
--- a/arch/arm/mach-k3/r5/sysfw-loader.c
+++ b/arch/arm/mach-k3/r5/sysfw-loader.c
@@ -89,7 +89,11 @@ static void *sysfw_load_address;
struct legacy_img_hdr *spl_get_load_buffer(ssize_t offset, size_t size)
{
if (sysfw_loaded)
- return (struct legacy_img_hdr *)(CONFIG_TEXT_BASE + offset);
+ if (IS_ENABLED(CONFIG_SPL_OS_BOOT))
+ return (struct legacy_img_hdr *)CONFIG_SYS_LOAD_ADDR;
+ else
+ return (struct legacy_img_hdr *)(CONFIG_TEXT_BASE +
+ offset);
else if (sysfw_load_address)
return sysfw_load_address;
else
--
2.49.0
^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PATCH v6 5/9] config: add falcon boot config fragment for am62x
2025-04-28 14:12 [PATCH v6 0/9] Add falcon support for am62a, 62p and 62x Anshul Dalal
` (3 preceding siblings ...)
2025-04-28 14:12 ` [PATCH v6 4/9] mach-k3: sysfw-loader: update img_hdr for falcon Anshul Dalal
@ 2025-04-28 14:12 ` Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 6/9] board: ti: add default dtb for am62 in falcon mode Anshul Dalal
` (3 subsequent siblings)
8 siblings, 0 replies; 20+ messages in thread
From: Anshul Dalal @ 2025-04-28 14:12 UTC (permalink / raw)
To: u-boot; +Cc: Anshul Dalal, vigneshr, trini, afd, m-chawdhry, n-francis, b-liu
This fragment enables falcon boot for the am62x, 62a and 62p.
To have enough stack and heap space for loading kernel image as
FIT the memory map was modified by expanding stack + heap size, the
PRELOADED_BL33_BASE in ATF has to also be updated to 0x82000000 since
the kernel requires to be loaded at 2MiB aligned address along with
change changing K3_HW_CONFIG_BASE to 0x88000000 for the DT passed to
kernel.
Modified memory map for R5 SPL (modified addresses marked with *):
0x80000000 +-------------------------------+ Start of DDR
512KiB | ATF reserved memory space | CONFIG_K3_ATF_LOAD_ADDR*
0x80080000 +-------------------------------+
31.5MiB | Unused |
0x82000000 +-------------------------------+ PRELOADED_BL33_BASE* in ATF
| | CONFIG_SYS_LOAD_ADDR*
57MiB | Kernel + initramfs Image | CONFIG_SPL_LOAD_FIT_ADDRESS*
| |
0x85900000 +-------------------------------+
| |
| R5 U-Boot SPL Stack + Heap |
39MiB | (size defined by |
|SPL_STACK_R_MALLOC_SIMPLE_LEN*)|
| |
0x88000000 +-------------------------------+ CONFIG_SPL_STACK_R_ADDR*
| | K3_HW_CONFIG_BASE* in ATF
16MiB | Kernel DTB | CONFIG_SPL_PAYLOAD_ARGS_ADDR*
| |
0x89000000 +-------------------------------+
331MiB | Device Manager (DM) Load Addr |
0x9db00000 +-------------------------------+
12MiB | DM Reserved |
0x9e700000 +-------------------------------+
1MiB | Unused |
0x9e800000 +-------------------------------+ BL32_BASE in ATF
24MiB | OPTEE |
0xa0000000 +-------------------------------+ End of DDR (512MiB)
Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
configs/am62x_r5_falcon.config | 38 ++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
create mode 100644 configs/am62x_r5_falcon.config
diff --git a/configs/am62x_r5_falcon.config b/configs/am62x_r5_falcon.config
new file mode 100644
index 00000000000..c9bb8d68505
--- /dev/null
+++ b/configs/am62x_r5_falcon.config
@@ -0,0 +1,38 @@
+# Enable falcon mode
+CONFIG_SPL_OS_BOOT=y
+
+# We use envs for setting bootargs and optionally for `falcon_(image|args)_file`
+CONFIG_SPL_ENV_SUPPORT=y
+
+# Perform FDT fixups from SPL
+CONFIG_OF_SYSTEM_SETUP=y
+
+# Enabling this causes issues with EMMC FS boot,
+# When enabled the SPL tries to detect FS on boot[01] hw partition which fails
+# since we need the raw tiboot3.bin there for the board to boot instead
+CONFIG_SUPPORT_EMMC_BOOT=n
+
+# Used as the 2MiB aligned load address for kernel
+CONFIG_SYS_LOAD_ADDR=0x82000000
+CONFIG_SPL_PAYLOAD_ARGS_ADDR=0x88000000
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x82000000
+CONFIG_SPL_STACK_R_ADDR=0x88000000
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2700000
+
+# We use the rootfs (i.e partition 2) for booting which is ext4 not FAT
+CONFIG_SYS_MMCSD_FS_BOOT_PARTITION=2
+CONFIG_SPL_FS_EXT4=y
+CONFIG_SPL_FS_FAT=n
+
+# Loading tispl_falcon instead of tispl which has fdt and A53 spl saves time
+CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="boot/tispl_falcon.bin"
+CONFIG_SPL_FS_LOAD_KERNEL_NAME="boot/fitImage"
+
+# Disabled to save space on the spl
+CONFIG_TI_K3_NAVSS_UDMA=n
+
+# During SPI boot, kernel and args are loaded from the eMMC or SD and not SPI,
+# therefore we don't actually make use of these config values.
+CONFIG_SYS_SPI_KERNEL_OFFS=0
+CONFIG_SYS_SPI_ARGS_OFFS=0
+CONFIG_SYS_SPI_ARGS_SIZE=0
--
2.49.0
^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PATCH v6 6/9] board: ti: add default dtb for am62 in falcon mode
2025-04-28 14:12 [PATCH v6 0/9] Add falcon support for am62a, 62p and 62x Anshul Dalal
` (4 preceding siblings ...)
2025-04-28 14:12 ` [PATCH v6 5/9] config: add falcon boot config fragment for am62x Anshul Dalal
@ 2025-04-28 14:12 ` Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 7/9] mach-k3: common: enable falcon mode for 62 platform Anshul Dalal
` (2 subsequent siblings)
8 siblings, 0 replies; 20+ messages in thread
From: Anshul Dalal @ 2025-04-28 14:12 UTC (permalink / raw)
To: u-boot; +Cc: Anshul Dalal, vigneshr, trini, afd, m-chawdhry, n-francis, b-liu
The SPL_FS_LOAD_ARGS_NAME config is used for the arguments to the kernel
(dtb in our case) in falcon boot.
Setting it in board specific Kconfig allows us to reuse the same config
fragment 'am62x_r5_falcon.config' for all 3 platforms for enabling
falcon boot.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
board/ti/am62ax/Kconfig | 3 +++
board/ti/am62px/Kconfig | 3 +++
board/ti/am62x/Kconfig | 3 +++
3 files changed, 9 insertions(+)
diff --git a/board/ti/am62ax/Kconfig b/board/ti/am62ax/Kconfig
index 51e7b3e0eab..187e9e5c9cd 100644
--- a/board/ti/am62ax/Kconfig
+++ b/board/ti/am62ax/Kconfig
@@ -23,4 +23,7 @@ if TARGET_AM62A7_R5_EVM
config SPL_LDSCRIPT
default "arch/arm/mach-omap2/u-boot-spl.lds"
+config SPL_FS_LOAD_ARGS_NAME
+ default "boot/dtb/ti/k3-am62a7-sk.dtb"
+
endif
diff --git a/board/ti/am62px/Kconfig b/board/ti/am62px/Kconfig
index 9d95ffd9b29..5f7252d7b19 100644
--- a/board/ti/am62px/Kconfig
+++ b/board/ti/am62px/Kconfig
@@ -23,4 +23,7 @@ if TARGET_AM62P5_R5_EVM
config SPL_LDSCRIPT
default "arch/arm/mach-omap2/u-boot-spl.lds"
+config SPL_FS_LOAD_ARGS_NAME
+ default "boot/dtb/ti/k3-am62p5-sk.dtb"
+
endif
diff --git a/board/ti/am62x/Kconfig b/board/ti/am62x/Kconfig
index 610dacfdc08..1564913096c 100644
--- a/board/ti/am62x/Kconfig
+++ b/board/ti/am62x/Kconfig
@@ -32,6 +32,9 @@ config SYS_CONFIG_NAME
config SPL_LDSCRIPT
default "arch/arm/mach-omap2/u-boot-spl.lds"
+config SPL_FS_LOAD_ARGS_NAME
+ default "boot/dtb/ti/k3-am625-sk.dtb"
+
source "board/ti/common/Kconfig"
endif
--
2.49.0
^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PATCH v6 7/9] mach-k3: common: enable falcon mode for 62 platform
2025-04-28 14:12 [PATCH v6 0/9] Add falcon support for am62a, 62p and 62x Anshul Dalal
` (5 preceding siblings ...)
2025-04-28 14:12 ` [PATCH v6 6/9] board: ti: add default dtb for am62 in falcon mode Anshul Dalal
@ 2025-04-28 14:12 ` Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 8/9] Makefile: update tispl regex to also clean falcon spl Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 9/9] doc: ti: am62: add falcon mode documentation Anshul Dalal
8 siblings, 0 replies; 20+ messages in thread
From: Anshul Dalal @ 2025-04-28 14:12 UTC (permalink / raw)
To: u-boot; +Cc: Anshul Dalal, vigneshr, trini, afd, m-chawdhry, n-francis, b-liu
We use the spl_board_prepare_for_boot hook to call k3_falcon_prep which
is ran after tispl is loaded but before jump_to_image.
In here, we find the boot media and load the image just as std falcon
flow (since spl_start_uboot returns 0 now). Once the kernel and args are
loaded, we perform fdt fixups on the fdt accompanying the kernel (if
loaded as FIT) or the loaded up args and return.
Now when the flow goes to jump_to_image, we do the regular pre-jump
procedure and jump to ATF which jumps to the kernel directly since we
have already loaded the kernel and dtb at their respective addresses
(PRELOADED_BL33_BASE and K3_HW_CONFIG_BASE).
Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
arch/arm/mach-k3/common.c | 107 ++++++++++++++++++++++++++++++++++++++
1 file changed, 107 insertions(+)
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index fa8cd93d664..ad5ed92eb03 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -263,8 +263,115 @@ static __maybe_unused void k3_dma_remove(void)
pr_warn("DMA Device not found (err=%d)\n", rc);
}
+#if IS_ENABLED(CONFIG_SPL_OS_BOOT) && !IS_ENABLED(CONFIG_ARM64)
+static bool tispl_loaded;
+
+int spl_start_uboot(void)
+{
+ if (!tispl_loaded)
+ return 1;
+ return 0;
+}
+
+static int k3_falcon_fdt_fixup(void *fdt)
+{
+ struct disk_partition info;
+ struct blk_desc *dev_desc;
+ char bootmedia[32];
+ char bootpart[32];
+ char str[256];
+ int ret;
+
+ strcpy(bootmedia, env_get("boot"));
+ strcpy(bootpart, env_get("bootpart"));
+ ret = blk_get_device_part_str(bootmedia, bootpart, &dev_desc, &info, 0);
+ if (ret < 0)
+ printf("Failed to get part details for %s %s [%d]\n", bootmedia,
+ bootpart, ret);
+ sprintf(str, "console=%s root=PARTUUID=%s rootwait", env_get("console"),
+ info.uuid);
+
+ fdt_set_totalsize(fdt, fdt_totalsize(fdt) + CONFIG_SYS_FDT_PAD);
+ ret = fdt_find_and_setprop(fdt, "/chosen", "bootargs", str,
+ strlen(str) + 1, 1);
+ if (ret) {
+ printf("Could not set bootargs: %s\n", fdt_strerror(ret));
+ return ret;
+ }
+ debug("Set bootargs to: %s\n", str);
+
+#ifdef CONFIG_OF_BOARD_SETUP
+ ret = ft_board_setup(fdt, gd->bd);
+ if (ret) {
+ printf("Failed in board fdt fixups: %s\n", fdt_strerror(ret));
+ return ret;
+ }
+#endif
+
+#ifdef CONFIG_OF_SYSTEM_SETUP
+ ret = ft_system_setup(fdt, gd->bd);
+ if (ret) {
+ printf("Failed in system fdt fixups: %s\n", fdt_strerror(ret));
+ return ret;
+ }
+#endif
+
+ return 0;
+}
+
+static int k3_falcon_prep(void)
+{
+ struct spl_image_loader *loader, *drv;
+ struct spl_image_info kernel_image;
+ struct spl_boot_device bootdev;
+ int ret = -ENXIO, n_ents;
+ void *fdt;
+
+ tispl_loaded = true;
+ memset(&kernel_image, '\0', sizeof(kernel_image));
+ drv = ll_entry_start(struct spl_image_loader, spl_image_loader);
+ n_ents = ll_entry_count(struct spl_image_loader, spl_image_loader);
+ bootdev.boot_device = spl_boot_device();
+ if (bootdev.boot_device == BOOT_DEVICE_SPI) {
+ if (strcmp(env_get("mmcdev"), "1") == 0)
+ bootdev.boot_device = BOOT_DEVICE_MMC;
+ else
+ bootdev.boot_device = BOOT_DEVICE_EMMC;
+ }
+ bootdev.boot_device_name = NULL;
+
+ for (loader = drv; loader != drv + n_ents; loader++) {
+ if (bootdev.boot_device != loader->boot_device)
+ continue;
+ if (loader) {
+ printf("Loading falcon payload from %s\n",
+ spl_loader_name(loader));
+ ret = loader->load_image(&kernel_image, &bootdev);
+ if (ret)
+ continue;
+
+ fdt = spl_image_fdt_addr(&kernel_image);
+ if (!fdt)
+ fdt = (void *)CONFIG_SPL_PAYLOAD_ARGS_ADDR;
+ ret = k3_falcon_fdt_fixup(fdt);
+ if (ret) {
+ printf("Failed performing fdt fixups in falcon flow: [%d]\n",
+ ret);
+ return ret;
+ }
+ return 0;
+ }
+ }
+
+ return ret;
+}
+#endif
+
void spl_board_prepare_for_boot(void)
{
+#if IS_ENABLED(CONFIG_SPL_OS_BOOT) && !IS_ENABLED(CONFIG_ARM64)
+ k3_falcon_prep();
+#endif
#if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
dcache_disable();
#endif
--
2.49.0
^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PATCH v6 8/9] Makefile: update tispl regex to also clean falcon spl
2025-04-28 14:12 [PATCH v6 0/9] Add falcon support for am62a, 62p and 62x Anshul Dalal
` (6 preceding siblings ...)
2025-04-28 14:12 ` [PATCH v6 7/9] mach-k3: common: enable falcon mode for 62 platform Anshul Dalal
@ 2025-04-28 14:12 ` Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 9/9] doc: ti: am62: add falcon mode documentation Anshul Dalal
8 siblings, 0 replies; 20+ messages in thread
From: Anshul Dalal @ 2025-04-28 14:12 UTC (permalink / raw)
To: u-boot; +Cc: Anshul Dalal, vigneshr, trini, afd, m-chawdhry, n-francis, b-liu
Build for A53 on am62 platforms now generates tispl_falcon.bin alongside
tispl.bin, edit the regex for `make clean` so that both files are
removed.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index e83672b1823..1d8fa759141 100644
--- a/Makefile
+++ b/Makefile
@@ -2225,7 +2225,7 @@ CLEAN_FILES += include/autoconf.mk* include/bmp_logo.h include/bmp_logo_data.h \
include/config.h include/generated/env.* drivers/video/u_boot_logo.S \
tools/version.h u-boot* MLO* SPL System.map fit-dtb.blob* \
u-boot-ivt.img.log u-boot-dtb.imx.log SPL.log u-boot.imx.log \
- lpc32xx-* bl31.c bl31.elf bl31_*.bin image.map tispl.bin* \
+ lpc32xx-* bl31.c bl31.elf bl31_*.bin image.map tispl*.bin* \
idbloader.img flash.bin flash.log defconfig keep-syms-lto.c \
mkimage-out.spl.mkimage mkimage.spl.mkimage imx-boot.map \
itb.fit.fit itb.fit.itb itb.map spl.map mkimage-out.rom.mkimage \
--
2.49.0
^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PATCH v6 9/9] doc: ti: am62: add falcon mode documentation
2025-04-28 14:12 [PATCH v6 0/9] Add falcon support for am62a, 62p and 62x Anshul Dalal
` (7 preceding siblings ...)
2025-04-28 14:12 ` [PATCH v6 8/9] Makefile: update tispl regex to also clean falcon spl Anshul Dalal
@ 2025-04-28 14:12 ` Anshul Dalal
8 siblings, 0 replies; 20+ messages in thread
From: Anshul Dalal @ 2025-04-28 14:12 UTC (permalink / raw)
To: u-boot; +Cc: Anshul Dalal, vigneshr, trini, afd, m-chawdhry, n-francis, b-liu
This patch adds user documentation for falcon boot for am62 platforms.
The main section is added to am62x_sk.rst and other documents just
include the section. Steps to build falcon support, usage and the
modified R5 memory map have been documented.
Two svg images have also been added for reference, one for the modified
tispl_falcon.bin and other for the falcon specific fitImage format.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
doc/board/ti/am62ax_sk.rst | 7 +
doc/board/ti/am62px_sk.rst | 7 +
doc/board/ti/am62x_sk.rst | 290 ++++++++++++++++++
doc/board/ti/img/fitImage_falcon.svg | 180 +++++++++++
.../ti/img/tifsstub_dm_tispl_falcon.bin.svg | 285 +++++++++++++++++
5 files changed, 769 insertions(+)
create mode 100644 doc/board/ti/img/fitImage_falcon.svg
create mode 100644 doc/board/ti/img/tifsstub_dm_tispl_falcon.bin.svg
diff --git a/doc/board/ti/am62ax_sk.rst b/doc/board/ti/am62ax_sk.rst
index 262340ef59a..9830916e3e0 100644
--- a/doc/board/ti/am62ax_sk.rst
+++ b/doc/board/ti/am62ax_sk.rst
@@ -192,6 +192,13 @@ https://www.ti.com/lit/pdf/spruj16 under the `Boot Mode Pins` section.
For SW2 and SW1, the switch state in the "ON" position = 1.
+Falcon Mode
+-----------
+
+.. include:: am62x_sk.rst
+ :start-after: .. am62x_evm_falcon_mode_start
+ :end-before: .. am62x_evm_falcon_mode_end
+
Debugging U-Boot
----------------
diff --git a/doc/board/ti/am62px_sk.rst b/doc/board/ti/am62px_sk.rst
index 99bdc034869..74f6dafa238 100644
--- a/doc/board/ti/am62px_sk.rst
+++ b/doc/board/ti/am62px_sk.rst
@@ -290,6 +290,13 @@ https://www.ti.com/lit/pdf/spruj83 under the `Boot Mode Pins` section.
For SW2 and SW1, the switch state in the "ON" position = 1.
+Falcon Mode
+-----------
+
+.. include:: am62x_sk.rst
+ :start-after: .. am62x_evm_falcon_mode_start
+ :end-before: .. am62x_evm_falcon_mode_end
+
Debugging U-Boot
----------------
diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst
index dab2970a85c..cb84e662042 100644
--- a/doc/board/ti/am62x_sk.rst
+++ b/doc/board/ti/am62x_sk.rst
@@ -526,6 +526,296 @@ Next, based on NET_VCI_STRING string mentioned in respective defconfig file `tib
fetches `tispl.bin` and then `tispl.bin` fetches `u-boot.img` from TFTP server which
completes Ethernet boot on the device.
+Falcon Mode
+-----------
+
+.. am62x_evm_falcon_mode_start
+
+Falcon boot flow on am62 platforms bypasses the A-core SPL and u-boot with the
+overall boot flow as below:
+
+**Normal boot flow:**
+
+* R5 SPL -> ATF -> OP-TEE -> Cortex-A SPL -> U-Boot -> Kernel
+
+**With falcon mode:**
+
+* R5 SPL -> ATF -> OP-TEE -> Kernel
+
+Build Process
+^^^^^^^^^^^^^
+
+Enabling falcon mode requires re-building ATF, U-boot and the kernel fitImage
+as follows:
+
+0. Setup environment variables:
+"""""""""""""""""""""""""""""""
+
+Refer to the build procedure above for setting up the environment variables.
+
+1. Trusted Firmware-A:
+""""""""""""""""""""""
+
+The R5 SPL in falcon mode loads the kernel at ``0x82000000`` and the
+corresponding DTB at ``0x88000000``. Therefore ATF needs to be rebuild with
+changes to the respective addresses.
+
+.. prompt:: bash $
+
+ # Change load addresses for the kernel and DTB
+ export TFA_EXTRA_ARGS="PRELOADED_BL33_BASE=0x82000000 K3_HW_CONFIG_BASE=0x88000000"
+
+.. include:: ../ti/k3.rst
+ :start-after: .. k3_rst_include_start_build_steps_tfa
+ :end-before: .. k3_rst_include_end_build_steps_tfa
+
+2. U-Boot:
+""""""""""
+
+* **2.1 R5:**
+
+.. prompt:: bash $
+
+ # use the common falcon config fragment for am62 platforms
+ export $UBOOT_FALCON_CFG_FRAGMENTR="am62x_r5_falcon.config"
+ export UBOOT_CFG_CORTEXR="${UBOOT_CFG_CORTEXR} ${UBOOT_FALCON_CFG_FRAGMENTR}"
+
+.. include:: ../ti/k3.rst
+ :start-after: .. k3_rst_include_start_build_steps_spl_r5
+ :end-before: .. k3_rst_include_end_build_steps_spl_r5
+
+* **2.2 A53:**
+
+After rebuilding ATF, the binary needs to be repackaged inside the tispl
+binaries:
+
+.. include:: ../ti/k3.rst
+ :start-after: .. k3_rst_include_start_build_steps_uboot
+ :end-before: .. k3_rst_include_end_build_steps_uboot
+
+3. fitImage:
+""""""""""""
+
+.. warning::
+
+ The ``fitImage`` available by default under ``boot/fitImage`` in rootfs of
+ the standard SDK release is not compatible with falcon mode.
+
+For secure boot in falcon mode, the compute heavy authentication required for
+the ``fitImage`` is offloaded from the slower R5 core to TIFS. This requires
+``fitImage`` to package the necessary binaries (kernel and dtb) with a
+pre-signed x509 certificate.
+
+**fitImage for falcon mode:**
+
+.. image:: img/fitImage_falcon.svg
+ :alt: fitImage for falcon boot image format
+
+* **Sources**
+
+ * **Core Secdev K3**
+
+ | **source:** https://git.ti.com/cgit/security-development-tools/core-secdev-k3
+ | **branch:** master
+
+**Follow the steps below to create a falcon compatible fitImage:**
+
+**3.1 Environment setup**
+
+.. prompt:: bash $
+
+ export DTB=path/to/dtb
+ export IMAGE=path/to/kernel-image
+
+**3.2 fitImage creation**
+
+ An Image tree source (*its*) file describes the structure and contents of the
+ final image produced by the mkimage tool.
+
+ To create the ``fitImage`` for falcon mode, create a file ``fitImage.its``
+ with the following contents inside the ``core-secdev-k3`` source directory,:
+
+.. code-block:: dts
+
+ /dts-v1/;
+
+ / {
+ description = "Kernel fitImage for falcon mode";
+ #address-cells = <1>;
+
+ images {
+ kernel-1 {
+ description = "Linux kernel";
+ data = /incbin/("Image.sec");
+ type = "kernel";
+ arch = "arm64";
+ os = "linux";
+ compression = "none";
+ load = <0x82000000>;
+ entry = <0x82000000>;
+ };
+ falcon.dtb {
+ description = "Flattened Device Tree blob";
+ data = /incbin/("falcon.dtb.sec");
+ type = "flat_dt";
+ arch = "arm64";
+ compression = "none";
+ load = <0x88000000>;
+ entry = <0x88000000>;
+ };
+ };
+
+ configurations {
+ default = "conf-falcon";
+ conf-falcon {
+ description = "Pre-signed Kernel and DTB";
+ kernel = "kernel-1";
+ fdt = "falcon.dtb";
+ };
+ };
+ };
+
+Sign the kernel and dtb using ``secure-binary-image.sh`` and create the
+``fitImage`` using mkimage:
+
+.. prompt:: bash $
+
+ # inside core-secdev-k3 source
+ cp $IMAGE Image
+ cp $DTB falcon.dtb
+ ./scripts/secure-binary-image.sh Image Image.sec
+ ./scripts/secure-binary-image.sh falcon.dtb falcon.dtb.sec
+ mkimage -f fitImage.its fitImage
+
+Usage
+^^^^^
+
+Falcon mode makes use of a cut down variant of the tispl binary called
+``tispl_falcon.bin`` with the Cortex-A SPL and it's corresponding DTBs removed.
+This file should be present alongside the existing ``tispl.bin`` after building
+U-Boot for the Cortex-A cores.
+
+- **tispl_falcon.bin**
+
+.. image:: img/tifsstub_dm_tispl_falcon.bin.svg
+ :alt: tispl_falcon.bin image format
+
+1. eMMC/SD Boot:
+""""""""""""""""
+
+Falcon mode for K3 devices only supports SD and eMMC in FS boot. The R5 SPL
+once loaded from the ``tiboot3.bin`` file from the boot partition looks for
+``tispl_falcon.bin``, the DTB and fitImage (or kernel image for unauthenticated
+boot) inside the boot directory of the second partition (rootfs).
+
+.. list-table::
+ :widths: 8 8 8 25
+ :header-rows: 1
+
+ * - File
+ - Copy path on SD/eMMC
+ - Partition
+ - Description
+
+ * - ``tiboot3.bin``
+ - ``/tiboot3.bin``
+ - boot (fat)
+ - R5 SPL with falcon support
+
+ * - ``tispl_falcon.bin``
+ - ``/boot/tispl_falcon.bin``
+ - rootfs (ext4)
+ - tispl binary without SPL for the A core and DTB
+
+ * - ``fitImage``
+ - ``/boot/fitImage``
+ - rootfs (ext4)
+ - kernel and dtb fitImage with pre-signed binaries
+
+2. OSPI Boot:
+"""""""""""""
+
+For OSPI boot, the ``tiboot3.bin`` and ``tispl_falcon.bin`` files should be
+flashed to the same addresses in flash as regular boot flow but the DTB and the
+fitImage (or kernel image for unauthenticated boot) are read from the rootfs's
+boot directory.
+
+Below commands can be used to download ``tiboot3.bin`` and ``tispl_falcon.bin``
+over tftp and then flash those to OSPI at their respective addresses.
+
+.. prompt:: bash =>
+
+ sf probe
+ tftp ${loadaddr} tiboot3.bin
+ sf update $loadaddr 0x0 $filesize
+ tftp ${loadaddr} tispl_falcon.bin
+ sf update $loadaddr 0x80000 $filesize
+
+R5 SPL Memory Map:
+^^^^^^^^^^^^^^^^^^
+
+Standard boot:
+""""""""""""""
+
+.. code-block::
+
+ 0x80000000 +-------------------------------+ Start of DDR
+ 512KiB | ATF reserved memory space | CONFIG_K3_ATF_LOAD_ADDR
+ | |
+ 0x80080000 +-------------------------------+ PRELOADED_BL33_BASE in ATF
+ 29.5MiB | A53 SPL + DTB + | CONFIG_SPL_LOAD_FIT_ADDRESS
+ | Download region for FIT in DFU|
+ 0x81e00000 +-------------------------------+
+ | R5 U-Boot SPL Stack + Heap |
+ 2MiB | (size defined by |
+ | SPL_STACK_R_MALLOC_SIMPLE_LEN)|
+ 0x82000000 +-------------------------------+ CONFIG_SPL_STACK_R_ADDR
+ 112MiB | Unused |
+ 0x89000000 +-------------------------------+
+ 331MiB | Device Manager (DM) Load Addr |
+ 0x9db00000 +-------------------------------+
+ 12MiB | DM Reserved |
+ 0x9e700000 +-------------------------------+
+ 1MiB | Unused |
+ 0x9e800000 +-------------------------------+ BL32_BASE in ATF
+ 24MiB | OPTEE |
+ 0xa0000000 +-------------------------------+ End of DDR (512MiB)
+
+Falcon mode:
+""""""""""""
+
+.. code-block::
+
+ 0x80000000 +-------------------------------+ Start of DDR
+ 512KiB | ATF reserved memory space | CONFIG_K3_ATF_LOAD_ADDR
+ 0x80080000 +-------------------------------+
+ 31.5MiB | Unused |
+ 0x82000000 +-------------------------------+ PRELOADED_BL33_BASE in ATF
+ | | CONFIG_SYS_LOAD_ADDR
+ 57MiB | Kernel + initramfs Image | CONFIG_SPL_LOAD_FIT_ADDRESS
+ | |
+ 0x85900000 +-------------------------------+
+ | |
+ | R5 U-Boot SPL Stack + Heap |
+ 39MiB | (size defined by |
+ | SPL_STACK_R_MALLOC_SIMPLE_LEN)|
+ | |
+ 0x88000000 +-------------------------------+ CONFIG_SPL_STACK_R_ADDR
+ | | K3_HW_CONFIG_BASE in ATF
+ 16MiB | Kernel DTB | CONFIG_SPL_PAYLOAD_ARGS_ADDR
+ | |
+ 0x89000000 +-------------------------------+
+ 331MiB | Device Manager (DM) Load Addr |
+ 0x9db00000 +-------------------------------+
+ 12MiB | DM Reserved |
+ 0x9e700000 +-------------------------------+
+ 1MiB | Unused |
+ 0x9e800000 +-------------------------------+ BL32_BASE in ATF
+ 24MiB | OPTEE |
+ 0xa0000000 +-------------------------------+ End of DDR (512MiB)
+
+.. am62x_evm_falcon_mode_end
+
Debugging U-Boot
----------------
diff --git a/doc/board/ti/img/fitImage_falcon.svg b/doc/board/ti/img/fitImage_falcon.svg
new file mode 100644
index 00000000000..a22e0f6564e
--- /dev/null
+++ b/doc/board/ti/img/fitImage_falcon.svg
@@ -0,0 +1,180 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause -->
+
+<!-- Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/ -->
+
+<svg
+ version="1.1"
+ width="231"
+ height="220"
+ viewBox="-0.5 -0.5 231 220"
+ id="svg72"
+ sodipodi:docname="fitImage_falcon.svg"
+ inkscape:version="1.4.1 (93de688d07, 2025-03-30)"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:svg="http://www.w3.org/2000/svg">
+ <sodipodi:namedview
+ id="namedview74"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ inkscape:pageshadow="2"
+ inkscape:pageopacity="0.0"
+ inkscape:pagecheckerboard="0"
+ showgrid="false"
+ inkscape:zoom="2.9"
+ inkscape:cx="83.62069"
+ inkscape:cy="131.72414"
+ inkscape:window-width="1918"
+ inkscape:window-height="1078"
+ inkscape:window-x="0"
+ inkscape:window-y="0"
+ inkscape:window-maximized="0"
+ inkscape:current-layer="g62"
+ inkscape:showpageshadow="2"
+ inkscape:deskcolor="#d1d1d1" />
+ <defs
+ id="defs2">
+ <inkscape:perspective
+ sodipodi:type="inkscape:persp3d"
+ inkscape:vp_x="0 : 104.5 : 1"
+ inkscape:vp_y="0 : 1000 : 0"
+ inkscape:vp_z="231 : 104.5 : 1"
+ inkscape:persp3d-origin="115.5 : 46 : 1"
+ id="perspective1" />
+ </defs>
+ <g
+ id="g62">
+ <rect
+ x="-0.06279549"
+ y="-0.062792346"
+ width="230.12561"
+ height="219.12558"
+ rx="34.518837"
+ ry="27.33382"
+ fill="#d5e8d4"
+ stroke="#82b366"
+ pointer-events="all"
+ id="rect4"
+ style="display:inline;fill:#dbe4f4;fill-opacity:1;stroke:#8166b3;stroke-width:0.888796;stroke-dasharray:none;stroke-opacity:1" />
+ <text
+ x="115.15599"
+ y="156.49472"
+ fill="#000000"
+ font-family="Helvetica"
+ font-size="12px"
+ text-anchor="middle"
+ id="text8-8-7-6-6"
+ style="display:inline"
+ inkscape:label="x509 cert">x509 Certificate</text>
+ <text
+ x="115.15598"
+ y="85.615631"
+ fill="#000000"
+ font-family="Helvetica"
+ font-size="12px"
+ text-anchor="middle"
+ id="text8-8-7-6-6-1"
+ style="display:inline"
+ inkscape:label="x509 cert">x509 Certificate</text>
+ <text
+ x="114.532"
+ y="42.263863"
+ fill="#000000"
+ font-family="Helvetica"
+ font-size="12px"
+ text-anchor="middle"
+ id="text8-8-7-6-6-5"
+ style="display:inline"
+ inkscape:label="x509 cert">Fit Header</text>
+ <text
+ x="114.78398"
+ y="106.884"
+ fill="#000000"
+ font-family="Helvetica"
+ font-size="12px"
+ text-anchor="middle"
+ id="text8-8-7-6-6-5-5"
+ style="display:inline"
+ inkscape:label="x509 cert">Kernel Image</text>
+ <rect
+ style="display:none;fill:#000000;fill-opacity:0;stroke:#000000;stroke-width:1.00157;stroke-dasharray:none;stroke-opacity:1"
+ id="rect1"
+ width="171.46796"
+ height="210.89911"
+ x="36.799908"
+ y="21.652758"
+ transform="translate(-7.533886,15.237117)" />
+ <text
+ xml:space="preserve"
+ style="font-size:21.3333px;text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#db8c8c;fill-opacity:1;stroke:#000000;stroke-width:1.13386"
+ x="90.327087"
+ y="177.15775"
+ id="text1"><tspan
+ sodipodi:role="line"
+ id="tspan1"
+ x="90.327087"
+ y="177.15775" /></text>
+ <text
+ xml:space="preserve"
+ style="font-size:21.3333px;text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#db8c8c;fill-opacity:1;stroke:#000000;stroke-width:1.13386"
+ x="106.45526"
+ y="214.93161"
+ id="text2"><tspan
+ sodipodi:role="line"
+ id="tspan2"
+ x="106.45526"
+ y="214.93161" /></text>
+ <g
+ id="g62-6"
+ transform="translate(-5.6022949,-9.676433)">
+ <text
+ x="120.33229"
+ y="188.7475"
+ fill="#000000"
+ font-family="Helvetica"
+ font-size="12px"
+ text-anchor="middle"
+ id="text8-8-7-6-6-5-2"
+ style="display:inline"
+ inkscape:label="x509 cert">DTB</text>
+ </g>
+ <rect
+ style="fill:#db8c8c;fill-opacity:0;stroke:#000000;stroke-width:1.13386"
+ id="rect2"
+ width="82.644012"
+ height="17.6518"
+ x="73.677986"
+ y="94.992081" />
+ <rect
+ style="fill:#db8c8c;fill-opacity:0;stroke:#000000;stroke-width:1.13386;stroke-dasharray:none"
+ id="rect2-7"
+ width="32.336376"
+ height="18.068098"
+ x="98.83181"
+ y="165.66302" />
+ <rect
+ style="fill:#db8c8c;fill-opacity:0;stroke:#000000;stroke-width:1.77036;stroke-dasharray:none"
+ id="rect3"
+ width="152.43475"
+ height="70.500725"
+ x="38.782627"
+ y="127.54861" />
+ <rect
+ style="fill:#db8c8c;fill-opacity:0;stroke:#000000;stroke-width:1.77036;stroke-dasharray:none"
+ id="rect3-9"
+ width="152.43475"
+ height="70.500732"
+ x="38.782623"
+ y="56.777336" />
+ <rect
+ style="fill:#db8c8c;fill-opacity:0;stroke:#000000;stroke-width:1.78506;stroke-dasharray:none"
+ id="rect5"
+ width="152.41736"
+ height="36.60006"
+ x="38.791306"
+ y="20.211617" />
+ </g>
+</svg>
diff --git a/doc/board/ti/img/tifsstub_dm_tispl_falcon.bin.svg b/doc/board/ti/img/tifsstub_dm_tispl_falcon.bin.svg
new file mode 100644
index 00000000000..7e2793c2ed9
--- /dev/null
+++ b/doc/board/ti/img/tifsstub_dm_tispl_falcon.bin.svg
@@ -0,0 +1,285 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause -->
+
+<!-- Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/ -->
+
+<svg
+ version="1.1"
+ width="231"
+ height="280"
+ viewBox="-0.5 -0.5 231 280"
+ id="svg72"
+ sodipodi:docname="tifsstub_dm_tispl_falcon.bin.svg"
+ inkscape:version="1.4.1 (93de688d07, 2025-03-30)"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns:xhtml="http://www.w3.org/1999/xhtml">
+ <sodipodi:namedview
+ id="namedview74"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ inkscape:pageshadow="2"
+ inkscape:pageopacity="0.0"
+ inkscape:pagecheckerboard="0"
+ showgrid="false"
+ inkscape:zoom="2.3561254"
+ inkscape:cx="175.5"
+ inkscape:cy="151.30774"
+ inkscape:window-width="1920"
+ inkscape:window-height="1080"
+ inkscape:window-x="0"
+ inkscape:window-y="0"
+ inkscape:window-maximized="0"
+ inkscape:current-layer="g62"
+ inkscape:showpageshadow="2"
+ inkscape:deskcolor="#d1d1d1" />
+ <defs
+ id="defs2">
+ <inkscape:perspective
+ sodipodi:type="inkscape:persp3d"
+ inkscape:vp_x="0 : 104.5 : 1"
+ inkscape:vp_y="0 : 1000 : 0"
+ inkscape:vp_z="231 : 104.5 : 1"
+ inkscape:persp3d-origin="115.5 : 46 : 1"
+ id="perspective1" />
+ </defs>
+ <g
+ id="g62">
+ <rect
+ x="-0.0064085587"
+ y="-0.0064054145"
+ width="230.01283"
+ height="278.39682"
+ rx="34.501923"
+ ry="34.727341"
+ fill="#d5e8d4"
+ stroke="#82b366"
+ pointer-events="all"
+ id="rect4"
+ style="stroke-width:1.00331" />
+ <rect
+ x="40"
+ y="30"
+ width="160"
+ height="60"
+ fill="none"
+ stroke="#000000"
+ pointer-events="all"
+ id="rect6" />
+ <g
+ transform="translate(-0.5,-0.5)"
+ id="g12">
+ <switch
+ id="switch10">
+ <foreignObject
+ style="overflow: visible; text-align: left;"
+ pointer-events="none"
+ width="100%"
+ height="100%"
+ requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
+ <xhtml:div
+ style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 158px; height: 1px; padding-top: 60px; margin-left: 41px;">
+ <xhtml:div
+ style="box-sizing: border-box; font-size: 0px; text-align: center;"
+ data-drawio-colors="color: rgb(0, 0, 0); ">
+ <xhtml:div
+ style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">FIT Header</xhtml:div>
+ </xhtml:div>
+ </xhtml:div>
+ </foreignObject>
+ <text
+ x="120"
+ y="64"
+ fill="#000000"
+ font-family="Helvetica"
+ font-size="12px"
+ text-anchor="middle"
+ id="text8">FIT Header</text>
+ </switch>
+ </g>
+ <rect
+ x="40"
+ y="160"
+ width="160"
+ height="50"
+ fill="none"
+ stroke="#000000"
+ pointer-events="all"
+ id="rect14" />
+ <g
+ transform="translate(-0.5,-0.5)"
+ id="g20">
+ <switch
+ id="switch18">
+ <foreignObject
+ style="overflow: visible; text-align: left;"
+ pointer-events="none"
+ width="100%"
+ height="100%"
+ requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
+ <xhtml:div
+ style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 158px; height: 1px; padding-top: 185px; margin-left: 41px;">
+ <xhtml:div
+ style="box-sizing: border-box; font-size: 0px; text-align: center;"
+ data-drawio-colors="color: rgb(0, 0, 0); ">
+ <xhtml:div
+ style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">TIFS Stub<xhtml:br />
+
+(GP, HS-FS, HS-SE)</xhtml:div>
+ </xhtml:div>
+ </xhtml:div>
+ </foreignObject>
+ <text
+ x="120"
+ y="189"
+ fill="#000000"
+ font-family="Helvetica"
+ font-size="12px"
+ text-anchor="middle"
+ id="text16">TIFS Stub...</text>
+ </switch>
+ </g>
+ <rect
+ x="40"
+ y="90"
+ width="160"
+ height="30"
+ fill="none"
+ stroke="#000000"
+ pointer-events="all"
+ id="rect22" />
+ <g
+ transform="translate(-0.5,-0.5)"
+ id="g28">
+ <switch
+ id="switch26">
+ <foreignObject
+ style="overflow: visible; text-align: left;"
+ pointer-events="none"
+ width="100%"
+ height="100%"
+ requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
+ <xhtml:div
+ style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 158px; height: 1px; padding-top: 105px; margin-left: 41px;">
+ <xhtml:div
+ style="box-sizing: border-box; font-size: 0px; text-align: center;"
+ data-drawio-colors="color: rgb(0, 0, 0); ">
+ <xhtml:div
+ style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">TF-A</xhtml:div>
+ </xhtml:div>
+ </xhtml:div>
+ </foreignObject>
+ <text
+ x="120"
+ y="109"
+ fill="#000000"
+ font-family="Helvetica"
+ font-size="12px"
+ text-anchor="middle"
+ id="text24">TF-A</text>
+ </switch>
+ </g>
+ <rect
+ x="40"
+ y="120"
+ width="160"
+ height="40"
+ fill="none"
+ stroke="#000000"
+ pointer-events="all"
+ id="rect30" />
+ <g
+ transform="translate(-0.5,-0.5)"
+ id="g36">
+ <switch
+ id="switch34">
+ <foreignObject
+ style="overflow: visible; text-align: left;"
+ pointer-events="none"
+ width="100%"
+ height="100%"
+ requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
+ <xhtml:div
+ style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 158px; height: 1px; padding-top: 140px; margin-left: 41px;">
+ <xhtml:div
+ style="box-sizing: border-box; font-size: 0px; text-align: center;"
+ data-drawio-colors="color: rgb(0, 0, 0); ">
+ <xhtml:div
+ style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">OP-TEE</xhtml:div>
+ </xhtml:div>
+ </xhtml:div>
+ </foreignObject>
+ <text
+ x="120"
+ y="144"
+ fill="#000000"
+ font-family="Helvetica"
+ font-size="12px"
+ text-anchor="middle"
+ id="text32">OP-TEE</text>
+ </switch>
+ </g>
+ <rect
+ x="40"
+ y="210"
+ width="160"
+ height="40"
+ fill="none"
+ stroke="#000000"
+ pointer-events="all"
+ id="rect38" />
+ <g
+ transform="translate(-0.5,-0.5)"
+ id="g44">
+ <switch
+ id="switch42">
+ <foreignObject
+ style="overflow: visible; text-align: left;"
+ pointer-events="none"
+ width="100%"
+ height="100%"
+ requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
+ <xhtml:div
+ style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 158px; height: 1px; padding-top: 230px; margin-left: 41px;">
+ <xhtml:div
+ style="box-sizing: border-box; font-size: 0px; text-align: center;"
+ data-drawio-colors="color: rgb(0, 0, 0); ">
+ <xhtml:div
+ style="display: inline-block; font-size: 12px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">R5 DM FW</xhtml:div>
+ </xhtml:div>
+ </xhtml:div>
+ </foreignObject>
+ <text
+ x="120"
+ y="234"
+ fill="#000000"
+ font-family="Helvetica"
+ font-size="12px"
+ text-anchor="middle"
+ id="text40">R5 DM FW</text>
+ </switch>
+ </g>
+ </g>
+ <switch
+ id="switch70">
+ <g
+ requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"
+ id="g64" />
+ <a
+ transform="translate(0,-5)"
+ xlink:href="https://www.drawio.com/doc/faq/svg-export-text-problems"
+ target="_blank"
+ id="a68">
+ <text
+ text-anchor="middle"
+ font-size="10px"
+ x="50%"
+ y="100%"
+ id="text66">Text is not SVG - cannot display</text>
+ </a>
+ </switch>
+</svg>
--
2.49.0
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH v6 1/9] spl: Kconfig: allow K3 devices to use falcon mode
2025-04-28 14:12 ` [PATCH v6 1/9] spl: Kconfig: allow K3 devices to use falcon mode Anshul Dalal
@ 2025-05-06 14:33 ` Andrew Davis
2025-05-07 3:33 ` Anshul Dalal
0 siblings, 1 reply; 20+ messages in thread
From: Andrew Davis @ 2025-05-06 14:33 UTC (permalink / raw)
To: Anshul Dalal, u-boot; +Cc: vigneshr, trini, m-chawdhry, n-francis, b-liu
On 4/28/25 9:12 AM, Anshul Dalal wrote:
> Falcon mode was disabled for TI_SECURE_DEVICE at commit e95b9b4437bc
> ("ti_armv7_common: Disable Falcon Mode on HS devices") for older 32-bit
> HS devices and can be enabled on K3 devices.
>
> For secure boot, the kernel with x509 headers can be packaged in a fit
"can be", this is the issue. Security is not just allowing methods that
are security checked, but forcing the use of such methods. Setting
OS_BOOT opens up several paths that look for non-FIT images. These
images do not enforce authentication like FIT does. This means one can
bypass secure boot when OS_BOOT is enabled by simply placing a non-FIT
boot image on the boot media.
Andrew
> container (fitImage) signed with TIFS keys for authentication.
>
> Signed-off-by: Anshul Dalal <anshuld@ti.com>
> ---
> common/spl/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index c08045f9c8d..68e900e9b91 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -1165,7 +1165,7 @@ config SPL_ONENAND_SUPPORT
>
> config SPL_OS_BOOT
> bool "Activate Falcon Mode"
> - depends on !TI_SECURE_DEVICE
> + depends on !TI_SECURE_DEVICE || ARCH_K3
> help
> Enable booting directly to an OS from SPL.
> for more info read doc/README.falcon
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v6 1/9] spl: Kconfig: allow K3 devices to use falcon mode
2025-05-06 14:33 ` Andrew Davis
@ 2025-05-07 3:33 ` Anshul Dalal
2025-05-07 18:06 ` Andrew Davis
0 siblings, 1 reply; 20+ messages in thread
From: Anshul Dalal @ 2025-05-07 3:33 UTC (permalink / raw)
To: Andrew Davis, u-boot; +Cc: vigneshr, trini, m-chawdhry, n-francis, b-liu
On Tue May 6, 2025 at 8:03 PM IST, Andrew Davis wrote:
> On 4/28/25 9:12 AM, Anshul Dalal wrote:
>> Falcon mode was disabled for TI_SECURE_DEVICE at commit e95b9b4437bc
>> ("ti_armv7_common: Disable Falcon Mode on HS devices") for older 32-bit
>> HS devices and can be enabled on K3 devices.
>>
>> For secure boot, the kernel with x509 headers can be packaged in a fit
>
> "can be", this is the issue. Security is not just allowing methods that
> are security checked, but forcing the use of such methods. Setting
> OS_BOOT opens up several paths that look for non-FIT images. These
> images do not enforce authentication like FIT does. This means one can
> bypass secure boot when OS_BOOT is enabled by simply placing a non-FIT
> boot image on the boot media.
>
As per spl_load_image_ext_os, the SPL first tries to load the file set
in falcon_args_file env variable but since it's not set in our case. And
the only way to set them is by rebuilding u-boot as uEnv.txt is not
supported at SPL stage.
This means the SPL only loads CONFIG_SPL_FS_LOAD_ARGS_NAME and
CONFIG_SPL_FS_LOAD_KERNEL_NAME which are set as the DTB and fitImage
respectively. Following that, authentication is enforced during FIT
loading by the call to board_fit_image_post_process in load_simple_fit.
So even if the fitImage was modified, boot would fail without valid
signatures on HS-SE devices.
- Anshul
>> container (fitImage) signed with TIFS keys for authentication.
>>
>> Signed-off-by: Anshul Dalal <anshuld@ti.com>
>> ---
>> common/spl/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
>> index c08045f9c8d..68e900e9b91 100644
>> --- a/common/spl/Kconfig
>> +++ b/common/spl/Kconfig
>> @@ -1165,7 +1165,7 @@ config SPL_ONENAND_SUPPORT
>>
>> config SPL_OS_BOOT
>> bool "Activate Falcon Mode"
>> - depends on !TI_SECURE_DEVICE
>> + depends on !TI_SECURE_DEVICE || ARCH_K3
>> help
>> Enable booting directly to an OS from SPL.
>> for more info read doc/README.falcon
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v6 1/9] spl: Kconfig: allow K3 devices to use falcon mode
2025-05-07 3:33 ` Anshul Dalal
@ 2025-05-07 18:06 ` Andrew Davis
2025-05-08 3:12 ` Anshul Dalal
0 siblings, 1 reply; 20+ messages in thread
From: Andrew Davis @ 2025-05-07 18:06 UTC (permalink / raw)
To: Anshul Dalal, u-boot; +Cc: vigneshr, trini, m-chawdhry, n-francis, b-liu
On 5/6/25 10:33 PM, Anshul Dalal wrote:
> On Tue May 6, 2025 at 8:03 PM IST, Andrew Davis wrote:
>> On 4/28/25 9:12 AM, Anshul Dalal wrote:
>>> Falcon mode was disabled for TI_SECURE_DEVICE at commit e95b9b4437bc
>>> ("ti_armv7_common: Disable Falcon Mode on HS devices") for older 32-bit
>>> HS devices and can be enabled on K3 devices.
>>>
>>> For secure boot, the kernel with x509 headers can be packaged in a fit
>>
>> "can be", this is the issue. Security is not just allowing methods that
>> are security checked, but forcing the use of such methods. Setting
>> OS_BOOT opens up several paths that look for non-FIT images. These
>> images do not enforce authentication like FIT does. This means one can
>> bypass secure boot when OS_BOOT is enabled by simply placing a non-FIT
>> boot image on the boot media.
>>
>
> As per spl_load_image_ext_os, the SPL first tries to load the file set
> in falcon_args_file env variable but since it's not set in our case. And
> the only way to set them is by rebuilding u-boot as uEnv.txt is not
> supported at SPL stage.
>
> This means the SPL only loads CONFIG_SPL_FS_LOAD_ARGS_NAME and
> CONFIG_SPL_FS_LOAD_KERNEL_NAME which are set as the DTB and fitImage
What is stopping me from replacing the content of the file "fitImage"
with a normal kernel image? When loading that image the file type
will be detected as a normal kernel image and all FIT logic bypassed,
including authentication, breaking our secure chain of trust.
Andrew
> respectively. Following that, authentication is enforced during FIT
> loading by the call to board_fit_image_post_process in load_simple_fit.
>
> So even if the fitImage was modified, boot would fail without valid
> signatures on HS-SE devices.
>
> - Anshul
>
>>> container (fitImage) signed with TIFS keys for authentication.
>>>
>>> Signed-off-by: Anshul Dalal <anshuld@ti.com>
>>> ---
>>> common/spl/Kconfig | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
>>> index c08045f9c8d..68e900e9b91 100644
>>> --- a/common/spl/Kconfig
>>> +++ b/common/spl/Kconfig
>>> @@ -1165,7 +1165,7 @@ config SPL_ONENAND_SUPPORT
>>>
>>> config SPL_OS_BOOT
>>> bool "Activate Falcon Mode"
>>> - depends on !TI_SECURE_DEVICE
>>> + depends on !TI_SECURE_DEVICE || ARCH_K3
>>> help
>>> Enable booting directly to an OS from SPL.
>>> for more info read doc/README.falcon
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v6 1/9] spl: Kconfig: allow K3 devices to use falcon mode
2025-05-07 18:06 ` Andrew Davis
@ 2025-05-08 3:12 ` Anshul Dalal
2025-05-08 4:02 ` Raghavendra, Vignesh
0 siblings, 1 reply; 20+ messages in thread
From: Anshul Dalal @ 2025-05-08 3:12 UTC (permalink / raw)
To: Andrew Davis, u-boot; +Cc: vigneshr, trini, m-chawdhry, n-francis, b-liu
On Wed May 7, 2025 at 11:36 PM IST, Andrew Davis wrote:
> On 5/6/25 10:33 PM, Anshul Dalal wrote:
>> On Tue May 6, 2025 at 8:03 PM IST, Andrew Davis wrote:
>>> On 4/28/25 9:12 AM, Anshul Dalal wrote:
>>>> Falcon mode was disabled for TI_SECURE_DEVICE at commit e95b9b4437bc
>>>> ("ti_armv7_common: Disable Falcon Mode on HS devices") for older 32-bit
>>>> HS devices and can be enabled on K3 devices.
>>>>
>>>> For secure boot, the kernel with x509 headers can be packaged in a fit
>>>
>>> "can be", this is the issue. Security is not just allowing methods that
>>> are security checked, but forcing the use of such methods. Setting
>>> OS_BOOT opens up several paths that look for non-FIT images. These
>>> images do not enforce authentication like FIT does. This means one can
>>> bypass secure boot when OS_BOOT is enabled by simply placing a non-FIT
>>> boot image on the boot media.
>>>
>>
>> As per spl_load_image_ext_os, the SPL first tries to load the file set
>> in falcon_args_file env variable but since it's not set in our case. And
>> the only way to set them is by rebuilding u-boot as uEnv.txt is not
>> supported at SPL stage.
>>
>> This means the SPL only loads CONFIG_SPL_FS_LOAD_ARGS_NAME and
>> CONFIG_SPL_FS_LOAD_KERNEL_NAME which are set as the DTB and fitImage
>
> What is stopping me from replacing the content of the file "fitImage"
> with a normal kernel image? When loading that image the file type
> will be detected as a normal kernel image and all FIT logic bypassed,
> including authentication, breaking our secure chain of trust.
>
> Andrew
That would require booti_setup to be executed in spl_parse_image_header,
which is not possible on the R5 SPL since the required config symbol
CMD_BOOTI is only available for ARM64 platforms.
In the worst case we end up loading a 32-bit zImage which wouldn't
boot on the Cortex-A cores anyway and would additionally require
enabling CMD_BOOTZ (currently disabled) at build time.
Regards,
Anshul
>
>> respectively. Following that, authentication is enforced during FIT
>> loading by the call to board_fit_image_post_process in load_simple_fit.
>>
>> So even if the fitImage was modified, boot would fail without valid
>> signatures on HS-SE devices.
>>
>> - Anshul
>>
>>>> container (fitImage) signed with TIFS keys for authentication.
>>>>
>>>> Signed-off-by: Anshul Dalal <anshuld@ti.com>
>>>> ---
>>>> common/spl/Kconfig | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
>>>> index c08045f9c8d..68e900e9b91 100644
>>>> --- a/common/spl/Kconfig
>>>> +++ b/common/spl/Kconfig
>>>> @@ -1165,7 +1165,7 @@ config SPL_ONENAND_SUPPORT
>>>>
>>>> config SPL_OS_BOOT
>>>> bool "Activate Falcon Mode"
>>>> - depends on !TI_SECURE_DEVICE
>>>> + depends on !TI_SECURE_DEVICE || ARCH_K3
>>>> help
>>>> Enable booting directly to an OS from SPL.
>>>> for more info read doc/README.falcon
>>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v6 1/9] spl: Kconfig: allow K3 devices to use falcon mode
2025-05-08 3:12 ` Anshul Dalal
@ 2025-05-08 4:02 ` Raghavendra, Vignesh
2025-05-08 11:37 ` Anshul Dalal
0 siblings, 1 reply; 20+ messages in thread
From: Raghavendra, Vignesh @ 2025-05-08 4:02 UTC (permalink / raw)
To: Anshul Dalal, Andrew Davis, u-boot; +Cc: trini, m-chawdhry, n-francis, b-liu
On 5/8/2025 8:42 AM, Anshul Dalal wrote:
> On Wed May 7, 2025 at 11:36 PM IST, Andrew Davis wrote:
>> On 5/6/25 10:33 PM, Anshul Dalal wrote:
>>> On Tue May 6, 2025 at 8:03 PM IST, Andrew Davis wrote:
>>>> On 4/28/25 9:12 AM, Anshul Dalal wrote:
>>>>> Falcon mode was disabled for TI_SECURE_DEVICE at commit e95b9b4437bc
>>>>> ("ti_armv7_common: Disable Falcon Mode on HS devices") for older 32-bit
>>>>> HS devices and can be enabled on K3 devices.
>>>>>
>>>>> For secure boot, the kernel with x509 headers can be packaged in a fit
>>>> "can be", this is the issue. Security is not just allowing methods that
>>>> are security checked, but forcing the use of such methods. Setting
>>>> OS_BOOT opens up several paths that look for non-FIT images. These
>>>> images do not enforce authentication like FIT does. This means one can
>>>> bypass secure boot when OS_BOOT is enabled by simply placing a non-FIT
>>>> boot image on the boot media.
>>>>
>>> As per spl_load_image_ext_os, the SPL first tries to load the file set
>>> in falcon_args_file env variable but since it's not set in our case. And
>>> the only way to set them is by rebuilding u-boot as uEnv.txt is not
>>> supported at SPL stage.
>>>
>>> This means the SPL only loads CONFIG_SPL_FS_LOAD_ARGS_NAME and
>>> CONFIG_SPL_FS_LOAD_KERNEL_NAME which are set as the DTB and fitImage
>> What is stopping me from replacing the content of the file "fitImage"
>> with a normal kernel image? When loading that image the file type
>> will be detected as a normal kernel image and all FIT logic bypassed,
>> including authentication, breaking our secure chain of trust.
>>
>> Andrew
> That would require booti_setup to be executed in spl_parse_image_header,
> which is not possible on the R5 SPL since the required config symbol
> CMD_BOOTI is only available for ARM64 platforms.
>
> In the worst case we end up loading a 32-bit zImage which wouldn't
> boot on the Cortex-A cores anyway and would additionally require
> enabling CMD_BOOTZ (currently disabled) at build time.
Is there any path where R5 SPL can be tricked to load and jump to
arbitrary binary? zImage, Image, elf, bin whatever?
IOW, does SPL_OS_BOOT always check for some sort of header for the image
that it loads and the only type of header we have enabled here is fitImage?
Regards
Vignesh
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v6 1/9] spl: Kconfig: allow K3 devices to use falcon mode
2025-05-08 4:02 ` Raghavendra, Vignesh
@ 2025-05-08 11:37 ` Anshul Dalal
2025-05-28 15:39 ` Andrew Davis
0 siblings, 1 reply; 20+ messages in thread
From: Anshul Dalal @ 2025-05-08 11:37 UTC (permalink / raw)
To: Raghavendra, Vignesh, Andrew Davis, u-boot
Cc: trini, m-chawdhry, n-francis, b-liu
On Thu May 8, 2025 at 9:32 AM IST, Vignesh Raghavendra wrote:
>
>
> On 5/8/2025 8:42 AM, Anshul Dalal wrote:
>> On Wed May 7, 2025 at 11:36 PM IST, Andrew Davis wrote:
>>> On 5/6/25 10:33 PM, Anshul Dalal wrote:
>>>> On Tue May 6, 2025 at 8:03 PM IST, Andrew Davis wrote:
>>>>> On 4/28/25 9:12 AM, Anshul Dalal wrote:
>>>>>> Falcon mode was disabled for TI_SECURE_DEVICE at commit e95b9b4437bc
>>>>>> ("ti_armv7_common: Disable Falcon Mode on HS devices") for older 32-bit
>>>>>> HS devices and can be enabled on K3 devices.
>>>>>>
>>>>>> For secure boot, the kernel with x509 headers can be packaged in a fit
>>>>> "can be", this is the issue. Security is not just allowing methods that
>>>>> are security checked, but forcing the use of such methods. Setting
>>>>> OS_BOOT opens up several paths that look for non-FIT images. These
>>>>> images do not enforce authentication like FIT does. This means one can
>>>>> bypass secure boot when OS_BOOT is enabled by simply placing a non-FIT
>>>>> boot image on the boot media.
>>>>>
>>>> As per spl_load_image_ext_os, the SPL first tries to load the file set
>>>> in falcon_args_file env variable but since it's not set in our case. And
>>>> the only way to set them is by rebuilding u-boot as uEnv.txt is not
>>>> supported at SPL stage.
>>>>
>>>> This means the SPL only loads CONFIG_SPL_FS_LOAD_ARGS_NAME and
>>>> CONFIG_SPL_FS_LOAD_KERNEL_NAME which are set as the DTB and fitImage
>>> What is stopping me from replacing the content of the file "fitImage"
>>> with a normal kernel image? When loading that image the file type
>>> will be detected as a normal kernel image and all FIT logic bypassed,
>>> including authentication, breaking our secure chain of trust.
>>>
>>> Andrew
>> That would require booti_setup to be executed in spl_parse_image_header,
>> which is not possible on the R5 SPL since the required config symbol
>> CMD_BOOTI is only available for ARM64 platforms.
>>
>> In the worst case we end up loading a 32-bit zImage which wouldn't
>> boot on the Cortex-A cores anyway and would additionally require
>> enabling CMD_BOOTZ (currently disabled) at build time.
>
> Is there any path where R5 SPL can be tricked to load and jump to
> arbitrary binary? zImage, Image, elf, bin whatever?
>
> IOW, does SPL_OS_BOOT always check for some sort of header for the image
> that it loads and the only type of header we have enabled here is fitImage?
It does check for the header and proceeds only with the desired security
enforced execution flow if the loaded image is FIT. For all other image
types, they are guarded by config symbols that are set unset in our case
except for spl_parse_legacy_header which could be triggered but would
just lead to a boot failure as we don't override the default weak
definition.
Regards,
Anshul
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v6 1/9] spl: Kconfig: allow K3 devices to use falcon mode
2025-05-08 11:37 ` Anshul Dalal
@ 2025-05-28 15:39 ` Andrew Davis
2025-05-29 1:08 ` Anshul Dalal
0 siblings, 1 reply; 20+ messages in thread
From: Andrew Davis @ 2025-05-28 15:39 UTC (permalink / raw)
To: Anshul Dalal, Raghavendra, Vignesh, u-boot
Cc: trini, m-chawdhry, n-francis, b-liu
On 5/8/25 6:37 AM, Anshul Dalal wrote:
> On Thu May 8, 2025 at 9:32 AM IST, Vignesh Raghavendra wrote:
>>
>>
>> On 5/8/2025 8:42 AM, Anshul Dalal wrote:
>>> On Wed May 7, 2025 at 11:36 PM IST, Andrew Davis wrote:
>>>> On 5/6/25 10:33 PM, Anshul Dalal wrote:
>>>>> On Tue May 6, 2025 at 8:03 PM IST, Andrew Davis wrote:
>>>>>> On 4/28/25 9:12 AM, Anshul Dalal wrote:
>>>>>>> Falcon mode was disabled for TI_SECURE_DEVICE at commit e95b9b4437bc
>>>>>>> ("ti_armv7_common: Disable Falcon Mode on HS devices") for older 32-bit
>>>>>>> HS devices and can be enabled on K3 devices.
>>>>>>>
>>>>>>> For secure boot, the kernel with x509 headers can be packaged in a fit
>>>>>> "can be", this is the issue. Security is not just allowing methods that
>>>>>> are security checked, but forcing the use of such methods. Setting
>>>>>> OS_BOOT opens up several paths that look for non-FIT images. These
>>>>>> images do not enforce authentication like FIT does. This means one can
>>>>>> bypass secure boot when OS_BOOT is enabled by simply placing a non-FIT
>>>>>> boot image on the boot media.
>>>>>>
>>>>> As per spl_load_image_ext_os, the SPL first tries to load the file set
>>>>> in falcon_args_file env variable but since it's not set in our case. And
>>>>> the only way to set them is by rebuilding u-boot as uEnv.txt is not
>>>>> supported at SPL stage.
>>>>>
>>>>> This means the SPL only loads CONFIG_SPL_FS_LOAD_ARGS_NAME and
>>>>> CONFIG_SPL_FS_LOAD_KERNEL_NAME which are set as the DTB and fitImage
>>>> What is stopping me from replacing the content of the file "fitImage"
>>>> with a normal kernel image? When loading that image the file type
>>>> will be detected as a normal kernel image and all FIT logic bypassed,
>>>> including authentication, breaking our secure chain of trust.
>>>>
>>>> Andrew
>>> That would require booti_setup to be executed in spl_parse_image_header,
>>> which is not possible on the R5 SPL since the required config symbol
>>> CMD_BOOTI is only available for ARM64 platforms.
>>>
>>> In the worst case we end up loading a 32-bit zImage which wouldn't
>>> boot on the Cortex-A cores anyway and would additionally require
>>> enabling CMD_BOOTZ (currently disabled) at build time.
>>
>> Is there any path where R5 SPL can be tricked to load and jump to
>> arbitrary binary? zImage, Image, elf, bin whatever?
>>
>> IOW, does SPL_OS_BOOT always check for some sort of header for the image
>> that it loads and the only type of header we have enabled here is fitImage?
>
> It does check for the header and proceeds only with the desired security
> enforced execution flow if the loaded image is FIT. For all other image
> types, they are guarded by config symbols that are set unset in our case
Are you sure?
The only thing preventing this from continuing in spl_parse_image_header()
is a check for CONFIG_SPL_PANIC_ON_RAW_IMAGE. Which is not set for us.
After that we check if OS_BOOT is enabled and if so allow for kernel
images to also pass[0]. What stops this from functioning?
Andrew
[0] https://github.com/u-boot/u-boot/blob/master/common/spl/spl.c#L338
> except for spl_parse_legacy_header which could be triggered but would
> just lead to a boot failure as we don't override the default weak
> definition.
>
> Regards,
> Anshul
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v6 1/9] spl: Kconfig: allow K3 devices to use falcon mode
2025-05-28 15:39 ` Andrew Davis
@ 2025-05-29 1:08 ` Anshul Dalal
2025-05-29 1:36 ` Andrew Davis
0 siblings, 1 reply; 20+ messages in thread
From: Anshul Dalal @ 2025-05-29 1:08 UTC (permalink / raw)
To: Andrew Davis, Raghavendra, Vignesh, u-boot
Cc: trini, m-chawdhry, n-francis, b-liu
On Wed May 28, 2025 at 9:09 PM IST, Andrew Davis wrote:
> On 5/8/25 6:37 AM, Anshul Dalal wrote:
>> On Thu May 8, 2025 at 9:32 AM IST, Vignesh Raghavendra wrote:
>>>
>>>
>>> On 5/8/2025 8:42 AM, Anshul Dalal wrote:
>>>> On Wed May 7, 2025 at 11:36 PM IST, Andrew Davis wrote:
>>>>> On 5/6/25 10:33 PM, Anshul Dalal wrote:
>>>>>> On Tue May 6, 2025 at 8:03 PM IST, Andrew Davis wrote:
>>>>>>> On 4/28/25 9:12 AM, Anshul Dalal wrote:
>>>>>>>> Falcon mode was disabled for TI_SECURE_DEVICE at commit e95b9b4437bc
>>>>>>>> ("ti_armv7_common: Disable Falcon Mode on HS devices") for older 32-bit
>>>>>>>> HS devices and can be enabled on K3 devices.
>>>>>>>>
>>>>>>>> For secure boot, the kernel with x509 headers can be packaged in a fit
>>>>>>> "can be", this is the issue. Security is not just allowing methods that
>>>>>>> are security checked, but forcing the use of such methods. Setting
>>>>>>> OS_BOOT opens up several paths that look for non-FIT images. These
>>>>>>> images do not enforce authentication like FIT does. This means one can
>>>>>>> bypass secure boot when OS_BOOT is enabled by simply placing a non-FIT
>>>>>>> boot image on the boot media.
>>>>>>>
>>>>>> As per spl_load_image_ext_os, the SPL first tries to load the file set
>>>>>> in falcon_args_file env variable but since it's not set in our case. And
>>>>>> the only way to set them is by rebuilding u-boot as uEnv.txt is not
>>>>>> supported at SPL stage.
>>>>>>
>>>>>> This means the SPL only loads CONFIG_SPL_FS_LOAD_ARGS_NAME and
>>>>>> CONFIG_SPL_FS_LOAD_KERNEL_NAME which are set as the DTB and fitImage
>>>>> What is stopping me from replacing the content of the file "fitImage"
>>>>> with a normal kernel image? When loading that image the file type
>>>>> will be detected as a normal kernel image and all FIT logic bypassed,
>>>>> including authentication, breaking our secure chain of trust.
>>>>>
>>>>> Andrew
>>>> That would require booti_setup to be executed in spl_parse_image_header,
>>>> which is not possible on the R5 SPL since the required config symbol
>>>> CMD_BOOTI is only available for ARM64 platforms.
>>>>
>>>> In the worst case we end up loading a 32-bit zImage which wouldn't
>>>> boot on the Cortex-A cores anyway and would additionally require
>>>> enabling CMD_BOOTZ (currently disabled) at build time.
>>>
>>> Is there any path where R5 SPL can be tricked to load and jump to
>>> arbitrary binary? zImage, Image, elf, bin whatever?
>>>
>>> IOW, does SPL_OS_BOOT always check for some sort of header for the image
>>> that it loads and the only type of header we have enabled here is fitImage?
>>
>> It does check for the header and proceeds only with the desired security
>> enforced execution flow if the loaded image is FIT. For all other image
>> types, they are guarded by config symbols that are set unset in our case
>
> Are you sure?
>
> The only thing preventing this from continuing in spl_parse_image_header()
> is a check for CONFIG_SPL_PANIC_ON_RAW_IMAGE. Which is not set for us.
>
> After that we check if OS_BOOT is enabled and if so allow for kernel
> images to also pass[0]. What stops this from functioning?
>
> Andrew
>
> [0] https://github.com/u-boot/u-boot/blob/master/common/spl/spl.c#L338
>
It would not function because of the unset CONFIG_CMD_BOOTI which can
only be set on 64 bit platforms anyway[1]. Hence the following check
would fail in spl_parse_image_header:
if (CONFIG_IS_ENABLED(OS_BOOT) && IS_ENABLED(CONFIG_CMD_BOOTI))
And as I said previously in the thread[2]; worst case is we load a
32-bit zImage, support for which would have to be explicitly enabled at
build time as the respective config CMD_BOOTZ is kept unset currently.
~ Anshul
[1] https://github.com/u-boot/u-boot/blob/e04d137231f2e9e14708a32448c879125b8e308f/cmd/Kconfig#L359
[2] https://lore.kernel.org/u-boot/D9QG8DY630MX.1OV8MBZIM4R8S@ti.com/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v6 1/9] spl: Kconfig: allow K3 devices to use falcon mode
2025-05-29 1:08 ` Anshul Dalal
@ 2025-05-29 1:36 ` Andrew Davis
2025-05-30 9:17 ` Anshul Dalal
0 siblings, 1 reply; 20+ messages in thread
From: Andrew Davis @ 2025-05-29 1:36 UTC (permalink / raw)
To: Anshul Dalal, Raghavendra, Vignesh, u-boot
Cc: trini, m-chawdhry, n-francis, b-liu
On 5/28/25 8:08 PM, Anshul Dalal wrote:
> On Wed May 28, 2025 at 9:09 PM IST, Andrew Davis wrote:
>> On 5/8/25 6:37 AM, Anshul Dalal wrote:
>>> On Thu May 8, 2025 at 9:32 AM IST, Vignesh Raghavendra wrote:
>>>>
>>>>
>>>> On 5/8/2025 8:42 AM, Anshul Dalal wrote:
>>>>> On Wed May 7, 2025 at 11:36 PM IST, Andrew Davis wrote:
>>>>>> On 5/6/25 10:33 PM, Anshul Dalal wrote:
>>>>>>> On Tue May 6, 2025 at 8:03 PM IST, Andrew Davis wrote:
>>>>>>>> On 4/28/25 9:12 AM, Anshul Dalal wrote:
>>>>>>>>> Falcon mode was disabled for TI_SECURE_DEVICE at commit e95b9b4437bc
>>>>>>>>> ("ti_armv7_common: Disable Falcon Mode on HS devices") for older 32-bit
>>>>>>>>> HS devices and can be enabled on K3 devices.
>>>>>>>>>
>>>>>>>>> For secure boot, the kernel with x509 headers can be packaged in a fit
>>>>>>>> "can be", this is the issue. Security is not just allowing methods that
>>>>>>>> are security checked, but forcing the use of such methods. Setting
>>>>>>>> OS_BOOT opens up several paths that look for non-FIT images. These
>>>>>>>> images do not enforce authentication like FIT does. This means one can
>>>>>>>> bypass secure boot when OS_BOOT is enabled by simply placing a non-FIT
>>>>>>>> boot image on the boot media.
>>>>>>>>
>>>>>>> As per spl_load_image_ext_os, the SPL first tries to load the file set
>>>>>>> in falcon_args_file env variable but since it's not set in our case. And
>>>>>>> the only way to set them is by rebuilding u-boot as uEnv.txt is not
>>>>>>> supported at SPL stage.
>>>>>>>
>>>>>>> This means the SPL only loads CONFIG_SPL_FS_LOAD_ARGS_NAME and
>>>>>>> CONFIG_SPL_FS_LOAD_KERNEL_NAME which are set as the DTB and fitImage
>>>>>> What is stopping me from replacing the content of the file "fitImage"
>>>>>> with a normal kernel image? When loading that image the file type
>>>>>> will be detected as a normal kernel image and all FIT logic bypassed,
>>>>>> including authentication, breaking our secure chain of trust.
>>>>>>
>>>>>> Andrew
>>>>> That would require booti_setup to be executed in spl_parse_image_header,
>>>>> which is not possible on the R5 SPL since the required config symbol
>>>>> CMD_BOOTI is only available for ARM64 platforms.
>>>>>
>>>>> In the worst case we end up loading a 32-bit zImage which wouldn't
>>>>> boot on the Cortex-A cores anyway and would additionally require
>>>>> enabling CMD_BOOTZ (currently disabled) at build time.
>>>>
>>>> Is there any path where R5 SPL can be tricked to load and jump to
>>>> arbitrary binary? zImage, Image, elf, bin whatever?
>>>>
>>>> IOW, does SPL_OS_BOOT always check for some sort of header for the image
>>>> that it loads and the only type of header we have enabled here is fitImage?
>>>
>>> It does check for the header and proceeds only with the desired security
>>> enforced execution flow if the loaded image is FIT. For all other image
>>> types, they are guarded by config symbols that are set unset in our case
>>
>> Are you sure?
>>
>> The only thing preventing this from continuing in spl_parse_image_header()
>> is a check for CONFIG_SPL_PANIC_ON_RAW_IMAGE. Which is not set for us.
>>
>> After that we check if OS_BOOT is enabled and if so allow for kernel
>> images to also pass[0]. What stops this from functioning?
>>
>> Andrew
>>
>> [0] https://github.com/u-boot/u-boot/blob/master/common/spl/spl.c#L338
>>
>
> It would not function because of the unset CONFIG_CMD_BOOTI which can
> only be set on 64 bit platforms anyway[1]. Hence the following check
> would fail in spl_parse_image_header:
>
> if (CONFIG_IS_ENABLED(OS_BOOT) && IS_ENABLED(CONFIG_CMD_BOOTI))
>
I linked the wrong line, the line a couple below for CONFIG_CMD_BOOTZ
is the one that concerns me.
> And as I said previously in the thread[2]; worst case is we load a
> 32-bit zImage, support for which would have to be explicitly enabled at
> build time as the respective config CMD_BOOTZ is kept unset currently.
>
What forces CMD_BOOTZ to not be set? Can it be enabled in SPL at all?
If it can you should make it "depends on !TI_SECURE_DEVICE" like other
dangerous to the secure chain of trust configs.
Andrew
> ~ Anshul
>
> [1] https://github.com/u-boot/u-boot/blob/e04d137231f2e9e14708a32448c879125b8e308f/cmd/Kconfig#L359
> [2] https://lore.kernel.org/u-boot/D9QG8DY630MX.1OV8MBZIM4R8S@ti.com/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v6 1/9] spl: Kconfig: allow K3 devices to use falcon mode
2025-05-29 1:36 ` Andrew Davis
@ 2025-05-30 9:17 ` Anshul Dalal
0 siblings, 0 replies; 20+ messages in thread
From: Anshul Dalal @ 2025-05-30 9:17 UTC (permalink / raw)
To: Andrew Davis, Raghavendra, Vignesh, u-boot
Cc: trini, m-chawdhry, n-francis, b-liu
On Thu May 29, 2025 at 7:06 AM IST, Andrew Davis wrote:
> On 5/28/25 8:08 PM, Anshul Dalal wrote:
>> On Wed May 28, 2025 at 9:09 PM IST, Andrew Davis wrote:
>>> On 5/8/25 6:37 AM, Anshul Dalal wrote:
>>>> On Thu May 8, 2025 at 9:32 AM IST, Vignesh Raghavendra wrote:
>>>>>
>>>>>
>>>>> On 5/8/2025 8:42 AM, Anshul Dalal wrote:
>>>>>> On Wed May 7, 2025 at 11:36 PM IST, Andrew Davis wrote:
>>>>>>> On 5/6/25 10:33 PM, Anshul Dalal wrote:
>>>>>>>> On Tue May 6, 2025 at 8:03 PM IST, Andrew Davis wrote:
>>>>>>>>> On 4/28/25 9:12 AM, Anshul Dalal wrote:
>>>>>>>>>> Falcon mode was disabled for TI_SECURE_DEVICE at commit e95b9b4437bc
>>>>>>>>>> ("ti_armv7_common: Disable Falcon Mode on HS devices") for older 32-bit
>>>>>>>>>> HS devices and can be enabled on K3 devices.
>>>>>>>>>>
>>>>>>>>>> For secure boot, the kernel with x509 headers can be packaged in a fit
>>>>>>>>> "can be", this is the issue. Security is not just allowing methods that
>>>>>>>>> are security checked, but forcing the use of such methods. Setting
>>>>>>>>> OS_BOOT opens up several paths that look for non-FIT images. These
>>>>>>>>> images do not enforce authentication like FIT does. This means one can
>>>>>>>>> bypass secure boot when OS_BOOT is enabled by simply placing a non-FIT
>>>>>>>>> boot image on the boot media.
>>>>>>>>>
>>>>>>>> As per spl_load_image_ext_os, the SPL first tries to load the file set
>>>>>>>> in falcon_args_file env variable but since it's not set in our case. And
>>>>>>>> the only way to set them is by rebuilding u-boot as uEnv.txt is not
>>>>>>>> supported at SPL stage.
>>>>>>>>
>>>>>>>> This means the SPL only loads CONFIG_SPL_FS_LOAD_ARGS_NAME and
>>>>>>>> CONFIG_SPL_FS_LOAD_KERNEL_NAME which are set as the DTB and fitImage
>>>>>>> What is stopping me from replacing the content of the file "fitImage"
>>>>>>> with a normal kernel image? When loading that image the file type
>>>>>>> will be detected as a normal kernel image and all FIT logic bypassed,
>>>>>>> including authentication, breaking our secure chain of trust.
>>>>>>>
>>>>>>> Andrew
>>>>>> That would require booti_setup to be executed in spl_parse_image_header,
>>>>>> which is not possible on the R5 SPL since the required config symbol
>>>>>> CMD_BOOTI is only available for ARM64 platforms.
>>>>>>
>>>>>> In the worst case we end up loading a 32-bit zImage which wouldn't
>>>>>> boot on the Cortex-A cores anyway and would additionally require
>>>>>> enabling CMD_BOOTZ (currently disabled) at build time.
>>>>>
>>>>> Is there any path where R5 SPL can be tricked to load and jump to
>>>>> arbitrary binary? zImage, Image, elf, bin whatever?
>>>>>
>>>>> IOW, does SPL_OS_BOOT always check for some sort of header for the image
>>>>> that it loads and the only type of header we have enabled here is fitImage?
>>>>
>>>> It does check for the header and proceeds only with the desired security
>>>> enforced execution flow if the loaded image is FIT. For all other image
>>>> types, they are guarded by config symbols that are set unset in our case
>>>
>>> Are you sure?
>>>
>>> The only thing preventing this from continuing in spl_parse_image_header()
>>> is a check for CONFIG_SPL_PANIC_ON_RAW_IMAGE. Which is not set for us.
>>>
>>> After that we check if OS_BOOT is enabled and if so allow for kernel
>>> images to also pass[0]. What stops this from functioning?
>>>
>>> Andrew
>>>
>>> [0] https://github.com/u-boot/u-boot/blob/master/common/spl/spl.c#L338
>>>
>>
>> It would not function because of the unset CONFIG_CMD_BOOTI which can
>> only be set on 64 bit platforms anyway[1]. Hence the following check
>> would fail in spl_parse_image_header:
>>
>> if (CONFIG_IS_ENABLED(OS_BOOT) && IS_ENABLED(CONFIG_CMD_BOOTI))
>>
>
> I linked the wrong line, the line a couple below for CONFIG_CMD_BOOTZ
> is the one that concerns me.
>
>> And as I said previously in the thread[2]; worst case is we load a
>> 32-bit zImage, support for which would have to be explicitly enabled at
>> build time as the respective config CMD_BOOTZ is kept unset currently.
>>
>
> What forces CMD_BOOTZ to not be set? Can it be enabled in SPL at all?
> If it can you should make it "depends on !TI_SECURE_DEVICE" like other
> dangerous to the secure chain of trust configs.
>
Sure, I'll update Kconfig to make CMD_BOOTZ and TI_SECURE_DEVICE
mutually exclusive in the next revision just like SPL_RAW_IMAGE_SUPPORT.
Thanks for the review!
~ Anshul
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2025-05-30 9:17 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-28 14:12 [PATCH v6 0/9] Add falcon support for am62a, 62p and 62x Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 1/9] spl: Kconfig: allow K3 devices to use falcon mode Anshul Dalal
2025-05-06 14:33 ` Andrew Davis
2025-05-07 3:33 ` Anshul Dalal
2025-05-07 18:06 ` Andrew Davis
2025-05-08 3:12 ` Anshul Dalal
2025-05-08 4:02 ` Raghavendra, Vignesh
2025-05-08 11:37 ` Anshul Dalal
2025-05-28 15:39 ` Andrew Davis
2025-05-29 1:08 ` Anshul Dalal
2025-05-29 1:36 ` Andrew Davis
2025-05-30 9:17 ` Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 2/9] mach-k3: fix reading size and addr from fdt on R5 Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 3/9] arch: arm: k3-binman: add fit for falcon boot Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 4/9] mach-k3: sysfw-loader: update img_hdr for falcon Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 5/9] config: add falcon boot config fragment for am62x Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 6/9] board: ti: add default dtb for am62 in falcon mode Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 7/9] mach-k3: common: enable falcon mode for 62 platform Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 8/9] Makefile: update tispl regex to also clean falcon spl Anshul Dalal
2025-04-28 14:12 ` [PATCH v6 9/9] doc: ti: am62: add falcon mode documentation Anshul Dalal
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox