| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
When using the ACPI tables supplied by QEMU, we don't need to build the
FADT and MADT tables in U-Boot.
This patch avoids a build failure
make qemu-riscv64_smode_defconfig acpi.config
riscv64-linux-gnu-ld.bfd: lib/acpi/acpi_table.o:
in function `acpi_write_fadt':
lib/acpi/acpi_table.c:265:(.text.acpi_write_fadt+0x15c):
undefined reference to `acpi_fill_fadt'
riscv64-linux-gnu-ld.bfd: lib/acpi/acpi_table.o:
in function `acpi_write_madt':
lib/acpi/acpi_table.c:294:(.text.acpi_write_madt+0x52):
undefined reference to `acpi_fill_madt'
Fixes: f5f7962091e4 ("acpi: x86: Write FADT in common code")
Fixes: 4a3fc0f525da ("acpi: x86: Move MADT to common code")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.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>
|
|
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 e1c3c720e780eed6647796d69dca6184640234a5.
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>
|
|
Use XPL_ as the symbol to indicate an SPL build. This means that SPL_ is
no-longer set.
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: d953137526cc ("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>
|
|
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
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>
|
