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
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
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
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
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
>
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
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