During yesterday's meeting, Fredrik, Pavel, and I brainstormed DFU for
the ARM.
There will be a small bootloader at the start of flash. During normal
operation, it will jump to the main firmware image, which will be just
after the bootloader. The other function of the bootloader will be to
handle the upgrade function (so even if the upgrade is borked, the
device can still restart an upgrade, even if it can't do anything else).
There are 3 jumpers that have to be inserted for the ARM to write the
FPGA config memory. The ARM can read the state of one of them (JP7, on
GPIO PF6). If, on boot, it detects the jumper, it waits for a new image
and signature on one of the UARTs. After verifying the signature, it
writes the new image to the main-firmware region of flash. It could
immediately jump to the new firmware, but I think it would make sense to
wait for the user to remove the jumpers, close the case, and power-cycle.
Also, since the jumper is required for writing into the FPGA config
memory, it follows that FPGA upgrade should use the same mechanism:
receive a new bitstream and signature, validate it, and write it.
The ARM can only read one of the jumpers directly, so there's not a
hardware way to distinguish an ARM upgrade from an FPGA upgrade. I think
it would make sense for the app that's transmitting the file to include
a file name or other indication of what it's sending. I'm picturing
something very like TFTP.
Since upgrade requires opening the case and inserting jumpers, by
definition this tampers the device, and the user has to generate a new
master key and re-load any externally-generated keys. That's probably
obvious, but I wanted to state it explicitly.
We talked about the potential difficulty of debugging a two-stage boot
(i.e. having gdb know what it's looking at, when the bootloader and the
main firmware come from different binaries). But gdb works over the
ST-LINK cable, so we could flash the device with the main firmware
(without the bootloader), debug it, flash it with the bootloader, and
load the main firmware by the upgrade process.
paul
_______________________________________________
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech
