Hi Gavin,
On Fri, May 31, 2024 at 04:23:13PM +1000, Gavin Shan wrote:
> I got a chance to try CCA software components, suggested by [1]. However, the
> edk2
> is stuck somewhere. I didn't reach to stage of loading guest kernel yet. I'm
> replying
> to see if anyone has a idea.
...
> INFO: BL31: Preparing for EL3 exit to normal world
> INFO: Entry point address = 0x60000000
> INFO: SPSR = 0x3c9
> UEFI firmware (version built at 01:31:23 on May 31 2024)
>
> The boot is stuck and no more output after that. I tried adding more verbose
> output
> from edk2 and found it's stuck at the following point.
>
>
> ArmVirtPkg/PrePi/PrePi.c::PrePiMain
> rmVirtPkg/Library/PlatformPeiLib/PlatformPeiLib.c::PlatformPeim
>
> #ifdef MDE_CPU_AARCH64
> //
> // Set the SMCCC conduit to SMC if executing at EL2, which is typically the
> // exception level that services HVCs rather than the one that invokes them.
> //
> if (ArmReadCurrentEL () == AARCH64_EL2) {
> Status = PcdSetBoolS (PcdMonitorConduitHvc, FALSE); // The function
> is never returned in my case
> ASSERT_EFI_ERROR (Status);
> }
> #endif
I'm able to reproduce this even without RME. This code was introduced
recently by c98f7f755089 ("ArmVirtPkg: Use dynamic PCD to set the SMCCC
conduit"). Maybe Ard (Cc'd) knows what could be going wrong here.
A slightly reduced reproducer:
$ cd edk2/
$ build -b DEBUG -a AARCH64 -t GCC5 -p ArmVirtPkg/ArmVirtQemuKernel.dsc
$ cd ..
$ git clone https://github.com/ARM-software/arm-trusted-firmware.git tf-a
$ cd tf-a/
$ make -j CROSS_COMPILE=aarch64-linux-gnu- PLAT=qemu DEBUG=1 LOG_LEVEL=40
QEMU_USE_GIC_DRIVER=QEMU_GICV3
BL33=../edk2/Build/ArmVirtQemuKernel-AARCH64/DEBUG_GCC5/FV/QEMU_EFI.fd all fip
&& \
dd if=build/qemu/debug/bl1.bin of=flash.bin && \
dd if=build/qemu/debug/fip.bin of=flash.bin seek=64 bs=4096
$ qemu-system-aarch64 -M virt,virtualization=on,secure=on,gic-version=3 -cpu
max -m 2G -smp 8 -monitor none -serial mon:stdio -nographic -bios flash.bin
Thanks,
Jean
