Newer versions of the imx8mm-cl-iot-gate boards may come populated with a
Samsung 4GB DDR model.
Add support for it.
Signed-off-by: Fabio Estevam <festevam@denx.de>
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 c8ffd1356d, reversing
changes made to 2ee6f3a5f7.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
We have a few places here that the function declarations do not
match their prototypes, correct them.
Signed-off-by: Ying-Chun Liu (PaulLiu) <paulliu@debian.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP i.MX U-Boot Team <uboot-imx@nxp.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reported-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
I was trying to employ lpddr4_mr_read() to something similar to what
the imx8mm-cl-iot-gate board is doing for auto-detecting the RAM
type. However, the version in drivers/ddr/imx/imx8m/ddrphy_utils.c
differs from the private one used by that board in how it extracts the
byte value, and I was only getting zeroes. Adding a bit of debug
printf'ing gives me
tmp = 0x00ffff00
tmp = 0x00070700
tmp = 0x00000000
tmp = 0x00101000
and indeed I was expecting a (combined) value of 0xff070010 (0xff
being Manufacturer ID for Micron). I can't find any documentation that
says how the values are supposed to be read, but clearly the iot-gate
definition is the right one, both for its use case as well as my
imx8mp-based board.
So lift the private definition of lpddr4_mr_read() from the
imx8mm-cl-iot-gate board code to ddrphy_utils.c, and add a declaration
in the ddr.h header where e.g. get_trained_CDD() is already declared.
This has only been compile-tested for the imx8mm-cl-iot-gate
board (since I don't have the hardware), but since I've merely moved
its definition of lpddr4_mr_read(), I'd be surprised if it changed
anything for that board.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Tested-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Currently, the DDR type is retrieved by iteracting inside an array
of possible DDR types.
This may take saveral attempts, which slows the overall U-Boot process
and does not provide a good user experience:
U-Boot SPL 2021.07 (Feb 28 2022 - 06:39:32 +0000)
DDRINFO: Cfg attempt: [ 1/6 ]
DDRINFO(M): mr5-8 [ 0xff000010 ]
DDRINFO(T): mr5-8 [ 0x5000010 ]
resetting ...
U-Boot SPL 2021.07 (Feb 28 2022 - 06:39:32 +0000)
DDRINFO: Cfg attempt: [ 2/6 ]
DDRINFO(M): mr5-8 [ 0xff000010 ]
DDRINFO(T): mr5-8 [ 0x1061010 ]
resetting ...
U-Boot SPL 2021.07 (Feb 28 2022 - 06:39:32 +0000)
DDRINFO: Cfg attempt: [ 3/6 ]
DDRINFO(M): mr5-8 [ 0xff000010 ]
DDRINFO(T): mr5-8 [ 0xff000010 ]
Normal Boot
WDT: Not starting
Trying to boot from MMC2
NOTICE: BL31: v2.5(release):v2.5
NOTICE: BL31: Built : 07:12:44, Jan 24 2022
Improve the boot time by retrieving the correct DDR information from
the EEPROM:
U-Boot SPL 2022.04-rc4-00045-g6d02bc40d58c (Mar 19 2022 - 08:22:29 -0300)
DDRINFO(D): Kingston 4096G
DDRINFO(M): mr5-8 [ 0xff000010 ]
DDRINFO(E): mr5-8 [ 0xff000010 ]
Normal Boot
WDT: Started watchdog@30280000 with servicing (60s timeout)
Trying to boot from MMC2
NOTICE: BL31: v2.5(release):v2.5
NOTICE: BL31: Built : 22:28:11, Mar 15 2022
Based on the original code from Compulab's U-Boot.
Tested on a imx8mm-cl-iot-gate board populated with 4GB of RAM.
Signed-off-by: Fabio Estevam <festevam@denx.de>
