Fix "Integer handling issues (SIGN_EXTENSION)" in newly added code:
Cast serial_info.reg_offset to u64 to prevent an integer overflow when
shifted too many bits to the left. Currently this never happens as the
shift is supposed to be less than 4.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
This commit introduces a number of failure to build issues. For now,
revert it and we will wait for v2 to address the issue and the build
problems as well.
This reverts commit e1c3c720e7.
Signed-off-by: Tom Rini <trini@konsulko.com>
Fix "Integer handling issues (SIGN_EXTENSION)" in newly added code:
Cast serial_info.reg_offset to u64 to prevent an integer overflow when
shifted too many bits to the left. Currently this never happens as the
shift is supposed to be less than 4.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Moritz Fischer <moritzf@google.com>
Patrick Rudolph <patrick.rudolph@9elements.com> says:
Based on the existing work done by Simon Glass this series adds
support for booting aarch64 devices using ACPI only.
As first target QEMU SBSA support is added, which relies on ACPI
only to boot an OS. As secondary target the Raspberry Pi4 was used,
which is broadly available and allows easy testing of the proposed
solution.
The series is split into ACPI cleanups and code movements, adding
Arm specific ACPI tables and finally SoC and mainboard related
changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the
mandatory ACPI tables are supported, allowing to boot into Linux
without errors.
The QEMU SBSA support is feature complete and provides the same
functionality as the EDK2 implementation.
The changes were tested on real hardware as well on QEMU v9.0:
qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \
-pflash secure-world.rom \
-pflash unsecure-world.rom
qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \
-smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \
-dtb bcm2711-rpi-4-b.dtb -nographic
Tested against FWTS V24.03.00.
Known issues:
- The QEMU rpi4 support is currently limited as it doesn't emulate PCI,
USB or ethernet devices!
- The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly
cache related).
- PCI on RPI4 isn't working on real hardware since the pcie_brcmstb
Linux kernel module doesn't support ACPI yet.
Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com
On Arm platforms that use ACPI they cannot rely on the "spin-table"
CPU bringup usually defined in the FDT. Thus implement the
'ACPI Multi-processor Startup for ARM Platforms', also referred to as
'ACPI parking protocol'.
The ACPI parking protocol works similar to the spin-table mechanism, but
the specification also covers lots of shortcomings of the spin-table
implementations.
Every CPU defined in the ACPI MADT table has it's own 4K page where the
spinloop code and the OS mailbox resides. When selected the U-Boot board
code must make sure that the secondary CPUs enter u-boot after relocation
as well, so that they can enter the spinloop code residing in the ACPI
parking protocol pages.
The OS will then write to the mailbox and generate an IPI to release the
CPUs from the spinloop code.
For now it's only implemented on ARMv8, but can easily be extended to
other platforms, like ARMv7.
TEST: Boots all CPUs on qemu-system-aarch64 -machine raspi4b
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Add a new method to write the processor device identified by _HID
ACPI0007, that is preferred over the Processor OpCode since ACPI 6.0.
Fixes booting arm using ACPI only since the Processor OpCode isn't
found valid by the Linux kernel.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Allocate memory for ACPI tables in generic acpi code. When ACPI wasn't
installed in other places, install the ACPI table using BLOBLISTs.
This allows non x86 platforms to boot using ACPI only in case the
EFI loader is being used, since EFI is necessary to advertise the location
of the ACPI tables in memory.
TEST: Booted QEMU SBSA (no QFW) using EFI and ACPI only.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Since ACPI 2.0 the RSDT is deprecated and the XSDT should be preferred.
Until now the RSDT and XSDT entries were keept in sync as all platforms
that installed ACPI tables placed them below 4GiB and thus the address
would fit into the 32bit RSDT.
On platforms that do not have usable DRAM below 4GiB, like QEMU sbsa,
the RSDT cannot be used. Allow both RSDT and XSDT to be null and only
fill those tables that are present in acpi_add_table().
TEST: Fixes a crash on QEMU sbsa and allows to boot on QEMU sbsa.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
The SoC can implement acpi_fill_iort to update the IORT table.
Add a helper function to fill out the NAMED_COMPONENT node.
TEST=Run FWTS V24.03.00 on RPi4 and round no problems.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Return the ACPI table revision in acpi_get_table_revision() for
PPTT and GTDT. Match both to ACPI 6.2.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
The FADT structure found in U-Boot represents FADT revision 6 and the
GICC and GICD structures defined in U-Boot are based on ACPI revision
6.3.
Bump the table revision to fix FWTS failures seen on aarch64.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Add a new method to acpi_ops to let drivers fill out ACPI MADT.
The code is unused for now until drivers implement the new ops.
TEST: Booted on QEMU sbsa using driver model generated MADT.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Write MADT in common code and let the SoC fill out the body by
calling acpi_fill_madt() which must be implemented at SoC level.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Write the FADT in common code since it's used on all architectures.
Since the FADT is mandatory all SoCs or mainboards must implement the
introduced function acpi_fill_fadt() and properly update the FADT.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
This moves the SPCR and DBG2 table generation into common code, so that
they can be used by architectures other than x86.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Simon Glass <sjg@chromium.org> says:
When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL
Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.
For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:
#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.
This series starts a change in terminology and usage to resolve the
above issues:
- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_
It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.
This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.
The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
Use PHASE_ as the symbol to select a particular XPL build. This means
that SPL_TPL_ is no-longer set.
Update the comment in bootstage to refer to this symbol, instead of
SPL_
Signed-off-by: Simon Glass <sjg@chromium.org>
Read chipselect properties from DT which are populated using 'reg'
property and save it in plat->cs[] array for later use.
Also read multi chipselect capability which is used for
parallel-memories and return errors if they are passed on using DT but
driver is not capable of handling it.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Move this header to include/u-boot/ so that it can be used by external
tools.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
We should have a single place where we write the default value to the
creator revision field. If we ever will have any table created by another
tool, we can overwrite the value afterwards.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The fields Creator ID and Creator Revision contain information about the
tool that created an ACPI table. This may be the ASL compiler for some
tables but it is not for others. Naming these fields aslc_id and
aslc_revision is misleading.
It is usual to see diverse values of Creator ID. On a laptop I saw these:
'AMD ', 'INTL, 'MSFT', 'PTEC'. Obviously not all relate to the Intel
ASL compiler.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
We have two implementations of write_acpi_tables(). One for writing ACPI
tables based on ACPI_WRITER() entries another based on copying tables from
QEMU.
Create a symbol CONFIG_QFW_ACPI that signifies copying ACPI tables from
QEMU and use it consistently.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Use X_DSDT and X_FIRMWARE_CTRL if available.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Rebased on -next to use nomap:
Signed-off-by: Simon Glass <sjg@chromium.org>
Sandbox uses an API to map between addresses and pointers. This allows
it to have (emulated) memory at zero and avoid arch-specific addressing
details. It also allows memory-mapped peripherals to work.
As an example, on many machines sandbox maps address 100 to pointer
value 10000000.
However this is not correct for ACPI, if sandbox starts another program
(e.g EFI app) and passes it the tables. That app has no knowledge of
sandbox's address mapping. So to make this work we want to store
10000000 as the value in the table.
Add two new 'nomap' functions which clearly make this exeption to how
sandbox works.
This should allow EFI apps to access ACPI tables with sandbox, e.g. for
testing purposes.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
The RSDT table is deprecated and does not exist on all systems.
By preference scan XSDT for the table to find. If no XSDT table exists, try
to use the RSDT table.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
* Converting to void * is superfluous when calling memset().
* acpi_fill_header() already fills oem_table_id.
Fixes: d953137526 ("x86: Move SSDT table to a writer function")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The field RsdtAddress has only 32 bit. The RSDT table cannot be located
beyond 4 GiB.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present two acpi files are built every time since they use a version
number from version.h
This is not necessary. Make use of the same technique as for the version
string, so that they are build only when they change.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is useful for other features. Move the function into library code
so it can be used outside just the 'acpi' command.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
We have several Kconfig options for ACPI, but all relate to specific
functions, such as generating tables and AML code.
Add a new option which controls including basic ACPI library code,
including the lib/acpi directory. This will allow us to add functions
which are available even if table generation is not supported.
Adjust the command to avoid a build error when ACPIGEN is not enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
There is a number of users that use uclass_first_device to access the
first and (assumed) only device in uclass.
Some check the return value of uclass_first_device and also that a
device was returned which is exactly what uclass_first_device_err does.
Some are not checking that a device was returned and can potentially
crash if no device exists in the uclass. Finally there is one that
returns NULL on error either way.
Convert all of these to use uclass_first_device_err instead, the return
value will be removed from uclass_first_device in a later patch.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
MCFG tables are used on multiple arches. Move to common ACPI lib.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Moritz Fischer <moritzf@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Use sizeof(*mcfg) instead of sizeof(*header)
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this list is used to collect items within the DSDT and SSDT
tables. It is useful for it to collect the whole tables as well, so there
is a list of what was created and which write created each one.
Refactor the code accordingly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Move this over to use a writer file, moving the code from the x86
implementation.
There is no need to store a separate variable since we can simply access
the ACPI context.
With this, the original monolithic x86 function for writing ACPI tables
is gone.
Note that QEMU has its own implementation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update this function to the newer style, so we can avoid passing and
returning an address through this function.
Also move this function out of the x86 code so it can be used by other
archs.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Move this table over to use a writer function, moving the code from the
x86 implementation.
Add a pointer to the DSDT in struct acpi_ctx so we can reference it later.
Disable this table for sandbox since we don't actually compile real ASL
code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Move this table over to use a writer function, moving the code from the
x86 implementation.
Add a pointer to the DSDT in struct acpi_ctx so we can reference it later.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the new ACPI writer to write the base tables at the start of the area,
moving this code from the x86 implementation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the new ACPI writer to write the ACPI tables. At present this is all
done in one monolithic function. Future work will split this out.
Unfortunately the QFW write_acpi_tables() function conflicts with the
'writer' version, so disable that for sandbox.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present acpi_setup_base_tables() both sets up the ACPI context and
writes out the base tables.
We want to use an ACPI writer to write the base tables, so split this
function into two, with acpi_setup_ctx() doing the context set, and
acpi_setup_base_tables() just doing the base tables.
Disable the writer's write_acpi_tables() function for now, to avoid
build errors. It is enabled in a following patch.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present we call lots of functions to generate the required ACPI tables.
It would be better to standardise these functions and allow them to be
automatically collected and used when needed.
Add a linker list to handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Rather than keying everything off ACPIGEN, use the main
GENERATE_ACPI_TABLE option to determine whether the core ACPI code
is included. Make sure these option are not enabled in SPL/TPL since we
never generate tables there.
Signed-off-by: Simon Glass <sjg@chromium.org>
Allow this to be used on any arch. Also convert to using macros so that
we can check the CONFIG option in C code.
Signed-off-by: Simon Glass <sjg@chromium.org>
