• State TI Thinks Resolved
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 47 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM6442: AM6442 – Questions About Boot Flow, Dev Boot Mode, SBL Null and SoC Initialization Binary

Kacper Kowalski
Prodigy 30 points

Part Number: AM6442

Hi,

I am currently bringing up a custom board based on the AM6442. At the moment, I do not have working OSPI flash access, so I am trying to understand the boot flow in detail and how Dev Boot mode interacts with the SoC initialization binary and SBL.

While reading the documentation, I got confused about a few things related to:

  • SoC initialization binary

  • SBL Null

  • Dev Boot mode

  • No Boot mode

  • DMSC / SYSFW behavior

  • JTAG debugging via CCS

I would appreciate clarification on the following.

1. SoC Initialization Binary – Why Does It Need to Be Flashed Only Once?

In the getting started guides, it is mentioned that the SoC initialization binary needs to be flashed.

My understanding is:

  • It initializes certain SoC components.

  • It prepares the device for proper debugging and boot.

However, I don’t understand why it needs to be run only once.

Questions:

  1. What exactly does the SoC initialization binary configure?

  2. Does it modify any non-volatile state inside the SoC?

  3. Does it program something inside:

    • DMSC?

    • SYSFW?

    • eFuses?

    • Some persistent configuration region?

  4. If it does not modify any non-volatile memory, why isn’t it required every boot?

What exactly changes in the system after it has been executed once?

2. Dev Boot Mode – Is Anything Executed From Flash?

Another confusing topic is Dev Boot mode.

If I understand correctly:

  • In Dev Boot mode, the ROM does not boot from OSPI.

  • We can connect via JTAG and load code into RAM.

Questions:

  1. In Dev Boot mode, is any code executed from flash at all?

  2. Is SBL Null executed in Dev Boot mode?

  3. If not, then how is the SoC initialized sufficiently for:

    • JTAG access

    • Loading code into RAM

    • Using SCI client APIs?

What exactly initializes the DMSC / SYSFW in Dev Boot mode?

3. Why Must SBL Null Be Flashed Again for Debugging?

Documentation states that:

If another application is flashed, and you want to debug using CCS, you need to flash SBL Null again.

This makes me think that:

  • Something from flash must be executed during boot

  • Otherwise, why would reflashing SBL Null matter?

Questions:

  1. In which boot modes is SBL Null actually executed?

  2. Is it correct that in OSPI boot mode, the ROM loads SBL from flash?

  3. In Dev Boot mode, is SBL completely bypassed?

  4. If Dev Boot bypasses flash, why does the documentation require reflashing SBL Null for debugging?

I am trying to understand whether Dev Boot mode truly avoids flash entirely, or whether there is still some interaction.

4. What Happens If I Use Dev Boot Mode Without Ever Flashing the SoC Init Binary?

Suppose:

  • I have a fresh custom board

  • No flash programmed

  • Boot mode set to Dev Boot

  • I connect via JTAG and load an R5 application into SRAM

What happens internally?

Specifically:

  1. Is DMSC / SYSFW running automatically from ROM?

  2. If my application calls SCI Client APIs, will they work?

  3. Or will they hang because DMSC is not properly initialized?

  4. Is it possible that:

    • RAM loading works

    • But SCI calls block because SYSFW is not ready?

I am trying to understand whether missing SoC initialization causes:

  • JTAG load failure

  • Peripheral clocks not enabled

  • SCI server not responding

  • Or something else

5. No Boot Mode – How Is It Different From Dev Boot?

What is the exact difference between:

  • Dev Boot mode

  • No Boot mode

In terms of:

  • ROM execution

  • SYSFW / DMSC startup

  • Peripheral initialization

  • JTAG availability

In No Boot mode:

  • Is SYSFW started?

  • Is DMSC running?

  • Or is the device left in a more minimal state?

6. High-Level Clarification I’m Looking For

I would really appreciate a simplified but technically precise explanation of:

  1. What always runs from ROM

  2. When SYSFW is loaded

  3. When SBL is required

  4. When flash is accessed

  5. What the SoC initialization binary actually changes

Right now the interaction between:

  • ROM

  • SYSFW / DMSC

  • SBL

  • Dev Boot

  • No Boot

  • JTAG debugging

is not fully clear to me.

