* 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
/*