The first RK35xx SoC was initially appended to the end of the otherwise
alphanumerically sorted spl_infos list, possible because it was using a
new header structure.
Re-sort the spl_infos list to keep it alphanumerically ordered based
on imagename.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Multiple newer Rockchip SoCs report 0x81 instead of 0xa when booting
from USB, i.e. on RK3576, RK3528, RK3506 and RV1106.
Move the bootsource_id 0x81 handling currently only used for RK3528 to
the common read_brom_bootsource_id() to reduce the need to override this
function when support for newer SoCs is introduced.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The rk3288 power-controller node contains an assigned-clocks property
that conflicts with the bindings. From the git history it shows that they
wanted to assign the rk3288 EDP_24M clock input centrally before an edp
node was available. Move the edp assigned-clocks property to the edp node
to reduce dtbs_check output.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://patch.msgid.link/7d6fa223-ab90-4c44-9180-54df78467ea5@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: 10712ce694a67304a99dbba20f8cb146ca5f4fd6 ]
(cherry picked from commit e1b4137b6bbc9998b13cde2eba0655cfdd358c69)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The u-boot,spl-boot-order property requires a label at a boot
device node. In order to migrate to OF_UPSTREAM more easier
add a spi_flash label to the rk3288-veyron.dtsi file.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://patch.msgid.link/8a423a6f-bfdc-4947-aef9-35ee7c4f6ca2@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[ upstream commit: ac7116a626e00d3024adedb43b74bdf2ce45efc2 ]
(cherry picked from commit 38e6f7cd300f66cc9f657cd0e8881a01acc664d0)
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The NanoPi Zero2 is a small single board computer developed by
FriendlyElec, based on the Rockchip RK3528A SoC.
Add support for the FriendlyElec NanoPi Zero2 board.
Features tested on a FriendlyElec NanoPi Zero2 2407:
- SD-card boot
- eMMC boot
- Ethernet
- USB host
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tiger suffers from eMMC signal integrity issues which means we can only
run it at HS200 max.
The Device Tree has these properties removed since v6.18 (commit
baa18d577cd4 ("arm64: dts: rockchip: disable HS400 on RK3588 Tiger")),
which has now merged in U-Boot.
Since the controller side doesn't support HS400 anymore, let's not
confuse users as to why HS400 is enabled in the config but not working
as we know it cannot work (and won't be used anyway since the controller
doesn't advertise support for it in the Device Tree).
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Enable use of DMA when loading FIT images from eMMC, SD-card and SPI
flash now that access to PMU_SRAM for non-secure masters is allowed.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The firewall block access to pmu sram for non-secure masters by default
after reset (0xffffbfff).
Change the pmu lookup configuration to match the default lookup config
for ddr and system sram (0xffff3fff) to allow loading TF-A using DMA.
Mainline TF-A will re-configure the firewall to use an even less
restrictive lookup (0xbffe3ff0), so this change is not expected to have
any real security implication.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: Alexey Charkov <alchark@gmail.com> # UFS
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add Kconfig option OF_SYSTEM_SETUP=y to support booting ROCK 5C Lite
boards with a RK3582 SoC. CPU and GPU cores are failed based on ip-state
and policy.
Tested on a ROCK 5C Lite v1.1:
cpu-code: 35 82
ip-state: 00 80 00 (otp)
ip-state: c0 9e 04 (policy)
remove cpu-map cluster2
fail gpu
fail rkvdec1
fail rkvenc1
fail cpu cpu@600
fail cpu cpu@700
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The a53_0 clock properties are already set correctly in their
common k3-<soc>-r5.dtsi includes. Stop overriding them in
the r5 board device trees.
Fixes the following error message:
Failed to set clock rates for '/a53@0': -61
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Reviewed-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Francesco Dolcini <francesco.dolcini@toradex.com> # Verdin AM62 Solo
Reviewed-by: Bryan Brattlof <bb@ti.com>
Convert a duplicate dtbs recipe into a dependency in the main Makefile.
Another recipe is already defined on line 2369, so we are getting
spurious warnings like:
Makefile:2369: warning: overriding recipe for target 'dtbs'
Makefile:1425: warning: ignoring old recipe for target 'dtbs'
The removed recipe was a no-op anyway so can be safely removed.
Signed-off-by: David Lechner <dlechner@baylibre.com>
The hashed-nodes property in a FIT signature node lists which FDT paths
are included in the signature hash. It is intended as a hint so should
not be used for verification.
Add a function to build the node list from scratch by iterating the
configuration's image references. Skip properties known not to be image
references. For each image, collect the path plus all hash and cipher
subnodes.
Use the new function in fit_config_check_sig() instead of reading
'hashed-nodes'.
Update the test_vboot kernel@ test case: fit_check_sign now catches the
attack at signature-verification time (the @-suffixed node is hashed
instead of the real one, causing a mismatch) rather than at
fit_check_format() time.
Update the docs to cover this. The FIT spec can be updated separately.
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Closes: https://lore.kernel.org/u-boot/20260302220937.3682128-1-trini@konsulko.com/
Reported-by: Apple Security Engineering and Architecture (SEAR)
Tested-by: Tom Rini <trini@konsulko.com>
The PCIe0 instance of PCIe on the J722S SoC uses the 4 GB Address Window
starting from 0x6_0000_0000 to map System Addresses to PCIe Bus Addresses.
Hence, enable CONFIG_SYS_PCI_64BIT.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Fixes: 79f3e77133 ("Subtree merge tag 'v6.16-dts' of dts repo [1] into dts/upstream")
The PCIe1 instance of PCIe on the J7200 SoC uses the 4 GB Address Window
starting from 0x41_0000_0000 to map System Addresses to PCIe Bus Addresses.
Hence, enable CONFIG_SYS_PCI_64BIT.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Fixes: 79f3e77133 ("Subtree merge tag 'v6.16-dts' of dts repo [1] into dts/upstream")
The PCIe0 instance of PCIe on the AM64x SoC uses the 4 GB Address Window
starting from 0x6_0000_0000 to map System Addresses to PCIe Bus Addresses.
Hence, enable CONFIG_SYS_PCI_64BIT.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Fixes: 79f3e77133 ("Subtree merge tag 'v6.16-dts' of dts repo [1] into dts/upstream")
The PCIe Controllers on the J784S4 and AM69 SoCs support Root-Complex
mode of operation. PCIe0 instance of PCIe on both of the SoCs is brought
out on the Starter-Kit (AM69) and EVM (J784S4) boards. Hence, enable
the configs required for Root-Complex mode of operation.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Fixes: 79f3e77133 ("Subtree merge tag 'v6.16-dts' of dts repo [1] into dts/upstream")
The PCIe Controllers on the J784S4 SoC support Root-Complex mode of
operation. Hence, enable it.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Fixes: 79f3e77133 ("Subtree merge tag 'v6.16-dts' of dts repo [1] into dts/upstream")
The PCIe Controllers in the K3 SoCs have 4 GB Address Windows in the
64-bit address space to map System (CPU) Addresses to PCIe Bus Addresses.
The physical addresses for these Address Windows across PCIe instances
across SoCs is as follows:
+--------+----------------+----------------+----------------+----------------+
| SoC | PCIe0 | PCIe1 | PCIe2 | PCIe3 |
+--------+----------------+----------------+----------------+----------------+
| AM64 | 0x6_0000_0000 | NA | NA | NA |
| J722S | 0x6_0000_0000 | NA | NA | NA |
| AM68 | NA | 0x41_0000_0000 | NA | NA |
| J7200 | NA | 0x41_0000_0000 | NA | NA |
| J721S2 | NA | 0x41_0000_0000 | NA | NA |
| J742S2 | 0x40_0000_0000 | 0x41_0000_0000 | NA | NA |
| AM69 | 0x40_0000_0000 | 0x41_0000_0000 | 0x42_0000_0000 | 0x43_0000_0000 |
| J721E | 0x40_0000_0000 | 0x41_0000_0000 | 0x42_0000_0000 | 0x43_0000_0000 |
| J784S4 | 0x40_0000_0000 | 0x41_0000_0000 | 0x42_0000_0000 | 0x43_0000_0000 |
+--------+----------------+----------------+----------------+----------------+
Two regions for a 1:1 mapping from virtual addresses to physical addresses
catering to all of the above will be required, which are:
1. For AM64 and J722S SoCs
=> Start: 0x6_0000_0000 Size: 0x1_0000_0000
2. For AM68, AM69, J7200, J721E, J721S2, J742S2 and J784S4 SoCs
=> Start: 0x40_0000_0000 Size: 0x4_0000_0000
Since the 'Flash Peripherals' region from 0x5_0000_0000 to 0x8_7FFF_FFFF
includes the mapping for AM64 and J722S SoCs, only the second region
mentioned above needs to be added.
Hence, add the region to support 64-bit address space for PCIe.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Fixes: 79f3e77133 ("Subtree merge tag 'v6.16-dts' of dts repo [1] into dts/upstream")
Drivers should extract device-tree data before probing via the
.of_to_plat hook.
Implement it for stm32_dsi driver. By doing so, it also solve a
variable shadowing in stm32_dsi_probe() where &clk was used as
peripheral clock and ref clock.
For readability some struct have been renamed such as:
* struct stm32_dsi_priv *dsi -> struct stm32_dsi_priv *priv
* struct clk clk -> struct clk pclk
Signed-off-by: Raphael Gallais-Pou <rgallaispou@gmail.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Add Kconfig option OF_SYSTEM_SETUP=y to support booting boards with a
RK3582 SoC. CPU and GPU cores are failed based on ip-state and policy.
Tested on a ROCK 5C Lite v1.1:
cpu-code: 35 82
ip-state: 10 00 00 (otp)
ip-state: 30 9e 04 (policy)
remove cpu-map cluster1
rename cpu-map cluster2
fail gpu
fail rkvdec1
fail rkvenc1
fail cpu cpu@400
fail cpu cpu@500
and on a Radxa E52C:
cpu-code: 35 82
ip-state: 00 04 00 (otp)
ip-state: c0 9e 04 (policy)
remove cpu-map cluster2
fail gpu
fail rkvdec1
fail rkvenc1
fail cpu cpu@600
fail cpu cpu@700
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The RK3582 SoC is a variant of the RK3588S with some IP blocks disabled.
What blocks are disabled/non-working is indicated by ip-state in OTP.
This add initial support for RK3582 by using ft_system_setup() to mark
any cpu, gpu and/or vdec/venc node with status=fail as indicated by
ip-state.
This apply same policy as vendor U-Boot for RK3582, i.e. two big cpu
cores, the gpu and one vdec/venc core is always failed/disabled.
Enable Kconfig option OF_SYSTEM_SETUP in board defconfig to make use of
the required DT fixups for RK3582 board variants.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The USB OTG U3 port may have been disabled early, add support to the
COMBPHY driver to re-enable the U3 port.
This matches changes made in the Linux commit 7bb14b61b7d0 ("phy:
rockchip: naneng-combphy: Enable U3 OTG port for RK3568").
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Acked-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
RK3588 has two known memory gaps when using 16+ GiB DRAM,
[0x3fc000000, 0x3fc500000) and [0x3fff00000, 0x400000000).
The vendor TPL blob encodes this information in the DDR_MEM tag data
passed to later boot phases. U-Boot proper will normally use this
information to configure the DRAM banks.
When a DDR_MEM tag cannot be found the fallback is to use the entire
range above 4 GiB. Something that will cause issues when OS try to use
memory from the two known memory gaps.
Add a weak dram init banksize fixup function and implement it for RK3588
to fix issues observed when trying to RAM boot RK3588 boards with 16+
GiB DRAM into Linux.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add a simple unit test for testing the RAUC bootmethod. Provide only the
very basic tests for now, running a scan and list, to verify correct
detection of the RAUC bootmethod. More advanced boot tests of this
bootmethod can be added in a separate patch.
This requires another mmc image (mmc10) to contain the following
partitions:
1. boot A: contains a dummy boot.scr
2. root A: contains an empty root filesystem
3. boot B: contains a dummy boot.scr
4. root B: contains an empty root filesystem
The bootmeth_rauc scans all four partitions for existence and expects a
boot script in each boot partition.
Also add BOOTMETH_RAUC as a dependency on sandbox so that we can test
this with:
$ ./test/py/test.py -B sandbox --build -k test_ut # build the mmc10.img
$ ./test/py/test.py -B sandbox --build -k bootflow_rauc
Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Reviewed-by: Simon Glass <simon.glass@canonical.com>
[trini: mmc9 is now in use, switch to mmc10]
Signed-off-by: Tom Rini <trini@konsulko.com>
FIT images don't work without having to explicitly specify physical
load addresses. Digging into that it looks like a flaw in
bootm_load_os().
It duplicates images->os for convenience. However, the code handling
"kernel_noload" images then updates the load address in the copy with
the value lmb_alloc_mem() returned. Later there's another call to
lmb_alloc_mem() that uses the old value. This leads to havoc due
to subsequent calls of lmb_alloc_mem() picking too low addresses.
The "fix" is to mark the local variable const to avoid accidental
assignments. This works but IMO the logic is still flawed somehow as
this leads to overlapping lmb reservations. I guess the fixed
reservation should only be done when the noload path wasn't hit.
Without the change:
+ bootm 0x40200000#qemu-arm 0x40200000#qemu-arm 0x40000000
Using 'qemu-arm' configuration
Verifying Hash Integrity ... OK
Trying 'kernel' kernel subimage
Description: Linux kernel
Created: 2026-02-24 14:10:09 UTC
Type: Kernel Image (no loading done)
Compression: gzip compressed
Data Start: 0x402000b8
Data Size: 12227440 Bytes = 11.7 MiB
Hash algo: sha256
Hash value: 7ea661fdecdd1127edd419cfbf8bff52e2d5ac55c...
Verifying Hash Integrity ... sha256+ OK
Using 'qemu-arm' configuration
Verifying Hash Integrity ... OK
Trying 'ramdisk' ramdisk subimage
Description: Initial ramdisk
Created: 2026-02-24 14:10:09 UTC
Type: RAMDisk Image
Compression: uncompressed
Data Start: 0x40da9528
Data Size: 1067114 Bytes = 1 MiB
Architecture: AArch64
OS: Linux
Load Address: unavailable
Entry Point: unavailable
Hash algo: sha256
Hash value: 2a711dcb5f58615187645ccec615c67eddcfbb3138...
Verifying Hash Integrity ... sha256+ OK
Booting using the fdt blob at 0x40000000
Working FDT set to 40000000
Uncompressing Kernel Image (no loading done) to 13a400000
Loading Ramdisk to 400fb000, end 401ff86a ... OK
device tree - allocation error
FDT creation failed!
resetting ...
Bloblist at 0 not found (err=-2)
alloc space exhausted ptr 400 limit 0
Bloblist at 0 not found (err=-2)
[reset]
After:
+ bootm 0x40200000#qemu-arm 0x40200000#qemu-arm 0x40000000
Using 'qemu-arm' configuration
Verifying Hash Integrity ... OK
Trying 'kernel' kernel subimage
Description: Linux kernel
Created: 2026-02-24 14:10:09 UTC
Type: Kernel Image (no loading done)
Compression: gzip compressed
Data Start: 0x402000b8
Data Size: 12227440 Bytes = 11.7 MiB
Hash algo: sha256
Hash value: 7ea661fdecdd1127edd419cfbf8bff52e2d5ac55ce...
Verifying Hash Integrity ... sha256+ OK
Using 'qemu-arm' configuration
Verifying Hash Integrity ... OK
Trying 'ramdisk' ramdisk subimage
Description: Initial ramdisk
Created: 2026-02-24 14:10:09 UTC
Type: RAMDisk Image
Compression: uncompressed
Data Start: 0x40da9528
Data Size: 1067114 Bytes = 1 MiB
Architecture: AArch64
OS: Linux
Load Address: unavailable
Entry Point: unavailable
Hash algo: sha256
Hash value: 2a711dcb5f58615187645ccec615c67eddcfbb3138...
Verifying Hash Integrity ... sha256+ OK
Booting using the fdt blob at 0x40000000
Working FDT set to 40000000
Uncompressing Kernel Image (no loading done) to 13a400000
Loading Ramdisk to 13a2fb000, end 13a3ff86a ... OK
Loading Device Tree to 000000013a1f8000, end 000000013a2fafff ... OK
Working FDT set to 13a1f8000
Starting kernel ...
Signed-off-by: Ludwig Nussel <ludwig.nussel@siemens.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Rafał Miłecki <rafal@milecki.pl> says:
I found flash_write_buf() somehow more difficult to follow than needed.
Some code turned out to be inconsistent and some not really needed.
There is a set of 6 patches that should be small enough to make them easy
to review. I was wondering if I should squash patches 5 and 6 but ended up
with sending two smaller diffs.
Those changes shouldn't really change any behaviour (except for smaller mem
alloc). Let me know if there are any issues with this!
Link: https://lore.kernel.org/r/20260221100011.29049-1-zajec5@gmail.com
Recent cleanups made some variables redundant. Both: "blocklen" and
"erase_len" ended up being used as temporary variables used locally in
some short code paths.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Reviewed-by: Tom Rini <trini@konsulko.com>
Calculate "erasesize" in the same place where other offsets and lengths
/ sizes are calculated. It makes code more consistent and will allow
further cleanups.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
In both code paths "blockstart" is calculated the same way. Unify it.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Reviewed-by: Tom Rini <trini@konsulko.com>
We already have DIV_ROUND_UP() to simplify code so add ROUND_UP() as
well. This makes code in flash_write_buf() easier to follow.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
When dealing with env data not aligned to flash blocks flash_write_buf()
has to use an extra buffer. It reads existing flash content to it,
modifies required part and writes it back.
While reading and writing a size stored in "write_total" is used. It's
what should be used when allocating the buffer too.
In some cases allocating memory of "erase_len" size could result in
allocating too big buffer. That wouldn't break anything but it was
making code less intuitive.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Use "erasesize" instead of "blocklen" in flash_write_buf()'s loop. This
change touches code executed for bad NAND blocks so it doesn't affect
any behaviour (for NAND flashes "blocklen" and "erasesize" are equal).
This just makes code a bit more consistent as "erasesize" is what is
used all around inside the writing loop.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
The upstream devicetree am33xx.dtsi does not have a "ti,am33xx-usb"
compatible, it uses "ti,sysc-omap4" for the same node. The
implementation of ti-musb uses a wrapper driver that binds to
ti,am33xx-usb and creates new devices ti-musb-host and
ti-musb-peripheral depending on the dr_mode property.
To avoid this wrapper driver with the upstream devicetree, add
compatibles for "ti,musb-am33xx" to both ti-musb-host and
ti-musb-peripheral. Add a bind function that checks for the correct
dr_mode value and rejects binding if it is not the correct driver.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Signed-off-by: Markus Schneider-Pargmann (TI.com) <msp@baylibre.com>
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
For the upstream DT the ctrl_mod node is using a relative register
address which is not translated by the current code.
Make address parsing understand relative addresses.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Signed-off-by: Markus Schneider-Pargmann (TI.com) <msp@baylibre.com>
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
