Skip to content

Conversation

npitre
Copy link

@npitre npitre commented Oct 1, 2025

This series modernizes ARM64 Fixed Virtual Platform (FVP) board support with
ARMv9-A enablement and unified board structure.

Changes:

  • Unified Board Structure - Cleaner hierarchical naming replacing verbose board
    names (fvp_base_revc_2xaem/{v8a,v9a,a320} with SMP variants)
  • ARMv9-A base architecture support with Cortex-A510 CPU by default
  • Specific Cortex A320 (ARMv9.2-A) CPU support
  • ARM FVP CPU power management driver to enable SMP on bare metal
  • Comprehensive ARM architecture feature detection test

Late additions for the full CI to pass:

  • Scalable Vector Extension (SVE) context switching
  • SVE context switching validation test
  • Fix for the nested IRQ test using NS execution and TF-A


config SOC_FVP_BASE_REVC_2XAEMV8A
config SOC_FVP_V8A
bool
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
bool

Board Variants
==============

This board configuration supports multiple architecture variants:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This board configuration supports multiple architecture variants:
The following board targets are available:

or other reword to remove configuration

Comment on lines +138 to +175
The legacy board name ``fvp_base_revc_2xaemv8a`` has been replaced with the
unified ``fvp_base_revc_2xaem/v8a`` naming. Update your build commands:

* Old: ``west build -b fvp_base_revc_2xaemv8a``
* New: ``west build -b fvp_base_revc_2xaem/v8a``

The legacy board name remains supported for backward compatibility.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a no, use the deprecated board feature

# SPDX-License-Identifier: Apache-2.0

config BOARD_FVP_BASE_REVC_2XAEM
bool
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
bool

NEVER declare these auto generated symbols, same goes for all below

Comment on lines 31 to 32
bool
default y if BOARD_QUALIFIERS = "a320"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no on this


**Cortex-A320 Configuration:**

The ``a320`` variant provides Cortex-A320 specific FVP configuration with:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use full name and call board target

# Use cortex-a710 as fallback since both are high-performance ARMv9-A cores with similar features
# TODO: Update to use cortex-a320 when GCC support is added (likely in GCC 15 or 16)
set(GCC_M_CPU cortex-a710)
message(STATUS "Using cortex-a710 as fallback for cortex-a320 (not yet supported in GCC)")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


config PM_CPU_OPS_FVP
bool "Support for ARM FVP CPU power management"
depends on BOARD_FVP_BASE_REVC_2XAEMV8A && !PM_CPU_OPS_PSCI
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

drivers should not depend on boards, use proper DT_* or select it from a Kconfig file in the board

/* Read the status for the selected CPU */
return sys_read32(pwrc_vaddr + PWRC_PSYSR_OFF);
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

@wearyzen
Copy link
Contributor

wearyzen commented Oct 2, 2025

Just a query not a change request: what do you think about moving boards to a separate boards/arm/fvp directory so that fvp_base_revc_2xaem/v8a becomes fvp/base_revc_2xaem/v8a? Later this fvp directory could be used to add other fvp boards similar to what qemu has.

@npitre npitre force-pushed the armv9 branch 3 times, most recently from cb177ff to 050a643 Compare October 3, 2025 12:59
@nashif nashif assigned wearyzen and unassigned nashif Oct 3, 2025
@nashif
Copy link
Member

nashif commented Oct 3, 2025

