This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

J722SXH01EVM: Falcon boot using SPI

Part Number: J722SXH01EVM

Tool/software:

Using SDK 09_02_00_05, I created a new tispl.bin using the method outlined here: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1334006/sk-am68-can-falcon-mode-be-enabled-on-sk-am68-j721s2-tda4vx

However it is not booting. The last print after setting CONFIG_LOGLEVEL=8:

U-Boot SPL 2023.04-00006-g96c6cb64-dirty (Jun 18 2024 - 09:42:46 -0500)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.6--w2023.01-j722s (Kool Koa')
k3_ddrss memory-controller@f300000: ddr freq0 not populated, using bypass frequency.
k3_ddrss memory-controller@f300000: vtt-supply not found.
SPL initial stack usage: 17064 bytes
Trying to boot from SPI
SPL: spl_image=0lx88fffee8
single-pinctrl pinctrl@f4000: configuring pins for ospi0-default-pins
single-pinctrl pinctrl@f4000: reg/val 88fffd94a/0x00010000
single-pinctrl pinctrl@f4000: reg/val 88fffd94a/0x00010000
single-pinctrl pinctrl@f4000: reg/val 88fffd94a/0x00050000
single-pinctrl pinctrl@f4000: reg/val 88fffd94a/0x00050000
single-pinctrl pinctrl@f4000: reg/val 88fffd94a/0x00050000
single-pinctrl pinctrl@f4000: reg/val 88fffd94a/0x00050000
single-pinctrl pinctrl@f4000: reg/val 88fffd94a/0x00050000
single-pinctrl pinctrl@f4000: reg/val 88fffd94a/0x00050000
single-pinctrl pinctrl@f4000: reg/val 88fffd94a/0x00050000
single-pinctrl pinctrl@f4000: reg/val 88fffd94a/0x00050000
single-pinctrl pinctrl@f4000: reg/val 88fffd94a/0x00050000
cadence_spi spi@fc40000: spi_find_chip_select: plat=43c43be4, cs=0
jedec_spi_nor flash@0: non-uniform erase sector maps are not supported yet.
jedec_spi_nor flash@0: from 0x00080000, len d
jedec_spi_nor flash@0: from 0x00080000, len d
jedec_spi_nor flash@0: from 0x00080564, len d

This implies we at least reach the function "spi_nor_parse_sfdp"

I've also tried changing the memory locations like below with the same result here: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1205638/faq-am625-how-to-boot-from-r5-u-boot-spl-directly-into-the-linux-kernel-skipping-a53-spl-and-a53-u-boot-falcon-mode

These memory locations move the CONFIG_SPL_STACK_R_ADDR and CONFIG_SPL_LOAD_FIT_ADDRESS around. These changes don't fix the issue though.

It is able communicate with the OSPI NOR because I'm able to flash and boot from the NOR normally, just not with the custom tispl.bin

I've also verified the tispl.bin image is fully written to the NOR starting at address 0x080000.

  • Hi,

    I have not tried the falcon boon on J722S.

    To begin with have you ported:

    diff --git a/board/ti/j721s2/evm.c b/board/ti/j721s2/evm.c
    index eea2c256b3..ce3ff90c97 100644
    --- a/board/ti/j721s2/evm.c
    +++ b/board/ti/j721s2/evm.c
    @@ -107,6 +107,8 @@ static void __maybe_unused detect_enable_spinand(void *blob)
     #if defined(CONFIG_SPL_BUILD)
     void spl_perform_fixups(struct spl_image_info *spl_image)
     {
    +       return;
    +

    I do not see similar function in j722s: https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/board/ti/j722s/evm.c?h=ti-u-boot-2023.04

    So I believe porting this will need to be different.

    Can you make sure that the tispl.bin is loaded? I want to know if the failure is while executing tispl.bin or before loading that.

    - Keerthy

  • Hi Keerthy,

    I did find and change this already:

    diff --git a/board/ti/j722s/evm.c b/board/ti/j722s/evm.c
    index 0194873f..9eb28ecd 100644
    --- a/board/ti/j722s/evm.c
    +++ b/board/ti/j722s/evm.c
    @@ -105,6 +105,7 @@ static void __maybe_unused detect_enable_spinand(void *blob)
     #if defined(CONFIG_SPL_BUILD)
     void spl_perform_fixups(struct spl_image_info *spl_image)
     {
    +       return;
            detect_enable_spinand(spl_image->fdt_addr);
     }
     #endif

    I applied the attached SPI patches from another forum post, so that's why the code exists. See attached.

    I found the code was stuck in a call to:
    spl_load_fit_image(info, sector, &ctx, node, spl_image);

    Eventually it calls this which hangs:
    info->read(info, sector + get_aligned_image_offset(info, offset), nr_sectors, src_ptr) != nr_sectors)

    I noticed src_ptr was the same value as the bl31.bin from the tispl.its_lin from the other forum post. So maybe trying to store the info to 0x70000000 is not accessible or causes some kind of CPU exception.

    Setting the load and entry to 0x9e780000 lets it get further, but now it's stuck with the following prints:

    U-Boot SPL 2023.04-00006-g96c6cb64-dirty (Jun 19 2024 - 11:25:09 -0500)
    SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.6--w2023.01-j722s (Kool Koa')
    SPL initial stack usage: 17064 bytes
    Trying to boot from SPI
    External data: dst=9e780000, offset=564, size=cef0
    Image OS is ARM Trusted Firmware
    spl_load_simple_fit[760]:spl_fit_image_get_os=25
    External data: dst=9e800000, offset=d454, size=74d48
    External data: dst=89000000, offset=8219c, size=20f30
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fail on Security Enforcing(HS-SE) devices
    External data: dst=82000000, offset=131dacc, size=11712
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fail on Security Enforcing(HS-SE) devices
    External data: dst=80080000, offset=a30cc, size=127aa00
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fail on Security Enforcing(HS-SE) devices
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fail on Security Enforcing(HS-SE) devices
    Warning: Did not detect image signing certificate. Skipping authentication to prevent boot failure. This will fail on Security Enforcing(HS-SE) devices
    Starting ATF on ARM64 core...
    
    NOTICE:  BL31: v2.10.0(release):v2.10.0-367-g00f1ec6b87-dirty
    NOTICE:  BL31: Built : 16:09:05, Feb  9 2024
    NOTICE:  Upgrade Firmwares for Power off functionality
    ERROR:   Failed to get response (-19)
    ERROR:   Transfer send failed (-19)
    ERROR:   Unable to query firmware capabilities (-19)
    
    


    Is there a way to recompile bl31.bin with the SDK so I could debug further?
    I'm using the pre-built "Image" file, so I'm wondering if I need to rebuild this to be bootable? I know the linux header isn't executable and is sometimes at the start of the image.

    Also attaching the current tispl.its_lin

    3704.j722s-ospi.tar

    /dts-v1/;
    
    / {
    	description = "Configuration to load ATF and SPL";
    	#address-cells = <1>;
    
    	images {
    		atf {
    			description = "ARM Trusted Firmware";
    			data = /incbin/("bl31.bin");
    			type = "firmware";
    			arch = "arm64";
    			compression = "none";
    			os = "arm-trusted-firmware";
    			load = <0x9e780000>;
    			entry = <0x9e780000>;
    		};
    		tee {
    			description = "OPTEE";
    			data = /incbin/("bl32.bin");
    			type = "tee";
    			arch = "arm64";
    			compression = "none";
    			os = "tee";
    			load = <0x9e800000>;
    			entry = <0x9e800000>;
    		};
    		dm {
    			description = "DM binary";
    			data = /incbin/("ti-dm/j722s/ipc_echo_testb_mcu1_0_release_strip.xer5f");
    			type = "firmware";
    			arch = "arm32";
    			compression = "none";
    			os = "DM";
    			load = <0x89000000>;
    			entry = <0x89000000>;
    		};
    		kernel {
    			description = "Linux Kernel (64-bit)";
    			data = /incbin/("Image");
    			type = "standalone";
    			os = "Linux";
    			arch = "arm64";
    			compression = "none";
    			load = <0x80080000>;
    			entry = <0x80080000>;
    		};
    		fdt {
    			description = "k3-j722s-evm";
    			data = /incbin/("k3-j722s-evm.dtb");
    			type = "standalone";
    			arch = "arm";
    			compression = "none";
    			load = <0x82000000>;
    			entry = <0x82000000>;
    		};
    	};
    	configurations {
    		default = "k3-j722s-evm.dtb";
    
    		k3-j722s-evm.dtb {
    			description = "k3-j722s-evm";
    			firmware = "atf";
    			loadables = "tee", "dm", "fdt", "kernel";
    		};
    	};
    };
    


    And here's the r5 changes to try to jump straight to the kernel:

    diff --git a/configs/j722s_evm_r5_defconfig b/configs/j722s_evm_r5_defconfig
    index 0f9828d2..85ce04cd 100644
    --- a/configs/j722s_evm_r5_defconfig
    +++ b/configs/j722s_evm_r5_defconfig
    @@ -24,7 +24,7 @@ CONFIG_DA8XX_GPIO=y
     CONFIG_DM_PCA953X=y
     CONFIG_SPL_DM_PCA953X=y
     CONFIG_OF_BOARD_SETUP=y
    -CONFIG_SPL_STACK_R_ADDR=0x82000000
    +CONFIG_SPL_STACK_R_ADDR=0x89000000
     CONFIG_SPL_SYS_MALLOC_F_LEN=0x8000
     CONFIG_SPL_NAND_SPI_SUPPORT=y
     CONFIG_SPL_MTD_SUPPORT=y
    @@ -36,7 +36,7 @@ CONFIG_SPL_LIBDISK_SUPPORT=y
     CONFIG_SPL_SPI_FLASH_SUPPORT=y
     CONFIG_SPL_SPI=y
     CONFIG_SPL_LOAD_FIT=y
    -CONFIG_SPL_LOAD_FIT_ADDRESS=0x80080000
    +CONFIG_SPL_LOAD_FIT_ADDRESS=0x84000000
     # CONFIG_DISPLAY_CPUINFO is not set
     CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y
     CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
    @@ -52,7 +52,7 @@ CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x200000
     CONFIG_SPL_SEPARATE_BSS=y
     CONFIG_SYS_SPL_MALLOC=y
     CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y
    -CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x84000000
    +CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x90000000
     CONFIG_SYS_SPL_MALLOC_SIZE=0x1000000
     CONFIG_SPL_EARLY_BSS=y
     CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
    @@ -145,3 +145,5 @@ CONFIG_SPL_TIMER=y
     CONFIG_OMAP_TIMER=y
     CONFIG_LIB_RATIONAL=y
     CONFIG_SPL_LIB_RATIONAL=y
    +CONFIG_TEXT_BASE=0x83000000
    +CONFIG_SYS_LOAD_ADDR=0x84000000
    \ No newline at end of file
  • I noticed src_ptr was the same value as the bl31.bin from the tispl.its_lin from the other forum post. So maybe trying to store the info to 0x70000000 is not accessible or causes some kind of CPU exception.

    Setting the load and entry to 0x9e780000 lets it get further, but now it's stuck with the following prints:

    This is good! Yes the ATF loading address for J722S is different. So now you are able to load ATF. ATF is executing.
    Can you compare the logs with default boot logs and check where in ATF the failure is?

    - Keerthy

  • Hi Keerthy,

    It's booting!

    It seems within the "chosen" node of the device tree I needed to put the bootargs after the stdout-path for it to work.

    For posterity, I also want to include that using this method has memory allocation issues because the memory isn't aligned.
    I had to follow the post here and make more modifications to fix: e2e.ti.com/.../5202491