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.

[FAQ] AM64x/AM62x SoC redundant/recovery boot support in ROM booting R5 bootloader

In response to the recent e2e posts, the FAQ lists redundant/recovery boot support in ROM loading R5-BL (BootLoader) in K3 SoCs, i.e. AM64x, AM62x, AM62A...

The FAQ also discusses the related topic on R5-BL integrity check by ROM on GP/HS. These SoC-level built-in features are useful for user on implementing a range of user cases  - normal boot, flashing, OTP key programming, SW update on the field etc... based on system design and requirements.

  • 1. Summary on redundancy/recovery boot support in ROM booting R5F-BL

    A quick summary on boot order/list by ROM after POR (Power-On-Reset):
    a) Primary boot media configured by BOOTMODE pins
    If primary boot media is memory boot media, i.e. (x)SPI, SD/eMMC, GPMC… the primary boot offset (0x0) is first used by ROM to load R5-BL. If integrity check on R5-BL by ROM fails, the redundant boot offset is used by ROM to load R5-BL.
    b) Backup boot media configured by BOOTMODE pins
    In case of integrity check on R5-BL on primary boot media fails, backup boot media is used by ROM to load R5-BL.

    The FAQ discuss redundant/recovery boot support [the step a) above] in ROM loading R5-BL.

    There’s companion FAQ which discusses the option for switching between eMMC boot partitions (boot0/boot1) to support redundant boot with addition of backup boot media (i.e. SPI).

    2. Summary on ROM check on R5F-BL integrity based on x.509 certificate on GP/HS
    a). The x.509 certificate is used by ROM to verify R5-BL integrity & confidentiality (optional) before launching R5-BL running on R5F on both GP/HS
    b). The R5-BL property, i.e. size, offset, sha512(R5-BL) etc... are imbedded in the x.509 certificate for R5-BL on both GP/HS

    3. Difference on x.509 certificate/signature verifications on GP/HS
    - On HS
    x.509 certificate is signed with the user's "real" private RSA key for HS. During secure boot process on HS-SE,
    a/. ROM first verify the RSA public key read from the x.509 certificate against the RSA public key hash previously provisioned into the SoC along with user's other key material during OTP key provisioning process by user on HS-FS at factory time.
    b/. Upon successful check on the RSA public key read from the x.509 certificate, ROM uses the public key to verify the x.509 signature.
    c/. Upon successful x.509 signature verifications, ROM check R5-BL integrity by calculating sha512(R5-BL) based on R5-BL property of size, offset from the x.509 certificate, and comparing it against the sha512(R5-BL) read from the x.509 certificate.
    - On GP
    x.509 certificate is a "self-signed x.509 certificate" signed with any RSA key, and during boot after POR on GP, the R5-BL integrity is checked by ROM based on R5-BL property of size, offset , sha512(R5-BL) from the "self-signed x.509 certificate". Note that a special provisioned RSA degenerate key is used to generate "self-signed x.509 certificate" for GP in TI SDK, where step 3a/. above in HS case is essentially "bypassed", and steps 3b/c. are "computationally simplified".

    4. Benefits with the same x.509 certificate architecture/flow for GP/HS
    - It facilitate SW development during prototyping, production, deployment phases. For example, it is possible to use "self-signed x.509 certificate" w/o requiring access to the secure key server during initial SW development/testing... on GP/HS-FS
    - The development SW signed with "self-signed x.509 certificate" in initial SW development/testing phase on GP/HS-FS are auto-nullified when moving onto the production phase on HS-SE, where only SW with real "x.509 certificate" signed with the user's matching "real" RSA private key would work.