arch/risc-v64: Add lazy FPU stacking and QEMU functional tests for GNU port

[Winstonllllai]

This PR adds functional enhancements for the ThreadX RISC-V 64-bit (RV64) GNU port, mirroring the improvements delivered for RV32 in #513.

Lazy FPU Stacking:

• Updated _tx_thread_context_save and _tx_thread_context_restore to save mstatus/sstatus and skip FP register save/restore when the FS field (bits 14:13) is Off.
• Applied to nested save, non-nested save, nested restore, no-preempt restore, and preempt restore paths.
• Supports TX_RISCV_SMODE (reads sstatus vs mstatus as appropriate).
• Reduces context switch overhead for threads that do not use floating point.

Automated Testing Framework:

• Introduced a Python-based E2E test harness using QEMU + GDB (azrtos_test_tx_gnu_riscv64_qemu.py).
• Added qemu_virt/CMakeLists.txt and registered the check-functional-riscv64 target.
• Validates multitasking, timer interrupts, FPU context preservation, and priority-based preemption.
• Extended demo_threadx.c with fpu_test_val and adjusted thread timing for GDB-driven verification.
  QEMU Boot & Link Fixes:
• Placed _start in a .text.boot section and added KEEP(*(.text.boot)) to link.lds so the entry point is pinned at 0x80000000 (QEMU virt reset PC).
• Linked kernel.elf with --whole-archive to ensure all ThreadX symbols resolve on RV64.

How to Run Tests

cmake -B build_qemu -DCMAKE_TOOLCHAIN_FILE=cmake/riscv64_gnu.cmake
cd build_qemu
make check-functional-riscv64

Tested on QEMU virt machine (rv64gc).
Please let me know if there is anything I should improve or if I missed anything.

[fdesbiens]

Hi @Winstonllllai.

Thank you for this contribution. @akifejaz and I will review it.

[Winstonllllai]

Hi @fdesbiens and @akifejaz ,
Thank you both for taking the time to review this contribution. I appreciate it and look forward to your feedback.

[akifejaz]

Hi @Winstonllllai please see comments below

[akifejaz]

Hi @Winstonllllai I see multiple issue at first glance some of those I already pointed in your previous PR : #513

and

