• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 119 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.

AM62P: AM62P: emmc and OSPI boot configs.

Abhijith Raj
Prodigy 205 points

Part Number: AM62P
Other Parts Discussed in Thread: UNIFLASH

Hi,
I am working on AM62P MCU domain.
In mcu flashing cfg from mcu+sdk i have seen two files default_sbl_ospi_linux_hs_fs.cfg and default_sbl_emmc_linux_hs_fs.cfg.

In ospi config

# First point to sbl_uart_uniflash_stage1 binary, which initialises DDR and receives sbl_uart_uniflash_stage2 binary
--flash-writer=sbl_prebuilt/am62px-sk/sbl_uart_uniflash_stage1.release.hs_fs.tiimage

# Points to sbl_uart_uniflash_stage2 binary, which function's as a server to flash one or more files
# Please note this binary is copied to DDR by sbl_uart_uniflash_stage1 and not written to any boot media like flash or eMMC
--file=../../examples/drivers/boot/sbl_uart_uniflash_multistage/sbl_uart_uniflash_stage2/am62px-sk/wkup-r5fss0-0_nortos/ti-arm-clang/sbl_uart_uniflash_stage2.release.appimage.hs_fs --operation=flash --flash-offset=0x0

# 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

# When sending bootloader make sure to flash at offset 0x0. ROM expects bootloader at offset 0x0
--file=sbl_prebuilt/am62px-sk/sbl_ospi_linux_stage1.release.hs_fs.tiimage --operation=flash --flash-offset=0x0

# 2nd stage bootloader with DM is flashed at 0x80000 or to whatever offset your bootloader is configured for
--file=../../examples/drivers/ipc/ipc_rpmsg_echo_linux/am62px-sk/wkup-r5fss0-0_freertos/ti-arm-clang/ipc_rpmsg_echo_linux.release.appimage.hs_fs --operation=flash --flash-offset=0x80000

# When sending application image, make sure to flash at offset 0x100000 (default) or to whatever offset your bootloader is configured for
--file=../../examples/drivers/ipc/ipc_rpmsg_echo_linux/am62px-sk/mcu-r5fss0-0_freertos/ti-arm-clang/ipc_rpmsg_echo_linux.release.appimage.hs_fs --operation=flash --flash-offset=0x800000

# HSM image is flashed at 0x800000 or to whatever offset your bootloader is configured for
--file=HSMAppimageGen/board/am62px-sk/hsm.appimage.hs_fs --operation=flash --flash-offset=0x240000

# Linux image is flashed at 0xC00000 or to whatever offset your bootloader is configured for
--file=linuxAppimageGen/board/am62px-sk/linux.appimage.hs_fs --operation=flash --flash-offset=0x1200000

# u-boot.img is flashed at 0x280000
--file=linuxAppimageGen/board/am62px-sk/u-boot.img --operation=flash --flash-offset=0x280000


In emmc cfg

# First point to sbl_uart_uniflash_stage1 binary, which initialises DDR and receives sbl_uart_uniflash_stage2 binary
--flash-writer=sbl_prebuilt/am62px-sk/sbl_uart_uniflash_stage1.release.hs_fs.tiimage

# Points to sbl_uart_uniflash_stage2 binary, which function's as a server to flash one or more files to eMMC
# Please note this binary is copied to DDR by sbl_uart_uniflash_stage1 and not written to any boot media like flash or eMMC
--file=../../examples/drivers/boot/sbl_uart_uniflash_multistage/sbl_uart_uniflash_stage2/am62px-sk/wkup-r5fss0-0_nortos/ti-arm-clang/sbl_uart_uniflash_stage2.release.appimage.hs_fs --operation=flash --flash-offset=0x0

# Now send one or more files to flash or flashverify as needed. The order of sending files does not matter

# When sending bootloader make sure to flash at offset 0x0. ROM expects bootloader at offset 0x0 of eMMC
--file=sbl_prebuilt/am62px-sk/sbl_emmc_linux_stage1.release.hs_fs.tiimage --operation=flash-emmc --flash-offset=0x0

# 2nd stage bootloader is flashed at 0x80000 or to whatever offset your bootloader is configured for
--file=../../examples/drivers/boot/sbl_emmc_linux_multistage/sbl_emmc_linux_stage2/am62px-sk/wkup-r5fss0-0_freertos/ti-arm-clang/sbl_emmc_linux_stage2.release.appimage.hs_fs --operation=flash-emmc --flash-offset=0x80000

# HSM image is flashed at 0x240000 or to whatever offset your bootloader is configured for
--file=HSMAppimageGen/board/am62px-sk/hsm.appimage.hs_fs --operation=flash-emmc --flash-offset=0x240000

# When sending application image, make sure to flash at offset 0x800000 (default) or to whatever offset your bootloader is configured for
--file=../../examples/drivers/ipc/ipc_rpmsg_echo_linux/am62px-sk/mcu-r5fss0-0_freertos/ti-arm-clang/ipc_rpmsg_echo_linux.release.appimage.hs_fs --operation=flash-emmc --flash-offset=0x800000

# Linux image is flashed at 0x1200000 or to whatever offset your bootloader is configured for
--file=linuxAppimageGen/board/am62px-sk/linux.appimage.hs_fs --operation=flash-emmc --flash-offset=0x1200000

# u-boot.img is flashed at 0x280000
--file=linuxAppimageGen/board/am62px-sk/u-boot.img --operation=flash-emmc --flash-offset=0x280000

 

 

