Skip to content

Remove RV32 qemu test scripts from upstream scope - #552

Open
Winstonllllai wants to merge 1 commit into
eclipse-threadx:masterfrom
Winstonllllai:rv32-remove-qemu-test-scripts
Open

Remove RV32 qemu test scripts from upstream scope#552
Winstonllllai wants to merge 1 commit into
eclipse-threadx:masterfrom
Winstonllllai:rv32-remove-qemu-test-scripts

Conversation

@Winstonllllai

Copy link
Copy Markdown
Contributor

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.

Drop the RV32 qemu_virt CMake integration, Python/GDB test script, and
test-only demo changes so the port no longer carries local-only QEMU
validation artifacts in the upstream tree.
@fdesbiens

Copy link
Copy Markdown
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants