Skip to content

Latest commit

 

History

History
196 lines (166 loc) · 9.26 KB

README.md

File metadata and controls

196 lines (166 loc) · 9.26 KB

Personal Computing Base System Architecture - Architecture Compliance Suite

Table of Contents

Personal Computing Base System Architecture

Personal Computing Base System Architecture (PC BSA) defines hardware and debug requirements for Arm-based personal computing platforms. It builds on the Arm BSA ruleset and adds PC-specific constraints so that operating systems and firmware interoperate consistently across implementations. Refer to the PC BSA specification for the authoritative rule set.

PC BSA - Architecture Compliance Suite

The PC BSA Architecture Compliance Suite provides self-checking tests that exercise the PC BSA rules across UEFI and Linux execution environments. Most rules run inside the UEFI shell via PC_bsa.efi; OS-visible behavior is validated by the Linux application and its kernel module companion.

Release details

  • Code quality: EAC
  • Latest release version: v1.0.0
  • Release tag: v25.12_PCBSA_1.0.0
  • Specification coverage: PC BSA v1.0
  • Execution levels: Pre-Silicon and Silicon
  • Scope: ACS is not a substitute for full design verification.
  • Prebuilt binaries: prebuilt_images/PCBSA/v25.12_PCBSA_1.0.0

Documentation & Guides

PC BSA coverage overview

PC BSA rules are implemented across multiple ACS components. Run every path below to claim complete coverage.

Sections covering PC BSA rules

  • UEFI-based tests — execute PC_bsa.efi (or the RDV3CFG1 reference flow) with the required modules, filters, and logging flags.
  • Linux-based tests — load pcbsa_acs.ko and run pcbsa_app to exercise OS-visible functionality.
  • SCT-based tests — run the Variable Services suite and any other SCT content referenced by the checklist.
  • BSA ACS dependencies — execute Bsa.efi plus the BSA Linux artifacts mandated by the PC BSA ruleset for shared requirements.
  • Manual evidence — document DUT-owner verification items called out in the PC BSA testcase checklist.

PC BSA build steps

UEFI Shell application

  1. Configure edk2, the toolchain, and the workspace using the Common UEFI build guide.
  2. Build the PC BSA binary:
    source ShellPkg/Application/sysarch-acs/tools/scripts/acsbuild.sh pcbsa
  3. Retrieve PC_bsa.efi from Build/Shell/<TOOL_CHAIN_TAG>/AARCH64/.

Linux application

  1. Download the shared Linux ACS build script:
    wget https://gitlab.arm.com/linux-arm/linux-acs/-/raw/master/acs-drv/files/build.sh
    chmod +x build.sh
  2. Build the drivers and applications:
    source build.sh
  3. The build artifacts appear under build/:
    pcbsa_acs.ko
    pcbsa_app
    bsa_acs.ko, bsa_app, sbsa_acs.ko, sbsa_app (also produced)
  4. For build-script arguments and limitations, see the Common Linux application guide.

PC BSA run steps

For UEFI application

Silicon system

  1. Copy PC_bsa.efi to a FAT-formatted USB drive.
  2. Boot the DUT to the UEFI shell, refresh mappings, and locate the filesystem:
    Shell> map -r
    Shell> fs0:
  3. Run PC_bsa.efi with the required parameters (see Common CLI arguments).
  4. Capture UART console output for reporting.

Example

Shell> PC_bsa.efi -v 1 -skip P_L1PE_01,P_L1GI_01 -f pcbsa_uefi.log

Runs PCBSA ACS with verbosity INFO, skips rules P_L1PE_01/P_L1GI_01and stores the UART output in pcbsa_uefi.log.

Use PC BSA rule IDs that follow the P_L<level><module>_<nn> pattern defined in PC BSA checklist (for example, P_L1PE_01, P_L1GI_01) when filtering, and record any resulting coverage gap.

Emulation environment with secondary storage

  1. Create a FAT image containing PC_bsa.efi:
    mkfs.vfat -C -n HD0 hda.img 2097152
    sudo mount -o rw,loop=/dev/loop0,uid=$(whoami),gid=$(whoami) hda.img /mnt/pcbsa
    sudo cp "<path to>/PC_bsa.efi" /mnt/pcbsa/
    sudo umount /mnt/pcbsa
    (Pick a free loop device if /dev/loop0 is busy.)
  2. Attach the image to the virtual platform per the model documentation.
  3. Boot to the UEFI shell.
  4. Refresh mappings and locate the filesystem:
    map -r
  5. Switch to the ACS filesystem, launch PC_bsa.efi with the required parameters, and capture UART logs for evidence.

Emulation environment without secondary storage

Some emulation platforms embed binaries directly into the firmware image instead of exposing a virtual disk. In that case:

  1. Add the path of PC_bsa.efi to the UEFI FD image used by the model.
  2. Rebuild the UEFI image so the binary is packaged alongside the UEFI shell.
  3. Boot the platform to the UEFI shell.
  4. Launch PC_bsa.efi with the desired arguments (see Common CLI arguments)
  5. Capture the UART console output for analysis.

For Linux application

  1. Copy pcbsa_acs.ko and pcbsa_app to the system.
  2. Load the kernel module:
    sudo insmod pcbsa_acs.ko
  3. Run the user-space application (see Common CLI arguments).
    ./pcbsa_app
  4. Inspect kernel logs as needed:
    sudo dmesg | tail -500
  5. Remove the module when testing completes:
    sudo rmmod pcbsa_acs (Unload bsa_acs and sbsa_acs if they are no longer required.)

RDV3CFG1 reference flow

Use this sequence to run the PC BSA UEFI application on the RDV3CFG1 Arm FVP.

  1. Build the software stack and download the FVP for the RDV3CFG1 model by following the RDV3CFG1 Setup Guide.
  2. Export the model path:
    export MODEL=<path of FVP_RDV3CFG1>
  3. Prepare the ACS disk image as described above FAT image with PC_bsa.efi
  4. Launch the model:
    cd <RDV3CFG1_WORKSPACE>/model-scripts/rdinfra/platforms/rdv3cfg1
    ./run_model.sh –v <path of hda.img>
  5. In UEFI Shell, press Esc, choose Built-in EFI Shell, refresh mappings, switch to the ACS filesystem, and run PC_bsa.efi.

Application arguments

Refer to Common CLI arguments for detailed flag descriptions, logging options, and sample invocations.\

Coverage guidance

  • Execute UEFI, Linux, and required SCT content to claim full PC BSA coverage.
  • Run the BSA ACS content (Bsa.efi plus any required Linux modules) in addition to PC BSA to satisfy the cross-specification dependencies documented in the PC BSA checklist.
  • Rules P_L1NV_01 and P_L1SE_01 require the VariableServicesTest from the SCT suite.
  • Refer to the BBR ACS User Guide and the SCT User Guide for guidance on building and selecting SCT test cases.

Limitations

  • Coverage spans UEFI tests, Linux tests, SCT content, and manual verification. Some rules require DUT-owner evidence; document those explicitly in reports.
  • Exerciser-dependent PCIe features (P2P, PASID, ATC, and similar) require appropriate hardware stimulus; without it the respective rules must be marked partial or skipped.

Feedback, contributions and support

License

PC BSA ACS is distributed under the Apache v2.0 License

Copyright (c) 2025-2026, Arm Limited and Contributors. All rights reserved.