On Thu, Nov 16, 2023 at 08:54:44PM +0100, Heinrich Schuchardt wrote:
On 11/16/23 19:35, Tom Rini wrote:
On Wed, Nov 15, 2023 at 03:23:52PM +0100, Heinrich Schuchardt wrote:
If U-Boot provides ACPI tables on RISC-V QEMU, we need to copy what QEMU provides.
Provide the qfw command to retrieve information from the QEMU firmware.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
board/emulation/qemu-riscv/Kconfig | 2 ++ lib/Kconfig | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/board/emulation/qemu-riscv/Kconfig b/board/emulation/qemu-riscv/Kconfig index d56b4b5bc1..933b035991 100644 --- a/board/emulation/qemu-riscv/Kconfig +++ b/board/emulation/qemu-riscv/Kconfig @@ -33,6 +33,8 @@ config BOARD_SPECIFIC_OPTIONS # dummy def_bool y select GENERIC_RISCV select SUPPORT_SPL
- select CMD_QFW if GENERATE_ACPI_TABLE
- select QFW_MMIO if GENERATE_ACPI_TABLE imply AHCI imply SMP imply BOARD_LATE_INIT
diff --git a/lib/Kconfig b/lib/Kconfig index 19649517a3..a94adc388f 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -300,7 +300,7 @@ config SPL_ACPI config GENERATE_ACPI_TABLE bool "Generate an ACPI (Advanced Configuration and Power Interface) table" depends on ACPI
- select QFW if QEMU
- select QFW if QEMU || TARGET_QEMU_VIRT help The Advanced Configuration and Power Interface (ACPI) specification provides an open standard for device configuration and management
In this case we aren't "generating" the table, we're using the table we've been passed, yes? I think that further shows the need to add a symbol which means that, and use it where appropriate. Or am I misunderstanding the GENERATE_ACPI_TABLE symbol?
If you look at drivers/misc/qfw.c you will find, that we only read ACPI tables created in QEMU if CONFIG_GNERATE_ACPI_TABLE=y. This contradicts the long text of the configuration symbol.
CONFIG_GNERATE_ACPI_TABLE is used to decide if we publish a device-tree in the EFI sub-system.
Simon tried to clean up EFI a bit in 53e8e6f98679 ("efi: x86: Correct the condition for installing ACPI tables") but did not change cmd/bootefi.c.
I would agree to calling the current usage of the symbol incoherent.
Yes, we need to start by making our ACPI-related symbols coherent. We need a symbol for "create ACPI tables" such as we seem to be doing in for example arch/x86/cpu/baytrail/acpi.c. And then a different symbol for utilizing pass-through tables. And then probably another symbol or two to handle what U-Boot does with these tables once U-Boot has access to a populated table.