arm-software / arm-systemready Goto Github PK

Both the v23.09_2.0.0 and V24.03_2.1.0 ACS images on the https://github.com/ARM-software/arm-systemready/tree/main/SR/prebuilt_images site, are showing “Arm ACS Version: v2.0.0-BETA-0” in the logs. Is this expected.

https://github.com/ARM-software/arm-systemready/tree/main/SR

In release details pre-built_image v23.01_2.0.0_BETA-0 (updated on Jan 16 ), with sbsa.efi version 7.1.0

After running this sbsa.efi in UEFI efi2 , system assert!

"ASSERT [ArmCpuDxe] /data/aone/space/224612335/source/workspace/uefi/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c(333): ((BOOLEAN)(0==1))

so that ACS Linux can collect ACPI dump logs by running the comments below.

acpidump > acpi.log
acpixtract -a acpi.log
iasl -d *.dat

By the way, the goal is to move https://gitlab.arm.com/systemready/systemready-es-sr-template/-/blob/main/os-logs/linux-distro-cmds.sh to https://github.com/ARM-software/arm-systemready to have single script file used in ACS test and OS test.

Many lines in log files have path to source file where message was located:

MediaIoProtocols:/home/rajgoy01/WORK/sbsa/sr_oob/SR/scripts/edk2-test/uefi-sct/SctPkg/TestCase/UEFI/EFI/Generic/SbbrRequiredUefiProtocols/BlackBoxTest/RequiredUefiProtocolsBBTestFunction.c:126:EFI_LOAD_FILE_PROTOCOL

Can those paths be shorter? Use some CI instead of rajgoy01 account?

Hello,
Could you provide or link to the building instructions for compiling this ourselves?

Hi folks,

An error occurred when following common/docs/SIE_ACS_Verification.md to install the swtpm package on Ubuntu 20.04 LTS:

$ sudo add-apt-repository ppa:itrue/swtpm
Cannot add PPA: 'ppa:~itrue/ubuntu/swtpm'.
The user named '~itrue' has no PPA named 'ubuntu/swtpm'
Please choose from the following available PPAs:
 * 'fd-find':  fd-find
 * 'grub-2.12':  grub-2.12
 * 'grubtest':  grubtest
 * 'kiwi':  kiwi
 * 'mesa-riscv64':  mesa-riscv64
 * 'misc':  itrue-misc
 * 'mqueue-dev':  mqueue-dev
 * 'odroid-hc4':  odroid-hc4
 * 'open-build-service':  Open Build Service
 * 'orangepi':  orangepi
 * 'pkcs11-dev':  pkcs11-dev
 * 'rtl8723bt-firmware':  rtl8723bt-firmware
 * 'rtl8723ds':  rtl8723ds-dkms
 * 'sparsecat':  PPA named sparsecat for Isaac True

From this website (https://launchpad.net/~itrue), it seems that Isaac has deprecated the swtpm ppa.
I built it from source code as a solution, so shall we update this doc?

BR,
Weizhao

'curl' command is missing in the latest IR ACS release image.
Please make this command available in the ACS.

This is needed for automation for the partners.

Hi,
I am doing a test for system-IR. Based on the latest version(commit: 032e50e, Mar 6), I follow the guideline of https://github.com/ARM-software/arm-systemready/tree/main/IR. But the command in the guideline does not work properly:

$ qemu-system-aarch64 -bios ${path2flash}/nor_flash.bin -drive file=${path2sysIR}/ir_acs_live_image.img,if=virtio,format=raw  -cpu cortex-a57 -smp 2 -m 2048 -M virt,secure=on -monitor null -no-acpi -nodefaults -nographic -rtc base=utc,clock=host -serial stdio -d unimp,guest_errors -machine virtualization=on
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v2.8(release):v2.8-493-g2b7150b38
NOTICE:  BL1: Built : 16:23:05, Mar  7 2023
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v2.8(release):v2.8-493-g2b7150b38
NOTICE:  BL2: Built : 16:23:06, Mar  7 2023
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v2.8(release):v2.8-493-g2b7150b38
NOTICE:  BL31: Built : 16:23:09, Mar  7 2023


U-Boot 2023.04-rc3-00082-gb08ffdffdc (Mar 07 2023 - 16:22:10 +0800)

DRAM:  2 GiB
Core:  51 devices, 14 uclasses, devicetree: board
Flash: 32 MiB
Loading Environment from Flash... *** Warning - bad CRC, using default environment

In:    pl011@9000000
Out:   pl011@9000000
Err:   pl011@9000000
Net:   No ethernet found.
Hit any key to stop autoboot:  0
Scanning for bootflows in all bootdevs
Seq  Method       State   Uclass    Part  Name                      Filename
---  -----------  ------  --------  ----  ------------------------  ----------------
Scanning global bootmeth 'efi_mgr':
Scanning bootdev '[email protected]':
fatal: no kernel available
No working controllers found
scanning bus for devices...
Unknown seq -1 for label 'scsi'
Scanning bootdev 'virtio-blk#32.bootdev':
** Bad device specification virtio 20 **
  0  efi          ready   virtio       1  virtio-blk#32.bootdev.par efi/boot/bootaa64.efi
** Booting bootflow 'virtio-blk#32.bootdev.part_1' with efi
No EFI system partition
No EFI system partition
Failed to persist EFI variables
Missing TPMv2 device for EFI_TCG_PROTOCOL
Missing RNG device for EFI_RNG_PROTOCOL
No UEFI binary known at beeccc30
Boot failed (err=-22)
Unknown seq -1 for label 'nvme'
No ethernet found.
No more bootdevs
---  -----------  ------  --------  ----  ------------------------  ----------------
(1 bootflow, 1 valid)
=>

Qemu version:

$ qemu-system-aarch64 --version
QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.24)
Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers

