Revert "i.MX28: Enable additional DRAM address bits"
PATCH v2 1/4 Revert "i.MX28: Enable additional DRAM address bits"
This reverts commit 69d26d09de1cb93e0a09ca71d9f0d41a66f0756a.
Apparently, this commit got mainline only because of out-of-tree port and causes breakage on board that is mainline. Revert.
Reason:
* The OOT board has 512MB of DRAM, enabling this additional address line enabled it to work fine with 512MB of RAM.
* Every mainline port has max. 256MB of DRAM, therefore this revert has no impact on any mainline port
* Though this caused a problem with new M28 board with 256MB of DRAM where the chips are wired differently. The patch-to-be-reverted caused the DRAM to behave like this:
[128MB chunk #1][128MB chunk #1 again][128MB chunk #2][128MB chunk #2 again]
Therefore to retain the current one-memory-init-rules-them-all situation, revert this patch until another board emerges and will actually be pushed mainline that needs different setup.
--- arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
V2: Update description of the patch (thanks for pushing me to do better job,
Detlev!)
arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c +1 -1
@@ -39,7 +39,7 @@ uint32_t dram_vals[] = {0x00000000 ,0x00000100 ,0x00000000 ,0x00000000 ,0x00000000 ,0x00000000 ,0x00000000 ,0x00000000 ,0x00000000 ,0x00000000 ,0x00010101 ,0x01010101 , -0x000f0f01 ,0x0f02010a ,0x00000000 ,0x00010101 , +0x000f0f01 ,0x0f02020a ,0x00000000 ,0x00010101 ,0x00000100 ,0x00000100 ,0x00000000 ,0x00000002 ,0x01010000 ,0x05060302 ,0x06005003 ,0x0a0000c8 , 0x02009c40, 0x0000030c, 0x0036a609, 0x031a0612,
Signature · 1 line
1.7.10
PATCH RESEND 2/4 M28: Scan only first 512 MB of DRAM to avoid memory wraparound
--- include/configs/m28evk.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/configs/m28evk.h +1 -1
@@ -88,7 +88,7 @@*/ #define CONFIG_NR_DRAM_BANKS 1/* 1 bank of DRAM */ #define PHYS_SDRAM_1 0x40000000/* Base address */ -#define PHYS_SDRAM_1_SIZE 0x40000000/* Max 1 GB RAM */ +#define PHYS_SDRAM_1_SIZE 0x20000000/* Max 512 MB RAM */ #define CONFIG_STACKSIZE 0x00010000/* 128 KB stack */ #define CONFIG_SYS_MALLOC_LEN 0x00400000/* 4 MB for malloc */ #define CONFIG_SYS_GBL_DATA_SIZE 128/* Initial data */
Signature · 1 line
1.7.10
PATCH v2 3/4 i.MX28: Add delay after CPU bypass is cleared
In reply to Marek VasutThis solves issues when larger amount of DRAM is used. Behave the same in case of CPU bypass as we do in case of EMI bypass, wait 15 ms. We need to wait until the clock domain stabilizes.
---
V2: Change the description, this issue seemed to have been caused by not
waiting after frobbing with the CPU bypass, it was unrelated to memory, but had a direct impact, causing trouble. This was yet another X-File of the imx-bootlets, sigh.
arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c | 2 ++ 1 file changed, 2 insertions(+)
arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c +2 -0
@@ -149,6 +149,8 @@ void mx28_mem_setup_cpu_and_hbus(void)/* Disable CPU bypass */ writel (CLKCTRL_CLKSEQ_BYPASS_CPU , &clkctrl_regs->hw_clkctrl_clkseq_clr); + +early_delay (15000 ); }void mx28_mem_setup_vdda (void )
Signature · 1 line
1.7.10
PATCH v2 3/4 i.MX28: Add delay after CPU bypass is cleared
Hi Marek,
Quoted 3 lines
This solves issues when larger amount of DRAM is used. Behave the same in case of CPU bypass as we do in case of EMI bypass, wait 15 ms. We need to wait until the clock domain stabilizes.
Sorry to be somewhat persistent here, but can you please include the information what "larger amount of DRAM" is that this delay works for? Also is this guessed, measured or calculated?
The reason why I am so persistent is that this is _available_ information now and it will be very valuable information for the next person reading the code while pondering the question "ok, this worked in the past, but maybe it is a problem on my brand new hardware".
Thanks
Detlev
Signature · 7 lines
Whenever you find yourself on the side of the majority it is
time to pause and reflect.
-- Mark Twain
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.dePATCH v2 3/4 i.MX28: Add delay after CPU bypass is cleared
Dear Detlev Zundel,
Quoted 9 lines
Hi Marek,
Quoted 3 lines
This solves issues when larger amount of DRAM is used. Behave the same in case of CPU bypass as we do in case of EMI bypass, wait 15 ms. We need to wait until the clock domain stabilizes.
Sorry to be somewhat persistent here, but can you please include the information what "larger amount of DRAM" is that this delay works for? Also is this guessed, measured or calculated?
Pure guesswork. I have no scientific background for this.
Quoted 4 lines
The reason why I am so persistent is that this is _available_ information now and it will be very valuable information for the next person reading the code while pondering the question "ok, this worked in the past, but maybe it is a problem on my brand new hardware".
There is zero information available, I'll need to dig deeper ... Fabio, can you comment on this? Is this needed or is it some other problem?
Quoted 2 lines
Thanks
Detlev
Best regards,
Marek Vasut
PATCH 1/1 i.MX28: Add delay after CPU bypass is cleared
In reply to Marek VasutThis solves issues when larger amount of DRAM is used, like 256MB. Behave the same in case of CPU bypass as we do in case of EMI bypass, but wait 15 ms. We need to wait until the clock domain stabilizes.
This issue seemed to have been caused by not waiting after frobbing with the CPU bypass, it was unrelated to memory, but had a direct impact, causing trouble. This was yet another X-File of the imx-bootlets, sigh. The conclusion is, trying a semi-random delay (there is delay after the EMI bypass change), the issue is fixed.
Another possible explanation is that we do not do the "simple memory test" FSL does in their imx-bootlets (1000 R/W cycles to/from piece of the memory, while also outputing something on the serial port). This might have caused the similar delay in the imx-bootlets and therefore they didn't need to add this explicitly.
For now, this seems good fix enough, but to me, whole that memory init code in imx-bootlets is completely flunked and it'd need deeper investigation.
--- arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c | 2 ++ 1 file changed, 2 insertions(+)
V2: Change the description, this issue seemed to have been caused by not
waiting after frobbing with the CPU bypass, it was unrelated to memory, but had a direct impact, causing trouble. This was yet another X-File of the imx-bootlets, sigh.
V3: Add more conspiracy theories into the commit message.
arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c +2 -0
@@ -149,6 +149,8 @@ void mx28_mem_setup_cpu_and_hbus(void)/* Disable CPU bypass */ writel (CLKCTRL_CLKSEQ_BYPASS_CPU , &clkctrl_regs->hw_clkctrl_clkseq_clr); + +early_delay (15000 ); }void mx28_mem_setup_vdda (void )
Signature · 1 line
1.7.10
PATCH 1/1 i.MX28: Add delay after CPU bypass is cleared
Quoted 41 lines · Marek Vasut
This solves issues when larger amount of DRAM is used, like 256MB. Behave the same in case of CPU bypass as we do in case of EMI bypass, but wait 15 ms. We need to wait until the clock domain stabilizes.
This issue seemed to have been caused by not waiting after frobbing with the CPU bypass, it was unrelated to memory, but had a direct impact, causing trouble. This was yet another X-File of the imx-bootlets, sigh. The conclusion is, trying a semi-random delay (there is delay after the EMI bypass change), the issue is fixed.
Another possible explanation is that we do not do the "simple memory test" FSL does in their imx-bootlets (1000 R/W cycles to/from piece of the memory, while also outputing something on the serial port). This might have caused the similar delay in the imx-bootlets and therefore they didn't need to add this explicitly.
For now, this seems good fix enough, but to me, whole that memory init code in imx-bootlets is completely flunked and it'd need deeper investigation.
Signed-off-by Marek Vasut <[email protected]>Cc Wolfgang Denk <[email protected]>Cc Detlev Zundel <[email protected]>Cc Stefano Babic <[email protected]>Cc Fabio Estevam <[email protected]>--- arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c | 2 ++ 1 file changed, 2 insertions(+)V2: Change the description, this issue seemed to have been caused by not
waiting after frobbing with the CPU bypass, it was unrelated to memory, but had a direct impact, causing trouble. This was yet another X-File of the imx-bootlets, sigh.
V3: Add more conspiracy theories into the commit message.arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c +0
-0
arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c void mx28_mem_setup_cpu_and_hbus(void) · line 155
Quoted 7 lines
arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c +2
-0@@ -149,6 +149,8 @@ void mx28_mem_setup_cpu_and_hbus(void)/* Disable CPU bypass */ writel (CLKCTRL_CLKSEQ_BYPASS_CPU , &clkctrl_regs->hw_clkctrl_clkseq_clr); + +early_delay (15000 ); }
It is fine with me
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH 1/1 i.MX28: Add delay after CPU bypass is cleared
Dear Stefano Babic,
Quoted 12 lines · Marek Vasut
Quoted 11 lines
This solves issues when larger amount of DRAM is used, like 256MB. Behave the same in case of CPU bypass as we do in case of EMI bypass, but wait 15 ms. We need to wait until the clock domain stabilizes.
This issue seemed to have been caused by not waiting after frobbing with the CPU bypass, it was unrelated to memory, but had a direct impact, causing trouble. This was yet another X-File of the imx-bootlets, sigh. The conclusion is, trying a semi-random delay (there is delay after the EMI bypass change), the issue is fixed.
Quoted 5 lines
Quoted 5 lines
Another possible explanation is that we do not do the "simple memory test" FSL does in their imx-bootlets (1000 R/W cycles to/from piece of the memory, while also outputing something on the serial port). This might have caused the similar delay in the imx-bootlets and therefore they didn't need to add this explicitly.
Yes Stefano ... I meant this patch ... and the above explanation :-( This is all so messed up :-/
Quoted 38 lines
Quoted 38 lines
For now, this seems good fix enough, but to me, whole that memory init code in imx-bootlets is completely flunked and it'd need deeper investigation.
Signed-off-by Marek Vasut <[email protected]>Cc Wolfgang Denk <[email protected]>Cc Detlev Zundel <[email protected]>Cc Stefano Babic <[email protected]>Cc Fabio Estevam <[email protected]>---
arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c | 2 ++ 1 file changed, 2 insertions(+)V2: Change the description, this issue seemed to have been caused by not
waiting after frobbing with the CPU bypass, it was unrelated to memory, but had a direct impact, causing trouble. This was yet another X-File of the imx-bootlets, sigh.
V3: Add more conspiracy theories into the commit message.
(quoted diff) +0
-0
b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.cindex 0d13537..9fa5d29 100644arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c +2
-0@@ -149,6 +149,8 @@ void mx28_mem_setup_cpu_and_hbus(void)/* Disable CPU bypass */ writel (CLKCTRL_CLKSEQ_BYPASS_CPU , &clkctrl_regs->hw_clkctrl_clkseq_clr); + +early_delay (15000 );
Quoted 8 lines
Quoted 1 line
}
It is fine with me
Acked-by Stefano Babic <[email protected]>Best regards,
Stefano Babic
Best regards,
Marek Vasut
PATCH 1/1 i.MX28: Add delay after CPU bypass is cleared
In reply to Stefano BabicHi Stefano,
Quoted 52 lines · Marek Vasut
Quoted 41 lines
This solves issues when larger amount of DRAM is used, like 256MB. Behave the same in case of CPU bypass as we do in case of EMI bypass, but wait 15 ms. We need to wait until the clock domain stabilizes.
This issue seemed to have been caused by not waiting after frobbing with the CPU bypass, it was unrelated to memory, but had a direct impact, causing trouble. This was yet another X-File of the imx-bootlets, sigh. The conclusion is, trying a semi-random delay (there is delay after the EMI bypass change), the issue is fixed.
Another possible explanation is that we do not do the "simple memory test" FSL does in their imx-bootlets (1000 R/W cycles to/from piece of the memory, while also outputing something on the serial port). This might have caused the similar delay in the imx-bootlets and therefore they didn't need to add this explicitly.
For now, this seems good fix enough, but to me, whole that memory init code in imx-bootlets is completely flunked and it'd need deeper investigation.
Signed-off-by Marek Vasut <[email protected]>Cc Wolfgang Denk <[email protected]>Cc Detlev Zundel <[email protected]>Cc Stefano Babic <[email protected]>Cc Fabio Estevam <[email protected]>--- arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c | 2 ++ 1 file changed, 2 insertions(+)V2: Change the description, this issue seemed to have been caused by not
waiting after frobbing with the CPU bypass, it was unrelated to memory, but had a direct impact, causing trouble. This was yet another X-File of the imx-bootlets, sigh.
V3: Add more conspiracy theories into the commit message.arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c +0
-0arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c void mx28_mem_setup_cpu_and_hbus(void) · line 155
Quoted 7 lines
arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c +2
-0@@ -149,6 +149,8 @@ void mx28_mem_setup_cpu_and_hbus(void)/* Disable CPU bypass */ writel (CLKCTRL_CLKSEQ_BYPASS_CPU , &clkctrl_regs->hw_clkctrl_clkseq_clr); + +early_delay (15000 ); }It is fine with me
Quoted 1 line
Acked-by Stefano Babic <[email protected]>
I'm also content with the commit message now, so I don't want to block this anymore.
Cheers
Detlev
Signature · 6 lines
Sab|bert|jahr - Umgangssprachlich f?r Elternzeit
-- "Wortschatz" v. Sascha Lobo
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.dePATCH v2 3/4 i.MX28: Add delay after CPU bypass is cleared
In reply to Marek VasutQuoted 24 lines · Marek Vasut
This solves issues when larger amount of DRAM is used. Behave the same in case of CPU bypass as we do in case of EMI bypass, wait 15 ms. We need to wait until the clock domain stabilizes.
Signed-off-by Marek Vasut <[email protected]>Cc Wolfgang Denk <[email protected]>Cc Detlev Zundel <[email protected]>Cc Stefano Babic <[email protected]>Cc Fabio Estevam <[email protected]>---
V2: Change the description, this issue seemed to have been caused by not
waiting after frobbing with the CPU bypass, it was unrelated to memory, but had a direct impact, causing trouble. This was yet another X-File of the imx-bootlets, sigh.arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c | 2 ++ 1 file changed, 2 insertions(+)arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c +0
-0
arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c void mx28_mem_setup_cpu_and_hbus(void) · line 153
Quoted 5 lines
arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c +2
-0@@ -149,6 +149,8 @@ void mx28_mem_setup_cpu_and_hbus(void)/* Disable CPU bypass */ writel (CLKCTRL_CLKSEQ_BYPASS_CPU , &clkctrl_regs->hw_clkctrl_clkseq_clr); + +early_delay (15000 );
Is there some influence (I assume that from your commit message) between size of the RAM and amount of time to wait ? Then yes, with boards with even more memory (this patch touches a common MX28 file) this delay is not enough. Should we correlate the delay maybe with PHYS_SDRAM_1_SIZE (maybe early_delay(15000 * (PHYS_SDRAM_1_SIZE / 512MB)) ?
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH v2 3/4 i.MX28: Add delay after CPU bypass is cleared
Dear Stefano Babic,
Quoted 31 lines · Marek Vasut
Quoted 30 lines
This solves issues when larger amount of DRAM is used. Behave the same in case of CPU bypass as we do in case of EMI bypass, wait 15 ms. We need to wait until the clock domain stabilizes.
Signed-off-by Marek Vasut <[email protected]>Cc Wolfgang Denk <[email protected]>Cc Detlev Zundel <[email protected]>Cc Stefano Babic <[email protected]>Cc Fabio Estevam <[email protected]>---
V2: Change the description, this issue seemed to have been caused by not
waiting after frobbing with the CPU bypass, it was unrelated to memory, but had a direct impact, causing trouble. This was yet another X-File of the imx-bootlets, sigh.
arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c | 2 ++ 1 file changed, 2 insertions(+)(quoted diff) +0
-0
b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.cindex 0d13537..a9b1bb6 100644arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c +0
-0@@ -149,6 +149,8 @@ void mx28_mem_setup_cpu_and_hbus(void)/* Disable CPU bypass */ writel(CLKCTRL_CLKSEQ_BYPASS_CPU,
Quoted 7 lines
arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c void mx28_mem_setup_cpu_and_hbus(void) · line 153
Quoted 4 lines
arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c +2
-0&clkctrl_regs->hw_clkctrl_clkseq_clr); + +early_delay (15000 );Is there some influence (I assume that from your commit message) between size of the RAM and amount of time to wait ?
Nope
Quoted 4 lines
Then yes, with boards with
even more memory (this patch touches a common MX28 file) this delay is not enough. Should we correlate the delay maybe withPHYS_SDRAM_1_SIZE(maybeearly_delay(15000 * (PHYS_SDRAM_1_SIZE / 512MB))?
There was a new version of this patch explaining how I got to this delay (or how FSL hid it from me).
Quoted 3 lines
Best regards,
Stefano Babic
Best regards,
Marek Vasut
PATCH 4/4 M28: Enable FDT support
In reply to Marek VasutThis will eventually be needed with Linux 3.5, which will be the point when MXS will be switched to FDT.
--- include/configs/m28evk.h | 2 ++ 1 file changed, 2 insertions(+)
include/configs/m28evk.h +2 -0
@@ -43,6 +43,8 @@#define CONFIG_ARCH_CPU_INIT #define CONFIG_ARCH_MISC_INIT +#define CONFIG_OF_LIBFDT +/* * SPL */
Signature · 1 line
1.7.10
PATCH 4/4 M28: Enable FDT support
Quoted 17 lines · Marek Vasut
This will eventually be needed with Linux 3.5, which will be the point when MXS will be switched to FDT.
Signed-off-by Marek Vasut <[email protected]>Cc Wolfgang Denk <[email protected]>Cc Detlev Zundel <[email protected]>Cc Stefano Babic <[email protected]>Cc Fabio Estevam <[email protected]>--- include/configs/m28evk.h | 2 ++ 1 file changed, 2 insertions(+)include/configs/m28evk.h +0
-0
include/configs/m28evk.h line 46
Quoted 4 lines
include/configs/m28evk.h +1
-0@@ -43,6 +43,8 @@#define CONFIG_ARCH_CPU_INIT #define CONFIG_ARCH_MISC_INIT +#define CONFIG_OF_LIBFDT
This is independent from the series, and can be applied directly.
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH 4/4 M28: Enable FDT support
Dear Stefano Babic,
Quoted 20 lines · Marek Vasut
Quoted 19 lines
This will eventually be needed with Linux 3.5, which will be the point when MXS will be switched to FDT.
Signed-off-by Marek Vasut <[email protected]>Cc Wolfgang Denk <[email protected]>Cc Detlev Zundel <[email protected]>Cc Stefano Babic <[email protected]>Cc Fabio Estevam <[email protected]>---
include/configs/m28evk.h | 2 ++ 1 file changed, 2 insertions(+)include/configs/m28evk.h +0
-0@@ -43,6 +43,8 @@
Quoted 8 lines
include/configs/m28evk.h line 46
Quoted 4 lines
include/configs/m28evk.h +1
-0#define CONFIG_ARCH_CPU_INIT #define CONFIG_ARCH_MISC_INIT +#define CONFIG_OF_LIBFDT This is independent from the series, and can be applied directly.
Applied to u-boot-imx, thanks.
I think the series was cleared either way, wasn't it?
Quoted 3 lines
Best regards,
Stefano Babic
Best regards,
Marek Vasut
PATCH 4/4 M28: Enable FDT support
Quoted 4 lines · Marek Vasut
Dear Stefano Babic,
I think the series was cleared either way, wasn't it?
I am slowly applying all free of comments patches to u-boot-imx, and reviewing what I have not yet done. So this one is completely independent and I could apply without many thoughts ;-)
But I am approaching to the other patches, so do not despair ;-)
Stefano
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH 4/4 M28: Enable FDT support
Dear Stefano Babic,
Quoted 11 lines · Marek Vasut
Quoted 4 lines
Dear Stefano Babic,
I think the series was cleared either way, wasn't it?
I am slowly applying all free of comments patches to u-boot-imx, and reviewing what I have not yet done. So this one is completely independent and I could apply without many thoughts ;-)
But I am approaching to the other patches, so do not despair ;-)
I think I made another series for you that should be clear. This series should be clear after DZU gulps down the previous explanation of crapiness :(
Quoted 2 lines
Stefano
Best regards,
Marek Vasut