Thank you for following up on @akifejaz's request so promptly. Removing test/threadx_test_tx_gnu_riscv32_qemu.py and the check-functional-riscv32 target is right, and it matches what he asked for on #549.

Two things go further than that, though, and I would like to separate them out. I tested both rather than reasoning from the diff, with riscv32-unknown-elf-gcc and qemu-system-riscv32.

The boot pinning is load bearing — please keep it

The PR reverts entry.S from .section .text.boot, "ax" to .section .text, and drops this from link.lds:

KEEP(*(.text.boot))   /* entry.s _start — must be first at 0x80000000 */

That comment is accurate. QEMU's virt machine with -bios none begins executing at a fixed 0x80000000, so _start has to be the first thing in the image, whatever the ELF entry point says.

With the PR applied the demo still boots — but only by accident, because build_libthreadx.sh happens to list entry.S first on the compiler command line. Move it later in that list and the linker places _start elsewhere:

In the last case the CPU jumps to 0x80000000 and runs whatever function the linker happened to put there. KEEP(*(.text.boot)) is what makes the boot address independent of source order, so it is a genuine fix rather than test scaffolding. Please restore both halves.

Deleting the whole CMakeLists loses the demo build target

qemu_virt/CMakeLists.txt does two jobs: it builds kernel.elf, and it registers the check-functional-riscv32 runner. Only the second was objected to. Deleting the file removes both, and unregistering EXAMPLE_DIR in ports/risc-v32/gnu/CMakeLists.txt removes the last CMake route to the example.

build_libthreadx.sh still builds and runs it, so nothing is stranded, but that script starts with rm -rf ../../../../../build/ and hardcodes its flags — it is a local convenience, not a build system. The rest of the tree has been moving toward CMake for exactly these examples, so I would keep the add_executable(kernel.elf ...) block and delete only the find_package(Python3) / add_custom_target(check-functional-riscv32 ...) section at the bottom.

One process note

This targets master. Please retarget it to dev, which is where the other RISC-V work has been landing.

Removing demo_threadx.c's test hooks and the .py script is exactly right — it is just the boot fix and the demo target that should survive the cleanup.

Hi @fdesbiens ,

Thanks for testing both scenarios rather than just reasoning from the diff — that boot-order dependency would have been very easy to miss. I've addressed both points.

Boot pinning restored
Reverted entry.S back to .section .text.boot, "ax", and restored the KEEP(*(.text.boot)) line in link.lds. Agreed this is a genuine fix, not test scaffolding — it shouldn't have been swept up in the cleanup. _start is now pinned at 0x80000000 independent of source/link order again.

CMakeLists.txt build target restored
Kept qemu_virt/CMakeLists.txt and the add_executable(kernel.elf ...) block, along with the EXAMPLE_DIR registration in ports/risc-v32/gnu/CMakeLists.txt. Removed only the find_package(Python3) call and the add_custom_target(check-functional-riscv32 ...) block, so the demo still has a CMake build path — just without the test runner.

Base branch
Saw you already retargeted this to dev — no action needed on my end there.

The PR should now be scoped to exactly what was asked: test script and demo test-hooks removed, boot pinning and demo build target kept. Let me know if anything else needs adjusting.