Remove RV32 qemu test scripts from upstream scope

[Winstonllllai]

Summary

Remove the local-only QEMU/GDB test script artifacts from the RV32 port.
This is a follow-up cleanup after review feedback on the earlier RV32 work. These scripts were useful for local validation, but they are not needed in the upstream PR scope.

[fdesbiens]

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:

build	_start	boots under QEMU
dev, entry.S first	0x80000000	yes, threads scheduling
dev, entry.S last	0x80000000	yes — pinning holds it
this PR, entry.S first	0x80000000	yes
this PR, entry.S last	0x80000d80	no output at all

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.

[Winstonllllai]

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.