J784S4XEVM: bootApp OSPI Boot Mode invalid magic number

Part Number: J784S4XEVM
Other Parts Discussed in Thread: UNIFLASH

Hi,

I am currently testing bootApp OSPI boot mode using the J784S4 EVM.

  • SDK Version: RTOS SDK v11.01

After flashing a custom image to OSPI using Uniflash, an "invalid magic number" error occurs during boot.

To rule out issues with my custom image, I also tested using the example images provided in the SDK, but the same problem persists.

file Read Time: 85598
Starting Sciserver..... PASSED
MCU R5F App started at 3873 usecs
Loading BootImage
file Read Time: 13149
Invalid magic number in Single image header
Error parsing Main Domain appimage
BootImage completed, status = -1
Failure during image copy and parsing
Loading BootImage
file Read Time: 14531
Invalid magic number in Single image header
Error parsing Main Domain appimage
BootImage completed, status = -1
Failure during image copy and parsing
Loading BootImage
file Read Time: 15763
file Read Time: 16402
file Read Time: 16798
BootImage completed, status = 0
SBL_SlaveCoreBoot completed for Core ID#0, Entry point is 0x70000000
OSPI flash left configured in Legacy SPI mode.

 OSPI NOR device ID: 0x5b1a, manufacturer ID: 0x34
Boot App: Started at 4088 usec
Boot App: Total Num booted cores = 1
Boot App: Booted Core ID #0 at 18154 usecs
MCU Boot Task started at 4088 usecs and finished at 81492 usecs

For reference, I followed the SDK test procedures.

Booting Linux via OSPI

Generate lateapps by using the following commands

goto <PDK>/packages/ti/boot/sbl/example/boot_app/scripts

Run ./generate_lateapps.sh <board_name>

Multicore images(lateapps) will be generated in <PDK>/packages/ti/boot/sbl/example/boot_app/binary/$BOARD/. Stage1 image corresponds to lateapp1, stage2 image corresponds to lateapp2 and so on.

Build boot_app_ospi by using the following command

make BOARD=<board_name> CORE=mcu1_0 boot_app_mmcsd_linux -sj

Flash images to ospi flash memory at specified address using uniflash tool

sbl_cust_img_mcu1_0_release.tiimage at an offset of 0x0

tifs.bin at an offset of 0x8000

boot_app_ospi_linux_<board_name>_mcu1_0_freertos_TestApp_release.appimage at an offset of 0x100000

stage1 image at an offset of 0x1fc0000

stage2 image at an offset of 0x27c0000

atf_optee.appimage at an offset of 0x1c0000

tidtb_linux.appimage at an offset of 0x7c0000

tikernelimage_linux.appimage at an offset of 0x1ec0000

>>>>>> uniflash tool command
dslite.bat --mode processors -c COM18 -f C:\ti\uniflash_9.4.1\processors\FlashWriter\j784s4_evm\uart_j784s4_evm_flash_programmer_release.tiimage -i 0
dslite.bat --mode processors -c COM18 -f D:\TI\rtos_app\ospi_boot\sbl_cust_img_mcu1_0_release.tiimage -d 3 -o 0 
dslite.bat --mode processors -c COM18 -f D:\TI\rtos_app\ospi_boot\tifs.bin -d 3 -o 80000
dslite.bat --mode processors -c COM18 -f D:\TI\rtos_app\ospi_boot\boot_app_ospi_linux_j784s4_evm_mcu1_0_freertos_TestApp_release.appimage -d 3 -o 100000
dslite.bat --mode processors -c COM18 -f D:\TI\rtos_app\ospi_boot\multicore_MCU2_0_MCU2_1_stage1.appimage -d 3 -o 0x1fc0000
dslite.bat --mode processors -c COM18 -f D:\TI\rtos_app\ospi_boot\multicore_DSPs_MCU3_0_MCU3_1_MCU4_0_MCU4_1_stage2.appimage -d 3 -o 27c0000

