Hi Leif,
Thank you very much for your feedback.
On Wed, 12 Aug 2020 at 19:41, Leif Lindholm via Asa-dev
<asa-dev(a)op-lists.linaro.org> wrote:
>
> Hi all,
>
> We've started looking at the TF-A qemu_sbsa port a bit, and found some
> things that were carried over from the mach-virt port for no good
> reason:
>
> Looking at plat/qemu/qemu_sbsa/platform.mk:
> - lib/cpus/aarch64/aem_generic.S is for fast models/foundation model.
> - although we may want to add a "generic armv8 cpu" to TF-A at some
> point, to reduce synchronization needs when bumping the cpu
> used by sbsa-ref in upstream QEMU.
For now, do we need to remove lib/cpus/aarch64/aem_generic.S
and lib/cpus/aarch64/cortex_a57.S from sbsa-qemu?
> - lib/cpus/aarch64/cortex_a53.S is not supported by sbsa-ref, nor does
> the A53 support enough physical address bits to be able to control
> this platform.
I'm not familiar with this item, is this a matter of QEMU side?
> - drivers/io/io_semihosting.c, lib/semihosting/semihosting.c, and
> lib/semihosting/${ARCH}/semihosting_call.S are not actually used.
> But there *are* some other bits of qemu/common code which needs to
> be cinditionalized-out if these files aren't included.
We are not using semi-hosting, I will try to remove these files
from the build target.
> - plat/common/plat_psci_common.c
> - all of the ${ARCH} stanzas should just be 'aarch64', this platform
> cannot be booted in aarch32.
I will fix this.
> - plat/common/plat_psci_common.c isn't usefully hooked up to anything
> at the moment, but we can fix that when we get to actually
> implementing useful PSCI. That file may simply not belong in
> 'common'.
I'm still checking the contents of plat/common/plat_psci_common.c, most of the
functions are optional.
Regards,
Masahisa
>
> /
> Leif
>
> --
> Asa-dev mailing list
> Asa-dev(a)op-lists.linaro.org
> https://op-lists.linaro.org/mailman/listinfo/asa-dev
On Tue, Aug 25, 2020 at 12:34:20PM +0000, Masahisa Kojima via Asa-dev wrote:
> Hi Leif,
>
> Thank you very much for your feedback.
>
> On Wed, 12 Aug 2020 at 19:41, Leif Lindholm via Asa-dev
> <asa-dev(a)op-lists.linaro.org> wrote:
> >
> > Hi all,
> >
> > We've started looking at the TF-A qemu_sbsa port a bit, and found some
> > things that were carried over from the mach-virt port for no good
> > reason:
> >
> > Looking at plat/qemu/qemu_sbsa/platform.mk:
> > - lib/cpus/aarch64/aem_generic.S is for fast models/foundation model.
> > - although we may want to add a "generic armv8 cpu" to TF-A at some
> > point, to reduce synchronization needs when bumping the cpu
> > used by sbsa-ref in upstream QEMU.
>
> For now, do we need to remove lib/cpus/aarch64/aem_generic.S
> and lib/cpus/aarch64/cortex_a57.S from sbsa-qemu?
>
> > - lib/cpus/aarch64/cortex_a53.S is not supported by sbsa-ref, nor does
> > the A53 support enough physical address bits to be able to control
> > this platform.
>
> I'm not familiar with this item, is this a matter of QEMU side?
>
> > - drivers/io/io_semihosting.c, lib/semihosting/semihosting.c, and
> > lib/semihosting/${ARCH}/semihosting_call.S are not actually used.
> > But there *are* some other bits of qemu/common code which needs to
> > be cinditionalized-out if these files aren't included.
>
> We are not using semi-hosting, I will try to remove these files
> from the build target.
>
> > - plat/common/plat_psci_common.c
> > - all of the ${ARCH} stanzas should just be 'aarch64', this platform
> > cannot be booted in aarch32.
>
> I will fix this.
>
> > - plat/common/plat_psci_common.c isn't usefully hooked up to anything
> > at the moment, but we can fix that when we get to actually
> > implementing useful PSCI. That file may simply not belong in
> > 'common'.
>
> I'm still checking the contents of plat/common/plat_psci_common.c, most of the
> functions are optional.
>
Hi Masahisa, thanks for taking this on, just for your information I have
been working on PSCI communicating with QEMU for shutdown/reset purposes
so have currently this branch of stuff I had to break out of common qemu
directory.
https://github.com/xXorAa/trusted-firmware-a/tree/secure-ec-wip
But I haven't done an in depth cleanup yet to make it more fine grained
so if you have any comments or advice based on your work they would be
greatfully received.
Thanks
Graeme
On Fri, 21 Aug 2020, at 11:34 AM, Masahisa Kojima via Asa-dev wrote:
> Hi all,
>
> I make StandaloneMM with secure varstore work on SBSA-QEMU.
>
> One item I would like to discuss is the location of non-secure shared memory
> between UEFI and Secure-EL0(StandaloneMM).
>
> For StandaloneMM, non-secure shared memory must be defined
> in compile time, because there is no method to know the
> shared memory address between uefi and tf-a in runtime.
>
I maybe missing something here, but ARM-TF can and does pass on a DT to edk2, can this not be defined there?
Graeme
> I allocated this non-secure shared memory at the bottom of the DRAM,
> because DRAM size varies depending on the QEMU parameter.
>
> DRAM layout is as follows(when the DRAM size is 1GB)
> 0x10000000000 - 0x10000FFFFFF(16MB) non-secure shared memory for StandaloneMM
> 0x10001000000 - 0x1003FFFFFFF(1GB - 16MB)
>
> Does anyone have comments on this?
> My concern is allocating something at the bottom of the DRAM is not
> the usual implementation?
> # Other packages like SGI allocate it at the top of DRAM.
>
> https://github.com/tianocore/edk2-platforms/blob/master/Platform/ARM/SgiPkg…
>
> --- patch ---
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> index 7d9a9cc50bf3..7ec5669615f0 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> @@ -387,7 +387,8 @@ [PcdsFixedAtBuild.common]
> gArmTokenSpaceGuid.PcdVFPEnabled|1
>
> # System Memory Base -- fixed
> - gArmTokenSpaceGuid.PcdSystemMemoryBase|0x10000000000
> + gArmTokenSpaceGuid.PcdSystemMemoryBase|0x10001000000
>
> diff --git a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c
> index 8c2eb0b6a028..7af9f5a4a1dc 100644
> --- a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c
> +++ b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c
> @@ -73,8 +73,13 @@ SbsaQemuLibConstructor (
> }
> }
>
> + // For StandaloneMM Non-Secure Shared buffer, reserve 16MB
> + // at the bottom of DRAM.
> + NewSize -= 0x1000000;
> +
> // Make sure the start of DRAM matches our expectation
> - ASSERT (FixedPcdGet64 (PcdSystemMemoryBase) == NewBase);
> + // remove base address check
> +// ASSERT (FixedPcdGet64 (PcdSystemMemoryBase) == NewBase);
> PcdStatus = PcdSet64S (PcdSystemMemorySize, NewSize);
> ------
>
> Regards,
> Masahisa
> --
> Asa-dev mailing list
> Asa-dev(a)op-lists.linaro.org
> https://op-lists.linaro.org/mailman/listinfo/asa-dev
>
Hi all,
I make StandaloneMM with secure varstore work on SBSA-QEMU.
One item I would like to discuss is the location of non-secure shared memory
between UEFI and Secure-EL0(StandaloneMM).
For StandaloneMM, non-secure shared memory must be defined
in compile time, because there is no method to know the
shared memory address between uefi and tf-a in runtime.
I allocated this non-secure shared memory at the bottom of the DRAM,
because DRAM size varies depending on the QEMU parameter.
DRAM layout is as follows(when the DRAM size is 1GB)
0x10000000000 - 0x10000FFFFFF(16MB) non-secure shared memory for StandaloneMM
0x10001000000 - 0x1003FFFFFFF(1GB - 16MB)
Does anyone have comments on this?
My concern is allocating something at the bottom of the DRAM is not
the usual implementation?
# Other packages like SGI allocate it at the top of DRAM.
https://github.com/tianocore/edk2-platforms/blob/master/Platform/ARM/SgiPkg…
--- patch ---
diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
index 7d9a9cc50bf3..7ec5669615f0 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
@@ -387,7 +387,8 @@ [PcdsFixedAtBuild.common]
gArmTokenSpaceGuid.PcdVFPEnabled|1
# System Memory Base -- fixed
- gArmTokenSpaceGuid.PcdSystemMemoryBase|0x10000000000
+ gArmTokenSpaceGuid.PcdSystemMemoryBase|0x10001000000
diff --git a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c
b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c
index 8c2eb0b6a028..7af9f5a4a1dc 100644
--- a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c
+++ b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c
@@ -73,8 +73,13 @@ SbsaQemuLibConstructor (
}
}
+ // For StandaloneMM Non-Secure Shared buffer, reserve 16MB
+ // at the bottom of DRAM.
+ NewSize -= 0x1000000;
+
// Make sure the start of DRAM matches our expectation
- ASSERT (FixedPcdGet64 (PcdSystemMemoryBase) == NewBase);
+ // remove base address check
+// ASSERT (FixedPcdGet64 (PcdSystemMemoryBase) == NewBase);
PcdStatus = PcdSet64S (PcdSystemMemorySize, NewSize);
------
Regards,
Masahisa
This patch series adds support for ACPI tables on the
SBSA Qemu platform. We are using a pseudo static
approach to create the ACPI tables. Some of the tables
such as DSDT, MCFG, SPCR, GTDT are created in a static
way at compile time because they hold a fixed configuration
and there are no changes at runtime.
The MADT and SSDT are dependant on the number of CPUs and
hence they are created at runtime based on the number of
CPUs the user has requested.
Changes in V2:
- Add support for SSDT table creation
- Addressed the comments of V1 patch
o Moved PCI changes to a separate patch
o Used Pcd to create common ACPI fields such as OEMID,
OEM revision etc.
o Created an Include directory to hold the common
header files for ACPI
Tanmay Jagdale (5):
SbsaQemu: Initial support for static ACPI tables
SbsaQemu: AcpiTables: Add PCI support and MCFG Table
SbsaQemu: Add new ACPI driver and FDT parser to count CPU
SbsaQemu: AcpiDxe: Create MADT table at runtime
SbsaQemu: AcpiDxe: Add support to SSDT Table
Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 12 +-
Platform/Qemu/SbsaQemu/SbsaQemu.fdf | 9 +
Silicon/Qemu/SbsaQemu/Acpi.dsc.inc | 36 ++
.../Qemu/SbsaQemu/AcpiTables/AcpiTables.inf | 46 ++
Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl | 449 ++++++++++++++++++
Silicon/Qemu/SbsaQemu/AcpiTables/Fadt.aslc | 80 ++++
Silicon/Qemu/SbsaQemu/AcpiTables/Gtdt.aslc | 67 +++
Silicon/Qemu/SbsaQemu/AcpiTables/Mcfg.aslc | 43 ++
Silicon/Qemu/SbsaQemu/AcpiTables/Spcr.aslc | 53 +++
.../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c | 379 +++++++++++++++
.../SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf | 67 +++
.../SbsaQemuPlatformDxe.inf | 1 -
.../Include/IndustryStandard/SbsaQemuAcpi.h | 81 ++++
Silicon/Qemu/SbsaQemu/SbsaQemu.dec | 8 +-
14 files changed, 1326 insertions(+), 5 deletions(-)
create mode 100644 Silicon/Qemu/SbsaQemu/Acpi.dsc.inc
create mode 100644 Silicon/Qemu/SbsaQemu/AcpiTables/AcpiTables.inf
create mode 100644 Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
create mode 100644 Silicon/Qemu/SbsaQemu/AcpiTables/Fadt.aslc
create mode 100644 Silicon/Qemu/SbsaQemu/AcpiTables/Gtdt.aslc
create mode 100644 Silicon/Qemu/SbsaQemu/AcpiTables/Mcfg.aslc
create mode 100644 Silicon/Qemu/SbsaQemu/AcpiTables/Spcr.aslc
create mode 100644 Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
create mode 100644 Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
create mode 100644 Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h
--
2.28.0
Hi all,
We've started looking at the TF-A qemu_sbsa port a bit, and found some
things that were carried over from the mach-virt port for no good
reason:
Looking at plat/qemu/qemu_sbsa/platform.mk:
- lib/cpus/aarch64/aem_generic.S is for fast models/foundation model.
- although we may want to add a "generic armv8 cpu" to TF-A at some
point, to reduce synchronization needs when bumping the cpu
used by sbsa-ref in upstream QEMU.
- lib/cpus/aarch64/cortex_a53.S is not supported by sbsa-ref, nor does
the A53 support enough physical address bits to be able to control
this platform.
- drivers/io/io_semihosting.c, lib/semihosting/semihosting.c, and
lib/semihosting/${ARCH}/semihosting_call.S are not actually used.
But there *are* some other bits of qemu/common code which needs to
be cinditionalized-out if these files aren't included.
- plat/common/plat_psci_common.c
- all of the ${ARCH} stanzas should just be 'aarch64', this platform
cannot be booted in aarch32.
- plat/common/plat_psci_common.c isn't usefully hooked up to anything
at the moment, but we can fix that when we get to actually
implementing useful PSCI. That file may simply not belong in
'common'.
/
Leif
I have played with ARM Enterprise ACS test suite yesterday locally.
It can not be added to CI yet as it requires working watchdog and reset
needs to function too (ASA-54).
Part of it was run of Luv. I put results online as someone may find it
interesting and useful:
https://people.linaro.org/~marcin.juszkiewicz/sbsa/luv-results-2020-08-06--…
I can add them to CI if this would be useful.
