Add RISC-V32 arch. port layer

[akifejaz]

This update adapts the ThreadX low-level kernel routines for RV32, including:

• startup and initialization logic
• context save/restore implementations
• interrupt control and scheduler entry
• thread stack build and system return paths
• timer interrupt handling

These changes provide full low-level support needed to run ThreadX on RISC-V32 targets.

This is similar to RISC-V64/GNU we already had. Its my first PR in Threadx, please let me know if I missed something or you have anything to add regarding this PR.

[fdesbiens]

Hi @akifejaz.

Thank you for this contribution and congratulations on your first PR!

I will request a review during today's committer meeting.

[billlamiework]

This looks really good... nice work! Here is my feedback on some minor issues and recommended testing:

1. Typically, we would not include tx_port.h in the assembly code or use macros to define assembly instructions LOAD, STORE, etc. The idea being that this makes the assembly code harder to read. We would also avoid using the same tx_port.h for 32-bit and 64-bit support - we would have a separate one for each. Of course, the ThreadX RISC-V/64-bit port was done differently (not the typical way). The RISC-V IAR 32-bit port is a better example.

2. For the inline assembly, it's good to use the "memory" option at the end to indicate a memory barrier

3. In tx_initialize_low_level.s, label timer1_plic_IRQHandler, It looks like this is being called from somewhere else, after tx_thread_context_save was called. Maybe that should be documented? Also, the about the call to tx_thread_context_save and the commented out stack adjustments could be confusing.

4. Minimal testing to verify the port. First, you should make sure the address passed to tx_application_define points to free memory (the compiler/linker has no use beyond that address).

Next, it's good to generate three (or more) assembly language threads of equal priority and with a time-slice of 2 ticks. Each thread basically fills the register set with thread-unique values and sits in a tight loop. A higher-priority assembly thread should then be created, where the processing simply sets all the compiler-saved registers with a pattern specific to that thread, then performs a tx_thread_sleep(2) call in a tight loop. Let this application run, then manually halt it and verify that the "tx_thread_run_count" of all threads is incrementing, and that each thread's register set follows the expected pattern. Also, verify that each thread's stack pointer remains constant. You should also verify that context save switches to the system stack pointer. This will verify much of the context saving and restoring.

Next, take the same system and don't start the three background threads - only start the higher-priority thread. This system will test the idle system processing. You should make sure that the stack pointer in the idle system is the system stack and isn't changing while in the _tx_thread_schedule_loop idle loop.

[akifejaz]

Hi @billlamiework Thank you for taking time to review.

1. Typically, we would not include tx_port.h in the assembly code or use macros to define assembly instructions LOAD, STORE, etc. The idea being that this makes the assembly code harder to read. We would also avoid using the same tx_port.h for 32-bit and 64-bit support - we would have a separate one for each. Of course, the ThreadX RISC-V/64-bit port was done differently (not the typical way). The RISC-V IAR 32-bit port is a better example.
2. For the inline assembly, it's good to use the "memory" option at the end to indicate a memory barrier
3. In tx_initialize_low_level.s, label timer1_plic_IRQHandler, It looks like this is being called from somewhere else, after tx_thread_context_save was called. Maybe that should be documented? Also, the about the call to tx_thread_context_save and the commented out stack adjustments could be confusing.

As I mentioned this is similar to RV64/GNU port that we already have in threadx and I also kind of followed the similar flow intentionally. However, I agree your points are valid and I'm already working on streamlining both RV ports starting from RV64 (like #496), I also noticed a issue with RV64 port (I mentioned here #416 (comment)) Hoping to cleanup this in coming PRs.

Also, about testing I've already verified its working on qemu virt see details #492

[fdesbiens]

Hi @akifejaz.

Just to synthesise what we discussed during this week's committer meeting.

• The 64-bit GNU port was contributed to the codebase by Microsoft when they owned the codebase. It deviates from established ThreadX coding standards.
• Most of our codebase avoids using macros in assembly files to keep code standard and readable.
• The 32-bit IAR port is a better model for you to emulate.
• We need to bring the 64-bit port in line with the rest of the codebase.

So, the short version is: please make changes to this PR to align with @billlamiework's recommendations.

I will work to publish past C coding standards on GitHub ASAP. I will also start a file to host assembly standards as well. In the meantime, please send an email to the threadx-dev mailing list if you are unsure about some of the details. Senior contributors like @billlamiework and @cypherbridge could provide guidance there.