WIP: renesas_ra: Add (more) support for RA6M5 and RA2E1

[desertsagebrush]

Detailed description

Adding/expanding support for Renesas RA6M5, RA4M1, and RA2E1 microcontrollers.

Todo:

• Add ID codes and confirm probe support
• Implement flashing for MF4/MF3 flash on the RA2E1 (RV40 flash for the RA6M5 is already supported)
• Handle RA4 MF3/4 flash gracefully (different block size)
• Possibly support the OCDREG control registers hanging off of AP1 (APB-AP)

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

[desertsagebrush]

Still todo:

• Handle the different block size for RA4 flash
• Update comments/etc to include the new RA family members
• Handle the OCDREG AP?
• Test more thoroughly
• Possibly split the flash routines into their own files?
• Possibly split the families into two feature flags to reduce the size burden?

[dragonmux]

Done a review - very happy with the general direction you're managing to take this, there are only a few fairly small details we spotted that could do with being cleaned up/sorted.

[dragonmux]

We're aware this is, on your part, a "following the style set before", however the parens here are not doing anything useful and can (should) be dropped please. Their presence doesn't follow any of the rest of the code base.

[desertsagebrush]

Sounds good! Would you like me to remove those from other places in this file while I'm at it?

[dragonmux]

Yes, please.

[dragonmux]

If it's possible to express this as a for loop over len, keeping len and addr constant, it would be better - the compiler's able to generate better code for this and prove to itself the correctness of the loop for optimisation purposes. Adding/tracking an offset turns out to be ~free due to instruction set things the compiler can take advantage of.

[desertsagebrush]

Sounds good; Would you like me to see about doing the same thing for the RV40 flash functions, which follow the same pattern?

[dragonmux]

That would be good, yes 🙂

[dragonmux]

Same query here, especially as src could be cast to a buffer pointer so you only have one cast to uint8_t to do and then everything else already uses the right pointer width for the remainder

[desertsagebrush]

Currently, it mostly works; for some reason, repeated scans of the same target may not properly identify the device and report it as an unknown device (but it does call the renesas_ra_probe method, so something is afoot in there, it seems). Also, sometimes the device seems to report that it has erased successfully but then throws a programming error every time it tries to program a previously written block. My guess is that there needs to be a delay post calling erase so that it can finish actually erasing even though the command is reporting that it finished properly, but I could be wrong.

Progress though!