public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ard Biesheuvel" <ard.biesheuvel@linaro.org>
To: Pete Batard <pete@akeo.ie>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>,
	Leif Lindholm <leif@nuviainc.com>
Subject: Re: [PATCH 1/1] EmbeddedPkg/AcpiLib: add GICC table init macro for ACPI 6.3
Date: Mon, 30 Mar 2020 16:19:16 +0200	[thread overview]
Message-ID: <CAKv+Gu-_HdL-q9vBk7nG1zhPvLOm62PqS-q05G4ZvmDtTeReDQ@mail.gmail.com> (raw)
In-Reply-To: <b94534ef-cb84-b657-ddf3-e1ab0eda7326@akeo.ie>

On Mon, 30 Mar 2020 at 16:07, Pete Batard <pete@akeo.ie> wrote:
>
> On 2020.03.30 15:01, Ard Biesheuvel wrote:
> > On Mon, 30 Mar 2020 at 15:56, Pete Batard <pete@akeo.ie> wrote:
> >>
> >> On 2020.03.30 14:20, Ard Biesheuvel wrote:
> >>> On Mon, 30 Mar 2020 at 15:12, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >>>>
> >>>> On Mon, 30 Mar 2020 at 15:09, Pete Batard <pete@akeo.ie> wrote:
> >>>>>
> >>>>> On 2020.03.30 14:06, Ard Biesheuvel wrote:
> >>>>>> On Fri, 27 Mar 2020 at 14:06, Pete Batard <pete@akeo.ie> 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.

  parent reply	other threads:[~2020-03-30 14:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-27 13:01 [edk2-platforms][PATCH 1/1] EmbeddedPkg/AcpiLib: add GICC table init macro for ACPI 6.3 Pete Batard
2020-03-27 13:06 ` [PATCH " Pete Batard
2020-03-30 13:06   ` Ard Biesheuvel
2020-03-30 13:09     ` Pete Batard
2020-03-30 13:12       ` Ard Biesheuvel
2020-03-30 13:20         ` Ard Biesheuvel
2020-03-30 13:56           ` Pete Batard
2020-03-30 14:01             ` Ard Biesheuvel
2020-03-30 14:06               ` Pete Batard
2020-03-30 14:16                 ` Ard Biesheuvel
2020-03-30 14:29                   ` Pete Batard
2020-03-30 14:34                     ` Ard Biesheuvel
2020-03-30 14:39                       ` Pete Batard
2020-03-30 14:42                         ` Ard Biesheuvel
2020-03-30 14:50                           ` Pete Batard
2020-03-30 14:19                 ` Ard Biesheuvel [this message]
2020-03-30 14:33                   ` Pete Batard
2020-03-30 14:48 ` [edk2-platforms][PATCH " Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKv+Gu-_HdL-q9vBk7nG1zhPvLOm62PqS-q05G4ZvmDtTeReDQ@mail.gmail.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox