You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a better idea about how the romfs feature might work/look like:
First you'll need to store some info about the romfs offset/address and size per board. I could add a USB command to retrieve this information instead.
Next step is to get the romfs contents. There are two options:
Add a USB command to dump the romfs contents.
Use the bootloader to read the romfs contents (this requires a reset into bootloader etc..).
Display the contents of the romfs in a filesystem browser-like window.
Users can add/delete files. *** All operations must be done in memory***
The "commit" phase:
Check if the romfs fits the space reserved for.
Commit using the bootloader to write the romfs.
A revert option? The romfs may contain the wifi/bt firmware as well, the user can delete any files, so we may need to have an option to revert it. We could either:
Require reflashing the release firmware.
Have the build generate the romfs.bin image separately. This will happen anyway for boards that use QSPI (because you use the IDE to load it). But I can generate it separately boards that don't use the QSPI as well.
The text was updated successfully, but these errors were encountered:
I have a better idea about how the romfs feature might work/look like:
romfs.bin
image separately. This will happen anyway for boards that use QSPI (because you use the IDE to load it). But I can generate it separately boards that don't use the QSPI as well.The text was updated successfully, but these errors were encountered: