• State
  • Locked Locked
  • Replies 20 replies
  • Subscribers 98 subscribers
  • Views 701 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TDA4VEN-Q1: OSPI not selected as primary boot when Primary=OSPI, Backup=UART (falls back to UART)

toshiki kouzai
Prodigy 80 points

Part Number: TDA4VEN-Q1
Other Parts Discussed in Thread: UNIFLASH

We are using a custom board based on TDA4VEN (J722S SoC) and programming software into OSPI flash.

Environment

  • SoC: TDA4VEN
  • SDKs:
    • ti-processor-sdk-linux-adas-j722s-evm-11_01_00_03
    • ti-processor-sdk-rtos-j722s-evm-11_01_00_04

Programming procedure

We program OSPI using UART boot mode with Uniflash.

  • Boot mode (UART):
    • SW3: 11011100
    • SW4: 00000000
  • Used image:
    • sbl_uart_uniflash.release.hs_fs.tiimage

The following components are written to OSPI:

  • flash-phy-tuning-data
  • hsm-demo-firmware-j722s-hs-fs.bin
  • linux.appimage.hs_fs
  • u-boot.img
  • sbl_ospi_hlos.release.hs_fs.tiimage

Observed behavior

  1. When booting in OSPI boot mode only:

    • SW3: 11001110
    • SW4: 01000000
      → System boots successfully and SBL from OSPI runs normally.

  2. When booting in Primary = OSPI, Backup = UART:

    • SW3: 11010000
    • SW4: 00110000
      → The device does not boot from OSPI, and instead always falls back to UART boot mode.

This behavior is reproducible not only on our custom board, but also on the J722S EVM.

Question

On our production board, boot-mode switches will not be populated.
Our expected flow is:

  • Use backup UART boot to program OSPI
  • On the next power-up, the device should automatically boot from primary OSPI

However, with the current behavior, OSPI is not selected when Primary=OSPI & Backup=UART.

  • Is this expected behavior for J722S/TDA4VEN?
  • Are there any known limitations, configuration requirements, or recommended solutions?
  • Do we need any additional OSPI header/signature configuration for the ROM/SBL to accept OSPI as a valid primary boot source in this mode?

Any guidance would be appreciated.

  • 0
    TI__Intellectual 2570 points

    Hi Toshiki,

    can you please share the document from which you are referring the primary/backup boot mode setting, As i saw in the TRM, Primary boot mode setting for OSPI and UART is different from what you shared.



    Shared the screen shot of J722S TRM.

    and also check if "primary boot mode config switch [6]" makes any difference.

    Please share me the section where it say "OSPI boot mode,  Primary boot mode and backup boot" pin settings.

    toshiki kouzai said:
    When booting in OSPI boot mode only:
    toshiki kouzai said:
    When booting in Primary = OSPI, Backup = UART

    Regards,

    Anil

  • 0 in reply to Anil Dali
    Prodigy 80 points

    Hi Anil,

    This is for J722S, and for the OSPI and UART boot mode pins, we referred to the following documents.

    J722S MCU+ SDK: EVM Setup
    J722SXH01EVM: [J722S][EVM] ブートモードをeMMCに設定する方法は?- Processors フォーラム - Processors - TI E2Eサポートフォーラム

    Based on the table shared earlier, doesn’t “Primary boot mode config switch [6]” affect the boot mode behavior of J722S?

    Regards,

    Toshiki

  • 0 in reply to toshiki kouzai
    TI__Intellectual 2570 points

    Hi Toshiki,

    Want to understand what makes it different from 

    normal boot settings (Like, OSPI or UART)
    and
    primary & secondary boot settings.

    There should be some switch setting that tells the processor to boot from primary boot setting and secondary boot settings.

    I have gone through the primary and secondary switch setting from from TRM: It is correct only. (I had confusion over B7 bit, but that is "Csel").

    Regards,

    Anil

  • 0 in reply to Anil Dali
    TI__Intellectual 2570 points

    and also, after switching to "Primary & Secondary" boot mode settings, have you flashed the required tiimage's to ospi?

    Regards,

    Anil

  • 0 in reply to Anil Dali
    Prodigy 80 points

    Hi Anil,

    My understanding is that during ROM boot, if a tiimage exists in the primary boot source (OSPI), the device boots from primary OSPI; if not, it falls back to the backup boot mode (UART).
    Is it possible that this understanding is incorrect?

    >and also, after switching to "Primary & Secondary" boot mode settings, have you flashed the required tiimage's to ospi?

    When no tiimage is programmed in OSPI, the device enters UART boot mode, and at that time I program sbl_ospi_hlos.release.hs_fs.tiimage into OSPI via UART.
    Since the tiimage is then present in OSPI, I expected that the next reboot would boot from OSPI.

    Regards,

    Toshiki

  • 0 in reply to toshiki kouzai
    TI__Intellectual 2570 points
    toshiki kouzai said:
    My understanding is that during ROM boot, if a tiimage exists in the primary boot source (OSPI), the device boots from primary OSPI; if not, it falls back to the backup boot mode (UART).

    yes, this is correct.

    and the same images you need to flash when you tried normal UART and OSPI boot mode.

    i.e from normal boot mode you tried to flash following : 

    • sbl_uart_uniflash.release.hs_fs.tiimage, 
    • flash-phy-tuning-data
    • hsm-demo-firmware-j722s-hs-fs.bin
    • linux.appimage.hs_fs
    • u-boot.img
    • sbl_ospi_hlos.release.hs_fs.tiimage

    so same images we need to flash when trying from primary & secondary boot mode.

    Regards.

    Anil

  • 0 in reply to Anil Dali
    Prodigy 80 points

    Hi Anil,

    We are flashing the same images for both the normal boot mode and the primary & secondary boot mode.

    Regards,

    Toshiki

  • 0 in reply to toshiki kouzai
    TI__Intellectual 2570 points

    can you please share the images for flashing via UART?

    It will take some time to build the binaries from the package.

  • 0 in reply to Anil Dali
    Prodigy 80 points

    Hi Anil,

    We will share the UART Uniflash and SBL OSPI TI images.
    Both images are used as-is from the following path:

    /ti-processor-sdk-rtos-j722s-evm-11_01_00_04/mcu_plus_sdk_j722s_11_01_00_15/tools/boot/sbl_prebuilt/j722s-evm/

    8372.tiimage.zip

    Additionally, for reference, we will also share the contents of the cfg file used by
    /ti-processor-sdk-rtos-j722s-evm-11_01_00_04/mcu_plus_sdk_j722s_11_01_00_15/tools/boot/uart_uniflash.py.
    --flash-writer=/home/kozai/cms_proj/uniflash_img/sbl_uart_uniflash.release.hs_fs.tiimage

# Program the OSPI PHY tuning attack vector
--operation=flash-phy-tuning-data

# Now send one or more files to flash or flashverify as needed. The order of sending files does not matter
# Hsm binary
--file=/home/kozai/ti/ti-processor-sdk-rtos-j722s-evm-11_01_00_04/mcu_plus_sdk_j722s_11_01_00_15/tools/boot/hsm_bin/hsm-demo-firmware-j722s-hs-fs.bin --operation=flash --flash-offset=0x80000

# MulticoreApp
--file=/home/kozai/cms_proj/linuxAppimageGen_tr/board/j722s-evm/linux.appimage.hs_fs --operation=flash --flash-offset=0xC0000

# Flash U-Boot.img
--file=/home/kozai/ti/ti-processor-sdk-rtos-j722s-evm-11_01_00_04/mcu_plus_sdk_j722s_11_01_00_15/tools/boot/hlos_prebuilt/j722s-evm/linux/u-boot.img --operation=flash --flash-offset=0x280000

