Regression tests cannot be generalized and be used with other architectures

[EAlexJ]

The current tests were written with some assumptions that do not work out for other architectures.

In getting the tests working on a virtual RISC-V platform(32 and 64 bit), I ran into the following issues:

• counters are not marked volatile, at higher optimization levels some tests deadlock
• some memory tests do not provide pools large enough to accommodate the required amount of blocks when working with a 64-bit system. Due to the overhead being larger the pools end up providing too few blocks, thus failing the tests
• some pointers are only 4 byte aligned, again not working on a 64-bit system which requires 8 byte alignment
• in some instances, there is "resonance" and the test does not progress. The test expects an interrupt during a small window, but I encountered cases where this window is always missed. This is exacerbated by the fact that on a virtual platforms instructions are always taking the same amount of time. In one instance there already is code to include a perturbation, but in my setup this was not large enough to make the test complete in a sensible time

While some of these points can be addressed pretty straight-forward, I would like to start a discussion, especially on the resonance issue.

[fdesbiens]

@EAlexJ: Thank you for raising this issue. I agree we need to address those problems in some way.

@eclipse-threadx/iot-threadx-committers and @eclipse-threadx/iot-threadx-contributors: I intend to discuss this particular issue at our next meeting. Please take the time to think about it. Thank you.

[cpdpls]

To add here. I agree this is an issue but the alignment one is not valid. While it is true for other architectures, it is not necessary in RISCV-64 as long as you are using the right assembly code for what you are loading or storing.

If you need to load 8 bytes by using the opcode ld then address must be aligned on 8 bytes. If you need 4 bytes, then you would use lw which needs the memory address to be aligned on 4 bytes.

But I agree the RISCV-64 will be updated at some points to have a true port taking full advantage of the 64 bit architecture.

[EAlexJ]

While in general your statement is right this breaks in this specific case I pointed out.

I hunted down the issue, and arrived at the following snippet in tx_byte_pool_create.c:

UINT  _tx_byte_pool_create(TX_BYTE_POOL *pool_ptr, CHAR *name_ptr, VOID *pool_start, ULONG pool_size)
{
    ...

    /* Calculate the end of the pool's memory area.  */
    block_ptr =  TX_VOID_TO_UCHAR_POINTER_CONVERT(pool_start);
    block_ptr =  TX_UCHAR_POINTER_ADD(block_ptr, pool_size);

    /* Backup the end of the pool pointer and build the pre-allocated block.  */
    block_ptr =  TX_UCHAR_POINTER_SUB(block_ptr, (sizeof(ALIGN_TYPE)));

    /* Cast the pool pointer into a ULONG.  */
    temp_ptr =             TX_BYTE_POOL_TO_UCHAR_POINTER_CONVERT(pool_ptr);
    block_indirect_ptr =   TX_UCHAR_TO_INDIRECT_UCHAR_POINTER_CONVERT(block_ptr);
    *block_indirect_ptr =  temp_ptr;

While pool_size is ensured to hold a multiple of ALIGN_TYPE sized chunks in the part that I left out, pool_start itself does not get aligned.
This leads to block_ptr being unaligned and thus the write to *block_indirect_ptr being unaligned.
For RISC-V with 64 bits the last bit compiles to a single sd instruction (as it should).

Interestingly txe_byte_pool_create.c does not check the alignment of the pool_ptr.

I cannot comment on the fact of the pointers not being checked for alignment being intentional or not, but to me it seems reasonable to expect that users provide base addresses to pools which are aligned correctly.

[cpdpls]

Oh indeed now I remember that part. I needed to temporarily redefine ALIGN_TYPE otherwise I would end up in the trap handler. That was indeed a step I needed to do in order to have the port working. Apologize for misunderstanding that part. Nevertheless, the port is known to be broken and I'll try to have some time to try to contribute fixing it in the near future when I have time.

[fdesbiens]

Thank you for the thoughtful discussion, @EAlexJ and @cpdpls.

I reviewed this issue with the core project team today. We would definitely welcome suggestions, or even PRs targeted at improving the robustness of our 64-bit support.

From my project lead's perspective, I will invest efforts to make sure we catch RISC-V issues much earlier in the development process. A logical step is to expand our CI/CD to run the regression test suite on a RISC-V-based environment. I know this is a goal for @akifejaz, for example.

We're especially interested in what you can share about your use cases and business requirements.

The next step is up to you. We can continue to exchange on GitHub, or I can invite you to our weekly team call to have a deeper exchange on the topic. Since I am not sure if the call will take place next week (on April 21, 2026), I would suggest targeting the April 28, 2026 call. Let me know your preference, and I can add you to the Zoom invite.

[cpdpls]

Hey @fdesbiens, I would definitely love to have a chat and have the chance to discuss this in a meeting with you and the team. It could allow both parties to better target what the priorities are and also for @EAlexJ and me to explain to all of you what roadblocks we encountered and what solutions/workaround we found.

I'm personally available any day so I'll say it doesn't really matter for me. As for the timing during, I'm available after 4 PM GMT+2