Currently mmu_setup for ARMv8 performs two functions, first it sets up
the page tables based the memory map provided by the board and then it
enables the MMU.
However for some platforms runtime fixes to the generated page tables
are required before the MMU can be enabled, such as K3 family of SoCs.
Therefore this patch moves the enablement of the MMU out of mmu_setup
and to a standalone mmu_enable function to give more granular control to
the platforms.
Note that no functional changes are intended from this patch.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Endpoints should not be disabled on bus reset inside UDC driver,
otherwise a race condition will happen between gadget driver. Gadget
driver will free the requests and disable endpoints in disconnect ops.
Also remove outdated comment about it in usba_ep_disable().
Signed-off-by: Zixun LI <admin@hifiphile.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Fixes: 59310d1ecb ("usb: gadget: introduce 'enabled' flag in struct usb_ep")
Link: https://patch.msgid.link/20260515-udc_ep-v2-1-cd335b4e62e4@hifiphile.com
[mkorpershoek: removed empty newline between Fixes: and sob]
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
The virtio_blk_do_single_req function returns ulong, which normally is
the processed size, but in an error case can be the actual error. Use
the special IS_ERR_VALUE macro to test for error.
Addresses-Coverity-ID: CID 645833 (DEADCODE) & CID 645834 (NO_EFFECT)
Signed-off-by: Christian Pötzsch <christian.poetzsch@kernkonzept.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Apple's M3 SoC is similar to M1 and M2 but uses a different memory map.
The main difference is that RAM starts at 0x100_0000_0000 like on t600x
and t602x (M1 and M2 Pro/Max/Ultra). Otherwise IO blocks have been
rearranged.
U-boot's existing drivers are compatible with the hardware and M3 device
trees will carry "apple,t8103-*" compatible strings. Only
apple-atcphy-reset might need a new compatible due to USB4 / DisplayPort
changes the Linux driver has to deal with.
Signed-off-by: Janne Grunau <j@jannau.net>
Acked-by: Mark Kettenis <kettenis@openbsd.org>
Janne Grunau <j@jannau.net> says:
The Linux device trees for Apple silicon devices cover now most of the
hardware as u-boot's internal device trees for M1 devices. Linux has in
addition device trees M2 and M1 and M2 Pro/Max/Ultra devices which were
never added in u-boot.
The most common use case for u-boot on Apple silicon devices does not
use DTBs from u-boot but passes runtime modified device trees from an
earlier boot loader (m1n1).
This change regresses support for the SPI on M1 and M1 Pro/Max notebooks
as SPI keyboard support is not in upstream Linux. This regression is in
my opinion acceptable due to the limited use of u-boot's DTBs for these
targets.
Link: https://lore.kernel.org/r/20260507-apple-dt-upstream-v2-0-35181f2b0509@jannau.net
The device tree on Apple silicon devices is passed from a previous
bootloader stage. The bootloader fills in dynamic information so
u-boot can not use its own device tree.
As documented in doc/board/apple/m1.rst it is possible to build boot
bundles (bootloader + device tree + gzipped u-boot binary). These are
useful for testing.
Instead of using u-boot's own device trees for M1 (t8103) devices use
upstream device trees from dts/upstream/src/arm64/apple. The u-boot
device trees have not seen updates since 2022. The upstream linux device
trees have feature parity for the M1 devices. In addition linux has
device trees for M1 Pro/Max/Ultra, M2 and M2 Pro/Max/Ultra devices.
Keep t8103-j274 as default device tree to avoid further updates.
Signed-off-by: Janne Grunau <j@jannau.net>
Acked-by: Mark Kettenis <kettenis@openbsd.org>
Remove outdated apple,pinctrl.yaml. The dts/upstream contains the
current version of this binding.
Signed-off-by: Janne Grunau <j@jannau.net>
Acked-by: Mark Kettenis <kettenis@openbsd.org>
These SoCs are supported since 2022/2023 but were never added to the
documentation. The devices very similar to the equivalent M1 devices.
The biggest difference is that the M2 and M2 Pro/Max based laptops no
longer use SPI for the keyboard.
Signed-off-by: Janne Grunau <j@jannau.net>
Acked-by: Mark Kettenis <kettenis@openbsd.org>
The main use case for u-boot on Apple silicon based devices is to
provide an EFI based bootloader for operating systems. This uses a
generic u-boot image with DTBs passed from an earlier boot loader
(m1n1). Use the generic board name "mac" for this purpose.
Signed-off-by: Janne Grunau <j@jannau.net>
I'm one of the co-maintainers of Apple silicon support in the Linux
kernel and have contributed to u-boot's Apple SoC support.
Signed-off-by: Janne Grunau <j@jannau.net>
Acked-by: Mark Kettenis <kettenis@openbsd.org>
The files weren't added to MAINTAINERS but clearly belong to Apple
silicon (M1) support.
Signed-off-by: Janne Grunau <j@jannau.net>
Acked-by: Mark Kettenis <kettenis@openbsd.org>
Add nodes to the binman configuration to create single binaries that
combine tiboot3-am69-*-aquila.bin, tispl.bin and u-boot.img into
firmware-aquila-am69-*.bin, with the proper offsets.
These binaries can be used to flash U-Boot via a single binary of three,
as it is done now.
Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
The Cadence SD6HC (SDHCI spec v4.20+) controller uses a soft PHY whose
DLL delay characteristics vary with PVT (Process, Voltage, Temperature)
and board-level trace routing.
A static delay value programmed via device tree for SD High Speed mode is
insufficient because the optimal sampling point varies per board, SD card,
and operating conditions. Runtime calibration is required.
While the SD Physical Layer Specification does not mandate tuning for
SD HS mode (only for UHS-I SDR50/SDR104), the Cadence SD6HC PHY
requires runtime calibration of its receive data delay line to find a
valid sampling window under constrained clock conditions.
The tuning is triggered from the set_ios_post callback because at that
moment hardware has committed the new bus width, clock frequency, and speed
mode to the controller registers. This ensuring the tuning sequence runs
at the correct SD HS operating conditions.
The tuning is gated by a device tree property "cdns,sd-hs-tuning" so
that only boards requiring runtime calibration opt in. When enabled,
the driver performs a 40-tap DLL sweep using CMD19 to find the largest
consecutive passing window, then programs the midpoint into
PHY_DLL_SLAVE_CTRL_REG.
To enable on a board, add to the MMC node in device tree:
&mmc {
cdns,sd-hs-tuning;
};
Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
Add the workaround proposed for J784S4 errata i2437 (link) for SE
clock-gating turning off too early. Without this, a hardware bug present
in C7120 leads to C7120 CPU hanging.
Link: https://www.ti.com/lit/pdf/sprz536
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Add the workaround proposed for J721S2 errata i2437 (link) for SE
clock-gating turning off too early. Without this, a hardware bug present
in C7120 leads to C7120 CPU hanging.
Link: https://www.ti.com/lit/pdf/sprz530
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Add a helper macro to write and verify a 32-bit value to a memory-mapped
register. This is essential for hardware errata workarounds that require
confirmation that register writes have taken effect before proceeding with
initialization.
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
When encountering a symlink pointing to an absolute path, ubifs_findfile
would return the target of the symlink as the result instead of resolving
any following components in the original path. Fix it by following the
same code path that is used for relative paths except that we set the
next inode to the root if we see a leading slash.
The existing code used memcpy and sprintf to copy the symlink target
into a fixed size stack buffer and was therefore vulnerable to buffer
overflows with a sufficiently long symlink target. Fix it by using a
heap buffer for the temporary path during path resolution.
Signed-off-by: Peter Collingbourne <peter@pcc.me.uk>
Fixes: 9d7952e4c6 ("ubifs: Add support for looking up directory and relative symlinks")
The PKCS#11 signing tests in ftest.py call tools.run('softhsm2-util', ...)
directly (and the equivalent for pkcs11-tool and p11-kit), even though
the test setup has already constructed the corresponding Bintool
instances. As Quentin Schulz observed on v1, the bintool wrapper for
these tools is currently used only as an "is this installed?" probe.
Route the eight remaining call sites in ftest.py through
<bintool>.run_cmd(...), which the Bintool base class already provides.
The change is test-side only; no production binman code calls these
tools.
Suggested-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
The Sphinx-generated bintools.rst currently produces an empty section
for this bintool, since its class docstring is only a single line and
so the body under the heading is blank.
Extend the docstring with a short description of what softhsm2-util
does and how binman uses it, so the generated documentation has useful
content.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
The Sphinx-generated bintools.rst currently produces an empty section
for this bintool, since its class docstring is only a single line and
so the body under the heading is blank.
Extend the docstring with a short description of what pkcs11-tool does
and how binman uses it, so the generated documentation has useful
content.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
The Sphinx-generated bintools.rst currently produces an empty section
for this bintool, since its class docstring is only a single line and
so the body under the heading is blank.
Extend the docstring with a short description of what p11-kit does and
how binman uses it, so the generated documentation has useful content.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
When using a worktree '.git' actually is a file and pygit2
init_repository() does not like that. The intention is not to create
a new git repo anyway so use normal constructor instead of
init_repository().
Signed-off-by: Ludwig Nussel <ludwig.nussel@siemens.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When creating the RSDT and the XSDT table they contain no entries.
The table size therefore must equal the header size.
Without this change a NULL deference has been observed in
acpi_find_table() when running `ut dm` on sandbox64_defconfig
executed via `sudo ./u-boot -D`.
Fixes: 94ba15a3f1 ("x86: Move base tables to a writer function")
Fixes: 7e586f6907 ("acpi: Put table-setup code in its own function")
Fixes: ab5efd576c ("x86: acpi: Adjust order in acpi_table.c")
Fixes: 867bcb63e7 ("x86: Generate a valid ACPI table")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Update dm_test_acpi_ctx_and_base_tables() in test/dm/acpi.c to expect
sizeof(struct acpi_table_header) for the initial table length (instead
of sizeof(*rsdt) / sizeof(*xsdt)), and to compute the checksum over
header->length bytes rather than the full struct size:
Signed-off-by: Simon Glass <sjg@chromium.org>
The dwc3_free_one_event_buffer() function incorrectly called free()
on event buffer structures allocated with devm_kzalloc(). This
caused heap corruption and a synchronous abort when exiting
fastboot mode via "fastboot continue".
Device-managed memory is automatically freed when the device is
removed, so manual deallocation causes the heap allocator to access
corrupted metadata.
Fixes: 884b10e86a ("usb: dwc3: core: fix memory leaks in event buffer cleanup")
Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
Reviewed-by: Marek Vasut <marek.vasut+usb@mailbox.org>
The symbol USB_EMUL is how sandbox has access to USB. It's
implementation however enforces a few other requirements. It must have
SCSI enabled, and in turn that means it must have BLK enabled. Finally,
we should not be using SANDBOX itself as a symbol to decide what to
build or not build here, as SANDBOX is selected for COMPILE_TEST builds
as well and so may not have enabled the sandbox specific USB support.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Marek Vasut <marek.vasut+usb@mailbox.org>
As exposed by "make randconfig", we have an issue with the dependencies
for RESET_RZG2L_USBPHY_CTRL. As this functionally depends on
REGULATOR_RZG2L_USBPHY, express this dependency directly in Kconfig as
well.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The USB_RENESAS_USBHS functionality can only work with DM_USB_GADGET
enabled, so express this dependency in Kconfig.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
test_fit.py declares a local make_fname closure that is byte-identical
to fit_util.make_fname. Drop the local copy and call the shared helper
at all seven call sites so there is one definition to maintain.
No behavioural change. Both implementations return
os.path.join(ubman.config.build_dir, basename).
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit 70101c3217 ("virtio: mmio: Return error codes on probe
failures") returns -ENODEV where it would return 0 before. That path is
apparently hit in qemu and breaks boot device discovery
(virtio_bootdev_hunt() expects only ENOENT). So return -ENOENT in
that path instead.
The remaining two error returns in the function are untouched as I
don't know where they play a role.
Signed-off-by: Ludwig Nussel <ludwig.nussel@siemens.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Kuan-Wei Chiu <visitorckw@gmail.com>
A number of our boards no longer boot with v2026.04, ironically as a
result of the effort to ensure 8-byte alignment of the dtb passed to
the kernel and getting rid of the fdt_high=0xffffffff.
The problem exists when the FIT image does specify a (properly
aligned) load address to use for the fdt. For example, we have
fdt-am335x-boneblack.dtb {
description = "Flattened Device Tree blob";
data = /incbin/(...);
...
load = <0x88000000>;
}
Now, with v2026.04 and depending on just exactly where that data ends
up, in a good case we see
Loading fdt from 0x8a8c6e10 to 0x88000000
Booting using the fdt blob at 0x88000000
Working FDT set to 88000000
Loading Kernel Image to 86008000
WARNING:
The 'fdt_high' environment variable is set to ~0. This is known to cause
boot failures due to placement of DT at non-8-byte-aligned addresses.
This system will likely fail to boot. Unset the 'fdt_high' environment
variable and submit a fix upstream.
Using Device Tree in place at 88000000, end 8801af2f
Working FDT set to 88000000
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
and the board boots (though with that ominous warning). However,
modifying the .its file a little, e.g. just removing the word "blob"
from the description, we end up with
Loading fdt from 0x8a8c6e14 to 0x88000000
Booting using the fdt blob at 0x9df94718
Working FDT set to 9df94718
Loading Kernel Image to 86008000
WARNING:
The 'fdt_high' environment variable is set to ~0. This is known to cause
boot failures due to placement of DT at non-8-byte-aligned addresses.
This system will likely fail to boot. Unset the 'fdt_high' environment
variable and submit a fix upstream.
Failed to reserve memory for fdt at 0x9df94718
FDT creation failed!
resetting ...
Notice how the "Loading fdt from" line still claims to load the fdt to
that 0x88000000 address, but since this "else if" clause looks at the
source address (buf) and comes before the "else if (load != data)"
clause, we end up doing the "allocate another buffer to use as target"
instead of actually copying to 0x88000000, but then the "fdt_high=~0"
logic in boot_relocate_fdt() obviously fails to do an lmb-reservation
of that area, and the boot fails.
When there's no load= property in the fdt node, this should not change
anything. But when there is, it is the alignment of that target which
is relevant, not the alignment of the fdt blob within the FIT
image. With this patch applied, we instead get the expected
Loading fdt from 0x8a8c6e14 to 0x88000000
Booting using the fdt blob at 0x88000000
Working FDT set to 88000000
Loading Kernel Image to 86008000
WARNING:
The 'fdt_high' environment variable is set to ~0. This is known to cause
boot failures due to placement of DT at non-8-byte-aligned addresses.
This system will likely fail to boot. Unset the 'fdt_high' environment
variable and submit a fix upstream.
Using Device Tree in place at 88000000, end 8801af2f
Working FDT set to 88000000
Starting kernel ...
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Fixes: 8fbcc0e0e8 ("boot: Assure FDT is always at 8-byte aligned address")
Reviewed-by: Simon Glass <sjg@chromium.org>
Coverity Scan defects are observed in fdtdec_apply_bloblist_dtos(),
since the live FDT taken from the bloblist is passed to libfdt helpers
which consume header size/offset fields:
- fdt_open_into()
- fdt_pack()
Validate the bloblist FDT with fdt_check_full() before calling
fdt_open_into() and again after applying overlays before calling
fdt_pack(). This makes the libfdt consumers operate on a checked FDT
blob while keeping the existing flow unchanged.
Also normalize libfdt return codes from this path to errno values,
including the overlay callback path through bloblist_apply_blobs().
Fixes: b70cbbfbf9 ("fdtdec: apply DT overlays from bloblist")
Addresses-Coverity-ID: CID 645837: (TAINTED_SCALAR)
Signed-off-by: Raymond Mao <raymond.mao@riscstar.com>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
The line that produces $(SPL_BIN)-align.bin invokes dd with
conv=block,sync but no cbs= operand. The result of dd conv=block
without cbs= is unspecified. GNU coreutils outputs anyway, but
uutils (default in Ubuntu 26.04 LTS) errors out for files with
newlines, including SPL binaries, producing:
dd: conv=block or conv=ubnblock specified without cbs=N
Either the block operand must be removed, or cbs=N must be added.
conv=block is for converting newline-terminated variable-length
records to fixed-length space-padded ones, which is meaningless
for a binary SPL image. The intent of the rule is 4-byte
alignment, which conv=sync alone provides by padding the final
block to bs= bytes with NULs.
During build, u-boot-spl-align.bin errors silently due to '@'.
Reproduced with uutils dd 0.8.0:
$ dd if=/dev/urandom of=/tmp/in bs=1 count=10000
$ dd if=/tmp/in of=/tmp/out conv=block,sync bs=4
dd: conv=block or conv=unblock specified without cbs=N
$ dd if=/tmp/in of=/tmp/out conv=sync bs=4
[succeeds]
Output is byte-identical to GNU dd's output for binary input.
Signed-off-by: Brad Klingerman <bdklingerman@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Pull request net-20260506.
net:
- phy: dp83867: default to 2ns delay if unspecified in device-tree
- nfs: fix buffer overflow in nfs_readlink_reply()
- cpsw: Add cpsw-switch DT binding support
- phy: add common PHY polarity properties support
- phy: adin: add support for the ADIN1200 phy
- macb: support for instances with less features
- phy: mscc: add support for the VSC8572
net-lwip:
- wget: correct diagnostic output
MT7621 doesn't boot on u-boot v2026.04. Fix it by correcting the
u-boot aligned offset.
Fixes: d9e183a04c ("MIPS: Assure end of U-Boot is at 8-byte aligned offset")
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Reviewed-by: Weijie Gao <weijie.gao@mediatek.com>