# When sending bootloader make sure to flash at offset 0x0. ROM expects bootloader at offset 0x0
--file=/home/kozai/cms_proj/sbl_ospi_hlos/j722s-evm/wkup-r5fss0-0_nortos/ti-arm-clang/sbl_ospi_hlos.release.hs_fs.tiimage --operation=flash --flash-offset=0x0


    Regards,
    Toshiki

  • 0 in reply to toshiki kouzai
    TI__Intellectual 2570 points

    Yes, I am also facing the similar issue (But tried with simple uart example, not linux.appimage)

    Attached the .cfg file which I used to flash the uart image to ospi.
    default_sbl_null_nor_hs_fs.cfg

    But to make sure "primary and secondary boot modes" are working on the EVM:

    Try with:

          Primary - I2C
          Secondary -  UART 

       Or different combinations to make sure no other switch setting causing this problem.

    - If facing the same issue try with any other J7 Platform: (J784S4, J721S2)

    Regards,

    Anil

  • 0 in reply to Anil Dali
    Prodigy 80 points

    Hi Anil,

    We tried setting xSPI as the Primary boot source and UART as the Backup, and confirmed that OSPI boot was executed correctly.
    In this mode, to check whether the system falls back to the backup UART when nothing is programmed in OSPI, we initialized OSPI in U-Boot and then rebooted the system. As a result, we confirmed that it entered UART boot mode.
    • SW3: 11001110
    • SW4: 01110000
    The OSPI initialization on U-Boot was performed using the following commands: =>sf probe and =>sf erase 0 0x4000000.

    However, when we attempted to program the device in the backup UART boot mode, although the write operation appeared to be progressing, it eventually resulted in an error. After that, attempting to boot using OSPI no longer executed anything.
    When UART boot mode is configured as the backup, does it become impossible to perform write operations to OSPI?
    Regards,
    Toshiki
  • 0 in reply to toshiki kouzai
    TI__Intellectual 2570 points

    Hi Toshiki,

    can you please try with the above images which i shared with xSPI boot mode as you mentioned?

    (want to give a try with simple example i.e without linux images) 

    Regards,

    Anil

  • 0 in reply to Anil Dali
    Prodigy 80 points

    Hi Anil,

    Are you suggesting that we try Primary: xSPI boot and Backup: UART boot?
    In this configuration, we attempted programming while omitting the Linux image, but it still resulted in an error.
    This is the programming log during UniFlash operation.
    kozai@VMUbuntu:~/cms_proj$ ./uart_uniflash_mcucoreSolo.sh 

Parsing config file ...
Parsing config file ... SUCCESS. Found 3 command(s) !!!

Executing command 1 of 3 ...
Found flash writer ... sending /home/kozai/cms_proj/uniflash_img/sbl_uart_uniflash.release.hs_fs.tiimage
Sent flashwriter /home/kozai/cms_proj/uniflash_img/sbl_uart_uniflash.release.hs_fs.tiimage of size 329295 bytes in 33.24s.

Executing command 2 of 3 ...
Command arguments : --operation=flash-phy-tuning-data
Sent flash phy tuning data in 1.63s.                                                                                                                                       
[STATUS] SUCCESS !!!

Executing command 3 of 3 ...
Command arguments : --file=/home/kozai/cms_proj/mcu_core/j722s-evm/mcu-r5fss0-0_freertos/ti-arm-clang/mcu_core.release.appimage.hs_fs --operation=flash --flash-offset=0xC0000
Sent /home/kozai/cms_proj/mcu_core/j722s-evm/mcu-r5fss0-0_freertos/ti-arm-clang/mcu_core.release.appimage.hs_fs of size 1091070 bytes in 108.4s.                           
[STATUS] ERROR: Flash verify failed !!!