• i see no significance for test/ dir & *.py script you can keep it for local testing. -- please also remove from RV32 port (PR : #513)
• the "TX_RISCV_SMODE" is obviously from some other PR, seems like merging issue, you should not be adding these changes
• There are multiple new empty asm symbols in there, I'm not sure why you've added those if you chose to keep them empty.
• also please change the comments carefully, I see you updated the comments wrongly, the earlier versions were fine.
• the file name is entry.S but your cmake calls it `entry.s' (small s), it should give build fails, please double check changes when submit PR

Also AI generated code should be marked properly. @fdesbiens when you get time, please also share the AI coding guidelines (if we have any) to him.

[Winstonllllai]

Hi @akifejaz . Thanks for the review — I've addressed the points below:

1. test/ & .py — Removed from this PR; kept locally only. Will do the same for RV32 (arch/risc-v32: Implement lazy FPU, GP relaxation, and QEMU automation for GNU port #513).
2. TX_RISCV_SMODE — Removed the unintended sstatus branches; lazy FPU now uses mstatus only, aligned with RV32.
3. Empty asm labels — These are branch targets for the lazy FPU skip path (FS == Off), not standalone empty symbols.
4. Comments — Reverted incorrect changes; now reference mstatus only.
5. entry.s — QEMU CMake integration removed, so that issue is gone.
6. AI-generated code — Only the QEMU test script was AI-assisted; it has been removed from this PR.

The PR is now scoped to lazy FPU context save/restore only.

[Winstonllllai]

For the RV32 cleanup requested in review, I opened a separate follow-up PR: #552. It removes the local-only QEMU test script and related CMake/test-only changes from the RV32 port.

[fdesbiens]

Thank you for the cleanup — the scope now matches the title, and I can see every one of @akifejaz's points addressed:

• the test/ directory and the .py script are gone; this PR now removes the RV64 one from dev
• TX_RISCV_SMODE is out of the diff. His read was right, and the feature has since reached dev by its own route
• the five remaining labels are all branch targets for the skip paths, not empty symbols
• the comment edits are confined to describing the new behaviour
• the entry.S / entry.s case mismatch went with the CMake file

I checked the mechanism rather than reading it. The FS extraction is correct — srli 13; andi 0x3; beqz isolates mstatus[14:13] and skips when Off — and slot 29 is in bounds for both ABIs, since the trap entry allocates 65 slots with floating point and 32 without. The whole RV64 port assembles clean with riscv64-unknown-elf-gcc 15.2.0, 8 of 8 files, hard float and soft float alike.

One thing to fix before this can go in

Slot 29 is read uninitialised on the first restore of every newly created thread.

The frame map at the top of tx_thread_stack_build.S documents it as reserved:

                    x1      28      Initial ra
                    --      29      reserved
                    mepc    30      Initial mepc

and the builder skips it accordingly — it writes slot 28 and slot 30 and nothing in between, because until now nothing read slot 29.

This PR reads it. Since mstatus is never written back to the CSR, the slot is purely a "was FP live?" hint, so the first _tx_thread_context_restore for a new thread tests whatever was already on that stack. If the leftover bits happen to give FS == 0, the floating-point registers are not restored, and the thread starts with the FP state of whatever ran before it rather than the zeros that tx_thread_stack_build.S writes into slots 31 to 62. The outcome depends on stack contents, so it will look intermittent.

One line alongside the existing initialisers fixes it:

    li      t1, 0x2000                                  // mstatus.FS = Initial
    sd      t1, 29*8(t0)                                // Initial mstatus

Any non-zero FS works; Initial is the honest description of a thread that has not run yet. Worth updating the frame map comment from reserved to mstatus in the same change, so the next person reading it knows the slot is now live.

Please also add a test that a thread created after another thread has used floating point starts with clean FP state — that is the case this bug breaks, and it is the one a reviewer cannot see by reading.

[fdesbiens]

@akifejaz — good catch, and yes, we do have guidelines. The authority is the Eclipse Foundation rather than anything we invent per project:

• Generative Artificial Intelligence Usage Guidelines for Eclipse Committers
• the Eclipse Project Handbook, which has a "Contributing Content Generated by an AI" section
• the Committer Due Diligence Guidelines, which apply to AI-assisted contributions exactly as they do to any other

The short version for contributors: you may use these tools, the contribution still has to pass the same IP due diligence as anything else, and the committer merging it remains responsible for its correctness and provenance. Disclosure is expected rather than optional.

Concretely, here is what that looks like in code already on dev.

A new file carries the disclosure in its header. From scripts/check_clang.sh:

#!/bin/bash
##############################################################################
# Copyright (c) 2026 Eclipse ThreadX contributors
#
# This program and the accompanying materials are made available under the
# terms of the MIT License which is available at
# https://opensource.org/licenses/MIT.
#
# AI Disclosure: This file was largely AI-generated by Claude Code (Opus 5).
# The AI-generated portions may be considered public domain (CC0-1.0)
# and not subject to the project's licence. The human contributor has
# reviewed and verified that the code is correct.
#
# SPDX-License-Identifier: MIT and CC0-1.0
##############################################################################

Note the SPDX-License-Identifier becomes MIT and CC0-1.0, not plain MIT.

An edit to an existing file keeps that file's licence header and adds one line just below it, plus the Eclipse copyright if it is not already there. From ports_module/cortex_m7/gnu/module_manager/src/tx_thread_schedule.S:

/***************************************************************************
 * Copyright (c) 2024 Microsoft Corporation
 * Copyright (c) 2026-present Eclipse ThreadX contributors
 *
 * This program and the accompanying materials are made available under the
 * terms of the MIT License which is available at
 * https://opensource.org/licenses/MIT.
 *
 * SPDX-License-Identifier: MIT
 **************************************************************************/
// Some portions generated by Codex (GPT-5).

Name the actual tool and version rather than a generic label — the tree currently has files naming Claude Code, Codex and Gemini, for example ports_module/cortex_m7/gnu/module_manager/src/tx_thread_system_return.S, which reads // Some portions generated by Gemini (Gemini 2.0 Flash).

@Winstonllllai — nothing to redo retroactively here; if any of this PR was AI-assisted, please add the appropriate marking to the two files you touched.

You are right that this is hard to find today: CONTRIBUTING.md says nothing about it. That file is due a broader refresh across the Eclipse ThreadX repositories, and these guidelines will be part of it. The updated version ships with our next release at the end of September.