Hi all,
I'm developing the RSE Firmware based on rdv3r1.
I have a concern about the SAM(Security Alarm Manager).
Refering to TRM and codes, for the handling SRAM partial write to sets a correct ECC value,
it read of 64 bits from the captured address(SAM.VMPWCAn) and write the value back to memory at the captured address.
After that, it clears the SAM captured address register and SAM event.
In that scheme, for the 32bit architecture CM55, what correct it everytime seems very overhead and burden if using a SRAM area as data region like stack, heap.
Because 32bit access frequently occurs in 32bit architecture.
Should we avoid using SRAM as data region even though i have found the cases of using SRAM as data region like?
Best Regards RH Kim
This is a test message as we suspect a problem in the mailing system.
From: 김륜현 via TF-M tf-m@lists.trustedfirmware.org Sent: Friday, January 9, 2026 5:41 AM To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Handling the SAM partial write
Hi all, I'm developing the RSE Firmware based on rdv3r1. I have a concern about the SAM(Security Alarm Manager). Refering to TRM and codes, for the handling SRAM partial write to sets a correct ECC value,
it read of 64 bits from the captured address(SAM.VMPWCAn) and write the value back to memory at the captured address. After that, it clears the SAM captured address register and SAM event. In that scheme, for the 32bit architecture CM55, what correct it everytime seems very overhead and burden if using a SRAM area as data region like stack, heap.
Because 32bit access frequently occurs in 32bit architecture. Should we avoid using SRAM as data region even though i have found the cases of using SRAM as data region like?
Best Regards RH Kim
tf-m@lists.trustedfirmware.org
-
Anton Komlev -
김륜현