feature/tm4c129xnczad #2282

Add Support for the TI tm4c129xnczad

• Convert the existing code from probe functions with case statements to a lookup table.
• Add Block/Erase size to the lookup table to support the larger erase size on Snowflake class devices.
• Add a fixed constant LMI_FLASH_WRITESIZE to limit writes to match write size.
• Document a discrepancy between the flash stub and the data sheet.
• Tested extensively against a tm4c129xnczad.

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds for hardware native (see Building the firmware)
• It builds as BMDA (see Building the BMDA)
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do

Closing issues

I've made up a new branch with all of the requested changes and better commit messages. Should I submit a new MR or add additional commits to this one?

Also: Would you like additional hardware for your test environment? I've got a box of eval boards for the popular network connected devices from LMI and Tiva, including the lm3s6965 thats the reference design for Qemu.

@rbsexton wrote in #2282 (comment):

I've made up a new branch with all of the requested changes and better commit messages. Should I submit a new MR or add additional commits to this one?

You should rebase this branch, which will update the request with the changes etc.. No idea how you were taught to use Git for your job, but in the broad sense the only time git rebase-based rewriting of history is "forbidden" is on the main branch of a repo.. a branch of a fork repo that you're preparing a changeset on to submit to a main repo, can absolutely be rebased however much you need/like and never violate that rule. Thus, git rebase -i main to also correct commit messages, and such.. git cherry-pick to pull fixes from that other branch onto this one as needed. Completely acceptable to do.

That also pairs with git push -f for this task, as force-pushing a PR branch is not only acceptable but encouraged.

I'm in change of a very small team that doesn't use a web-mediated MR process. This is mostly new to me.

Thanks very much for explaining that.

All changes have been rolled up and commit messages are cleaned up.

Clang-fixes.

Disabled clang-format for vertically aligned tables and #defines. Added spaces around << per clang-format.

Run it all through clang-format to fix some line ending issues.

Done.