I have started working with using mboot from the filesystem on a device with plenty of filesystem thanks to an external flash chip. So far I am very happy with this setup, and it is not too different than how the pyboard-D is setup.
I might be running into a project where support for an older design with 240k max filesystem but a mountable SD card. I am curious if anybody else has used a SD card to store a dfu file for bootloading, is it supported, is it recommended, and if not can it be with minimal effort?
On the surface it does seem like mboot dfu from filesystem should work, but want to avoid chasing functionality that might not be there.
mboot from mounted SD card
mboot from mounted SD card
_______________
Travis Travelstead
Travis Travelstead
Re: mboot from mounted SD card
Hi Travis,
I assume you're talking about fwupdate.py with a .dfu.gz file?
I think what you want is probably technically possible, but as far as I am aware, mboot doesn't have any existing support for sd cards (e.g. looking at the makefile, it doesn't bring in the stm32 sdcard driver, and there are no memory range definitions for an sd card).
The sdcard driver would end up making mboot bigger, so wouldn't want it by default, but I guess if you're managing your own board firmware then that doesn't matter! It looks relatively straightforward to add though -- you'd come up with another address range (akin to MBOOT_SPIFLASH_LAYOUT) that mboot would know to map to the SD card, and then in main.c do_read / do_write call into the sd card driver.
This does sound like a neat feature though -- it's pretty common to see real devices that take firmware updates this way. Perhaps worth raising a bug and see what Damien thinks?
I assume you're talking about fwupdate.py with a .dfu.gz file?
I think what you want is probably technically possible, but as far as I am aware, mboot doesn't have any existing support for sd cards (e.g. looking at the makefile, it doesn't bring in the stm32 sdcard driver, and there are no memory range definitions for an sd card).
The sdcard driver would end up making mboot bigger, so wouldn't want it by default, but I guess if you're managing your own board firmware then that doesn't matter! It looks relatively straightforward to add though -- you'd come up with another address range (akin to MBOOT_SPIFLASH_LAYOUT) that mboot would know to map to the SD card, and then in main.c do_read / do_write call into the sd card driver.
This does sound like a neat feature though -- it's pretty common to see real devices that take firmware updates this way. Perhaps worth raising a bug and see what Damien thinks?
Re: mboot from mounted SD card
You are correct, the intent was to use the fwupdate.py with the zipped DFU firmware. And yes the hope is that it could be done from SPI flash device, since it is a common storage method and relative to microcontrollers nearly unlimited in size.
You do bring up some good points regarding what MBOOT would need to do in order to mount the SD card and read the DFU file from it.
I do think Damien has added some features into the bootloader for passing variables to it, which could potential hold information about a file on the SD card. But the libraries necessary for the SD card and filesystem on it would need to be there.
For now I might need to think about this some more and maybe ask Damien for his thoughts. I do agree it could be useful for some designs where a SD card is already present and external filesystem that could more easily hold a DFU is not practical.
You do bring up some good points regarding what MBOOT would need to do in order to mount the SD card and read the DFU file from it.
I do think Damien has added some features into the bootloader for passing variables to it, which could potential hold information about a file on the SD card. But the libraries necessary for the SD card and filesystem on it would need to be there.
For now I might need to think about this some more and maybe ask Damien for his thoughts. I do agree it could be useful for some designs where a SD card is already present and external filesystem that could more easily hold a DFU is not practical.
_______________
Travis Travelstead
Travis Travelstead