[PATCH v3 22/30] board: emulation: Add QEMU sbsa support

Patrick Rudolph patrick.rudolph at 9elements.com
Thu Sep 12 08:23:40 CEST 2024


On Thu, Sep 12, 2024 at 2:58 AM Simon Glass <sjg at chromium.org> wrote:
>
> Hi Patrick,
>
> On Wed, 11 Sept 2024 at 00:26, Patrick Rudolph
> <patrick.rudolph at 9elements.com> wrote:
> >
> > Add support for Arm sbsa [1] v0.3+ that is supported by QEMU [2].
> >
> > Unlike other Arm based platforms the machine only provides a minimal
> > FDT that contains number of CPUs, ammount of memory and machine-version.
> > The boot firmware has to provide ACPI tables to the OS.
> >
> > Add a minimal amount of devicetree nodes to make the board useable within
> > U-Boot, provide documentation how to use, enable binman to fabricate both
> > ROMs that are required to boot and add ACPI tables to make it full compatible
> > to the EDK2 reference implementation.
> >
> > The board was tested using Fedora 40 Aarch64 Workstation. It's able
> > to boot from USB and AHCI or network.
> >
> > Tested and found working:
> > - serial
> > - PCI
> > - xHCI
> > - Bochs display
> > - AHCI
> > - network using e1000e
> > - CPU init
> > - Booting Fedora 40
> >
> > 1: Server Base System Architecture (SBSA)
> > 2: https://www.qemu.org/docs/master/system/arm/sbsa.html
> >
> > Signed-off-by: Patrick Rudolph <patrick.rudolph at 9elements.com>
> > Cc: Peter Robinson <pbrobinson at gmail.com>
> > Cc: Simon Glass <sjg at chromium.org>
> > Cc: Tom Rini <trini at konsulko.com>
> > ---
> > Changelog v3:
> > - Add GIC and GIC-ITS to devicetree
> > - Select GICv3 driver
> > - Drop acpi_fill_madt and use driver model instead
> >
> > ---
> >  arch/arm/Kconfig                            |   1 +
> >  arch/arm/dts/qemu-sbsa.dts                  |  49 ++
> >  arch/arm/include/asm/arch-qemu-sbsa/boot0.h |  33 ++
> >  arch/arm/mach-qemu/Kconfig                  |  36 +-
> >  board/emulation/qemu-arm/MAINTAINERS        |   2 +
> >  board/emulation/qemu-sbsa/Kconfig           |  58 +++
> >  board/emulation/qemu-sbsa/Makefile          |   8 +
> >  board/emulation/qemu-sbsa/acpi.c            | 235 ++++++++++
> >  board/emulation/qemu-sbsa/dsdt.asl          | 483 ++++++++++++++++++++
> >  board/emulation/qemu-sbsa/lowlevel_init.S   |  22 +
> >  board/emulation/qemu-sbsa/qemu-sbsa.c       | 481 +++++++++++++++++++
> >  board/emulation/qemu-sbsa/qemu-sbsa.env     |  14 +
> >  board/emulation/qemu-sbsa/qemu-sbsa.h       |  38 ++
> >  board/emulation/qemu-sbsa/smc.c             |  72 +++
> >  configs/qemu-arm-sbsa_defconfig             |  10 +
> >  doc/board/emulation/index.rst               |   1 +
> >  doc/board/emulation/qemu-sbsa.rst           |  98 ++++
> >  doc/develop/driver-model/virtio.rst         |   1 +
> >  include/configs/qemu-sbsa.h                 |  98 ++++
> >  19 files changed, 1734 insertions(+), 6 deletions(-)
> >  create mode 100644 arch/arm/dts/qemu-sbsa.dts
> >  create mode 100644 arch/arm/include/asm/arch-qemu-sbsa/boot0.h
> >  create mode 100644 board/emulation/qemu-sbsa/Kconfig
> >  create mode 100644 board/emulation/qemu-sbsa/Makefile
> >  create mode 100644 board/emulation/qemu-sbsa/acpi.c
> >  create mode 100644 board/emulation/qemu-sbsa/dsdt.asl
> >  create mode 100644 board/emulation/qemu-sbsa/lowlevel_init.S
> >  create mode 100644 board/emulation/qemu-sbsa/qemu-sbsa.c
> >  create mode 100644 board/emulation/qemu-sbsa/qemu-sbsa.env
> >  create mode 100644 board/emulation/qemu-sbsa/qemu-sbsa.h
> >  create mode 100644 board/emulation/qemu-sbsa/smc.c
> >  create mode 100644 configs/qemu-arm-sbsa_defconfig
> >  create mode 100644 doc/board/emulation/qemu-sbsa.rst
> >  create mode 100644 include/configs/qemu-sbsa.h
>
> Wow there is a lot in this patch!
>
> I don't think this should be in a separate subdir, just using
> board/emulation/qemu-arm should be OK?
Why would it share the code base with qemu-arm, as it's a completely
different board?

>
> I see you are setting plat data in the board file...is there not a CPU
> driver which can read it from the devicetree or set it based on the
> compatible string?
The CPU driver could read the data from devicetree, but that would require a new
DT binding. Is that the preferred method over using plat data?

>
> For FDT fixup, can you please use the event and the ofnode interface?
> See EVT_FT_FIXUP and bootmeth_vbe_ft_fixup() as an example.
>
> Regards,
> Simon


More information about the U-Boot mailing list