Hi Peter,
On Tue, 15 Oct 2024 at 07:34, Peter Robinson pbrobinson@gmail.com wrote:
On Tue, 15 Oct 2024 at 14:10, Simon Glass sjg@chromium.org wrote:
Hi Peter,
On Tue, 15 Oct 2024 at 04:28, Peter Robinson pbrobinson@gmail.com wrote:
On Mon, 14 Oct 2024 at 14:12, Patrick Rudolph patrick.rudolph@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.
Who is going to support this?
Support what?
You tell me? I didn't understand your question either.
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