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>

Tom Rini <trini@konsulko.com> says:

This series switches to always using $(PHASE_) in Makefiles when
building rather than $(PHASE_) or $(XPL_). It also starts on documenting
this part of the build, but as a follow-up we need to rename
doc/develop/spl.rst and expand on explaining things a bit.

Link: https://lore.kernel.org/r/20250401225851.1125678-1-trini@konsulko.com

It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.

Signed-off-by: Tom Rini <trini@konsulko.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>

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

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

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>