Tony Lindgren's "LC15: Fix flakey ddr3 detection with ref_ctrl and ref_ctrl_final" assumes that 802bb57a584d also affects OMAP5 but it doesn't, which means slower out-of-spec refresh rate is left at the end and .ref_ctrl_final is never written. Let's write it out.
It is also good idea to set EMIF_REG_INITREF_DIS_MASK (like dra7 code does) because otherwise a write to TIMING1 will start initialization sequence (as documentation states) before other registers are programmed.
Tested on 2GB and 4GB boards.
Signed-off-by: Grazvydas Ignotas notasas@gmail.com --- arch/arm/cpu/armv7/omap-common/emif-common.c | 14 ++++++++------ arch/arm/cpu/armv7/omap5/sdram.c | 5 +++++ 2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c b/arch/arm/cpu/armv7/omap-common/emif-common.c index 912db800ad..f43609103d 100644 --- a/arch/arm/cpu/armv7/omap-common/emif-common.c +++ b/arch/arm/cpu/armv7/omap-common/emif-common.c @@ -176,10 +176,7 @@ void emif_update_timings(u32 base, const struct emif_regs *regs) { struct emif_reg_struct *emif = (struct emif_reg_struct *)base;
- if (!is_dra7xx()) - writel(regs->ref_ctrl, &emif->emif_sdram_ref_ctrl_shdw); - else - writel(regs->ref_ctrl_final, &emif->emif_sdram_ref_ctrl_shdw); + writel(regs->ref_ctrl_final, &emif->emif_sdram_ref_ctrl_shdw);
writel(regs->sdram_tim1, &emif->emif_sdram_tim_1_shdw); writel(regs->sdram_tim2, &emif->emif_sdram_tim_2_shdw); @@ -387,7 +384,8 @@ static void omap5_ddr3_init(u32 base, const struct emif_regs *regs) { struct emif_reg_struct *emif = (struct emif_reg_struct *)base;
- writel(regs->ref_ctrl, &emif->emif_sdram_ref_ctrl); + writel(regs->ref_ctrl | EMIF_REG_INITREF_DIS_MASK, + &emif->emif_sdram_ref_ctrl); writel(regs->sdram_config_init, &emif->emif_sdram_config); /* * Set SDRAM_CONFIG and PHY control registers to locked frequency @@ -403,12 +401,16 @@ static void omap5_ddr3_init(u32 base, const struct emif_regs *regs) writel(regs->sdram_tim3, &emif->emif_sdram_tim_3);
writel(regs->read_idle_ctrl, &emif->emif_read_idlectrl); + writel(regs->emif_rd_wr_lvl_rmp_ctl, &emif->emif_rd_wr_lvl_rmp_ctl);
+ writel(regs->ref_ctrl, &emif->emif_sdram_ref_ctrl); writel(regs->sdram_config2, &emif->emif_lpddr2_nvm_config); writel(regs->sdram_config_init, &emif->emif_sdram_config); do_ext_phy_settings(base, regs);
- writel(regs->emif_rd_wr_lvl_rmp_ctl, &emif->emif_rd_wr_lvl_rmp_ctl); + __udelay(1000); + writel(regs->ref_ctrl_final, &emif->emif_sdram_ref_ctrl); + omap5_ddr3_leveling(base, regs); }
diff --git a/arch/arm/cpu/armv7/omap5/sdram.c b/arch/arm/cpu/armv7/omap5/sdram.c index 684467cb5f..bd86b0d9cb 100644 --- a/arch/arm/cpu/armv7/omap5/sdram.c +++ b/arch/arm/cpu/armv7/omap5/sdram.c @@ -36,6 +36,7 @@ const struct emif_regs emif_regs_532_mhz_2cs = { .sdram_config_init = 0x80800EBA, .sdram_config = 0x808022BA, .ref_ctrl = 0x0000081A, + .ref_ctrl_final = 0x0000081A, .sdram_tim1 = 0x772F6873, .sdram_tim2 = 0x304a129a, .sdram_tim3 = 0x02f7e45f, @@ -55,6 +56,7 @@ const struct emif_regs emif_regs_532_mhz_2cs_es2 = { .sdram_config_init = 0x80800EBA, .sdram_config = 0x808022BA, .ref_ctrl = 0x0000081A, + .ref_ctrl_final = 0x0000081A, .sdram_tim1 = 0x772F6873, .sdram_tim2 = 0x304a129a, .sdram_tim3 = 0x02f7e45f, @@ -74,6 +76,7 @@ const struct emif_regs emif_regs_266_mhz_2cs = { .sdram_config_init = 0x80800EBA, .sdram_config = 0x808022BA, .ref_ctrl = 0x0000040D, + .ref_ctrl_final = 0x0000040D, .sdram_tim1 = 0x2A86B419, .sdram_tim2 = 0x1025094A, .sdram_tim3 = 0x026BA22F, @@ -94,6 +97,7 @@ const struct emif_regs emif_regs_ddr3_532_mhz_1cs = { .sdram_config = 0x61851B32, .sdram_config2 = 0x0, .ref_ctrl = 0x00001035, + .ref_ctrl_final = 0x00001035, .sdram_tim1 = 0xCCCF36B3, .sdram_tim2 = 0x308F7FDA, .sdram_tim3 = 0x027F88A8, @@ -118,6 +122,7 @@ const struct emif_regs emif_regs_ddr3_532_mhz_1cs_es2 = { .sdram_config = 0x61851B32, .sdram_config2 = 0x0, .ref_ctrl = 0x00001035, + .ref_ctrl_final = 0x00001035, .sdram_tim1 = 0xCCCF36B3, .sdram_tim2 = 0x308F7FDA, .sdram_tim3 = 0x027F88A8,
Should be much easier to compare against the datasheet. No actual register changes introduced by this change.
Partially based on IGEPv5 u-boot: https://git.isee.biz/arm-boot/u-boot-arm/blob/u-boot-2014.01.y-omap5/board/i...
Signed-off-by: Grazvydas Ignotas notasas@gmail.com --- board/goldelico/letux-cortex15/lc15.c | 43 +++++++++++++++++++++++++-- 1 file changed, 40 insertions(+), 3 deletions(-)
diff --git a/board/goldelico/letux-cortex15/lc15.c b/board/goldelico/letux-cortex15/lc15.c index fdf4a67198..a618ab4095 100644 --- a/board/goldelico/letux-cortex15/lc15.c +++ b/board/goldelico/letux-cortex15/lc15.c @@ -36,15 +36,52 @@ const struct omap_sysinfo sysinfo = { * NOTE: please run a kernel with LPAE enabled to make use of the 4GB RAM! */
+/* Register sdram_tim1 = EMIF_SDRAM_TIMMING_1 (0x4C000018) */ +#define T_RTW 7 /* between Read to Write data phases.*/ +#define T_RP 7 /* Precharge to Activate or Refresh. */ +#define T_RCD 7 /* Activate to Read or Write. */ +#define T_WR 8 /* last Write transfer to Precharge. */ +#define T_RAS 20 /* Activate to Precharge. >= T_RCD value */ +#define T_RC 27 /* Activate to Activate. */ +#define T_RRD 7 /* Activate to Activate for a different bank. For an 8-bank, ((tFAW / (4 × tCK)) - 1) */ +#define T_WTR 4 /* last Write to Read. */ +#define T_SDRAM_TIM1 \ + ((T_RTW-1) << 29) | ((T_RP-1) << 25) | ((T_RCD-1) << 21) | ((T_WR-1) << 17) \ + | ((T_RAS-1) << 12) | ((T_RC-1) << 6) | ((T_RRD-1) << 3) | ((T_WTR-1)) + +/* Register sdram_tim2 = EMIF_SDRAM_TIMMING_2 (0x4C000020) */ +#define T_XP 4 /* from power-down exit to any command other than a read command */ +#define T_ODT 0 /* from ODT enable to write data driven for DDR3. Must be equal to tAONPD */ +#define T_XSNR 144 /* from Self-Refresh exit to any command other than a Read command. For DDR3, the value of tXS must be programmed. */ +#define T_XSRD 512 /* from Self-Refresh exit to a Read command. For DDR3, the value of tXSDLL must be programmed. */ +#define T_RTP 4 /* for the last read command to a Precharge command */ +#define T_CKE 3 /* between CKE pin changes */ +#define T_SDRAM_TIM2 \ + ((T_XP-1) << 28) | (T_ODT << 25) | ((T_XSNR-1) << 16) | ((T_XSRD-1) << 6) \ + | ((T_RTP-1) << 3) | (T_CKE-1) + +/* Register sdram_tim3 = EMIF_SDRAM_TIMMING_3 (0x4C000028) */ +#define T_PDLL_UL 0 /* cycles for PHY DLL to unlock. A value of N will be equal to N x 128 clocks */ +#define T_CSTA 3 /* between write-to-write or read-to-read data phases to different chip selects. */ +#define T_CKESR 4 /* cycles for which SDRAM must remain in Self Refresh */ +#define T_ZQ_ZQCS 64 /* cycles for a ZQCS command. */ +#define T_TDQSCKMAX 1 /* clock that satisfies tDQSCKmax for LPDDR2. */ +#define T_RFC 191 /* DDR clock cycles from Refresh or Load Mode to Refresh or Activate.*/ +#define T_RAS_MAX 8 /* Maximum number of REFRESH_RATE intervals from Activate to Precharge command */ +#define T_SDRAM_TIM3 \ + (T_PDLL_UL << 28) | ((T_CSTA-1) << 24) | ((T_CKESR-1) << 21) \ + | ((T_ZQ_ZQCS-1) << 15) | ((T_TDQSCKMAX-1) << 13) | ((T_RFC-1) << 4) | T_RAS_MAX + + const struct emif_regs emif_regs_ddr3_532_mhz_2cs_es2 = { .sdram_config_init = 0x61851B3A, .sdram_config = 0x61851B3A, .sdram_config2 = 0x0, .ref_ctrl = 0x000040F1, .ref_ctrl_final = 0x00001035, - .sdram_tim1 = 0xCCCF36B3, - .sdram_tim2 = 0x308F7FDA, - .sdram_tim3 = 0x027F8BE8, + .sdram_tim1 = T_SDRAM_TIM1, + .sdram_tim2 = T_SDRAM_TIM2, + .sdram_tim3 = T_SDRAM_TIM3, .read_idle_ctrl = 0x00050000, .zq_config = 0xD007190B, .temp_alert_config = 0x00000000,
The RAM datasheet states tXS must be tRFC + 10ns, and 10ns is 6 cycles in our case.
Signed-off-by: Grazvydas Ignotas notasas@gmail.com --- board/goldelico/letux-cortex15/lc15.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/goldelico/letux-cortex15/lc15.c b/board/goldelico/letux-cortex15/lc15.c index a618ab4095..4ac5ef8d0e 100644 --- a/board/goldelico/letux-cortex15/lc15.c +++ b/board/goldelico/letux-cortex15/lc15.c @@ -52,7 +52,7 @@ const struct omap_sysinfo sysinfo = { /* Register sdram_tim2 = EMIF_SDRAM_TIMMING_2 (0x4C000020) */ #define T_XP 4 /* from power-down exit to any command other than a read command */ #define T_ODT 0 /* from ODT enable to write data driven for DDR3. Must be equal to tAONPD */ -#define T_XSNR 144 /* from Self-Refresh exit to any command other than a Read command. For DDR3, the value of tXS must be programmed. */ +#define T_XSNR T_RFC+6 /* from Self-Refresh exit to any command other than a Read command. For DDR3, the value of tXS must be programmed. */ #define T_XSRD 512 /* from Self-Refresh exit to a Read command. For DDR3, the value of tXSDLL must be programmed. */ #define T_RTP 4 /* for the last read command to a Precharge command */ #define T_CKE 3 /* between CKE pin changes */
Issue found by Tony Lindgren.
Signed-off-by: Grazvydas Ignotas notasas@gmail.com --- board/goldelico/letux-cortex15/lc15.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/goldelico/letux-cortex15/lc15.c b/board/goldelico/letux-cortex15/lc15.c index 4ac5ef8d0e..4c435fb882 100644 --- a/board/goldelico/letux-cortex15/lc15.c +++ b/board/goldelico/letux-cortex15/lc15.c @@ -74,8 +74,8 @@ const struct omap_sysinfo sysinfo = {
const struct emif_regs emif_regs_ddr3_532_mhz_2cs_es2 = { - .sdram_config_init = 0x61851B3A, - .sdram_config = 0x61851B3A, + .sdram_config_init = 0x61851BBA, + .sdram_config = 0x61851BBA, .sdram_config2 = 0x0, .ref_ctrl = 0x000040F1, .ref_ctrl_final = 0x00001035,
* Grazvydas Ignotas notasas@gmail.com [181011 23:20]:
Tony Lindgren's "LC15: Fix flakey ddr3 detection with ref_ctrl and ref_ctrl_final" assumes that 802bb57a584d also affects OMAP5 but it doesn't, which means slower out-of-spec refresh rate is left at the end and .ref_ctrl_final is never written. Let's write it out.
Oh this is a good catch, it means we've been running the memory at a way higher refresh rate than we should need to. It is also interesting that this seems to be somewhat related to the self-refresh?
This change works for me only work if EMIF_POWER_MANAGEMENT_CONTROL is disabled based on few quick experiments, so I wonder what's the relationship with higher non-standard values of EMIF_SDRAM_REFRESH_CONTROL REFRESH_RATE and self-refresh?
Regards,
Tony
On Sat, Oct 13, 2018 at 6:45 PM Tony Lindgren tony@atomide.com wrote:
- Grazvydas Ignotas notasas@gmail.com [181011 23:20]:
Tony Lindgren's "LC15: Fix flakey ddr3 detection with ref_ctrl and ref_ctrl_final" assumes that 802bb57a584d also affects OMAP5 but it doesn't, which means slower out-of-spec refresh rate is left at the end and .ref_ctrl_final is never written. Let's write it out.
Oh this is a good catch, it means we've been running the memory at a way higher refresh rate than we should need to. It is also interesting that this seems to be somewhat related to the self-refresh?
This change works for me only work if EMIF_POWER_MANAGEMENT_CONTROL is disabled based on few quick experiments, so I wonder what's the relationship with higher non-standard values of EMIF_SDRAM_REFRESH_CONTROL REFRESH_RATE and self-refresh?
Well as far as I understand that field is a delay, so larger values mean it's refreshed less often = lower refresh rate. But I've noticed TRM's 15.3.4.6 states that only 13 LSB bits are used, so with that 0x40F1 becomes 0xF1, a very short period, meaning EMIF's refresh backlog will often be long. Because before entering self-refresh EMIF clears normal refresh backlog (15.3.4.4.3), it takes a lot longer until it actually does the self-refresh command and it becomes likely some actual work will arrive and self-refresh will be cancelled (I guess). With reduced number of self-refresh attempts you get some stability improvement.
It's a bit guesses/speculation but I think it explains things you see.
Gražvydas
* Grazvydas Ignotas notasas@gmail.com [181013 16:57]:
On Sat, Oct 13, 2018 at 6:45 PM Tony Lindgren tony@atomide.com wrote:
- Grazvydas Ignotas notasas@gmail.com [181011 23:20]:
Tony Lindgren's "LC15: Fix flakey ddr3 detection with ref_ctrl and ref_ctrl_final" assumes that 802bb57a584d also affects OMAP5 but it doesn't, which means slower out-of-spec refresh rate is left at the end and .ref_ctrl_final is never written. Let's write it out.
Oh this is a good catch, it means we've been running the memory at a way higher refresh rate than we should need to. It is also interesting that this seems to be somewhat related to the self-refresh?
This change works for me only work if EMIF_POWER_MANAGEMENT_CONTROL is disabled based on few quick experiments, so I wonder what's the relationship with higher non-standard values of EMIF_SDRAM_REFRESH_CONTROL REFRESH_RATE and self-refresh?
Well as far as I understand that field is a delay, so larger values mean it's refreshed less often = lower refresh rate. But I've noticed TRM's 15.3.4.6 states that only 13 LSB bits are used, so with that 0x40F1 becomes 0xF1, a very short period, meaning EMIF's refresh backlog will often be long. Because before entering self-refresh EMIF clears normal refresh backlog (15.3.4.4.3), it takes a lot longer until it actually does the self-refresh command and it becomes likely some actual work will arrive and self-refresh will be cancelled (I guess). With reduced number of self-refresh attempts you get some stability improvement.
It's a bit guesses/speculation but I think it explains things you see.
Yes OK makes sense to me. So I guess the conclusion is that broken self-refresh is the core problem we have somewhere. And using a non-standard refresh rate or disabling the internal dll just both happen to prevent memory from hitting self-refresh hiding the problem.
Regards,
Tony
* Tony Lindgren tony@atomide.com [181014 16:12]:
- Grazvydas Ignotas notasas@gmail.com [181013 16:57]:
On Sat, Oct 13, 2018 at 6:45 PM Tony Lindgren tony@atomide.com wrote:
- Grazvydas Ignotas notasas@gmail.com [181011 23:20]:
Tony Lindgren's "LC15: Fix flakey ddr3 detection with ref_ctrl and ref_ctrl_final" assumes that 802bb57a584d also affects OMAP5 but it doesn't, which means slower out-of-spec refresh rate is left at the end and .ref_ctrl_final is never written. Let's write it out.
Oh this is a good catch, it means we've been running the memory at a way higher refresh rate than we should need to. It is also interesting that this seems to be somewhat related to the self-refresh?
This change works for me only work if EMIF_POWER_MANAGEMENT_CONTROL is disabled based on few quick experiments, so I wonder what's the relationship with higher non-standard values of EMIF_SDRAM_REFRESH_CONTROL REFRESH_RATE and self-refresh?
Well as far as I understand that field is a delay, so larger values mean it's refreshed less often = lower refresh rate. But I've noticed TRM's 15.3.4.6 states that only 13 LSB bits are used, so with that 0x40F1 becomes 0xF1, a very short period, meaning EMIF's refresh backlog will often be long. Because before entering self-refresh EMIF clears normal refresh backlog (15.3.4.4.3), it takes a lot longer until it actually does the self-refresh command and it becomes likely some actual work will arrive and self-refresh will be cancelled (I guess). With reduced number of self-refresh attempts you get some stability improvement.
It's a bit guesses/speculation but I think it explains things you see.
Yes OK makes sense to me. So I guess the conclusion is that broken self-refresh is the core problem we have somewhere. And using a non-standard refresh rate or disabling the internal dll just both happen to prevent memory from hitting self-refresh hiding the problem.
Looks like the individual memory chips work just fine with datasheet tRFC 187 if mapped one at a time with a single .dmm_lisa_map_ entry. Also self-refresh works then just fine with timer set to 9.
Trying to map something from both emif instances with two .dmm_lisa_map_ entries with or without interleaving makes the tRFC need to go up to around 230 cycles and self-refresh test will hang.
I wonder if some of the ddr3 control signals could be crossed, or if some control signals need to be left out for emif2?
Or could it just be that there is still some power or impedance issue with both emif in use that affects tRFC and self-refresh?
Obviously the address and data lines work fine as tested with memtester earlier :)
Test patch below that just maps 1GB from the end of emif2 if somebody wants to play with it. To test individual chips, just keep one .dmm_lisa_map_ line enabled at a time.
Regards,
Tony
8< --------------------- diff --git a/board/goldelico/letux-cortex15/lc15.c b/board/goldelico/letux-cortex15/lc15.c --- a/board/goldelico/letux-cortex15/lc15.c +++ b/board/goldelico/letux-cortex15/lc15.c @@ -103,6 +103,23 @@ void emif_get_reg_dump(u32 emif_nr, const struct emif_regs **regs) *regs = &emif_regs_ddr3_532_mhz_2cs_es2; }
+#define CONFIG_DRAM_1G +#if defined(CONFIG_DRAM_1G) +const struct dmm_lisa_map_regs lisa_map_cm_pyra = { + //.dmm_lisa_map_0 = 0x80600100, + //.dmm_lisa_map_1 = 0x80600140, + //.dmm_lisa_map_2 = 0x80600200, + .dmm_lisa_map_3 = 0x80600240, + .is_ma_present = 0x1, +}; + +void emif_get_dmm_regs(const struct dmm_lisa_map_regs **dmm_lisa_regs) +{ + *dmm_lisa_regs = &lisa_map_cm_pyra; +} +#endif + +#if !defined(CONFIG_DRAM_1G) void dram_init_banksize(void) { /* make U-Boot pass the same as bootarg "mem=2032M@0x80000000 mem=2048M@0x200000000" would do */ gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE; // == 0x80000000 @@ -116,6 +133,7 @@ void dram_init_banksize(void) /* report 4 GB during boot */ gd->ram_size = gd->bd->bi_dram[0].size + gd->bd->bi_dram[1].size; } +#endif /* CONFIG_DRAM_1G */ #endif
/*
* Tony Lindgren tony@atomide.com [181016 18:04]:
I wonder if some of the ddr3 control signals could be crossed, or if some control signals need to be left out for emif2?
So here I'm thinking TRM "Figure 15-46. EMIF DDR3 Generic Configuration" that shows the lines that should be different for each die:
CK NCK ODT CKE NCS
So each emif has two chips with each chip having two dies. To me it seems Figure 15-46 matches how it should be?
So the signals listed above should be selectively connected for each chip in the emif and not to both chips on the emif?
Regards,
Tony
Hi Tony,
Am 16.10.2018 um 20:19 schrieb Tony Lindgren tony@atomide.com:
- Tony Lindgren tony@atomide.com [181016 18:04]:
I wonder if some of the ddr3 control signals could be crossed, or if some control signals need to be left out for emif2?
So here I'm thinking TRM "Figure 15-46. EMIF DDR3 Generic Configuration"
in my TRM (Version Y) there is Figure 16-48. EMIF DDR3 Generic Configuration.
that shows the lines that should be different for each die:
CK NCK ODT CKE NCS
So each emif has two chips with each chip having two dies. To me it seems Figure 15-46 matches how it should be?
Yes.
So the signals listed above should be selectively connected for each chip in the emif and not to both chips on the emif?
I have checked the schematics and there are for each dual-die chip:
CK (common to both dies) NCK (common to both dies) ODT0, ODT1 (individual for each die) CKE0, CKE1 (individual for each die) NCS0, NCS1 (individual for each die)
Which means both dies share the same clock but have the other controls separately.
EMIF provides CKA, NCKA, CKB and NCKB. The first two are connected to CK, NCK and the other two are not connected. We can't connect (N)CKB anywhere because the dual-die chips have no separate clock inputs...
This would mean the EMIF must be programmed in a way that takes care of this shared clocks...
Hm. Could it be that the configuration assumes clka and clkb being enabled/disabled separately for self-refresh. And then for example clka is stopped? Which also stops the clock of cke1 die which isn't expected by the EMIF?
BR, Nikolaus
* H. Nikolaus Schaller hns@goldelico.com [181016 19:25]:
Hi Tony,
Am 16.10.2018 um 20:19 schrieb Tony Lindgren tony@atomide.com:
- Tony Lindgren tony@atomide.com [181016 18:04]:
I wonder if some of the ddr3 control signals could be crossed, or if some control signals need to be left out for emif2?
So here I'm thinking TRM "Figure 15-46. EMIF DDR3 Generic Configuration"
in my TRM (Version Y) there is Figure 16-48. EMIF DDR3 Generic Configuration.
that shows the lines that should be different for each die:
CK NCK ODT CKE NCS
So each emif has two chips with each chip having two dies. To me it seems Figure 15-46 matches how it should be?
Yes.
So the signals listed above should be selectively connected for each chip in the emif and not to both chips on the emif?
I have checked the schematics and there are for each dual-die chip:
CK (common to both dies) NCK (common to both dies) ODT0, ODT1 (individual for each die) CKE0, CKE1 (individual for each die) NCS0, NCS1 (individual for each die)
Which means both dies share the same clock but have the other controls separately.
EMIF provides CKA, NCKA, CKB and NCKB. The first two are connected to CK, NCK and the other two are not connected. We can't connect (N)CKB anywhere because the dual-die chips have no separate clock inputs...
Well looking at the Pyra schematics to me it seems that for example on emif1 cke0 and cke1 are both connected to U3401 and U3402. To me it seems U3401 should only have cke0 and U3402 should have only cke1 (or the other way around) just as in "EMIF DDR3 Generic Configuration". And the same for the other used lines, and for emif2.
This would mean the EMIF must be programmed in a way that takes care of this shared clocks...
Hm. Could it be that the configuration assumes clka and clkb being enabled/disabled separately for self-refresh. And then for example clka is stopped? Which also stops the clock of cke1 die which isn't expected by the EMIF?
I'm guessing that taking a 1mm drill bit and drilling out CKE1 ball from U3401 and CKE0 U3402 ball slightly sideways might fix it if there is enough room around the ddr3 chips and somebody wants to try :)
Probably the NCS0 and 1 would need to be modified too.. And for all the four chips in a similar way.
Regards,
Tony
Hi Tony,
Am 17.10.2018 um 01:03 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [181016 19:25]:
Hi Tony,
Am 16.10.2018 um 20:19 schrieb Tony Lindgren tony@atomide.com:
- Tony Lindgren tony@atomide.com [181016 18:04]:
I wonder if some of the ddr3 control signals could be crossed, or if some control signals need to be left out for emif2?
So here I'm thinking TRM "Figure 15-46. EMIF DDR3 Generic Configuration"
in my TRM (Version Y) there is Figure 16-48. EMIF DDR3 Generic Configuration.
that shows the lines that should be different for each die:
CK NCK ODT CKE NCS
So each emif has two chips with each chip having two dies. To me it seems Figure 15-46 matches how it should be?
Yes.
So the signals listed above should be selectively connected for each chip in the emif and not to both chips on the emif?
I have checked the schematics and there are for each dual-die chip:
CK (common to both dies) NCK (common to both dies) ODT0, ODT1 (individual for each die) CKE0, CKE1 (individual for each die) NCS0, NCS1 (individual for each die)
Which means both dies share the same clock but have the other controls separately.
EMIF provides CKA, NCKA, CKB and NCKB. The first two are connected to CK, NCK and the other two are not connected. We can't connect (N)CKB anywhere because the dual-die chips have no separate clock inputs...
Well looking at the Pyra schematics to me it seems that for example on emif1 cke0 and cke1 are both connected to U3401 and U3402. To me it seems U3401 should only have cke0 and U3402 should have only cke1 (or the other way around) just as in "EMIF DDR3 Generic Configuration". And the same for the other used lines, and for emif2.
Are you sure with oyur idea?
U3401 is for 16 bits and U3402 for the other 16 bits of the 32 bit EMIF channel.
Both, U3401 and U3402 have two dies inside where one responds to ODT/CKE/NCS0 and the other to ODT/CKE/NCS1. So U3401 combines what is shown as "Die 1" and "Die 2" in the figure and U3402 combines "Die 3" and "Die 4". So ODT/CKE/NCS0 and ODT/CKE/NCS1 must be connected to a single U340x.
Cutting either would IMHO make half of the memory capacity unaccessible.
This would mean the EMIF must be programmed in a way that takes care of this shared clocks...
Hm. Could it be that the configuration assumes clka and clkb being enabled/disabled separately for self-refresh. And then for example clka is stopped? Which also stops the clock of cke1 die which isn't expected by the EMIF?
I'm guessing that taking a 1mm drill bit and drilling out CKE1 ball from U3401 and CKE0 U3402 ball slightly sideways might fix it if there is enough room around the ddr3 chips and somebody wants to try :)
Probably the NCS0 and 1 would need to be modified too.. And for all the four chips in a similar way.
Regards,
Tony
BR, Nikolaus
Am 17.10.2018 um 06:42 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Tony,
Am 17.10.2018 um 01:03 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [181016 19:25]:
Hi Tony,
Am 16.10.2018 um 20:19 schrieb Tony Lindgren tony@atomide.com:
- Tony Lindgren tony@atomide.com [181016 18:04]:
I wonder if some of the ddr3 control signals could be crossed, or if some control signals need to be left out for emif2?
So here I'm thinking TRM "Figure 15-46. EMIF DDR3 Generic Configuration"
in my TRM (Version Y) there is Figure 16-48. EMIF DDR3 Generic Configuration.
that shows the lines that should be different for each die:
CK NCK ODT CKE NCS
So each emif has two chips with each chip having two dies. To me it seems Figure 15-46 matches how it should be?
Yes.
So the signals listed above should be selectively connected for each chip in the emif and not to both chips on the emif?
I have checked the schematics and there are for each dual-die chip:
CK (common to both dies) NCK (common to both dies) ODT0, ODT1 (individual for each die) CKE0, CKE1 (individual for each die) NCS0, NCS1 (individual for each die)
Which means both dies share the same clock but have the other controls separately.
EMIF provides CKA, NCKA, CKB and NCKB. The first two are connected to CK, NCK and the other two are not connected. We can't connect (N)CKB anywhere because the dual-die chips have no separate clock inputs...
Well looking at the Pyra schematics to me it seems that for example on emif1 cke0 and cke1 are both connected to U3401 and U3402. To me it seems U3401 should only have cke0 and U3402 should have only cke1 (or the other way around) just as in "EMIF DDR3 Generic Configuration". And the same for the other used lines, and for emif2.
Are you sure with oyur idea?
U3401 is for 16 bits and U3402 for the other 16 bits of the 32 bit EMIF channel.
Both, U3401 and U3402 have two dies inside where one responds to ODT/CKE/NCS0 and the other to ODT/CKE/NCS1. So U3401 combines what is shown as "Die 1" and "Die 2" in the figure and U3402 combines "Die 3" and "Die 4". So ODT/CKE/NCS0 and ODT/CKE/NCS1 must be connected to a single U340x.
The only wiring difference I see is that we do CK(#) of "Die 2" to (N)CKA as well and not (N)CKB because they are not available separately in the MT41K256M16HA-125 package.
Cutting either would IMHO make half of the memory capacity unaccessible.
This would mean the EMIF must be programmed in a way that takes care of this shared clocks...
Hm. Could it be that the configuration assumes clka and clkb being enabled/disabled separately for self-refresh. And then for example clka is stopped? Which also stops the clock of cke1 die which isn't expected by the EMIF?
I'm guessing that taking a 1mm drill bit and drilling out CKE1 ball from U3401 and CKE0 U3402 ball slightly sideways might fix it if there is enough room around the ddr3 chips and somebody wants to try :)
Probably the NCS0 and 1 would need to be modified too.. And for all the four chips in a similar way.
Regards,
Tony
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
* H. Nikolaus Schaller hns@goldelico.com [181017 04:42]:
Am 17.10.2018 um 01:03 schrieb Tony Lindgren tony@atomide.com: Well looking at the Pyra schematics to me it seems that for example on emif1 cke0 and cke1 are both connected to U3401 and U3402. To me it seems U3401 should only have cke0 and U3402 should have only cke1 (or the other way around) just as in "EMIF DDR3 Generic Configuration". And the same for the other used lines, and for emif2.
Are you sure with oyur idea?
No :)
U3401 is for 16 bits and U3402 for the other 16 bits of the 32 bit EMIF channel.
Both, U3401 and U3402 have two dies inside where one responds to ODT/CKE/NCS0 and the other to ODT/CKE/NCS1. So U3401 combines what is shown as "Die 1" and "Die 2" in the figure and U3402 combines "Die 3" and "Die 4". So ODT/CKE/NCS0 and ODT/CKE/NCS1 must be connected to a single U340x.
Oh I thought U3401 would be "Die 1" and "Die 3" for chips connected to cs0. Yeah probably you're right and U3401 is "Die 1" and "Die 2", otherwise the ddr3 package would not even need separate balls for cke0 and cke1.
Cutting either would IMHO make half of the memory capacity unaccessible.
That would not be good..
Tony
Am 17.10.2018 um 07:13 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [181017 04:42]:
Am 17.10.2018 um 01:03 schrieb Tony Lindgren tony@atomide.com: Well looking at the Pyra schematics to me it seems that for example on emif1 cke0 and cke1 are both connected to U3401 and U3402. To me it seems U3401 should only have cke0 and U3402 should have only cke1 (or the other way around) just as in "EMIF DDR3 Generic Configuration". And the same for the other used lines, and for emif2.
Are you sure with oyur idea?
No :)
U3401 is for 16 bits and U3402 for the other 16 bits of the 32 bit EMIF channel.
Both, U3401 and U3402 have two dies inside where one responds to ODT/CKE/NCS0 and the other to ODT/CKE/NCS1. So U3401 combines what is shown as "Die 1" and "Die 2" in the figure and U3402 combines "Die 3" and "Die 4". So ODT/CKE/NCS0 and ODT/CKE/NCS1 must be connected to a single U340x.
Oh I thought U3401 would be "Die 1" and "Die 3" for chips connected to cs0. Yeah probably you're right and U3401 is "Die 1" and "Die 2", otherwise the ddr3 package would not even need separate balls for cke0 and cke1.
Cutting either would IMHO make half of the memory capacity unaccessible.
That would not be good..
Indeed. What I am really worried about is that I can't find any bit of information about the cka and ckb except that ckb is not used for LPDDR2...
Hm. I think there was an AN about DDR3 for OMAP5 which might have more information. I have to dig it out.
BR, Nikolaus
Am 17.10.2018 um 07:16 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 17.10.2018 um 07:13 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [181017 04:42]:
Am 17.10.2018 um 01:03 schrieb Tony Lindgren tony@atomide.com: Well looking at the Pyra schematics to me it seems that for example on emif1 cke0 and cke1 are both connected to U3401 and U3402. To me it seems U3401 should only have cke0 and U3402 should have only cke1 (or the other way around) just as in "EMIF DDR3 Generic Configuration". And the same for the other used lines, and for emif2.
Are you sure with oyur idea?
No :)
U3401 is for 16 bits and U3402 for the other 16 bits of the 32 bit EMIF channel.
Both, U3401 and U3402 have two dies inside where one responds to ODT/CKE/NCS0 and the other to ODT/CKE/NCS1. So U3401 combines what is shown as "Die 1" and "Die 2" in the figure and U3402 combines "Die 3" and "Die 4". So ODT/CKE/NCS0 and ODT/CKE/NCS1 must be connected to a single U340x.
Oh I thought U3401 would be "Die 1" and "Die 3" for chips connected to cs0. Yeah probably you're right and U3401 is "Die 1" and "Die 2", otherwise the ddr3 package would not even need separate balls for cke0 and cke1.
Cutting either would IMHO make half of the memory capacity unaccessible.
That would not be good..
Indeed. What I am really worried about is that I can't find any bit of information about the cka and ckb except that ckb is not used for LPDDR2...
Hm. I think there was an AN about DDR3 for OMAP5 which might have more information. I have to dig it out.
Well, I found what I thought could be relevant, but it was section "7.7 DDR3 Board Design and Layout Guidelines" in SWPS050I and covers only general PCB layout guidelines.
It provides no information about cka vs. ckb and other signals or EMIF setup.
BR, Nikolaus
Maybe we could ask our Memphis contact about that? He's knowlegable with memory chips and this is no OMAP specific question.
On 17 October 2018 09:39:50 CEST, "H. Nikolaus Schaller" hns@goldelico.com wrote:
Am 17.10.2018 um 07:16 schrieb H. Nikolaus Schaller
Am 17.10.2018 um 07:13 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [181017 04:42]:
Am 17.10.2018 um 01:03 schrieb Tony Lindgren tony@atomide.com: Well looking at the Pyra schematics to me it seems that for
example
on emif1 cke0 and cke1 are both connected to U3401 and U3402. To
me
it seems U3401 should only have cke0 and U3402 should have only
cke1
(or the other way around) just as in "EMIF DDR3 Generic
Configuration".
And the same for the other used lines, and for emif2.
Are you sure with oyur idea?
No :)
U3401 is for 16 bits and U3402 for the other 16 bits of the 32 bit
EMIF channel.
Both, U3401 and U3402 have two dies inside where one responds to
ODT/CKE/NCS0
and the other to ODT/CKE/NCS1. So U3401 combines what is shown as
"Die 1" and "Die 2"
in the figure and U3402 combines "Die 3" and "Die 4". So
ODT/CKE/NCS0 and
ODT/CKE/NCS1 must be connected to a single U340x.
Oh I thought U3401 would be "Die 1" and "Die 3" for chips connected
to cs0.
Yeah probably you're right and U3401 is "Die 1" and "Die 2",
otherwise
the ddr3 package would not even need separate balls for cke0 and
cke1.
Cutting either would IMHO make half of the memory capacity
unaccessible.
That would not be good..
Indeed. What I am really worried about is that I can't find any bit
of information
about the cka and ckb except that ckb is not used for LPDDR2...
Hm. I think there was an AN about DDR3 for OMAP5 which might have
more
information. I have to dig it out.
Well, I found what I thought could be relevant, but it was section "7.7 DDR3 Board Design and Layout Guidelines" in SWPS050I and covers only general PCB layout guidelines.
It provides no information about cka vs. ckb and other signals or EMIF setup.
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 17.10.2018 um 10:01 schrieb Michael Mrozek EvilDragon@openpandora.org:
Maybe we could ask our Memphis contact about that? He's knowlegable with memory chips and this is no OMAP specific question.
No, it is the other way round. cka and ckb are outputs of the OMAP and we can only connect cka to the memory chips.
And now we do not know how the EMIF controls the cka and ckb...
My theory: EMIF assumes that each chip has separate clock cka and ckb. Now EMIF can turn off cka to save energy. It does not know that cka does also serve the second die because it assumes that it is connected to ckb. So it keeps ckb running but the chip has no clock.
But without information I can't prove or disprove this or find out what consequences this has.
@Tony: does the dra7 or omap4 have the same EMIF? And maybe more documentation about clka and clkb?
On 17 October 2018 09:39:50 CEST, "H. Nikolaus Schaller" hns@goldelico.com wrote:
Am 17.10.2018 um 07:16 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 17.10.2018 um 07:13 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [181017 04:42]:
Am 17.10.2018 um 01:03 schrieb Tony Lindgren tony@atomide.com: Well looking at the Pyra schematics to me it seems that for example on emif1 cke0 and cke1 are both connected to U3401 and U3402. To me it seems U3401 should only have cke0 and U3402 should have only cke1 (or the other way around) just as in "EMIF DDR3 Generic Configuration". And the same for the other used lines, and for emif2. Are you sure with oyur idea? No :)
U3401 is for 16 bits and U3402 for the other 16 bits of the 32 bit EMIF channel.
Both, U3401 and U3402 have two dies inside where one responds to ODT/CKE/NCS0 and the other to ODT/CKE/NCS1. So U3401 combines what is shown as "Die 1" and "Die 2" in the figure and U3402 combines "Die 3" and "Die 4". So ODT/CKE/NCS0 and ODT/CKE/NCS1 must be connected to a single U340x. Oh I thought U3401 would be "Die 1" and "Die 3" for chips connected to cs0. Yeah probably you're right and U3401 is "Die 1" and "Die 2", otherwise the ddr3 package would not even need separate balls for cke0 and cke1.
Cutting either would IMHO make half of the memory capacity unaccessible. That would not be good.. Indeed. What I am really worried about is that I can't find any bit of information about the cka and ckb except that ckb is not used for LPDDR2...
Hm. I think there was an AN about DDR3 for OMAP5 which might have more information. I have to dig it out.
Well, I found what I thought could be relevant, but it was section "7.7 DDR3 Board Design and Layout Guidelines" in SWPS050I and covers only general PCB layout guidelines.
It provides no information about cka vs. ckb and other signals or EMIF setup.
BR, Nikolaus Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen / Greetings,
Michael Mrozek OpenPandora GmbH Geschäftsführer / CEO: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland / Germany Tel.: +49 841 / 990 5548 http://www.openpandora.de/ http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt eMail: mrozek@openpandora.org
On Wed, 17 Oct 2018 10:14:33 +0200 "H. Nikolaus Schaller" hns@goldelico.com wrote:
My theory: EMIF assumes that each chip has separate clock cka and ckb. Now EMIF can turn off cka to save energy. It does not know that cka does also serve the second die because it assumes that it is connected to ckb. So it keeps ckb running but the chip has no clock.
But without information I can't prove or disprove this or find out what consequences this has.
Is there anyway to boot with all the lower 2GB reserved (for nothing) forcing only the upper 2GB to be used, it might possibly give a clue as to whats going on ?
--- bedroomcoders.co.uk - coding adventures of a geek...
* Mr C Camacho chriscamacho@virginmedia.com [181017 15:35]:
On Wed, 17 Oct 2018 10:14:33 +0200 "H. Nikolaus Schaller" hns@goldelico.com wrote:
My theory: EMIF assumes that each chip has separate clock cka and ckb. Now EMIF can turn off cka to save energy. It does not know that cka does also serve the second die because it assumes that it is connected to ckb. So it keeps ckb running but the chip has no clock.
Yeah this seems like the best explanation so far.
Note that in am57xx TRM things seem different as in "Figure 17-46. EMIF DDR2/DDR3 Configuration Without ECC" there's just CK ddri_ck listed, so not sure what has changed.
But without information I can't prove or disprove this or find out what consequences this has.
Is there anyway to boot with all the lower 2GB reserved (for nothing) forcing only the upper 2GB to be used, it might possibly give a clue as to whats going on ?
Yeah this is easy to do, see the test patch below. It maps 2GB from emif2 with no interleaving. With interleaving the map_2 value would be 0x80700300 which is the default. That's the TRM register for "Table 15-49. DMM_LISA_MAP_i".
This works just fine for self-refresh. But if any configuration is added for kernel for emif1 also, self-refresh will hang the system it seems.
No idea what the connection is between emif1 and emif2 related to the self-refresh hang without interleaving copnfigured though.
Regards,
Tony
8< --------------------- diff --git a/board/goldelico/letux-cortex15/lc15.c b/board/goldelico/letux-cortex15/lc15.c --- a/board/goldelico/letux-cortex15/lc15.c +++ b/board/goldelico/letux-cortex15/lc15.c @@ -103,6 +103,20 @@ void emif_get_reg_dump(u32 emif_nr, const struct emif_regs **regs) *regs = &emif_regs_ddr3_532_mhz_2cs_es2; }
+const struct dmm_lisa_map_regs lisa_map_cm_pyra = { + .dmm_lisa_map_0 = 0x0, + .dmm_lisa_map_1 = 0x0, + .dmm_lisa_map_2 = 0x80700200, + .dmm_lisa_map_3 = 0xFF020100, + .is_ma_present = 0x1, +}; + +void emif_get_dmm_regs(const struct dmm_lisa_map_regs **dmm_lisa_regs) +{ + *dmm_lisa_regs = &lisa_map_cm_pyra; +} + +#if 0 void dram_init_banksize(void) { /* make U-Boot pass the same as bootarg "mem=2032M@0x80000000 mem=2048M@0x200000000" would do */ gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE; // == 0x80000000 @@ -117,6 +131,7 @@ void dram_init_banksize(void) gd->ram_size = gd->bd->bi_dram[0].size + gd->bd->bi_dram[1].size; } #endif +#endif
/* * Board Revision Detection
-
Grazvydas Ignotas -
H. Nikolaus Schaller -
Michael Mrozek -
Mr C Camacho -
Tony Lindgren