Patchwork [U-Boot] mx23: Put back RAM voltage level to its original value

login
register
mail settings
Submitter Fabio Estevam
Date April 26, 2013, 4:01 p.m.
Message ID <1366992090-4331-1-git-send-email-festevam@gmail.com>
Download mbox | patch
Permalink /patch/239886/
State Awaiting Upstream
Delegated to: Stefano Babic
Headers show

Comments

Fabio Estevam - April 26, 2013, 4:01 p.m.
From: Fabio Estevam <fabio.estevam@freescale.com>

commit 5c2f444c9 (mxs: Reset the EMI block on mx23) changed the DDR voltage 
level, which causes mx23evk to fail to load a kernel.

Put back the original values, so that mx23evk can boot a kernel again.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
 arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Marek Vasut - April 26, 2013, 4:20 p.m.
Dear Fabio Estevam,

> From: Fabio Estevam <fabio.estevam@freescale.com>
> 
> commit 5c2f444c9 (mxs: Reset the EMI block on mx23) changed the DDR voltage
> level, which causes mx23evk to fail to load a kernel.
> 
> Put back the original values, so that mx23evk can boot a kernel again.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>

Is that _really_ it? Can you please try compiling kernel on the MX23 machine to 
test if the memory is really stable?

Best regards,
Marek Vasut
Eric Benard - April 26, 2013, 4:24 p.m.
Hi Fabio,

Le Fri, 26 Apr 2013 13:01:26 -0300,
Fabio Estevam <festevam@gmail.com> a écrit :

> From: Fabio Estevam <fabio.estevam@freescale.com>
> 
> commit 5c2f444c9 (mxs: Reset the EMI block on mx23) changed the DDR voltage 
> level, which causes mx23evk to fail to load a kernel.
> 
> Put back the original values, so that mx23evk can boot a kernel again.
> 
what are the values of these levels (previous one and new one) in mV ?

Best regards,
Eric
Fabio Estevam - April 26, 2013, 5:14 p.m.
On Fri, Apr 26, 2013 at 1:20 PM, Marek Vasut <marex@denx.de> wrote:

> Is that _really_ it? Can you please try compiling kernel on the MX23 machine to
> test if the memory is really stable?

With this change I can boot the kernel and mount rootfs 100% of the times.

I don't have an easy way to do native build on mx23.

Anyway, if memory needs further optimization, that would be another patch.

This one allows my mx23evk to be useful again.

Regards,

Fabio Estevam
Fabio Estevam - April 26, 2013, 5:17 p.m.
On Fri, Apr 26, 2013 at 1:24 PM, Eric Bénard <eric@eukrea.com> wrote:

> what are the values of these levels (previous one and new one) in mV ?

0x10 ==> 2.5V
0x12 ==> 2.6V

46v32m16 says that VDD is : 2.5V +/- 0.2V, so 2.6V is a valid supply voltage.

Not sure why 2.5V fails though.

Regards,

Fabio Estevam
robertcnelson@gmail.com - April 26, 2013, 6:14 p.m.
On Fri, Apr 26, 2013 at 11:01 AM, Fabio Estevam <festevam@gmail.com> wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> commit 5c2f444c9 (mxs: Reset the EMI block on mx23) changed the DDR voltage
> level, which causes mx23evk to fail to load a kernel.
>
> Put back the original values, so that mx23evk can boot a kernel again.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>

Tested-by: Robert Nelson <robertcnelson@gmail.com>

