[U-Boot] [PATCH 1/4 V2] Revert "i.MX28: Enable additional DRAM address bits"

[U-Boot] [PATCH 1/4 V2] Revert "i.MX28: Enable additional DRAM address bits"

[Marek Vasut]

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.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
---
 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!)

diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
index 4f62142..0d13537 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
@@ -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,
-- 
1.7.10

[U-Boot] [PATCH 2/4 RESEND] M28: Scan only first 512 MB of DRAM to avoid memory wraparound

[Marek Vasut]

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
---
 include/configs/m28evk.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h
index 4016570..7e1661e 100644
--- a/include/configs/m28evk.h
+++ b/include/configs/m28evk.h
@@ -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 */
-- 
1.7.10

[U-Boot] [PATCH 3/4 V2] i.MX28: Add delay after CPU bypass is cleared

[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 <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
---

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(+)

diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
index 0d13537..a9b1bb6 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
@@ -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)
-- 
1.7.10

[U-Boot] [PATCH 4/4] M28: Enable FDT support

[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 <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
---
 include/configs/m28evk.h |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h
index 7e1661e..b419516 100644
--- a/include/configs/m28evk.h
+++ b/include/configs/m28evk.h
@@ -43,6 +43,8 @@
 #define	CONFIG_ARCH_CPU_INIT
 #define	CONFIG_ARCH_MISC_INIT
 
+#define CONFIG_OF_LIBFDT
+
 /*
  * SPL
  */
-- 
1.7.10

[U-Boot] [PATCH 3/4 V2] i.MX28: Add delay after CPU bypass is cleared

[Detlev Zundel]

Hi Marek,

> 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

-- 
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.de

[U-Boot] [PATCH 3/4 V2] i.MX28: Add delay after CPU bypass is cleared

[Marek Vasut]

Dear Detlev Zundel,

> Hi Marek,
> 
> > 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.

> 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?

> Thanks
>   Detlev

Best regards,
Marek Vasut

[U-Boot] [PATCH] i.MX28: Add delay after CPU bypass is cleared

[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 <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
---
 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.

diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
index 0d13537..9fa5d29 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
@@ -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)
-- 
1.7.10

[U-Boot] [PATCH 4/4] M28: Enable FDT support

[Stefano Babic]

On 03/05/2012 17:47, Marek Vasut wrote:
> 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 <marex@denx.de>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Detlev Zundel <dzu@denx.de>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> ---
>  include/configs/m28evk.h |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h
> index 7e1661e..b419516 100644
> --- a/include/configs/m28evk.h
> +++ b/include/configs/m28evk.h
> @@ -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

-- 
=====================================================================
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
=====================================================================

[U-Boot] [PATCH 4/4] M28: Enable FDT support

[Marek Vasut]

Dear Stefano Babic,

> On 03/05/2012 17:47, Marek Vasut wrote:
> > 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 <marex@denx.de>
> > Cc: Wolfgang Denk <wd@denx.de>
> > Cc: Detlev Zundel <dzu@denx.de>
> > Cc: Stefano Babic <sbabic@denx.de>
> > Cc: Fabio Estevam <festevam@gmail.com>
> > ---
> > 
> >  include/configs/m28evk.h |    2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h
> > index 7e1661e..b419516 100644
> > --- a/include/configs/m28evk.h
> > +++ b/include/configs/m28evk.h
> > @@ -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.

I think the series was cleared either way, wasn't it?

> 
> Best regards,
> Stefano Babic

Best regards,
Marek Vasut

[U-Boot] [PATCH 4/4] M28: Enable FDT support

[Stefano Babic]

On 06/05/2012 18:12, Marek Vasut wrote:
> 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

-- 
=====================================================================
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
=====================================================================

[U-Boot] [PATCH 3/4 V2] i.MX28: Add delay after CPU bypass is cleared

[Stefano Babic]

On 03/05/2012 17:47, Marek Vasut wrote:
> 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 <marex@denx.de>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Detlev Zundel <dzu@denx.de>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> ---
> 
> 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(+)
> 
> diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
> index 0d13537..a9b1bb6 100644
> --- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
> +++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
> @@ -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

-- 
=====================================================================
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
=====================================================================

[U-Boot] [PATCH 3/4 V2] i.MX28: Add delay after CPU bypass is cleared

[Marek Vasut]

Dear Stefano Babic,

> On 03/05/2012 17:47, Marek Vasut wrote:
> > 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 <marex@denx.de>
> > Cc: Wolfgang Denk <wd@denx.de>
> > Cc: Detlev Zundel <dzu@denx.de>
> > Cc: Stefano Babic <sbabic@denx.de>
> > Cc: Fabio Estevam <festevam@gmail.com>
> > ---
> > 
> > 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(+)
> > 
> > diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
> > b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c index 0d13537..a9b1bb6
> > 100644
> > --- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
> > +++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
> > @@ -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 ?

Nope

> 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)) ?

