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.