> ---
>  arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> index bc2d69c..4950490 100644
> --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
> @@ -234,7 +234,7 @@ static void mx23_mem_setup_vddmem(void)
>         struct mxs_power_regs *power_regs =
>                 (struct mxs_power_regs *)MXS_POWER_BASE;
>
> -       writel((0x10 << POWER_VDDMEMCTRL_TRG_OFFSET) |
> +       writel((0x12 << POWER_VDDMEMCTRL_TRG_OFFSET) |
>                 POWER_VDDMEMCTRL_ENABLE_ILIMIT |
>                 POWER_VDDMEMCTRL_ENABLE_LINREG |
>                 POWER_VDDMEMCTRL_PULLDOWN_ACTIVE,
> @@ -242,7 +242,7 @@ static void mx23_mem_setup_vddmem(void)
>
>         early_delay(10000);
>
> -       writel((0x10 << POWER_VDDMEMCTRL_TRG_OFFSET) |
> +       writel((0x12 << POWER_VDDMEMCTRL_TRG_OFFSET) |
>                 POWER_VDDMEMCTRL_ENABLE_LINREG,
>                 &power_regs->hw_power_vddmemctrl);
>  }
> --
> 1.7.9.5

Sweet! This fixes the random memory issues I was seeing on my
imx233-oLinuXno-Micro when using u-boot..

I Used memtester for memory verification..

u-boot v2013.04 & v3.9-rc7

root@arm:/home/debian# memtester 24M
memtester version 4.2.2 (32-bit)
Copyright (C) 2010 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffff000
want 24MB (25165824 bytes)
got  24MB (25165824 bytes), trying mlock ...locked.
Loop 1:
  Stuck Address       : ok
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
  Compare MUL         : ok
  Compare DIV         : ok
  Compare OR          : ok
  Compare AND         : ok
  Sequential Increment: ok
  Solid Bits          : ok
  Block Sequential    : testing 254FAILURE: 0xfefefefe != 0xfefe00fe
at offset 0x002c11bc.
  Checkerboard        : setting  37^C

u-boot v2013.04 + mx23: Put back RAM voltage level to its original
valueu-boot & v3.9-rc7

root@arm:/home/debian# memtester 24M
memtester version 4.2.2 (32-bit)
Copyright (C) 2010 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).


pagesize is 4096
pagesizemask is 0xfffff000
want 24MB (25165824 bytes)
got  24MB (25165824 bytes), trying mlock ...locked.
Loop 1:
  Stuck Address       : ok
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
  Compare MUL         : ok
  Compare DIV         : ok
  Compare OR          : ok
  Compare AND         : ok
  Sequential Increment: ok
  Solid Bits          : ok
  Block Sequential    : ok
  Checkerboard        : ok
  Bit Spread          : ok
  Bit Flip            : ok
  Walking Ones        : ok
  Walking Zeroes      : ok
  8-bit Writes        : ok
  16-bit Writes       : ok

Loop 2:
  Stuck Address       : ok

root@arm:/home/debian# cat /proc/cpuinfo
processor	: 0
model name	: ARM926EJ-S rev 5 (v5l)
BogoMIPS	: 226.09
Features	: swp half thumb fastmult edsp java
CPU implementer	: 0x41
CPU architecture: 5TEJ
CPU variant	: 0x0
CPU part	: 0x926
CPU revision	: 5

Hardware	: Freescale i.MX23 (Device Tree)
Revision	: 0000
Serial		: 0000000000000000

root@arm:/home/debian# uname -a
Linux arm 3.9.0-rc7-imxv5-x0.9 #2 Thu Apr 25 15:27:14 CDT 2013
armv5tejl GNU/Linux

Regards,
Marek Vasut - April 26, 2013, 6:16 p.m.
Dear Fabio Estevam,

> On Fri, Apr 26, 2013 at 1:24 PM, Eric Bénard <eric@eukrea.com> wrote:
> > what are the values of these levels (previous one and new one) in mV ?
> 
> 0x10 ==> 2.5V
> 0x12 ==> 2.6V
> 
> 46v32m16

Eh? What's this code above?

> says that VDD is : 2.5V +/- 0.2V, so 2.6V is a valid supply
> voltage.
> 
> Not sure why 2.5V fails though.

http://s8.postimg.org/dn7jhntut/imx233_olinuxino_maxi_2_5_V_rising.jpg check 
this, this is as much as I got from tsvetan so far, it's the VDDMEM ramping. I 
dunno what's that weird drop before it starts going from 1V5 to 2V5, but it's 
strange at best and I don't like it. I think that's also the source of our 
problems, the DRAM suffers undervolt and quickly afterwards is configured for 
regular operation ... I'd say check mx23_mem_setup_vddmem() and inspect the 
result with a scope. I think we need some slow ramping function like 
mxs_power_set_vddx().

Best regards,
Marek Vasut
Marek Vasut - April 26, 2013, 6:21 p.m.
Dear Fabio Estevam,

> On Fri, Apr 26, 2013 at 1:20 PM, Marek Vasut <marex@denx.de> wrote:
> > Is that _really_ it? Can you please try compiling kernel on the MX23
> > machine to test if the memory is really stable?
> 
> With this change I can boot the kernel and mount rootfs 100% of the times.
> 
> I don't have an easy way to do native build on mx23.

Yes you have, extract ELDK 5.3 for armv5te from ftp://ftp.denx.de/pub/eldk/ on 
SD card (use for example rootfs-qte-sdk) and all the tools are readily there. 
Just grab kernel source, run make mxs_defconfig ; make -j 2 and wait overnight. 
If it crashes, we still have problem.

> Anyway, if memory needs further optimization, that would be another patch.
> 
> This one allows my mx23evk to be useful again.
> 
> Regards,
> 
> Fabio Estevam

Best regards,
Marek Vasut
Eric Benard - April 26, 2013, 7:42 p.m.
Hi Marek,

Le Fri, 26 Apr 2013 20:16:30 +0200,
Marek Vasut <marex@denx.de> a écrit :
> > On Fri, Apr 26, 2013 at 1:24 PM, Eric Bénard <eric@eukrea.com> wrote:
> > > what are the values of these levels (previous one and new one) in mV ?
> > 
> > 0x10 ==> 2.5V
> > 0x12 ==> 2.6V
> > 
> > 46v32m16
> 
> Eh? What's this code above?
> 
mt46v32m16 is a Micron DDR chipset :
http://www.micron.com/parts/dram/ddr-sdram/mt46v32m16tg-6t?source=ps

Eric
Fabio Estevam - April 26, 2013, 8:08 p.m.
On Fri, Apr 26, 2013 at 3:16 PM, Marek Vasut <marex@denx.de> wrote:
> Dear Fabio Estevam,
>
>> On Fri, Apr 26, 2013 at 1:24 PM, Eric Bénard <eric@eukrea.com> wrote:
>> > what are the values of these levels (previous one and new one) in mV ?
>>
>> 0x10 ==> 2.5V
>> 0x12 ==> 2.6V
>>
>> 46v32m16
>
> Eh? What's this code above?

It is the DDR part number on mx23evk.

>
>> says that VDD is : 2.5V +/- 0.2V, so 2.6V is a valid supply
>> voltage.
>>
>> Not sure why 2.5V fails though.
>
> http://s8.postimg.org/dn7jhntut/imx233_olinuxino_maxi_2_5_V_rising.jpg check
> this, this is as much as I got from tsvetan so far, it's the VDDMEM ramping. I
> dunno what's that weird drop before it starts going from 1V5 to 2V5, but it's

Why 1.5V? The VDDMEM reset value is 1.7V.

> strange at best and I don't like it. I think that's also the source of our
> problems, the DRAM suffers undervolt and quickly afterwards is configured for
> regular operation ... I'd say check mx23_mem_setup_vddmem() and inspect the
> result with a scope. I think we need some slow ramping function like
> mxs_power_set_vddx().

Ok, but can we have this patch applied and do this investigation in parallel?

At least we could have U-boot usable on mx23 again.
Otavio Salvador - April 26, 2013, 8:13 p.m.
On Fri, Apr 26, 2013 at 5:08 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Fri, Apr 26, 2013 at 3:16 PM, Marek Vasut <marex@denx.de> wrote:
>> strange at best and I don't like it. I think that's also the source of our
>> problems, the DRAM suffers undervolt and quickly afterwards is configured for
>> regular operation ... I'd say check mx23_mem_setup_vddmem() and inspect the
>> result with a scope. I think we need some slow ramping function like
>> mxs_power_set_vddx().
>
> Ok, but can we have this patch applied and do this investigation in parallel?
>
> At least we could have U-boot usable on mx23 again.

I also vote for it to be applied and then do this investigation in
parallel. Even if there're still pending issues it does improve the
current status.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
Marek Vasut - April 26, 2013, 8:56 p.m.
Dear Fabio Estevam,

> On Fri, Apr 26, 2013 at 3:16 PM, Marek Vasut <marex@denx.de> wrote:
> > Dear Fabio Estevam,
> > 
> >> On Fri, Apr 26, 2013 at 1:24 PM, Eric Bénard <eric@eukrea.com> wrote:
> >> > what are the values of these levels (previous one and new one) in mV ?
> >> 
> >> 0x10 ==> 2.5V
> >> 0x12 ==> 2.6V
> >> 
> >> 46v32m16
> > 
> > Eh? What's this code above?
> 
> It is the DDR part number on mx23evk.
> 
> >> says that VDD is : 2.5V +/- 0.2V, so 2.6V is a valid supply
> >> voltage.
> >> 
> >> Not sure why 2.5V fails though.
> > 
> > http://s8.postimg.org/dn7jhntut/imx233_olinuxino_maxi_2_5_V_rising.jpg
> > check this, this is as much as I got from tsvetan so far, it's the
> > VDDMEM ramping. I dunno what's that weird drop before it starts going
> > from 1V5 to 2V5, but it's
> 
> Why 1.5V? The VDDMEM reset value is 1.7V.

Some voltage drop, that's no problem.

> > strange at best and I don't like it. I think that's also the source of
> > our problems, the DRAM suffers undervolt and quickly afterwards is
> > configured for regular operation ... I'd say check
> > mx23_mem_setup_vddmem() and inspect the result with a scope. I think we
> > need some slow ramping function like mxs_power_set_vddx().
> 
> Ok, but can we have this patch applied and do this investigation in
> parallel?
> 
> At least we could have U-boot usable on mx23 again.

I'd say try one more thing -- use a different PSU. I suspect the powerblock on 
olinuxino is cheap crap and the stability of the DRAM depends on the PSU too. 
After that, yes, we can have it in.

Best regards,
Marek Vasut
Fabio Estevam - April 26, 2013, 8:58 p.m.
On Fri, Apr 26, 2013 at 3:16 PM, Marek Vasut <marex@denx.de> wrote:

>
> http://s8.postimg.org/dn7jhntut/imx233_olinuxino_maxi_2_5_V_rising.jpg check
> this, this is as much as I got from tsvetan so far, it's the VDDMEM ramping. I
> dunno what's that weird drop before it starts going from 1V5 to 2V5, but it's
> strange at best and I don't like it. I think that's also the source of our
> problems, the DRAM suffers undervolt and quickly afterwards is configured for
> regular operation ... I'd say check mx23_mem_setup_vddmem() and inspect the

Currently mx23_mem_setup_vddmem() does not clear ENABLE_ILIMIT
bit as recommended by the mx23 Reference Manual:

"Controls the inrush limit (~10mA) for the memory
supply voltage. Default is active. This should remain
active until the supply settles after enabling the linreg.
This should be disabled before accessing the memory."

FSL bootlets does clear this bit.

I did the same as FSL bootlets locally and this alone does not allowed
me to boot the kernel without bumping VDDMEM to 2.6V.

I can send a patch that clears ENABLE_LIMIT, after this one gets applied.
Marek Vasut - April 26, 2013, 8:58 p.m.
Dear Otavio Salvador,

> On Fri, Apr 26, 2013 at 5:08 PM, Fabio Estevam <festevam@gmail.com> wrote:
> > On Fri, Apr 26, 2013 at 3:16 PM, Marek Vasut <marex@denx.de> wrote:
> >> strange at best and I don't like it. I think that's also the source of
> >> our problems, the DRAM suffers undervolt and quickly afterwards is
> >> configured for regular operation ... I'd say check
> >> mx23_mem_setup_vddmem() and inspect the result with a scope. I think we
> >> need some slow ramping function like mxs_power_set_vddx().
> > 
> > Ok, but can we have this patch applied and do this investigation in
> > parallel?
> > 
> > At least we could have U-boot usable on mx23 again.
> 
> I also vote for it to be applied and then do this investigation in
> parallel. Even if there're still pending issues it does improve the
> current status.

But someone has to do this! And so far I see noone capable/willing to do that :(

Best regards,
Marek Vasut
Marek Vasut - April 26, 2013, 9:07 p.m.
Dear Fabio Estevam,

> On Fri, Apr 26, 2013 at 3:16 PM, Marek Vasut <marex@denx.de> wrote:
> > http://s8.postimg.org/dn7jhntut/imx233_olinuxino_maxi_2_5_V_rising.jpg
> > check this, this is as much as I got from tsvetan so far, it's the
> > VDDMEM ramping. I dunno what's that weird drop before it starts going
> > from 1V5 to 2V5, but it's strange at best and I don't like it. I think
> > that's also the source of our problems, the DRAM suffers undervolt and
> > quickly afterwards is configured for regular operation ... I'd say check
> > mx23_mem_setup_vddmem() and inspect the
> 
> Currently mx23_mem_setup_vddmem() does not clear ENABLE_ILIMIT
> bit as recommended by the mx23 Reference Manual:
> 
> "Controls the inrush limit (~10mA) for the memory
> supply voltage. Default is active. This should remain
> active until the supply settles after enabling the linreg.
> This should be disabled before accessing the memory."
> 
> FSL bootlets does clear this bit.
> 
> I did the same as FSL bootlets locally and this alone does not allowed
> me to boot the kernel without bumping VDDMEM to 2.6V.
> 
> I can send a patch that clears ENABLE_LIMIT, after this one gets applied.

Fabio, can you get someone in FSL to measure all these VDDx (VDDD, VDDA, VDDIO, 
VDDMEM) rails with stock 2013.04 U-Boot image from powerup to u-boot command 
line and send us the results? You'd need a scope that can produce an image of 
what's happening on the rails. I just can't figure out how to get this displayed 
on my scope, sorry :-(

Best regards,
Marek Vasut
Fabio Estevam - April 26, 2013, 9:08 p.m.
On Fri, Apr 26, 2013 at 3:21 PM, Marek Vasut <marex@denx.de> wrote:

> Yes you have, extract ELDK 5.3 for armv5te from ftp://ftp.denx.de/pub/eldk/ on
> SD card (use for example rootfs-qte-sdk) and all the tools are readily there.
> Just grab kernel source, run make mxs_defconfig ; make -j 2 and wait overnight.
> If it crashes, we still have problem.

Right, but without this patch I can not even boot a kernel on mx23evk,
how would I be able to natively build one? ;-)
Fabio Estevam - April 26, 2013, 9:10 p.m.
On Fri, Apr 26, 2013 at 5:56 PM, Marek Vasut <marex@denx.de> wrote:

>> Why 1.5V? The VDDMEM reset value is 1.7V.
>
> Some voltage drop, that's no problem.

Well, 100mV does all the difference on my test.

> I'd say try one more thing -- use a different PSU. I suspect the powerblock on
> olinuxino is cheap crap and the stability of the DRAM depends on the PSU too.
> After that, yes, we can have it in.

I am not running on olinuxino.
Marek Vasut - April 26, 2013, 9:11 p.m.
Dear Fabio Estevam,

> On Fri, Apr 26, 2013 at 3:21 PM, Marek Vasut <marex@denx.de> wrote:
> > Yes you have, extract ELDK 5.3 for armv5te from
> > ftp://ftp.denx.de/pub/eldk/ on SD card (use for example rootfs-qte-sdk)
> > and all the tools are readily there. Just grab kernel source, run make
> > mxs_defconfig ; make -j 2 and wait overnight. If it crashes, we still
> > have problem.
> 
> Right, but without this patch I can not even boot a kernel on mx23evk,
> how would I be able to natively build one? ;-)

Boot the kernel with this patch and then use ELDK to do the testing please.

Best regards,
Marek Vasut
Marek Vasut - April 26, 2013, 9:14 p.m.
Dear Fabio Estevam,

> On Fri, Apr 26, 2013 at 5:56 PM, Marek Vasut <marex@denx.de> wrote:
> >> Why 1.5V? The VDDMEM reset value is 1.7V.
> > 
> > Some voltage drop, that's no problem.
> 
> Well, 100mV does all the difference on my test.

Yes, I get it, I'm just worried we're just putting a plaster on another one, not 
fixing the _real_ issue.

> > I'd say try one more thing -- use a different PSU. I suspect the
> > powerblock on olinuxino is cheap crap and the stability of the DRAM
> > depends on the PSU too. After that, yes, we can have it in.
> 
> I am not running on olinuxino.

The freescale powerblock should be ok, yes.

Best regards,
Marek Vasut
Otavio Salvador - April 26, 2013, 11:01 p.m.
On Fri, Apr 26, 2013 at 5:58 PM, Marek Vasut <marex@denx.de> wrote:
> Dear Otavio Salvador,
>
>> On Fri, Apr 26, 2013 at 5:08 PM, Fabio Estevam <festevam@gmail.com> wrote:
>> > On Fri, Apr 26, 2013 at 3:16 PM, Marek Vasut <marex@denx.de> wrote:
>> >> strange at best and I don't like it. I think that's also the source of
>> >> our problems, the DRAM suffers undervolt and quickly afterwards is
>> >> configured for regular operation ... I'd say check
>> >> mx23_mem_setup_vddmem() and inspect the result with a scope. I think we
>> >> need some slow ramping function like mxs_power_set_vddx().
>> >
>> > Ok, but can we have this patch applied and do this investigation in
>> > parallel?
>> >
>> > At least we could have U-boot usable on mx23 again.
>>
>> I also vote for it to be applied and then do this investigation in
>> parallel. Even if there're still pending issues it does improve the
>> current status.
>
> But someone has to do this! And so far I see noone capable/willing to do that :(

Oh really? Fabio, other people and me are doing it. We have some
people helping to debug it and using their time to help testing it so
it seems like a false accusation.

So as I said, I see no reason to not get this patch in for now.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
Marek Vasut - April 26, 2013, 11:33 p.m.
Dear Otavio Salvador,

> On Fri, Apr 26, 2013 at 5:58 PM, Marek Vasut <marex@denx.de> wrote:
> > Dear Otavio Salvador,
> > 
> >> On Fri, Apr 26, 2013 at 5:08 PM, Fabio Estevam <festevam@gmail.com> wrote:
> >> > On Fri, Apr 26, 2013 at 3:16 PM, Marek Vasut <marex@denx.de> wrote:
> >> >> strange at best and I don't like it. I think that's also the source
> >> >> of our problems, the DRAM suffers undervolt and quickly afterwards
> >> >> is configured for regular operation ... I'd say check
> >> >> mx23_mem_setup_vddmem() and inspect the result with a scope. I think
> >> >> we need some slow ramping function like mxs_power_set_vddx().
> >> > 
> >> > Ok, but can we have this patch applied and do this investigation in
> >> > parallel?
> >> > 
> >> > At least we could have U-boot usable on mx23 again.
> >> 
> >> I also vote for it to be applied and then do this investigation in
> >> parallel. Even if there're still pending issues it does improve the
> >> current status.
> > 
> > But someone has to do this! And so far I see noone capable/willing to do
> > that :(
> 
> Oh really? Fabio, other people and me are doing it. We have some
> people helping to debug it and using their time to help testing it so
> it seems like a false accusation.

it == grabbing a scope and doing the real measurement :(

> So as I said, I see no reason to not get this patch in for now.

I am not against in per-se. I am worried noone will come up with real fix when 
there is a "good enough plaster" put on to cover the real problem.

Best regards,
Marek Vasut
Stefano Babic - April 27, 2013, 11:09 a.m.
On 27/04/2013 01:33, Marek Vasut wrote:
> Dear Otavio Salvador,
> 

Hi Fabio, Otavio, Marek,

>> On Fri, Apr 26, 2013 at 5:58 PM, Marek Vasut <marex@denx.de> wrote:
>>> Dear Otavio Salvador,
>>>
>>>> On Fri, Apr 26, 2013 at 5:08 PM, Fabio Estevam <festevam@gmail.com> wrote:
>>>>> On Fri, Apr 26, 2013 at 3:16 PM, Marek Vasut <marex@denx.de> wrote:
>>>>>> strange at best and I don't like it. I think that's also the source
>>>>>> of our problems, the DRAM suffers undervolt and quickly afterwards
>>>>>> is configured for regular operation ... I'd say check
>>>>>> mx23_mem_setup_vddmem() and inspect the result with a scope. I think
>>>>>> we need some slow ramping function like mxs_power_set_vddx().
>>>>>
>>>>> Ok, but can we have this patch applied and do this investigation in
>>>>> parallel?
>>>>>
>>>>> At least we could have U-boot usable on mx23 again.
>>>>
>>>> I also vote for it to be applied and then do this investigation in
>>>> parallel. Even if there're still pending issues it does improve the
>>>> current status.
>>>
>>> But someone has to do this! And so far I see noone capable/willing to do
>>> that :(
>>
>> Oh really? Fabio, other people and me are doing it. We have some
>> people helping to debug it and using their time to help testing it so
>> it seems like a false accusation.
> 
> it == grabbing a scope and doing the real measurement :(
> 
>> So as I said, I see no reason to not get this patch in for now.
> 
> I am not against in per-se. I am worried noone will come up with real fix when 
> there is a "good enough plaster" put on to cover the real problem.

I agree that we have not yet found a clear cause of the behavior - but
ler me say that is quite bound to the hardware and how voltage is
applied to the DDR. As the patch reports to allow to boot kernel in most
cases, I agree with Fabio to apply this - and IMHO most investigation
should be done by the hardware developers.

Best regards,
Stefano
Marek Vasut - April 27, 2013, 11:34 a.m.
Dear Stefano Babic,

> On 27/04/2013 01:33, Marek Vasut wrote:
> > Dear Otavio Salvador,
> 
> Hi Fabio, Otavio, Marek,
> 
> >> On Fri, Apr 26, 2013 at 5:58 PM, Marek Vasut <marex@denx.de> wrote:
> >>> Dear Otavio Salvador,
> >>> 
> >>>> On Fri, Apr 26, 2013 at 5:08 PM, Fabio Estevam <festevam@gmail.com> 
wrote:
> >>>>> On Fri, Apr 26, 2013 at 3:16 PM, Marek Vasut <marex@denx.de> wrote:
> >>>>>> strange at best and I don't like it. I think that's also the source
> >>>>>> of our problems, the DRAM suffers undervolt and quickly afterwards
> >>>>>> is configured for regular operation ... I'd say check
> >>>>>> mx23_mem_setup_vddmem() and inspect the result with a scope. I think
> >>>>>> we need some slow ramping function like mxs_power_set_vddx().
> >>>>> 
> >>>>> Ok, but can we have this patch applied and do this investigation in
> >>>>> parallel?
> >>>>> 
> >>>>> At least we could have U-boot usable on mx23 again.
> >>>> 
> >>>> I also vote for it to be applied and then do this investigation in
> >>>> parallel. Even if there're still pending issues it does improve the
> >>>> current status.
> >>> 
> >>> But someone has to do this! And so far I see noone capable/willing to
> >>> do that :(
> >> 
> >> Oh really? Fabio, other people and me are doing it. We have some
> >> people helping to debug it and using their time to help testing it so
> >> it seems like a false accusation.
> > 
> > it == grabbing a scope and doing the real measurement :(
> > 
> >> So as I said, I see no reason to not get this patch in for now.
> > 
> > I am not against in per-se. I am worried noone will come up with real fix
> > when there is a "good enough plaster" put on to cover the real problem.
> 
> I agree that we have not yet found a clear cause of the behavior - but
> ler me say that is quite bound to the hardware and how voltage is
> applied to the DDR. As the patch reports to allow to boot kernel in most
> cases, I agree with Fabio to apply this - and IMHO most investigation
> should be done by the hardware developers.

Yes, I am already pestering Tsvetan to stop lazing around and do the measurement 
;-) Actually, CCed.

So far, we only have the VDDMEM graph which doesn't look nice :-(

Best regards,
Marek Vasut
Fabio Estevam - April 27, 2013, 5:28 p.m.
Hi Stefano,

On Sat, Apr 27, 2013 at 8:09 AM, Stefano Babic <sbabic@denx.de> wrote:

> I agree that we have not yet found a clear cause of the behavior - but
> ler me say that is quite bound to the hardware and how voltage is
> applied to the DDR. As the patch reports to allow to boot kernel in most
> cases, I agree with Fabio to apply this - and IMHO most investigation
> should be done by the hardware developers.

100% agreed. The patch I proposed can be seen as a workaround, not a real fix.

Applying it will give the benefit of allowing mx23 to boot a kernel
again, and then we can focus on the real fix, which requires a more
careful and detailed investigation.

Thanks,

Fabio Estevam
Otavio Salvador - April 27, 2013, 5:53 p.m.
On Sat, Apr 27, 2013 at 2:28 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Stefano,
>
> On Sat, Apr 27, 2013 at 8:09 AM, Stefano Babic <sbabic@denx.de> wrote:
>
>> I agree that we have not yet found a clear cause of the behavior - but
>> ler me say that is quite bound to the hardware and how voltage is
>> applied to the DDR. As the patch reports to allow to boot kernel in most
>> cases, I agree with Fabio to apply this - and IMHO most investigation
>> should be done by the hardware developers.
>
> 100% agreed. The patch I proposed can be seen as a workaround, not a real fix.
>
> Applying it will give the benefit of allowing mx23 to boot a kernel
> again, and then we can focus on the real fix, which requires a more
> careful and detailed investigation.

100% agreed as well.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
Marek Vasut - April 27, 2013, 6:39 p.m.
Dear Otavio Salvador,

> On Sat, Apr 27, 2013 at 2:28 PM, Fabio Estevam <festevam@gmail.com> wrote:
> > Hi Stefano,
> > 
> > On Sat, Apr 27, 2013 at 8:09 AM, Stefano Babic <sbabic@denx.de> wrote:
> >> I agree that we have not yet found a clear cause of the behavior - but
> >> ler me say that is quite bound to the hardware and how voltage is
> >> applied to the DDR. As the patch reports to allow to boot kernel in most
> >> cases, I agree with Fabio to apply this - and IMHO most investigation
> >> should be done by the hardware developers.
> > 
> > 100% agreed. The patch I proposed can be seen as a workaround, not a real
> > fix.
> > 
> > Applying it will give the benefit of allowing mx23 to boot a kernel
> > again, and then we can focus on the real fix, which requires a more
> > careful and detailed investigation.
> 
> 100% agreed as well.

So ... who is gonna make the measurements with a scope and come up with a proper 
patch, who's volunteering to do that please?

Best regards,
Marek Vasut
Stefano Babic - April 28, 2013, 9:06 a.m.
On 26/04/2013 18:01, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
> 
> commit 5c2f444c9 (mxs: Reset the EMI block on mx23) changed the DDR voltage 
> level, which causes mx23evk to fail to load a kernel.
> 
> Put back the original values, so that mx23evk can boot a kernel again.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---


Applied to u-boot-imx, thanks.

Best regards,
Stefano Babic
Marek Vasut - April 28, 2013, 11:06 p.m.
Dear Fabio Estevam,

> From: Fabio Estevam <fabio.estevam@freescale.com>
> 
> commit 5c2f444c9 (mxs: Reset the EMI block on mx23) changed the DDR voltage
> level, which causes mx23evk to fail to load a kernel.
> 
> Put back the original values, so that mx23evk can boot a kernel again.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>

So, here are the results from M28EVK and MX23EVK:

http://twilight.ponies.cz/MX23.tar.xz
http://twilight.ponies.cz/MX28.tar.xz

What you can see (rather what's wrong on MX23):
- VDDA should be 1V5, but jumps over 2V and stabilizes at 1V7
- VDDIO has some weird ripple where it goes to 3V5
- VDDMEM is FUBAR

Best regards,
Marek Vasut
Marek Vasut - April 28, 2013, 11:19 p.m.
Dear Fabio Estevam,
> 
> > From: Fabio Estevam <fabio.estevam@freescale.com>
> > 
> > commit 5c2f444c9 (mxs: Reset the EMI block on mx23) changed the DDR
> > voltage level, which causes mx23evk to fail to load a kernel.
> > 
> > Put back the original values, so that mx23evk can boot a kernel again.
> > 
> > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> 
> So, here are the results from M28EVK and MX23EVK:
> 
> http://twilight.ponies.cz/MX23.tar.xz
> http://twilight.ponies.cz/MX28.tar.xz
> 
> What you can see (rather what's wrong on MX23):
> - VDDA should be 1V5, but jumps over 2V and stabilizes at 1V7
> - VDDIO has some weird ripple where it goes to 3V5
> - VDDMEM is FUBAR

Ah btw this is stock 2013.04

Best regards,
Marek Vasut

Patch

diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
index bc2d69c..4950490 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -234,7 +234,7 @@  static void mx23_mem_setup_vddmem(void)
 	struct mxs_power_regs *power_regs =
 		(struct mxs_power_regs *)MXS_POWER_BASE;
 
-	writel((0x10 << POWER_VDDMEMCTRL_TRG_OFFSET) |
+	writel((0x12 << POWER_VDDMEMCTRL_TRG_OFFSET) |
 		POWER_VDDMEMCTRL_ENABLE_ILIMIT |
 		POWER_VDDMEMCTRL_ENABLE_LINREG |
 		POWER_VDDMEMCTRL_PULLDOWN_ACTIVE,
@@ -242,7 +242,7 @@  static void mx23_mem_setup_vddmem(void)
 
 	early_delay(10000);
 
-	writel((0x10 << POWER_VDDMEMCTRL_TRG_OFFSET) |
+	writel((0x12 << POWER_VDDMEMCTRL_TRG_OFFSET) |
 		POWER_VDDMEMCTRL_ENABLE_LINREG,
 		&power_regs->hw_power_vddmemctrl);
 }