Thanks in advance for clarifying.

  • 0
    TI__Genius 17420 points

    Hi,

    Kacper Kowalski said:
    SoC Initialization Binary – Why Does It Need to Be Flashed Only Once?

    We flash SBL NULL for SoC Initialization it is already mentioned in the documentation: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_02_00_24/exports/docs/api_guide_am64x/EVM_SETUP_PAGE.html#EVM_FLASH_SOC_INIT 

    So as long as SBL NULL is flashed and it is not overwritten by anything else, you don't need to re-flash it.

    You can check SBL NULL example from MCU+SDK to understand what all is initialized, mostly it initializes DDR, all cores and puts them into a WFI state, so you can load any application to a particular core via CCS: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_02_00_24/exports/docs/api_guide_am64x/EXAMPLES_DRIVERS_SBL_NULL.html 

    Kacper Kowalski said:
    Dev Boot Mode – Is Anything Executed From Flash?

    Nothing is executed from Flash in dev boot mode, ROM will do some minimal hardware configurations to allow access to R5F0-0 via JTAG, then the user needs to do further initialization and load sysfw and boardcfg. In the MCU+SDK we use the following example to do the same: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_02_00_24/exports/docs/api_guide_am64x/EXAMPLES_DRIVERS_SCICLIENT_CCS_INIT.html, so we first initialize the SoC using this script via CCS and then we can load any application to any core via CCS. SBL is not really a requirement when booting in Dev boot mode.

    Kacper Kowalski said:
    Why Must SBL Null Be Flashed Again for Debugging?

    It is mentioned in the documentation that you need to flash SBL NULL to the OSPI and then you boot in OSPI boot mode to run the SoC initialization binary: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_02_00_24/exports/docs/api_guide_am64x/EVM_SETUP_PAGE.html#EVM_FLASH_SOC_INIT, it is flashed at 0x0 offset in flashed. Let's say at later point you are flashing another SBL at the same offset then your SBL NULL is overwritten and no longer exists at 0x0, so if you need to use it again, you need to re-flash it at 0x0.

    For questions 4 and 5, please refer to section 4.4.11 No boot/Development boot in the TRM.

  • 0 in reply to Meet Thakar
    Prodigy 30 points

    Hi,

    Thanks for the reply. I appreciate the links, but the documentation you referenced is exactly what I’ve already read. My confusion is about the detailed runtime behavior, not about where the examples are located.

    Let me try to clarify the exact scenario that is unclear to me.

    You stated that:

    Nothing is executed from Flash in Dev Boot mode.

    And I understand that in Dev Boot mode, the ROM does only minimal hardware setup and enables JTAG access to R5F0-0.

    However, here is what I observe in practice:

    1. I flash SBL NULL to OSPI and boot once in OSPI boot mode.

    2. The SoC initializes properly.

    3. I then switch to Dev Boot mode and can debug via CCS without problems.

    4. The next day, I power-cycle the board.

    5. Boot mode is still set to Dev Boot.

    6. I do not explicitly run any SysFW loading script.

    7. I do not boot from OSPI.

    8. Yet I can still connect via CCS and load/debug applications normally.

    This creates the following fundamental question:

    If Dev Boot mode truly executes nothing from OSPI, and if nothing persistent was modified by SBL NULL, then after a full power cycle:

    Why does everything still work?

    More concretely:

    • Does SBL NULL modify any persistent state?

    • Does it program anything into DMSC?

    • Does it alter some internal non-volatile configuration?

    • Does SYSFW get loaded automatically from ROM in Dev Boot?

    • Is CCS silently running the sciclient_ccs_init sequence behind the scenes?

    • Is the ROM loading SYSFW internally even in Dev Boot?

    • Or is JTAG access and RAM loading possible even without SYSFW fully initialized?

    What I’m trying to understand is:

    Is there any “one-time” effect from running SBL NULL once, or is that assumption incorrect?

    Because logically, after a cold power cycle in Dev Boot mode, the SoC should be in a clean reset state. If nothing is executed from OSPI, and I do not manually initialize SysFW or board configuration, then the system should behave as if SBL NULL had never run.

    Yet that is not what I observe.

    So I am trying to understand:

    • What always runs from ROM on every reset?

    • When and how SYSFW is started in Dev Boot?

    • Whether SYSFW is embedded in ROM or must be loaded externally.

    • Whether SCI client APIs can function without explicitly loading SYSFW.

    • Whether CCS automatically performs hidden initialization steps.

    My confusion is specifically about the apparent contradiction between:

    “Nothing runs from Flash in Dev Boot mode”

    and

    “You only need to flash SBL NULL once”

    Because those two statements together imply some persistent effect, which I cannot reconcile with the reset behavior of the SoC.

    I would really appreciate a more detailed explanation of the exact boot flow and SYSFW behavior during:

    • OSPI boot

    • Dev Boot

    • No Boot

    especially what runs from ROM every time versus what must be explicitly loaded.

    Thanks again — I’m trying to build a precise mental model of the boot sequence.