- Asa-dev - op-lists.linaro.org

Re: [Asa-dev] Pseudo Static ACPI tables for Qemu Sbsa platform

by Graeme Gregory

On 29/07/2020 21:35, Tanmay Jagdale via Asa-dev wrote: > Hi Leif, Graeme, > > I have pushed the following branch that adds support for the > pseudo static approach of modifying the ACPI tables. > http://git.linaro.org/people/tanmay.jagdale/edk2-platforms.git/log/?h=qemu_… > > With this we can boot Linux with any number of CPUs and the > ACPI tables will get configured at runtime based on the CPU > count. > > I have separated them into 4 commits and a patch with all the > changes consolidated into one is in the attached file. > > There are a few issues > 1. We have to pass acpi_apic_instance=2 bootarg to Linux because > 2 APIC tables are getting created we have to use the 2nd instance > which gets created at runtime. > I'm working on a fix for this issue. I think if you just rename the madt.aslc to madt.c this will fix that. The aslc extension means that version of the table automatically gets installed. Thanks Graeme > 2. The SSDT table does not have entries for all CPUs and I'm working > on updating that table too. > > Can you please review this patchset and see if these changes are > okay ? > > With Regards, > Tanmay

3 years, 9 months

2
3
0 0

Pseudo Static ACPI tables for Qemu Sbsa platform

by Tanmay Jagdale

Hi Leif, Graeme, I have pushed the following branch that adds support for the pseudo static approach of modifying the ACPI tables. http://git.linaro.org/people/tanmay.jagdale/edk2-platforms.git/log/?h=qemu_… With this we can boot Linux with any number of CPUs and the ACPI tables will get configured at runtime based on the CPU count. I have separated them into 4 commits and a patch with all the changes consolidated into one is in the attached file. There are a few issues 1. We have to pass acpi_apic_instance=2 bootarg to Linux because 2 APIC tables are getting created we have to use the 2nd instance which gets created at runtime. I'm working on a fix for this issue. 2. The SSDT table does not have entries for all CPUs and I'm working on updating that table too. Can you please review this patchset and see if these changes are okay ? With Regards, Tanmay

3 years, 9 months

1
0
0 0

Updated TF-A binaries in edk2-non-osi

by Tanmay Jagdale

