On 2020.03.30 15:19, Ard Biesheuvel wrote:
On Mon, 30 Mar 2020 at 16:07, Pete Batard <[email protected]> wrote:
On 2020.03.30 15:01, Ard Biesheuvel wrote:
On Mon, 30 Mar 2020 at 15:56, Pete Batard <[email protected]> wrote:
On 2020.03.30 14:20, Ard Biesheuvel wrote:
On Mon, 30 Mar 2020 at 15:12, Ard Biesheuvel <[email protected]> wrote:
On Mon, 30 Mar 2020 at 15:09, Pete Batard <[email protected]> wrote:
On 2020.03.30 14:06, Ard Biesheuvel wrote:
On Fri, 27 Mar 2020 at 14:06, Pete Batard <[email protected]> wrote:
Incidentally, this is not an [edk2-platform] patch, as the subject line
from previous mail seemed to indicate, but an [edk2] patch.
Do we have a user for this?
Yes we do. I have a pachset lined up that updates the Raspberry Pi ACPI
to 6.3, that has a dependency on this.
But does the RPi have SPE and the associated overflow interrupt?
No, but it doesn't matter since the specs indicate that SPE values can
be set to zero if unused/non-applicable.
ACPI
is designed to be backward compatible, so it is perfectly acceptable
to use the 6.2 macros in the context of a firmware implementation that
complies with 6.3.
This is what happens if you try to use EFI_ACPI_6_0_GICC_STRUCTURE_INIT
in a 6.3 context:
/usr/src/edk2/MdePkg/Include/IndustryStandard/Acpi10.h:297:33: error:
excess elements in scalar initializer [-Werror]
#define EFI_ACPI_RESERVED_BYTE 0x00
^~~~
Building ...
/usr/src/edk2/MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf [AARCH64]
/usr/src/edk2/EmbeddedPkg/Include/Library/AcpiLib.h:64:30: note: in
expansion of macro ‘EFI_ACPI_RESERVED_BYTE’
{EFI_ACPI_RESERVED_BYTE, EFI_ACPI_RESERVED_BYTE,
EFI_ACPI_RESERVED_BYTE} \
^~~~~~~~~~~~~~~~~~~~~~
/usr/src/edk2-platforms/Platform/RaspberryPi/AcpiTables/Madt.aslc:64:5:
note: in expansion of macro ‘EFI_ACPI_6_0_GICC_STRUCTURE_INIT’
EFI_ACPI_6_0_GICC_STRUCTURE_INIT (
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
What do you mean exactly by 'in a 6.3 context': are you trying to
statically initialize a 63 struct with the 60 macro?
Yes. I am trying to upgrade all of our ACPI tables to 6.3, on account
that (part of a commit message from the edk2-platform I have lined up):
-----------------------------------------------------------------------
Because of its widespread availability and low price, we expect the
Raspberry Pi source to be used by platform developers as a starting
point to create their own platform implementation.
Actually, even though I *really* like the RPi4 port in terms of
functionality and polish, it is *not* a good example to follow to
build a new platform.
First of all, it is based on PrePi instead of PrePeiCore, and so it is
very difficult to add PEI phase drivers for, e.g., capsule update or
measured boot. But in general, the quirky hardware and firmware
arrangement make it a one-off design IMO, and new platforms should use
something like SynQuacer as a reference instead.
I'll be the first to agree that are much better platforms to use as
starting point. Unfortunately they don't come at the same price point
and widespread availability, which is why I think there is value is
trying to showcase what we can with the Pi's, despite their major
annoying quirks.
Regards,
/Pete
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#56646): https://edk2.groups.io/g/devel/message/56646
Mute This Topic: https://groups.io/mt/72586671/21656
Group Owner: [email protected]
Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
