xtensa/esp32s3: Fix esp32s3 sched_lock crash

[hujun260]

Summary

move the code to iram0 since sched_lock/sched_unlock is called in the early boot phase

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

[eren-terzioglu]

Hi,

Checking it in our internal CI. I will notify the result.

Update: I need to be sure about a some defconfigs, so tests are in progress. fyi

[eren-terzioglu]

Checking finished, you can merge this if it is good for you too @xiaoxiang781216.

Thanks for your effort @hujun260.

[xiaoxiang781216]

@hujun260 let's drop the spinlock change and use #15728 instead.

[tmedicci]

@hujun260 let's drop the spinlock change and use #15728 instead.

Please. I tested this PR without 9a61a1d + #15728 and it seems it solves #15688

[xiaoxiang781216]

@hujun260 let's drop the spinlock change and use #15728 instead.

Please. I tested this PR without 9a61a1d + #15728 and it seems it solves #15688

Thanks @tmedicci, I think the better fix is that:

1. Remove the bad spin lock usage by arch: Remove the abuse of spinlock in smp boot #15728
2. Move sched_lock/sched_unlock to iram0 by updating this pr
3. Close esp32: replace spin_lock_irqsave with raw_spin_lock_irqsave. espressif/esp-hal-3rdparty#8

So, I drop 9a61a1d from this pr, both pr is ready for merging now.