arch: use raw_spin_[un]lock to replace spin_[un]lock, fix regression b69111d16a2a330fa272af8175c832e08881844b of https://github.com/apache/nuttx/pull/14578

[hujun260]

Summary

arch: use raw_spin_[un]lock to replace spin_[un]lock, fix regression b69111d of #14578
reason:
Due to the addition of sched_lock in the spinlock, using a spinlock in the *cpustart file during the boot phase is quite special. CPU0 waits for CPU1 to start up, using a spinlock as a multi-core synchronization strategy. However, the matching calls are not made within the same task, resulting in a mismatch in the scheduler lock count and preventing the system from booting. The sequence is:
CPU0 spin_lock, spin_lock, spin_unlock;
CPU1 spin_unlock.
CPU0 and CPU1 are running different tasks.

This patch hasn't completely resolved the boot-up issue.

Impact

xtensa

Testing

esp32s3-devkit:smp

[nuttxpr]

[Experimental Bot, please feedback here]

Yes, this PR appears to meet the basic NuttX requirements, but it is incomplete. While it provides a summary of the change, its impact, and some testing information, it lacks crucial details.

Missing Information/Weaknesses:

• Summary: While the summary explains the why, it lacks sufficient detail on what precisely changed in the code. "Use raw_spin_[un]lock to replace spin_[un]lock" is a high-level description. More detail on the specific code modifications is needed.
• Impact: Specifying "xtensa" is too broad. List the specific xtensa boards affected. Explain the original regression more clearly (what functionality was broken?). Address all impact points (user, build, hardware, documentation, security, compatibility). Even if the answer is "NO," explicitly state it for each. The current PR only addresses hardware impact.
• Testing: The testing section is inadequate. "esp32s3-devkit:smp" is insufficient. Provide:
  • Complete build information: Host OS, compiler version, NuttX configuration.
  • Clearer test procedure: What steps were taken to test? How was the fix validated?
  • Actual logs: The placeholders for "Testing logs before change" and "Testing logs after change" need to be filled with real log output demonstrating the issue and the fix. Simply stating that something "works as intended" isn't convincing. Show evidence.
• Incomplete Fix Acknowledgment: The statement "This patch hasn't completely resolved the boot-up issue" is a major red flag. A PR should generally fix the issue it claims to address. If it doesn't fully resolve the problem, explain why and what further work is needed. This might warrant splitting the fix into multiple, smaller PRs.

Recommendation:

The PR needs substantial revision before it can be considered for merging. Provide the missing information outlined above to make it complete and convincing. If the fix is indeed incomplete, clearly explain the next steps and consider breaking down the work into smaller, manageable PRs.

[xiaoxiang781216]

@eren-terzioglu could you verify this patch with espressif/esp-hal-3rdparty#8?

[hujun260]

@eren-terzioglu could you verify this patch with espressif/esp-hal-3rdparty#8?

@eren-terzioglu

My verification steps are as follows:

make distclean -j25;./tools/configure.sh -E esp32s3-devkit:smp;make -j25
cd ./arch/xtensa/src/esp32s3/esp-hal-3rdparty
gh pr checkout -f 8
cd -
make -j25;make flash ESPTOOL_PORT=/dev/ttyUSB0 ESPTOOL_BINDIR=/home/hujun5/work/ssd/esp-bins