Hi Heinrich,
On Thu, 16 Nov 2023 at 12:43, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 11/16/23 19:33, Tom Rini wrote:
On Wed, Nov 15, 2023 at 03:23:50PM +0100, Heinrich Schuchardt wrote:
RISC-V QEMU provides the ACPI tables. We do not need to generate them ourselves.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
lib/acpi/Makefile | 2 +- lib/acpi/acpi_writer.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/acpi/Makefile b/lib/acpi/Makefile index c1c9675b5d..19fa6ac869 100644 --- a/lib/acpi/Makefile +++ b/lib/acpi/Makefile @@ -12,7 +12,7 @@ obj-$(CONFIG_$(SPL_)ACPIGEN) += acpi_table.o obj-y += acpi_writer.o
# With QEMU the ACPI tables come from there, not from U-Boot -ifndef CONFIG_QEMU +ifeq ($(CONFIG_QEMU)$(CONFIG_TARGET_QEMU_VIRT),)
The goal here is to say that we have been passed ACPI tables, and not to generate them, yes? Lets just introduce a symbol which says that and enable it as needed in both QEMU targets and others as needed please.
These are the conflicting function implementations:
drivers/misc/qfw.c:158:ulong write_acpi_tables(ulong addr) lib/acpi/acpi_writer.c:72:ulong write_acpi_tables(ulong start_addr)
drivers/misc/Makefile has:
ifdef CONFIG_QFW obj-y += qfw.o
but inside the driver we find another constraint:
#if defined(CONFIG_GENERATE_ACPI_TABLE) && !defined(CONFIG_SANDBOX)
So probably we should probably have a symbol which is set for
CONFIG_QFW && CONFIG_GENERATE_ACPI_TABLE && !CONFIG_SANDBOX
Maybe call it CONFIG_QFW_ACPI, "Read ACPI tables from QEMU".
Yes that sounds good.
Regards, Simon