this should all be tested now:
1. invoking against precompiled _pb2.py files provided by user
2. invoking against .proto files provided by user which must be compiled
3. invoking with a special option to use shipped (by us) .proto files
which must be compiled
4. erroring because none of the above occurred
this took some reorganization, but this should finally give me stability
in using this in GP2040-CE's build process
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
note that the google protobuf project does not recommend shipping
generated _pb2.py files, so that functionality has been removed from the
project. this also partially undoes the previous commit since using the
provided .proto files is less of an issue and also the default now, so
maybe don't spam the console as much
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
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>
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>
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>
`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>
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 is just to clarify the purpose of this since a related method is
coming soon for the board config
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
this allows for putting a JSON representation of a config into the user
config area of a binary to be flashed on the board. this allows for
conveying configs as simple JSON files and using them to convey specific
binaries by parts
this is the start of the support to use JSON files on a *new* section of
the binary reserved for board default configs
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
