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'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.

[kiriane-c]

@stnolting, I think there is a hardware issue when using the JTAG mode of my FPGA. Vivado doesn't detect the FPGA in that mode and signals warnings/errors on the POR_B signal.

[stnolting]

Oh, that's not good... But maybe this is just some boot configuration option issue?! Does your board provide some switches/jumper to select the FPGA boot mode? Perhaps something is configured incorrectly there.

[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? 🤔

[koviadjevi]

Hello @ALL, i am currently trying to run the basic Zephyr Helloworld application on a digilent Genesys2 board.
Following the Zephyr documentation's instructions for the Neorv32, i succeed to use west for the build, but i am currently stuck at the step of flashing, since i am using JTAG
As required by the documentation i a enabled the OCD_EN param et the bootmode is 0. But when running the west flash it results in the following error message

###################################################
Open On-Chip Debugger 0.11.0+dev-00728-gb6f95a16c-dirty (2024-10-20-01:26)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
1
Info : clock speed 1000 kHz
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: neorv32.cpu: IR capture error; saw 0x00 not 0x01
Warn : Bypassing JTAG setup events due to errors
Error: dtmcontrol is 0. Check JTAG connectivity/board power.
Warn : target neorv32.cpu.0 examination failed
Info : starting gdb server for neorv32.cpu.0 on 3333
Info : Listening on port 3333 for gdb connections
TargetName Type Endian TapName State

---

0* neorv32.cpu.0 riscv little neorv32.cpu unknown

Error: Target not examined yet

FATAL ERROR: command exited with status 1: ..../zephyr-sdk-0.17.0/sysroots/x86_64-pokysdk-linux/usr/bin/openocd -s ...../zephyr/zephyrproject/zephyr/boards/others/neorv32/support -s .....zephyr-sdk-0.17.0/sysroots/x86_64-pokysdk-linux/usr/share/openocd/scripts -f ...../zephyr/zephyrproject/zephyr/boards/others/neorv32/support/openocd.cfg '-c init' '-c targets' -c halt -c 'load_image ....../zephyr/zephyrproject/zephyr/build/zephyr/zephyr.elf' -c 'resume 0x0000000000000000' -c shutdown
###################################################

Do you guys have an idea of what i may be doing wrong and how i can fix it please ?

[stnolting]

Unfortunately, you cannot use the BSCAN primitives as a "normal" JTAG port because they are not directly connected to the JTAG pins of the FPGA. Instead, the BSCAN primitives use specific JTAG instructions to build something like a "tunnel" that can be used to issue custom JTAG instructions.

You need some glue logic that converts the BSCAN operations into debug module interface transactions (and not the JTAG transactions of the actual debug transfer module).

Basically, you need something like this: https://github.com/eugene-tarassov/vivado-risc-v/blob/master/vhdl-wrapper/src/net/largest/riscv/vhdl/jtag.vhdl

This is pretty complicated. I recommend mapping the processor's JTAG signals to some headers on your board and connecting a simple USB-JTAG bridge (e.g. an FTDI break-out board).

[koviadjevi]

@stnolting i am not sure i get it correctly, will that be possible to give a code example on how that can be done please?

[stnolting]

I am not familiar with the Genesys 2 board. However, I am using the Nexys Video board which provides a secondary USB/FTDI port that can be used as user JTAG port for the processor's on-chip debugger.

Here is a cut-out from my (Nexys Video) XDC file that connects the processor's JTAG lines to the secondary USB-JTAG bridge:

set_property -dict { PACKAGE_PIN U20   IOSTANDARD LVCMOS33 } [get_ports { jtag_tck_i }]; #IO_L11P_T1_SRCC_14 Sch=prog_d0/sck
set_property -dict { PACKAGE_PIN P14   IOSTANDARD LVCMOS33 } [get_ports { jtag_tdi_i }]; #IO_L19P_T3_A10_D26_14 Sch=prog_d1/mosi
set_property -dict { PACKAGE_PIN P15   IOSTANDARD LVCMOS33 } [get_ports { jtag_tdo_o }]; #IO_L22P_T3_A05_D21_14 Sch=prog_d2/miso
set_property -dict { PACKAGE_PIN U17   IOSTANDARD LVCMOS33 } [get_ports { jtag_tms_i }]; #IO_L18P_T2_A12_D28_14 Sch=prog_d3/s

Looking at the XDC file of Genesys 2 it seems like this is also possible for that board:

#set_property -dict { PACKAGE_PIN AD27  IOSTANDARD LVCMOS33 } [get_ports { PROG_D[0] }]; #IO_L11P_T1_SRCC_13 Sch=prog_d0/sck
#set_property -dict { PACKAGE_PIN W27   IOSTANDARD LVCMOS33 } [get_ports { PROG_D[1] }]; #IO_L2P_T0_13 Sch=prog_d1/mosi
#set_property -dict { PACKAGE_PIN W28   IOSTANDARD LVCMOS33 } [get_ports { PROG_D[2] }]; #IO_L2N_T0_13 Sch=prog_d2/miso
#set_property -dict { PACKAGE_PIN W29   IOSTANDARD LVCMOS33 } [get_ports { PROG_D[3] }]; #IO_L4P_T0_13 Sch=prog_d3/ss

[koviadjevi]

Thank you very much @stnolting !!!, it works like a charm after adapting a bit your suggestions! thanks again.

[stnolting]

That's awesome! 🚀