CONFIG_CMD_DNS and CONFIG_CMD_WGET depend on CONFIG_CMD_NET.
CONFIG_CMD_NET depends on CONFIG_NET or CONFIG_NET_LWIP.
We shall only enable CONFIG_EFI_HTTP if there is network support.
We have to select CONFIG_CMD_NET.
Fixes: d7d07a8b508b ("efi_loader: support boot from URI device path") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
- Implement i.MX93 erratum fix on the dwc_eth_qos driver to fix RMII.
- Add support for Emcraft Systems NavQ+.
- Fix the size of IVT + CSF blob tacked on to u-boot.itb.
This patch series aims to add DM support for the AEMIF controller that
can be found in the DaVinci SoCs.
This controller has already a driver used by the Keystone SoCs so I
add my work to it.
As we can now easily import Linux device-trees, I try to stick the
most I can to the Linux bindings of the AEMIF controller. To do so I add
an 'intermediate' driver called 'ti-aemif-cs'. It's in charge of
configuring timings for a given chip select of the AEMIF controller.
The AEMIF's bindings in the Linux tree have a node for the AEMIF
controller and then a node for each AEMIF's chip select. This CS node
doesn't have a compatible property but describes the timing parameters
used by a given chip select.
The U-Boot DM framework expects every node to have a 'compatible'
property. If no 'compatible' is present in a node, its children won't be
parsed by u-boot.
Add DM support to the ti-aemif driver.
Add a new ti-aemif-cs driver to comply with the Linux bindings and the
U-Boot's DM philosophy. This driver handles the timing parameters
of an AEMIF's chip select so move aemif_cs_configure() from ti-aemif.c
to ti-aemif-cs.c.
Tom Rini [Tue, 29 Oct 2024 18:12:09 +0000 (12:12 -0600)]
Merge patch series "Support Aspeed SGPIO controller"
Billy Tsai <billy_tsai@aspeedtech.com> says:
AST2600 SoC has 2 SGPIO master interfaces one with 128 pins another one
with 80 pins, AST2500/AST2400 SoC has 1 SGPIO master interface that
supports up to 80 pins.
Tom Rini [Mon, 28 Oct 2024 16:48:42 +0000 (10:48 -0600)]
test/cmd: Make some "ut dm" tests only available on sandbox
Currently, the "dm" suite in unit tests (ut) is only available on
sandbox. Make sure that all cmd tests that are part of this suite are
only available on sandbox and not attempted to be run on hardware (where
it will fail to be able to be started).
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com>
Ilias Apalodimas [Sat, 26 Oct 2024 08:05:53 +0000 (11:05 +0300)]
disk: Mark static functions in part_efi.c
Mark all the functions that are only defined locally as static and
quiesce W=1 warnings
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
[trini: Add __maybe_unused as it's now seen as unused in some cases] Signed-off-by: Tom Rini <trini@konsulko.com>
Ilias Apalodimas [Wed, 23 Oct 2024 15:26:36 +0000 (18:26 +0300)]
lmb: Remove lmb_alloc_flags()
lmb_alloc_flags() & lmb_alloc_base_flags() are just a wrappers for
_lmb_alloc_base(). Since the only difference is the max address of the
allowed allocation which _lmb_alloc_base() already supports with the
LMB_ALLOC_ANYWHERE flag, remove one of them.
Keep the lmb_alloc_base_flags() which also prints an error on failures
and adjust efi_allocate_pages() to only use one of them.
While at it clean up the duplicate function description from the header
file.
Ilias Apalodimas [Wed, 23 Oct 2024 15:22:01 +0000 (18:22 +0300)]
lmb: Simplify lmb_should_notify usage
We never call lmb_map_update_notify() without checking the result of
lmb_should_notify(). Instead of running that function everytime fold it
in there and add the additional flags parameter
Ilias Apalodimas [Wed, 23 Oct 2024 15:22:00 +0000 (18:22 +0300)]
lmb: Fix lmb_add_region_flags() return codes and testing
The function description says this should return 0 or -1 on failures.
When regions coalesce though this returns the number of coalescedregions
which is confusing and requires special handling of the return code.
On top of that no one is using the number of coalesced regions.
So let's just return 0 on success and adjust our selftests accordingly
Jonas Jelonek [Tue, 22 Oct 2024 16:31:18 +0000 (10:31 -0600)]
cpu_func.h: provide noncached_set_region prototype to fix build
Due to the removal of weak functions in 7d6cee2cd0 ("cmd: cache: Remove
weak function"), U-Boot fails to compile after updating to v2024.10 for
mediatek target in OpenWrt with GCC-14 with error:
cmd/cache.c: In function 'do_dcache':
cmd/cache.c:57:25: error: implicit declaration of function
'noncached_set_region' [-Wimplicit-function-declaration]
Thus, provide a prototype in include/cpu_func.h to fix a build
error in cmd/cache.c, since related prototypes are also located there.
The issue occurred after the update of uboot-mediatek in OpenWrt to
v2024.10, in combination with GCC-14 toolchain. It was reported and
discussed in https://github.com/openwrt/openwrt/issues/16697, and
temporarily fixed with
https://github.com/openwrt/openwrt/commit/92ca322dd1f48158b8829fec59319a12e4ae4295.
Tom Rini [Tue, 22 Oct 2024 16:31:17 +0000 (10:31 -0600)]
CONFIG_SYS_NONCACHED_MEMORY: Move prototypes to include/cpu_func.h for consistency
Currently, a number of generic cache related functions have their common
prototype declared in include/cpu_func.h. Move the current set of
noncached functions there as well to match.
Erik Schumacher [Mon, 28 Oct 2024 15:30:56 +0000 (15:30 +0000)]
net: dwc_eth_qos: Remove obsolete imx8 includes
They were added with commit 0e9d23945ce0 ("net: eqos: implement callbaks
to get interface and set txclk rate") but were not removed with
commit 5fc783b5d9c9 ("net: dwc_eth_qos: move i.MX code out") when i.MX
specific code was moved to a separate file.
Signed-off-by: Erik Schumacher <erik.schumacher@iris-sensing.com>
Erik Schumacher [Mon, 28 Oct 2024 15:30:17 +0000 (15:30 +0000)]
net: dwc_eth_qos_imx: Add platform specific reset for i.MX93
The EQOS on i.MX93 fails to finish the reset procedure in RMII mode.
This is described in errata ERR051683. This patch implements the
provided workaround which sets the PS and FES bits after the SWR is set
by using the eqos_fix_soc_reset function.
Adapted from linux-kernel commit b536f32b5b03 ("net: stmmac: dwmac-imx:
use platform specific reset for imx93 SoCs")
Signed-off-by: Erik Schumacher <erik.schumacher@iris-sensing.com>
Erik Schumacher [Mon, 28 Oct 2024 15:29:42 +0000 (15:29 +0000)]
net: dwc_eth_qos: Add support for platform specific reset
This patch adds support for optional platform specific reset logic in
the dwc_eth_qos driver. This new function 'eqos_fix_soc_reset' is called
after the EQOS_DMA_MODE_SWR is set and before the driver waits for this
bit to clear.
Signed-off-by: Erik Schumacher <erik.schumacher@iris-sensing.com>
Rasmus Villemoes [Thu, 24 Oct 2024 12:27:35 +0000 (14:27 +0200)]
imx: hab: fix size of IVT+CSF blob tacked on to u-boot.itb
Loading flash.bin using uuu fails when flash.bin does not have the
right size.
When flash.bin is loaded from some storage medium (sd card/emmc), SPL
just loads some random garbage bytes from beyond what has been
populated when flash.bin was written, but when loaded via uuu, SPL
hangs waiting for the host to send the expected number of bytes. Which
is (size of FIT image aligned to 0x1000)+CONFIG_CSF_SIZE. The
alignment to 0x1000 is already done and is necessary in all cases
because that's the exact expected location of the 32 byte IVT
header. But the IVT+CSF blob tacked onto the end must be a total of
CONFIG_CSF_SIZE.
This is exactly the same fix as 89f19f45d650, except that this time
around I don't know how to cleanly get CONFIG_CSF_SIZE.
Billy Tsai [Wed, 16 Oct 2024 08:59:53 +0000 (16:59 +0800)]
gpio: Add Aspeed SGPIO driver
The Aspeed SGPIO driver supports the SGPIO controllers found in the
AST2400, AST2500 and AST2600 BMC SoCs. The implementation is a cut-down
copy of the upstream Linux kernel driver, adapted for u-boot.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Sughosh Ganu [Mon, 21 Oct 2024 17:24:33 +0000 (22:54 +0530)]
fdt: lmb: add reserved regions as no-overwrite
The boot_fdt_add_mem_rsv_regions() function reserves the memreserve and
reserved-memory regions. These regions are being set with the LMB_NONE
flag which allows overwriting and re-using the regions. This was fine
earlier when the LMB memory map was local and not enforced
globally. But that is no longer the case. Mark these regions as
LMB_NOOVERWRITE so that they cannot be used.
Sughosh Ganu [Mon, 21 Oct 2024 17:18:20 +0000 (22:48 +0530)]
lmb: add a check to prevent memory overrun
When printing the LMB flags for a memory region, there is a need to
check that the array index that is computed is a sane value. Put a
noisy assert in case this check fails, as that implies something with
the LMB code is not working as expected.
Tom Rini [Tue, 29 Oct 2024 02:54:36 +0000 (20:54 -0600)]
Merge patch series "boards: siemens: iot2050: SM variant, sysinfo support, fixes & cleanups"
Jan Kiszka <jan.kiszka@siemens.com> says:
This adds support for the new IOT2050 SM variant, introduces a sysinfo
driver which also permits SMBIOS support and switches the board to
OF_UPSTREAM. There are some further fixes for the boards included as well.
Not yet included is configuration support for DMA isolation via the PVU as
this depends on not yet merged DT bindings and another overlay.
[trini: This is just the first 10 patches in the series for now]
Baocheng Su [Tue, 22 Oct 2024 06:04:27 +0000 (08:04 +0200)]
board: iot2050: Support new IOT2050-SM variant
Main differences between the new variant and Advanced PG2:
1. Arduino interface is removed. Instead, an new ASIC is added for
communicating with PLC 1200 signal modules.
2. USB 3.0 type A connector is removed, only USB 2.0 type A connector is
available.
3. DP interface is tailored down. Instead, to communicate with the
PLC 1200 signal modules, a USB 3.0 type B connector is added but the
signal is not USB.
4. DDR size is increased to 4 GB.
5. Two sensors are added, one tilt sensor and one light sensor.
Signed-off-by: Baocheng Su <baocheng.su@siemens.com>
[Jan: rebased over OF_UPSTREAM] Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Conor Dooley [Wed, 23 Oct 2024 10:17:54 +0000 (11:17 +0100)]
riscv: dts: mpfs: migrate to OF_UPSTREAM
The U-Boot copy of the mpfs devicetree has, in general, been neglected
somewhat in comparison to the one in Linux. Moving to OF_UPSTREAM to
keep both in sync should serve to eliminate that discrepancy.
Additionally, moving to OF_UPSTREAM will let U-Boot automatically pick
up the devicetree rework that is in progress at [1].
Conor Dooley [Wed, 23 Oct 2024 10:17:52 +0000 (11:17 +0100)]
clk: microchip: mpfs: support new syscon based devicetree configuration
Why get a devicetree description wrong once when you can get it wrong
twice? The original mistake, which the driver supports was failing to
describe the main PLL that the "cfg" and "periph" clocks parented by.
The second mistake was describing the "cfg" and "periph" clocks a
reg region within the clock controller, rather as two registers within
a syscon region that also contains pinctrl, interrupt muxing controls
and other functions.
Make up for lost time and describe these regions as they should have
been originally, preserving support for the existing two configurations
for the sake of existing systems with firmware-provided devicetrees.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Anton Blanchard [Thu, 8 Aug 2024 02:14:17 +0000 (02:14 +0000)]
riscv: resume needs to be a global
If we take an exception before u-boot is relocated, there's a good
chance we will end up in an endless loop of exceptions because resume is
invalid until after relocation.
Signed-off-by: Anton Blanchard <antonb@tenstorrent.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Jan Kiszka [Tue, 22 Oct 2024 06:04:25 +0000 (08:04 +0200)]
arm64: dts: ti: iot2050: Add overlays for M.2 used by firmware
To allow firmware to pick up all DTs from here, move the overlays that
are normally applied during DT fixup to the kernel source as well. Hook
then into the build nevertheless to ensure that regular checks are
performed.
Li Hua Qian [Tue, 22 Oct 2024 06:04:24 +0000 (08:04 +0200)]
arm64: dts: ti: iot2050: Disable lock-step for all iot2050 boards
The PG1 A variant of the iot2050 series has been identified which
partially lacks support for lock-step mode. This implies that all
iot2050 boards can't support this mode. As a result, lock-step mode has
been disabled across all iot2050 boards for consistency and to avoid
potential issues.
Jan Kiszka [Tue, 22 Oct 2024 06:04:23 +0000 (08:04 +0200)]
board: siemens: iot2050: Stop using special spl DT sources
We can simply use the default DT, Basic PG1, because no nodes that are
different between the variants play a role for SPL. Will help with the
migration to OF_UPSTREAM.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Baocheng Su [Tue, 22 Oct 2024 06:04:22 +0000 (08:04 +0200)]
board: siemens: iot2050: Generalize the fdt fixup
The fdt fixup logic actually also applies to other possible variants who
also have device tree overlays. So generalize this part by extracting
it from the m.2 specific function and make it a standalone one.
Since now we only have M.2 variant consuming the overlay, it may not
have immediate effect for other variant, however this makes the future
variant more easier to apply fdt fixups.
Signed-off-by: Baocheng Su <baocheng.su@siemens.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Baocheng Su [Tue, 22 Oct 2024 06:04:20 +0000 (08:04 +0200)]
board: siemens: iot2050: Control pcie power for all variants
The power control pin of pcie interface not only works for M.2 interface
but also for miniPCIE, so promote this logic to all variants to
workaround the module hang issue.
Signed-off-by: Baocheng Su <baocheng.su@siemens.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Tom Rini [Tue, 29 Oct 2024 02:53:34 +0000 (20:53 -0600)]
Revert "acpi_table: Fix coverity defect in acpi_write_spcr"
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.
Patrick Rudolph [Mon, 28 Oct 2024 08:08:35 +0000 (09:08 +0100)]
acpi_table: Fix coverity defect in acpi_write_spcr
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>
Paul Barker [Wed, 23 Oct 2024 10:53:19 +0000 (11:53 +0100)]
mmc: renesas-sdhi: Add compatible string for rzg2l-sdhi
After the recent dts/upstream subtree merge, the sdhi compatible string
used in the device tree for RZ/G2L family SoCs is "renesas,rzg2l-sdhi"
not "renesas,rcar-gen3-sdhi". This broke the ability to access the eMMC
and SD card devices on RZ/G2L boards.
Fix this by adding the new compatible string to the sdhi driver.
Fixes: 136b7b6d2e98 ("Subtree merge tag 'v6.11-dts' of dts repo [1] into dts/upstream") Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Marek Vasut [Sun, 27 Oct 2024 02:04:31 +0000 (03:04 +0100)]
ARM: renesas: Drop old unused power DT headers
Renesas R-Car systems use mainline Linux DTs for U-Boot via OF_UPSTREAM,
which also includes headers from dts/upstream/include/dt-bindings/power .
Remove unused legacy DT header files from include/dt-bindings/power .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Marek Vasut [Sun, 27 Oct 2024 02:04:30 +0000 (03:04 +0100)]
ARM: renesas: Drop old unused clock DT headers
Renesas R-Car systems use mainline Linux DTs for U-Boot via OF_UPSTREAM,
which also includes headers from dts/upstream/include/dt-bindings/clock .
Remove unused legacy DT header files from include/dt-bindings/clock .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Mayuresh Chitale [Fri, 23 Aug 2024 09:41:25 +0000 (09:41 +0000)]
riscv: Add support for defining instructions
Add insn-def.h which is similar to that in linux and contains the macros
to generate any instruction of type 'I' using the assembler's .insn
directive.
Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
E Shattow [Sat, 26 Oct 2024 12:40:15 +0000 (05:40 -0700)]
riscv64: dts: starfive: Mars ethernet0 phy delay values sync with upstream Linux
Milk-V Mars vendor board support package has value 0xa (multiplier=150) for both
rx and tx delay. Upstream Linux has this as 1500 for both rx and tx delay. There
is no documentation for why this should remain 1900 so correct it now. Mars CM
and Mars CM Lite follow the same network phy delay values as Mars in the vendor
board support package.
Fixes: 92db23f7660de5897c8e3b91489b5b5780ffcd16 Signed-off-by: E Shattow <e@freeshell.de> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
This patch series enables full RVVM virtual machine support which was
earlier inconveniently provided as out-of-tree patchset.
This should be cleaner than a separate board config, since both
emulators provide similar feature set. Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Enable framebuffer for better virtual machine integration.
Some guests need EFI FB to work properly. Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
QEMU supports NVMe devices, but U-Boot only tries to boot from Virtio.
This is problematic when explicitly using NVMe, so fix that.
Additionally, RVVM virtual machine is almost fully compatible with QEMU,
except it only implements NVMe drives instead of VirtIO. Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Andrew Goodbody [Fri, 25 Oct 2024 17:07:00 +0000 (18:07 +0100)]
x86: Missed removal of CMD_BOOTEFI_HELLO_COMPILE
The config setting CMD_BOOTEFI_HELLO_COMPILE was removed in favour
of BOOTEFI_HELLO_COMPILE but the usage in this Makefile was not
updated. Fix it.
Fixes: 6fe80876dcc7 ("efi_loader: Rename and move CMD_BOOTEFI_HELLO_COMPILE") Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Andrew Goodbody [Fri, 25 Oct 2024 16:47:32 +0000 (17:47 +0100)]
test: efi_loader: Fix dependency for http test
The config setting CMD_BOOTEFI_HELLO_COMPILE was removed in favour
of BOOTEFI_HELLO_COMPILE but the dependency for
test_efi_helloworld_net_http was not updated and so is now incorrect
preventing the test from ever running. Fix it.
Fixes: 6fe80876dcc7 ("efi_loader: Rename and move CMD_BOOTEFI_HELLO_COMPILE") Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tom Rini [Sun, 27 Oct 2024 23:14:22 +0000 (17:14 -0600)]
Merge patch series "Implement ACPI on aarch64"
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:
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.
Patrick Rudolph [Wed, 23 Oct 2024 13:20:19 +0000 (15:20 +0200)]
configs: Add RPI4 ACPI defconfig
Allows to build the RPi4 with ACPI enabled.
TEST: - Boots on qemu-system-aarch64 -machine raspi4b
- Boots on real hardware with arm_64bit=1 in config.txt
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Cc: Simon Glass <sjg@chromium.org> Cc: Matthias Brugger <mbrugger@suse.com> Cc: Peter Robinson <pbrobinson@gmail.com>
Patrick Rudolph [Wed, 23 Oct 2024 13:20:17 +0000 (15:20 +0200)]
arm: mach-bcm283x: Enable ARMV8_MULTIENTRY
On FDT platforms the APs are brought out of reset using the spin-table
as defined in the DT. On ACPI enabled platforms there's no FDT, thus
enable the ARMV8_MULTIENTRY and BLOBLIST to use the ACPI parking
protocol instead.
TEST: - APs enter Linux when run on qemu-system-aarch64 -machine raspi4b
- APs on real hardware do not enter Linux, but continue spinning in
their ACPI parking protocol spinloop. To be investigated.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Matthias Brugger <mbrugger@suse.com> Cc: Peter Robinson <pbrobinson@gmail.com> Cc: Tom Rini <trini@konsulko.com>
Patrick Rudolph [Wed, 23 Oct 2024 13:20:16 +0000 (15:20 +0200)]
arm: mach-bcm283x: Add ARMV8_MULTIENTRY support
When ACPI is enabled over FDT the APs cannot be brought out of reset
by the OS using the "FDT spin-table" mechanism, as no FDT is provided
to the OS. The APs must be released out of reset in u-boot and then
brought up in an ACPI compliant fashion.
When ARMV8_MULTIENTRY is specified, the APs are released from reset
and will enter U-Boot after it has been relocated as well.
By default ARMV8_MULTIENTRY is not selected, keeping existing behaviour.
TEST: All APs enter U-Boot when run on qemu-system-aarch64 and on
real hardware.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Matthias Brugger <mbrugger@suse.com> Cc: Peter Robinson <pbrobinson@gmail.com> Cc: Tom Rini <trini@konsulko.com>
Patrick Rudolph [Wed, 23 Oct 2024 13:20:14 +0000 (15:20 +0200)]
armv8: cpu: Enable ACPI parking protocol
Update the generic entry point code to support the ACPI parking protocol.
The ACPI parking protocol can be used when PSCI is not available to bring
up secondary CPU cores.
When enabled secondary CPUs will enter U-Boot proper and spin in their own
4KiB reserved memory page, which also acts as mailbox with the OS to
release the CPU.
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>
Patrick Rudolph [Wed, 23 Oct 2024 13:20:13 +0000 (15:20 +0200)]
arm: cpu: Add ACPI parking protocol support
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>
Simon Glass [Wed, 23 Oct 2024 13:20:12 +0000 (15:20 +0200)]
board: raspberrypi: Add ASL files from tianocore
Add the necessary DSDT files copied from tianocore to boot the RPi4.
In addition generate a board specific SSDT to dynamically enable/disable
ACPI devices based on FDT. This is required to support the various variants
and boot options. It also allows to test the code on QEMU 9.0 without
modifications, since it doesn't emulate PCIe yet.
Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Simon Glass <sjg@chromium.org> Cc: Matthias Brugger <mbrugger@suse.com> Cc: Peter Robinson <pbrobinson@gmail.com>
Patrick Rudolph [Wed, 23 Oct 2024 13:20:11 +0000 (15:20 +0200)]
arm: bcm283x: Generate ACPI tables
Generate SoC specific ACPI tables for BCM2711:
- FADT
- PPTT
- GTDT
Board specific tables like DSDT and SSDT are added in a separate patch.
MADT is already properly generated from the FDT.
When ACPI is enabled for a different SoC compliation will fail by
design, indicating the required functions that needs to be implemented.
When ACPI is not enabled the added code does nothing, keeping existing
behaviour.
TEST: Booted on RPi4 with only ACPI enabled, providing no FDT to the OS.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Simon Glass <sjg@chromium.org> Cc: Matthias Brugger <mbrugger@suse.com> Cc: Peter Robinson <pbrobinson@gmail.com> Cc: Tom Rini <trini@konsulko.com>
Simon Glass [Wed, 23 Oct 2024 13:20:10 +0000 (15:20 +0200)]
arm: mach-bcm283x: Bring in some header files from tianocore
These header files presumably duplicate things already in the U-Boot
devicetree. For now, bring them in to get the ASL code and ACPI table
code to compile.
Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Matthias Brugger <mbrugger@suse.com> Cc: Matthias Brugger <mbrugger@suse.com> Cc: Peter Robinson <pbrobinson@gmail.com> Cc: Tom Rini <trini@konsulko.com>
Patrick Rudolph [Wed, 23 Oct 2024 13:20:09 +0000 (15:20 +0200)]
arm: mach-bcm283x: Map the ARM local MMIO as well
Cover the "ARM local MMIO" range as well in the default MMU mapping in
order to allow future code to access the GIC-400 without crashing. For
now the GIC is not touched in u-boot, thus this change is a noop.
See [1](BCM2711 ARM Peripherals) for reference.
TEST: Enabled CONFIG_GICV2 and accessed the GIC in C code without crash.
Patrick Rudolph [Wed, 23 Oct 2024 13:20:08 +0000 (15:20 +0200)]
board: emulation: Add QEMU sbsa support
Add support for Arm sbsa [1] v0.3+ that is supported by QEMU [2].
Unlike other Arm based platforms the machine only provides a minimal
FDT that contains number of CPUs, ammount of memory and machine-version.
The boot firmware has to provide ACPI tables to the OS.
Due to this design a full DTB is added here as well that allows U-Boot's
driver to properly function. The DTB is appended at the end of the U-Boot
image and will be merged with the QEMU provided DTB.
In addition provide documentation how to use, enable binman to fabricate both
ROMs that are required to boot and add ACPI tables to make it full compatible
to the EDK2 reference implementation.
The board was tested using Fedora 40 Aarch64 Workstation. It's able
to boot from USB and AHCI or network.
Tested and found working:
- serial
- PCI
- xHCI
- Bochs display
- AHCI
- network using e1000e
- CPU init
- Booting Fedora 40
1: Server Base System Architecture (SBSA)
2: https://www.qemu.org/docs/master/system/arm/sbsa.html
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Cc: Peter Robinson <pbrobinson@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com>
Patrick Rudolph [Wed, 23 Oct 2024 13:20:06 +0000 (15:20 +0200)]
drivers/arm: Implement acpi_fill_madt
Fill the MADT table in the GIC driver and armv8 CPU driver to
drop SoC specific code. While the GIC only needs devicetree
data, the CPU driver needs additional information stored in
the cpu_plat struct.
While on it update the only board making use of the existing
drivers and writing ACPI MADT in mainboard code.
TEST: Booted on QEMU sbsa-ref using GICV3 driver model generated MADT.
Booted on QEMU raspb4 using GICV2 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>
Support reading the "interrupts" property from the devicetree in case
the "interrupts-extended" property isn't found. As the "interrupts"
property is commonly used, this allows to parse all existing FDT and
makes irq_get_by_index() more useful.
The "interrupts" property doesn't contain a phandle as "interrupts-extended"
does, so implement a new method to locate the interrupt-parent called
irq_get_interrupt_parent().
TEST: Read the interrupts from the GIC node for ACPI MADT generation.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Moritz Fischer <moritzf@google.com>
Patrick Rudolph [Wed, 23 Oct 2024 13:20:04 +0000 (15:20 +0200)]
arm: lib: Add GICV2 driver
Add a generic GICV2 driver that:
- parses the DT and generates the ACPI MADT subtables
- implement of_xlate() and allows irq_get_by_index() to return the
correct interrupt mappings
Map DT interrupts to ARM GIC interrupts as follows:
- Interrupt numbers ID32-ID1019 are used for SPIs
- ID0-ID15 are used for SGIs
- ID16-ID31 are used for PPIs
TEST: Booted on QEMU raspb4 using GICV2 driver model generated MADT.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Simon Glass <sjg@chromium.org>
projects / u-boot.git / log