[BUG] CONFIG_RISCV_PERCPU_SCRATCH mismatch stack pointer

[evolution124]

Description / Steps to reproduce the issue

1. riscv_percpu_init will first initialize and add g_percpu to g_freelist, the g_percpu[i].irq_stack is sequential initialized.
   static void riscv_percpu_init(void) {
   ...
   for (i = 0; i < HART_CNT; i++)
   {
   /* Set interrupt stack (if any) */

#if CONFIG_ARCH_INTERRUPTSTACK > 15
g_percpu[i].irq_stack = (uintptr_t)g_intstacktop - i * INT_STACK_SIZE;
#endif

  sq_addlast((struct sq_entry_s *) &g_percpu[i], &g_freelist);
}

...
}

2. riscv_percpu_add_hart(...) will dequeue the g_freelist and assign the g_percpu to the booting hart
   but the hart booting order will mismatch with the sequential order.

3. riscv_percpu_get_irqstack will get irq_stack.

On which OS does this issue occur?

[OS: Linux]

What is the version of your OS?

Ubuntu24.04

NuttX Version

96f440f0c068f278cc11a956c2c6cf52ff79cf01

Issue Architecture

[Arch: risc-v]

Issue Area

[Area: Kernel]

Host information

No response

Verification

• I have verified before submitting the report.

[imeghar2408-max]

Hi, @evolution124
I’m investigating this issue and traced the current flow through riscv_percpu_init() and riscv_percpu_add_hart(). It looks like irq_stack is assigned according to the g_percpu[] index, while the corresponding g_percpu entry is assigned to a HART based on freelist dequeue order.

Would the intended fix be to select the g_percpu entry deterministically using the HART-to-logical-CPU mapping (for example, riscv_hartid_to_cpuid(hartid)) instead of assigning entries from the freelist? I’m also checking the different RISC-V startup paths before preparing a patch.