While comparing the two configurations, I noticed a difference in the image flashed at the Stage-2 bootloader offset (0x80000)


ospi config - 
 2nd stage bootloader with DM is flashed at 0x80000 or to whatever offset your bootloader is configured for
--file=../../examples/drivers/ipc/ipc_rpmsg_echo_linux/am62px-sk/wkup-r5fss0-0_freertos/ti-arm-clang/ipc_rpmsg_echo_linux.release.appimage.hs_fs --operation=flash --flash-offset=0x80000

 emmc config 
# 2nd stage bootloader is flashed at 0x80000 or to whatever offset your bootloader is configured for
--file=../../examples/drivers/boot/sbl_emmc_linux_multistage/sbl_emmc_linux_stage2/am62px-sk/wkup-r5fss0-0_freertos/ti-arm-clang/sbl_emmc_linux_stage2.release.appimage.hs_fs --operation=flash-emmc --flash-offset=0x80000

My understanding is that the image at offset 0x80000 is intended to be the Stage-2 bootloader. However, in the OSPI configuration, the file being flashed is the ipc_rpmsg_echo_linux application, whereas in the eMMC configuration it is explicitly the sbl_emmc_linux_stage2 image.

This has led to some confusion regarding the boot flow:

  1. Is the image flashed at 0x80000 in the OSPI configuration actually acting as the Stage-2 bootloader?
  2. Does the Stage-2 bootloader also contain the DM firmware, or are they separate components?
  3. Why is an RPMsg example being flashed at the Stage-2 bootloader offset in the OSPI configuration, while the eMMC configuration uses a dedicated sbl_emmc_linux_stage2 image?
  4. Is the comment "2nd stage bootloader with DM" in the OSPI configuration accurate, or is the RPMsg application simply being used as the WKUP-R5 firmware?

Could someone please clarify the intended boot flow and the role of the image placed at offset 0x80000 in both cases?

  • 0
    TI__Mastermind 22605 points

    Hi,

    Abhijith Raj said:
    • Is the image flashed at 0x80000 in the OSPI configuration actually acting as the Stage-2 bootloader?
    • Does the Stage-2 bootloader also contain the DM firmware, or are they separate components?

    ipc_rpmsg_echo_linux for WKUP-R5 is a multi-threaded application, where 1 thread acts as the bootloader and other as your DM firmware:

    Abhijith Raj said:
    Why is an RPMsg example being flashed at the Stage-2 bootloader offset in the OSPI configuration, while the eMMC configuration uses a dedicated sbl_emmc_linux_stage2 image?

    There is no particular reason behind it, sbl_emmc_linux_stage2 doesn't run the wakeup core application, so it will run the boot thread and do the SciServer init but wouldn't initialize the IPC application, if you need to test ipc, then you can just go ahead and use the ipc rpmsg example as it is done in the OSPI cfg file.

    Best Regards,

    Meet.

  • 0 in reply to Meet Thakar
    Prodigy 205 points

    Hi  ,

    My requirement is to boot the DM/WKUP-R5 core from OSPI with a custom application. For example, I need the firmware running on the DM core to handle a CAN node and a GPIO, so I assume I would need to develop and load custom firmware for that core.

    At the same time, my main application running on MCU R5 should boot from eMMC and execute a different set of features.

    Could you please clarify how this is expected to work with the secondary bootloader? Specifically:

    • How does the secondary bootloader interact with the custom application running on the DM/WKUP-R5 core?
    • Is the custom DM firmware integrated into the secondary bootloader image, or is it loaded separately?
    • If I need a custom application on the DM core, what is the recommended boot flow when the MCU R5 application is booting from eMMC?

    I am trying to understand how the secondary bootloader and the custom DM firmware are combined and loaded during boot.

    Thanks.

  • 0 in reply to Abhijith Raj
    TI__Mastermind 22605 points

    Hi,

    Abhijith Raj said:
    • How does the secondary bootloader interact with the custom application running on the DM/WKUP-R5 core?
    • Is the custom DM firmware integrated into the secondary bootloader image, or is it loaded separately?

    Your ipc_rpmsg_echo for WKUP R5 is a FreeRTOS application, so we create 2 tasks here, please refer to this: https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/am62px-sk/wkup-r5fss0-0_freertos/main.c#L114

    Here, sbl_stage2_main task acts as your SBL Stage-2 and boots the application images for MCU, HSM and A53, while main_thread, initializes SciServer thread and runs your IPC application by calling ipc_rpmsg_echo_main: https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/am62px-sk/wkup-r5fss0-0_freertos/main.c#L94C5-L94C24 

    Abhijith Raj said:
    If I need a custom application on the DM core, what is the recommended boot flow when the MCU R5 application is booting from eMMC?

    You can use the same flow as ipc_rpmsg_echo for your custom application. You can use the IPC example as a base and just call your custom applications main function instead of ipc_rpmsg_echo_main 

    Abhijith Raj said:
    At the same time, my main application running on MCU R5 should boot from eMMC and execute a different set of features.

    Please note that, booting from Dual boot media (OSPI+EMM) is not supported OOB from MCU+SDK, so you will have to make few changes to make this work. You can refer to this FAQ on how you can enable booting from dual boot media:  [FAQ] How to boot from dual boot media (OSPI NOR + eMMC) using MCU+SDK? 

    Please note that according to your requirement you have to change the bootmedia for MCU instance to EMMC instead of Linux Instance.

    Best Regards,

    Meet.