arm64: fix fvp smp faild to boot

[hujun260]

Summary

fix fvp smp faild to boot
we should give a busy wait addr
This commit fixes the regression from #13640

Impact

arm64 fvp smp

Testing

fvp-armv8r:nsh_smp ostest

[nuttxpr]

[Experimental Bot, please feedback here]

This pull request appears to meet the basic NuttX requirements. However, it could be improved with some clarifications:

Summary:

• More Detail: Briefly explain why the busy wait address is needed. What was the specific issue causing the FVP SMP boot failure?
• Functional Change: Be specific about which part of the code is modified. For example, "Added a busy wait loop in the ARM64 FVP platform initialization code".
• How it Works: Explain at a high level how providing the busy wait address resolves the boot issue.

Impact:

• Hardware: While you mention "arm64 fvp smp", be explicit about the specific architectures and boards affected.
• Documentation: If this fix impacts user understanding (e.g., if the busy wait address is configurable), mention if a documentation update is needed or provided.

Testing:

• Build Host: Specify the operating system, CPU architecture, and compiler used for testing.
• Target(s): Provide the full architecture and board configuration used (e.g., "arm64, FVP:nsh_smp").
• Logs: While "ostest" is mentioned, consider including relevant snippets of the logs that demonstrate the issue before the fix and the successful outcome after the fix.

By adding these details, you'll make it easier for reviewers to understand and evaluate your pull request.

[XuNeo]

Any idea why FVP needs busy wait?

[hujun260]

The FVP SMP startup has always been using the busywait strategy. Before my modification, it serially waited for a fixed global variable (cpu_ready_flag). After I changed it to parallel startup for CPUs (1 to n), I added a wait address for more generality. However, at that time, the FVP SMP was not configured accordingly, leading to this error.

Additionally, let me mention that the arm64 QEMU SMP startup uses the PSCI method, rather than busywait.