The U-Boot project has been assigned the vendor ID 'UBOO' [1]. Use this
vendor ID and our release version in the ACPI table headers.

[1] ACPI ID Registry
    https://uefi.org/ACPI_ID_List

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Heinrich Schuchardt <heinrich.schuchardt@canonical.com> says:

Introduce a new function to update ACPI table headers.
This allows to simplify the existing code.

Link: https://lore.kernel.org/r/20250321232121.251800-1-heinrich.schuchardt@canonical.com

Use acpi_update_checksum() for updating ACPI table header checksum.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>

Simon Glass <sjg@chromium.org> says:

U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it
is not perfect.

With both builds, executing the VESA ROM causes an intermittent hang, at
least on some AMD CPUs.

With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit)
is done in a way that works on real hardware but not with QEMU. This
means that performance is 4-5x slower than it could be, at least on my
CPU.

We can work around the first problem by using Bochs, which is anyway a
better choice than VESA for QEMU. The second can be addressed by using
the same descriptor across the jump to long mode.

With an MTRR fix this allows booting into Ubuntu on qemu-x86_64

In v3 some e820 patches are included to make booting reliable and avoid
ACPI tables being dropped. Also, several MTTR problems are addressed, to
support memory sizes above 4GB reliably.

Link: https://lore.kernel.org/all/20250315142643.2600605-1-sjg@chromium.org/

This table lacks a correct checksum at present, so fix it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

The values in the FADT are pointers so should not go through sandbox's
normal addr<->pointer mapping. Fix this.

Signed-off-by: Simon Glass <sjg@chromium.org>

The spec recommends to set the mapping_offset only when there are
ID mappings as indicated by the mapping_count field.

Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>

The IORT spec says that reserved bits must be set to zero, thus clear
all fields of the struct before starting to fill out non-reserved
fields.

Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>

Check that the provided offsets are really pointing to a node
that have been previously written and are of the correct type.

Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>

Even though the RC node has the correct size and the ID mappings
are written to the end of the node, the ID 'mapping offset' and
'mapping count' are not written in the IORT RC node header, thus it
looks like that the RC node has no ID mappings.
The Linux kernel doesn't complain about the invalid IORT RC node,
even though the spec says that each RC node must have an ID mapping.
The kernel will fail to use MSI IRQs and fall back to a legacy IRQ
mechanism that's not working either.
Finally it will show strange behaviour around PCI interrupts, making it
hard to trace back to an invalid IORT RC nodes.

Add the missing ID mapping count and mapping offset.

TEST: Fixes IRQ usage of PCI devices on qemu/sbsa-ref.
Fixes: bf5d37662da5 "acpi: acpi_table: Add IORT support"

Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>