Issue in demo: RISC-V_RV32_QEMU_VIRT_GCC (RegTest Failure)

Kernel
1

Hi guys,

I’m still trying to use the latest version of the demo RISC-V_RV32_QEMU_VIRT_GCC and I encountered this error running the latest version, enabling the 64-bit architecture.

I compiled the application using the makefile provided in the repository, and then I executed the application with QEMU, as indicated in the README file:

$ make -C build/gcc/ RVA23=1
$ qemu-system-riscv64 -nographic -machine virt -net none -chardev stdio,id=con,mux=on \
    -serial chardev:con -mon chardev=con,mode=readline -bios none -smp 4 \
    -cpu rv64,zba=true,zbb=true,v=true,vlen=256,vext_spec=v1.0,rvv_ta_all_1s=true,rvv_ma_all_1s=true -s --kernel build/gcc/output/RTOSDemo.elf

Here is my output on the terminal.

FreeRTOS Demo Start (With FPU and vector)
FreeRTOS Demo SUCCESS: : 5035
FreeRTOS Demo ERROR: Register test 1.
 : 10035
FreeRTOS Demo ERROR: Register test 1.
 : 15035
FreeRTOS Demo ERROR: Register test 1.
 : 20035
FreeRTOS Demo ERROR: Register test 1.
 : 25035

... (repeats indefinitely)

So, from what I see, the demo starts, prints the initial “Start” message, and usually one “SUCCESS” message from the prvCheckTask. Shortly after, it consistently starts reporting errors from the register check task 1. From what I understand, this indicates that the ulRegTest1LoopCounter variable (updated by vRegTest1Implementation in RegTest.S) is no longer incrementing, meaning the task has likely hit its error loop due to a failed register comparison after a context switch.

Troubleshooting Done

  1. RV32 Build: The demo works perfectly fine when built for the default RV32IMAC target (make -C build/gcc/).
  2. main_blinky: The other demo works perfectly in both versions (32-bits and 64-bits)
  3. RV64 Build (No VPU): If I modify the build/gcc/Makefile for the RVA23=1 target to disable the VPU by removing -DconfigENABLE_VPU=1 from CFLAGS (leaving FPU enabled with -DconfigENABLE_FPU=1), clean, and rebuild, the demo runs correctly on the same QEMU command line. It prints continuous “SUCCESS” messages.

Conclusions and Suspected Cause

Based on the troubleshooting, the issue seems specifically related to enabling the Vector Processing Unit (VPU) (-DconfigENABLE_VPU=1) on the 64-bit RISC-V port.

However, I am not so expert with hardware and assembly language to continue the investigation by myself :cry:
Could you help me understand which part of the code I should update to make the demo completely work?

As always, thank you for your time and support!

2

Did you ensure that the you have latest FreeRTOS-Kernel code? VPU support was added in this PR - Add support for Vector context save support on RISC-V by cubidesj · Pull Request #1260 · FreeRTOS/FreeRTOS-Kernel · GitHub.

3

Hi Gaurav,

I am on the main branch of the latest commit (the one related to my pull
request). This is the first entry obtained with the command git log.

$ git log

commit 91659446648a00f24b0b8af6327230658cc65c07 (HEAD -> main, 
origin/main, origin/HEAD)
Author: Luca Mannella <luca.mannella@studenti.polito.it>
Date:   Tue Apr 8 07:54:31 2025 +0200

     Align stack size to 16-byte boundary by changing `__stack_size` 
from 350 to 352​ (#1335)

     This commit updates the __stack_size definition in the
     linker flags, changing its value from 350 to 352. This
     change ensures that the stack size is a multiple of 16,
     aligning the stack pointer (sp) to a 16-byte boundary
     as required by the system architecture.​

Should I use a different branch?

Thank you again as usual for your fast response!

4

You are on the correct branch of FreeRTOS.
What @aggarg asked to verify you are on the correct branch of FreeRTOS/Source .
Looks like the demo is getting stuck in an infinite loop here

You can try running the demo with debugger and checking the backtrace , once the code breaks at that point .

5

As @karahulx said, check FreeRTOS/Source:

cd FreeRTOS/Source
git log
6

Hi guys, thank you for your suggestions!

I moved inside the FreeRTOS/Source folder and typing git log, I observed that I not alligend with the last commit of the source code (I was convinced that typing git pull from the main repository cloned recursively would take care also of the related dependencies but I was wrong :cry: )

$ git log

commit 4d9cd906d3f7c339ee3d6d64a00c416d58a8b003 (HEAD)
Author: Jonathan Cubides <92931721+cubidesj@users.noreply.github.com>
Date:   Thu Mar 6 19:34:48 2025 +0100

    RISCV Add FPU context save (#1250)
    * port: riscv: Split the number of registers and the size of the context
    * port: riscv: Create some macros for the FPU context
    * port: riscv: Add a couple of macros that store fpu context
    * port: riscv: Update the stack init function to include the fpu context size
    * port: riscv: Add a chip_specific_extensions file that includes the F extension
    * Update dictionary to include some risc-v instructions
    * port: riscv: Fix a few typos
    * port: riscv: Apply @aggarg's sugestions

However, typing git pull in that directory gave me this output:

luca@Lenovo-V15-G3-ABA[±|detached:origin/HEAD~5 ✓]:~/.../FreeRTOS/Source $ git pull
remote: Enumerating objects: 7, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 7 (delta 2), reused 2 (delta 2), pack-reused 1 (from 1)
Decompressing objects: 100% (7/7), 8.39 KiB | 238.00 KiB/s, done.
Da https://github.com/FreeRTOS/FreeRTOS-Kernel
   0030d609a..03db672b8  main       -> origin/main
Currently you are not on a branch.
Specify the branch that you want to merge.
See git-pull(1) for details.

    git pull <remote> <branch>

(I translated some messages from Italian, so they would reasonably be slightly different.)

Then, I entered git pull origin main and now my repo seems aligned to the last commit:

$ git log

commit 03db672b8f45db24aa99f12051f7cf86746b9ed9 (HEAD, origin/main, origin/HEAD)
Author: arctic-alpaca <67190338+arctic-alpaca@users.noreply.github.com>
Date:   Thu Apr 3 11:02:44 2025 +0200

    Fix race in POSIX port `vPortEndScheduler` (#1262)
    
    * Fix race in POSIX port `vPortEndScheduler`
    
    The `vPortEndScheduler` checks whether it's a FreeRTOS thread after signalling the scheduler thread to stop. This creates a race between the check and the destruction of the thread key. By moving the signal to the scheduler thread after the check, the race is prevented.
    
    * Code review suggestions
    
    Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
    ---------
    Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
    Co-authored-by: Gaurav Aggarwal <aggarg@amazon.com>

Updating also the Kernel source to the latest version I was able to execute the 4 applications on QEMU (32/64 bits + blinky/full)!

Thank you very much for your support, I will pay more attention to the structure of the repository and its sub-repositories from now on!

7

The command to use is git pull --recurse-submodules.

Glad that you are able to make it work!

1 Like