| Age | Commit message (Collapse) | Author |
|---|
|
- net: ravb: Configure CXR31 and CXR35 on rzg2l
|
|
As in Linux with d78c0ced60 ("net: ravb: Make write access to CXR35 first
before accessing other EMAC register"), configure CXR31 and CXR35 correctly
on rzg2. MII mode does not work correctly unless those registers are
properly configured.
Signed-off-by: Mathieu Othacehe <othacehe@gnu.org>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
The scsi_read function incorrectly decrements the block count twice
when handling large disks that trigger the CONFIG_SYS_64BIT_LBA code
path (reads beyond block 268,435,455). The variable 'blks' was being
decremented both inside the 64-bit LBA block and after the successful
scsi_exec() call, causing incorrect block count tracking and data
abort errors on large capacity disks.
Signed-off-by: Balaji Selvanathan <balaji.selvanathan@oss.qualcomm.com>
Tested-by: Tony Dinh <mibodhi@gmail.com>
|
|
The config is wrongly written, result
in only support socdk board.
Fixes: 92dcb3ad5d98 ("cmd/dma: implement dmareset command")
Signed-off-by: Brian Sune <briansune@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
The GitHub dependabot tool has reported a "medium" priority bug
CVE-2025-68146, with this package. Update to the patched version.
Reported-by: GitHub dependabot
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
The option should be 'net_lwip' and not 'net lwip' (see all usage of it
in the test code base).
Fixes: 2bac578c5aba ("test: allow multiple config options in buildconfigspec")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
|
|
Avoid NULL pointer dereference in case 'env select' is invoked
without parameters, check the arg count and make sure it is at
least 2, otherwise print usage.
The crash is easy to trigger e.g. in sandbox:
$ ./u-boot -Tc "env select"
Fixes: a97d22ebba23 ("cmd: env: add env select command")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tested-by: Vincent Stehlé <vincent.stehle@arm.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
The alt name for tispl binary is "tispl.bin" and not "tispl", this patch
fixes the documentation to the correct alt name.
Fixes: def64b493748 ("doc: board: Add document for DFU boot on am62x SoCs")
Fixes: 3633fdbb6b90 ("ti: add support for AM6254atl SiP")
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
|
|
Pull request net-20251218.
net-lwip:
- Avoid NULL dereference in _set_cacert()
- Fix filename handling in TFTP
|
|
Running `wget cacert builtin` leads to a crash in _set_cacert():
Unhandled exception: Load access fault
Function _set_cacert() dereferences variable wget_info.
We must initialize it before executing the cacert sub-command.
Fixes: d3761a31ef09 ("lwip: split net/lwip/wget.c")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
The code to choose the filename to use does not cope with no name set at
all. Firstly the test for a name in net_boot_file_name tests the pointer
rather than the string it points to. Secondly the cleanup on exit in
this case attempts to free a global variable. Fix both issues.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
|
|
Signed-off-by: Jonathan GUILLOT <jonathan@joggee.fr>
Fixes: ff6ef4b9093f ("doc: man-page for the part command")
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
Remove duplicate '@parent' field documentation in struct mtk_composite.
There is no need to say the same thing twice.
Also fix spelling mistake in the word "parent" while we're at it.
Signed-off-by: David Lechner <dlechner@baylibre.com>
|
|
Currently, the terms of both licenses (GPL 2.0 and BSD-2-Clause) must be
met.
However, before switching to the SPDX license identifier, the license
information in the file begins with:
"libfdt is dual licensed: you can use it either under the terms of
the GPL, or the BSD license, at your option."
Therefore, the missing "OR" between the licenses is added.
Fixes: 3508476 ("libfdt: SPDX-License-Identifier: GPL-2.0+ BSD-2-Clause")
Signed-off-by: Max Merchel <Max.Merchel@ew.tq-group.com>
|
|
https://source.denx.de/u-boot/custodians/u-boot-rockchip
CI: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/28748
Please pull the updates for rockchip platform:
- New Board support: rk3588 Radxa ROCK 5T, ROCK 5B+;
- I2C Fixes;
- RAM boot from maskrom;
|
|
Improve the image header documentation for v1 header:
- specify this applies to all MMC, not only SD cards,
- specify the offset for SPI flashes,
- specify the key used for RC4 encoding,
- specify what "init" refers to, especially since some configs enable
TPL,
- specify what "init_boot_size" refers to, especially since some configs
enable TPL,
- specify the size of a block,
- add documentation for init_size and init_boot_size,
Note that the offset on the storage medium isn't necessarily 32KiB (64
blocks) for MMC or 0 for SPI flashes, it's just the first offset the
BootROM checks. Barebox[1] lists a few options, though those are
applicable to RK35xx which use the v2 header, so not guaranteed they can
be shared. On RK3399, the binary can at least be stored at offset 0 and
32KiB on SPI flashes.
[1] https://git.pengutronix.de/cgit/barebox/tree/arch/arm/mach-rockchip/bbu.c#n19
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
In the last message sent in rockchip_i2c_xfer, the controller is
disabled (see rk_i2c_disable() in rk_i2c_read()/rk_i2c_write()), then
the STOP condition is sent (see rk_i2c_send_stop_bit() in
rockchip_i2c_xfer()) and the controller is disabled once again (see
rk_i2c_disable() right after).
The issue is that re-enabling the controller just to send the STOP
condition doesn't work. When, the controller is disabled, the SCL and
SDA lanes are not driven anymore and thus enter the idle mode where they
are kept high by the external HW pull-up. To send a STOP condition, one
needs to drive the SDA line so that a rising edge happens while SCL is
high. Experimentally (on PX30 and RK3399), when enabling the controller
to send a STOP condition after it's been disabled, the controller only
drives the SDA line to trigger the rising edge for the STOP condition,
leaving SCL undriven (and thus, high). This means, that because SDA is
high before this happens and that we need a rising edge, the controller
drives the SDA line low and then releases it, meaning we trigger a START
condition followed by a STOP condition:
SCL
_________
_____...
__ _____
_____... \/
SDA
^ STOP
^ START
This is illegal in I2C protocol[1]:
5. A START condition immediately followed by a STOP condition (void
message) is an illegal format. Many devices however are designed to
operate properly under this condition.
My guess is that the I2C controller IP knows that it makes only sense to
send a STOP condition after a START condition, meaning the controller is
already driving the SCL line low and neither the device nor controller
drive the SDA line after the last ACK/NACK as there's no need to, then
it needs to drive SDA, release SCL to make it high and then release the
SDA line. However, after it's been disabled, the SCL is already released
so the controller only essentially drives SDA and then releases it.
It happens that this seems to be breaking the SE050 Secure Element after
a few transfers in the middle of a transfer where it starts clock
stretching the bus forever. It may be related to Errata 3.2[2] but the
description of the setup isn't an exact match to the current situation.
It seems to be required to disable the I2C controller between messages
as the Linux kernel states that "The HW is actually not capable of
REPEATED START. But we can get the intended effect by resetting its
internal state and issuing an ordinary START.". Between messages, this
logic seems fine as I get an Sr (repeated START condition) before
starting the next message in the transfer without a STOP condition.
However, we should NOT disable the controller after the last message in
the transfer otherwise we do this illegal START condition followed by
the STOP condition, hence the added check.
[1] https://www.nxp.com/docs/en/user-guide/UM10204.pdf 3.1.10 The target address and R/W bit point 5
[2] https://www.nxp.com/docs/en/errata/SE050_Erratasheet.pdf
Fixes: c9fca5ec8849 ("rockchip: i2c: don't sent stop bit after each message")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
The I2C_CON_LASTACK is kind of a misnomer as setting it means sending a
NACK as last byte acknowledge when the controller is in receive mode. It
should therefore be used only when there's no more data to transfer
after this.
Move the comment in the proper if block.
Sync the comment with the Linux kernel's while at it so it's more
explicit.
Fixes: 5deaa530280f ("rockchip: i2c: fix >32 byte reads")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
I2C_CON_STOP is a flag to be used for the con register, where it is bit
4 to send the STOP condition.
To enable the interrupt the controller sends to tell it's finished
sending the STOP condition, it's the ien register at bit 5.
Let's use the proper offset.
My hunch is that enabling the interrupt is useless as the interrupt
status register is always up-to-date and enabling the interrupt is just
so that the interrupt is available via the GIC. However, U-Boot has no
interrupt support and the logic was working well before this patch. This
is just so people aren't side-tracked when debugging I2C issues on
Rockchip by checking all writes are proper.
Fixes: 3437469985df ("rockchip: Add I2C driver")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Include the FDT for Radxa ROCK 5T in the FIT, in addition to those for
5B and 5B+, and add board selection code to load the 5T FDT when the
DRAM type is LPDDR5 and ADC channel 5 value is close to 1016.
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Include FDTs for both ROCK 5B and 5B+ in the FIT and add board selection
code to load the 5B+ FDT when the DRAM type is LPDDR5 and ADC channel 5
value is close to 4095.
U-Boot 2025.07 (Jul 14 2025 - 21:28:20 +0000)
Model: Radxa ROCK 5B+
SoC: RK3588
DRAM: 8 GiB
Features tested on a ROCK 5B+ v1.2:
- SD-card boot
- eMMC boot
- SPI flash boot
- PCIe/NVMe
- Ethernet
- USB/TCPM
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Add a helper function based on rockchip_sdram_size() that return what
DRAM type is used on current running board.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
The BootROM in Rockchip SoCs will enter maskrom mode when boot firmware
cannot be found in nand/spi/mmc storage.
In maskrom mode the USB OTG port can accept one of two custom commands.
Initially a 0x471 command to load TPL into SRAM. After TPL has been
executed and it has returned back-to-BROM, a 0x472 command to load SPL
into start of DRAM.
Add two binman images that can be used to RAM boot from maskrom mode:
- u-boot-rockchip-usb471.bin that contains TPL to init DRAM.
- u-boot-rockchip-usb472.bin that contains SPL and the normal FIT
payload with i.e. U-Boot proper, TF-A and FDT.
A config fragment rockchip-ramboot.config can be used to enable building
of these two binman images, e.g.:
make generic-rk3588_defconfig rockchip-ramboot.config
These binman images can be used with the proprietary rkbin boot_merger
tool to create a special loader image that can be used with tools such
as rkdeveloptool or rockusb tools to RAM boot from maskrom, e.g.:
Create loader image:
$ ../rkbin/tools/boot_merger ./RK3588MINIALL.ini
Boot from maskrom:
$ rkdeveloptool db u-boot-rockchip-rk3588-loader.bin
or
$ rockusb download-boot u-boot-rockchip-rk3588-loader.bin
Another option that does not require use of proprietary tools is using
open source tools such as rkflashtool or rkusbboot that can load the
binman images directly without any need to first create a special loader
image to RAM boot from maskrom, e.g.:
$ rkflashtool l < u-boot-rockchip-usb471.bin
$ rkflashtool L < u-boot-rockchip-usb472.bin
or
$ rkusbboot u-boot-rockchip-usb471.bin u-boot-rockchip-usb472.bin
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: Arnaud Patard <arnaud.patard@collabora.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Drop SoC specific TEXT_BASE and use a common TEXT_BASE for all SoCs.
Move the common TEXT_BASE to 8 MiB offset from start of DRAM to help
support RAM boot from maskrom introduced in next patch.
RAM boot from maskrom mode will expect the FIT payload to be located at
2 MiB offset from start or DRAM.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: Arnaud Patard <arnaud.patard@collabora.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
When one attempts to build Tiger and Jaguar from the same directory,
because Tiger will set the IOMUX to 2 but Jaguar doesn't reset it,
Jaguar will have IOMUX set to 2 if built after Tiger.
This isn't an issue if in separate directories or building Tiger after
Jaguar because the default if missing from the configuration file is 0.
Let's make it explicit that the iomux is 0 for Jaguar.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
Upstream TF-A has support for RK3588 since v2.12 so let's document how
to use upstream TF-A instead of the prebuilt binary blob from Rockchip
if one wants to do that.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
The instructions are regularly out of date because the generated or
prebuilt binaries are updated and the filename doesn't match our
instructions anymore.
Additionally, since commit 55a95caaef15 ("tools: ddrbin_tool: add
ddrbin_tool.py and update to v1.21 20241211") end of October 2024,
ddrbin_tool doesn't exist anymore and has been replaced by
ddrbin_tool.py python script (which currently isn't an executable) so
let's update these instructions as well.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
|
|
We do not perform a check on the value of getsize in get_fatent to
ensure that it will fit within the allocated buffer. For safety sake,
add a check now and if the value exceeds FATBUFBLOCKS use that value
instead. While not currently actively exploitable, it was in the past so
adding this check is worthwhile.
This addresses CVE-2025-24857 and was originally reported by Harvey
Phillips of Amazon Element55.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request efi-2026-01-rc5
CI: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/28738
Documentation:
* Fix typos in the TI K3 board documentation.
* Describe the TI J742S2.
UEFI:
* Add EFI_PARTITION_INFO_PROTOCOL_GUID translation in the UUID library.
|
|
s/Uenv.txt/uEnv.txt
s/then/than
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
J742S2 SOC is derivative of J784S4, most of build infra of j784s4 is used
to build u-boot for J742S2 EVM board.
Add guide users on how to build for that board.
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
|
|
Add support for translating the EFI_PARTITION_INFO_PROTOCOL_GUID
to a text.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
CVE-2025-47273 describes a path traversal vulnerability.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
The current FDT decoding tests calculate the memory required
for FDT manipulation by directly adding a fixed margin to
fdt_totalsize(gd->fdt_blob). The static analyzer flagged
"gd->fdt_blob->totalsize" as a tainted value being passed
to fdt_open_into().
Ensure the size is validated by checking that the total size
is within a reasonable maximum FDT limit for unit tests.
Signed-off-by: Adriana Nicolae <adriana@arista.com>
|
|
The TI AM43xx HS boards have been using CFG_PRAM to hide the top 64MB
firewalled DRAM memory from U-Boot. However, CFG_PRAM only prevents
U-Boot from relocating into that memory, but it is still open for access
for any other usage.
Therefore, migrate into using CONFIG_SYS_MEM_TOP_HIDE which reduces the
ram size itself ensuring that memory is not visible to U-Boot at all
(either for reloc, or general usage).
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
|
|
The objcopy man-page teaches:
--target=bfdname
Use bfdname as the object format for
both the input and the output file
This implies for --target=efi-app-x86_64 that the input file would have
to be an EFI app.
Objcopy in binutils 2.45 checks this more strictly than previous versions
and refuses to accept an ELF file as input with --target=efi-app-x86_64.
Replace --target by --output-target for building sandbox and x86 EFI
binaries.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
https://source.denx.de/u-boot/custodians/u-boot-stm
CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/28704
_ Add 1 GiB DRAM support for STM32MP13x DHCOR SoM
_ Fix 512 MiB DRAM support for STM32MP13x DHCOR SoM
_ Fix handling OPTEE in middle of the DRAM
_ Add missing debug UART build for STM32MP1 DHSOM
|
|
Commit c37a6684818d ("stm32mp: fix compilation issue with DEBUG_UART")
split the debug UART initialization code into two files, but failed to
update other non-ST boards. This did not lead to noticeable breakage
until debug UART is enabled, which is not the default. Update the
Makefile accordingly to allow debug UART to work.
Fixes: c37a6684818d ("stm32mp: fix compilation issue with DEBUG_UART")
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
|
|
Add DRAM settings for 1 GiB variant of DH STM32MP13xx DHCOR SoM
and support for SoM DRAM coding HW straps decoding and automatic
DRAM configuration selection. Enable CONFIG_BOARD_EARLY_INIT_F on
all STM32MP1 DHSOM, as it is required for the HW straps decoding.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
|
|
Update DRAM chip type and density comment for 512 MiB DRAM settings for
DH STM32MP13xx DHCOR DHSBC to match the chip on the SoM. No functional
change.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
|
|
STM32MP13xx may have OPTEE-OS at 0xdd000000 even on systems with 1 GiB
of DRAM at 0xc0000000, which is not the end of DRAM anymore. This puts
the OPTEE-OS in the middle of DRAM. Currently, the code sets RAM top to
0xdd000000 and prevents the DRAM range past OPTEE at 0xe0000000..0xffffffff
from being set as cacheable and from being usable. The code also sets the
area over OPTEE as invalid region in MMU tables, which is not correct.
Adjust the code such, that it only ever sets RAM top just before OPTEE
in case the OPTEE is really at the end of DRAM, mainly to be backward
compatible. Furthermore, adjust the MMU table configuration such, that
the regions over the OPTEE are simply skipped and not reconfigured, and
the regions between end of OPTEE and RAM top are set as cacheable, if
any actually exist.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
|
|
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
My old mail address, ziyao@disroot.org, has stopped working. Switch to
my new address, me@ziyao.cc, and map it in .mailmap.
Signed-off-by: Yao Zi <me@ziyao.cc>
|
|
With LTO enabled, mini U-Boot was hanging during reloc_fdt().
The initial stack pointer was placed too low, and the FDT memcpy
destination was carved only 4KB above it. This left insufficient
margin, causing the FDT copy to overwrite the live early stack
and corrupt execution before relocation.
To fix this, increase the malloc heap from 8KB to 12KB and raise the
initial stack pointer by 4KB. Together these adjustments increase
the separation between the early stack and the FDT region during
the pre-relocation phase, eliminating the overlap and fixing the
hang on mini builds (QSPI/OSPI).
Signed-off-by: Pranav Tilak <pranav.vinaytilak@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
After talking with Derald, take over the maintainership role for this
platform.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
The GitHub dependabot tool has reported two "high" priority bugs,
CVE-2025-66418 and CVE-2025-66471, with this package. Update to the
patched version.
Reported-by: GitHub dependabot
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Resync all defconfig files using qconfig.py
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Remove the unsupported MMC_HS400 mode and select MMC_HS200 instead to avoid
confusion.
Signed-off-by: Dominik Haller <d.haller@phytec.de>
|
|
While adding CPSW device support to enable Ethernet boot for J722S,
dev-data and clk-data for eMMC was removed by mistake, which leads to eMMC
boot failure. Update the dev-data and clk-data to fix that.
Fixes: a02009f3a816 ("arm: mach-k3: j722s: Update SoC autogenerated data to enable Ethernet boot")
Reported-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: Chintan Vankar <c-vankar@ti.com>
Tested-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
|
