Draft: RV32M1: Port to the cortex-m4 core

[karstenkoenig]

This ports Zephyr to the RV32M1 cortex m4 core. Tested the uart, i2c and spi operation with some samples.
It creates a shared RV32M1 KConfig option and adds dts/soc/board definition based on the risc-v version.

I also started porting the M0+ core, but it only has 32 IRQs for NVIC and the rest would require porting the multilevel IRQ feature to NVIC, not sure if that would be well received. The M0+ cores usefulness seems very limited with only the first level 32 IRQs

Draft status due to remaining issues:

• the board needs documentation -> Can I just reference the risc-v documentation and document the differences?
• there is no openocd config -> I right now have to use some Segger jlink configs I found in the sdk, is there openocd config somewhere or would it be easy to create?
• boards/common, dts/common and soc/common don't exist / seem unusable in this case so there is a lot of duplication -> I don't feel very confident in this part of the build system, but I wouldn't mind looking into it a for a follow up PR

Requires this openisa hal pullrequest:
zephyrproject-rtos/hal_openisa#6

I am quite impressed how little there was to add to support the Cortex-M4 core and how easy it was to get it running! And a lot of that can also be common and core independent code/dts data :-)

[karstenkoenig]

Fixed the compliance and most build buildkite issues, but it still points out an issue where z_clock_elapsed can't be found, need to dig a bit into it and will notify once I found a solution :-)

[karstenkoenig]

Fixed the remaining issue shown by buildkite, it was a KConfig dependency issue. To double check I also actually ran the affected testcases and they pass :-) So all checks are green now, and I'd welcome feedback if my port is going in the right direction.

I also tried digging into openocd or pyOCD config files, but it all seems very opaque and quite beyond my capabilities. Sadly the segger JLink solution provided by openisa/NXP isn't really that smooth of an experience, one has to copy some extra segger FLM files and so on into the segger install folder. Took a while to actually find them :-( https://open-isa.org/community/topic/jlink-patch-for-rv32m1/
Is it ok to just document it as good as possible and leave it at that?

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[PeterKietzmann]

@karstenkoenig very nice work! One main advantage of this platform is to compare RISC- and ARM based performance and it would be cool to have all cores supported by the OS. I would be very interested in playing around with your port and could also provide some testing, though, I don't really know about the development procedures in zephyr. So far I was able to compile hello_world but it remains unclear to me how to flash the Cortex-M4. Would you share more detailed instructions on that?

[karstenkoenig]

Hi @PeterKietzmann great to hear that you are interested! sorry for dragging this here out. The documentation about flashing/using is what's mostly still missing here and it will probably always be rough as I couldn't find any openocd config that would make integration with zephyr straight forward.

Please download their ARM SDK here
https://open-isa.org/downloads/

Prepping JLink:
'Getting Started with RV32M1 SDK ARM.pdf' section 5.3 documents a bit how to install the JLink patch, disregard the mention of downloading the patch of the website, it's in a folder 'third_party_pack' in the SDK. And good luck installing that patch to be honest... need to modify some xml file, copy it to the right folder, make sure to have the rights correct on the files etc... I think I had to use a couple of different guides around the web until it finally properly worked. https://wiki.segger.com/Using_JLinkDevices.xml is a start. The actual secret sauce is in some closed source .FLM files for segger :-(

Anyways, once you get your JLink to a state where you can select an RV32M1_M4 or so you can continue with -

Selecting the core to execute:
Follow the zephyr guide https://docs.zephyrproject.org/2.3.0/boards/riscv/rv32m1_vega/doc/index.html#programming-and-debugging but instead of ri5cy_boot you need to enter cm4_boot. Make sure you connect your JLink to the jtag port mentioned in the guide

Flashing and debugging the arm core:
Now you need to switch JLink to the swd connector on the board, it is J7/SWD. I can't remember the correct orientation, but if on connection JLink doesn't report a reasonable supply voltage just swap it over. And then try to connect!

Good luck! I wish there was an openocd solution. I don't know enough about openocds operation, but I believe it should be possible to just use the same flashing operation as for the risc-v core as that access port should work for flashing all the time. But not sure I really want to dig into that to be honest :-|

[PeterKietzmann]

@karstenkoenig many thanks for the information! I was able to flash and boot from the Cortex M4 now. Some additional remarks on flashing (from Linux):

• The required JLink patches are not part of the ARM SDK for Linux. So I downloaded and installed the Windows SDK.
• I've copied third_party_pack/segger/Devices/opnisa to my JLink installation path (/opt/SEGGER/JLink_<version>/Devices/).
  (This required sudo and I had to give full read/write access to the folder again sudo chmod -R 755 /opt/SEGGER/JLink_<version>/Devices/openisa/)
• And added the content of third_party_pack/segger/JLinkDevices.xml to /opt/SEGGER/JLink_<version>/JLinkDevices.xml.
• Start JLink: JLinkExe -device RV32M1_M4.
• connect.
• Select SWD.
• Confirm interface speed of 4000kHz.
• loadfile <path to compiled .bin file>.
• r (reset).
• g (go).
• exit
• Done.

[karstenkoenig]

Thanks for pulling through and documenting the detailed steps. But to be honest this is sort of why I didn't really progress with documentation, because applying that JLink patch feels so ridiculously dirty and having to peel it out of the windows sdk is just the cherry on top :-(

@dleach or @MaureenHelm is there a chance to get Segger to include the RV32M1_M4 and _M0plus devices into their JLink bundles?