There was a new version of this patch explaining how I got to this delay (or how 
FSL hid it from me).

> 
> Best regards,
> Stefano Babic

Best regards,
Marek Vasut

[U-Boot] [PATCH] i.MX28: Add delay after CPU bypass is cleared

[Stefano Babic]

On 04/05/2012 13:32, Marek Vasut wrote:
> 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 <marex@denx.de>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Detlev Zundel <dzu@denx.de>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> ---
>  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.
> 
> diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
> index 0d13537..9fa5d29 100644
> --- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
> +++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
> @@ -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

Acked-by: Stefano Babic <sbabic@denx.de>

Best regards,
Stefano Babic

-- 
=====================================================================
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
=====================================================================

[U-Boot] [PATCH] i.MX28: Add delay after CPU bypass is cleared

[Marek Vasut]

Dear Stefano Babic,

> On 04/05/2012 13:32, Marek Vasut wrote:
> > 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.

Yes Stefano ... I meant this patch ... and the above explanation :-( This is all 
so messed up :-/

> > 
> > 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 <marex@denx.de>
> > Cc: Wolfgang Denk <wd@denx.de>
> > Cc: Detlev Zundel <dzu@denx.de>
> > Cc: Stefano Babic <sbabic@denx.de>
> > Cc: Fabio Estevam <festevam@gmail.com>
> > ---
> > 
> >  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.
> > 
> > diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
> > b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c index 0d13537..9fa5d29
> > 100644
> > --- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
> > +++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
> > @@ -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
> 
> Acked-by: Stefano Babic <sbabic@denx.de>
> 
> Best regards,
> Stefano Babic

Best regards,
Marek Vasut

[U-Boot] [PATCH 4/4] M28: Enable FDT support

[Marek Vasut]

Dear Stefano Babic,

> On 06/05/2012 18:12, Marek Vasut wrote:
> > 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 :(

> 
> Stefano

Best regards,
Marek Vasut

[U-Boot] [PATCH] i.MX28: Add delay after CPU bypass is cleared

[Detlev Zundel]

Hi Stefano,

> On 04/05/2012 13:32, Marek Vasut wrote:
>> 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 <marex@denx.de>
>> Cc: Wolfgang Denk <wd@denx.de>
>> Cc: Detlev Zundel <dzu@denx.de>
>> Cc: Stefano Babic <sbabic@denx.de>
>> Cc: Fabio Estevam <festevam@gmail.com>
>> ---
>>  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.
>> 
>> diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
>> index 0d13537..9fa5d29 100644
>> --- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
>> +++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
>> @@ -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
>
> Acked-by: Stefano Babic <sbabic@denx.de>

I'm also content with the commit message now, so I don't want to block
this anymore.

Acked-by: Detlev Zundel <dzu@denx.de>

Cheers
  Detlev

-- 
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.de