All commands from config file are executed !!!

    When programming with Primary: UART, the write operation succeeds, but no logs are output at boot time.
    Regards,
    Toshiki
  • 0 in reply to toshiki kouzai
    TI__Intellectual 2570 points
    toshiki kouzai said:
    Are you suggesting that we try Primary: xSPI boot and Backup: UART boot?

    yes Toshiki,

    and can you please try the following from your end, if still facing issue we will have the call to discuss.

    Try with xSPI boot mode setting (Primary = ospi & Backup = uart)

    • SW3: 11001110
    • SW4: 01110000

    from above boot setting, try flashing simple uart example binary from the following .cfg file. (No linux image/No Uniflash tool is required)

    Attached the steps to run the .cfg file

    Attached the .cfg file used for flashing the images. 

    default_sbl_ospi_hlos_hs_fs.cfg

    Regards,

    Anil

  • 0 in reply to Anil Dali
    Prodigy 80 points

    Hi Anil,

    The issue where no logs were output at boot after programming with Primary: UART has been resolved.
    The cause was that the data size was too large and overflowed into the address that had been offset.

    However, the issue where programming results in an error when Primary = OSPI and Backup = UART is still not resolved.

    Sorry, but we were unable to access and receive default_sbl_ospi_hlos_hs_fs.cfg.

    Regards,

    Toshiki

  • 0 in reply to toshiki kouzai
    TI__Intellectual 2570 points

    Steps to run the .cfg file:

    - Set the board in UART boot mode (Primary = OSPI and Backup = UART, by erasing the older images from ospi)

    - Run the "default_sbl_ospi_hlos_hs_fs.cfg" from the following directory (as shown in the above image)

          cd {sdk_install_path}/tools/boot

    From linux:

    python -p uart_uniflash.py -p /dev/ttyUSB* --cfg=default_sbl_hlos_hs_fs.cfg

    From windows:

    python -p uart_uniflash.py -p COM*  --cfg=default_sbl_hlos_hs_fs.cfg

    (ttyUSB* or COM* should be selected based on "CCCCCC..." characters coming on the terminal emulators).

    After successfully flashing the images, we will be getting the output from OSPI. 

    (First try with normal boot mode, then try with Primary & Backup boot mode.)

    Regards,

    Anil

  • 0 in reply to Anil Dali
    Prodigy 80 points

    Hi Anil,

    I tried to carry this out, but I was told that it cannot be done because default_sbl_hlos_hs_fs.cfg does not exist.
    That is why I assumed the CFG file was being shared by you.

    Also, please note that this environment does not have python, so I am using python3 instead.

    kozai@VMUbuntu:~/ti/ti-processor-sdk-rtos-j722s-evm-11_01_00_04/mcu_plus_sdk_j722s_11_01_00_15/tools/boot$ python3 uart_uniflash.py -p /dev/ttyUSB2 --cfg=default_sbl_hlos_hs_fs.cfg
[ERROR] Configuration file [default_sbl_hlos_hs_fs.cfg] not found !!!

    Regards,

    Toshiki

  • 0 in reply to toshiki kouzai
    TI__Intellectual 2570 points

    Hi Toshiki,

    Sorry for late reply.

    Can you please use the following command to flash sbl.

    python3 uart_uniflash.py -p /dev/ttyUSB2 --cfg=sbl_prebuilt/j722s-evm/default_sbl_ospi_hlos_hs_fs.cfg

    Regards,

    Anil

  • 0 in reply to Anil Dali
    TI__Intellectual 2570 points

    yes Toshiki,

    I am able to run the above command in primary & secondary boot mode!!

    I tried following: 

    I. Run the below command to flash the any example (I have taken simple UART example), keeping in the (Primary = ospi & Backup = uart)

    • SW3: 11001110
    • SW4: 01110000

    python3 uart_uniflash.py -p /dev/ttyUSB2 --cfg=sbl_prebuilt/j722s-evm/default_sbl_ospi_hlos_hs_fs.cfg

    II. But while running the above command make sure to disconnect /dev/ttyUSB2) (The com port in which we are observing CCCCC characters)

    III. We will be able to see the console logs on UART0 port.

    Booting HSM core ...
    Calling Sciclient_procBootGetProcessorState, ProcId 0x80...
    Calling Sciclient_procBootRequestProcessor, ProcId 0x80...
    Setting HALT for ProcId 0x80...
    Calling Sciclient_procBootAuthAndStart ...
    ERROR: App_loadAndAuthHsmBinary:268: Sciclient_procBootAuthAndStart...FAILED
    Clearing HALT for ProcId 0x80...
    Calling Sciclient_procBootReleaseProcessor, ProcId 0x80...
    HSM Core booted successfully
    Some tests have failed!!
    ASSERT: 0.104395s: ../main.c:main:350: 0 failed !!!

    Though it is failing, but we can say primary & secondary boot mode is working.

    For this I have tried erasing the complete OSPI flash, Then I am able to get the CCCCC characters on ttyUSB2 , which means UART as primary boot mode is working, 

    after this again if i try to flash the OSPI , then i am getting the above logs. Which means Primary and Secondary boot is working.

    Regards,

    Anil

  • 0 in reply to Anil Dali
    Prodigy 80 points

    Hi Anil,

    Thank you very much.
    I apologize, but due to a one‑week extended holiday, my confirmation and response with the results will be delayed. Please bear with me for a little while.

    Regards,

    Toshiki