[U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
From: Fabio Estevam fabio.estevam@freescale.com
Currently the following kernel hang happens when loading a 2.6.35 kernel from Freeescale on a mx28evk board:
RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Bus freq driver module loaded IMX usb wakeup probe usb h1 wakeup device is registered mxs_cpu_init: cpufreq init finished ...
Loading the same kernel using the bootlets from the imx-bootlets-src-10.12.01 package, the hang does not occur.
Comparing the DDR2 initialization from the bootlets code against the U-boot one, we can notice some mismatches, and after applying the same initialization into U-boot the 2.6.35 kernel can boot normally.
Also tested with 'mtest' command, which runs succesfully.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com --- Changes since v1: - Fix tabs/space confusion and only show the real context changes arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index f8392f6..2195dce 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -45,17 +45,17 @@ static uint32_t dram_vals[] = { 0x00000000, 0x00000000, 0x00010101, 0x01010101, 0x000f0f01, 0x0f02020a, 0x00000000, 0x00010101, 0x00000100, 0x00000100, 0x00000000, 0x00000002, - 0x01010000, 0x05060302, 0x06005003, 0x0a0000c8, - 0x02009c40, 0x0000030c, 0x0036a609, 0x031a0612, + 0x01010000, 0x07080403, 0x06005003, 0x0a0000c8, + 0x02009c40, 0x0002030c, 0x0036a609, 0x031a0612, 0x02030202, 0x00c8001c, 0x00000000, 0x00000000, 0x00012100, 0xffff0303, 0x00012100, 0xffff0303, 0x00012100, 0xffff0303, 0x00012100, 0xffff0303, 0x00000003, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000612, 0x01000F02, - 0x06120612, 0x00000200, 0x00020007, 0xf5014b27, - 0xf5014b27, 0xf5014b27, 0xf5014b27, 0x07000300, - 0x07000300, 0x07000300, 0x07000300, 0x00000006, + 0x06120612, 0x00000200, 0x00020007, 0xf4004a27, + 0xf4004a27, 0xf4004a27, 0xf4004a27, 0x07000300, + 0x07000300, 0x07400300, 0x07400300, 0x00000005, 0x00000000, 0x00000000, 0x01000000, 0x01020408, 0x08040201, 0x000f1133, 0x00000000, 0x00001f04, 0x00001f04, 0x00001f04, 0x00001f04, 0x00001f04, @@ -76,14 +76,14 @@ static uint32_t dram_vals[] = { 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, - 0x00000000, 0x00000000, 0x00010000, 0x00020304, - 0x00000004, 0x00000000, 0x00000000, 0x00000000, + 0x00000000, 0x00000000, 0x00010000, 0x00030404, + 0x00000003, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x01010000, 0x01000000, 0x03030000, 0x00010303, 0x01020202, 0x00000000, 0x02040303, 0x21002103, 0x00061200, - 0x06120612, 0x04320432, 0x04320432, 0x00040004, + 0x06120612, 0x04420442, 0x04420442, 0x00040004, 0x00040004, 0x00000000, 0x00000000, 0x00000000, - 0x00000000, 0x00010001 + 0x00000000, 0xffffffff
/* * i.MX23 DDR at 133MHz
On Thu, Feb 28, 2013 at 7:59 PM, Fabio Estevam festevam@gmail.com wrote:
From: Fabio Estevam fabio.estevam@freescale.com
Currently the following kernel hang happens when loading a 2.6.35 kernel from Freeescale on a mx28evk board:
RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Bus freq driver module loaded IMX usb wakeup probe usb h1 wakeup device is registered mxs_cpu_init: cpufreq init finished ...
Loading the same kernel using the bootlets from the imx-bootlets-src-10.12.01 package, the hang does not occur.
Comparing the DDR2 initialization from the bootlets code against the U-boot one, we can notice some mismatches, and after applying the same initialization into U-boot the 2.6.35 kernel can boot normally.
Also tested with 'mtest' command, which runs succesfully.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
Acked-by: Otavio Salvador otavio@ossystems.com.br
Dear Otavio Salvador,
On Thu, Feb 28, 2013 at 7:59 PM, Fabio Estevam festevam@gmail.com wrote:
From: Fabio Estevam fabio.estevam@freescale.com
Currently the following kernel hang happens when loading a 2.6.35 kernel from Freeescale on a mx28evk board:
RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Bus freq driver module loaded IMX usb wakeup probe usb h1 wakeup device is registered mxs_cpu_init: cpufreq init finished ...
Loading the same kernel using the bootlets from the imx-bootlets-src-10.12.01 package, the hang does not occur.
Comparing the DDR2 initialization from the bootlets code against the U-boot one, we can notice some mismatches, and after applying the same initialization into U-boot the 2.6.35 kernel can boot normally.
Also tested with 'mtest' command, which runs succesfully.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
Acked-by: Otavio Salvador otavio@ossystems.com.br
Otavio, did you review the changes done in this patch ?
Best regards, Marek Vasut
On Wed, Mar 6, 2013 at 11:31 AM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Thu, Feb 28, 2013 at 7:59 PM, Fabio Estevam festevam@gmail.com wrote:
From: Fabio Estevam fabio.estevam@freescale.com
Currently the following kernel hang happens when loading a 2.6.35 kernel from Freeescale on a mx28evk board:
RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Bus freq driver module loaded IMX usb wakeup probe usb h1 wakeup device is registered mxs_cpu_init: cpufreq init finished ...
Loading the same kernel using the bootlets from the imx-bootlets-src-10.12.01 package, the hang does not occur.
Comparing the DDR2 initialization from the bootlets code against the U-boot one, we can notice some mismatches, and after applying the same initialization into U-boot the 2.6.35 kernel can boot normally.
Also tested with 'mtest' command, which runs succesfully.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
Acked-by: Otavio Salvador otavio@ossystems.com.br
Otavio, did you review the changes done in this patch ?
This is the setup used in FSL U-Boot and it fixes 2.6.35.3 cpufreq kernel hang; it is good enough for me to accept it. If you care enough, go ahead and check every change bit.
Dear Otavio Salvador,
On Wed, Mar 6, 2013 at 11:31 AM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Thu, Feb 28, 2013 at 7:59 PM, Fabio Estevam festevam@gmail.com wrote:
From: Fabio Estevam fabio.estevam@freescale.com
Currently the following kernel hang happens when loading a 2.6.35 kernel from Freeescale on a mx28evk board:
RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Bus freq driver module loaded IMX usb wakeup probe usb h1 wakeup device is registered mxs_cpu_init: cpufreq init finished ...
Loading the same kernel using the bootlets from the imx-bootlets-src-10.12.01 package, the hang does not occur.
Comparing the DDR2 initialization from the bootlets code against the U-boot one, we can notice some mismatches, and after applying the same initialization into U-boot the 2.6.35 kernel can boot normally.
Also tested with 'mtest' command, which runs succesfully.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
Acked-by: Otavio Salvador otavio@ossystems.com.br
Otavio, did you review the changes done in this patch ?
This is the setup used in FSL U-Boot and it fixes 2.6.35.3 cpufreq kernel hang; it is good enough for me to accept it. If you care enough, go ahead and check every change bit.
That is indeed the plan, I will Ack this after I am done with it. It will still make it for .04, dont worry.
You should not Ack patches you did not even test nor validate, since the value of your Ack is declining.
Best regards, Marek Vasut
On Wed, Mar 6, 2013 at 12:41 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Wed, Mar 6, 2013 at 11:31 AM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Thu, Feb 28, 2013 at 7:59 PM, Fabio Estevam festevam@gmail.com wrote:
From: Fabio Estevam fabio.estevam@freescale.com
Currently the following kernel hang happens when loading a 2.6.35 kernel from Freeescale on a mx28evk board:
RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Bus freq driver module loaded IMX usb wakeup probe usb h1 wakeup device is registered mxs_cpu_init: cpufreq init finished ...
Loading the same kernel using the bootlets from the imx-bootlets-src-10.12.01 package, the hang does not occur.
Comparing the DDR2 initialization from the bootlets code against the U-boot one, we can notice some mismatches, and after applying the same initialization into U-boot the 2.6.35 kernel can boot normally.
Also tested with 'mtest' command, which runs succesfully.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
Acked-by: Otavio Salvador otavio@ossystems.com.br
Otavio, did you review the changes done in this patch ?
This is the setup used in FSL U-Boot and it fixes 2.6.35.3 cpufreq kernel hang; it is good enough for me to accept it. If you care enough, go ahead and check every change bit.
That is indeed the plan, I will Ack this after I am done with it. It will still make it for .04, dont worry.
You should not Ack patches you did not even test nor validate, since the value of your Ack is declining.
Are you sure you read my comment?
... it fixes 2.6.35.3 cpufreq kernel hang; ...
Regards,
-- 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 Wed, Mar 6, 2013 at 12:41 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Wed, Mar 6, 2013 at 11:31 AM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Thu, Feb 28, 2013 at 7:59 PM, Fabio Estevam festevam@gmail.com
wrote:
From: Fabio Estevam fabio.estevam@freescale.com
Currently the following kernel hang happens when loading a 2.6.35 kernel from Freeescale on a mx28evk board:
RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Bus freq driver module loaded IMX usb wakeup probe usb h1 wakeup device is registered mxs_cpu_init: cpufreq init finished ...
Loading the same kernel using the bootlets from the imx-bootlets-src-10.12.01 package, the hang does not occur.
Comparing the DDR2 initialization from the bootlets code against the U-boot one, we can notice some mismatches, and after applying the same initialization into U-boot the 2.6.35 kernel can boot normally.
Also tested with 'mtest' command, which runs succesfully.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
Acked-by: Otavio Salvador otavio@ossystems.com.br
Otavio, did you review the changes done in this patch ?
This is the setup used in FSL U-Boot and it fixes 2.6.35.3 cpufreq kernel hang; it is good enough for me to accept it. If you care enough, go ahead and check every change bit.
That is indeed the plan, I will Ack this after I am done with it. It will still make it for .04, dont worry.
You should not Ack patches you did not even test nor validate, since the value of your Ack is declining.
Are you sure you read my comment?
... it fixes 2.6.35.3 cpufreq kernel hang; ...
Yes, I did read it.
Best regards, Marek Vasut
On 28/02/2013 23:59, Fabio Estevam wrote:
From: Fabio Estevam fabio.estevam@freescale.com
Currently the following kernel hang happens when loading a 2.6.35 kernel from Freeescale on a mx28evk board:
RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Bus freq driver module loaded IMX usb wakeup probe usb h1 wakeup device is registered mxs_cpu_init: cpufreq init finished ...
Hi all,
Loading the same kernel using the bootlets from the imx-bootlets-src-10.12.01 package, the hang does not occur.
Comparing the DDR2 initialization from the bootlets code against the U-boot one, we can notice some mismatches, and after applying the same initialization into U-boot the 2.6.35 kernel can boot normally.
Also tested with 'mtest' command, which runs succesfully.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
Changes since v1:
- Fix tabs/space confusion and only show the real context changes
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index f8392f6..2195dce 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -45,17 +45,17 @@ static uint32_t dram_vals[] = { 0x00000000, 0x00000000, 0x00010101, 0x01010101, 0x000f0f01, 0x0f02020a, 0x00000000, 0x00010101, 0x00000100, 0x00000100, 0x00000000, 0x00000002,
- 0x01010000, 0x05060302, 0x06005003, 0x0a0000c8,
- 0x02009c40, 0x0000030c, 0x0036a609, 0x031a0612,
- 0x01010000, 0x07080403, 0x06005003, 0x0a0000c8,
- 0x02009c40, 0x0002030c, 0x0036a609, 0x031a0612, 0x02030202, 0x00c8001c, 0x00000000, 0x00000000, 0x00012100, 0xffff0303, 0x00012100, 0xffff0303, 0x00012100, 0xffff0303, 0x00012100, 0xffff0303, 0x00000003, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000612, 0x01000F02,
- 0x06120612, 0x00000200, 0x00020007, 0xf5014b27,
- 0xf5014b27, 0xf5014b27, 0xf5014b27, 0x07000300,
- 0x07000300, 0x07000300, 0x07000300, 0x00000006,
- 0x06120612, 0x00000200, 0x00020007, 0xf4004a27,
- 0xf4004a27, 0xf4004a27, 0xf4004a27, 0x07000300,
- 0x07000300, 0x07400300, 0x07400300, 0x00000005, 0x00000000, 0x00000000, 0x01000000, 0x01020408, 0x08040201, 0x000f1133, 0x00000000, 0x00001f04, 0x00001f04, 0x00001f04, 0x00001f04, 0x00001f04,
@@ -76,14 +76,14 @@ static uint32_t dram_vals[] = { 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
- 0x00000000, 0x00000000, 0x00010000, 0x00020304,
- 0x00000004, 0x00000000, 0x00000000, 0x00000000,
- 0x00000000, 0x00000000, 0x00010000, 0x00030404,
- 0x00000003, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x01010000, 0x01000000, 0x03030000, 0x00010303, 0x01020202, 0x00000000, 0x02040303, 0x21002103, 0x00061200,
- 0x06120612, 0x04320432, 0x04320432, 0x00040004,
- 0x06120612, 0x04420442, 0x04420442, 0x00040004, 0x00040004, 0x00000000, 0x00000000, 0x00000000,
- 0x00000000, 0x00010001
- 0x00000000, 0xffffffff
/*
- i.MX23 DDR at 133MHz
Apart of the fact that fixes booting old kernel, these changes affects all mx28 boards, not only mx28evk. Can we have a description about which changes are done and why they are required ?
Else to be accepted we need at least a Tested-vy for all boards using it.
Regards, Stefano
Hi Stefano,
On Wed, Mar 13, 2013 at 5:16 AM, Stefano Babic sbabic@denx.de wrote:
Apart of the fact that fixes booting old kernel, these changes affects all mx28 boards, not only mx28evk. Can we have a description about which changes are done and why they are required ?
Else to be accepted we need at least a Tested-vy for all boards using it.
Yes, having a Tested-by would be really nice.
Currently we have the following mx28 based boards that still needs to be tested:
apx4devkit, m28evk and sc_sps_1.
Veli-Pekka/Marek,
Could you please try this patch on your systems?
About the description of the changes: I haven't really gone deep into the path of comparing all the bits that changed. I simply took a working DDR init script for mx28evk from imx bootlets code and used it.
Moving forward, I think we should split the DDR init per board instead of a global init.
Regards,
Fabio Estevam
Lauri,
On Wed, Mar 13, 2013 at 11:18 AM, Fabio Estevam festevam@gmail.com wrote:
Hi Stefano,
On Wed, Mar 13, 2013 at 5:16 AM, Stefano Babic sbabic@denx.de wrote:
Apart of the fact that fixes booting old kernel, these changes affects all mx28 boards, not only mx28evk. Can we have a description about which changes are done and why they are required ?
Else to be accepted we need at least a Tested-vy for all boards using it.
Yes, having a Tested-by would be really nice.
Currently we have the following mx28 based boards that still needs to be tested:
apx4devkit, m28evk and sc_sps_1.
Veli-Pekka/Marek,
Could you please try this patch on your systems?
Veli-Pekka's email bounced. Would you have a chance to test it?
Thanks,
Fabio Estevam
Hi,
On 03/13/2013 04:22 PM, Fabio Estevam wrote:
Lauri,
On Wed, Mar 13, 2013 at 11:18 AM, Fabio Estevam festevam@gmail.com wrote:
Hi Stefano,
On Wed, Mar 13, 2013 at 5:16 AM, Stefano Babic sbabic@denx.de wrote:
Apart of the fact that fixes booting old kernel, these changes affects all mx28 boards, not only mx28evk. Can we have a description about which changes are done and why they are required ?
Else to be accepted we need at least a Tested-vy for all boards using it.
Yes, having a Tested-by would be really nice.
Currently we have the following mx28 based boards that still needs to be tested:
apx4devkit, m28evk and sc_sps_1.
Veli-Pekka/Marek,
Could you please try this patch on your systems?
Veli-Pekka's email bounced. Would you have a chance to test it?
Yes, I'll test the patch.
Lauri
On Thu, Mar 14, 2013 at 2:09 AM, Lauri Hintsala lauri.hintsala@bluegiga.com wrote:
Hi,
On 03/13/2013 04:22 PM, Fabio Estevam wrote:
Lauri,
On Wed, Mar 13, 2013 at 11:18 AM, Fabio Estevam festevam@gmail.com wrote:
Hi Stefano,
On Wed, Mar 13, 2013 at 5:16 AM, Stefano Babic sbabic@denx.de wrote:
Apart of the fact that fixes booting old kernel, these changes affects all mx28 boards, not only mx28evk. Can we have a description about which changes are done and why they are required ?
Else to be accepted we need at least a Tested-vy for all boards using it.
Yes, having a Tested-by would be really nice.
Currently we have the following mx28 based boards that still needs to be tested:
apx4devkit, m28evk and sc_sps_1.
Veli-Pekka/Marek,
Could you please try this patch on your systems?
Veli-Pekka's email bounced. Would you have a chance to test it?
Yes, I'll test the patch.
Lauri, did you give this patch?
Dear Stefano Babic,
On 28/02/2013 23:59, Fabio Estevam wrote:
From: Fabio Estevam fabio.estevam@freescale.com
Currently the following kernel hang happens when loading a 2.6.35 kernel from Freeescale on a mx28evk board:
RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Bus freq driver module loaded IMX usb wakeup probe usb h1 wakeup device is registered mxs_cpu_init: cpufreq init finished ...
Hi all,
Loading the same kernel using the bootlets from the imx-bootlets-src-10.12.01 package, the hang does not occur.
Comparing the DDR2 initialization from the bootlets code against the U-boot one, we can notice some mismatches, and after applying the same initialization into U-boot the 2.6.35 kernel can boot normally.
Also tested with 'mtest' command, which runs succesfully.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
Changes since v1:
- Fix tabs/space confusion and only show the real context changes
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index f8392f6..2195dce 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -45,17 +45,17 @@ static uint32_t dram_vals[] = {
0x00000000, 0x00000000, 0x00010101, 0x01010101, 0x000f0f01, 0x0f02020a, 0x00000000, 0x00010101, 0x00000100, 0x00000100, 0x00000000, 0x00000002,
- 0x01010000, 0x05060302, 0x06005003, 0x0a0000c8,
- 0x02009c40, 0x0000030c, 0x0036a609, 0x031a0612,
0x01010000, 0x07080403, 0x06005003, 0x0a0000c8,
0x02009c40, 0x0002030c, 0x0036a609, 0x031a0612,
0x02030202, 0x00c8001c, 0x00000000, 0x00000000, 0x00012100, 0xffff0303, 0x00012100, 0xffff0303, 0x00012100, 0xffff0303, 0x00012100, 0xffff0303, 0x00000003, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000612, 0x01000F02,
- 0x06120612, 0x00000200, 0x00020007, 0xf5014b27,
- 0xf5014b27, 0xf5014b27, 0xf5014b27, 0x07000300,
- 0x07000300, 0x07000300, 0x07000300, 0x00000006,
0x06120612, 0x00000200, 0x00020007, 0xf4004a27,
0xf4004a27, 0xf4004a27, 0xf4004a27, 0x07000300,
0x07000300, 0x07400300, 0x07400300, 0x00000005,
0x00000000, 0x00000000, 0x01000000, 0x01020408, 0x08040201, 0x000f1133, 0x00000000, 0x00001f04, 0x00001f04, 0x00001f04, 0x00001f04, 0x00001f04,
@@ -76,14 +76,14 @@ static uint32_t dram_vals[] = {
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
- 0x00000000, 0x00000000, 0x00010000, 0x00020304,
- 0x00000004, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00010000, 0x00030404,
0x00000003, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x01010000, 0x01000000, 0x03030000, 0x00010303, 0x01020202, 0x00000000, 0x02040303, 0x21002103, 0x00061200,
- 0x06120612, 0x04320432, 0x04320432, 0x00040004,
0x06120612, 0x04420442, 0x04420442, 0x00040004,
0x00040004, 0x00000000, 0x00000000, 0x00000000,
- 0x00000000, 0x00010001
- 0x00000000, 0xffffffff
/*
- i.MX23 DDR at 133MHz
Apart of the fact that fixes booting old kernel, these changes affects all mx28 boards, not only mx28evk. Can we have a description about which changes are done and why they are required ?
Please see [1] below, this describes the situation at hand perfectly :-)
Other than that, I tested it and see no issue.
Else to be accepted we need at least a Tested-vy for all boards using it.
Regards, Stefano
[1] http://devopsreactions.tumblr.com/post/40166795163/when-you-review- undocumented-code
On 13/03/2013 17:01, Marek Vasut wrote:
Apart of the fact that fixes booting old kernel, these changes affects all mx28 boards, not only mx28evk. Can we have a description about which changes are done and why they are required ?
Please see [1] below, this describes the situation at hand perfectly :-)
Other than that, I tested it and see no issue.
Else to be accepted we need at least a Tested-vy for all boards using it.
Regards, Stefano
[1] http://devopsreactions.tumblr.com/post/40166795163/when-you-review- undocumented-code
It is perfect for this sort of hexadecimal tables !
Regards, Stefano
Dear Fabio Estevam,
From: Fabio Estevam fabio.estevam@freescale.com
Currently the following kernel hang happens when loading a 2.6.35 kernel from Freeescale on a mx28evk board:
RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Bus freq driver module loaded IMX usb wakeup probe usb h1 wakeup device is registered mxs_cpu_init: cpufreq init finished ...
Loading the same kernel using the bootlets from the imx-bootlets-src-10.12.01 package, the hang does not occur.
Comparing the DDR2 initialization from the bootlets code against the U-boot one, we can notice some mismatches, and after applying the same initialization into U-boot the 2.6.35 kernel can boot normally.
Also tested with 'mtest' command, which runs succesfully.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
On M28EVK:
Tested-by: Marek Vasut marex@denx.de
Best regards, Marek Vasut
Hi,
On 03/01/2013 12:59 AM, Fabio Estevam wrote:
From: Fabio Estevam fabio.estevam@freescale.com
Currently the following kernel hang happens when loading a 2.6.35 kernel from Freeescale on a mx28evk board:
RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Bus freq driver module loaded IMX usb wakeup probe usb h1 wakeup device is registered mxs_cpu_init: cpufreq init finished ...
I tried to boot Freescale's 2.6.35.3 kernel on apx4devkit. The device is still freezing after mxs_cpu_init print.
Full logs:
U-Boot 2013.04-rc1-00002-g9659479 (Mar 19 2013 - 08:30:05)
CPU: Freescale i.MX28 rev1.2 at 454 MHz BOOT: SSP SD/MMC #0, 3V3 I2C: ready DRAM: 64 MiB NAND: 128 MiB MMC: MXS MMC: 0 In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0
1944456 bytes read in 754 ms (2.5 MiB/s) ## Booting kernel from Legacy Image at 41000000 ... Image Name: Linux-2.6.35.3-01010-ge53a812 Created: 2013-03-19 6:31:40 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1944392 Bytes = 1.9 MiB Load Address: 40008000 Entry Point: 40008000 Loading Kernel Image ... OK OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel. Linux version 2.6.35.3-01010-ge53a812 (hintsla@bgtlh) (gcc version 4.3.4 (crosstool-NG-1.7.0) ) #32 Tue Mar 19 08:31:39 EET 2013 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 CPU: VIVT data cache, VIVT instruction cache Machine: Freescale MX28EVK board Memory policy: ECC disabled, Data cache writeback Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: console=tty0 console=ttyAMA0,115200 consoleblank=0 ethaddr=00:07:80:01:66:db btaddr=00:07:80:01:67:0d wlanaddr=00:07:80:59:ef:64 root=/dev/mmcblk0p2 rootwait mtdparts=gpmi-nand:128k(bootstrap),1024k(boot),768k(env),-(root) rw PID hash table entries: 256 (order: -2, 1024 bytes) Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 64MB = 64MB total Memory: 60880k/60880k available, 4656k reserved, 0K highmem Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) DMA : 0xfde00000 - 0xffe00000 ( 32 MB) vmalloc : 0xc4800000 - 0xf0000000 ( 696 MB) lowmem : 0xc0000000 - 0xc4000000 ( 64 MB) modules : 0xbf000000 - 0xc0000000 ( 16 MB) .init : 0xc0008000 - 0xc002d000 ( 148 kB) .text : 0xc002d000 - 0xc03b8000 (3628 kB) .data : 0xc03b8000 - 0xc03e4ba0 ( 179 kB) SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Hierarchical RCU implementation. RCU-based detection of stalled CPUs is disabled. Verbose stalled-CPUs detection is disabled. NR_IRQS:288 Console: colour dummy device 80x30 console [tty0] enabled console [ttyAMA0] enabled Calibrating delay loop... 226.09 BogoMIPS (lpj=1130496) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok regulator: core version 0.5 NET: Registered protocol family 16 regulator: vddd: 800 <--> 1575 mV at 1500 mV fast normal regulator: vdddbo: 800 <--> 1575 mV fast normal regulator: vdda: 1500 <--> 2275 mV at 1800 mV fast normal vddio = 3380000, val=10 regulator: vddio: 2880 <--> 3680 mV at 3380 mV fast normal regulator: overall_current: fast normal regulator: vbus5v: regulator: mxs-duart-1: fast normal regulator: mxs-bl-1: fast normal regulator: mxs-i2c-1: fast normal regulator: mmc_ssp-1: fast normal regulator: mmc_ssp-2: fast normal regulator: charger-1: fast normal regulator: power-test-1: fast normal regulator: cpufreq-1: fast normal i.MX IRAM pool: 124 KB@0xc4820000 Initializing GPMI pins Initializing SSP2 pins bio: create slab <bio-0> at 0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb Advanced Linux Sound Architecture Driver Version 1.0.23. IMX usb wakeup probe usb DR wakeup device is registered Switching to clocksource mxs clock source NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) Switched to NOHz mode on CPU #0 TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered UDP hash table entries: 256 (order: 0, 4096 bytes) UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) NET: Registered protocol family 1 RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Bus freq driver module loaded IMX usb wakeup probe usb h1 wakeup device is registered WARNING : No battery connected ! Aborting power driver initialization mxs-battery: probe of mxs-battery.0 failed with error 1 mxs_cpu_init: cpufreq init finished
And after that line the device is completely dead.
Lauri
Loading the same kernel using the bootlets from the imx-bootlets-src-10.12.01 package, the hang does not occur.
Comparing the DDR2 initialization from the bootlets code against the U-boot one, we can notice some mismatches, and after applying the same initialization into U-boot the 2.6.35 kernel can boot normally.
Also tested with 'mtest' command, which runs succesfully.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
Changes since v1:
- Fix tabs/space confusion and only show the real context changes arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index f8392f6..2195dce 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -45,17 +45,17 @@ static uint32_t dram_vals[] = { 0x00000000, 0x00000000, 0x00010101, 0x01010101, 0x000f0f01, 0x0f02020a, 0x00000000, 0x00010101, 0x00000100, 0x00000100, 0x00000000, 0x00000002,
- 0x01010000, 0x05060302, 0x06005003, 0x0a0000c8,
- 0x02009c40, 0x0000030c, 0x0036a609, 0x031a0612,
- 0x01010000, 0x07080403, 0x06005003, 0x0a0000c8,
- 0x02009c40, 0x0002030c, 0x0036a609, 0x031a0612, 0x02030202, 0x00c8001c, 0x00000000, 0x00000000, 0x00012100, 0xffff0303, 0x00012100, 0xffff0303, 0x00012100, 0xffff0303, 0x00012100, 0xffff0303, 0x00000003, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000612, 0x01000F02,
- 0x06120612, 0x00000200, 0x00020007, 0xf5014b27,
- 0xf5014b27, 0xf5014b27, 0xf5014b27, 0x07000300,
- 0x07000300, 0x07000300, 0x07000300, 0x00000006,
- 0x06120612, 0x00000200, 0x00020007, 0xf4004a27,
- 0xf4004a27, 0xf4004a27, 0xf4004a27, 0x07000300,
- 0x07000300, 0x07400300, 0x07400300, 0x00000005, 0x00000000, 0x00000000, 0x01000000, 0x01020408, 0x08040201, 0x000f1133, 0x00000000, 0x00001f04, 0x00001f04, 0x00001f04, 0x00001f04, 0x00001f04,
@@ -76,14 +76,14 @@ static uint32_t dram_vals[] = { 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
- 0x00000000, 0x00000000, 0x00010000, 0x00020304,
- 0x00000004, 0x00000000, 0x00000000, 0x00000000,
- 0x00000000, 0x00000000, 0x00010000, 0x00030404,
- 0x00000003, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x01010000, 0x01000000, 0x03030000, 0x00010303, 0x01020202, 0x00000000, 0x02040303, 0x21002103, 0x00061200,
- 0x06120612, 0x04320432, 0x04320432, 0x00040004,
- 0x06120612, 0x04420442, 0x04420442, 0x00040004, 0x00040004, 0x00000000, 0x00000000, 0x00000000,
- 0x00000000, 0x00010001
0x00000000, 0xffffffff
/*
- i.MX23 DDR at 133MHz
On Tue, Mar 19, 2013 at 3:52 AM, Lauri Hintsala lauri.hintsala@bluegiga.com wrote:
Hi,
On 03/01/2013 12:59 AM, Fabio Estevam wrote:
From: Fabio Estevam fabio.estevam@freescale.com
Currently the following kernel hang happens when loading a 2.6.35 kernel from Freeescale on a mx28evk board:
RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Bus freq driver module loaded IMX usb wakeup probe usb h1 wakeup device is registered mxs_cpu_init: cpufreq init finished ...
I tried to boot Freescale's 2.6.35.3 kernel on apx4devkit. The device is still freezing after mxs_cpu_init print.
Full logs:
U-Boot 2013.04-rc1-00002-g9659479 (Mar 19 2013 - 08:30:05)
CPU: Freescale i.MX28 rev1.2 at 454 MHz BOOT: SSP SD/MMC #0, 3V3 I2C: ready DRAM: 64 MiB NAND: 128 MiB MMC: MXS MMC: 0 In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0
1944456 bytes read in 754 ms (2.5 MiB/s) ## Booting kernel from Legacy Image at 41000000 ... Image Name: Linux-2.6.35.3-01010-ge53a812 Created: 2013-03-19 6:31:40 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1944392 Bytes = 1.9 MiB Load Address: 40008000 Entry Point: 40008000 Loading Kernel Image ... OK OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel. Linux version 2.6.35.3-01010-ge53a812 (hintsla@bgtlh) (gcc version 4.3.4 (crosstool-NG-1.7.0) ) #32 Tue Mar 19 08:31:39 EET 2013 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 CPU: VIVT data cache, VIVT instruction cache Machine: Freescale MX28EVK board Memory policy: ECC disabled, Data cache writeback Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: console=tty0 console=ttyAMA0,115200 consoleblank=0 ethaddr=00:07:80:01:66:db btaddr=00:07:80:01:67:0d wlanaddr=00:07:80:59:ef:64 root=/dev/mmcblk0p2 rootwait mtdparts=gpmi-nand:128k(bootstrap),1024k(boot),768k(env),-(root) rw PID hash table entries: 256 (order: -2, 1024 bytes) Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 64MB = 64MB total Memory: 60880k/60880k available, 4656k reserved, 0K highmem Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) DMA : 0xfde00000 - 0xffe00000 ( 32 MB) vmalloc : 0xc4800000 - 0xf0000000 ( 696 MB) lowmem : 0xc0000000 - 0xc4000000 ( 64 MB) modules : 0xbf000000 - 0xc0000000 ( 16 MB) .init : 0xc0008000 - 0xc002d000 ( 148 kB) .text : 0xc002d000 - 0xc03b8000 (3628 kB) .data : 0xc03b8000 - 0xc03e4ba0 ( 179 kB) SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Hierarchical RCU implementation. RCU-based detection of stalled CPUs is disabled. Verbose stalled-CPUs detection is disabled. NR_IRQS:288 Console: colour dummy device 80x30 console [tty0] enabled console [ttyAMA0] enabled Calibrating delay loop... 226.09 BogoMIPS (lpj=1130496) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok regulator: core version 0.5 NET: Registered protocol family 16 regulator: vddd: 800 <--> 1575 mV at 1500 mV fast normal regulator: vdddbo: 800 <--> 1575 mV fast normal regulator: vdda: 1500 <--> 2275 mV at 1800 mV fast normal vddio = 3380000, val=10 regulator: vddio: 2880 <--> 3680 mV at 3380 mV fast normal regulator: overall_current: fast normal regulator: vbus5v: regulator: mxs-duart-1: fast normal regulator: mxs-bl-1: fast normal regulator: mxs-i2c-1: fast normal regulator: mmc_ssp-1: fast normal regulator: mmc_ssp-2: fast normal regulator: charger-1: fast normal regulator: power-test-1: fast normal regulator: cpufreq-1: fast normal i.MX IRAM pool: 124 KB@0xc4820000 Initializing GPMI pins Initializing SSP2 pins bio: create slab <bio-0> at 0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb Advanced Linux Sound Architecture Driver Version 1.0.23. IMX usb wakeup probe usb DR wakeup device is registered Switching to clocksource mxs clock source NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) Switched to NOHz mode on CPU #0 TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered UDP hash table entries: 256 (order: 0, 4096 bytes) UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) NET: Registered protocol family 1 RPC: Registered udp transport module.
RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Bus freq driver module loaded IMX usb wakeup probe usb h1 wakeup device is registered WARNING : No battery connected ! Aborting power driver initialization mxs-battery: probe of mxs-battery.0 failed with error 1 mxs_cpu_init: cpufreq init finished
And after that line the device is completely dead.
Are you sure you booted it with the Fabio's patch applied; this is exactly how it behaves *without* it.
On 03/19/2013 01:35 PM, Otavio Salvador wrote:
On Tue, Mar 19, 2013 at 3:52 AM, Lauri Hintsala lauri.hintsala@bluegiga.com wrote:
Hi,
On 03/01/2013 12:59 AM, Fabio Estevam wrote:
From: Fabio Estevam fabio.estevam@freescale.com
Currently the following kernel hang happens when loading a 2.6.35 kernel from Freeescale on a mx28evk board:
RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Bus freq driver module loaded IMX usb wakeup probe usb h1 wakeup device is registered mxs_cpu_init: cpufreq init finished ...
I tried to boot Freescale's 2.6.35.3 kernel on apx4devkit. The device is still freezing after mxs_cpu_init print.
Full logs:
U-Boot 2013.04-rc1-00002-g9659479 (Mar 19 2013 - 08:30:05)
CPU: Freescale i.MX28 rev1.2 at 454 MHz BOOT: SSP SD/MMC #0, 3V3 I2C: ready DRAM: 64 MiB NAND: 128 MiB MMC: MXS MMC: 0 In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0
1944456 bytes read in 754 ms (2.5 MiB/s) ## Booting kernel from Legacy Image at 41000000 ... Image Name: Linux-2.6.35.3-01010-ge53a812 Created: 2013-03-19 6:31:40 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1944392 Bytes = 1.9 MiB Load Address: 40008000 Entry Point: 40008000 Loading Kernel Image ... OK OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel. Linux version 2.6.35.3-01010-ge53a812 (hintsla@bgtlh) (gcc version 4.3.4 (crosstool-NG-1.7.0) ) #32 Tue Mar 19 08:31:39 EET 2013 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 CPU: VIVT data cache, VIVT instruction cache Machine: Freescale MX28EVK board Memory policy: ECC disabled, Data cache writeback Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: console=tty0 console=ttyAMA0,115200 consoleblank=0 ethaddr=00:07:80:01:66:db btaddr=00:07:80:01:67:0d wlanaddr=00:07:80:59:ef:64 root=/dev/mmcblk0p2 rootwait mtdparts=gpmi-nand:128k(bootstrap),1024k(boot),768k(env),-(root) rw PID hash table entries: 256 (order: -2, 1024 bytes) Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 64MB = 64MB total Memory: 60880k/60880k available, 4656k reserved, 0K highmem Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) DMA : 0xfde00000 - 0xffe00000 ( 32 MB) vmalloc : 0xc4800000 - 0xf0000000 ( 696 MB) lowmem : 0xc0000000 - 0xc4000000 ( 64 MB) modules : 0xbf000000 - 0xc0000000 ( 16 MB) .init : 0xc0008000 - 0xc002d000 ( 148 kB) .text : 0xc002d000 - 0xc03b8000 (3628 kB) .data : 0xc03b8000 - 0xc03e4ba0 ( 179 kB) SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Hierarchical RCU implementation. RCU-based detection of stalled CPUs is disabled. Verbose stalled-CPUs detection is disabled. NR_IRQS:288 Console: colour dummy device 80x30 console [tty0] enabled console [ttyAMA0] enabled Calibrating delay loop... 226.09 BogoMIPS (lpj=1130496) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok regulator: core version 0.5 NET: Registered protocol family 16 regulator: vddd: 800 <--> 1575 mV at 1500 mV fast normal regulator: vdddbo: 800 <--> 1575 mV fast normal regulator: vdda: 1500 <--> 2275 mV at 1800 mV fast normal vddio = 3380000, val=10 regulator: vddio: 2880 <--> 3680 mV at 3380 mV fast normal regulator: overall_current: fast normal regulator: vbus5v: regulator: mxs-duart-1: fast normal regulator: mxs-bl-1: fast normal regulator: mxs-i2c-1: fast normal regulator: mmc_ssp-1: fast normal regulator: mmc_ssp-2: fast normal regulator: charger-1: fast normal regulator: power-test-1: fast normal regulator: cpufreq-1: fast normal i.MX IRAM pool: 124 KB@0xc4820000 Initializing GPMI pins Initializing SSP2 pins bio: create slab <bio-0> at 0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb Advanced Linux Sound Architecture Driver Version 1.0.23. IMX usb wakeup probe usb DR wakeup device is registered Switching to clocksource mxs clock source NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) Switched to NOHz mode on CPU #0 TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered UDP hash table entries: 256 (order: 0, 4096 bytes) UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) NET: Registered protocol family 1 RPC: Registered udp transport module.
RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Bus freq driver module loaded IMX usb wakeup probe usb h1 wakeup device is registered WARNING : No battery connected ! Aborting power driver initialization mxs-battery: probe of mxs-battery.0 failed with error 1 mxs_cpu_init: cpufreq init finished
And after that line the device is completely dead.
Are you sure you booted it with the Fabio's patch applied; this is exactly how it behaves *without* it.
Yes, I am. I booted up U-Boot version "2013.04-rc1-00002-g9659479 (Mar 19 2013 - 08:30:05)" and my git log says:
$ git log --oneline -3 9659479 (HEAD) mxs: spl_mem_init: Align DDR2 init with FSL bootlets source 7ddcf4c ARM: mxs: disable battery charger circuit 2536850 (tag: v2013.04-rc1) Prepare v2013.04-rc1
Battery charger patch is very simple and it shouldn't affect to this problem any way:
--- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c @@ -918,6 +918,9 @@ void mxs_power_init(void)
writel(POWER_5VCTRL_PWDN_5VBRNOUT, &power_regs->hw_power_5vctrl_set);
+ /* Disable battery charger circuit */ + power_regs->hw_power_charge_set = POWER_CHARGE_PWD_BATTCHRG; + early_delay(1000); }
Lauri
Hi Lauri,
On Tue, Mar 19, 2013 at 8:43 AM, Lauri Hintsala lauri.hintsala@bluegiga.com wrote:
Battery charger patch is very simple and it shouldn't affect to this problem any way:
--- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c @@ -918,6 +918,9 @@ void mxs_power_init(void)
writel(POWER_5VCTRL_PWDN_5VBRNOUT,&power_regs->hw_power_5vctrl_set);
/* Disable battery charger circuit */power_regs->hw_power_charge_set = POWER_CHARGE_PWD_BATTCHRG;early_delay(1000);
What about this change? Do you plan to submit this as a patch?
On Tue, Mar 19, 2013 at 3:52 AM, Lauri Hintsala lauri.hintsala@bluegiga.com wrote:
I tried to boot Freescale's 2.6.35.3 kernel on apx4devkit. The device is still freezing after mxs_cpu_init print.
Are you able to boot 3.8?
I assume that the freeze still happened without this patch, right?
On 03/19/2013 02:36 PM, Fabio Estevam wrote:
On Tue, Mar 19, 2013 at 3:52 AM, Lauri Hintsala lauri.hintsala@bluegiga.com wrote:
I tried to boot Freescale's 2.6.35.3 kernel on apx4devkit. The device is still freezing after mxs_cpu_init print.
Are you able to boot 3.8?
I booted up to 3.2.
I assume that the freeze still happened without this patch, right?
The freeze happens with and without this patch if I use 2.6.35.3 kernel from Freescale.
Lauri
On Wed, Mar 20, 2013 at 2:17 AM, Lauri Hintsala lauri.hintsala@bluegiga.com wrote:
Are you able to boot 3.8?
I booted up to 3.2.
I assume that the freeze still happened without this patch, right?
The freeze happens with and without this patch if I use 2.6.35.3 kernel from Freescale.
Thanks for testing, Lauri.
I think the issue with cpufreq still happens for you on 2.6.35 because you may use a different DDR model/topology than the one in mx28evk.
Stefano,
Since this patch does not cause any problems and does fix the 2.6.35 boot on mx28evk, is it possible to apply it for 2013.04?
Thanks,
Fabio Estevam
On 20/03/2013 06:33, Fabio Estevam wrote:
On Wed, Mar 20, 2013 at 2:17 AM, Lauri Hintsala lauri.hintsala@bluegiga.com wrote:
Are you able to boot 3.8?
I booted up to 3.2.
I assume that the freeze still happened without this patch, right?
The freeze happens with and without this patch if I use 2.6.35.3 kernel from Freescale.
Thanks for testing, Lauri.
I think the issue with cpufreq still happens for you on 2.6.35 because you may use a different DDR model/topology than the one in mx28evk.
Stefano,
Since this patch does not cause any problems and does fix the 2.6.35 boot on mx28evk, is it possible to apply it for 2013.04?
Agree - I merge it.
Regards, Stefano
On 28/02/2013 23:59, Fabio Estevam wrote:
From: Fabio Estevam fabio.estevam@freescale.com
Currently the following kernel hang happens when loading a 2.6.35 kernel from Freeescale on a mx28evk board:
RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Bus freq driver module loaded IMX usb wakeup probe usb h1 wakeup device is registered mxs_cpu_init: cpufreq init finished ...
Applied to u-boot-imx, thanks.
Best regards, Stefano Babic
participants (5)
-
Fabio Estevam -
Lauri Hintsala -
Marek Vasut -
Otavio Salvador -
Stefano Babic