[U-Boot] [PATCH] mx23: Put back RAM voltage level to its original value
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(-)
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); }
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
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
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
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? ;-)
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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.
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
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.
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
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,
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
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
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
participants (6)
-
Eric Bénard -
Fabio Estevam -
Marek Vasut -
Otavio Salvador -
Robert Nelson -
Stefano Babic