Hi Graeme and Masahisa, I updated the TF-A binaries in edk2-non-osi (with Masahisa's fix) and pushed to the following branch: http://git.linaro.org/people/tanmay.jagdale/edk2-non-osi.git/commit/?id=aa1… I have tested this by booting on Qemu SBSA and verified that the device tree error is not showing up. Can you please review the patch if it is okay ? If okay then I'll send it out the edk2-non-osi mailing list. With Regards, Tanmay

3 years, 10 months

2
1
0 0

Script for building UEFI

by Graeme Gregory

Hi Tanmay, As asked in the meeting here is the script I use to build with the important but being only updating the 1st 2M of flash between runs so variable area is preserved. #! /bin/bash export WORKSPACE=`pwd` export PACKAGES_PATH=$WORKSPACE/edk2:$WORKSPACE/edk2-platforms:$WORKSPACE/edk2-non-osi make -C edk2/BaseTools . edk2/edksetup.sh GCC5_AARCH64_PREFIX=aarch64-linux-gnu- build -b DEBUG -a AARCH64 -t GCC5 -p edk2-platforms/Platform/Qemu/SbsaQemu/SbsaQemu.dsc dd if=./Build/SbsaQemu/DEBUG_GCC5/FV/SBSA_FLASH0.fd of=qemu-run/SBSA_FLASH0.fd conv=notrunc dd if=./Build/SbsaQemu/DEBUG_GCC5/FV/SBSA_FLASH1.fd of=qemu-run/SBSA_FLASH1.fd conv=notrunc bs=2M count=1 Thanks Graeme

3 years, 11 months

1
0
0 0

Re: [Asa-dev] SbsaQemu Variable Problem

by Tanmay Jagdale

Hi Graeme, The issue lies in the way the Flash1 is laid out. At offset 0x0 - UEFI Compact binary At offset 0x40000 - NorFlash Variable storage with EFI_VOLUME_HEADER So the Arm NorFlash driver looks for EFI_VOLUME_HEADER at 0x0 offset but we have the UEFI binary present hence it couldn't find it and proceeded to reinitialize the flash region at 0x40000, hence all the EFI variables were lost. I have created the following patch in edk2: (This is a hack to get it to work, would need to find a way a more generic way to fix this issue) diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvbDxe.c b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvbDxe.c index e248fdf6db..d8cee8ca24 100644 --- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvbDxe.c +++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvbDxe.c @@ -134,7 +134,8 @@ ValidateFvHeader ( UINTN VariableStoreLength; UINTN FvLength; - FwVolHeader = (EFI_FIRMWARE_VOLUME_HEADER*)Instance->RegionBaseAddress; + FwVolHeader = (EFI_FIRMWARE_VOLUME_HEADER*)(Instance->RegionBaseAddress + + (Instance->StartLba * Instance->Media.BlockSize)); FvLength = PcdGet32(PcdFlashNvStorageVariableSize) + PcdGet32(PcdFlashNvStorageFtwWorkingSize) + PcdGet32(PcdFlashNvStorageFtwSpareSize); This patch makes the header checking code to look at the right offset. Also the following patch in edk2-platforms (This patch is just to make it match the ArmVirt Flash layout) diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf index 7f1a60e3ee..9ccfe7f1fa 100644 --- a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf @@ -58,10 +58,10 @@ FILE = Platform/Qemu/Sbsa/fip.bin [FD.SBSA_FLASH1] BaseAddress = 0x10000000|gArmTokenSpaceGuid.PcdFdBaseAddress -Size = 0x002C0000|gArmTokenSpaceGuid.PcdFdSize +Size = 0x00300000|gArmTokenSpaceGuid.PcdFdSize ErasePolarity = 1 -BlockSize = 0x00001000 -NumBlocks = 0x2C0 +BlockSize = 0x00040000 +NumBlocks = 0xB ## Place for EFI (BL33) # This offset (if any as it is 0x0 currently) + BaseAddress (0x10000000) must be set in PRELOADED_BL33_BASE at ATF @@ -90,8 +90,8 @@ DATA = { 0x5f, 0x46, 0x56, 0x48, 0xff, 0xfe, 0x04, 0x00, # HeaderLength # CheckSum # ExtHeaderOffset #Reserved #Revision 0x48, 0x00, 0x28, 0x09, 0x00, 0x00, 0x00, 0x02, - # Blockmap[0]: 0x3 Blocks * 0x40000 Bytes / Block - 0x3, 0x00, 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, + # Blockmap[0]: 0x4 Blocks * 0x40000 Bytes / Block + 0x4, 0x00, 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, # Blockmap[1]: End 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, ## This is the VARIABLE_STORE_HEADER With the above 2 patches, I'm able to store the EFI variables persistently. Can you please let me know what you think about these patches ? With Regards, Tanmay On Thu, 11 Jun 2020 at 16:55, Graeme Gregory via Asa-dev < asa-dev(a)op-lists.linaro.org> wrote: > Hi Tanmay, > > I was doing some checking and we are causing these errors in log. > > ValidateFvHeader: No Firmware Volume header present > NorFlashFvbInitialize: The FVB Header is not valid. > NorFlashFvbInitialize: Installing a correct one for this volume. > Which is resetting all the variables > > Graeme > -- > Asa-dev mailing list > Asa-dev(a)op-lists.linaro.org > https://op-lists.linaro.org/mailman/listinfo/asa-dev >

3 years, 11 months

1
0
0 0

SbsaQemu Variable Problem

by Graeme Gregory

Hi Tanmay, I was doing some checking and we are causing these errors in log. ValidateFvHeader: No Firmware Volume header present NorFlashFvbInitialize: The FVB Header is not valid. NorFlashFvbInitialize: Installing a correct one for this volume. Which is resetting all the variables Graeme

3 years, 11 months

1
0
0 0

Unable to attend today's team meeting

by Masato Fukumori

Hi Graeme-san, guys I’m sorry, I’m unable to attend team meeting due to other meeting. Let me report my status at next week. Best Regards, Masato Fukumori

3 years, 11 months

1
0
0 0

2024

2023

2022

2021

2020

Asa-dev