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

AM263P4: SBL - Permanently Read only

Addison Audette
Prodigy 175 points

Part Number: AM263P4

I am using the AM263P and would like to make the memory region containing the Secondary Bootloader (SBL) permanently read-only after it is initially programmed.

Is there any supported mechanism on the AM263P or its associated OSPI flash to make the SBL storage region immutable/one-time programmable, such that it cannot be erased or rewritten by software after provisioning?

Ideally, we would like the SBL to remain executable/readable but permanently prevent any future modification to that region. If this is possible, what hardware or flash protection mechanism would TI recommend?

  • 0
    TI__Mastermind 40653 points

    Hi Addison,

    The AM263P4's OSPI controller does not provide a permanent, hardware-fused, one-time-programmable write-protection mechanism for flash sectors. The available protections are software-controlled and can be reversed at runtime. However, there are layered approaches you can combine to achieve a strong defense against SBL modification.

    The OSPI peripheral includes a software-controlled write protection feature using three registers 1:

    Register Purpose
    OSPI_LOWER_WR_PROT_REG Bottom block of the protected region
    OSPI_UPPER_WR_PROT_REG Top block of the protected region
    OSPI_WR_PROT_CTRL_REG Enable (ENB_FLD) and invert (INV_FLD) control
    When ENB_FLD = 1, any AHB write targeting the protected region is rejected and generates an error response plus interrupt 2. TI recommends enabling this before the OSPI controller is fully enabled after POR to block unintended writes during initialization 1.

    Critical limitation: This is a runtime-only mechanism. The ENB_FLD bit resets to 0 on every power cycle and can be cleared by any software with register access — it is not permanent 2.

    Hardware Write-Protect Pin (ZCZ_F Variant)

    If you are using the AM263P4 ZCZ_F (Flash-in-Package) variant, the OSPI_D2 signal doubles as an active-low hardware Write Protect (WP#) input to the on-die flash. Pin L1 (OSPI0_ZCZ_F_WP) must be pulled up to VDDS33 via a 4.7 kΩ resistor to keep the flash writable 3.

    By driving this pin low (or leaving it unconnected with appropriate pull-down), you can hardware-assert WP# to the flash die. The effectiveness of this depends on the specific flash die's WP# behavior — most NOR flash parts use WP# to protect the Status Register lock bits, not individual sectors directly. You would need to:

    1. Program the flash's Status Register to lock the sectors covering the SBL region (typically offset 0x0 through 0x80000).
    2. Assert WP# low to prevent the Status Register from being modified.

    This provides a board-level hardware lock that software alone cannot override, but it is not truly OTP — physical access to the board could release WP#.

    Recommended Layered Strategy

    Since no single mechanism on the AM263P4 provides true permanent immutability, The architecture supports a defense-in-depth approach:

    1. Secure Boot Chain — The RBL cryptographically verifies the SBL (RSA signature) before executing it. Even if the SBL flash region were somehow modified, a tampered image would fail authentication and the device would not boot it 4.

    2. Anti-Rollback via eFuse OTP Counters — The AM263P4 has hardware-enforced, one-way eFuse counters (32 bits for SBL version). These are permanent and cannot be decremented. Only the HSM core can increment them via HsmClient_writeSWRev() — R5F application cores are completely barred from eFuse access by hardware firewalls 4.

    3. OSPI Write Protection Registers — Configure the SBL region as protected in your SBL's own early init code (before handing off to the application), so the application cannot accidentally or maliciously erase/rewrite the SBL region during normal operation 1.

    4. Flash-Level Sector Protection + WP# Pin — Use the external flash's (or FiP's) sector lock bits combined with the hardware WP# pin to create a board-level lock that resists software-only attacks.

    There is not a true permanent OTP or eFuse-based flash sector lock for the OSPI flash region on the AM263P4. The eFuse OTP mechanism exists only for version counters (anti-rollback), not for arbitrary flash write-protection. If your application requires a formally certified immutable boot region, this may need to be addressed at the external flash part level (some NOR flash devices offer permanent OTP sectors or one-time-lock bits) rather than through the AM263P4 SoC itself.

    1. AM263Px Technical Reference Manual - OSPI Write Protection
    2. AM263Px Register Manual - OSPI_WR_PROT_CTRL_REG
    3. AM263P4 Datasheet - ZCZ_F WP Pin
    4. E2E: AM263P4 Anti-Rollback and Secure Boot

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    Prodigy 175 points

    Thank you for your response, that was very helpful!

    Since the AM263P4 does not provide a permanent internal mechanism to make the SBL storage region immutable, can the ROM Bootloader authenticate and boot an SBL from an external memory or hardware solution that can be permanently locked after programming?

    For example, could the SBL reside in an external memory device or other hardware that remains readable by the AM263P4 RBL but cannot be erased or rewritten once provisioned? Are there any boot-source or interface limitations that would prevent this type of architecture?

  • 0 in reply to Addison Audette
    TI__Mastermind 40653 points
    Hi Addison,
    Great follow-up question. To directly answer: Yes, the AM263P4 RBL can authenticate and boot an SBL from an external NOR flash device that is permanently locked after provisioning — but there are important interface constraints and nuances to understand.
    RBL Boot Source Limitations
    The AM263P4 RBL exclusively supports booting from OSPI-connected NOR flash devices. NAND flash is not supported as a boot source. The supported boot modes (per the AM263Px TRM, Table 5-1) are:
    Boot Mode Boot Media Notes
    QSPI (4S), 50 MHz External QSPI/NOR Flash ZCZ-C & ZCZ-S only
    QSPI (1S), 50 MHz External OSPI/NOR Flash ZCZ-C & ZCZ-S only
    OSPI (8S), 50 MHz External OSPI/NOR Flash All packages
    xSPI (1S→8D), 25 MHz, SFDP External OSPI/NOR Flash All packages
    UART External Host All packages (fallback)
    In all OSPI boot modes, the RBL reads the SBL image from address offset 0x0000_0000 of the flash connected to OSPI CS0. The RBL copies the SBL image into internal RAM and then executes it — it is not execute-in-place (XIP). The RBL also assumes the flash is already powered up and initialized before boot.
    Can the External Flash Be Permanently Locked?
    Yes — this is where the external flash device itself becomes the key enabler. Since the AM263P4 RBL only reads from the flash during boot (it does not write or erase), if you provision an external NOR flash device that supports one-time-programmable (OTP) sector locks or permanent write-protection bits, the RBL will still be able to read and authenticate the SBL from those locked sectors normally.
    What to look for in an external NOR flash:
    • Some NOR flash devices (e.g., certain Infineon/Cypress S25FS or Winbond W25Q series parts) offer permanent OTP sectors or one-time lock bits (e.g., OTP area, Security Registers, or permanent block protect via WPS/TBPROT bits combined with hardware WP#). Once these bits are blown, those regions become read-only and cannot be erased or reprogrammed — even with direct flash commands.
    • Select a device where the SBL-containing sectors (starting at offset 0x0) can be covered by the permanent protection mechanism.
    RBL Authentication of the SBL Still Applies
    Regardless of the storage medium's physical write-protection, the RBL will always authenticate the SBL image via RSA signature verification before executing it on an HS-SE (High Security - Security Enforced) device. This means even if the physical lock were somehow circumvented, a tampered SBL would be rejected by the RBL's cryptographic check. The two layers (cryptographic authentication + physical immutability) complement each other well.
    Practical Recommendation
    Layer Mechanism
    Cryptographic RBL RSA signature verification of SBL (hardware enforced on HS-SE device)
    Physical (Flash-level) Select an external NOR flash with permanent OTP sector lock or one-time block protect; drive WP# low via board-level pull-down after provisioning
    Software (Runtime) Configure OSPI write protection registers in SBL early init to block application-layer writes to the SBL region
    The key constraint is that the external flash must be a NOR flash device connected to OSPI CS0, and the specific permanence of the write-protection depends entirely on the capabilities of the NOR flash part you select — this is not an AM263P4 SoC feature, but it is fully compatible with the AM263P4 boot flow.
    Please refer to the AM263Px TRM – Section 5 (Boot) for the full boot mode table and RBL operation details.
    Best Regards,
    Zackary Fleenor