search

raspberrypi / pico-examples

BSD 3-Clause "New" or "Revised" License
2.83k stars 818 forks source link

Writing otp.json file reports an error #556

Open Octopus1633 opened 3 days ago

Octopus1633 commented 3 days ago

Hi,

I defined a new key and updated the otp.json file (according to https://github.com/raspberrypi/pico-examples/pull/536). I wrote the new key to an unused page in otp, and it showed that the write failed, but the encryption program with the new key can run normally (the encryption program cannot be run when the otp.json file is not written). It seems that the new key has been written to the corresponding page of otp. image

In addition, I tested writing the otp.json file in the build directory to otp and performing a secure boot. The write also failed, but the encryption program can run normally. Running an unencrypted program is the same as a non-secure boot, it cannot run in flash, but it can run in SRAM. Is this normal? image

will-v-pi commented 1 day ago

Have you previously written these otp.json files to your OTP (like in #554)? If so, then see 13.5.2 in the datasheet - you cannot re-write a key once you've set the valid bit, so cannot re-write these otp.json files to the same device again. If you want to use the same device again they you'll need to delete the OTP_DATA_KEY1, OTP_DATA_KEY1_VALID, OTP_DATA_KEY2 and OTP_DATA_KEY2_VALID fields from the otp.json file, and change PAGE30_LOCK0 to PAGE31_LOCK0 (the new page you're storing the key in) or remove it if you don't require page locks. I would strongly recommend reading section 13 of the datasheet before playing with OTP, to understand the permanent modifications you are making to your device.

Running an unencrypted program is the same as a non-secure boot, it cannot run in flash, but it can run in SRAM. Is this normal?

I'm not sure what you mean by this - the encrypted programs all run in SRAM, and the encrypted bootloader will only run encrypted programs, so if you try to run something encrypted with a different key (or not encrypted at all) then it will just be decrypted as garbage and won't be run?

Octopus1633 commented 1 day ago

Yes, as you said, I modified the otp.json and the routine, successfully wrote the key to page 31 and read it successfully. However, when I executed "picotool otp load otp.json" for the first time, it showed that the write failed (as shown in the picture I posted earlier, the write was actually successful), which is a bit strange. image

Running an unencrypted program is the same as a non-secure boot, it cannot run in flash, but it can run in SRAM. Is this normal?

I tested that in the case of secure boot (writing the otp.json file in the build directory), I can still burn the unencrypted firmware and run it.

will-v-pi commented 1 day ago

However, when I executed "picotool otp load otp.json" for the first time, it showed that the write failed (as shown in the picture I posted earlier, the write was actually successful), which is a bit strange.

Was this definitely the first time writing the OTP keys and key_valid bits on the device? You can check this with picotool otp get key1_valid which will return a permission failure if it has already been written. I've just tested on a clean device, and if I write the intial otp.json (using page 30), then reboot and write your otp.json (using page 31), I get exactly the same error that you're seeing, so I believe this is what's happening.

I tested that in the case of secure boot (writing the otp.json file in the build directory), I can still burn the unencrypted firmware and run it.

Secure boot hasn't been enabled on your device, because the otp load command stops when it has an error - in this case the permissions error when it tries to write an OTP key that has been marked as valid. You'll need to remove the already written fields from the file before you can write it to the device again and enable secure boot, or just use a device with clean OTP.