dram_para1 is different in the D1s DDR2 configuration, but investigation
shows its default value is not actually used, as a hardcoded value is
used in auto_scan_dram_rank_width(), and auto_scan_dram_size()
completely overwrites the existing value.
Clarify the logic here by splitting dram_para1 into its six different
fields, as done in dram_sunxi_dw.c.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Some of these unused parameters have different values on the D1s SoC,
which includes in-package DDR2. Make that explicit, instead of including
the values from the stock DDR3 configuration. We still keep the unused
parameters around for now, for comparison with the BSP DRAM parameters.
Signed-off-by: Samuel Holland <samuel@sholland.org>
On D1/D1s, the boot ROM enables the data cache, and it is left enabled
throughout SPL. Some DRAM controller settings affect the mapping of the
CPU address space, so the data cache must be flushed when changing them.
Signed-off-by: Samuel Holland <samuel@sholland.org>
The check is expected to pass on D1s, where the DRAM die has only one
bank, as signified by bit 12 being unset in the stock dram_para1 value.
Changing the offset matches the algorithm from dram_sunxi_dw.c (which
uses 2 bank bits + 9 page bits), and works on D1, D1s, and T113-S3.
Link: https://github.com/smaeul/sun20i_d1_spl/issues/14
Link: https://github.com/YuzukiHD/TinyKasKit/commit/1bc76937dcf3
Reported-by: YuzukiTsuru <gloomyghost@gloomyghost.com>
Signed-off-by: Samuel Holland <samuel@sholland.org>
The SDRAM_IDX in DDRSS_V2A_CTL_REG describes the number of address bits
minus 16 that are used to determine the mask used to detect memory
rollover and prevent aliasing and false coherency issues.
Set SDRAM_IDX using the device private data, ddr_ram_size for K3 family
of SoCs.
Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
The functionality of enabling Inline ECC is now controlled by
CONFIG_K3_INLINE_ECC. So, remove the support for 'ti,ecc-enable'
property to avoid redundancy and to ensure the Inline ECC feature is
mananged through build-time config.
Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Add CONFIG_K3_INLINE_ECC so that ECC functions can be compiled into R5 SPL
only when the config has been enabled.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Enable ECC 1-bit error, 2-bit error, multiple 1-bit error interrupts
by setting the respective bits in the DDRSS_V2A_INT_SET_REG register.
Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
Setup the ECC region's start and range using the device private data,
ddrss->ddr_bank_base[0] and ddrss->ddr_ram_size. Also, move start and
range of ECC regions from 32 bits to 64 bits to accommodate for
DDR greater than or equal to 4GB.
Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
As R5 is a 32 bit processor, the RAM banks' base and size calculation
is restricted to 32 bits, which results in wrong values if bank's base
is greater than 32 bits or bank's size is greater than or equal to 4GB.
So, add k3_ddrss_ddr_bank_base_size_calc() to get the base address and
size of RAM's banks from the device tree memory node, and store in a
64 bit device private data which can be used for ECC reserved memory
calculation, Setting ECC range and Fixing up bank size in device tree
when ECC is enabled.
Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
The 1-bit inline ECC support in TI's DDRSS bridge requires
the configured memory regions to be preloaded with a pattern
before use. This is done by the k3-ddrss driver from the
R5 SPL in a 'for' loop. It takes around 10 seconds to fill
2GB of memory, for example. Memset can cut the time in half
and using DMA currently yields a similar result.
The BIST engine of DDR controller provides support for
initializing any memory region with a pattern. This
bypasses the DDRSS bridge, so the required inline ECC
data is not computed and populated in the memory. For
some values like zero, the computed ECC syndrome is also
zero and we can use these values to preload the memory
from the DDR controller, without the assistance of the
bridge.
The registers involved in the process are described in the
'DDR controller registers' topic in [1] AM62 and [2] J721E
reference manuals.
The patch replaces the 'for' loop memory fill function with
the BIST memory initialization procedure. This cuts the time
to preload the 2GB memory from 10 seconds down to 1 second.
The bist preload function uses the lpddr4 APIs in the k3-ddrss,
so this is compatible with devices with both 16-bit LPDDR4 and
32-bit LPDDR4 interfaces (e.g J721E).
[1] AM62x: https://www.ti.com/lit/pdf/spruiv7
[2] DRA829/TDA4VM: https://www.ti.com/lit/zip/spruil1
Signed-off-by: Georgi Vlaev <g-vlaev@ti.com>
Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
Add Renesas R-Car Gen4 DBSC5 DRAM controller driver. This driver is currently
capable of bringing LPDDR5 DRAM on Renesas R-Car V4H Whitehawk board. Further
boards can be supported by supplying board specific DRAM configuration data
via dbsc5_get_board_data(). Support for R-Car V4M is not implemented, however
the driver is already mostly prepared to support this SoC.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Those debug() calls might be useful, but beware. They can cause the DDR
controller to hang if we do not run the sequence quickly enough.
They usually are not an issue with upstream U-Boot and the default DDR
config, but they have become troublesome with custom DDR configs.
Drop those debug() statements that shouldn't be present in
time-sensitive code, to avoid anyone else falling into the trap.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Simon Glass <sjg@chromium.org> says:
When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL
Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.
For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:
#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.
This series starts a change in terminology and usage to resolve the
above issues:
- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_
It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.
This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.
The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
Use PHASE_ as the symbol to select a particular XPL build. This means
that SPL_TPL_ is no-longer set.
Update the comment in bootstage to refer to this symbol, instead of
SPL_
Signed-off-by: Simon Glass <sjg@chromium.org>
In lpddr4_start function error returned by lpddr4_enablepiinitiator
may go undetected due to overwrite of return code.
Add support to handle error in above case.
Reported-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Add driver for AST2700 to initialize DRAM in SPL.
This patch also refactors the Kconfig dependency of
Aspeed DRAM drivers as some of them are shared among
the file structures of RV and ARM ISAs.
Signed-off-by: Chia-Wei Wang <chiawei_wang@aspeedtech.com>
Acked-by: Leo Yu-Chi Liang <ycliang@andestech.com>
The code here is confusing due to large blocks which are #ifdefed out.
Add a function phase_sdram_init() which returns whether SDRAM init
should happen in the current phase, using that as needed to control the
code flow.
This increases code size by about 500 bytes in SPL when the cache is on,
since it must call the rather large rockchip_sdram_size() function.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present gd->ram_size is 0 in SPL, meaning that it is not possible to
enable the cache. Correct this by always populating the RAM size
correctly.
This increases code size by about 500 bytes in SPL, since it must call
the rather large rockchip_sdram_size() function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
The J722S family of SoCs uses the same DDR controller as found on the
AM62A family. Enable this option when building for the J722S family.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
Move cru_rk3308.h and grf_rk3308.h to arch-rockchip to match path used
for all other Rockchip SoCs.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Please pull the updates for rockchip platform:
- Add board: rk3588 Generic, Cool Pi CM5, Theobroma-Systems RK3588 Jaguar SBC,
Toybrick TB-RK3588X;
rk3588s Cool Pi 4B;
rk3566 Pine64 PineTab2;
- Add saradc v2 support;
- Add PMIC RK806 support;
- rk3588 disable force_jtag by default;
- Migrate to use IO-domain driver for all boards;
- Use common bss and stack addresses for rk33xx and rk35xx boards;
- Other updates for driver, config and dts;
The am62px family of SoCs uses the same DDR controller as found on the
am62ax family. Enable this option when building for the am62px family
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Signed-off-by: Bryan Brattlof <bb@ti.com>
The different macros use writel which is defined in asm/io.h, so let's
include the header so users of hardware.h do not need to include
asm/io.h as well.
While at it, remove asm/io.h includes wherever
asm/arch-rockchip/hardware.h is included already.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
hardware.h is only defining macros which are "wrappers" around writel().
writel() is however not available in hardware.h, <asm/io.h> needs to be
included. This means in order to use the wrappers in hardware.h, one
also needs to include the <asm/io.h> header.
However, this cannot be done currently because hardware.h is included in
include/configs files, which are implicitly included by every code file
by default, which makes the compilation of arch/arm/cpu/armv8/u-boot.lds
fail because ALIGN (the ARM assembly directive) got redefined by some
of the include files coming from <asm.io.h>.
Because nothing in the include/configs file actually use hardware.h,
let's remove the inclusion of hardware.h from the include/configs files
and explicitly add it wherever it is required.
This prepares for the next commit where <asm/io.h> will be included in
hardware.h.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Add J784S4 initialization files for initial SPL boot.
config SYS_K3_MCU_SCRATCHPAD_BASE default value is same
for J721E, J721S2, J784S4. So combined them into a single
default.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
[ add firewall configurations and change the R5 MCU scratchpad ]
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Signed-off-by: Dasnavis Sabiya <sabiya.d@ti.com>
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> # AM69-SK
Rename ARCH_RMOBILE to ARCH_RENESAS because all the chips are made
by Renesas, while only a subset of them is from the R-Mobile
line.
Use the following command to perform the rename:
"
$ git grep -l 'ARCH_RMOBILE' | xargs -I {} sed -i 's@ARCH_RMOBILE@ARCH_RENESAS@g' {}
"
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Add support for ddr4 on rv1126. Timing detection files are imported
from downstream Rockchip BSP u-boot. Allow selecting ddr4 ram with
define CONFIG_RAM_ROCKCHIP_DDR4.
Signed-off-by: Tim Lunn <tim@feathertop.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The Allwinner R528/T113-s/D1/D1s SoCs all share the same die, so use the
same DRAM initialisation code.
Make use of prior art here and lift some code from awboot[1], which
carried init code based on earlier decompilation efforts, but with a
GPL2 license tag.
This code has been heavily reworked and cleaned up, to match previous
DRAM routines for other SoCs, and also to be closer to U-Boot's coding
style and support routines.
The actual DRAM chip timing parameters are included in the main file,
since they cover all DRAM types, and are protected by a new Kconfig
CONFIG_SUNXI_DRAM_TYPE symbol, which allows the compiler to pick only
the relevant settings, at build time.
The relevant DRAM chips/board specific configuration parameters are
delivered via Kconfig, so this code here should work for all supported
SoCs and DRAM chips combinations.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Sam Edwards <CFSworks@gmail.com>
At the moment all Allwinner DRAM initialisation routines are stored in
arch/arm/mach-sunxi, even though those "drivers" are just a giant
collection of writel's, without any architectural dependency.
The R528/T113-s SoC (with ARM cores) and the D1/D1s Soc (with RISC-V
cores) share the same die, so should share the same DRAM init routines as
well.
To prepare for this, add a new sunxi directory inside drivers/ram, and
add some stub entries to prepare for the addition of the share DRAM code
for those SoCs.
The RISC-V D1(s) SoCs will probably use SPL_DM, so for that SoC this
would be the right directory anyway.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
A follow-up to commit 842fb5de424e
("drivers: use devfdt_get_addr_size_index_ptr when cast to pointer")
and commit 320a1938b6f7
("drivers: use devfdt_get_addr_index_ptr when cast to pointer").
In addition to using the *_ptr variants of these functions where the
address is cast to a pointer, this also changes devfdt_get_addr_*() to
dev_read_addr_*() in a few places. Some variable and field types are
changed from fdt_addr_t or phys_addr_t to void* where the cast was
happening later.
This patch fixes a number of compile warnings when building a 32bit
U-Boot with CONFIG_PHYS_64BIT=y. In some places, it also fixes error
handling where the return value of dev_read_addr() etc. was checked for
NULL instead of FDT_ADDR_T_NONE.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
_ alignment with kernel DT v6.5 for stm32f429 and stm32f746
_ rework way of displaying ST logo for stm32f746-disco and stm32f769-disco
STM32 MPU:
_ alignment with kernel DT v6.6-rc1
_ add RNG support for stm32mp13
_ add USB, USB boot and stm32prog command support for stm32mp13
_ add support of USART1 clock for stm32mp1
_ only print RAM and board code with SPL_DISPLAY_PRINT flag for
stm32mp1
_ rename update_sf to dh_update_sd_to_sf and add dh_update_sd_to_emmc
for stm32mp15xx DHCOR
-----BEGIN PGP SIGNATURE-----
iQJQBAABCgA6FiEEXyrViUccKBz9c35Jysd4L3sz/6YFAmUdaJccHHBhdHJpY2Uu
Y2hvdGFyZEBmb3NzLnN0LmNvbQAKCRDKx3gvezP/ptHxEACdibF5EoRb40qhQCWB
mwW50s76xWOyHGOGjSe3l18zxPdBjQ+9rnT8/A+mjaa8he4kMX9EZJyYRogcz7eR
QcnSeu9Q4L8bKbqnPBOpKF6TN7rFOIUcu+BWp3o8jZ+7/q7OSJrVLsjbXtCuCLnB
q5Pie/in7hmHJsQr6LJ4r31chW6Zm4VDuFiXquuxyE/c94Q8Ue27ag1/RfXL8b/g
Ir9aO+PAldGnVdnhPz4e6PZhzMfCVafw+DR7GVx3Zfnx2bg/dajo38UaLBDdEIS1
EIKONU2CBT/W1kPkLFiz+NdaYCzK9EL+RIbN/iG7ms+ds1+wc3zXpWwqZFASfIod
ZF788Up+wW+3SrKI2ySFjhQroNzDascn+bbHm4yJuAsORqY0XkxjSuWcSz++q8Hs
eMTw/R4uMfEiDvN1A7xlhBMuBrBHk4/6bdCRx2R6nkWes542fsgjXy8tGRWyUgnY
nbpTfYU07N8ck6arZ36KThedD7whJHHRcBYtLjhRG+lKbD0epWy67pXgTr9edTLf
U6ddH+Tndn4qhx067VhZ8vEXTCzypt4lY61MLcM0b9z8S1nJDn8b8jmiii7IR76L
/ocXzuLvNWHfmwNnB2hj/YY+n78vlZhegUxL5/6sH9lNebnewyEzCkVENNELUSYf
8M6vEZprvuhN44Z6hBUWZxXk0w==
=1mUx
-----END PGP SIGNATURE-----
Merge tag 'u-boot-stm32-20231004' of https://source.denx.de/u-boot/custodians/u-boot-stm
STM32 MCU:
_ alignment with kernel DT v6.5 for stm32f429 and stm32f746
_ rework way of displaying ST logo for stm32f746-disco and stm32f769-disco
STM32 MPU:
_ alignment with kernel DT v6.6-rc1
_ add RNG support for stm32mp13
_ add USB, USB boot and stm32prog command support for stm32mp13
_ add support of USART1 clock for stm32mp1
_ only print RAM and board code with SPL_DISPLAY_PRINT flag for
stm32mp1
_ rename update_sf to dh_update_sd_to_sf and add dh_update_sd_to_emmc
for stm32mp15xx DHCOR
[ Fix merge conflict at board/st/common/stm32mp_dfu.c ]
Signed-off-by: Tom Rini <trini@konsulko.com>
Ensure that the RAM configuration line is only printed when
CONFIG_SPL_DISPLAY_PRINT is set.
Signed-off-by: Harald Seiler <hws@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