Is there anything wrong with my operation?

On latest SystemReady ES ACS image, bootingt to the "Linux Boot" grub option, and adding kernel param "noacs":

    linux /Image rootwait  debug crashkernel=512M log_buf_len=1M print-fata\
l-signals=1 efi=debug acpi=on earlycon console=tty0 console=ttyS0  console=\
ttyAMA0 noacs

I still see output message saying "ACS completed":

### 
Additional option set to not run ACS Tests. Skipping ACS tests on Linux

sync: ignoring all arguments


The ACS test suites are completed.

Is there a way to build ACS IR 1.x image?
It looks like the IR buildroot is corrupted (using IR/scripts/build-scripts).

Our uart controller use the 64-bit base address, we fill the 64-bit address correctly in the SPCR table, but test code retains only the last 32 bits.

The Code is in the bsa-acs\test_pool\peripherals\operating_system\test_os_d005.c. In payload function, uart_base type is 'uint32_t'.

Hi,
Recently, I am working on the SystemReady-IR testing on the specific platform.
In the IR guide, there is a rule about how to install the Linux distro.(https://developer.arm.com/documentation/DUI1101/2-0/Test-SystemReady-IR/Test-installation-of-Linux-distributions?lang=en)
"SystemReady IR must boot at least two unmodified generic UEFI distribution images from an ISO image written to a USB drive."

But my device does not have a second disk device or USB.
So, my question is:
If I choose to install a Linux distro by the network, does it comply with the SystemReady-IR rules?
If it complies with IR rules, is there any spec to declare it?

As per https://wiki.yoctoproject.org/wiki/Releases, langdale is EOL and no longer supported.

Hi experts,

I hope you are doing great. I am currently working on a project related to the SystemReady SR certification and I have run into some issues that I need assistance with.

Specifically, I tested the certification on a qemu sbsa-ref device and found that the test results were not fully passed. There were about 32 failed test cases and 113 cases that were not supported out of a total of 1000 test cases. I am wondering if there is a guide or any resources available that can help me analyze the failed test cases? Also, is there a guide that can explain which specific cases can cause the certification to fail, and which ones won't impact the outcome of the certification?

I appreciate any guidance or resources you can provide to help me better understand how I can improve the certification results. Thanks for taking the time to read this email.

Best regards,
Yin
SR_bbr_acs_log_caselist.txt
SR_bbr_acs.log

PR #98 Introduced edk2-test-parser, but the build scripts were hardcoded with x86_64 paths, with no hardware agnostic paths or provisions. Meaning that ACS can no longer be built on aarch64 systems.

Comment from Chetan:

"As suspected the issue was still observed since the fix in linux mainline is available from on v6.8-rc6 revisions onwards
https://github.com/torvalds/linux/blob/v6.8-rc6/drivers/pci/msi/irqdomain.c#L64 and the latest ACS SR image is based on Linux v6.7.

Can you please raise a request on arm-systemready github to update the SR linux base to v6.8"

I ran the ES ACS that was built using the new Github Actions / workflow, when booting into Linux, After the BSA tests it tries to run the EDK-2 Test parser, but complains that it is missing the curses module.

There is one build break when run the command:
./build-scripts/build-ir-live-image.sh. The failure as the followings.

~/workspace/arm-systemready/IR/scripts ~/workspace/arm-systemready/IR/scripts ~/workspace/arm-systemready/IR/scripts/edk2-test/uefi-sct ~/workspace/arm-systemready/IR/scripts/edk2-test ~/workspace/arm-systemready/IR/scripts ~/workspace/arm-systemready/IR/scripts ~/workspace/arm-systemready/IR/scripts
./build-scripts/build-linux.sh: line 98: outpath: invalid indirect expansion
Build failed: error while running source at line 106 in ./build-scripts/build-linux.sh for [][].

I'm using ubuntu 20.04 on x86_64 machine.

r64343@lava2:~$ cat /etc/issue
Ubuntu 20.04.2 LTS \n \l

Jason Liu

When booting from Grub, it can’t mount the USB key partitions, so no logs are saved to acs_results directory.
When booting from Startup.nsh, logs can be saved to acs_results directory.

By the document SystemReady Security Interface Extension User Guide
3.7 Secure firmware update test, mentions a series of tests about firmware update. We can find an prebuild image from https://github.com/ARM-software/arm-systemready/tree/main/SIE/prebuilt_images/v22.10_SIE_REL1.1.0

Flowing 3.7, Q1: my first question is whether the capsule update test can be simulated by qemu?

(I noticed there is a repo https://git.gitlab.arm.com/systemready/firmware-build/qemu/sbsa-ref-ve-es, which could be related to section 3.7. But I found its SbsaQemu.dsc (sbsa-ref-ve-es/build-firmware.sh) doesn't have the capability to do capsule update because its CapsuleLib is NULL. )
Q2: is there an SIE repo to cover firmware update tests like sbsa-ref-ve-es did if the answer to Q1 is yes?