usb: dwc3: Fix crash on fastboot exit due to incorrect memory free
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: 884b10e86a05 ("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>
Tom Rini [Mon, 23 Mar 2026 14:38:36 +0000 (08:38 -0600)]
usb: Correct dependencies around USB_EMUL
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>
Tom Rini [Mon, 23 Mar 2026 14:32:02 +0000 (08:32 -0600)]
reset: Correct dependencies for RESET_RZG2L_USBPHY_CTRL
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>
Aristo Chen [Fri, 1 May 2026 05:51:04 +0000 (05:51 +0000)]
test: fit: Use shared make_fname from fit_util
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>
Ludwig Nussel [Mon, 4 May 2026 07:10:23 +0000 (09:10 +0200)]
virtio: fix boot device hunting in qemu with virtio
Commit 70101c3217ae ("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>
boot: image-fit.c: check target, not source, for 8-byte alignment when loading FDT
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: 8fbcc0e0e839 ("boot: Assure FDT is always at 8-byte aligned address") Reviewed-by: Simon Glass <sjg@chromium.org>
Raymond Mao [Wed, 6 May 2026 14:55:33 +0000 (10:55 -0400)]
lib: fdtdec: validate bloblist FDT before consuming libfdt size
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: b70cbbfbf94f ("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>
Brad Klingerman [Fri, 1 May 2026 14:38:50 +0000 (09:38 -0500)]
Makefile: remove block from conv=block, sync in SPL alignment dd
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 '@'.
* initialize variables in efi_dp_from_http()
* cmd: eficonfig: adjust struct eficonfig_entry, field key
* efi_dt_fixup: use fdtdec_get_bool() for reading boolean no-map property
* efi_selftest_memory: check for duplicates first
* simplify efi_mem_sort() using list_for_each_entry_safe
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
Shiji Yang [Sun, 12 Apr 2026 12:12:25 +0000 (20:12 +0800)]
mips: mtmips: align MT7621 image blobs to 8-byte boundary
MT7621 doesn't boot on u-boot v2026.04. Fix it by correcting the
u-boot aligned offset.
Fixes: d9e183a04c92 ("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>
Christian DREHER [Tue, 28 Apr 2026 18:04:08 +0000 (20:04 +0200)]
net: macb: add gigabit implementation for fixed-link
A fixed gigabit link on a non-gigabit controller is only rejected
during PHY init (even though there is no PHY to init), because, on
device-tree parsing, the controller is not probed, and it is still
unknown whether it is gigabit-capable.
This code was only tested on emulator with a full-duplex RGMII
interface, but is expected to work in GMII or half-duplex as well.
Signed-off-by: Christian DREHER <christian.dreher@nanoxplore.com>
Christian DREHER [Tue, 28 Apr 2026 18:04:07 +0000 (20:04 +0200)]
net: macb: do not set user_io when it does not exist
Cadence Ethernet MAC has a feature named user_io, which provides
some input and some output signals for arbitrary purpose in the SoC.
From the driver code, I understand that, on Atmel SoC, it is used to
drive the PHY mode.
At least on Cadence IP7014 r1p12, this feature is optional, and I am
working on a SoC that does not instantiate it. The presence of this
feature is advertised in DCFG1, this patch merely disables the access
to the user_io register based on this information.
I did not apply this change to the non-gigabit capable versions of
the IP, as I do not have documentation for them, and a new non-gigabit
instance is unlikely to appear. I prefer avoiding regressions on old
systems.
Signed-off-by: Christian DREHER <christian.dreher@nanoxplore.com>
Christian DREHER [Tue, 28 Apr 2026 18:04:06 +0000 (20:04 +0200)]
net: macb: use SA1 for MAC filtering on GEM
The MACB uses specific address registers (SA Top and Bottom) to
filter source or destination MAC addresses.
On the Gigabit Ethernet version, SA1B is @0x88.
On the non-GEM version, SA1B is @0x98.
Before this commit, the code was always writing 0x98. By chance,
on GEM, this is the address of SA3B, allowing the driver to work
anyway.
The motivation for this change is to be able to use the driver on
an instance of the GEM with less than 4 SA registers.
Signed-off-by: Christian DREHER <christian.dreher@nanoxplore.com>
Christian DREHER [Tue, 28 Apr 2026 18:04:05 +0000 (20:04 +0200)]
net: macb: include arch/clk.h only when necessary
It does not exist in my setup (an on-going arm64 SoC), and removing
it does not cause any missing declaration, but some code called when
CONFIG_CLK is missing calls get_macb_pclk_rate, which is only defined
in arch/arm/mach-at91/include/mach/clk.h
Signed-off-by: Christian DREHER <christian.dreher@nanoxplore.com>
test: dm: add PHY common props unit tests and sandbox DT nodes
Add sandbox DM unit tests for the PHY common properties library and the
corresponding device tree test nodes to arch/sandbox/dts/test.dts.
Also enable CONFIG_PHY_COMMON_PROPS in configs/sandbox_defconfig so
the tests are built and run in the sandbox environment.
The test file covers rx/tx polarity lookups for all relevant cases:
- missing property (defaults to PHY_POL_NORMAL)
- single value without names array (applies to all modes)
- count mismatch between values and names arrays (-EINVAL)
- name found by exact match
- name not found with no "default" fallback (-EINVAL)
- name not found with a "default" entry (uses fallback value)
- unsupported polarity value (-EOPNOTSUPP)
Ported from Linux KUnit test:
linux/drivers/phy/phy-common-props-test.c
net: phy: airoha: air_en8811: use standard rx-polarity/tx-polarity properties
Replace the proprietary airoha,pnswap-rx / airoha,pnswap-tx boolean
device tree properties with the standard rx-polarity and tx-polarity
properties defined in phy-common-props.yaml.
Backward compatibility is maintained by reading the legacy boolean
properties first and passing them as the default_pol argument to
phy_get_rx/tx_polarity(). If the standard properties are absent the
legacy values are used transparently, so existing device trees remain
functional without modification.
The dt-bindings/phy/phy.h header with PHY_POL_NORMAL, PHY_POL_INVERT,
and PHY_POL_AUTO constants is provided via dts/upstream/include, which
is already in the build include path.
Ported from Merge tag 'phy-for-7.0':
git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy
Upstream devicetrees use a newer DT binding using cpsw-switch
compatibles. The bindings are a bit different, so two functions are
introduced to capture the differences, cpsw_eth_of_to_plat_switch() and
cpsw_eth_of_to_plat_legacy().
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
If wget_info->silent is set, we should not print anything.
If wget_info->silent we print the received content size.
Printing the value of the Content-Length header is redundant
For chunked transfer no Content-Length header is sent.
The content length is returned as HTTPC_CONTENT_LEN_INVALID by the LwIP
library. In this case we were incorrectly printing '4 GiB'.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
net: nfs: fix buffer overflow in nfs_readlink_reply()
nfs_readlink_reply() validates rlen only against the incoming packet
length (inherited from CVE-2019-14195), but not against the destination
buffer nfs_path_buff[2048]. A malicious NFS server can send a valid
READLINK reply where pathlen + rlen exceeds sizeof(nfs_path_buff),
overflowing the BSS buffer into adjacent memory.
The recent fix in fd6e3d34097f addressed the same overflow class in
net/lwip/nfs.c but left the legacy path in net/nfs-common.c unpatched.
Add bounds checks before both memcpy calls in nfs_readlink_reply():
- relative path branch: reject if pathlen + rlen >= sizeof(nfs_path_buff)
- absolute path branch: reject if rlen >= sizeof(nfs_path_buff)
Fixes: cf3a4f1e86 ("net: nfs: Fix CVE-2019-14195") Cc: stable@vger.kernel.org Signed-off-by: Sebastian Alba Vives <sebasjosue84@gmail.com> Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
net: phy: dp83867: default to 2ns delay if unspecified in device-tree
Since Linux commit c360eb0c3ccb ("dt-bindings: net: ethernet-controller:
Add informative text about RGMII delays"), the interpretation of RGMII
delays has changed. Prior to the commit, the RGMII Variant among "rgmii",
"rgmii-id", "rgmii-rxid" and "rgmii-txid" clearly specified whether it is
the MAC or the PHY that "should" add the delay. However, post that commit,
the RGMII Variant only specifies whether or not there is a delay on the
PCB traces between the MAC and the PHY, leaving it open as to who adds the
delay.
Hence, instead of enforcing the existence of the device-tree properties
"ti,rx-internal-delay" and "ti,tx-internal-delay", default to a delay
of 2ns, while continuing to override this delay with the aforementioned
properties, if they exist in the device-tree.
This is in line with the Linux driver implementation updated by commit 6bf78849371d ("net: phy: dp83867: use 2ns delay if not specified in DTB").
Mathew McBride [Fri, 1 May 2026 01:36:08 +0000 (11:36 +1000)]
arm: dts: remove local copy of Ten64 board DTS
This board has been migrated to the upstream / kernel
device tree version (OF_UPSTREAM), so remove the
old 'local' copies that are no longer required.
However, the -u-boot.dtsi append needs to remain,
because the SoC fsl-ls1088a-u-boot.dtsi is required
for some devices (like PCIe controllers and DPAA2 ethernet)
to properly enumerate under U-Boot.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mathew McBride <matt@traverse.com.au> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Mathew McBride [Fri, 1 May 2026 01:36:07 +0000 (11:36 +1000)]
configs: ten64: switch to OF_UPSTREAM
Two recent additions to the mainline device tree allow us
to switch away from the local U-Boot copy:
* Board/embedded controller (traverse,ten64-controller)
is now in the mainline device tree.
* USB Hub (USB5744) connections were also added to
the mainline device tree but not in U-Boot.
The LS1088A and Ten64 device trees in U-Boot were actually
'synced' to mainline some time ago, so the content
(except for the changes mentioned above) is identical.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mathew McBride <matt@traverse.com.au> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Ten64 board revs A through C have a Microchip USB5744
hub on the board, which must be configured over I2C
at boot time to become usable.
This function has not been part of the mainline
U-Boot for this board until now, as a mainline driver
and device-tree binding is now available for the USB5744.
Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mathew McBride <matt@traverse.com.au> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Mathew McBride [Fri, 1 May 2026 01:36:05 +0000 (11:36 +1000)]
configs: ten64: enable OF_BOARD_FIXUP
We have added board_fix_fdt to remove elements from U-Boot's
internal FDT related to the USB hub, so CONFIG_OF_BOARD_FIXUP
needs to be enabled to utilize it.
Signed-off-by: Mathew McBride <matt@traverse.com.au> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Mathew McBride [Fri, 1 May 2026 01:36:04 +0000 (11:36 +1000)]
board: ten64: remove USB hub references from internal FDT when needed
More recent revisions of the Ten64 board do not have a USB Hub
(USB5744). The references to the USB5744 need to be removed in U-Boot's
internal FDT to avoid the USB5744 setup being invoked on these boards.
Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mathew McBride <matt@traverse.com.au> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Mathew McBride [Fri, 1 May 2026 01:36:03 +0000 (11:36 +1000)]
board: ten64: add fdt fixup to hide usb hub topology
The USB Hub (microchip,usb5744) can enter a dis-/reconnect loop
if a driver tries to re-initialise the hub over I2C.
On the Ten64 board, this process only needs to be run once
per system reset cycle, which is carried out by U-Boot.
As there are distributions shipping with the affected
driver by default, the best solution is to remove
the USB hub topology information from the FDT passed
to the operating system, so the OS won't attempt
to re-initialise the USB hub under any circumstance.
Signed-off-by: Mathew McBride <matt@traverse.com.au> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Mathew McBride [Fri, 1 May 2026 01:36:02 +0000 (11:36 +1000)]
arm: gpio: include integer type definitions for gpio.h
Both consumers and sub-arch specific versions of gpio.h
may reference stdint or other non-C90 type definitions.
Ensure the common ones are available by including linux/types.h
before any other headers.
This issue came to light when the usb onboard hub driver
was enabled for ten64_tfa_defconfig:
In file included from ./arch/arm/include/asm/gpio.h:2,
from common/usb_onboard_hub.c:10:
./arch/arm/include/asm/arch/gpio.h:17:9: error: unknown type name 'ulong'
17 | ulong addr;
./arch/arm/include/asm/arch/gpio.h:18:9: error: unknown type name 'ulong'
18 | ulong size;
./arch/arm/include/asm/arch/gpio.h:19:9: error: unknown type name 'uint'
19 | uint ngpios;
(In this instance, the cited errors actually originate from
arch/arm/include/asm/arch-fsl-layerscape/gpio.h, which is included
by the arm top level asm/gpio.h)
Implemented as per suggestion from Quentin Schulz in Link:
When CONFIG_DM_SPI_FLASH is enabled, sf command will default find
device from DT which requires to use "jedec,spi-nor" compatible
string not obsoleted "spi-flash". So update NXP LS DTS to use
new compatible string
Signed-off-by: Ye Li <ye.li@nxp.com> Acked-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Ye Li [Fri, 17 Apr 2026 14:16:36 +0000 (22:16 +0800)]
arm: dts: layerscape: Fix DT build warning in SPI nodes
There are lots of DT warning in layerscape DTS files like:
node name for SPI buses should be 'spi' and SPI bus unit address
format error.
Update the spi node name and flash node name to avoid build warning
Signed-off-by: Ye Li <ye.li@nxp.com> Acked-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Ye Li [Fri, 17 Apr 2026 14:15:29 +0000 (22:15 +0800)]
arm: dts: fsl-ls1088a: Enable USB nodes
Enable USB nodes in -u-boot.dtsi. After sync dts with kernel, USB
nodes status are set to disabled. So "usb start" does not work on
ls1088ardb and ls1088aqds.
Fixes: 10ff7e6b043b ("arm: dts: fsl-ls1088a: sync usb controller nodes with Linux") Signed-off-by: Ye Li <ye.li@nxp.com> Tested-by: Wei Lu <w.lu@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Ye Li [Fri, 17 Apr 2026 14:15:28 +0000 (22:15 +0800)]
arm: dts: fsl-ls1088a: Enable SD device
Due to update of fsl-ls1088a.dtsi in previous patch, the esdhc
node is disabled, so u-boot can't to probe any eSDHC controller.
Fixes: fd4f7b0158d0 ("arm: dts: fsl-ls1088a: move and sync existing bindings to be under /soc") Signed-off-by: Ye Li <ye.li@nxp.com> Tested-by: Wei Lu <w.lu@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Ye Li [Fri, 17 Apr 2026 14:14:37 +0000 (22:14 +0800)]
arm: dts: fsl-ls1088a: Set dpmac nodes default to disabled
Disable ethernet controller dpmac nodes in fsl-ls1088a.dtsi. Board
dts is responsible to enable them. Otherwise will meet failure from
ldpaa_eth driver on LS1088AQDS board, because only few dpmac
controllers can be enabled on this board.
Signed-off-by: Ye Li <ye.li@nxp.com> Tested-by: Wei Lu <w.lu@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
LS1088AQDS u-boot contains multiple DTB files:
fsl-ls1088a-qds-21-x.dtb and fsl-ls1088a-qds-29-x.dtb.
It does not use default device tree fsl-ls1088a-qds.dtb
However, the nodes updated in fsl-ls1088a-qds-u-boot.dtsi are not
included for fsl-ls1088a-qds-21-x.dts and fsl-ls1088a-qds-29-x.dts,
so fail to get any output from serial.
Signed-off-by: Ye Li <ye.li@nxp.com> Tested-by: Wei Lu <w.lu@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Ye Li [Thu, 16 Apr 2026 13:48:38 +0000 (21:48 +0800)]
arm: layerscape: Check zero size memory bank before lmb_add
In layerspace's lmb_arch_add_memory implementation, all memory bank
are added to lmb, even some is with zero size. This will cause lmb
treating it as overlap with available memory by lmb_addrs_overlap
and merge with available memory. Finally causing available memory
start address changed to 0.
For example, on LX2160, before zero memory bank added to lmb, there
are two available memory regions:
- region 0, start 0x80000000, size 0x7be00000
- region 1, start 0x2080000000, size 0x700000000
After zero size memory bank added, merge to one region:
- region 0, start 0, size 0x2780000000
This wrong new region causes efi_memory_init issue when allocating bounce
buffer because of conflict address (with uboot reserved) is allocated.
Signed-off-by: Ye Li <ye.li@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
mmc: msm_sdhci: Use max-frequency to get clock rate
msm_sdc_clk_init() uses clock-frequency to get the clock rate for SDC
clocks. However, the DT files seem to use max-frequency for the same.
Since msm_sdc_clk_init() doesn't find clock-frequency in the DT, it sets 201500000 as the clock rate and this results in timeout errors on IPQ
platforms.
Additionally, clock-frequency is not DT bindings compliant. Hence, get
clock rate using DT bindings compliant max-frequency.
Peng Fan [Sat, 18 Apr 2026 12:37:35 +0000 (20:37 +0800)]
power: regulator: Correct Kconfig for PFUZE100
Use CONFIG_$(PHASE_)DM_REGULATOR_PFUZE100 as the build condition for
pfuze100 regulator driver.
Add Kconfig option for SPL_DM_REGULATOR_PFUZE100.
To avoid break current platforms, set the Kconfig default value same
as PMIC_PFUZE100.
Peng Fan [Sat, 18 Apr 2026 12:37:34 +0000 (20:37 +0800)]
power: regulator: pfuze100: support non-independent mode
Some BUCKs could work in single/dual phase mode, not in independent
mode. In single/dual phase mode, registers of both regulators,
must be identically set. So configure mode and value for both BUCKs.
CONF registers are not touched, leave them as default OTP settings.
PFUZE100/200 SW3A/B, could work in single/dual phase mode, so introduce
a new macro by adding a pointer to the SW3B descriptor.
Peng Fan [Sat, 18 Apr 2026 12:37:33 +0000 (20:37 +0800)]
power: regulator: pfuze100: support high output voltage mode
Some PFUZE regulators can operate in either low or high output voltage mode,
with different minimum voltages and voltage step sizes selected by a hardware
control bit. However, the current PFUZE100 regulator driver assumes low output
voltage mode only, resulting in incorrect voltage calculation and programming
when high voltage mode is enabled.
Extend the regulator descriptor to describe high output voltage mode by adding
a mask to detect the mode and a dedicated voltage description (min_uV and
step size). Update voltage get/set handling to dynamically select the correct
voltage parameters based on the high voltage mode bit.
Peng Fan [Sat, 18 Apr 2026 12:37:32 +0000 (20:37 +0800)]
power: regulator: pfuze100: Fix min_uV usage
regulator-min-microvolt in device tree is not always match the minimal
voltage in the pmic datasheet, direclty using the min value from device
tree as base may cause wrong voltage settings being written.
Directly use the min_uV from datasheet to avoid wrong settings.
Depending on the phase selection (single or multi), the FPWM bits
configured forces the regulator to operate in PWM mode. In case of
multi-phase selection, the FPWM_MP bits enforce the regulator to also
operate in multi-phase. This fixes correct multi-phase operation.
While at this, correct incorrect macro alignment as well.
Tom Rini [Tue, 5 May 2026 16:37:16 +0000 (10:37 -0600)]
Merge patch series "binman: Fix preload signing with encrypted FIT"
Yan WANG <yan.wang@softathome.com> says:
This series improves the reliability and efficiency of binman preload
header generation and test it against an encrypted FIT image signed with
a preload header.
When a preload header references other entries (e.g. an encrypted FIT)
through the collection etype, the referenced entries may be rebuilt
multiple times during binman processing. This becomes problematic when
the referenced entry produces non-deterministic output, such as FIT
encryption using random IVs or timestamps, since rebuilding the entry
changes the data.
This series ensures that referenced entries are built only once and that
preload signing is performed after all data is collected. It also avoids
unnecessary repacking or repeated signing operations by the preload.
The changes include:
* generate preload header placeholders in ObtainContents() and sign
data only once in ProcessContentsUpdate()
* mark referenced entries as build_done in the collection etype to
avoid rebuilding data
* add a functional test for signing an encrypted FIT with a preload
header
Paul HENRYS [Fri, 17 Apr 2026 08:30:50 +0000 (10:30 +0200)]
tools: binman: Test signing an encrypted FIT with a preload header
Add a test to verify the preload header correctly signs an encrypted
FIT. This test exercises the case where encryption uses random IVs that
would change between mkimage calls.
Signed-off-by: Paul HENRYS <paul.henrys_ext@softathome.com> Reviewed-by: Simon Glass <sjg@chromium.org>
yan wang [Fri, 17 Apr 2026 08:30:49 +0000 (10:30 +0200)]
binman: collection: Set build_done on referenced entries
The collection etype uses phandles in the 'content' property to
reference other entries. Mark each referenced entry with build_done
to avoid rebuilding the same entry data multiple times.
This is important for cases where rebuilding may change the data
content, e.g. due to timestamps or random IVs in encryption.
Refactor GetContentsByPhandle() to return both the entry object and
its data.
Signed-off-by: yan wang <yan.wang@softathome.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Paul HENRYS [Fri, 17 Apr 2026 08:30:48 +0000 (10:30 +0200)]
binman: Generate preload header and sign data only once
To optimize preload generation, generate the header and signatures only
after all data has been collected in ProcessContentsUpdate(). This
avoids signing the data multiple times.
Since header_size is known upfront (from __init__), create a placeholder
in `ObtainContents()` to avoid an extra packing pass when
ProcessContentsUpdate() detects a size change.
This reduces unnecessary repacking and signing operations.
Signed-off-by: Paul HENRYS <paul.henrys_ext@softathome.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Tue, 5 May 2026 16:36:08 +0000 (10:36 -0600)]
Merge patch series "configs: toradex: Enable EFI"
Francesco Dolcini <francesco.dolcini@toradex.com> says:
Enable standard EFI support for all the arm64 Toradex boards, as
required for booting standard aarch64 Linux distribution, following the
ARM recommendations for SystemReady compliance.
The RTC used on these boards is not currently supported by U-Boot,
therefore it is not enabled at the moment.
Enable EFI related options, as suggested for booting standard aarch64
Linux distribution, following the ARM recommendations for SystemReady
compliance [1].
The RTC used on this board is not currently supported by U-Boot,
therefore it is not enabled at the moment.
configs: verdin-imx8mp: Enable EFI related options
Enable EFI related options, as suggested for booting standard aarch64
Linux distribution, following the ARM recommendations for SystemReady
compliance [1].
The RTC used on this board is not currently supported by U-Boot,
therefore it is not enabled at the moment.
configs: verdin-imx8mm: Enable EFI related options
Enable EFI related options, as suggested for booting standard aarch64
Linux distribution, following the ARM recommendations for SystemReady
compliance [1].
The RTC used on this board is not currently supported by U-Boot,
therefore it is not enabled at the moment.
Enable EFI related options, as suggested for booting standard aarch64
Linux distribution, following the ARM recommendations for SystemReady
compliance [1].
The RTC used on this board is not currently supported by U-Boot,
therefore it is not enabled at the moment.
Enable EFI related options, as suggested for booting standard aarch64
Linux distribution, following the ARM recommendations for SystemReady
compliance [1].
The RTC used on this board is not currently supported by U-Boot,
therefore it is not enabled at the moment.
configs: toradex-smarc-imx95: Enable EFI related options
Enable EFI related options, as suggested for booting standard aarch64
Linux distribution, following the ARM recommendations for SystemReady
compliance [1].
The RTC used on this board is not currently supported by U-Boot,
therefore it is not enabled at the moment.
configs: toradex-smarc-imx8mp: Enable EFI related options
Enable EFI related options, as suggested for booting standard aarch64
Linux distribution, following the ARM recommendations for SystemReady
compliance [1].
The RTC used on this board is not currently supported by U-Boot,
therefore it is not enabled at the moment.
Enable standard EFI support, as required for booting standard aarch64
Linux distribution, following the ARM recommendations for SystemReady
compliance [1].
The RTC used on this board is not currently supported by U-Boot,
therefore it is not enabled at the moment.
Enable EFI related options, as suggested for booting standard aarch64
Linux distribution, following the ARM recommendations for SystemReady
compliance [1].
The RTC used on this board is not currently supported by U-Boot,
therefore it is not enabled at the moment.
Enable standard EFI support, as required for booting standard aarch64
Linux distribution, following the ARM recommendations for SystemReady
compliance [1].
The RTC used on this board is not currently supported by U-Boot,
therefore it is not enabled at the moment.
efi_mem_sort: use list_for_each_entry_safe instead
Use list_for_each_entry_safe and comparisons against the current and
next efi_mem_desc. This reduces the computation required for merging
regions, prevents unnecessary additional iterations of the list, and
requires less temporary values.
Check for duplicate memory mappings before reporting any incorrect
attributes. Could be that second allocation has the correct type while
the first doesn't. Knowing there is a duplicate in this scenario is
more helpful than just reporting the first mismatch.
cmd: eficonfig: adjust struct eficonfig_entry, field key
The number EFICONFIG_ENTRY_NUM_MAX - 1 must be printable
to field key of struct eficonfig_entry.
Fixes: 1f0583beeb32 ("eficonfig: set EFICONFIG_ENTRY_NUM_MAX to INT_MAX - 1") Fixes: 23aa0502a4b9 ("eficonfig: increase the number of menu entries")
Addresses-Coverity-ID: 583414 - Out-of-bounds write Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Marek Vasut [Mon, 27 Apr 2026 01:10:15 +0000 (03:10 +0200)]
arm64: renesas: Add Cortex-M33 build option to R-Car Gen5
The R-Car Gen5 SoCs contains Cortex-M33, Cortex-R52 and Cortex-A720AE
cores. Add U-Boot build options for the Cortex-M33 core.
Since the Cortex-M33 core is a 32bit core, select V8M and ARM64 for
RCAR64 accordingly. Select TMU timer on the 32bit core, where it is
used instead of the ARMv8 timer. Adjust TMU timer base address to match
the address map of the Cortex-M33 core. Disable unused OF_BOARD_SETUP
as well as unavailable POSITION_INDEPENDENT configuration options.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Add support of Renesas R-Car Gen5 window watchdog timer. Timeout
configuration is derived from CONFIG_WATCHDOG_TIMEOUT_MSECS, which
is more accurate than the 1-second granularity 'timeout' passed to
.start callback.
Reviewed-by: Stefan Roese <stefan.roese@mailbox.org> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add R-Car Gen5 RSIP controller remoteproc driver capable of starting
the SCP, Cortex-R52 and Cortex-A720 cores in Renesas R-Car R8A78000
X5H SoC. The SCP core is started by releasing the core from reset,
the Cortex-R52 and Cortex-A720 are started using the SCP SCMI call.
The entry point for SCP core is fixed to its STCM, entry points for
Cortex-R52 and Cortex-A720 are set during rproc load.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Mon, 20 Apr 2026 01:22:12 +0000 (03:22 +0200)]
arm: dts: renesas: Remove duplicate AVB pinmux assignment on V3M
Both R-Car V3M Eagle and V3MSK U-Boot DT extras contain AVB pinmux
assignment, which is a leftover from before the same pinmux was part
of upstream DTs. Remove the duplicate AVB pinmux assignment in favor
of the upstream DT content. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Mon, 20 Apr 2026 01:21:10 +0000 (03:21 +0200)]
arm: dts: renesas: Clean up RPC DT nodes
Remove duplicate properties which are present both in arch/arm/dts/
and upstream dts/upstream/src/arm64/renesas/ in favor of those in
upstream DTs. Since those are duplicates, this causes no functional
change. Remove unused num-cs and bank-width DT properties.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
m68k: set proper u-boot image size for initial boot
There is a value of 256K hardcoded as u-boot image size. This
produce bank tty as soon as the image size grows over the limit.
Fix it by using value preset by CONFIG_SYS_MONITOR_LEN.
Some NXP imx hardware ip module as the esdhc controller are exactly the
same in some new ColdFire cpus. For the specific case, mcf5441x needs to
use the existing fsl_esdhc_imx.c driver for the esdhc device.
Create a stub to be able to use NXP "imx" serie drivers as the
fsl_esdhc_imx in the ColdFire architecture.
common: memsize: fix occasionally failing alias probing
probe_ram_size_by_alias() detects whether a probe address still aliases
a lower address by writing through one address and reading through the
other.
On i.MX95 this occasionally reported a false non-alias when the alias
read happened immediately after the write.
A memory barrier alone, mb(), was tested but did not make the failure go
away. This suggests that ordering the CPU accesses is not sufficient for
this probe, likely because the issue is in the path to the memory
controller rather than in the core itself.
Read the written address back before checking the alias address. This
appears to force the write to become observable at the probe address
before using the alias read to decide whether the tested address range
exists.
If the readback does not match the written pattern, restore the saved
value and continue with the next check. This keeps the probe robust for
addresses that do not reliably retain the test pattern.
Fixes: 0977448b45e2 ("common: memsize: add RAM size probe based on alias detection") Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Reviewed-by: Simon Glass <sjg@chromium.org>
projects / thirdparty / u-boot.git / log
