Updated elf2uf2 to allow more targets

[ghost]

In my recent PR for the FeatherM4 board, I noted that the elf2uf2.py tool used by modm was written specifically for the RP2040. @salkinium questioned that, and I pointed out the reasons that was true.

I decided to see if I could change it, and hence this PR. I consider this to be a solution looking for a problem, since even though it will now produce a uf2 file for almost every ARM-based example, the number of boards with uf2 bootloaders in that list is limited to maybe half a dozen at most (and the RP2040 boards already worked).

One thing I found while working on this: only the memories listed in the device file are passed to the program. Those that are added or manipulated in the board module are not, and would cause an exception. Since these are usually RAM, nothing from the ELF file gets directly loaded to them; so if a memory range shows up in the ELF program header that was not an argument to elf2uf2, and the ph filesize parameter is zero, a message is printed and the conversion continues. (That seldom happens, and not at all with the boards that matter here.)

In looking at modm-generated makefiles, I found that the memory ranges for this command all started with '0x0x' instead of just '0x'. The source of that was in build_script_generator/make/module.lb, and has been fixed.

I also updated the FeatherM4 documentation to reflect the fact that the uf2 method will now work.

Thanks,
Tom Rush

[salkinium]

This is very awesome!

[salkinium]

I wonder how much work a scons/make program-uf2 command would be, that looks for the right connected external media drives and copies the UF2 binary there. You could probably recognize the drives by name and their small size. Just a thought, since manually copying the binary to the drive is always annoying.

[salkinium]

Do you want to try to rebase your branch on top of the latest develop? While on your branch do git rebase -i develop and then modify the commit list.

[ghost]

I'm glad you approve! Been kinda busy today, but I took a closer look and made some changes in the sections where the data blocks are laid out and then assembled. I thought the nested dictionaries were a bit cumbersome, went with three-element tuples for the page fragments. I'm doing testing with examples now, looks good so far. I'll commit that change and then try the rebase.

As far as a program-uf2 command is concerned, it shouldn't be too hard, but I would have to check into where the different systems mount the drives. Ubuntu is easy, I haven't touched a Windows box for years, and I've never had a Mac.

[ghost]

Please forgive my inexperience with git. After doing the rebase, I couldn't push anything else to the branch. I merged it into develop on the local, and then pushed to develop on my remote. The branch is still there, but it's the unrebased version.

[salkinium]

No worries, I rebased and squashed your commits into two, will merge next.

[ghost]

Thanks!
I do have a question, though: I have been reading up on git (the book ProGit), and it seems that the rebase I performed did exactly what it was supposed to do, which was to pull my commits back into develop. That, in turn, rendered my branch superfluous.

So where did I go wrong? Should I have not done the merge of the branch into develop after the rebase? The branch looks just as it did before the rebase, and develop looks good to go, just 3 commits (the way that I squashed them) ahead.

I like to submit things, but git can still make me feel like an idiot :-( Your comments, when you have time, are welcome.

[salkinium]

What you did worked, however, you rebased your local develop branch on top of the modm/develop branch and then pushed that to your fork. However, this PR only gets updated when you (force) push to its branch on your fork (fix/tool_elf2uf2).

I personally use a mix of GUI and CLI for everyday git operations (only using CLI is just too annoying for most things), so in my maintainer view it looks like this:

1. add the forks remote: git remote add tarush53 git@github.com:tarush53/modm.git.
2. fetch all remotes of all forks git fetch --all --jobs 32 --recurse-submodules=on-demand
3. Check in the GUI what the state of branch is like. I think the CLI equivalent is git log --graph --decorate --pretty=oneline --abbrev-commit --all.
4. Update local develop to remote modm/develop if necessary.
5. Checkout your forks branch, in this case fix/tool_elf2uf2.
6. interactive rebase against updated local develop: git rebase -i develop. Does reordering, rewording, squashing all in one go.
7. Check in GUI that I did the right things.
8. Force push my local fix/tool_elf2uf2 to the tarush53 fork to update this PR.

You would have to do this from the other perspective, ie. add the modm-io/modm repo as upstream remote, update your local develop branch, do the rebase, force push back onto your own fork, etc.

[ghost]

Great!

Thanks so much for the explanation! I didn't try to force the push; I see the failure message and think anything that says 'force' will just make matters worse (past experiences breaking things :-)

This should be a great help. On to the next project!