Leaving the bootloader from an IRQ (eg USB or I2C IRQ) will not work if
MBOOT_LEAVE_BOOTLOADER_VIA_RESET is disabled, ie if mboot jumps directly to
the application. This is because the CPU will still be in IRQ state when
the application starts and IRQs of lower priority will be blocked.
Fix this by setting a flag when the bootloader should finish, and exit the
bootloader always from the main (top level) thread.
This also improves the USB behaviour of mboot: it no longer abruptly
disconnects when the manifest command is sent.
Signed-off-by: Damien George <damien@micropython.org>
This commit adds support to stm32's mboot for signe, encrypted and
compressed DFU updates. It is based on inital work done by Andrew Leech.
The feature is enabled by setting MBOOT_ENABLE_PACKING to 1 in the board's
mpconfigboard.mk file, and by providing a header file in the board folder
(usually called mboot_keys.h) with a set of signing and encryption keys
(which can be generated by mboot_pack_dfu.py). The signing and encryption
is provided by libhydrogen. Compression is provided by uzlib. Enabling
packing costs about 3k of flash.
The included mboot_pack_dfu.py script converts a .dfu file to a .pack.dfu
file which can be subsequently deployed to a board with mboot in packing
mode. This .pack.dfu file is created as follows:
- the firmware from the original .dfu is split into chunks (so the
decryption can fit in RAM)
- each chunk is compressed, encrypted, a header added, then signed
- a special final chunk is added with a signature of the entire firmware
- all chunks are concatenated to make the final .pack.dfu file
The .pack.dfu file can be deployed over USB or from the internal filesystem
on the device (if MBOOT_FSLOAD is enabled).
See #5267 and #5309 for additional discussion.
Signed-off-by: Damien George <damien@micropython.org>
The implementation internally uses sector erase to wipe everything except
the sector(s) that mboot lives in (by erasing starting from
APPLICATION_ADDR).
The erase command can take some time (eg an STM32F765 with 2MB of flash
takes 8 to 10 seconds). This time is normally enough to make pydfu.py fail
with a timeout. The DFU standard includes a mechanism for the DFU device
to request a longer timeout as part of the get-status response just before
starting an operation. This timeout functionality has been implemented
here.