Repurpose the allocated resources with version V12.00.00 of
k3-resource-partition, matching the update made for the TI J784S4
configuration files. [1]
The Aquila AM69 rm-cfg.yaml and tifs-rm-cfg.yaml remain aligned with
board/ti/j784s4/*-rm-cfg.yaml.
[1] commit c4fcf9b806 ("board: ti: j7*: Update rm-cfg and tifs-rm-cfg")
Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Add the previously missing TIFS RM configuration, generated with
V12.00.00 of k3-resource-partition.
This file is exactly the same as board/ti/am62x/tifs-rm-cfg.yaml.
rm-cfg.yaml and tifs-rm-cfg.yaml need to be in sync, this was already
taken care of by TI. [1]
It was verified that rm-cfg.yaml also remained unchanged with V12.00.00
of the tool.
[1] commit 64ebab10b5 ("toradex: verdin-am62: rm-cfg: Update rm-cfg to reflect new resource reservation")
Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
TI updated rm-cfg for v11.02.09 of the TIFS firmware. [1]
Refresh the tifs-rm-cfg.yaml as well, with version V12.00.00 of
k3-resource-partition, so that it remains in sync with rm-cfg.yaml.
rm-cfg.yaml was also updated with V12.00.00 of the tool and noted to
have no changes.
[1] commit a66704e9a1 ("board: toradex: verdin-am62p: rm-cfg: Update rm-cfg to reflect new resource reservation")
Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.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>
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>
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>
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>
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>
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
Signed-off-by: Lucien.Jheng <lucienzx159@gmail.com>
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.
Link: https://git.kernel.org/linus/66d8a334b57e64e43810623b3d88f0ce9745270b
Signed-off-by: Lucien.Jheng <lucienzx159@gmail.com>
Add a new PHY_COMMON_PROPS library that provides helper functions for
PHY drivers to read standardized polarity properties from the device
tree node:
- phy_get_rx_polarity() / phy_get_tx_polarity()
- phy_get_manual_rx_polarity() / phy_get_manual_tx_polarity()
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
Link: https://git.kernel.org/linus/e7556b59ba65179612bce3fa56bb53d1b4fb20db
Signed-off-by: Lucien.Jheng <lucienzx159@gmail.com>
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>
Use driver data to pass the correct gmii_sel function. This way new
compatibles don't need manual compatible matching as is done in
cpsw_phy_sel().
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>
With NET_LWIP wget produces this output with an overlong line
and missing white space:
=> wget $kernel_addr_r http://example.com/
################################################# 4 GiB540 bytes transferred in 2 ms (263.7 KiB/s)
Bytes transferred = 540 (21c hex)
Removing the condition on inserting a line feed yields:
=> wget $kernel_addr_r http://example.com/
################################################# 4 GiB
540 bytes transferred in 2 ms (263.7 KiB/s)
Bytes transferred = 540 (21c hex)
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
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 fd6e3d3409 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>
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").
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Anshul Dalal <anshuld@ti.com>
There are two reasons why the USB stack needs to be
started before handing to bootflow or other boot
sequences:
1. When a USB hub is present on the board, we need to
do the required sequences to make it usable
2. To make USB storage devices 'visible' to bootflow
without further intervention
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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>
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>
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>
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>
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>
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:
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Link: https://lore.kernel.org/u-boot/35038a9a-fa5a-4f9f-b34e-17cc80a7824c@cherry.de/
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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>
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>
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: 10ff7e6b04 ("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>
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: fd4f7b0158 ("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>
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>
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>
The 'default ... if SYS_L3_SIZE_512KB' statement is written twice, making
the second instance dead code.
Based on the context, I believe the author of the code intended to set a
default value of '1048576' when SYS_L3_SIZE_1024KB is set.
This dead code was detected by kconfirm, a static analysis tool for
Kconfig.
Fixes: b85d75951f ("powerpc: Migrate SYS_L3_SIZE to Kconfig")
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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.
Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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.
Fixes: 065a452ae6 ("power: regulator: tps65941: add regulator support")
Link: https://www.ti.com/lit/ds/symlink/tps6594-q1.pdf
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Takuma Fujiwara <t-fujiwara1@ti.com>
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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
Link: https://lore.kernel.org/r/20260417083050.499955-1-yan.wang@softathome.com
