makes it so that we retain the old file, e.g. GP2040CE.uf2.old if we're
about to write GP2040CE.uf2
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
now that we create segmented UF2 files properly in concatenate, we need
the ability to read them, which we'd previously saved for later; that
time is now. the reader now supports jumps forward (but not backwards,
and I don't know how likely it is we'll ever see this)
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
previous commit added the ability to pass a list of location+binary
combinations to create UF2s, meaning we no longer need to pad the
concatenated UF2 the same way we pad the raw binary output. this makes
for a more sanely-sized UF2 and faster write
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
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>
naively adding UF2 blocks together is at least wrong by spec; it
produces one file with wrong block counts --- say I'm writing 3770
blocks, the naive uf2(firmware) + uf2(config) solution yields a file
that says it's 3642 blocks for a while, then 128 blocks. picotool kind
of does a "wtf" at this but writes it anyway, but I am not confident
this is safe, so I'll just do the dumb thing again for now (meaning we
pretty much always write 8128 or 8192 blocks when concatenating configs)
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
the prior version, for the board/user configs, took the whole ~2MB
binary file and converted it to a UF2, which made for a lot of chunks
that were just writing 0s, between the end of the firmware and the start
of the config(s). this changes the logic to build each portion as
separate UF2 chunks and then combine them.
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
this allows for loading an existing GP2040-CE dump or board in BOOTSEL
over USB and saving the parsed configuration to a new .bin/.uf2 file.
might be useful for making quick backups or variants of configs
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
`edit-config --filename foo.uf2` can now create standalone config UF2
files. still working on reading UF2s, or maybe what edit-config needs is
a "Save As..." in order to read from a board/config and output it to a
new file, but this is a start
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>
this will be used for a help screen, which isn't done yet, but this
makes the edit screen incrementally better too
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>
current libraries seem to have problems on Windows with thinking files
are duplicated when they are not, making it impossible to compile .proto
files at runtime in this tool on that platform. this adds a fallback of
using shipped, precompiled files in the package. I was already intending
on providing this as an option anyway, so might as well start doing it
now.
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>
Brian S. Stephan