Hi,
So I found some hacked up settings that allow booting 4GB pyra at 1.35V. I just set the timings to max to see what would happen and then that worked with the termination set to zero. Obviously not the correct timings though.. But hey at least proves that this memory can work at 1.35V pretty much :)
Regards,
Tony
Tony Lindgren (2): Pyra/LC15: Proof of concept ddr3 max timings for 1.35V Pyra/LC15: Configure interleaving for 4GB DDR3
arch/arm/cpu/armv7/omap-common/emif-common.c | 5 +++++ arch/arm/include/asm/emif.h | 1 + board/goldelico/letux-cortex15/lc15.c | 33 +++++++++++++++++++++------- 3 files changed, 31 insertions(+), 8 deletions(-)
Looks like termination set to zero and ref_ctrl to sdram_tim3 set to max values we can at least boot to console and run memtester.
Note that these are not the real timings.. It seems that the earlier timings only work for 1.5V and the timings need to be much slower for 1.35V probably because of the slew rate changing.
I'm still getting memory errors with these quite easilye with two instances of memtester 1900M. But at least the system no longer hangs at 1.35V. The errors seem to start somewhere above 70 C something. --- board/goldelico/letux-cortex15/lc15.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)
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 @@ -34,16 +34,19 @@ const struct omap_sysinfo sysinfo = { * choose 2GB or 4GB automatically. * * NOTE: please run a kernel with LPAE enabled to make use of the 4GB RAM! + * + * REVISIT: Somebody calculate proper ref_ctrl to sdram_tim3 + * */
const struct emif_regs emif_regs_ddr3_532_mhz_2cs_es2 = { - .sdram_config_init = 0x61851B3A, - .sdram_config = 0x61851B3A, + .sdram_config_init = 0x60851B3A, + .sdram_config = 0x60851B3A, .sdram_config2 = 0x0, - .ref_ctrl = 0x00001035, - .sdram_tim1 = 0xCCCF36B3, - .sdram_tim2 = 0x308F7FDA, - .sdram_tim3 = 0x027F88A8, + .ref_ctrl = 0x0000ffff, + .sdram_tim1 = 0xffffffff, + .sdram_tim2 = 0xffffffff, + .sdram_tim3 = 0xffffffff, .read_idle_ctrl = 0x00050000, .zq_config = 0xD007190B, .temp_alert_config = 0x00000000,
* Tony Lindgren tony@atomide.com [170817 21:44]:
I'm still getting memory errors with these quite easilye with two instances of memtester 1900M. But at least the system no longer hangs at 1.35V. The errors seem to start somewhere above 70 C something.
And keeping the temperatures down below 65C with a heat sink and a fan seems to make memtester behave, saw some errors after about half an hour of testing when the cpu temperature got to 68C.
Later,
Tony
Am Thu, 17 Aug 2017 22:39:33 -0700 hat Tony Lindgren tony@atomide.com geschrieben:
Thanks, that's interesting!
One more info from the distributor: As Dual Die chips basically have twice the load, the might need a different combination of resistors and capacitors than Single-Rank chip.
Looking at what you found out, it could very well be that changing the used resistors and / or capacitors might do the trick.
- Tony Lindgren tony@atomide.com [170817 21:44]:
I'm still getting memory errors with these quite easilye with two instances of memtester 1900M. But at least the system no longer hangs at 1.35V. The errors seem to start somewhere above 70 C something.
And keeping the temperatures down below 65C with a heat sink and a fan seems to make memtester behave, saw some errors after about half an hour of testing when the cpu temperature got to 68C.
Later,
Tony _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 18.08.2017 um 12:18 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Thu, 17 Aug 2017 22:39:33 -0700 hat Tony Lindgren tony@atomide.com geschrieben:
Thanks, that's interesting!
One more info from the distributor: As Dual Die chips basically have twice the load, the might need a different combination of resistors and capacitors than Single-Rank chip.
Well, this means signal load i.e. resistors and capacities inside the chip (Si on SiO2 forms resistors and inductors and capacitors as well).
So we can't change those.
What can be changed is the drive strength on the OMAP side. This is more or less equivalent to changing driver resistance.
In other words: higher driver strength sends stronger signals and this charges/discharges capacitors formed by the Si chips in the DDR3 Multi Chip package faster. Faster charge/discharge gives better signals (usually) and more room for timing misalignment.
But it looks as if Tony, Juliano and Matthijs have already discussed that.
Looking at what you found out, it could very well be that changing the used resistors and / or capacitors might do the trick.
- Tony Lindgren tony@atomide.com [170817 21:44]:
I'm still getting memory errors with these quite easilye with two instances of memtester 1900M. But at least the system no longer hangs at 1.35V. The errors seem to start somewhere above 70 C something.
And keeping the temperatures down below 65C with a heat sink and a fan seems to make memtester behave, saw some errors after about half an hour of testing when the cpu temperature got to 68C.
Later,
Tony _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On 28 August 2017 at 17:27, H. Nikolaus Schaller hns@goldelico.com wrote:
In other words: higher driver strength sends stronger signals and this charges/discharges capacitors formed by the Si chips in the DDR3 Multi Chip package faster. Faster charge/discharge gives better signals (usually) and more room for timing misalignment.
Well... this description is only accurate if the propagation delay (trace length) is negligible in comparison to the rise/fall time. In general, drive strength can also be too high and result in overshoot.
But it looks as if Tony, Juliano and Matthijs have already discussed that.
Signal integrity simulation based on IBIS data of the omap5 and ram show very clean eye diagrams, not only for the default ODT setting (60Ω) but even if ODT is disabled (to reduce consumption and increase voltage swing). Based on this it seems the default drive strength (40Ω) should be fine.
Matthijs
Am Mon, 28 Aug 2017 17:27:53 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
One more info from the distributor: As Dual Die chips basically have twice the load, the might need a different combination of resistors and capacitors than Single-Rank chip.
Well, this means signal load i.e. resistors and capacities inside the chip (Si on SiO2 forms resistors and inductors and capacitors as well). So we can't change those.
Ah, okay. Well, signal integrity is fine, so that's not the problem. Or would increasing the driver strength help with noise on the power traces as well?
Can the driver strength be increased by software?
notaz mentioned the EVM has over 44 capacitors for the RAM power traces only... how many do we have and can those be changed / optimized?
What can be changed is the drive strength on the OMAP side. This is more or less equivalent to changing driver resistance. In other words: higher driver strength sends stronger signals and this charges/discharges capacitors formed by the Si chips in the DDR3 Multi Chip package faster. Faster charge/discharge gives better signals (usually) and more room for timing misalignment.
Am 31.08.2017 um 13:21 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Mon, 28 Aug 2017 17:27:53 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
One more info from the distributor: As Dual Die chips basically have twice the load, the might need a different combination of resistors and capacitors than Single-Rank chip.
Well, this means signal load i.e. resistors and capacities inside the chip (Si on SiO2 forms resistors and inductors and capacitors as well). So we can't change those.
Ah, okay. Well, signal integrity is fine, so that's not the problem. Or would increasing the driver strength help with noise on the power traces as well?
Can the driver strength be increased by software?
notaz mentioned the EVM has over 44 capacitors for the RAM power traces only... how many do we have and can those be changed / optimized?
We don't have that many but AFAIR there are at least 2 per DDR3 chip. On the latest (not yet populated PCB) there are 13 for 4 chips, i.e. >3 per DDR3 chip.
No idea if increasing that helps to get the 4GB DRAM more stable.
The problem is that I can form hypotheses and explanations for both outcomes :(
+ Basically the 4GB dual die chips may need more decoupling (local energy buffer) for VDD because they draw more current if both chips are active
- On the other hand 2GB RAM works well with much less decoupling than the EVM which also has only 2GB RAM... So 48 is not needed for 2GB.
BR, Nikolaus
Am Thu, 31 Aug 2017 16:08:49 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
notaz mentioned the EVM has over 44 capacitors for the RAM power traces only... how many do we have and can those be changed / optimized?
We don't have that many but AFAIR there are at least 2 per DDR3 chip. On the latest (not yet populated PCB) there are 13 for 4 chips, i.e.
3 per DDR3 chip.
Ah - we optimized the capacitors for the DDR3 chips as well? Then I guess we should probably populate a few to test that!
- Basically the 4GB dual die chips may need more decoupling (local
energy buffer) for VDD because they draw more current if both chips are active
Yep.
- On the other hand 2GB RAM works well with much less decoupling than
the EVM which also has only 2GB RAM... So 48 is not needed for 2GB.
True as well. The solution is probably somewhere inbetween. As it works for Tony if he increases the voltage and Juliano showed that we might have too much noise, then a LITTLE improvement might already be enough.
So those >3 per DDR3 could help!
Hi,
Am 31.08.2017 um 17:15 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Thu, 31 Aug 2017 16:08:49 +0200 hat "H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
notaz mentioned the EVM has over 44 capacitors for the RAM power traces only... how many do we have and can those be changed / optimized?
We don't have that many but AFAIR there are at least 2 per DDR3 chip. On the latest (not yet populated PCB) there are 13 for 4 chips, i.e.
3 per DDR3 chip.
Ah - we optimized the capacitors for the DDR3 chips as well?
I haven't said that... Just that I only counted them on the latest PCB layout. Which has not been populated and is ahead of our prototypes.
I didn't cross-check with previous boards (it is a little more difficult to locate and open the files).
Now I have done that and capacitors have not changed since the first CPU board prototype.
Then I guess we should probably populate a few to test that!
- Basically the 4GB dual die chips may need more decoupling (local
energy buffer) for VDD because they draw more current if both chips are active
Yep.
- On the other hand 2GB RAM works well with much less decoupling than
the EVM which also has only 2GB RAM... So 48 is not needed for 2GB.
True as well. The solution is probably somewhere inbetween.
If at all. It could still be something completely different.
As it works for Tony if he increases the voltage and Juliano showed that we might have too much noise, then a LITTLE improvement might already be enough.
So those >3 per DDR3 could help!
Yes, according to this completely unproven theory.
I just want to say that I would prefer new facts before drawing conclusions from hypotheses :) I understand that you prefer to really do something than still be digging in the fog/mist.
Unfortunately it is hardware and not changing some line in source code and recompiling :(
Especially since changes cost money. >3 per DDR3 chip means: * scrapping the 500 boards and * trying to squeeze in more capacitors * have PCBs built and populated
If it helps: fine. If not: wasted money and time.
The change-compile-boot-analyse cycle for software is significantly faster...
So I'd prefer to get more facts about different parameter sets that work/don't work etc. first.
BR, Nikolaus
On Do, 2017-08-31 at 17:30 +0200, H. Nikolaus Schaller wrote:
Hi,
Now I have done that and capacitors have not changed since the first CPU board prototype.
Ah, okay.
As it works for Tony if he increases the voltage and Juliano showed that we might have too much noise, then a LITTLE improvement might already be enough. So those >3 per DDR3 could help!
Yes, according to this completely unproven theory. I just want to say that I would prefer new facts before drawing conclusions from hypotheses :) I understand that you prefer to really do something than still be digging in the fog/mist.
Unfortunately it is hardware and not changing some line in source code and recompiling :(
I know, that's why I asked in my first mail whether someone has an idea what we could still check. What doesn't make sense is when no one tries anything in software anymore because there are no new ideas or everything has been tried already.
That would be a total standstill for hard- and software and that's worst case scenario.
Especially since changes cost money. >3 per DDR3 chip means:
- scrapping the 500 boards and
- trying to squeeze in more capacitors
- have PCBs built and populated
If it helps: fine. If not: wasted money and time.
Yep, I know. Scrapping the 500 boards would only make sense if it turns out to be the issue though. And if it IS the issue, then scrapping them would be the right thing to do.
But if no one knows another solution to try in software and nothing happens for about 8 weeks, we would have the time to build new PCBs.
So sure, finding a software solution is the highest priority, but if there are no ideas left we can't just sit and do nothign.
The change-compile-boot-analyse cycle for software is significantly faster...
I am well aware of that. But if you tinker around for 8 weeks and find out nothing helps, you still lost 8 weeks.
If you try to improve the PCBs and order a prototype sample, you can still tinker around. If you find the solution: Great! If you don't, at least you don't have to wait another 6 weeks for an improved PCB.
So yes, as long as there are more ideas and things to try, I don't want to try to fix the hardware. But once all ideas have been tried out, I don't want to waste any time either.
So I'd prefer to get more facts about different parameter sets that work/don't work etc. first.
Well, according to the distributor, they should work with standard Jedec timings without any issues. Same as the 2GB RAM.
If they don't, then they suggest to fix the hardware.
I'm fine if we use non-standard timings, of course (as long as it works), but according to the distributor, there shouldn't be much to setup in software, which is my biggest concern.
HI,
Am 31.08.2017 um 20:02 schrieb Michael Mrozek EvilDragon@openpandora.org:
On Do, 2017-08-31 at 17:30 +0200, H. Nikolaus Schaller wrote:
Hi,
Now I have done that and capacitors have not changed since the first CPU board prototype.
Ah, okay.
As it works for Tony if he increases the voltage and Juliano showed that we might have too much noise, then a LITTLE improvement might already be enough. So those >3 per DDR3 could help!
Yes, according to this completely unproven theory. I just want to say that I would prefer new facts before drawing conclusions from hypotheses :) I understand that you prefer to really do something than still be digging in the fog/mist.
Unfortunately it is hardware and not changing some line in source code and recompiling :(
I know, that's why I asked in my first mail whether someone has an idea what we could still check. What doesn't make sense is when no one tries anything in software anymore because there are no new ideas or everything has been tried already.
That would be a total standstill for hard- and software and that's worst case scenario.
Especially since changes cost money. >3 per DDR3 chip means:
- scrapping the 500 boards and
- trying to squeeze in more capacitors
- have PCBs built and populated
If it helps: fine. If not: wasted money and time.
Yep, I know. Scrapping the 500 boards would only make sense if it turns out to be the issue though. And if it IS the issue, then scrapping them would be the right thing to do.
But if no one knows another solution to try in software and nothing happens for about 8 weeks, we would have the time to build new PCBs.
So sure, finding a software solution is the highest priority, but if there are no ideas left we can't just sit and do nothign.
The change-compile-boot-analyse cycle for software is significantly faster...
I am well aware of that. But if you tinker around for 8 weeks and find out nothing helps, you still lost 8 weeks.
If you try to improve the PCBs and order a prototype sample, you can still tinker around. If you find the solution: Great! If you don't, at least you don't have to wait another 6 weeks for an improved PCB.
So yes, as long as there are more ideas and things to try, I don't want to try to fix the hardware. But once all ideas have been tried out, I don't want to waste any time either.
So I'd prefer to get more facts about different parameter sets that work/don't work etc. first.
Well, according to the distributor, they should work with standard Jedec timings without any issues. Same as the 2GB RAM.
If they don't, then they suggest to fix the hardware.
If we know what to fix, it is easy. But we don't even know what to fix in the hardware. The simulations did not reveal a problem so far.
And that additional capacitors may help is just a theory.
You remember: we had the same problem with the 2 GB RAM and >1.25 GHz OPPs and also discussed capacitors.
I even added some more capacitors on the backside of one PCB through scratching open some VIAs. It did not have any noticeable effect.
What did have a big effect - even without any additional capacitors - was to change the EMIF setup...
I'm fine if we use non-standard timings, of course (as long as it works), but according to the distributor, there shouldn't be much to setup in software, which is my biggest concern.
I don't understand the EMIF and DDR3 timings well enough to know what and if it can be improved by EMIF configs (I do not even understand in detail what the 2 GB patch really did).
BTW: higher voltage could also mean that the chips simply draw more current and we have more mV of voltage drop between Palmas output and DDR3L VDD input. This SMPS does not have a separate sense line going back from the DDR3L to the Palmas. It simply regulates the Palmas output to 1.35V. The voltage at the chip VDD pins be smaller. Hence we must configure the Palmas to send more. And dual-die chips need twice the current so the mV drop is twice as large... But on the other hand the chips are not selected both at the same time. So they are alternatingly active. Which means power consumption should not be twice as high.
Could be - but that is again speculation unless we can measure it somehow and demonstrate that this is the problem. If it is, we have two choices: a) make the wires from Palmas to DDR3L bigger (change PCB layout) b) set the Palmas to 1.42V so that the DDR3L gets 1.35V and keep the PCB as it is
To be honest, I don't feel that I have enough information to suggest either.
Hm. What we could ask is for the Samsung DDR3L single-die variant. I.e. same die, same package but only 2 GB in total. And rework one CPU board with those and compare to a 2 GB board with IM DDR3L 2 GB chip.
Or we can ask if IM has a 4 GB dual-die variant.
Would be a little risky transplantation, but then we know if it is IM vs. SAMSUNG or 2GB vs. 4GB. Nevertheless I would do such HW mods only after we are sure that all EMIF config options have been tried without success.
BR, Nikolaus
Based on igepv5 u-boot commit 4521f304a913 ("IGEPv5: Modify lisa_regs structure, added ma_hm_interleave variable") by Manel Caro mcaro@iseebcn.com, we need to configure interleaving for 4GB DDR3 to work properly.
With out this patch u-boot somehow has hard time booting reliably even with smps6 set to 1.50V and termination set to 0.
Note that with interleaving the memory addresses are different if passed from kernel command line. Typically those can be left out as u-boot will pass them. --- arch/arm/cpu/armv7/omap-common/emif-common.c | 5 +++++ arch/arm/include/asm/emif.h | 1 + board/goldelico/letux-cortex15/lc15.c | 18 ++++++++++++++++-- 3 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c b/arch/arm/cpu/armv7/omap-common/emif-common.c --- a/arch/arm/cpu/armv7/omap-common/emif-common.c +++ b/arch/arm/cpu/armv7/omap-common/emif-common.c @@ -1339,6 +1339,11 @@ void dmm_init(u32 base) &hw_lisa_map_regs->dmm_lisa_map_0);
setbits_le32(MA_PRIORITY, MA_HIMEM_INTERLEAVE_UN_MASK); + + /* MA_PRIORITY[8] HIMEM_INTERLEAVE_UN bit to 0x1 */ + if (lisa_map_regs->is_ma_hm_interleave) + __raw_writel(__raw_readl(MA_PRIORITY) | + (1 << 8) , MA_PRIORITY); }
/* diff --git a/arch/arm/include/asm/emif.h b/arch/arm/include/asm/emif.h --- a/arch/arm/include/asm/emif.h +++ b/arch/arm/include/asm/emif.h @@ -756,6 +756,7 @@ struct dmm_lisa_map_regs { u32 dmm_lisa_map_2; u32 dmm_lisa_map_3; u8 is_ma_present; + u8 is_ma_hm_interleave; };
#define CS0 0 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 @@ -69,10 +69,10 @@ void emif_get_reg_dump(u32 emif_nr, const struct emif_regs **regs) }
void dram_init_banksize(void) -{ /* make U-Boot pass the same as bootarg "mem=2032M@0x80000000 mem=2048M@0x200000000" would do */ +{ /* make U-Boot pass the same as bootarg "mem=2032M@0x80000000 mem=2048M@0x300000000" would do */ gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE; // == 0x80000000 gd->bd->bi_dram[0].size = 2032*(1024UL*1024); // first 2GB - gd->bd->bi_dram[1].start = 0x200000000UL; + gd->bd->bi_dram[1].start = 0x300000000UL; gd->bd->bi_dram[1].size = 2048*(1024UL*1024); // second 2GB #if 0 // get back "stolen" memory gd->bd->bi_dram[1].start = 0x2FF000000UL; @@ -81,6 +81,20 @@ 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; } + +const struct dmm_lisa_map_regs lisa_map_pyra_4g = { + .dmm_lisa_map_0 = 0x0, + .dmm_lisa_map_1 = 0x0, + .dmm_lisa_map_2 = 0x807C0300, + .dmm_lisa_map_3 = 0xFF020100, + .is_ma_present = 0x1, + .is_ma_hm_interleave = 0x1, +}; + +void emif_get_dmm_regs(const struct dmm_lisa_map_regs **dmm_lisa_regs) +{ + *dmm_lisa_regs = &lisa_map_pyra_4g; +} #endif
/*
Hi, finally I am back in office and tried to make it working.
But I can't boot with this setup. RAM is "not working" which indicates subtle parameter variations.
U-Boot SPL 2016.11-00248-g0249324 (Aug 28 2017 - 15:11:23) OMAP5432-GP ES2.0 SDRAM: identified size not same as expected size identified: 0 expected: 40000000
spl:board_init_r()
spl_init() Trying to boot from MMC1 WARNING: DDR RAM is not working! (12000000) Found LC15 V5.1 board_mmc_init called (vers = 51) MLO hard: gpio7 = eMMC soft: gpio82 = 0 (mmc1=eMMC) ctrl: gpio76 = 1 (ctrl=soft)
Should I try a different patch set?
src hns$ git log --oneline -5 0249324736 Pyra/LC15: Configure interleaving for 4GB DDR3 3ec0ad03d8 Pyra/LC15: Proof of concept ddr3 max timings for 1.35V c8fb1e629c U-Boot: OMAP: fix variables names in default boot environment <- http://git.goldelico.com/?p=gta04-uboot.git;a=commit;h=c8fb1e629c77d3da954d6... e16ab8dd10 Letux boot-scr: add boot.scr source for Udoo Neo 2e5153378d Letux: add boot.scr source for udoo neo src hns$
BR, Nikolaus
Am 18.08.2017 um 06:43 schrieb Tony Lindgren tony@atomide.com:
Hi,
So I found some hacked up settings that allow booting 4GB pyra at 1.35V. I just set the timings to max to see what would happen and then that worked with the termination set to zero. Obviously not the correct timings though.. But hey at least proves that this memory can work at 1.35V pretty much :)
Regards,
Tony
Tony Lindgren (2): Pyra/LC15: Proof of concept ddr3 max timings for 1.35V Pyra/LC15: Configure interleaving for 4GB DDR3
arch/arm/cpu/armv7/omap-common/emif-common.c | 5 +++++ arch/arm/include/asm/emif.h | 1 + board/goldelico/letux-cortex15/lc15.c | 33 +++++++++++++++++++++------- 3 files changed, 31 insertions(+), 8 deletions(-)
-- 2.14.1
* H. Nikolaus Schaller hns@goldelico.com [170828 08:24]:
Hi, finally I am back in office and tried to make it working.
But I can't boot with this setup. RAM is "not working" which indicates subtle parameter variations.
U-Boot SPL 2016.11-00248-g0249324 (Aug 28 2017 - 15:11:23) OMAP5432-GP ES2.0 SDRAM: identified size not same as expected size identified: 0 expected: 40000000
spl:board_init_r()
spl_init() Trying to boot from MMC1 WARNING: DDR RAM is not working! (12000000) Found LC15 V5.1 board_mmc_init called (vers = 51) MLO hard: gpio7 = eMMC soft: gpio82 = 0 (mmc1=eMMC) ctrl: gpio76 = 1 (ctrl=soft)
Should I try a different patch set?
Just the "Pyra/LC15: Proof of concept ddr3 max timings for 1.35V" is enough for me. And in that patch the ref_ctrl value of anything around 4 x 0x1035 seems to work. No idea why the ref_ctrl must be off that much..
The second patch is not needed at all as pointed out by Matthijs as the interleaving is already enabled.
Regards,
Tony
-
H. Nikolaus Schaller -
Matthijs van Duin -
Michael Mrozek -
Tony Lindgren