Following the white paper for one-time programmable memory, the memory rows for RPi 5/ CM5 are listed as rows 74-84. The documentation page covering OTP in this repo lists rows 77-84 for BCM2712 devices. Recent testing confirms that for the CM5, the rows are 77-84. Additionally, the example in the white paper for programming (page 9) covers RPi4/ CM4 devices only with reference to rows 40-42. As the customer programmable memory rows start at 77 and not 74, the method for row determination is incorrect as described int he white paper.
Additionally, while trying to confirm the correct rows prior to writing to this region, I found a command in the vcio driver linux/drivers/char/broadcom/vcio.c on line 41
0x00030086, /* SET_CUSTOMER_OTP_LOCK */
which looks to be another possible lock command for OTP memory. I did not have the opportunity to test this command as I had already locked the region using the
0x00038021, /* SET_CUSTOMER_OTP */
command listed in the white paper and found it to work as expected. Still, might warrant investigation and clarity if this command has value.
Given that you only get one shot at writing to this region, it would be greatly appreciated if any documentation is highly specific and accurate.
Following the white paper for one-time programmable memory, the memory rows for RPi 5/ CM5 are listed as rows 74-84. The documentation page covering OTP in this repo lists rows 77-84 for BCM2712 devices. Recent testing confirms that for the CM5, the rows are 77-84. Additionally, the example in the white paper for programming (page 9) covers RPi4/ CM4 devices only with reference to rows 40-42. As the customer programmable memory rows start at 77 and not 74, the method for row determination is incorrect as described int he white paper.
Additionally, while trying to confirm the correct rows prior to writing to this region, I found a command in the vcio driver linux/drivers/char/broadcom/vcio.c on line 41
0x00030086, /* SET_CUSTOMER_OTP_LOCK */which looks to be another possible lock command for OTP memory. I did not have the opportunity to test this command as I had already locked the region using the
0x00038021, /* SET_CUSTOMER_OTP */command listed in the white paper and found it to work as expected. Still, might warrant investigation and clarity if this command has value.
Given that you only get one shot at writing to this region, it would be greatly appreciated if any documentation is highly specific and accurate.