restore.py and BBRAM keys: risk of bricking

[DigitalBrains1]

This line:

xous-core/tools/restore.py

Line 749 in 85c4071

print("Restore finished copying objects.\nYou will need to reboot by inserting a paperclip in the hole in the lower right hand side,\nand follow on-screen instructions")

says:

Restore finished copying objects.
You will need to reboot by inserting a paperclip in the hole in the lower right hand side,
and follow on-screen instructions

If you are using a BBRAM key, I think you should only soft-reboot, or your gateware (at this point encrypted to the all-zeroes key) will no longer load. The script tries to reset the Precursor already; the paperclip method is for when that actually didn't work, but naively following these instructions bricks your device (you can bring it back with the debug board).

When it reboots correctly, the Precursor greets you with a prompt that says:

Device has already been initialized. A restore will overwrite existing keys, and potentially fail if your device is locked by a different backup key

Proceed?

I'm ready!

Not yet, maybe later

I think the paperclip method will definitely brick a device with BBRAM keys if you do it at the end of restore.py? I think it will reconfigure the FPGA from flash, but that bitstream is encrypted to the incorrect key. So perhaps the instructions should explain that when you are using BBRAM keys, you should not do the paperclip method. Of course, if the user is not able to trigger a soft reboot at this point, their device is unusable as well.

And earlier I said "you can bring it back with the debug board", but I'm not sure if that's easy to do while not also resetting your BBRAM keys, which you might not want.

This issue report is based on a conversation with bunnie at 38C3, I hope it accurately reflects what he explained to me :-).