threadx icon indicating copy to clipboard operation
threadx copied to clipboard

Illegal Memory Dereference in tx_initialize_low_level for ARMv8-A AMP (Cortex-A34) with GNU Toolchain

Open sathya-1207 opened this issue 11 months ago • 3 comments

When building ThreadX for ARM Cortex-A34 in AMP mode using the GNU toolchain, the tx_initialize_low_level file contains the following sequence to save the first available memory address:

tx_initialize_low_level.S

/* Save the first available memory address.  */
// _tx_initialize_unused_memory =  (VOID_PTR) Image$$ZI$$Limit;

LDR     x0, =_tx_initialize_unused_memory   // Pickup address of unused memory ptr
LDR     x1, =__top_of_ram                   // Pickup unused memory address
LDR     x1, [x1]                            //
STR     x1, [x0]                            // Store unused memory address

The issue occurs at the instruction:

LDR     x1, [x1]   // Dereferencing __top_of_ram
  • This dereferences __top_of_ram, which is illegal and results in _tx_initialize_unused_memory being updated with a garbage value. After commenting out this block, ThreadX runs successfully, and I can create threads without issues.

Target Device:

  • ARM Cortex-A34
  • ThreadX Version: 6.4.1
  • Toolchain: GNU GCC

To Reproduce

  • Build ThreadX for Cortex-A34 in AMP mode using the GNU toolchain.
  • Run the system and observe _tx_initialize_unused_memory.
  • The value is garbage due to the illegal dereference of __top_of_ram.
  • Commenting out this block allows ThreadX to function correctly.

Expected Behavior _tx_initialize_unused_memory should be assigned a valid address without dereferencing __top_of_ram, ensuring correct memory initialization. Removing the instruction solves the issue.

  LDR     x1, [x1] 

Impact Showstopper: Prevents proper initialization and causes unpredictable behavior in ThreadX.

Additional Context

  • This issue is specific to the GNU toolchain. Other toolchains (such as IAR or ARM Compiler) may not be affected.
  • __top_of_ram should likely be treated as an absolute address rather than being dereferenced.
  • Since this issue affects multiple ARMv8-A ports, a global fix may be required across affected architectures (such as Cortex-A53, Cortex-A55, and Cortex-A57, where I have observed the illegal instruction) when using the GNU toolchain.
  • Cortex-M3 and Cortex-R5 ports do not have this issue, which i have already ported. Suggesting that the memory initialization logic for ARMv8-A cores may need review.

sathya-1207 avatar Feb 03 '25 04:02 sathya-1207