Hi, it would be nice to have a maintainer for the ARM64 arch, this is now vacant :(

ARM64 arch:

@npitre
Copy link
Author

npitre commented Oct 3, 2025 via email

@npitre npitre force-pushed the armv9 branch 3 times, most recently from 7e162a1 to 5df7a66 Compare October 6, 2025 04:01
Nicolas Pitre added 7 commits October 6, 2025 00:09
Change SGI interrupt lines from 14-15 to 6-7 for nested interrupt
testing. SGI 8-15 are unaccessible from Non-Secure state (e.g., when
running with TF-A), causing test failures. SGI 0-2 are reserved for
Zephyr SMP IPIs, so use SGI 6-7 which work in both Secure and
Non-Secure configurations.

Fixes test failure: "isr0 did not execute" assertion at line 184.

Signed-off-by: Nicolas Pitre <[email protected]>
Add a new PM CPU ops driver for ARM Fixed Virtual Platform (FVP) that
enables bare metal SMP support without ARM Trusted Firmware (ATF).

The driver provides CPU power-on and system reset operations by directly
interfacing with FVP's power controller (PWRC) and V2M system registers.

The implementation includes RVBAR_EL3 configuration to redirect
secondary CPU reset vectors to Zephyr's image header, enabling
proper SMP initialization without firmware assistance.

Signed-off-by: Nicolas Pitre <[email protected]>
This adds necessary configuration files to build with SMP and no trusted
firmware. Given PSCI is not available, CPU power management uses the FVP
power controller directly.

Signed-off-by: Nicolas Pitre <[email protected]>
Reorganize fvp_aemv8a SOC into unified fvp_aem series with a v8a
architecture variants to enable cleaner board target naming. This also
sets the stage for upcoming ARMv9-A support.

Signed-off-by: Nicolas Pitre <[email protected]>
Create unified board configuration to replace verbose board naming
with shorter hierarchical structure. This board works with the new
unified fvp_aem SOC series and supports the v8a architecture variant.

This enables board targets like:
- fvp_base_revc_2xaem/v8a (basic ARMv8-A)
- fvp_base_revc_2xaem/v8a/smp (ARMv8-A SMP)
- fvp_base_revc_2xaem/v8a/smp/ns (ARMv8-A SMP non-secure)

The structure replaces the existing overly verbose board with a cleaner,
more maintainable organization and provides a foundation for adding v9a
variants.

Signed-off-by: Nicolas Pitre <[email protected]>
Add deprecated.cmake mappings to redirect old board names to new
unified structure:

- fvp_base_revc_2xaemv8a
→ fvp_base_revc_2xaem/v8a

- fvp_base_revc_2xaemv8a/fvp_base_revc_2xaemv8a/smp
→ fvp_base_revc_2xaem/v8a/smp

- fvp_base_revc_2xaemv8a/fvp_base_revc_2xaemv8a/smp/ns
→ fvp_base_revc_2xaem/v8a/smp/ns

This ensures existing build commands and documentation continue to work
with deprecation warnings while transitioning to the new board structure.

Signed-off-by: Nicolas Pitre <[email protected]>
Add ARMv9-A architecture support with Cortex-A510 CPU as the default
processor for generic ARMv9-A targets.

Signed-off-by: Nicolas Pitre <[email protected]>
Nicolas Pitre added 8 commits October 6, 2025 15:18
ARMv9-A is AArch64-only and does not support AArch32 execution states
at EL1/EL2/EL3. Configure TF-A build to disable AArch32 register
context (CTX_INCLUDE_AARCH32_REGS=0) when building for ARMv9-A platforms.

This fixes TF-A boot failures on ARMv9-A non-secure variants where
TF-A would panic with:
  ERROR: EL1 supports AArch64-only. Please set build flag
         CTX_INCLUDE_AARCH32_REGS = 0

Signed-off-by: Nicolas Pitre <[email protected]>
New board targets:
- fvp_base_revc_2xaem/v9a (basic ARMv9-A single core)
- fvp_base_revc_2xaem/v9a/smp (ARMv9-A SMP 4 cores)
- fvp_base_revc_2xaem/v9a/smp/ns (ARMv9-A SMP non-secure with TFA)

Signed-off-by: Nicolas Pitre <[email protected]>
Add Cortex-A320 support to the unified FVP board structure with ARMv9.2-A
specific configuration parameters.

New board target:
- fvp_base_revc_2xaem/a320

Signed-off-by: Nicolas Pitre <[email protected]>
Add comprehensive test to validate ARM64 architectural feature detection
across ARMv8.1 through ARMv9-A implementations, providing runtime
verification of processor capabilities and security features.

Core architecture features tested:
- Exception Level (EL) support detection (EL0-EL3)
- SVE (Scalable Vector Extension) presence and capabilities
- Advanced SIMD (NEON) and Floating Point implementation levels
- Architecture version classification (ARMv8 vs ARMv9-A)

ARMv8.1-A+ features:
- LSE (Large System Extensions) atomic operations with level detection
- Pointer Authentication (PAC) with comprehensive variant analysis:
  * API/APA (Address), GPI/GPA (Generic) authentication
  * Enhanced PAC levels (1, 3, 4, 5) with FPACCOMBINE detection
  * QARMA3 algorithm support (GPA3/APA3)

ARMv8.5-A+ security and performance features:
- Branch Target Identification (BTI) for control flow integrity
- Memory Tagging Extensions (MTE) with level classification
- Random Number Generation (RNDR) hardware entropy
- Speculative Store Bypass Safe (SSBS) side-channel mitigation

ARMv8.7-A+ advanced features:
- WFxT (Wait with Timeout) enhanced synchronization
- RPRES (Reciprocal Precision) optimized math operations

ARMv8.8-A+ features:
- MOPS (Memory Copy/Set) optimized memory operations
- BC (Branch Consistency) advanced branch handling

Signed-off-by: Nicolas Pitre <[email protected]>
Implement Scalable Vector Extension (SVE) context switching support,
enabling threads to use SVE instructions with lazy context preservation
across task switches.

The implementation is incremental: if only FPU instructions are used
then only the NEON access is granted and preserved to minimize context
switching overhead. If SVE is used then the NEON context is upgraded to
SVE and then full SVE access is granted and preserved from that point
onwards.

Signed-off-by: Nicolas Pitre <[email protected]>
Add test to validate SVE (Scalable Vector Extension) context switching
implementation, ensuring proper register preservation across thread
switches in multi-threaded environments.

Signed-off-by: Nicolas Pitre <[email protected]>
Expand the SVE context switching test to cover all thread privilege
combinations with validation of SVE state preservation across different
contexts.

Test Coverage:
- Privileged vs Privileged threads (kernel mode)
- User vs User threads (userspace with memory domains)
- User vs Privileged threads (mixed privilege levels)

Signed-off-by: Nicolas Pitre <[email protected]>
This fixes the following:

CMakeStyle File:cmake/gcc-m-cpu.cmake Line:7
Column:Remove space before '(' in if() statements
CMakeStyle File:cmake/gcc-m-cpu.cmake Line:22
Column:Remove space before '(' in if() statements
CMakeStyle File:cmake/gcc-m-cpu.cmake Line:28
Column:Remove space before '(' in if() statements
CMakeStyle File:cmake/gcc-m-cpu.cmake Line:38
Column:Remove space before '(' in if() statements
CMakeStyle File:cmake/gcc-m-cpu.cmake Line:48
Column:Remove space before '(' in if() statements

Signed-off-by: Nicolas Pitre <[email protected]>
Copy link

sonarqubecloud bot commented Oct 6, 2025

Increase ARM64 stack sizes to accommodate deeper call stacks in
userspace and SMP configurations when FPU_SHARING is enabled:

- PRIVILEGED_STACK_SIZE: 1024 → 4096 bytes (with FPU_SHARING)
- TEST_EXTRA_STACK_SIZE: 2048 → 4096 bytes (with FPU_SHARING)

The default 1KB privileged stack is insufficient for ARM64 userspace
syscalls when FPU context switching is enabled. While FPU context
itself is saved in the thread structure, the FPU trap handler and
syscall path create deeper call stacks with additional stack frames
for exception handling, particularly on SMP systems.

Symptom: Userspace tests crash with Data Abort (EC 0x24) near stack
boundaries during syscalls, particularly on SMP configurations where
multiple threads exercise FPU lazy switching.

Fixes CI test failures on fvp_base_revc_2xaem SMP variants:
- kernel.threads.dynamic (now passes completely)
- Multiple userspace tests with FPU_SHARING enabled

Signed-off-by: Nicolas Pitre <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants