RTEMS | Mips malta smp foundation (!1153)

[Lucky Singh (@LuckySingh)]

Lucky Singh commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1153#note_146738


I used AI  to help me structure the commit messages and the MR description to match RTEMS standards, but the technical implementation and the code changes are entirely my own work based on the Malta board's architecture and the current SMP blockers I encountered.

To verify the changes, I used **QEMU** with the `-smp 2` flag. Earlier The build would fail during the linking stage because of redundant declarations in `cpuimpl.h` and missing atomic exchange definitions for MIPS in the SMP context. Even with hacks, Core 1 would behave unpredictably because it shared the same stack as Core 0.After the changes the kernel builds successfully for the `mips/malta` BSP with `RTEMS_SMP = True`.Using the QEMU monitor (`info registers`), I verified that Core 0 reaches the application entry/fatal halt while **Core 1 is successfully parked** in the newly implemented parking loop in `start.S`.I also verified that each core now has a distinct stack assigned based on its CP0 EBase/Processor ID, preventing the memory corruption I saw earlier.

![aa1439145ba43121eafb376cb3d3d0f369751d86.jpeg](/uploads/513eed1abba0b43efd563449d99b947b/aa1439145ba43121eafb376cb3d3d0f369751d86.jpeg){width=900 height=478}

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1153#note_146738
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260322/5021e318/attachment-0001.htm>