arm/qemu: add cortex-r5 support

[yf13]

Summary

This adds QEMU emulated Cortex-R5 chip with virt sample board config.
Thanks @hujun260 for the discussions.

Impacts

QEMU emulated armv7 boards

Testing

• local checks with qemu-armv7a:nsh, qemu-armv7r:nsh
• CI checks.

[nuttxpr]

[Experimental Bot, please feedback here]

No, this PR description does not fully meet the NuttX requirements. While it provides some information, it lacks crucial details and depth required for a proper review. Here's a breakdown of the missing information:

Summary:

• Why is this change necessary? The PR states what it does, but not why. Is this for testing, supporting a new platform, or something else? What problem does it solve or functionality does it enable?
• What functional part of the code is being changed? This is too vague. Which files/directories were modified? Mentioning specific subsystems (e.g., board support, architecture-specific code, QEMU emulation layer) would be helpful.
• How does the change exactly work? More detail is needed. Does it introduce new drivers? Modify existing ones? What configurations are needed?

Impact:

While the "Impacts" section mentions QEMU emulated ARMv7 boards, it needs to address all the specific points required:

• New feature? Existing feature changed? Specify explicitly. This is likely a new feature.
• Impact on user: Does this change how users interact with NuttX? Probably not, but explicitly state "NO" if that's the case.
• Impact on build: Will users need to do anything different to build for this new target? If so, explain. If not, explicitly state "NO".
• Impact on hardware: This is addressed partially, but could be more precise. Does it affect any existing hardware? Likely "NO". Be clear about this.
• Impact on documentation: Does this require updates to the NuttX documentation? If so, were those updates included in the PR? If not needed, state "NO".
• Impact on security: Explicitly state "NO" if there are no security implications.
• Impact on compatibility: Explicitly address backward, forward, and interoperability compatibility. Likely "NO" for backward compatibility if it's a new feature, but specify.
• Anything else to consider: None mentioned. Even if there's nothing, explicitly state "None".

Testing:

• Build Host(s): Insufficient detail. Provide OS, CPU architecture, compiler version (e.g., "Linux x86_64, GCC 12.2.0").
• Target(s): More specific information is needed. "qemu-armv7a:nsh" is the configuration, not the architecture. State something like "ARMv7-A (QEMU), nsh configuration" and similarly for "qemu-armv7r:nsh" (e.g., "ARMv7-R (QEMU), nsh configuration").
• Testing logs: The placeholder text needs to be replaced with actual logs demonstrating the functionality before and after the change. Show that the new board configuration works as expected. Just showing that the existing configurations still work isn't sufficient.

In short, the PR description needs significant expansion to meet the requirements. Provide more context, details, and specific answers to all the questions posed in the template. This will make it easier for reviewers to understand and evaluate the changes.

[xiaoxiang781216]

can we unify armv7-a and armv7-r start code?

[yf13]

There is per this commet. If it is still needed, maybe in the future we can check if armv7-a side can take the same approach for unifying?

[xiaoxiang781216]

My suggestion is: either let armv7-r call nx_start in assembly code, or remove nx_start in assemly code in armv7-a arm_head.S.

[yf13]

see #15624

[xiaoxiang781216]

qemu_bringup

[yf13]

thanks! see #15620