AM62P: Sleep Mode control

Part Number: AM62P

Hi TI Expert,

In TRM of "spruj83c.pdf", in chapter public ROM, it mentioned:

image.png

As we known, the "M4" in am62px SoC family, it is part of SMS sub system (TIFS/HSM), and during boot time, it will run secure ROM, but why it will direct Public ROM to sleep? this seems responsible of R5F_DM? for wakeup sequence, it also mentioned DM is actived before than others:

image.png

My question is: 

What this "M4" means? during Public ROM "main module", if no boot images received, M4 (DM or M4F_core0) will send signal "sleep" to the public ROM goto sleep?

Thanks in advance

 

  • Hello Tim,

    You are not using the latest revision of the TRM document. You can download the latest one (rev. D) from here:
    https://www.ti.com/product/AM62P

    As we known, the "M4" in am62px SoC family, it is part of SMS sub system (TIFS/HSM), and during boot time, it will run secure ROM, but why it will direct Public ROM to sleep? this seems responsible of R5F_DM?

    The M4 core is the first and only core to execute from the Public ROM at power-on. The R5F_DM plays no role in this, it only takes over after the ROM has been gated off by TIFS. Since the M4 is the secure-boot authority (running the TIFS/HSM firmware), it is the logical entity to decide when the ROM is no longer needed and should be gated off. These are some reasons:

    • Security isolation- After secure boot, the ROM must be hidden from non-secure masters (R5F, A53, etc.). Putting it to sleep prevents any malicious core from reading ROM contents.
    • Boot-order enforcement- The non-secure side (R5F_DM, A53) must never run before the ROM has been verified and hidden. The M4/TIFS enforces this ordering.

    You can see the boot process flow in the AM62P TRM in section 5. Initialization, point 5.2. Boot Process, point 5.2.3. Boot Process Flow.

    What this "M4" means? during Public ROM "main module", if no boot images received, M4 (DM or M4F_core0) will send signal "sleep" to the public ROM goto sleep?

    In the AM62Px architecture, "M4" refers to the M4F_core0, which is part of the SMS (Secure Management Subsystem). Specifically, it is the core that runs the TIFS (TI Foundational Security) / HSM firmware. The M4F_core0 (TIFS/HSM) is responsible for issuing the sleep request to the Public ROM. The R5F_DM plays no role in this sleep signaling.

    Best Regards,

    Borislav Lazarkov

  • Thanks for so quickly reply.

    What means of this sentence? Is it mean the Public ROM will running on M4F_core0? 

  • Hello Tim,

    When the AM62Px powers ON, all cores are in reset except the M4F. The M4F wakes up, reads and executes the Public ROM code, performs hardware initialization and security verification, and only then releases other cores (R5F_DM, A53) from reset. No other core ever directly runs from the Public ROM.

    Best Regads,

    Borislav Lazarkov

  • Hi Borislav, 

    So the Public ROM will be the first executing code, and it will execute on M4F core0.

    Then what about Secure ROM? does it mean, if Public ROM need secure ROM to authentication, Public ROM will request M4F core0 to read and execute Secure ROM, and secure ROM also runs on M4F Core0 too?

    And which ROM will load other images?  (e.g. TIFS, R5F_SBL...), Public ROM or Secure ROM?

    Best Regards.

  • Hello Tim,

    The M4F wakes up, reads and executes the Public ROM code, performs hardware initialization and security verification, and only then releases other cores (R5F_DM, A53) from reset.

    I was just listing them, there are not in order. I apologize for the mistake.

    for wakeup sequence, it also mentioned DM is actived before than others:

    image.png

    That excerpt is from the AM62Px TRM, section 6.2.4.11 Low Power Mode Sequencing with Device Manager, which covers the wakeup from Deep Sleep, not the cold boot sequence.

    So the Public ROM will be the first executing code, and it will execute on M4F core0.

    Then what about Secure ROM? does it mean, if Public ROM need secure ROM to authentication, Public ROM will request M4F core0 to read and execute Secure ROM, and secure ROM also runs on M4F Core0 too?

    And which ROM will load other images?  (e.g. TIFS, R5F_SBL...), Public ROM or Secure ROM?

    As you can see on the picture M4 ROM executes first, not R5 (Public ROM). On the figure in the yellow boxes, R5 (Public ROM) handles boot image loading. R5 (Public ROM) loads the image. R5 requests M4 for Image Integrity Check — M4 performs the authentication. M4 responds with pass/fail- if it fails, it will retry or abort.

    Best Regards,

    Borislav Lazarkov

  • Sorry, a little confused for me:

    1. the M4 ROM (I guess this mean Secure ROM, right?) will be 1st executed.

    2. You mentioned R5 (Public ROM), do you mean the Public ROM will execute on R5F core0? if Yes, seems conflict with your previous description:

    3. You said the R5 (public ROM) will handle boot image loading, and request M4 for image integrity check, but in TRM chapter 5.2.2:

    It mentioned M4 ROM (Secure ROM) will handle M4 image (I guess it is TIFS firmware) loading. this is confused to me. Other TI Expert told me, the 5.2.2 chapter is correct, the above description of "R5 ROM" load TIFS is incorrect, and he said, will have new process:

    please help to double check.

    Thanks very much!

    Beat Regards!

  • Hello Tim,

    1. the M4 ROM (I guess this mean Secure ROM, right?) will be 1st executed.

    Yes, M4 ROM (Secure ROM) will be executed first.

    You mentioned R5 (Public ROM), do you mean the Public ROM will execute on R5F core0? if Yes, seems conflict with your previous description:

    M4F_core0 wakes up and executes the M4 ROM (Secure ROM). The Public ROM runs on R5F_core0 only after M4 ROM releases R5 from reset.

    You said the R5 (public ROM) will handle boot image loading, and request M4 for image integrity check, but in TRM chapter 5.2.2:

    After reviewing TRM Section 5.2.2 alongside the watchdog timer note, the correct picture is actually more nuanced than what both my earlier response and the Figure 5-3 description suggested:

    Corrected Boot Image Loading Flow:

    • M4 ROM executes first on M4F_core0— sets up watchdog timer (RTI0, 3 minutes), configures PLLs, firewalls, Secure Proxy, SA2UL, and releases R5 from reset
    • R5 Public ROM executes second on R5F_core0— handles boot media detection and loads SBL/SPL, all within the 3-minute watchdog window
    • Once SBL is loaded, M4 ROM restarts the watchdog for an additional 3 minutes
    • The customer-provided R5 SBL then takes responsibility for loading and installing TIFS/SYSFW into M4

    When Section 5.2.2 mentions "M4 firmware loading", this refers to the security infrastructure that M4 ROM sets up (SA2UL, SHA512 integrity checks, X509 certificate parsing, Secure Proxy) to facilitate and authenticate the SYSFW loading, rather than M4 ROM directly transferring the SYSFW image itself.

    R5 (via Public ROM and then SBL) is responsible for the actual image loading, while M4 ROM provides the security framework and watchdog supervision around the entire process. Hong Guan64's note about the combined boot flow aligns with this, the combined binary blob (SBL + SYSFW) is what R5 SBL handles in the new flow.

    I apologize for the earlier inaccuracy!

    Best Regards,

    Borislav Lazarkov

  • Thanks for so detail explanation.

    So actually, M4 (Secure ROM) will first run to authenticate the boot image (tiboot3.bin, --- TIFS + R5F_SBL_stage1...), and if passed, then R5F public ROM will handle to load the image into relevant cores (TIFS--->M4F_core0, R5F_SBL_Stage1---->R5F_core0), am I correct?

    I also asked another topic:

    AM62P: Bootloader of SBL Stage1 running - Processors forum - Processors - TI E2E support forums

    the Expert (Prashant Shivhare)  also told me, the Secure ROM will load TIFS + R5F_SBL_Stage1 image.

    So confused me. 

    B.R.

    Thanks again

  • Hello Tim,

    Let me ask Prashant for this question.

    Please give me some time. Thank you for your patience!

    Best Regards,

    Borislav Lazarkov

  • Hello Tim,

    Your statement is partially correct but has some inaccuracies.

    What's correct:

    • M4 ROM executes first
    • M4 ROM handles authentication (SA2UL, SHA512, X509 certificate parsing)
    • TIFS eventually runs on M4F_core0
    • R5F SBL eventually runs on R5F_core0

    What's incorrect:

    • Authentication timing
      • M4 ROM doesn't authenticate before R5 loads the image. The flow is:
        • R5 Public ROM first loads the image (tiboot3.bin) from boot media
        • Then requests M4 ROM to authenticate it via SA2UL/SHA512
        • Authentication is a collaborative step, not a prerequisite gate before R5 even starts
    • "R5F Public ROM loads images into relevant cores". This is not quite right either.
      • R5 Public ROM loads SBL/SPL only
      • It is the R5 SBL (customer image) that loads and installs TIFS/SYSFW into M4F_core0
      • R5 Public ROM itself doesn't directly load TIFS into M4

    In conclusion, R5 Public ROM loads tiboot3.bin from boot media, then requests M4 ROM for authentication via SA2UL/SHA512. If authentication passes, R5 Public ROM boots the SBL/SPL on R5F_core0. The R5 SBL then takes responsibility for loading and installing TIFS/SYSFW into M4F_core0.

    Best Regards,

    Borislav Lazarkov

  • Hello Borislav 

    Thanks for correcting me so patiently!

    I also have a question, If the SoC wakeup from deep sleep, whether have the boot sequence same with cold boot?

    e.g. Loading and authenticating images? In TRM, Sleep and wakeup sequence seems don't mention this.

    B.R

    Tim

  • Hello Tim Wang,

    Borislav is currently out of office and will be available after mid of the next week.

    The Section, Low Power Mode Sequencing with Device Manager of the AM62P TRM, provides a step by step explanation of the wake-up from Deep Sleep sequence, as follows:

    In the Section, Low Power Mode Reset Handling  of the TRM, the Deep sleep + wake-up and restoration sequences are depicted through the following diagram:

    As can be seen there is MAIN domain reset assertion and de-assertion involved. 

    The AM62Px TRM / Chapter, Initialization/ Section, Boot Process Flow specifies that:

    However I suspect that upon reset  the R5 / M4 execution vectors may be directed or NOT to the AM62P Public ROM Code / M4 ROM  depending on the previous power state of the AM62Px processor system. It is possible that the wake-up from deep sleep is handled by M4F TIFS / SYSFW code + R5F DM code already loaded by SBL during previous power-up boot cycle. As per my understanding the procedure can transfer the On-chip RAM memory code/data to an external  LPDDR during deep sleep and restore it to on-chip SRAM after wake-up.

    Please allow me some time to discuss with our AM62P ROM and Security experts on the routines of image loading / authentication / integrity check and decryption that take place during wake-up from deep sleep. I will try to come back with an answer early next week.

    Thank you for your patience !

    Best Regards,

    Anastas Yordanov

  • Hello Anastas Yordanov

    Thanks very much, waiting your result.

    Best Regards,

    Tim.

  • Hello,

    According to public ROM main loop description:

    When or what condition, the M4 will direct public ROM to go to sleep?

    Thanks

  • Hello Tim,

    When or what condition, the M4 will direct public ROM to go to sleep?

    I can only assume, this happens in one of the highlighted blocks of the Boot Process flowchart:

    I have contacted our AM62P ROM expert for more details and I am awaiting his response.

    Thank you for your patience !

    Best Regards,

    Anastas Yordanov

  • Hi,

    When or what condition, the M4 will direct public ROM to go to sleep?

    This seems to be referring to, the 1st block highlighted by Anastas, where No valid image is found at both primary and backup boot modes.

    Best Regards,

    Meet.

  • Thanks,

    So the sentence " This loop repeats until a boot image has been received or directed to sleep by the M4" can understand as:

    1. the public ROM Main loop will load the boot image file (tiboot3.bin) from external, and request M4 secure ROM to authenticates it. If integrity check OK, the main loop will continue to handle the boot up sequence; this is clear.

    2. If the integrity check failed, will re-try, at same time, the M4 will handle 180s watchdog, if the watchdog timeout, then M4 will direct R5 public ROM to abort boot up sequence, and go to sleep.

    3. If a new R5 reset is triggered, (by whom?), then will restart the boot up sequence.

    Am I Correct? 

    If yes, during R5 sleep status, what about the M4 (secure ROM) operation? it will wait the R5 reset? O nothing?

    Thanks

  • Hello Tim,

    1. the public ROM Main loop will load the boot image file (tiboot3.bin) from external, and request M4 secure ROM to authenticates it. If integrity check OK, the main loop will continue to handle the boot up sequence; this is clear.

    This is correct in spirit, but the flow is slightly more nuanced:

    1. R5 Public ROM loads tiboot3.bin from boot media.
    2. It then passes it to M4 for authentication (cryptographic signature check via SA2UL/SHA512).
    3. If authentication passes, M4 releases R5 from sleep (de-asserts R5 reset) so the main loop continues.

    2. If the integrity check failed, will re-try, at same time, the M4 will handle 180s watchdog, if the watchdog timeout, then M4 will direct R5 public ROM to abort boot up sequence, and go to sleep.

    The watchdog timeout does NOT cause a soft "sleep", it causes a hardware reset of the R5 subsystem. The reset is hardware-driven (watchdog hardware asserts R5 reset line automatically), the M4 does not need to take a software action to trigger it. So "go to sleep" is not quite right, it is more accurately a forced R5 reset, which puts R5 back to its initial public ROM state. The retry loop then restarts automatically after the reset.

     

    3. If a new R5 reset is triggered, (by whom?), then will restart the boot up sequence.

    The M4 core triggers the R5 reset, specifically by writing to the system-controller reset register that controls the R5 reset line. This happens in two scenarios:

    • Authentication succeeds. M4 de-asserts R5 reset to let R5 continue.
    • Watchdog timeout. Hardware forces R5 reset. M4 then re-releases R5 to retry.

    If yes, during R5 sleep status, what about the M4 (secure ROM) operation? it will wait the R5 reset? O nothing?

    M4 remains ACTIVE, it does NOT sleep. While R5 is in sleep/reset state, M4 is busy doing:

    • Running the watchdog timer- Monitors the 180s countdown.
    • Executing authentication- Verifying tiboot3.bin signature via SA2UL/SHA512.
    • Controlling R5 reset line- Holds R5 in reset or releases it based on auth result.
    • May enter WFI briefly- Low-power idle between tasks, but stays alive and responsive.

    Best Regards,

    Borislav Lazarkov