| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
mvebu_mem_map[] deliberately leaves the ATF and TEE region unmapped:
{
/* RAM 0-64MB */
.phys = 0x0UL,
.size = ATF_REGION_START,
...
},
/* ATF and TEE region 0x4000000-0x5400000 not mapped */
{
/* RAM 66MB-2GB */
.phys = ATF_REGION_END,
...
},
Nothing tells LMB about the hole, so the whole of DRAM bank 0 is added
as available memory (sizes elided from the dumps below for width):
lmb_dump_all:
memory.count = 0x2
memory[0] [0x0-0xbfffffff], flags: none
memory[1] [0x100000000-0x43fffffff], flags: none
reserved.count = 0x4
reserved[0] [0x4000000-0x41fffff], flags: no-map
reserved[1] [0x7eb1d000-0x7eb1ffff], flags: no-notify, no-overwrite
reserved[2] [0x7eb20f40-0xbfffffff], flags: no-overwrite
reserved[3] [0x100000000-0x43fffffff], flags: no-overwrite
The only part of the hole that is reserved is the 2 MiB psci-area from
armada-ap80x.dtsi. The remaining 18 MiB is allocatable, and since
lmb_add() notifies the EFI allocator, it is also published to EFI
payloads as EFI_CONVENTIONAL_MEMORY. Any access to it faults:
=> md 0x4200000 4
"Synchronous Abort" handler, esr 0x96000006, far 0x4200000
Resetting CPU ...
ESR 0x96000006 is a data abort at the current exception level with
DFSC 0x06, a level 2 translation fault - there is no mapping, which is
exactly what mvebu_mem_map[] intends. The same abort with WnR set
(esr 0x96000046) is what MemTest86 v11 for ARM64 hits on its first
write, because the EFI memory map it is handed says:
0x000004000000 - 0x0000041FFFFF (2MB) {Reserved Memory}
0x000004200000 - 0x000006FFFFFF (46MB) {Free Memory}
Add an lmb_arch_add_memory() for Armada 8k that adds each DRAM bank
around the ATF and TEE region instead of over it, and select
LMB_ARCH_MEM_MAP for ARMADA_8K. The hook replaces the generic
lmb_add_memory() rather than extending it, so it also has to reproduce
the LMB_LIMIT_DMA_BELOW_RAM_TOP reservation above gd->ram_top; both are
needed on this SoC, which maps only the first 2 GiB of DRAM.
After the change:
lmb_dump_all:
memory.count = 0x3
memory[0] [0x0-0x3ffffff], flags: none
memory[1] [0x5400000-0xbfffffff], flags: none
memory[2] [0x100000000-0x43fffffff], flags: none
reserved.count = 0x3
reserved[0] [0x7eb1d000-0x7eb1ffff], flags: no-notify, no-overwrite
reserved[1] [0x7eb20f40-0xbfffffff], flags: no-overwrite
reserved[2] [0x100000000-0x43fffffff], flags: no-overwrite
=> md 0x4200000 4
"Synchronous Abort" handler, esr 0x96000006, far 0x4200000
=> md 0x5400000 4
05400000: 00000000 ffffffff 00000000 ffdfffff ................
and MemTest86 completes passes instead of aborting.
Note the psci-area reservation disappears from the dump: the region is
no longer part of the LMB memory map, so boot_fdt_reserve_region() gets
-EINVAL back from lmb_alloc_mem() and skips it. That is harmless - the
memory is not allocatable either way - but it is a visible change in
"bdinfo" output.
board_get_usable_ram_top() already clamps gd->ram_top to the 2 GiB that
mvebu_mem_map[] maps, for the same underlying reason. A ram_top limit
cannot express a hole in the middle of a bank, hence this patch.
Tested on a SolidRun MACCHIATObin (Armada 8040) with 16 GiB of DRAM.
Signed-off-by: Bruno Banelli <bbanelli@gmail.com>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-efi
Pull request efi-2026-10-rc4-2
CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-efi/-/pipelines/1198
Documentation:
* board: ti: am64x: add missing debugging section
* board: ti: correct path to tcl scripts
* regenerate u-boot-stats-v2026.07: Regenerate
UEFI
* Consider type of platform_get_rng_device() return value
* Remove duplicate function declarations
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-fsl-qoriq
CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-fsl-qoriq/-/jobs/84506
- Various config fixes for Layerscape/QorIQ boards
- Fix fsl_dspi by adding missed Layerscape compatible
- Fix ldpaa_eth inverted error logic
- Extend mpq8785 for MPQ8646
|
|
These boards are typically fitted with an Intel PCIe network card.
Since commit cd9b71c3f629 ("layerscape: Disable CONFIG_FMAN_ENET on
*aqds* platforms") which disabled on-chip DPAA networking, we can now
set CONFIG_DM_ETH for the Intel driver.
We also need to enable PCI bus enumeration during init, to actually make
use of the DM_ETH driver.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Vincent Jardin <vjardin@free.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
The 512-byte console input buffer limit for Layerscape SoCs originates
from copy-pasted boilerplate in the original LS2085A board support added
in commit f749db3a75ec ("ARMv8/ls2085a_emu: Add LS2085A emulator and
simulator board support"). No rationale was given for the 512-byte
choice; every subsequent FSL_LSCH2 and FSL_LSCH3 common header
(ls1043a, ls1046a, ls1088a, lx2160a, ...) inherited it by convention.
When CONFIG_SYS_CBSIZE was moved to Kconfig in commit d31466b382dd
("Convert CONFIG_SYS_CBSIZE to Kconfig"), the existing 512-byte values
were transcribed mechanically into Kconfig defaults, cementing the
limit without re-examining its validity.
The practical consequence is that environment variables holding
multi-step boot scripts are silently truncated at 510 usable characters
on all Layerscape boards, making it impossible to store commands such
as combined TFTP+flash sequences in a single variable.
The same problem was already identified and fixed for i.MX6 and i.MX7
in commit f7b237b81e5a ("MLK-24380 imx6: Enlarge the console I/O buffer
to 1024"), whose commit message states: "we have some env variables with
long script string and exceed the 512". FSL_LSCH2 and FSL_LSCH3 were
not included in that fix.
Remove FSL_LSCH2 and FSL_LSCH3 from the 512-byte special case, letting
them fall through to the generic default of 1024. This is consistent
with the i.MX6/MX7 precedent and with the majority of other
architectures. Boards that need a larger buffer can still override
CONFIG_SYS_CBSIZE in their defconfig.
The Layerscape defconfigs carrying the now-stale CONFIG_SYS_PBSIZE=532
override were already cleaned up in commit 82d725c31cbd ("configs:
layerscape: drop CONFIG_SYS_PBSIZE=532 override").
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Vincent Jardin <vjardin@free.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
All Layerscape defconfigs (FSL_LSCH2 and FSL_LSCH3) carry an explicit
CONFIG_SYS_PBSIZE=532, which was set to match the 512-byte SYS_CBSIZE
default that applies to those SoCs (512 + 20 bytes of prompt headroom
= 532).
The Kconfig default for SYS_PBSIZE is 1044, which corresponds to the
generic 1024-byte SYS_CBSIZE default. The per-board override of 532
was only necessary because the FSL_LSCH2/LSCH3 CBSIZE default was
lower than the generic one.
Drop the explicit CONFIG_SYS_PBSIZE=532 from all 40 affected Layerscape
defconfigs in preparation for removing FSL_LSCH2 and FSL_LSCH3 from
the 512-byte SYS_CBSIZE special case. After this commit SYS_PBSIZE
will be 1044 (the Kconfig default), which matches the upcoming 1024-byte
CBSIZE.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Vincent Jardin <vjardin@free.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
The QorIQ Development System (QDS) boards are highly reconfigurable, and
it is desirable to be able to run 'fdt apply' from environment scripts
to apply various DTB overlays.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Vincent Jardin <vjardin@free.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
saveenv fails on the LS2088A-QDS board with:
Flash buffer write timeout at address 580500000 data fffffffffec6fec6
The NOR flash (Spansion S29GL01GT) is connected to the IFC as a 16-bit
device, as reflected by the CSPR_PORT_SIZE_16 setting in the board
configuration. However, CONFIG_SYS_FLASH_CFI_WIDTH is not set, so the
CFI probe loop starts at portwidth=1 (8-bit) and stops as soon as it
finds a valid CFI QRY signature, which it does at portwidth=1 because
the S29GL01GT supports x8 mode and the IFC byte-lane routing makes the
8-bit probe succeed first. As a result, flinfo reports "(8 x 8)" instead
of the correct "(16 x 16)".
With the wrong port width, all flash commands - unlock sequences, buffer
write, write confirm - are issued to incorrect byte addresses. The
AMD/Spansion chip rejects the malformed write command sequence by
toggling DQ6 indefinitely, which the cfi_flash driver reports as a
buffer write timeout.
Commit 53879b17382f ("cfi_flash: Fix detection of 8-bit bus flash
devices via address shift") introduced the address-shift probing logic
that causes the 8-bit probe to match before the correct 16-bit one.
An identical fix to this one was applied to the ls2088ardb platform in
commit ed56fda586fc ("config: ls2088ardb: Add config
CONFIG_SYS_FLASH_CFI_WIDTH"), but it was not realized that it should
apply to ls2088aqds as well.
Set CONFIG_SYS_FLASH_CFI_WIDTH_16BIT to force the CFI probe to start
at the correct 16-bit port width.
Fixes: 53879b17382f ("cfi_flash: Fix detection of 8-bit bus flash devices via address shift")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Vincent Jardin <vjardin@free.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
CONFIG_ENV_RELOC_GD_ENV_ADDR causes gd->env_addr to be adjusted by
the relocation offset at the start of board_r init:
gd->env_addr += gd->reloc_off;
On QDS boards with CONFIG_ENV_IS_IN_FLASH=y the environment driver
(env/flash.c) sets env_addr to CONFIG_ENV_ADDR, a fixed memory-mapped
NOR flash address (0x580500000 on LS2088A-QDS). That address is a
hardware constant and must not be adjusted. Applying the relocation
offset corrupts it to an unmapped address (e.g. 0x5fa1fb004).
The first call to env_get() after relocation passes this corrupted
address to env_get_from_linear(), which then issues an AXI read from
the bogus address. The bus returns a SLVERR, which the CPU core buffers
as an asynchronous SError and delivers on the next function epilogue,
producing:
"Error" handler, esr 0xbf000000
elr: 00000000fbd68068 lr : 00000000fbd68040
...
Resetting CPU ...
ESR 0xbf000000 decodes as EC=0x2F (SError), IDS=1 (implementation-
defined syndrome), consistent with a Cortex-A72 external abort.
Disable the option for the four QDS TFA defconfigs that combine
CONFIG_ENV_RELOC_GD_ENV_ADDR=y with CONFIG_ENV_IS_IN_FLASH=y:
ls1043aqds_tfa, ls1046aqds_tfa, ls1088aqds_tfa, and ls2088aqds_tfa.
The remaining Layerscape defconfigs that carry RELOC_GD_ENV_ADDR use
SPI_FLASH, MMC, or NAND storage, none of which use a memory-mapped
CONFIG_ENV_ADDR, so they are unaffected.
Since commit 123682c7651d ("env: Rename SYS_RELOC_GD_ENV_ADDR to
ENV_RELOC_GD_ENV_ADDR"), the Kconfig option has been renamed, so
splitting the change for each board is slightly pointless (it can't be
backported as one to individual configs).
Fixes: c43a4f827691 ("configs: nxp: Enable CONFIG_SYS_RELOC_GD_ENV_ADDR")
Fixes: effcb1ebe44a ("configs: ls1088a: Enable CONFIG_SYS_RELOC_ENV_ADDR")
Fixes: 5e736c9397e5 ("configs: ls1046aqds: Configure environment related configs")
Fixes: b42f71732320 ("configs: ls1043aqds: Configure environment related configs")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Vincent Jardin <vjardin@free.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
There have been updates to the mapping of company names since the
statistics for v2026.07 were made. While these mapping changes would be
present going back a number of releases, just re-generate the most
recent release statistics for now.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
OpenOCD has reorganised the tcl scripts for TI's reference boards into a
ti/ subdirectory. Update their paths to the new locations.
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
The OpenOCD debugging section is missing for the AM64-EVM. Add it to the
board's documentation page.
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
commit f4bbd7b9faa4 ("efi_loader: Separate device path into its own header")
split some function declarations to their own header file. Remove two
remaining duplicates efi_dp_from_lo() and efi_dp_concat()
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
|
|
The return value of platform_get_rng_device() is efi_status_t.
It does not fit into an integer variable ret. Use variable status.
The RNG device was available when registering the protocol. When it is no
longer available in GetRng(), this is a device error and not an unsupported
algorithm. Use EFI_DEVICE_ERROR returned by platform_get_rng_device() as
return value of GetRng().
Addresses-Coverity-ID: 532068 Overflowed constant
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
All callers already write messages.
* In efi_rng_register we have a log_warning().
* In get_rng() we have an EFI_PRINT() statement.
These different message types are adequate as get_rng() runs inside the API
and efi_rng_register() runs on the U-Boot cli level.
Remove the duplicate debug message in platform_get_rng_device()
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
Bryan Brattlof <bb@ti.com> says:
While updating the check_maintainers_files.sh it was noticed many of the
MAINTAINERS entries in board/ti/ are out of date[0].
So this series aims as trying to update all entries by splitting each
board into their own block, sorting the F: entries, correcting any file
names, and finally adding any missing files I noticed.
[0] https://lore.kernel.org/all/cover.1787555916.git.michal.simek@amd.com/
Link: https://lore.kernel.org/r/20260829-maintainer-fixes-v1-0-e4e03971e14c@ti.com
|
|
There are missing files for TI's J722S-EVM board in its MAINTAINERS
entry. Add the missing files.
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
There are missing files for TI's J721S2 based boards in their
MAINTAINERS entries. Add them.
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
There are some files the J721E-EVM and J721E-SK boards depend on and are
not claimed in the MAINTAINERS file. Add them
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
There are some files the J7200-EVM board depends on not claimed in the
MAINTAINERS file. Add them.
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
There are some files the AM62P-SK board depends on not claimed in the
MAINTAINERS file. Add them.
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
There are some files the AM62D-EVM board depends on not claimed in the
MAINTAINERS file. Add them.
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
There are some files the AM62A-SK board depends on not claimed in the
MAINTAINERS file. Add them.
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
There are some files for the AM62 based boards not claimed in the
MAINTAINERS file. Add them.
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
There are two board variants based upon the J721S2 SoC, The
J721S2XSOMXEVM and SK-AM68. Split their MAINTAINERS entries so we can
better track which files are needed for each board.
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
There are two board variants based upon the J721E SoC, The SK-TDA4VM and
the J721EXSOMXEVM. Split their MAINTAINERS entries so we can better
track which files are needed for each board.
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
There are two boards which TI supports based upon the AM64 SOC, the
SK-AM64B and the TMDS64EVM. Split their MAINTAINERS entries so we can
better track which files are needed for each board.
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
There are three board variants based upon the AM62 SoC, The SK-AM62,
SK-AM62-LP and the SK-AM62-SIP. Split their MAINTAINERS entries so we
can better track which files are needed for each board.
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
To allow for easier upkeep moving forward when new board variants and
board revisions are introduced, correct the names of the boards in the
MAINTAINERS files to match their names on ti.com.
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
To help with identifying missing or incorrect entries in the board
specific MAINTAINERS files, sort them alphabetically.
Signed-off-by: Bryan Brattlof <bb@ti.com>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-imx
CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-imx/-/pipelines/1190
- Fix EEPROM address on Data Modul i.MX8M Plus eDM SBC.
- Increase malloc area size on Data Modul i.MX8M eDM SBC.
- Reload the training firmware for every PHY configuration to avoid boot hang.
|
|
ddr_load_train_firmware() remembers the type of the last loaded firmware
image in a static variable and returns early if the same type is
requested again. That is valid within a single ddr_cfg_phy() call, where
the 1D image is used for several frequency setpoints in a row, but the
state also survives across calls.
Boards that probe several DDR configurations call ddr_init() more than
once. The power up procedure at the beginning of ddr_init() resets the
DDR PHY, which leaves the image in the PHY memory in an undefined state.
The second call then skips the loading, starts the PMU on whatever is
left of it and the training firmware never reports a result. As the PHY
also stops answering on its APB interface at that point, the boot hangs
in a register read, which no software timeout can recover from.
On some specific Kontron SL i.MX8MM with 1GB or 2GB DDR, where the first
init is expected to fail and the second one uses an adjusted
configuration, this made the boot hang every few cycles.
Move the check into ddr_cfg_phy(), the only caller, so that the loading
is still skipped for repeated setpoints of one run, but never across
runs.
Fixes: b614ddb5d335 ("ddr: imx: Save the FW loading if it hasn't changed")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
|
|
The malloc area size may run out during DFU usage for bootloader update
with "dfu_get_buf: Could not memalign 0x800000 bytes" error message.
Increase the malloc area size to prevent this problem.
Signed-off-by: Marek Vasut <marex@nabladev.com>
|
|
The Embedded EEPROM address on Data Modul i.MX8M Plus eDM SBC is 0x51
on all boards starting with revision 902 and newer, update the EEPROM
address to 0x51 to cover all production hardware.
Older board revisions had the EEPROM strapped to address 0x50 but the
EEPROM was not populated on those boards. A subset of rev. 902 boards
also do not have the EEPROM populated. Rev. 903 and newer boards have
the EEPROM populated and strapped to address 0x51. Therefore, setting
the EEPROM address to 0x51 unconditionally does not break any users.
Signed-off-by: Marek Vasut <marex@nabladev.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
|
|
enetc_bind() names each interface by calling enetc_dev_id(), which for
LS1028A is supposed to return PCI_FUNC(pci_get_devfn(dev)) - the PCI
function number of each port, giving "enetc-0", "enetc-1", "enetc-2"
(and "enetc-6", if enabled).
The guard that selects this path is enetc_is_ls1028a(), which checks
pplat->vendor == PCI_VENDOR_ID_FREESCALE. However, pplat->vendor is
not yet populated when enetc_bind() runs. It was thought this extra
check would not introduce a functional change, but it did.
The bind sequence in device_bind() calls uclass_bind_device() first,
which invokes pci_uclass_child_post_bind(). That callback tries to
parse the vendor ID from a "pciVVVV,DDDD"-format compatible string via
ofnode_read_pci_vendev(), but the LS1028A ENETC DT nodes carry
"fsl,enetc", not a PCI compatible - so pplat->vendor stays 0.
The actual PCI config-space read that sets pplat->vendor = 0x1957
happens only after device_bind() returns, when the PCI bus enumerator
processes the scanned BDF. By that point enetc_bind() has already run
and named all three ports "enetc-0".
pci_get_devfn() is not affected by this ordering problem: it reads the
"reg" property of the DT node directly via ofnode_read_pci_addr(), and
is called by the same pci_uclass_child_post_bind() to populate
pplat->devfn before enetc_bind() is invoked.
Remove the enetc_is_ls1028a() guard from enetc_dev_id() and call
pci_get_devfn() unconditionally for the LS1028A path. This is safe
because enetc_dev_id() is only reached from the ofnode_valid() branch
of enetc_bind(), and the iMX95 case is already handled above by
enetc_dev_id_imx() (which also reads the "reg" property directly).
Fixes: 4eb5ef73a956 ("net: fsl_enetc: Introduce enetc_dev_id()")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Add the MPQ8646, which handles the same case as the MPQ8785.
It shares the info table, and it shares the VOUT:
both parts report VID in VOUT_MODE while actually encoding VOUT
as DIRECT with m=64 R=1, which mpq8785_identify_vout() already fixes up.
Linux does the same thing from the other side:
drivers/hwmon/pmbus/mpq8646.c intercepts PMBUS_VOUT_MODE in
read_byte_data() and returns DIRECT when the chip says
VID.
Linux gained the compatible in the shared binding
(Documentation/devicetree/bindings/hwmon/pmbus/mps,mpq8785.yaml,
commit e7ba3115134b "dt-bindings: hwmon: pmbus: add MPS MPQ8646"),
which groups it with mps,mpq8785 for mps,vout-fb-divider-ratio-permille,
the same here.
Verified against silicon on a board whose +0V8_VDD rail is an
MPQ8646: the chip self-reports MODEL="MPQ8646" with VOUT_MODE=0x17.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
ldpaa_eth_bind() returned -EINVAL for a DPMAC node without
phy-connection-type.
That is not "skip this device", it is "the tree is broken":
the DM core propagates it out of lists_bind_fdt() and
dm_scan_fdt(), initr_dm() fails, and U-Boot stops before the prompt with
ldpaa_eth ethernet@1: incorrect phy mode
initcall_run_r(): initcall initr_dm() failed
### ERROR ### Please RESET the board ###
for a MAC nobody asked U-Boot to drive.
Why it matters: device trees imported from Linux enable
every DPMAC and leave the phy description to the board file, because the
kernel's dpaa2 driver does not need one for an MC-managed MAC. U-Boot's
own Layerscape .dtsi instead ships all eighteen disabled for the board to
opt into. So the moment a board takes its SoC description from
dts/upstream, every DPMAC it does not configure in U-Boot is enabled and
unconfigured, and one of them is enough to stop the boot.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Acked-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
The driver matched only fsl,vf610-dspi and fsl,ls1021a-v1.0-dspi. The
Linux device trees under dts/upstream describe the Layerscape
DSPI as "fsl,lx2160a-dspi", "fsl,ls2085a-dspi" instead, without vf610
fallback, so any board built against those trees leaves all three DSPI
controllers unbound.
On LX2160A, dspi0, dspi1 and dspi2 were having
"no driver matches".
There is no code path changes, only the match table.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Commit 9f1807e57cb ("env: add env_set_runtime() helper") broke the use
of "make envtools" to create the target fw_setenv/fw_printenv
binaries. The problem is that the #include <config.h>, in addition to
pulling in linux/kconfig.h to get the IS_ENABLED() helper, also ends
up pulling in lots of architecture/board specific headers.
Fix it by simply using an #ifdef.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Max Merchel <Max.Merchel@ew.tq-group.com>
|
|
This file requires <asm/arch/imx-regs.h> to know what IOMUXC_BASE_ADDR
is, and had been getting this via an indirect include path. Correct
this, so we can fix other bugs which happen to expose this indirect
inclusion.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Anton Ivanov <anton@binarly.io> says:
The data-offset, data-position and data-size FIT properties are 32-bit
unsigned values, but were read through signed int. Also, they are
excluded from the configuration signature, so they are attacker
controlled.
Patch 1 switches the accessors and their callers to u32, removing
the ad-hoc handling of "negative" values in U-Boot proper. This
transition was discussed and agreed on in [1].
The SPL loader has its own copy of this logic with the same problems
and fewer checks. Patch 2 factors out a test helper, patch 3 makes the
SPL offset/size arithmetic overflow-safe, and patch 4 adds the
addressable-range and FIT_SIGNATURE_MAX_SIZE bounds check that U-Boot
proper already performs in fit_image_get_data().
Patches 3 and 4 build on each other and on patch 1, so they are not
intended to be cherry-picked individually.
[1] https://lore.kernel.org/u-boot/CAPWaX55XWFLcMGRuaUuXXn__MX_UG4J8QTd6rvXZmJ4WSOCy9w@mail.gmail.com/
Link: https://lore.kernel.org/r/20260902-b4-fit-ext-data-hardening-v4-0-a884a5de96ea@binarly.io
|
|
fit_image_get_data() checks that the external-data region fits in the
addressable range and, for signed FITs, stays below
FIT_SIGNATURE_MAX_SIZE. The SPL loader had no equivalent check, so a
hostile data-offset or data-size could make the read offset wrap past
ULONG_MAX, or the destination range wrap around the end of the address
space.
Add the same check to load_simple_fit(), using the block-aligned read
size and the source pointer the read actually uses.
Signed-off-by: Anton Ivanov <anton@binarly.io>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The data-offset, data-position and data-size FIT properties are
excluded from the configuration signature, so they are attacker
controlled even when signature verification succeeds. The offset and
size arithmetic in load_simple_fit() can wrap on hostile values:
- adding the external-data base offset to data-offset can wrap past
UINT32_MAX,
- get_aligned_image_size() adds the block-alignment overhead and
rounds up to the block length, which can wrap past ULONG_MAX,
- adding the FIT's device offset to the aligned external-data offset
can wrap past ULONG_MAX.
Make get_aligned_image_size() return the aligned size through an out
parameter and fail with -EOVERFLOW when the computation would wrap,
check the two offset additions explicitly, and compare the
block-aligned size (the amount info->read() actually transfers)
against max_size before reading. Do the same for the FIT header read
in spl_simple_fit_read().
Signed-off-by: Anton Ivanov <anton@binarly.io>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Turn spl_test_fit_external_oversize() into a parameterized helper
which builds a FIT with external data, overwrites one property of the
image node with a hostile value and checks that spl_load_simple_fit()
fails with the expected error.
This is in preparation for adding tests for the remaining
external-data properties.
No functional change.
Signed-off-by: Anton Ivanov <anton@binarly.io>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The data-offset, data-position and data-size FIT properties are
stored as 32-bit unsigned values (fdt32_t), but the accessors
fit_image_get_data_offset(), fit_image_get_data_position() and
fit_image_get_data_size() return them through a signed int.
Switch the accessors and their callers to u32. This removes the
special processing of "negative" values in fit_image_get_data().
Signed-off-by: Anton Ivanov <anton@binarly.io>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Since Linux commit 5b2f8c133d98 ("nvmem: layouts: u-boot-env:
add optional "env-size" property"), there is support for providing the size
of the u-boot environment used by the bootloader to the layout NVMEM driver
in order to calculate the CRC if the range is less than the partition size
in a similar fashion that it would be provided in a fw_env.config file.
Devicetree binary cells are always stored in big-endian,
so endian translation is now necessary for this case.
Reuse the buffer that holds the path for opening the compatible sysfs file
for parsing this env-size property and possibly more in the future,
as soon as the correct device is identified with the compatible property.
Signed-off-by: Michael C. Pratt <mcpratt@pm.me>
|
|
Ever since the transition from a separate NVMEM driver to the layout driver
in Linux commit 5f15811286af ("nvmem: layouts: add U-Boot env layout"),
it is very common within devicetree to have the compatible string "u-boot,env"
in the nested nvmem-layout node instead of the parent partition node.
This allows u-boot tools to detect the u-boot environment on a
partition that is also using the layout driver for NVMEM cells.
Signed-off-by: Michael C. Pratt <mcpratt@pm.me>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-amd
AMD/Xilinx fixes for v2026.10-rc3
AMD/Xilinx:
- MAINTAINERS fragment fixes
fpga:
- Check bitstream length against the supplied buffer
versal2:
- initialize num_banks variable in dram_init()
- move platform_id/platform_version to .data
versal-net:
- move platform_id/platform_version to .data
xilinx-spi:
- fix premature transfer termination at low SCK
|
|
fpga_loadbitstream() receives a size argument describing the length of
the caller's buffer but never uses it. All header offsets are read from
the bitstream, including the 32-bit data length at tag 0x65, which is
passed to fpga_load() unmodified and becomes the DMA transfer length.
A header declaring more data than the caller supplied makes the DMA
read beyond the end of the buffer.
Reject the bitstream if its header and the data it declares do not
fit within size.
Fixes: c26acc1a43b3 ("Remove bit swapping in Xilinx Spartan bitfile loading")
Signed-off-by: Pranav Tilak <pranav.vinaytilak@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/20260827051212.2683473-1-pranav.vinaytilak@amd.com
|
