Application Controllable file flashes

[michalcourson]

@stephenhensley

I have a feature that I for sure am going to implement for my project at the very least. I want your input on if it makes sense to add to the repo proper, as it's going to either be a breaking change, or an additional variant. Just want to know if you think this fits within the goals of what you'd want to release

Basically, I want to expand the boot_info struct to include a filename so that the application can control when the bootloader goes to flash from connected media, and what file to load. I've had a number of problems come up due to the simple .bin search that it does now (one of them being caused by macOS and it's tendency to leave hidden ghost files when you try to delete stuff). With this update, the root directory scan would not run, and files will only be flashed from media when explicitly told to.

The one thing that I'm not exactly sure how to handle with this is recovery if there is a power interruption or something. I might end up trying to save some values to the flash so that it knows what to do when power is restored. Or, I could maybe just move my files to a sub directory and leave the .bin search on the root... I need to do some more brainstorming there.

[stephenhensley]

🤔 This is interesting. I've definitely run into similar issues as you described.
I'll have to think on it as well, but I am potentially open to expanding on the boot-info (maybe not with a char*, but FixedCapStr or something with a known size).

Another possible solution that could be potentially more flexible, and more specific to the media-based updates would be to support a .daisy hidden file.
The file could be a simple txt key-value format:

FILECONTAINS "MyModule-" # filters searched bins down by this str
FILENAME "MyModule-v1.2.0.bin" # looks only for this file
SEARCHDIR "/update" # search this directory instead of the root

or something like that, which would have media-specific information, and could be written to by any application.
This would also ensure that if there was power loss between triggering the update, and getting back to the bootloader the meta-information we care about would be on the device with the update itself.

This would have the added benefit of being totally backwards compatible, and requiring no real changes to libDaisy unless we want to write some helpers for generating/parsing the file.

Let me know what you think!