PROCESSOR-SDK-AM62A: Reducing Linux Boot time

On Slide 3, It is mentioned to shift from A53 to R5.

How to do it in Yocto build environment?

Hi Sathiya,

I am not familiar with Yocto, but I doubt the process has been implemented in Yocto. You probably would have to exercise the process manually in the Processor SDK, then implement the steps in Yocto.

FYI, here is an article providing the instructions for this step summarized in the Slide 3:

e2e.ti.com/.../faq-am625-how-to-boot-from-r5-u-boot-spl-directly-into-the-linux-kernel-skipping-a53-spl-and-a53-u-boot-falcon-mode

Thank You Bin Liu.

Bin Liu said:

e2e.ti.com/.../faq-am625-how-to-boot-from-r5-u-boot-spl-directly-into-the-linux-kernel-skipping-a53-spl-and-a53-u-boot-falcon-mode

I will check this and contact you regarding any query.

Can you conform that this procedure of switching boot from R5F SPL -> Linux is not available in Yocto?

Because I can see few files with reference to am62x_evm_r5_defconfig for u-boot. Proper README or procedure is missing. I just want that procedure to do it in Yocto.

I am preferring Yocto because all other specs needed for my project is already implemented in Yocto.

I highly doubt this procedure is already in Yocto, since it is purely a boot flow customization.

am62x_evm_r5_defconfig is used for configuring u-boot for R5 binary, the defconfig file itself has nothing to do with this boot flow customization procedure.

Ok

Hello Bin Liu,

Bin Liu said:

e2e.ti.com/.../faq-am625-how-to-boot-from-r5-u-boot-spl-directly-into-the-linux-kernel-skipping-a53-spl-and-a53-u-boot-falcon-mode

As Binman is replaced k3-image-gen in SDK 9.1, This patch has become invalid. I manually applied the patch but I got the following binman error from make u-boot sysfw-image

So I can't generate tiboot3.bin file.

  AR      spl/common/spl/built-in.o
  AR      spl/env/built-in.o
  LD      spl/u-boot-spl
  OBJCOPY spl/u-boot-spl-nodtb.bin
  SYM     spl/u-boot-spl.sym
  CAT     spl/u-boot-spl-dtb.bin
  COPY    spl/u-boot-spl.bin
  BINMAN  .binman_stamp
Image 'fsstub-hs' is missing external blobs but is still functional: fsstub-hs-cert.bin fsstub-hs-enc.bin
Image 'fsstub-fs' is missing external blobs but is still functional: fsstub-fs-cert.bin fsstub-fs-enc.bin
Image 'fsstub-gp' is missing external blobs but is still functional: fsstub-gp.bin
binman: name 'ELFError' is not defined
make[2]: *** [/home/snarayanan/ti/ti-processor-sdk-linux-edgeai-am62axx-evm-09_01_00_07/board-support/ti-u-boot-2023.04+gitAUTOINC+b0d717b732-gb0d717b732/Makefile:1108: .binman_stamp] Error 1
make[2]: Leaving directory '/home/snarayanan/ti/ti-processor-sdk-linux-edgeai-am62axx-evm-09_01_00_07/board-support/ti-u-boot-2023.04+gitAUTOINC+b0d717b732-gb0d717b732/build/a53'
make[1]: *** [Makefile:177: sub-make] Error 2
make[1]: Leaving directory '/home/snarayanan/ti/ti-processor-sdk-linux-edgeai-am62axx-evm-09_01_00_07/board-support/ti-u-boot-2023.04+gitAUTOINC+b0d717b732-gb0d717b732'
make: *** [makerules/Makefile_u-boot:15: u-boot-a53] Error 2

Hi Sathiya,

The boot optimization work documented in the mentioned E2E FAQ has not been exercised on SDK9.1 yet, but I quickly reviewed the 3 patches provided in the FAQ (am62-r5-spl-to-kernel-boot-sdk-v08.06-13-mar-23.tar.gz) and don't see anything directly related to Binman.

Can you please provide details of your manual patching process? Which patch has to manually applied? What is the diff after you manually applied?

Hi Bin Liu,

Bin Liu said:

don't see anything directly related to Binman.

In files <UBOOT_DIR>/include/configs/ti_armv7_common.h and <UBOOT_DIR>/include/configs/am62ax_evm.h, the structure is changed according to the binman.

Here is the diff:

iff --git a/configs/am62ax_evm_r5_defconfig b/configs/am62ax_evm_r5_defconfig
index b92fea415a..cc0c56ab07 100644
--- a/configs/am62ax_evm_r5_defconfig
+++ b/configs/am62ax_evm_r5_defconfig
@@ -1,6 +1,7 @@
 CONFIG_ARM=y
 CONFIG_ARCH_K3=y
 CONFIG_TI_SECURE_DEVICE=y
+CONFIG_SYS_TEXT_BASE=0x83000000
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x200000
 CONFIG_SYS_MALLOC_F_LEN=0x8000
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
@@ -17,7 +18,7 @@ CONFIG_SPL_TEXT_BASE=0x43c00000
 CONFIG_DM_RESET=y
 CONFIG_SPL_MMC=y
 CONFIG_SPL_SERIAL=y
-CONFIG_SPL_STACK_R_ADDR=0x82000000
+CONFIG_SPL_STACK_R_ADDR=0x89000000
 CONFIG_SPL_SYS_MALLOC_F_LEN=0x7145
 CONFIG_SPL_SIZE_LIMIT=0x3A7F0
 CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x4400
