imeghar2408-max commented on issue #19713:
URL: https://github.com/apache/nuttx/issues/19713#issuecomment-5647010364
Hi @evolution124 ,
I investigated the hartid/cpuid handling around this issue and found two
separate problems.
First, `riscv_cpu_boot()` expects a logical CPU ID, while `mhartid` is the
physical hart ID. MPFS already uses:
riscv_cpu_boot(riscv_hartid_to_cpuid(mhartid));
Several other RISC-V startup paths currently pass `mhartid` directly,
including qemu-rv, eic7700x, bl808, sg2000, k210, k230 and jh7110. I’m
preparing a small PR to correct these callers.
There is also a deeper issue with the idle-stack handling described in the
original report: early boot assembly indexes the initial stack using the raw
hart ID, while the later C-side idle-stack calculation uses the logical CPU ID.
This works for the current MPFS offset-style mapping (`hart - 1`), but appears
to break for an arbitrary mapping such as `hart 1 -> cpu 2`, `hart 2 -> cpu 1`.
Before investigating that part further, could you clarify whether
`CONFIG_ARCH_RV_CPUID_MAP` is intended to support arbitrary/non-affine
hartid↔cpuid mappings, or only mappings that can be handled by the current
early-boot stack layout?
If arbitrary mappings are intended, the early boot stack handling seems to
need a broader design change across the RISC-V startup assembly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
