In dbsc5_read_vref_training the arrays dvw_min_byte0_table and
dvw_min_byte1_table have 128 elements per channel. The variable
vref_stop_index is limited to be a maximum of 128. This means that the
index used to access the arrays must use a test of '< vref_stop_index'
rather than '<= vref_stop_index' in order to prevent out of bounds
accesses to the arrays.

This issue was found by Smatch.

Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tested-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

E Shattow <e@freeshell.de> says:

Make consistent use of lowercase hexadecimal prefix '0x' throughout U-Boot.

There are a few remaining uses of uppercase 'X' to denote hexadecimal prefix
or placeholder in documentation and error messages.

External devicetree-rebasing dts/upstream and the generated code of
xilinx/zynq are ignored for the series.

Link: https://lore.kernel.org/r/20250606224558.1117422-1-e@freeshell.de

Use consistent lowercase hex prefix style in drivers/*

Does not change hex prefix case in allcaps uppercase style error messages

Signed-off-by: E Shattow <e@freeshell.de>

RAM drivers using Device Model currently lack of their own Kconfig menu
entry, which makes Kconfig put all options of the class in the top-level
menu of device drivers. These options are also incorrectly grouped with
pinctrl options in the generated .config, which is hard to read. Let's
create a menu entry for these drivers.

Fixes: 6c51df6859f ("dm: Add support for RAM drivers")
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>

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>

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.

Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

This patch cleans the vendor code of DDR initialization up, converts the
driver to fit in DM framework and use a firmware[1] packaged by binman to
ship PHY configuration.

Currently the driver is only capable of initializing the controller to
work with dual-rank 3733MHz LPDDR4, which is shipped by 16GiB variants
of LicheePi 4A boards and I could test with. Support for other
configurations could be easily added later.

Link: https://github.com/ziyao233/th1520-firmware # [1]
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

Add ddr driver for rk3576 to get the ram capacity.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Add support for reading DRAM size information from PMUGRF os_reg18 reg.

Compared to most Rockchip SoCs the RK3528 use os_reg18 for DRAM info,
instead of os_reg2.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Currently in j721e_init.c we check which firewalls to remove using
the board configuration (e.g CONFIG_TARGET_J721E_R5_EVM). We do this
as J721e and J7200 have different IP and firewalls but use the same
SoC definition (SOC_K3_J721E) even though they are different SoCs.

The idea was they would be similar enough that they both could use
the same SoC config to help with common code sharing. Board checks
would then be used differentiate.

This has grown far too messy to maintain any more, especially now
that there is more than one board using J721e (EVM, SK, Beagle AI64).
As differentiation is done based on board, every one of these boards
would have to have checks added for them. Instead let's split J7200
support out from J721e like how normal new SoC support is done.

This patch touches several subsystems and could not be split much better
as when we add SOC_K3_J7200 we want to make use of it in all spots that
once used the combined SOC_K3_J721E so we can turn off SOC_K3_J721E when
building for J7200 boards.

Signed-off-by: Andrew Davis <afd@ti.com>