Initial Zephyr RTOS support

[henrikbrixandersen]

I have submitted a PR for the Zephyr RTOS for adding initial support for running on the NEORV32 SoC: zephyrproject-rtos/zephyr#39162

Once the initial support has been merged, I will submit individual PRs for adding support for the other NEORV32 peripherals.

[stnolting]

This is really awesome!
I always wanted to check out Zephyr on the NEORV32, but I was overwhelmed by the porting complexity... 😅
I am really looking forward to this - your commits at Zephyr are just like a porting guide.

Thank you so much for your great work! 👍

[stnolting]

@henrikbrixandersen

Your port is upstream! 🚀
This is really really great - thanks again for porting! 👍

Right now I am trying to test the basic "hello world" example (https://docs.zephyrproject.org/latest/boards/riscv/neorv32/doc/index.html). Setting up the build system is quite easy and west is incredible complex but very handy.

My first attempt to generate an executable failed, because the NEORV32 executable image generator was not in PATH. Maybe it would be good to add that to the documentation, too.

-- The neorv32 image_gen utility was not found, neorv32 image files cannot be generated

However, after adding that everything compiled without problems (tested with the latest hardware version 1.6.2.1):

CMD:> u
Awaiting neorv32_exe.bin... OK
CMD:> e
Booting...

*** Booting Zephyr OS build v2.7.99-547-g02fceed732ab  ***
Hello World! neorv32

🎉 Zephyr OS on the NEORV32! 🎉 😄

---

Just a small question regarding the ELF generated by the Zephyr build system:

I tried to convert zephyr.elf into an executable "by hand", so using the default NEORV32 makefile. This does not work because the NEORV32 linker script puts all the interesting stuff in sections like .text (names starting with a dot) while the Zephyr linker script puts everything in sections like text (NO dot). Is this intentional?

[kiriane-c]

I am using Zephyr 3.6.0 and NEORV32 RISC-V Processor (version 0x01090803).

I also tried to debug but I get this and I don't really know what it means.

-- west debug: rebuilding
ninja: no work to do.
-- west debug: using runner openocd
-- runners.openocd: OpenOCD GDB server running on port 3333; no thread info available
Open On-Chip Debugger 0.11.0+dev-00728-gb6f95a16c (2024-05-29-12:13)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
1
adapter speed: 2000 kHz

Error: no device found
Error: unable to open ftdi device with vid 0403, pid 6010, description 'Flyswatter', serial '*' at bus location '*'

GNU gdb (Zephyr SDK 0.16.8) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=riscv64-zephyr-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://github.com/zephyrproject-rtos/sdk-ng/issues>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /zephyrproject/zephyr/build/zephyr/zephyr.elf...
:3333: Connexion terminée par expiration du délai d'attente.
You can't do that when your target is 'exec'

[stnolting]

Could you please tell me what I've probably done wrong ?

That's hard to say. What processor configuration are you using?

• are you using internal IMEM & DMEM?
• what are the sizes of the memories (e.g. IMEM + DMEM)? Is this sync with the linker script / Zephyr build?
• have you enabled the MTIME machine time?
• what CPU ISA extensions are you using? Is this sync with your Zephyr build?

I also tried to debug but I get this and I don't really know what it means.

Seems like there is no JTAG adapter available. What kind of adapter are you using? Is it a (simple) FTDI-based one?

[kiriane-c]

I'm using internal IMEM and DMEM with sizes 64kB and 32kB respectively. MTIME and the CPU extensions C, M and Zicsr are enabled.

I think the problem comes from the FPGA board I'm using; Zynq UltraScale+ MPSoC ZCU104. This is because when trying to access JTAG boot mode, I get errors on Vivado regarding Power Status and POR_B signal.

[stnolting]

The processor configuration seems fine (assuming that you have also enabled the UART).

Why do you think there is a FPGA issue? You can see the bootloader console, right?

[henrikbrixandersen]

I am using Zephyr 3.6.0 and NEORV32 RISC-V Processor (version 0x01090803).

Zephyr v3.6.0 supports NEORV32 v1.8.6.

[henrikbrixandersen]

Zephyr TRNG support PR: zephyrproject-rtos/zephyr#39527

[robhancocksed]

FYI, I've got a PR to update the Zephyr port to the 1.9.8 core revision and add in a few more drivers like XIRQ and the watchdog timer: zephyrproject-rtos/zephyr#71294

The recent neorv32 core changes in interrupt handling make it a lot easier to support interrupts in a general fashion across drivers - previously the way in which FIRQ interrupts needed to be cleared was fairly inconsistent.

There's some discussion about whether it's necessary to maintain compatibility with previous neorv32 revisions. It seems difficult to do so given that the differences go beyond what would end up in the device tree files and extend to things like the bit assignments in SYSINFO registers etc.

Part of the answer might depend on whether there are known "breaking" changes coming in core parts of the neorv32 core which might result in even more versions that need to be supported?

[stnolting]

Hey @robhancocksed!

I've got a PR to update the Zephyr port to the 1.9.8 core revision and add in a few more drivers like XIRQ and the watchdog timer: zephyrproject-rtos/zephyr#71294

This looks really great! I have already received a few requests asking when there will be an updated version of the NEORV32 port. So, thank you very much for all your work!

The recent neorv32 core changes in interrupt handling make it a lot easier to support interrupts in a general fashion across drivers - previously the way in which FIRQ interrupts needed to be cleared was fairly inconsistent.

Right, the FIRQ handling was quite... horrible... 😅 I'm really glad that we finally reworked that! The FIRQ handling is not only much more consistent among each other, but also in relation to the other standard RISC-V interrupts.

There's some discussion about whether it's necessary to maintain compatibility with previous neorv32 revisions. It seems difficult to do so given that the differences go beyond what would end up in the device tree files and extend to things like the bit assignments in SYSINFO registers etc.

That's indeed a problem.

In my humble opinion, only the latest/current version should be supported. Anything else would be far too much work in the end... 🙈

Part of the answer might depend on whether there are known "breaking" changes coming in core parts of the neorv32 core which might result in even more versions that need to be supported?

Furthermore, this project is under constant development. Breaking changes are not planned, but they happen from time to time, especially when we discover a severe bug. And isn't such a bug-fix ultimately a "breaking" change? 🤔