how to switch sp to _tx_thread_system_stack_ptr in ports_smp for arm-v7？

[carll00226]

hi scott:
I notice that there are some notes in ports_smp which describe the switch between system stack and task stack for SP, but the related codes are deleted. I want to add the switch to system stack with _tx_thread_system_stack_ptr, can you please tell me where and how to add the switch codes?
Thanks.

[goldscott]

Hi @carll00226, I'm no longer on the Azure RTOS team, so I may not be able to answer all the issues that come up here. Can you show me the notes you are referencing?

[carll00226]

ｔｘ＿ｔｈｒｅａｄ＿ｃｏｎｔｅｘｔ＿ｓａｖｅ．Ｓ

ｔｘ＿ｔｈｒｅａｄ＿ｓｙｓｔｅｍ＿ｒｅｔｕｒｎ．Ｓ

[carll00226]

hi, scott:
So you go to PX5 RTOS ?

[goldscott]

Hi @carll00226 - I'm still at Microsoft, just in a completely different organization.

That comment may have been a copy-paste error or may be from an old implementation. Shouldn't the IRQ stack be used (at least in interrupts where _tx_thread_context_save is called)?

[fdesbiens]

Hi @carll00226, and my sincere apologies for the very long delay in getting back to you. I am Frédéric Desbiens, the Eclipse Foundation project lead for Eclipse ThreadX, and we are working through the backlog of issues inherited from the Azure RTOS days.

The short answer is that you should not add that switch, and that the comments you found are stale pseudo-code left over from an older generic template. They do not describe what the ARMv7-A SMP ports actually do. Scott's instinct in his last reply was exactly right: on this architecture the IRQ stack is the system stack, and the switch is performed by the hardware rather than by software.

On ARMv7-A each processor mode has its own banked stack pointer. IRQ_Handler branches straight to _tx_thread_context_save while still in IRQ mode (ports_smp/cortex_a7_smp/gnu/example_build/startup.S:170), so on entry sp is already the per-core banked IRQ stack that the startup code carves out of _stack_init_irq, 1024 bytes per CPU (startup.S:284-289). The scratch registers saved at tx_thread_context_save.S:91-99 therefore land on the IRQ stack, not on the thread stack, and the ISR body runs there too. There is nothing left for a software sp = _tx_thread_system_stack_ptr to accomplish.

The thread's own stack pointer is only saved when preemption is actually required. _tx_thread_context_restore takes the __tx_thread_preempt_restore path (tx_thread_context_restore.S:197), switches to SVC mode (:201), builds the remainder of the interrupt frame on the thread's SVC stack, stores the result in tx_thread_stack_ptr at offset 8 (:233), and branches to _tx_thread_schedule. The synchronous path in _tx_thread_system_return.S does the same thing at line 141 and jumps to the scheduler at line 196. The scheduling loop then runs on the per-core SVC stack that startup.S:298-301 set up.

_tx_thread_system_stack_ptr is a real, live variable only on the AArch64 SMP ports, for example ports_smp/cortex_a73_smp/gnu/src/tx_thread_context_save.S:192, where it is an array indexed by core. ARMv8-A does not bank a stack pointer per processor mode the way ARMv7-A does, so those ports have to keep the system stack in a variable and reload it explicitly. Porting that mechanism back to ARMv7-A would be redundant, and it would break the IRQ-mode return path, because __tx_thread_no_preempt_restore (tx_thread_context_restore.S:180-191) pops the saved SPSR and scratch registers from the IRQ stack and returns with MOVS pc, lr.

If your goal is simply to give interrupt handlers more room, the supported approach is to enlarge the per-core IRQ stacks in your own startup code and linker script rather than to introduce a stack switch in the kernel. If you genuinely need ISR bodies to run on some other stack, do the mode or stack change inside your own IRQ_Handler after _tx_thread_context_save returns through __tx_irq_processing_return, and restore it before you branch to _tx_thread_context_restore; the kernel makes no assumption about the stack in between those two points, only that it is unchanged across them.

I am closing this issue as answered, but please do reopen it or comment if anything above does not match what you are seeing. Thank you for reporting the misleading comments -- they have now caused confusion more than once, and I have opened #734 to track cleaning them up.

[fdesbiens]

Follow-up: #735 is now open against dev and removes the misleading pseudo-code from all 38 affected ARMv7-A files, which closes #734. Every changed line is a comment, so there is no behavioural change.