Hello Yann,
My view would be to use a new, unique OID for the STM32MP2 DDR firmware upstream, and to place it under STMicroelectronics's own enterprise number rather than Arm’s.
I would avoid keeping the legacy colliding value in upstream, even behind a compatibility option. The issue for me is that an OID should remain globally unique, and once we know that 1.3.6.1.4.1.4128.2300.1 is already used upstream for ETHOSN_NPU_FW_CONTENT_CERT_PK_OID, I do not think we should reuse it for a different purpose. For the same reason, I would also not change the existing Ethos-N OID upstream, as that would just move the compatibility issue to another user.
So my preference would be:
* use a new STM32MP2 DDR firmware OID upstream * use the ST enterprise number for that new OID * handle compatibility for already deployed products as a downstream migration topic, rather than carrying the collision into upstream.
On the enterprise number question, I think using the ST one is the cleaner choice. NXP using Arm’s namespace does not seem like a good reason to continue doing the same for new platform-specific OIDs.
Thanks, Manish Badarkhe ________________________________ From: Yann Gautier via TF-A tf-a@lists.trustedfirmware.org Sent: 30 September 2026 08:39 To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: [TF-A] Questions about OID
Hello,
I was planning to upstream the code to support Trusted Board Boot on STM32MP2. But I came to an issue with the OID we have chosen.
Our first implementation was done back in 2023, and based on TF-A v2.8. We needed an OID for the DDR PHY firmware, almost the same way it was done by NXP with this patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/6155
So I ended up doing this patch: https://github.com/STMicroelectronics/arm-trusted-firmware/commit/c7f0e2eb64...
But now that I want to upstream that code, I see that this OID has been chosen between TF-A v2.8 and TF-A v2.9 for ETHOSN_NPU_FW_CONTENT_CERT_PK_OID.
As I think OIDs should be unique, I then cannot re-use the same one.
But then I will have some issues with customers that already made products with with our software based either on either v2.8 or v2.10. If they need to update their version to a newer one, they will need to regenerate the certificates for this DDR firmware if the software is updated.
For the update procedure, only the FIP may be updated, so if the cert_create tool uses a new OID, it won't match the one used in BL2 DT.
A possible solution would be this one: #if STM32MP_LEGACY_DDR_FW_OID #define DDR_FW_HASH_OID "1.3.6.1.4.1.4128.2300.1" #else #define DDR_FW_HASH_OID "1.3.6.1.4.1.4128.2400.1" #endif
But we'd still have the same OID as ETHOSN_NPU_FW_CONTENT_CERT_PK_OID if STM32MP_LEGACY_DDR_FW_OID is selected.
Another one is just to keep the new value and set the patch as a breaking change, and then inform our customers through the release notes that they should take care of this new version.
A third one would be to change ETHOSN_NPU_FW_CONTENT_CERT_PK_OID. But then you'll face the same issues about such a change, and the dependencies with other tools or pieces of software that would need update.
In your opinion what would be the better solution?
Another question I have is about the OID entreprise number? Should I keep Arm one (4128), or use the STMicroelectronics' (7616)? But that would differ from what NXP has done.
Thanks, Yann -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org