BL2 MMC Access and BL3x Binary Loading and Recovery mechanism in Secure Boot Flow on NXP S32G399ACGM

[yashasdu]

Hello NXP Community,

On my custom S32G399ACGM board with Yocto BSP43 and secure boot enabled, the BL3x binaries (BL31, BL32, BL33) reside in the first partition of the MMC.

As BL2 is responsible for loading and authenticating these binaries during boot, I am looking to implement a recovery mechanism within this BL3x loading process.

To proceed, I need detailed insight into the current default mechanism by which BL2 fetches and loads these binaries from the MMC partition:

• Does BL2 access the MMC partition as raw data using fixed offsets or hardcoded addresses?

• Does it parse partition tables or filesystems to locate the binaries?

• Which exact parts of the TF-A or platform code implement this loading and authentication?

• Are there existing implementations for recovery mechanisms around this BL3x loading flow?

Understanding this will allow me to appropriately design and integrate a recovery solution in the BL3x load/authenticate process.

Any references to source code, configuration files, or documentation—especially for Yocto BSP43 on S32G399ACGM—would be highly beneficial.

Thank you for your assistance!

[alejandro_e · Accepted solution]

Hello @yashasdu,

Here are my answer to your questions:

• Does BL2 access the MMC partition as raw data using fixed offsets or hardcoded addresses?

  • It uses raw data, the offsets are define here:
    • s32cc_platform_def.h#L119 
    • s32cc_platform_def.h#L130 
    • s32cc_platform_def.h#L102 

• Does it parse partition tables or filesystems to locate the binaries?

  • As mentioned above, it uses defined offsets.

• Which exact parts of the TF-A or platform code implement this loading and authentication?

  • Please check the following as a start point: bl_common.c#L151 and bl1_main.c#L203 

• Are there existing implementations for recovery mechanisms around this BL3x loading flow?

  • We do not offer examples for recovery mechanism, from my experience, the the A/B updates in Android has been implemented by other customers. although instead of using it exclusively by updates you can flash the same software in both slots and selectively boot depending on the authentication results.
    • You can check the following reference:
      • Android A/B updates — Das U-Boot unknown version documentation
      • A/B (seamless) system updates  |  Android Open Source Project
    • Please also check the ARM official docs on the ATF:
      • https://trustedfirmware-a.readthedocs.io/en/latest/plat/nxp/index.html
      • https://trustedfirmware-a.readthedocs.io/en/latest/process/security.html
      • https://trustedfirmware-a.readthedocs.io/en/latest/design/auth-framework.html
      • https://trustedfirmware-a.readthedocs.io/en/latest/design/alt-boot-flows.html 
  • Please note that this is only a recommendation and we do not offer any support on the issue that may arrive from the implementation.

If needed you can contact professional services and request this implementation:

NXP Engineering Services

Professional Support for Processors and Microcontrollers

Professional Engineering Services Information Request (CAM802 2019)

Although we cannot offer support on the implementation you need, if you encounter any problem related to the BSP or chips themselves, please create a post detailing it and me or one of my colleagues will try to help you.

Please let me know if you have more questions.

[alejandro_e]

Hello @yashasdu,

Were your questions answered with the information I provided? or do you have more questions. 

I so please select my reply as an accepted solution.

Thanks in advance