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>
When env support is disabled then usage of env_get_f() generates linker
errors. So do not compile env_get_f() when env support is disabled (for
example when disabled only in SPL).
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Add entry for 3732 MT/s mode of operation of the LPDDR4, in
which case the DDR PLL has to be configured in 933 MHz mode.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@denx.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>
The value CONFIG_DB_784MP_GP is only used in the DDR code to refer to
CONFIG_TARGET_DB_MV784MP_GP so just use that second value directly.
Cc: Stefan Roese <sr@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Stefan Roese <sr@denx.de>
This converts the following to Kconfig:
CONFIG_CHIP_SELECTS_PER_CTRL
Cc: Alison Wang <alison.wang@nxp.com>
Cc: Pramod Kumar <pramod.kumar_1@nxp.com>
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Cc: Rajesh Bhagat <rajesh.bhagat@nxp.com>
Cc: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
In commit 3fc92a215b ("ddr: marvell: a38x: fix SPLIT_OUT_MIX state
decision") I ported a cleaned up and changed version of patch
mv_ddr: a380: fix SPLIT_OUT_MIX state decision
In the port we removed checking for BYTE_HOMOGENEOUS_SPLIT_OUT bit,
because:
- the fix seemed to work without it
- the bit was checked for only at one place out of two, while the second
bit, BYTE_SPLIT_OUT_MIX, was checked for in both cases
- without the removal it didn't work on Allied Telesis' x530 board
We recently had a chance to test on more boards, and it seems that the
change needs to be opposite: instead of removing the check for
BYTE_HOMOGENEOUS_SPLIT_OUT from the first if() statement, the check
needs to be added also to the second one - it needs to be at both
places.
With this change all the Turris Omnia boards I have had available to
test seem to work, I didn't encounter not even one failed DDR training.
As last time, I am noting that I do not understand what this code is
actually doing, I haven't studied the DDR training algorithm and
I suspect that no one will be able to explain it to U-Boot contributors,
so we are left with this blind poking in the code with testing whether
it works on several boards and hoping it doesn't break anything for
anyone :-(.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
After acking the requested frequency, should wait the ack bit clear
by DDR controller and check the DFS interrupt for next request polling.
Otherwise, the next polling of request bit will get previous value
that DDR controller have not cleared it, so a wrong request frequency
is used.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
On i.MX8ULP, The dram config timing need to be saved into sram for
ddr retention when APD enter PD mode, so add this support on i.MX8ULP.
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
This is a cleaned up and fixed version of a patch
mv_ddr: a380: fix SPLIT_OUT_MIX state decision
in each pattern cycle the bus state can be changed
in order to avoide it, need to back to the same bus state on each
pattern cycle
by
Moti Boskula <motib@marvell.com>
The original patch is not in Marvell's mv-ddr-marvell repository. It was
gives to us by Marvell to fix an issues with DDR training on some
boards, but it cannot be applied as is to mv-ddr-marvell, because it is
a very dirty draft patch that would certainly break other things, mainly
DDR4 training code in mv-ddr-marvell, since it changes common functions.
I have cleaned up the patch and removed stuff that seemed unnecessary
(when removed, it still fixed things). Note that I don't understand
completely what the code does exactly, since I haven't studied the DDR
training code extensively (and I suspect that no one besides some few
people in Marvell understand the code completely).
Anyway after the cleanup the patch still fixes isssues with DDR training
on the failing boards.
There was also a problem with the original patch on some of the Allied
Telesis' x530 boards, reported by Chris Packham. I have asked Chris to
send me some logs, and managed to fix it:
- if you look at the change, you'll notice that it introduces
subtraction of cur_start_win[] and cur_end_win[] members, depending on
a bit set in the current_byte_status variable
- the original patch subtracted cur_start_win[] if either
BYTE_SPLIT_OUT_MIX or BYTE_HOMOGENEOUS_SPLIT_OUT bits were set, but
subtracted cur_end_win[] only if the first one (BYTE_SPLIT_OUT_MIX)
was set
- from Chris Packham logs I discovered that the x530 board where the
original patch introduced DDR training failure, only the
BYTE_HOMOGENEOUS_SPLIT_OUT bit was set, and on our boards where the
patch is needed only the BYTE_SPLIT_OUT_MIX is set in the
current_byte_status variable
- this led me to the hypothesis that both cur_start_win[] and
cur_end_win[] should be subtracted only if BYTE_SPLIT_OUT_MIX bit is
set, the BYTE_HOMOGENEOUS_SPLIT_OUT bit shouldn't be considered at all
- this hypothesis also gains credibility when considering the commit
title ("fix SPLIT_OUT_MIX state decision")
Hopefully this will fix things without breaking anything else.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Chris Packham <judge.packham@gmail.com>
Before commit 4c289425752f ("mv_ddr: a38x: add support for ddr async
mode"), Asynchornous Mode was only used when the CPU Subsystem Clock
Options[4:0] field in the SAR1 register was set to value 0x13: CPU at
2 GHz and DDR at 933 MHz.
Then commit 4c289425752f ("mv_ddr: a38x: add support for ddr async
mode") added support for Asynchornous Modes with frequencies other than
933 MHz (but at least 467 MHz), but the code it added to check for
whether Asynchornous Mode should be used is wrong: it checks whether the
frequency setting in board DDR topology map is set to value other than
MV_DDR_FREQ_SAR.
Thus boards which define a specific value, greater than 400 MHz, for DDR
frequency in their board topology (e.g. Turris Omnia defines
MV_DDR_FREQ_800), are incorrectly put into Asynchornous Mode after that
commit.
The A38x Functional Specification, section 10.12 DRAM Clocking, says:
In Synchornous mode, the DRAM and CPU clocks are edge aligned and run
in 1:2 or 1:3 CPU to DRAM frequency ratios.
Change the check for whether Asynchornous Mode should be used according
to this explanation in Functional Specification.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
No functional change intended. This patch switches from the legacy I2C
API to the DM I2C API, so that this code can be used with DM I2C
enabled.
Signed-off-by: Stefan Roese <sr@denx.de>
This converts the following to Kconfig:
CONFIG_SYS_BR0_PRELIM
CONFIG_SYS_OR1_PRELIM
CONFIG_SYS_BR1_PRELIM
CONFIG_SYS_OR2_PRELIM
CONFIG_SYS_BR2_PRELIM
CONFIG_SYS_OR2_PRELIM
CONFIG_SYS_BR3_PRELIM
CONFIG_SYS_OR3_PRELIM
CONFIG_SYS_BR4_PRELIM
CONFIG_SYS_OR4_PRELIM
CONFIG_SYS_BR5_PRELIM
CONFIG_SYS_OR5_PRELIM
CONFIG_SYS_BR6_PRELIM
CONFIG_SYS_OR6_PRELIM
CONFIG_SYS_BR7_PRELIM
CONFIG_SYS_OR7_PRELIM
This also introduces CONFIG_SYS_BR0_PRELIM_BOOL as not all platforms
that can set these values do so. Add the relevant SYS_BRx_PRELIM_BOOL
to platforms that had not been previously migrated.
Signed-off-by: Tom Rini <trini@konsulko.com>
Adds check for memory clock variable before calculating caslat_actual.
Set mclk_ps to slowest DIMM supported if mclk_ps is found zero.
Signed-off-by: Maninder Singh <maninder.singh_1@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Fix Bad Shift operator issue in step_to_string function
by adding an if check
Signed-off-by: Priyanka Singh <priyanka.singh@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Fix possible divide by zero issue in fsl_ddr_set_memctl_regs
by adding an if check
Signed-off-by: Priyanka Singh <priyanka.singh@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Fix possible divide by zero issue in get_memory_clk_period_ps
by adding a check
Signed-off-by: Priyanka Singh <priyanka.singh@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
The KBUILD_BASENAME contains just the name of the compiled module,
in this case 'sequencer', rather than a full path to the compiled
file. Use it to prevent pulling the full path into the U-Boot binary,
which is useless and annoying.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Siew Chin Lim <elly.siew.chin.lim@intel.com>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tien Fong Chee <tien.fong.chee@intel.com>
- Guard most of the options in drivers/ddr/fsl/Kconfig with
SYS_FSL_DDR || SYS_FSL_MMDC.
- Migrate FSL_DMA, DDR_ECC, DDR_ECC_CMD, and ECC_INIT_VIA_DDRCONTROLLER
to Kconfig.
- Clean up the logic for including the DDR_ECC_CMD code.
Signed-off-by: Tom Rini <trini@konsulko.com>
As this symbol can either be a fixed value or the function
get_board_ddr_clk, migration is tricky. Introduce a choice of DYNAMIC
or STATIC_DDR_CLK_FREQ. If DYNAMIC, we continue to use the board
defined get_board_ddr_clk function. If STATIC, set CONFIG_DDR_CLK_FREQ
to that value and now include/clock_legacy.h contains the function
prototype or defines get_board_ddr_clk() to that static value. Update
callers to test for DYNAMIC or STATIC.
Signed-off-by: Tom Rini <trini@konsulko.com>
Move the symbol that controls building some JEDEC SPD support functions
to Kconfig. This is required on the TI keystone 2 platforms and very
frequently (but not always) used on large number of Freescale/NXP
platforms, so use imply there.
Signed-off-by: Tom Rini <trini@konsulko.com>
We have a number of CONFIG symbols to express the fixed size of system
memory. For now, rename CONFIG_DDR_FIXED_SIZE to CONFIG_SYS_SDRAM_SIZE
and adjust usage to match that CONFIG_SYS_SDRAM_SIZE expects the entire
size rather than MiB.
Cc: Marek Behún <marek.behun@nic.cz>
Cc: Stefan Roese <sr@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Marek Behún <marek.behun@nic.cz>
The DDR subsystem in Diamond Mesa is consisted of controller, PHY,
memory reset manager and memory clock manager.
Configuration settings of controller, PHY and memory reset manager
is come from DDR handoff data in bitstream, which contain the register
base addresses and user settings from tool.
Configuration settings of memory clock manager is come from the HPS
handoff data in bitstream, however the register base address is defined
in device tree.
The calibration is fully done in HPS, which requires IMEM and DMEM
binaries loading to PHY SRAM for running this calibration, both
IMEM and DMEM binaries are also part of bitstream, this bitstream
would be loaded to OCRAM by SDM, and configured by DDR driver.
Signed-off-by: Siew Chin Lim <elly.siew.chin.lim@intel.com>
Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Minimum 1GB memory size is required in current memory test, so this patch
improves the memory test for processing memory size less than 1GB, and
the size in power of two.
Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Add iMX8ULP DDR initialization driver which loads the DDR timing
parameters and executes the training procedure.
When enabling IMX8ULP_DRAM_PHY_PLL_BYPASS, using PHY PLL bypass mode
to do DDR init
Signed-off-by: Ye Li <ye.li@nxp.com>
This board has not been converted to CONFIG_DM_PCI by the deadline and is
also missing conversion to CONFIG_DM. Remove it. As this is the last
ARCH_T4160 platform, remove that support as well.
Signed-off-by: Tom Rini <trini@konsulko.com>
This board has not been converted to CONFIG_DM_PCI by the deadline and is
also missing conversion to CONFIG_DM. Remove it. This is also the last
of the ARCH_MPC8641/MPC8610 platforms, so remove that support as well.
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
These boards have not been converted to CONFIG_DM_PCI by the deadline and is
also missing conversion to CONFIG_DM. Remove them. As this includes
the last ARCH_MPC8572 platform, remove that as well.
Cc: Peter Tyser <ptyser@xes-inc.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Peter Tyser <ptyser@xes-inc.com>
These boards have not been converted to CONFIG_DM_PCI by the deadline and is
also missing conversion to CONFIG_DM. Remove them. As this is the only
ARCH_MPC8555 platform left, remove that support as well.
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
This board has not been converted to CONFIG_DM_PCI by the deadline and is
also missing conversion to CONFIG_DM. Remove it. As this is the only
MPC8541 target left, remove that architecture support as well.
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
With gcc-11 we see:
drivers/ddr/marvell/a38x/ddr3_debug.c:672:47: error: argument 2 of type 'u32[5]' {aka 'unsigned int[5]'} with mismatched bound [-Werror=array-parameter=]
672 | int ddr3_tip_read_adll_value(u32 dev_num, u32 pup_values[MAX_INTERFACE_NUM * MAX_BUS_NUM],
| ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/ddr/marvell/a38x/ddr3_training_ip_engine.h:10,
from drivers/ddr/marvell/a38x/ddr3_init.h:17,
from drivers/ddr/marvell/a38x/ddr3_debug.c:6:
drivers/ddr/marvell/a38x/ddr3_training_ip_flow.h:116:47: note: previously declared as 'u32[]' {aka 'unsigned int[]'}
And similar warnings. Correct these by updating the prototype. Remove
the prototype for ddr3_tip_read_pup_value as it is unused.
Signed-off-by: Tom Rini <trini@konsulko.com>
These boards have not been converted to CONFIG_DM_MMC by the deadline.
Remove them. As the P5020 is the last ARCH_P5020 platform, remove that
support as well.
Cc: Andy Fleming <afleming@gmail.com>
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
VDD SOC normal run changed to 0.85V
LPDDR4 freq0 change from 4000MTS to 2400MTS
Signed-off-by: haidong.zheng <haidong.zheng@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Config option ARMADA_39X is never set so remove all dead code hidden under
ifdef CONFIG_ARMADA_39X blocks.
Also remove useless checks for CONFIG_ARMADA_38X define as this macro is
always defined for a38x code path.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
The arrays `pbs_dq_mapping`, `div_ratio1to1` and `div_ratio2to1` have
different bounds declared in header files where these variables are also
defined from the ones declared in source files.
This causes the compiler to complain (when building with LTO):
ddr3_sdram.c:24:12: warning: type of ‘pbs_dq_mapping’ does not match
original declaration
[-Wlto-type-mismatch]
ddr3_patterns_64bit.h:911:5: note: array types have different bounds
ddr3_patterns_64bit.h:911:5: note: ‘pbs_dq_mapping’ was previously
declared here
ddr3_dfs.c:45:11: warning: type of ‘div_ratio1to1’ does not match
original declaration [-Wlto-type-mismatch]
ddr3_axp_vars.h:167:4: note: array types have different bounds
ddr3_axp_vars.h:167:4: note: ‘div_ratio1to1’ was previously declared
here
ddr3_dfs.c:46:11: warning: type of ‘div_ratio2to1’ does not match
original declaration [-Wlto-type-mismatch]
ddr3_axp_vars.h:196:4: note: array types have different bounds
ddr3_axp_vars.h:196:4: note: ‘div_ratio2to1’ was previously declared
here
CI managed to trigger this as an error when compiling with LTO for AXP.
Fix this by using values from the header files, which seem to be the
correct ones.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
In arch/arm/mach-mvebu/dram.c we always include axp's xor.h for common
XOR definitions, regardless whether we compile for axp or a38x.
But the declaration of this function has a different signature in axp's
xor.h from the one used in a38x' implementation - one parameter is u64
instead of u32. This can result in wrong argument's being passed to that
function on a38x with no one the wiser.
I discovered this when building U-Boot for Turris Omnia with LTO. The
compiler complains about the different signatures being thrown into the
same linking process:
axp/xor.h:67:5: warning: type of ‘mv_xor_mem_init’ does not match
original declaration [-Wlto-type-mismatch]
67 | int mv_xor_mem_init(u32 chan, u32 start_ptr, u32 block_size,
| ^
a38x/xor.c:165:5: note: type mismatch in parameter 3
165 | int mv_xor_mem_init(u32 chan, u32 start_ptr, unsigned long long
| ^
a38x/xor.c:165:5: note: type ‘long long unsigned int’ should match
type ‘u32’
Fix this by changing the type of the block_size argument in the axp's
implementation and header file to the one used in a38x (and upstream
mv-ddr-marvell).
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
This syncs drivers/ddr/marvell/a38x/ with the master branch of repository
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git up to the
commit 7c351731d196 ("Merge pull request #29 from pali/sync-a38x-uboot").
This patch was created by following steps:
1. Replace all a38x files in U-Boot tree by files from upstream github
Marvell mv-ddr-marvell repository.
2. Run following command to omit portions not relevant for a38x and ddr3:
files=drivers/ddr/marvell/a38x/*
sed 's/#if defined(CONFIG_ARMADA_38X) || defined(CONFIG_ARMADA_39X)/#ifdef TRUE/' -i $files
unifdef -m -UMV_DDR -UMV_DDR_ATF -UCONFIG_DDR4 -UCONFIG_APN806 \
-UCONFIG_MC_STATIC -UCONFIG_MC_STATIC_PRINT -UCONFIG_PHY_STATIC \
-UCONFIG_PHY_STATIC_PRINT -UCONFIG_CUSTOMER_BOARD_SUPPORT \
-UCONFIG_A3700 -UA3900 -UA80X0 -UA70X0 -DTRUE $files
3. Manually omit SPDX-License-Identifier changes from this patch as
upstream license in upstream github repository contains long license
texts and U-Boot is using just SPDX-License-Identifier.
After applying this patch, a38x ddr3 code in upstream Marvell github
repository and in U-Boot would be fully identical. So in future applying
above steps could be used to sync code again.
The only change in this patch is removal of dead code and some fixes with
include files.
Signed-off-by: Pali Rohár <pali@kernel.org>
Tested-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
commit 258be123226f8f5cd516b7813fe201fb7d7416e9 upstream.
At this moment, only page 0 of SPD is being read but to support
smbios, we need to read page 1 also which has more info. In order
to do that, we need to allocate more space.
Signed-off-by: Sujeet Baranwal <sujeet.baranwal@cavium.com>
Tested-by: sa_ip-sw-jenkins <sa_ip-sw-jenkins@marvell.com>
Reviewed-by: Sujeet Kumar Baranwal <Sujeet.Baranwal@cavium.com>
Reviewed-by: Nadav Haklai <nadavh@marvell.com>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Chris Packham <judge.packham@gmail.com>
The code was processed with unifdef utility to omit portions not
relevant to A38x and DDR3. This removes usage of many macros, including
A70X0, A80X0 and A3900. It seems that the unifdef utility did not remove
the macros from #else comment.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Bump version of a38x DDR3 trianing to version 14.0.0 to reflect the
version in the mv-ddr-devel branch of upstream repository
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git.
There is a new version numbering system, where after 18.12.0 came
1.0.0, 2.0.0, and so on until 14.0.0. So 14.0.0 is newer than 18.12.0.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
commit 56db5d1464b44df10a02b99e615ebd6f6a35c428 upstream.
@pali suggested this change
In commit 6285efb ("mv_ddr: add support for twin-die combined memory
device") was added support for twin-die combined memory device and
default value for explicitly uninitialized structure members is zero, s
also twin_die_combined is initialized to zero. Which means COMBINED
value.
As prior this commit there was no support for twin-die combined memory
device, default value for twin_die_combined should be NOT_COMBINED. This
change change order of enum mv_ddr_twin_die to ensure that NOT_COMBINED
has value zero.
Signed-off-by: heaterC <airyguy@gmx.de>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
commit 2bdd12dd68b1f8e27a03a3443ae49a09a14c18e4 upstream.
The commit mentioned above changes non-DDR3 stuff in upstream, but it
also changes code in ddr3_training.c.
Import this change to remain consistent with upstream.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
commit c8b301463d508c807a33f7b7eaea98bbda4aa35e upstream.
The funtion returnd cs size in byte instead of MB, that cause
calculation error since the caller was expected to get u32 and when he
got above 4G it refers it as 0.
The fix was to get the cs memory size from function as in MB and then
multiply it by 1MB.
Signed-off-by: Moti Buskila <motib@marvell.com>
Reviewed-by: Kostya Porotchkin <kostap@marvell.com>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
