Hi all
I seek some inputs / inspiration on a firmware upgrade project I am working on.
First a little background information. The project is based on a Microchip (former Atmel) chip from the SAMV series (300MHz, 2MB flash, ~400kB ram). The firmware is written in C. The devices are to be deployed remotely and will have to accept firmware upgrades Over The Air. As a fallback (if the OTA upgrade fails), it shall be possible to upgrade by accessing the device physically. First, I will focus on the upgrade process and later the security related subjects, such as firmware encryption and signature. For now, I seek inputs on the firmware upgrade only. The device runs a bootloader and a main application. The bootloader will implement the firmware upgrade when an image is ready. The application can pull new images OTA. The device has a SD-card installed which is used by the application and formatted using FAT32.
Currently, my plan is the following (with a lot of missing details):
1. When the application is running, it can receive new firmware OTA. The firmware image is "somehow" made available to the bootloader, and the system is reset such that the bootloader can flash the new image. For now, I am not sure if the application should place the image in the internal flash (wasting a lot a flash) or on the SD-card. By placing the image on the SD-card, half of the internal flash does not need to be reserved for firmware images. The disadvantage is that the bootloader becomes more complicated, as it needs to communicate with the SD-card. More on the SD-card in #3.
2. When the OTA firmware fails, the bootloader will have to be able to accept images directly. I hope to be able to do this using the SD-card to avoid any additional external interfaces, USB drivers etc. The bootloader has to be as simple as possible to reduce the risk of bugs. Ideally, it should not need to know FAT32 - but only need to read raw sectors from the SD-card. The MCU impements a SD-card interface in hardware, which makes the communication with the sd-card fairly simple.
3. When using the SD-card for image storage, the image can either be placed "directly" on the SD-card or using the FAT32 filesystem. By placing the image directly on the card, the bootloader does not need a copy of the filesystem - which makes it much simpler. The disadvantages are: 1. the application uses the filesystem and the content cannot be deleted during firmware upgrade, 2. using the fallback method (with physical access to the device), the SD-card shall be "flashed" with the image using some sort of image flashing tool (e.g. etcher?). Maybe an option is to use two partitions on the sd-card, one for images (without filesystem) and one with a filesystem - then the bootloader can simply read from the first partition, without filesystem.
I hope above makes sense. Any feedback is highly appreciated.
I have a few additional specific questions:
- When a SD-card is partitioned, how is the partition headers formatted? I guess the bootloader will have to be able to parse the partition structure. I have not been able to find specific documentation on this. I will appriciate if you know of any similar applications you can refer to.
- When using an image flash tool (as e.g. used for flash of raspberry pi image), it seems that multiple partitions are created, which are flashed with the binaries. I have not been able to find documentation on the *.img format or any tools used for creating such files. If a create a binary firmware file, it seems not to be accepted by sd-card flashing tools (such as etcher).
Looking forward to your replies.
Thanks
Br
Christian