@@ -25,7 +26,7 @@ CONFIG_SPL_FS_FAT=y
 CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_SPL_SPI=y
 CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_LOAD_FIT_ADDRESS=0x80080000
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x84000000
 CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y
diff --git a/include/configs/am62ax_evm.h b/include/configs/am62ax_evm.h
index 7eef6644dd..1dbab59856 100644
--- a/include/configs/am62ax_evm.h
+++ b/include/configs/am62ax_evm.h
@@ -13,7 +13,9 @@
 
 /* DDR Configuration */
 #define CFG_SYS_SDRAM_BASE1            0x880000000
-
+#ifdef CONFIG_SYS_K3_SPL_ATF
+#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME        "atf-tee-dm-kernel-fdt.bin"
+#endif
 
 /* Now for the remaining common defines */
 #include <configs/ti_armv7_common.h>
diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h
index dbbeff34ba..be9bb641fb 100644
--- a/include/configs/ti_armv7_common.h
+++ b/include/configs/ti_armv7_common.h
@@ -31,6 +31,26 @@
  * blob before loading the ramdisk, as DTBO location is only used as a temporary
  * storage, and can be re-used after 'fdt apply' command is done.
  */
+#if defined(CONFIG_CPU_V7R) && defined(CONFIG_SOC_K3_AM62A7)
+/*
+ * In order to support a direct R5 SPL -> Linux Kernel boot flow use
+ * a load address that is well beyond the space where Kernel and DTB
+ * will need to get populated to avoid any conflicts.
+ */
+#define DEFAULT_LINUX_BOOT_ENV \
+       "loadaddr=0x84000000\0" \
+       "kernel_addr_r=0x82000000\0" \
+       "fdtaddr=0x88000000\0" \
+       "dtboaddr=0x89000000\0" \
+       "fdt_addr_r=0x88000000\0" \
+       "fdtoverlay_addr_r=0x89000000\0" \
+       "rdaddr=0x88080000\0" \
+       "ramdisk_addr_r=0x88080000\0" \
+       "scriptaddr=0x80000000\0" \
+       "pxefile_addr_r=0x80100000\0" \
+       "bootm_size=0x10000000\0" \
+       "boot_fdt=try\0"
+#else
 #define DEFAULT_LINUX_BOOT_ENV \
        "loadaddr=0x82000000\0" \
        "kernel_addr_r=0x82000000\0" \
@@ -45,6 +65,8 @@
        "bootm_size=0x10000000\0" \
        "boot_fdt=try\0"
 
+#endif
+
 #define DEFAULT_FIT_TI_ARGS \
        "boot_fit=0\0" \
        "addr_fit=0x90000000\0" \
diff --git a/include/environment/ti/k3_dfu.h b/include/environment/ti/k3_dfu.h
index a16a3adeca..8e3764422e 100644
--- a/include/environment/ti/k3_dfu.h
+++ b/include/environment/ti/k3_dfu.h
@@ -29,6 +29,7 @@
        "u-env.raw raw 0x3400 0x100 mmcpart 1;" \
        "sysfw.itb.raw raw 0x3600 0x800 mmcpart 1\0"
 
+
 #define DFU_ALT_INFO_OSPI \
        "dfu_alt_info_ospi=" \
        "tiboot3.bin raw 0x0 0x080000;" \
@@ -38,9 +39,24 @@
        "sysfw.itb raw 0x6c0000 0x100000;" \
        "rootfs raw 0x800000 0x3800000\0"
 
+#ifdef CONFIG_SOC_K3_AM62A7
+
+/*
+ * In order to support a direct R5 SPL -> Linux Kernel boot flow use
+ * a load address that is well beyond the space where Kernel and DTB
+ * will need to get populated to avoid any conflicts. Also increase
+ * the size of the section to accomodate a reasonably sized Kernel+
+ * initramfs combined image.
+ */
+#define DFU_ALT_INFO_RAM \
+       "dfu_alt_info_ram=" \
+       "atf-tee-dm-kernel-fdt.bin ram 0x84000000 0x4000000\0"
+
+#else
 #define DFU_ALT_INFO_RAM \
        "dfu_alt_info_ram=" \
        "tispl.bin ram 0x80080000 0x200000;" \
-       "u-boot.img ram 0x81000000 0x400000\0" \
+       "u-boot.img ram 0x81000000 0x400000\0"
+#endif
 
 #endif /* __TI_DFU_H */

Thanks Sathiya,

Now I see the u-boot code has some structure changes, the patches for SDK8.x u-boot doesn't apply to the u-boot in SDK9.x anymore.

I am not aware of any exercise internally to enable the falcon mode for u-boot in SDK9.x. But please let me check and get back to you.

Bin,

Sathiya actually got the Falcon boot working, see this partially duplicate post here: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1310265/sk-am62a-lp-booting-to-linux-kernel-directly-from-r5f-spl/4980575#4980575

There's still open questions regarding boot time optimizations (the end goal) on the other thread, feel free to chime in if you have any inputs.

Regards, Andreas

Hi Andreas,

Thanks for the update. I will close this thread and review the other one.

Hi Bin,

I let this thread on, because here it is discussing about falcon boot in Processor SDK not Yocto.