dslite.bat --mode processors -c COM18 -f D:\TI\rtos_app\ospi_boot\atf_optee.appimage -d 3 -o 1c0000
dslite.bat --mode processors -c COM18 -f D:\TI\rtos_app\ospi_boot\tidtb_linux.appimage -d 3 -o 7c0000
dslite.bat --mode processors -c COM18 -f D:\TI\rtos_app\ospi_boot\tikernelimage_linux.appimage -d 3 -o 1ec0000

The error occurs in the SBL_MulticoreImageParse function. This function is called for both MMC/SD and OSPI boot modes. The same lateapp1 and lateapp2 images are used in both cases.

  • MMC/SD boot: works correctly
    • magic number 0x5254534d 0x5254534d
      file Read Time: 171091
      magic number 0x5254534d 0x5254534d
      file Read Time: 359769
  • OSPI boot: results in "invalid magic number" error

Below is the hex dump of the lateapp1 image.

image.png

I have checked similar issues discussed in forums, but could not find a clear solution.

Any help would be greatly appreciated.

  • Hi,

    Have you also flashed tuning data at the last sector of the flash? This is required for the tuning.. 

    Regards,

    Brijesh

  • Hi Brijesh,

    Thank you for your response.

    Regarding the “tuning data” you mentioned, are you referring to using the image shown below?

    dslite.bat --mode processors -c COM18 -f C:\ti\uniflash_9.4.1\processors\FlashWriter\j784s4_evm\nor_spi_patterns.bin -d 3 -o 3FC0000
    C:\ti\uniflash_9.4.1>dslite.bat --mode processors -c COM18 -f C:\ti\uniflash_9.4.1\processors\FlashWriter\j784s4_evm\nor_spi_patterns.bin -d 3 -o 3FC0000
    Executing the following command:
    > C:\ti\uniflash_9.4.1\processors\ProcessorSDKSerialFlash.exe -c COM18 -f C:\ti\uniflash_9.4.1\processors\FlashWriter\j784s4_evm\nor_spi_patterns.bin -d 3 -o 3FC0000
    
    For more details and examples, please refer to the UniFlash Quick Start guide.
    
    
    ----------------------------------------------------------------------------
    ProcessorSDKSerialFlash CLI Tool
    Copyright (C) 2017-2023 Texas Instruments Incorporated - http://www.ti.com/
    Version 1.10.0.0
    ----------------------------------------------------------------------------
    Transferring the Image to Flash Programmer..
    
    Transferring Header Information..
    Header Transfer Complete!
    
    Flashing Image of size 128 bytes
    Flash Programming Success!

    Even after writing that image, the result is the same and I still get an “invalid magic number” error.

    If “tuning data” refers to something else that needs to be done, could you please share any related links or documentation?

  • Hi,

    No this is correct data, it has to be flashed in the last sector of the flash. Is the address 0x3FC0000 correct? 

    Regards,

    Brijesh

  • I understand after reviewing the post. I am currently checking the relevant chipset documentation. If it works correctly after modifying the sector offset, I will close this issue.

    thank yoy

  • Thank you Brijesh

    I have confirmed that OSPI boot is working correctly.

    However, the issue was not related to the pattern size (it was verified to be 512Mb and the address 0x3FC0000 is correct), but rather an error in the SDK Guide documentation.

    In the guide, the flash layout is described as follows:

    • sbl_cust_img_mcu1_0_release.tiimage at an offset of 0x0
    • tifs.bin at an offset of 0x8000
    • boot_app_ospi_linux_<board_name>_mcu1_0_freertos_TestApp_release.appimage at an offset of 0x100000
    • stage1 image at an offset of 0x1fc0000
    • stage2 image at an offset of 0x27c0000
    • atf_optee.appimage at an offset of 0x1c0000
    • tidtb_linux.appimage at an offset of 0x7c0000
    • tikernelimage_linux.appimage at an offset of 0x1ec0000

    However, the locations of tidtb_linux.appimage and tikernelimage_linux.appimage are swapped.

    If flashed according to the guide, the kernel image overwrites the stage1 image region.

    By reviewing the actual SBL source code, it is clear that:

    • the kernel should be located at 0x7c0000
    • the DTB should be located at 0x1ec0000

    It would be appreciated if the documentation could be updated accordingly.