this is in preparation for making smaller .uf2 files buy not needing
padding, instead passing multiple location+binary combos to the
converter
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
the UF2 file wasn't converted to binary format before searching for the
board/user config sections, so it was reading the middle of the UF2 file
instead of the end of the binary file and returning that there were no
configs
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
this allows for creating a UF2 that writes the user config to the whole
user config section of flash, allowing for easy copying/juggling of
configurations by just maintaining a library of .uf2 files you like to
apply
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
the former is to avoid an upcoming circular dependency, the latter is to
allow for creating an e.g. user-config-only .uf2 by specifying the
proper offset to start the UF2 addressing at.
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
prior MIT-licensed versions can be obtained from the Git history; this
does not revoke those versions
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
with this, the combining methods can combine both a board and user
config into one binary, which is a step closer to having a command that
does it, and then we can start removing BoardConfig.h from the firmware
build and replace it with patched binaries.
to test it, another retrieval method was added too, and this will
probably be used for more dump commands or a better info or something
like that
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
this also bumps the proto files in the test directory as a matter of
convenience, so some tests got updated accordingly
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
prior to this, the concatenate assumed it was concatenating a firmware
with a full *storage section*, e.g. the already-padded 8192 bytes, but
it's equally valuable now that I'm creating configs to have just a
config section + footer, which needs to be padded 8192. now concatenate
supports both
now you don't need to fiddle with specific byte ranges of a dump, you
can just dump the whole board if that's more convenient, and
visualize-storage will parse that
also more testing in general
Brian S. Stephan