Tom Rini [Wed, 11 Jun 2025 19:31:45 +0000 (13:31 -0600)]
Merge patch series "dm: core: use {s,u}32 instead of int for dev_read_{s,u}32_default"
Quentin Schulz <foss+uboot@0leil.net> says:
Out of all the dev_read_*_default functions, only two do not properly
use the type as argument and return type: dev_read_u32_default and
dev_read_s32_default. They both use int instead of u32/s32.
Considering that it's generally not guaranteed that an int is 4 bytes
but also for consistency sake, let's have them use the expected type.
Note that I have not tested this, just stumbled upon that inconsistency
by chance.
Quentin Schulz [Wed, 28 May 2025 13:06:19 +0000 (15:06 +0200)]
dm: core: use s32 instead of int for dev_read_s32_default
dev_read_s32_default is for getting an s32 from a Device Tree property
and allows to take a default value if that property is missing.
Considering it calls ofnode_read_u32_default which takes a u32 and
returns a u32, it should do the same instead of using an int, especially
considering that int size is typically architecture-specific, as opposed
to s32/u32.
s32 and u32 being the same size, dev_read_s32* functions calling
ofnode_read_u32_default shouldn't be an issue (at the type level at
least) as the information will be stored appropriately in 4B regardless
of the sign.
This incidentally matches all other dev_read_*_default functions.
Fixes: a1b17e4f4c82 ("dm: core: Add a function to read into a unsigned int") Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org>
Quentin Schulz [Wed, 28 May 2025 13:06:18 +0000 (15:06 +0200)]
dm: core: use u32 instead of int for dev_read_u32_default
dev_read_u32_default is for getting a u32 from a Device Tree property
and allows to take a default value if that property is missing.
Considering it calls ofnode_read_u32_default which takes a u32 and
returns a u32, it should do the same instead of using an int, especially
considering that int size is typically architecture-specific, as opposed
to u32.
This incidentally matches all other dev_read_*_default functions (except
dev_read_s32_default which will be tackled in the next commit).
Fixes: 47a0fd3bad38 ("dm: core: Implement live tree 'read' functions") Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org>
- Add clock and reset drivers support for STM32MP25
- Add STM32H747-Discovery board support
- Add tamp_nvram driver
- Add SPL support and clock tree init to STM32MP13 RCC driver
- Add STM32MP13xx ram support
- Add support for STM32 Image V2.0 for STM32MP13xx
- Fix SYSRAM size on STM32MP13xx
- Fix DBGMCU macro on STM32MP13xx
- Auto-detect ROM API table on STM32MP15xx
Dario Binacchi [Sat, 7 Jun 2025 09:37:17 +0000 (11:37 +0200)]
board: stm32: add stm32h747-discovery board support
The board includes an STM32H747XI SoC with the following resources:
- 2 Mbytes Flash
- 1 Mbyte SRAM
- LCD-TFT controller
- MIPI-DSI interface
- FD-CAN
- USB 2.0 high-speed/full-speed
- Ethernet MAC
- camera interface
Detailed information can be found at:
https://www.st.com/en/evaluation-tools/stm32h747i-disco.html
The board includes an STM32H747XI SoC with the following resources:
- 2 Mbytes Flash
- 1 Mbyte SRAM
- LCD-TFT controller
- MIPI-DSI interface
- FD-CAN
- USB 2.0 high-speed/full-speed
- Ethernet MAC
- camera interface
Detailed information can be found at:
https://www.st.com/en/evaluation-tools/stm32h747i-disco.html
dt-bindings: clock: stm32h7: rename USART{7,8}_CK to UART{7,8}_CK
As stated in the reference manual RM0433, the STM32H743 MCU has
USART1/2/3/6, UART4/5/7/8, and LPUART1. The patches make all the clock
macros for the serial ports consistent with the documentation.
dt-bindings: arm: stm32: add compatible for stm32h747i-disco board
The board includes an STM32H747XI SoC with the following resources:
- 2 Mbytes Flash
- 1 MByte SRAM
- LCD-TFT controller
- MIPI-DSI interface
- FD-CAN
- USB 2.0 high-speed/full-speed
- Ethernet MAC
- camera interface
Detailed information can be found at:
https://www.st.com/en/evaluation-tools/stm32h747i-disco.html
Marek Vasut [Mon, 12 May 2025 17:09:47 +0000 (19:09 +0200)]
tools: stm32image: Add support for STM32 Image V2.0
Add support for generating STM32 Image V2.0, which is used by STM32MP13xx.
The image header layout is similar to STM32MP15xx STM32 Image V1.0, but is
different enough to justify duplicate functions to generate the v2 image.
This code at least attempts to align the V1 and V2 image handling where
possible.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Marek Vasut [Mon, 12 May 2025 17:09:05 +0000 (19:09 +0200)]
ram: stm32mp1: Add STM32MP13xx support
Add support for configuring DRAM controller on STM32MP13xx SoC.
The DRAM controller is basically identical to the DWC controller
on STM32MP15xx SoC, except the bus width is reduced from 32bit to
16bit and a few registers and bits are therefore not present.
Handle the difference by factoring these parts out. Use IS_ENABLE()
as much as possible to assure code which is not enabled on builds
for a single SoC gets compiled out. Handle the different offset of
RCC_DDRITFCR register and missing DDRC2 clock the same way.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Marek Vasut [Mon, 12 May 2025 17:08:29 +0000 (19:08 +0200)]
clk: stm32mp13: Add SPL support and clock tree init to STM32MP13 RCC driver
Add SPL support and clock tree init to STM32MP13 RCC driver. This
consists of two parts, make SCMI into an optional dependency and
add clock tree initialization. The SCMI dependency is made optional
first by registering the few core clock provided by SCMI clock as
fixed clock, and second by letting the clock core parse out the
clock configuration from SoC registers. The clock initialization
code is derived from STM32MP15xx clock tree initialization code,
which is almost identical, except for the use of new PLL2000 for
PLL1 on STM32MP13xx .
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
Marek Vasut [Mon, 12 May 2025 16:45:14 +0000 (18:45 +0200)]
ARM: stm32: Auto-detect ROM API table on STM32MP15xx
The ROM API table location is passed to the SPL by BootROM in register r0,
make use of this, store the content of r0 and later use it to access the
ROM API table to determine current boot device.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Mon, 12 May 2025 16:44:53 +0000 (18:44 +0200)]
ARM: stm32: Fix DBGMCU macro on STM32MP13xx
The DBGMCU block is available at address 0x50081000 both on STM32MP13xx
and on STM32MP15xx . There is no reason to limit the DBGMCU macro being
set only on STM32MP15xx , remove the ifdeffery.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Mon, 12 May 2025 16:44:04 +0000 (18:44 +0200)]
ARM: stm32: Fix SYSRAM size on STM32MP13xx
The STM32MP13xx has only 128 kiB of SYSRAM starting at address 0x2ffe0000 .
The STM32MP15xx has 256 kiB of SYSRAM starting at address 0x2ffc0000 . Make
sure both SoCs configure ARMV7_SECURE_BASE correctly . Define the SYSRAM
base in stm32.h to be consistent with the STM32MP15xx macro.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
In RCC the ops of the CCF registered CLK device can be called directly,
this patch avoid recursive call of clk_ function done by CCF clock
framework which update the clock information, for example
clk_enable is called 2 times, clkp->enable_count is increased 2 times.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Lukasz Majewski <lukma@denx.de> Cc: Sean Anderson <seanga2@gmail.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Patrick Delaunay [Tue, 27 May 2025 13:27:50 +0000 (15:27 +0200)]
clk: scmi: manage properly the clk identifier with CCF
Each clock identifier needs to be unique when CCF is activated,
and it is not respected today by SCMI clock driver.
This patch supports a unique clk id by using the uclass API
clk_get_id() / dev_clk_dm() and by activating by default
CONFIG_CLK_AUTO_ID with CCF which adds an offset to the SCMI
clock identifiers.
After this patch, the SCMI clock driver can coexist with other
clock provider without conflict, they can share internal identifier
[0..N] defined in their binding and the clock ID = 0
(reserved for dummy clock) is no more used.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Lukasz Majewski <lukma@denx.de> Cc: Sean Anderson <seanga2@gmail.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Patrick Delaunay [Tue, 27 May 2025 13:27:49 +0000 (15:27 +0200)]
clk: fixed_rate: configure clock ID with CONFIG_CLK_AUTO_ID
Update CLK ID to avoid 0 id, used for dummy clock with CCF
and to allow selection by clk_get_by_id, used to
get private data associated to the UCLASS_CLK device
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Lukasz Majewski <lukma@denx.de> Cc: Sean Anderson <seanga2@gmail.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Patrick Delaunay [Tue, 27 May 2025 13:27:46 +0000 (15:27 +0200)]
clk: add CONFIG_CLK_AUTO_ID
Add a new config CONFIG_CLK_AUTO_ID to support a unique clk id
for all the clock providers, managed by clk uclass, when the clock
reference arg[0] is the same.
When the CONFIG is activated, the clock id is limited to the lower
CLK_ID_SZ = 24 bits in default clock xlate function
and the sequence number + 1 of the clk provider device is
added for the 8 higher bits.
We use sequence number + 1 to avoid the "dummy" clock id = 0,
used for invalid clock when CCF is activated.
When this config is activated, the new function clk_get_id()
should be used to get back the internal reference to clock
for the each clock provider.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Lukasz Majewski <lukma@denx.de> Cc: Sean Anderson <seanga2@gmail.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Simon Glass [Sat, 24 May 2025 13:06:37 +0000 (07:06 -0600)]
test: tpm: Skip failing tests on coral
These tests have been failing for some months. Disable them so that a CI
run can pass on coral. Further work will be needed to see how to make
them pass.
* Pattern 'GPL' did not match any files.
* Pattern 'BSD-2-Clause' did not match any files.
* SetuptoolsDeprecationWarning: License classifiers are deprecated.
Since commit 159b6f0e1199 ("caam: Fix CAAM error on startup") the following
regression was reported by Tim Harvey:
"I've found that this patch causes a regression on an imx8mm board
(imx8mm_venice_defconfig) where the first call to caam_rng_read fails
here in jr_dequeue but if you call it again it works. With some
debugging added:
SEC0: RNG instantiated
...
Hit any key to stop autoboot: 0
u-boot=> rng list
RNG #0 - caam-rng
u-boot=> rng 0 10
caam_rng_read caam-rng len=16
run_descriptor_jr_idx idx=0
Error in SEC deq: -1
caam_rng_read_one run_descriptor_jr failed: -1
caam_rng_read caam-rng caam_rng_read_one failed: -5
Reading RNG failed
u-boot=> rng 0 10
caam_rng_read caam-rng len=16
run_descriptor_jr_idx idx=0 00000000: ad 2e ad c0 2a 12 27 c4 65 82 66 19 be ef f6 07 ....*.'.e.f.....
If I revert your patch caam_rng_read works initially and on subsequent
calls."
" I ran into this when I was testing
lwIP HTTPS as it causes anything that uses dm_rng to fail the first
time (such as HTTPS)."
Revert it for now to avoid the regression.
Reported-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Fabio Estevam <festevam@gmail.com> Acked-by: Peng Fan <peng.fan@nxp.com>
Yang Xiwen [Sat, 31 May 2025 13:10:03 +0000 (21:10 +0800)]
arm: qemu: Add imply CONFIG_POSITION_INDEPENDENT
Add 'imply CONFIG_POSITION_INDEPENTDENT' for QEMU arm arch. This allows
qemu arm boards to load u-boot.bin at any address. It is skipped by
default when u-boot is loaded by either --bios or --kernel.
To load u-boot.bin at a different address, one can use u-boot
chain-loading or qemu loader device[1].
Yang Xiwen [Sat, 31 May 2025 13:10:02 +0000 (21:10 +0800)]
arm: armv7: restore section to .text after saved_args
when CONFIG_BLOBLIST is enabled, the section is switched to .data but is
not switched back to .text. It makes all the code below placed in .data
section, also breaks CONFIG_POSITION_INDEPENDENT.
Fix it by adding `.section .text` to switch the section back to .text.
Fixes: 5103e69344d6 ("arm: armv7: save boot arguments") Signed-off-by: Yang Xiwen <forbidden405@outlook.com>
Yao Zi [Fri, 30 May 2025 09:48:51 +0000 (09:48 +0000)]
doc: thead: lpi4a: Update for S-Mode proper U-Boot support
Proper U-Boot for Lichee Pi 4A now runs in S mode instead of M mode,
which means the extra firmware, OpenSBI, must be built and integrated
in the image, and the vendor U-Boot cannot chainload the result image
anymore as it runs in M mode.
Remove redundant information about chainloading and update build steps
to mention OpenSBI firmware.
Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Yao Zi [Fri, 30 May 2025 09:48:50 +0000 (09:48 +0000)]
board: thead: licheepi4a: Run proper U-Boot in S-Mode
RISC-V software usually expects S mode when leaving the firmware, e.g.
UEFI applications could only run in S mode. Let's convert proper U-Boot
of Lichee Pi 4A port to run in S mode.
Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Yao Zi [Fri, 30 May 2025 09:48:47 +0000 (09:48 +0000)]
riscv: cpu: th1520: Build spl.c for SPL only
Symbols in spl.c only function correctly in SPL stage. Build the file
for SPL only to avoid weak symbols in proper U-Boot being unexpectedly
reloaded.
Fixes: 5fe9ced3552 ("riscv: cpu: Add TH1520 CPU support") Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
configs: raise SPL_SYS_MALLOC_SIZE to 8 MiB on RISC-V
On several RISC-V boards we have seen that 1 MiB is a insufficient value
for CONFIG_SPL_SYS_MALLOC_SIZE.
For instance qemu-riscv32_spl_defconfig fails booting because u-boot.itb
exceeds 1 MiB.
8 MiB is a reasonable value that allows adding FPGA blobs or splash images
to main U-boot.
Reported-by: Simon Glass <sjg@chromium.org> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Tom Rini [Sat, 7 Jun 2025 14:18:54 +0000 (08:18 -0600)]
Merge tag 'doc-2025-07-rc4' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request doc-2025-07-rc4
Documentation:
* fix typo in gcc.rst
* correct EFI_TCG2_PROTOCOL_MEASURE_DTB description
* Add missing reference to firmware for BB-AI64
* Tidy up the bootefi-command docs
Peter Robinson [Sun, 25 May 2025 12:10:58 +0000 (13:10 +0100)]
doc: board: ti: Add missing firmware for BB-AI64
The details of the sysfw.itb from the R5 build that
also needs to be copied as part of the target images
is missing, but is included in the image formats a
little further down, so add it to the instructions.
%s/data that change/data that changes/
%s/cannot be used has/cannot be used for/
%s/Otherwise/Otherwise,/
%s/allows better measurement/allows for better measurement/
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tom Rini [Fri, 6 Jun 2025 16:51:52 +0000 (10:51 -0600)]
Merge patch series "Remove as much arch/arm/dts/*.h as possible"
Tom Rini <trini@konsulko.com> says:
Taking inspiration from Heiko's patch[1] this series goes and cleans up
all of the arch/arm/dts/*.h files that can be easily removed. The big
challenge I ran in to here was that for some platforms that aren't using
OF_UPSTREAM were didn't have a sufficiently deep search path to find
files there rather than arch/arm/dts. This also showed that only ARM had
local header files to deal with.
Tom Rini [Wed, 28 May 2025 23:27:10 +0000 (17:27 -0600)]
nxp: Remove local arch/arm/dts/imx8mm-pinfunc.h
We have this file in both arch/arm/dts and
dts/upstream/src/arm64/freescale. This file is identical save for
changes which have been made upstream. Remove our local copy to get in
sync with upstream now.
Acked-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Wed, 28 May 2025 23:27:09 +0000 (17:27 -0600)]
atmel: Remove local arch/arm/dts/{sama5d2, sama7g5}-pinfunc.h
We have these files in both arch/arm/dts and
dts/upstream/src/arm/microchip. These files are identical save for
changes which have been made upstream. Remove our local copy to get in
sync with upstream now.
Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Wed, 28 May 2025 23:27:08 +0000 (17:27 -0600)]
arch/arm/dts: Remove strict subset header
As part of moving to using OF_UPSTREAM and so the upstream DT related
header files we have a header that is under the arch/arm/dts directory
and differ in being a strict subset of what is found upstream. We can
remove this now to prevent future conflicts.
Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com>
As part of moving to using OF_UPSTREAM and so the upstream DT related
header files we have a number of these headers that are under the
arch/arm/dts directory and differ only in combinations of spacing
changes and/or switching to SPDX license tags. We can remove these now
to prevent future conflicts.
Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Wed, 28 May 2025 23:27:06 +0000 (17:27 -0600)]
arch/arm/dts: Remove identical headers
As part of moving to using OF_UPSTREAM and so the upstream DT related
header files we have a number of these headers that are under the
arch/arm/dts directory and are currently identical to the versions in
dts/upstream. We can remove these now to prevent future conflicts.
Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Wed, 28 May 2025 23:27:05 +0000 (17:27 -0600)]
arch/arm/dts: Remove unused header
As part of moving to using OF_UPSTREAM and so the upstream DT related
header files we have a header that is under the arch/arm/dts directory
and now unused. We can remove this now to prevent any future conflicts.
Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Wed, 28 May 2025 23:27:04 +0000 (17:27 -0600)]
scripts/Makefile.lib: Rework upstream_dtsi_include to get subdirectories
A problem with the logic in upstream_dtsi_include currently is that it
does not list directories such as dts/upstream/src/arm/nxp/imx and so
will not findi "imx6ul-pinfunc.h" for example as it is normally and
correctly included without vendor sub-paths. Expand the current wildcard
glob to catch these directories too.
Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Wed, 28 May 2025 20:37:45 +0000 (14:37 -0600)]
include/dt-bindings: Remove headers we can safely upgrade
As part of moving to using OF_UPSTREAM and so the upstream dt-bindings
headers we have a number of these headers that are in our include
directory and while they are not a strict subset of the upstream version
of the headers, all platforms build with the new headers as well. We can
remove the copies under include/dt-bindings now to prevent future
conflicts.
Tom Rini [Wed, 28 May 2025 00:03:01 +0000 (18:03 -0600)]
include/dt-bindings/reset: Remove local version of bcm6318-reset.h
Aside from SPDX tags, the only difference between our version of this
header and upstream is that BCM6318_RST_HOSTMIPS was defined to 11 (the
same as BCM6318_RST_PHYMIPS) and is now defined to 12.
Tom Rini [Tue, 27 May 2025 23:50:38 +0000 (17:50 -0600)]
include/dt-bindings: Remove strict subset headers
As part of moving to using OF_UPSTREAM and so the upstream dt-bindings
headers we have a number of these headers that are in our include
directory and differ in being a strict subset of what is found upstream.
We can safely remove the copies under include/dt-bindings now to prevent
future conflicts.
As part of moving to using OF_UPSTREAM and so the upstream dt-bindings
headers we have a number of these headers that are in our include
directory and differ only in combinations of spacing changes and/or
switching to SPDX license tags. We can safely remove the copies under
include/dt-bindings now to prevent future conflicts.
Tom Rini [Tue, 27 May 2025 22:18:34 +0000 (16:18 -0600)]
include/dt-bindings: Remove identical headers
As part of moving to using OF_UPSTREAM and so the upstream dt-bindings
headers we have a number of these headers that are in our include
directory and are currently identical to the versions in dts/upstream.
We can remove these now to prevent future conflicts.
Tom Rini [Tue, 27 May 2025 22:18:33 +0000 (16:18 -0600)]
include/dt-bindings: Remove unused headers
As part of moving to using OF_UPSTREAM and so the upstream dt-bindings
headers we have a number of these headers that are in our include
directory and not referenced by any code outside of dts/upstream. We can
remove these now to prevent future conflicts.
Quentin Schulz [Wed, 28 May 2025 12:07:27 +0000 (14:07 +0200)]
power: rk8xx: fix swapped mask and value in init registers for RK806
The val (the bits to set) is the second member of the reg_data structure
and mask the third one. We obviously want to clear bits 6 and 7 in order
to only set bit 7 in there instead of only clearing bit 7 in order to
write bits 6 and 7 (which makes no sense).
Fortunately, according to the datasheet, bit 6 value doesn't matter when
bit 7 is set so this is essentially just a cosmetic change, no intended
change in behavior.
Fixes: f172575d92cd ("power: rk8xx: add support for RK806") Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Justin Klaassen [Fri, 23 May 2025 16:53:41 +0000 (16:53 +0000)]
rockchip: rk3399-nanopi-4: Enable IO-domain driver in SPL
The NanoPi RK3399 boards support UHS-I (up to SDR104) SD cards, however
using any of these 1.8v modes results in a boot failure in SPL upon soft
reboot.
The issue is that the "vcc_sdio" regulator is left at 1.8v on reboot
and the corresponding GPIO defaults to 3.3v. This prevents the SD card
from being reinitialized and read successfully.
This change enables the RK8XX regulators and Rockchip IO-domain drivers
in SPL, which initializes "vcc_sdio" regulator to 3.0v and configures
the GPIO for the correct level on boot.
Signed-off-by: Justin Klaassen <justin@tidylabs.net> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Justin Klaassen [Fri, 23 May 2025 16:53:40 +0000 (16:53 +0000)]
rockchip: rk3399-nanopi-4: Allow MMC driver to control SD regulators
This change removes the "regulator-always-on" property from the
"vcc3v0_sd" (vmmc-supply) and "vcc_sdio" (vqmmc-supply) regulators,
which otherwise prevents the MMC driver from being able to power cycle
the SD card as part of the initialization procedure.
It also removes the "regulator-boot-on" from the "vcc_sdio" regulator,
which could theoretically damage a SD card that is already initialized
in a low voltage mode.
Signed-off-by: Justin Klaassen <justin@tidylabs.net> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Justin Klaassen [Fri, 23 May 2025 16:53:39 +0000 (16:53 +0000)]
regulator: rk8xx: Add CONFIG_SPL_REGULATOR_RK8XX
Allows use of the regulator functions of the RK8XX PMIC in SPL, which is
necessary to support the functionality of the Rockchip IO-domain driver
on relevant platforms.
rockchip: px30: Fix hard dependency to DEBUG_UART_BOARD_INIT
Because DEBUG_UART_BOARD_INIT depends on DEBUG_UART, hard dependency
to DEBUG_UART_BOARD_INIT in ROCKCHIP_PX30 can cause warnings if
DEBUG_UART is disabled.
The DEBUG_UART_BOARD_INIT is already implied by ARCH_ROCKCHIP entry.
Remove hard dependency from ROCKCHIP_PX30, so that it will be
consistent with other rockchip boards.
debug_uart: Replace debug functions with dummies if CONFIG_DEBUG_UART is not set
In case DEBUG UART is not used, define dummy macros replacing
the actual function implementations that will not be available.
This allows to compile code and avoid linker errors.
Redefine the DEBUG_UART_FUNCS macro if DEBUG UART is not available,
to avoid compilation errors.
Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
ram: rockchip: Fix dependency of RAM_ROCKCHIP_DEBUG
The RAM_ROCKCHIP_DEBUG can be used only if DEBUG_UART is
available.
The next commit introduces changes in definition of debug
uart functions, so that DEBUG_UART is required to be defined
in order to initialize uart and use print functions.
efi: stub: Change _debug_uart_putc function to inline
Update definition of _debug_uart_putc to static inline.
This will allow to avoid compilation warnings about unused code
after introduction of patch changing debug uart functions to
dummies if CONFIG_DEBUG_UART is not set.
This also matches the instructions in include/debug_uart.h and
provides consistency with implementations for other platforms.
Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
arm: uniphier: Change _debug_uart_putc function to inline
Update the definition of _debug_uart_putc to static inline.
This matches the instructions in include/debug_uart.h and
provides consistency with implementations for other platforms.
Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Heiko Thiery [Wed, 28 May 2025 09:05:37 +0000 (11:05 +0200)]
arm: dts: remove k3-serdes.h
This file is a duplicate and also comes with the sync of the linux
mainline dts files. By removing this the one from the dts folder should
be taken that is more up-to-date.
cmd: bootmenu: permit to select bootmenu entry with a shortcut
Permit to select a bootmenu entry with a key shortcut. This is
especially useful in production or testing scenario to automate flashing
procedure or testing procedure.
The boot entry are changed to append the shortcut key to it.
Example:
1. Run default boot command.
2. Boot system via TFTP.
3. Boot production system from NAND.
4. Boot recovery system from NAND.
5. Load production system via TFTP then write to NAND.
6. Load recovery system via TFTP then write to NAND.
7. Load BL31+U-Boot FIP via TFTP then write to NAND.
8. Load BL2 preloader via TFTP then write to NAND.
9. Reboot.
a. Reset all settings to factory defaults.
0. Exit
0 is always reserved for Exit to console.
On pressing the keyboard key 2, the bootmenu entry 2 is selected and
executed.
Up to 34 key shortcut (0 excluded as reserved) are supported from 1-9
and a-z.
If a shortcut key not present in the bootmenu list is pressed, it is
simply ignored and eventually the autoboot is interrupted.
Capital A-Z are converted to lower a-z and the related option is
selected.
Suggested-by: Weijie Gao <weijie.gao@mediatek.com> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Tested-by: Petr Štetiar <ynezz@true.cz>
The high-speed UART from MediaTek supports baudrate accuracy
compensation when using high-speed mode 3.
This is done by calculating the first digit of the fraction part of
sample count value. The fraction value will be then used as the
reference to insert 0 to 10 sample cycle(s) to one frame (assume
that frame format is 8n1, i.e. 10 bits per frame).
The fracdiv_[l/m] registers are used to determine whether a bit in one frame
should be inserted with one sample cycle.
With typical 40MHz source clock, the actual baudrates with/without
accuracy compensation are:
projects / thirdparty / u-boot.git / log
