mykhailosopiha commented on PR #20144: URL: https://github.com/apache/nuttx/pull/20144#issuecomment-5681263702
> @liam-geotab @darrylring @mykhailosopiha I think having it integrated on efuse has another advantage: it makes it possible to use OTP from userspace, that is not possible with this current implementation. > > @mykhailosopiha the STM32H5 is ECC granule = 16 bits, you can do a test: try to write only at 0x08FFF000 and later 0x08FFF004 (you can write 0x08FFF000 and 0x08FFF002 too, you just can't write 0x08FFF000 and later 0x08FFF001). And there is another way to make sure we are not corrupting our data: before attempting to write, read the content if it is 0xFFFF you can write that position without damaging the OTP. > > @liam-geotab we can merge this PR, but we need Documentation about this feature, otherwise it becomes "Another Hidden Feature of NuttX". It is possible to write adjacent bytes, I did that when was implementing these changes - absolutely fine. I guess providing access to user space per-word write is a valuable feature, and api like "write a word" is a good way to give user full control over the content of the OTP. Thou - pay the price of managing that access when doing write. A proper irq orchestration is needed for this: we want to read every writable memory beforehand, distinguishing "normal read of legitimate data", "virgin read" and "read corrupted data" by checking ECCD (I imagine it is still may shoot us in the knee with some unexpected outcome that may report a virgin block even if there is a "lucky" data corruption that would result in ECCD pretending to report a virgin read), though this all is a pure theory right now an not likely to happen). Also, to write more than 1 word user will need to call "write" function multiple times working with its overheads manually - validate that memory is not fragmented and the entire resulting N bytes are available for writing before actually writing that data. It has it's own implications: multi-write atomicity from user space must be guaranteed, which in non trivial task if we consider a programmed guarantee rather than a contract "please write good code don't write bad code". TLDR: In my opinion both APIs should be there - they serve different goals. A driver-like API to read/write words should exist with a "how to not brick your memory" guide. I also believe that having a smart API that does "Write this data chunk to this OTP address and make sure data is not corrupted" should also be present - it resolves pretty complex multi-level error handling under the hood. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
