[PATCH v8 00/37] Implement ACPI on aarch64

[Peter Robinson]

On Tue, 15 Oct 2024 at 16:28, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Peter,
>
> On Tue, 15 Oct 2024 at 07:34, Peter Robinson <pbrobinson at gmail.com> wrote:
> >
> > On Tue, 15 Oct 2024 at 14:10, Simon Glass <sjg at chromium.org> wrote:
> > >
> > > Hi Peter,
> > >
> > > On Tue, 15 Oct 2024 at 04:28, Peter Robinson <pbrobinson at gmail.com> wrote:
> > > >
> > > > On Mon, 14 Oct 2024 at 14:12, Patrick Rudolph
> > > > <patrick.rudolph at 9elements.com> wrote:
> > > > >
> > > > > Based on the existing work done by Simon Glass this series adds
> > > > > support for booting aarch64 devices using ACPI only.
> > > > > As first target QEMU SBSA support is added, which relies on ACPI
> > > > > only to boot an OS. As secondary target the Raspberry Pi4 was used,
> > > > > which is broadly available and allows easy testing of the proposed
> > > > > solution.
> > > > >
> > > > > The series is split into ACPI cleanups and code movements, adding
> > > > > Arm specific ACPI tables and finally SoC and mainboard related
> > > > > changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the
> > > > > mandatory ACPI tables are supported, allowing to boot into Linux
> > > > > without errors.
> > > > >
> > > > > The QEMU SBSA support is feature complete and provides the same
> > > > > functionality as the EDK2 implementation.
> > > > >
> > > > > The changes were tested on real hardware as well on QEMU v9.0:
> > > > >
> > > > > qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \
> > > > >                     -pflash secure-world.rom \
> > > > >                     -pflash unsecure-world.rom
> > > > >
> > > > > qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \
> > > > > -smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \
> > > > > -dtb bcm2711-rpi-4-b.dtb -nographic
> > > > >
> > > > > Tested against FWTS V24.03.00.
> > > > >
> > > > > Known issues:
> > > > > - The QEMU rpi4 support is currently limited as it doesn't emulate PCI,
> > > > >   USB or ethernet devices!
> > > > > - The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly
> > > > >   cache related).
> > > > > - PCI on RPI4 isn't working on real hardware since the pcie_brcmstb
> > > >
> > > > I believe the EDK2 version works by using the generic ACPI PCI driver,
> > > > why wouldn't this use the same driver?
> > > >
> > > > Overall given RPi4 has massive limitations I think at the moment it
> > > > should be dropped from the series so it doesn't block the
> > > > generic/qemu/bsa support landing. I feel it will be a support problem
> > > > with having such a reduced functionality device in mainline.
> > >
> > > Perhaps this could be handled in a follow-up? We are on v8 here.
> >
> > What exactly done in a follow up?
>
> Anything to do with the real rpi. It is far better to have a starting point.

According to the docs above the SMP bring up doesn't work and nor does
the PCI support. Users won't have a great experience and complain.

> >
> > > Who is going to support this?
> >
> > Support what?
>
> You tell me? I didn't understand your question either.

>From a RPi PoV I am sure there will be complaints, as the maintainer I
get emails all the time, I don't need any more.

> >
> > > >
> > > > >   Linux kernel module doesn't support ACPI yet.
> > > > >
> > > > > Maximilian Brune (3):
> > > > >   acpi: x86: Move SPCR and DBG2 into common code
> > > > >   acpi: x86: Write FADT in common code
> > > > >   serial: serial_pl01x: Implement .getinfo() for PL01
> > > > >
> > >
> > > [..]
> > >
> > > Regards,
> > > Simon
>
> Regards,
> Simon