[U-Boot] [PATCH] ppc: Unlock cache-as-ram in a consistent manner

[U-Boot] [PATCH] ppc: Unlock cache-as-ram in a consistent manner

[Peter Tyser]

Previously, non-e500 architectures only unlocked their data cache which
was used as early RAM when booting to Linux using the "bootm" command.
This change causes all PPC boards with CONFIG_SYS_INIT_RAM_LOCK defined
to unlock their data cache during U-Boot's initialization.  This
improves U-Boot performance and provides a common cache state when
booting to different OSes.

Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
---
I've tested this on 86xx boards, it'd be great if someone could test on
83xx and 74xx/7xx.  85xx boards should not be affected by this change.

This change assumes http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/63423
has already been applied, or the lib/ppc patches in the diffs below can
be changed to lib_ppc.

Peter

 lib/ppc/board.c |    6 +++---
 lib/ppc/bootm.c |    9 ---------
 2 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/lib/ppc/board.c b/lib/ppc/board.c
index 155171d..1495b3f 100644
--- a/lib/ppc/board.c
+++ b/lib/ppc/board.c
@@ -68,7 +68,7 @@
 #if defined(CONFIG_LOGBUFFER)
 #include <logbuff.h>
 #endif
-#if defined(CONFIG_SYS_INIT_RAM_LOCK) && defined(CONFIG_E500)
+#if defined(CONFIG_SYS_INIT_RAM_LOCK)
 #include <asm/cache.h>
 #endif
 #ifdef CONFIG_PS2KBD
@@ -754,8 +754,8 @@ void board_init_r (gd_t *id, ulong dest_addr)
 	icache_enable ();	/* it's time to enable the instruction cache */
 #endif
 
-#if defined(CONFIG_SYS_INIT_RAM_LOCK) && defined(CONFIG_E500)
-	unlock_ram_in_cache();	/* it's time to unlock D-cache in e500 */
+#if defined(CONFIG_SYS_INIT_RAM_LOCK)
+	unlock_ram_in_cache();	/* it's time to unlock D-cache */
 #endif
 
 #if defined(CONFIG_BAB7xx) || defined(CONFIG_CPC45)
diff --git a/lib/ppc/bootm.c b/lib/ppc/bootm.c
index 0d702bf..e7d2c98 100644
--- a/lib/ppc/bootm.c
+++ b/lib/ppc/bootm.c
@@ -38,11 +38,6 @@
 #include <fdt.h>
 #include <libfdt.h>
 #include <fdt_support.h>
-
-#endif
-
-#ifdef CONFIG_SYS_INIT_RAM_LOCK
-#include <asm/cache.h>
 #endif
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -71,10 +66,6 @@ static void boot_jump_linux(bootm_headers_t *images)
 
 	show_boot_progress (15);
 
-#if defined(CONFIG_SYS_INIT_RAM_LOCK) && !defined(CONFIG_E500)
-	unlock_ram_in_cache();
-#endif
-
 #if defined(CONFIG_OF_LIBFDT)
 	if (of_flat_tree) {	/* device tree; boot new style */
 		/*
-- 
1.6.2.1

[U-Boot] [PATCH] ppc: Unlock cache-as-ram in a consistent manner

[Liu Dave-R63238]

> Previously, non-e500 architectures only unlocked their data 
> cache which
> was used as early RAM when booting to Linux using the "bootm" command.
> This change causes all PPC boards with 
> CONFIG_SYS_INIT_RAM_LOCK defined
> to unlock their data cache during U-Boot's initialization.  This
> improves U-Boot performance and provides a common cache state when
> booting to different OSes.
> 
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> ---
> I've tested this on 86xx boards, it'd be great if someone 
> could test on
> 83xx and 74xx/7xx.  85xx boards should not be affected by this change.
> 
> This change assumes 
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/63423
> has already been applied, or the lib/ppc patches in the diffs 
> below can
> be changed to lib_ppc.

I'm afraid some 83xx boards will not work after the patch is applied.
It is some was assuming the data cache locked. (that is cache-inhibited)

[U-Boot] [PATCH] ppc: Unlock cache-as-ram in a consistent manner

[Peter Tyser]

On Sat, 2009-07-11 at 07:52 +0800, Liu Dave-R63238 wrote:
> > Previously, non-e500 architectures only unlocked their data 
> > cache which
> > was used as early RAM when booting to Linux using the "bootm" command.
> > This change causes all PPC boards with 
> > CONFIG_SYS_INIT_RAM_LOCK defined
> > to unlock their data cache during U-Boot's initialization.  This
> > improves U-Boot performance and provides a common cache state when
> > booting to different OSes.
> > 
> > Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> > ---
> > I've tested this on 86xx boards, it'd be great if someone 
> > could test on
> > 83xx and 74xx/7xx.  85xx boards should not be affected by this change.
> > 
> > This change assumes 
> > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/63423
> > has already been applied, or the lib/ppc patches in the diffs 
> > below can
> > be changed to lib_ppc.
> 
> I'm afraid some 83xx boards will not work after the patch is applied.
> It is some was assuming the data cache locked. (that is cache-inhibited)

Do those boards have CONFIG_SYS_INIT_RAM_LOCK defined?  I'm not familiar
with the 83xx arch, but would a board that required the data cache to be
disabled be considered broken?  ie shouldn't its MMU be setup up
correctly so that the cache could be enabled?

In any case, if this patch breaks the 83xx or 74xx/7xx architectures, I
hope the "86xx: Unlock l1 cache unconditionally" still makes it in.

Best,
Peter

[U-Boot] [PATCH] ppc: Unlock cache-as-ram in a consistent manner

[Wolfgang Denk]

Dear "Liu Dave-R63238",

In message <D7CCA83BB0796C49BC0BB53B6AB120895152B9@zch01exm21.fsl.freescale.net> you wrote:
> > Previously, non-e500 architectures only unlocked their data 
> > cache which
> > was used as early RAM when booting to Linux using the "bootm" command.
> > This change causes all PPC boards with 
> > CONFIG_SYS_INIT_RAM_LOCK defined
> > to unlock their data cache during U-Boot's initialization.  This
> > improves U-Boot performance and provides a common cache state when
> > booting to different OSes.
> > 
> > Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> > ---
> > I've tested this on 86xx boards, it'd be great if someone 
> > could test on
> > 83xx and 74xx/7xx.  85xx boards should not be affected by this change.
> > 
> > This change assumes 
> > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/63423
> > has already been applied, or the lib/ppc patches in the diffs 
> > below can
> > be changed to lib_ppc.
> 
> I'm afraid some 83xx boards will not work after the patch is applied.
> It is some was assuming the data cache locked. (that is cache-inhibited)

Are you just concerned, or did you actually test the patch, with
negative results?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Perfection is reached, not when there is no longer anything  to  add,
but when there is no longer anything to take away.
                                           - Antoine de Saint-Exupery

[U-Boot] [PATCH] ppc: Unlock cache-as-ram in a consistent manner

[Liu Dave-R63238]

> > > I've tested this on 86xx boards, it'd be great if someone 
> > > could test on
> > > 83xx and 74xx/7xx.  85xx boards should not be affected by 
> this change.
> > > 
> > > This change assumes 
> > > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/63423
> > > has already been applied, or the lib/ppc patches in the diffs 
> > > below can
> > > be changed to lib_ppc.
> > 
> > I'm afraid some 83xx boards will not work after the patch 
> is applied.
> > It is some was assuming the data cache locked. (that is 
> cache-inhibited)
> 
> Are you just concerned, or did you actually test the patch, with
> negative results?

I'm just concerned. I didn't test the patch.

[U-Boot] [PATCH] ppc: Unlock cache-as-ram in a consistent manner

[Kumar Gala]

On Jul 20, 2009, at 6:44 PM, Liu Dave-R63238 wrote:

>>>> I've tested this on 86xx boards, it'd be great if someone
>>>> could test on
>>>> 83xx and 74xx/7xx.  85xx boards should not be affected by
>> this change.
>>>>
>>>> This change assumes
>>>> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/63423
>>>> has already been applied, or the lib/ppc patches in the diffs
>>>> below can
>>>> be changed to lib_ppc.
>>>
>>> I'm afraid some 83xx boards will not work after the patch
>> is applied.
>>> It is some was assuming the data cache locked. (that is
>> cache-inhibited)
>>
>> Are you just concerned, or did you actually test the patch, with
>> negative results?
>
> I'm just concerned. I didn't test the patch.

I still don't understand the concern.  I think we should go ahead with  
this patch and if it really shows an issue we can revert it.  However,  
I'm really dont know under what situation that a board has defined  
CONFIG_SYS_INIT_RAM_LOCK that unlock_ram_in_cache() once we are  
running in RAM should be an issue.

- k

[U-Boot] [PATCH] ppc: Unlock cache-as-ram in a consistent manner

[Wolfgang Denk]

Dear Peter Tyser,

In message <1247269570-11406-1-git-send-email-ptyser@xes-inc.com> you wrote:
> Previously, non-e500 architectures only unlocked their data cache which
> was used as early RAM when booting to Linux using the "bootm" command.
> This change causes all PPC boards with CONFIG_SYS_INIT_RAM_LOCK defined
> to unlock their data cache during U-Boot's initialization.  This
> improves U-Boot performance and provides a common cache state when
> booting to different OSes.
> 
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> ---
> I've tested this on 86xx boards, it'd be great if someone could test on
> 83xx and 74xx/7xx.  85xx boards should not be affected by this change.
> 
> This change assumes http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/63423
> has already been applied, or the lib/ppc patches in the diffs below can
> be changed to lib_ppc.
> 
> Peter
> 
>  lib/ppc/board.c |    6 +++---
>  lib/ppc/bootm.c |    9 ---------
>  2 files changed, 3 insertions(+), 12 deletions(-)

Applied.

Hm... tested on TQM834x - it's still booting, but flash recognition
stopped working:


OLD:

	U-Boot 2008.10-00085-g13f9496-dirty (Oct 22 2008 - 00:28:08) MPC83XX

	Reset Status:

	CPU:   e300c1, MPC8349E, Rev: 1.1 at 533.328 MHz, CSB: 266.664 MHz
	Board: TQM834x
	PCI1:  32 bit, 33 MHz
	I2C:   ready
	DTT:   1 is 32 C
	DRAM:  256 MB
	FLASH: 32 MB
	PCI:   Bus Dev VenId DevId Class Int
		00  0b  104c  ac55  0607  ff
		00  0b  104c  ac55  0607  ff
	...


NEW:

	U-Boot 2009.06-00513-g982adfc (Jul 23 2009 - 20:46:38) MPC83XX

	Reset Status: Software Hard, External/Internal Soft, External/Internal Hard

	CPU:   e300c1, MPC8349E, Rev: 1.1 at 533.328 MHz, CSB: 266.664 MHz
	Board: TQM834x
	PCI1:  32 bit, 33 MHz
	I2C:   ready
	DRAM:  256 MB
	FLASH: ## Unknown FLASH on Bank 1 - Size = 0x02000000 = 0 MB
	32 MB
	PCI:   Bus Dev VenId DevId Class Int
		00  0b  104c  ac55  0607  ff
		00  0b  104c  ac55  0607  ff
	=> fli

	Bank # 1: missing or unknown FLASH type

Probably because of caching?

I can't do anything right now as I cannot reprogram the flash any
more. Need to attach a BDI when I'm bck in the office tomorrow
morning.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The one charm of marriage is that it makes a  life  of  deception  a
neccessity."                                            - Oscar Wilde

[U-Boot] [PATCH] ppc: Unlock cache-as-ram in a consistent manner

[Kim Phillips]

On Thu, 23 Jul 2009 21:01:01 +0200
Wolfgang Denk <wd@denx.de> wrote:

> 	FLASH: ## Unknown FLASH on Bank 1 - Size = 0x02000000 = 0 MB
> 	32 MB
> 	PCI:   Bus Dev VenId DevId Class Int
> 		00  0b  104c  ac55  0607  ff
> 		00  0b  104c  ac55  0607  ff
> 	=> fli
> 
> 	Bank # 1: missing or unknown FLASH type
> 
> Probably because of caching?

ahem, I just noticed I accidentally broke the TQM8349 with commit
9993e19 (but pci still works?) - anyway, can you tell me if this fixes
it?:

diff --git a/include/configs/TQM834x.h b/include/configs/TQM834x.h
index 492bdcc..da08b7c 100644
--- a/include/configs/TQM834x.h
+++ b/include/configs/TQM834x.h
@@ -250,7 +250,7 @@ extern int tqm834x_num_flash_banks;
 #define CONFIG_PCI_SCAN_SHOW            /* show pci devices on startup */
 
 /* PCI1 host bridge */
-#define CONFIG_SYS_PCI1_MEM_BASE       0x80000000
+#define CONFIG_SYS_PCI1_MEM_BASE       0x90000000
 #define CONFIG_SYS_PCI1_MEM_PHYS       CONFIG_SYS_PCI1_MEM_BASE
 #define CONFIG_SYS_PCI1_MEM_SIZE       0x10000000      /* 256M */
 #define CONFIG_SYS_PCI1_MMIO_BASE      (CONFIG_SYS_PCI1_MEM_BASE + CONFIG_SYS_PCI1_MEM_SIZE)

Thanks,

Kim

[U-Boot] [PATCH] ppc: Unlock cache-as-ram in a consistent manner

[Wolfgang Denk]

Dear Peter,

In message <20090723190101.C8F8A832E416@gemini.denx.de> I wrote:
>
> In message <1247269570-11406-1-git-send-email-ptyser@xes-inc.com> you wrote:
> > Previously, non-e500 architectures only unlocked their data cache which
> > was used as early RAM when booting to Linux using the "bootm" command.
> > This change causes all PPC boards with CONFIG_SYS_INIT_RAM_LOCK defined
> > to unlock their data cache during U-Boot's initialization.  This
> > improves U-Boot performance and provides a common cache state when
> > booting to different OSes.
...
> Hm... tested on TQM834x - it's still booting, but flash recognition
> stopped working:

I git-bisected the problem on TQM834x:

982adfc610669482a32127282fe489857a92cfe3 is first bad commit
commit 982adfc610669482a32127282fe489857a92cfe3
Author: Peter Tyser <ptyser@xes-inc.com>
Date:   Fri Jul 10 18:46:10 2009 -0500

    ppc: Unlock cache-as-ram in a consistent manner
    
    Previously, non-e500 architectures only unlocked their data cache which
    was used as early RAM when booting to Linux using the "bootm" command.
    This change causes all PPC boards with CONFIG_SYS_INIT_RAM_LOCK defined
    to unlock their data cache during U-Boot's initialization.  This
    improves U-Boot performance and provides a common cache state when
    booting to different OSes.
    
    Signed-off-by: Peter Tyser <ptyser@xes-inc.com>

:040000 040000 bf1093b8403580234125df8e97d948c318e8965f 5dce3a5e28ea46706aba44ec62e88584883d0cc4 M   lib_ppc


Please suggest how to continue. Shall I revert this commit?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If something is different, it's either better or worse,  and  usually
both.                                                    - Larry Wall

[U-Boot] [PATCH] ppc: Unlock cache-as-ram in a consistent manner

[Peter Tyser]

On Fri, 2009-07-24 at 15:46 +0200, Wolfgang Denk wrote:
> Dear Peter,
> 
> In message <20090723190101.C8F8A832E416@gemini.denx.de> I wrote:
> >
> > In message <1247269570-11406-1-git-send-email-ptyser@xes-inc.com> you wrote:
> > > Previously, non-e500 architectures only unlocked their data cache which
> > > was used as early RAM when booting to Linux using the "bootm" command.
> > > This change causes all PPC boards with CONFIG_SYS_INIT_RAM_LOCK defined
> > > to unlock their data cache during U-Boot's initialization.  This
> > > improves U-Boot performance and provides a common cache state when
> > > booting to different OSes.
> ...
> > Hm... tested on TQM834x - it's still booting, but flash recognition
> > stopped working:
> 
> I git-bisected the problem on TQM834x:
> 
> 982adfc610669482a32127282fe489857a92cfe3 is first bad commit
> commit 982adfc610669482a32127282fe489857a92cfe3
> Author: Peter Tyser <ptyser@xes-inc.com>
> Date:   Fri Jul 10 18:46:10 2009 -0500
> 
>     ppc: Unlock cache-as-ram in a consistent manner
>     
>     Previously, non-e500 architectures only unlocked their data cache which
>     was used as early RAM when booting to Linux using the "bootm" command.
>     This change causes all PPC boards with CONFIG_SYS_INIT_RAM_LOCK defined
>     to unlock their data cache during U-Boot's initialization.  This
>     improves U-Boot performance and provides a common cache state when
>     booting to different OSes.
>     
>     Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> 
> :040000 040000 bf1093b8403580234125df8e97d948c318e8965f 5dce3a5e28ea46706aba44ec62e88584883d0cc4 M   lib_ppc
> 
> 
> Please suggest how to continue. Shall I revert this commit?

Did you try making the change Kim suggested?  Or backing out
9993e196da707a0a1cd4584f1fcef12382c1c144 completely as a test?

Does anyone else have an 83xx board they'd be willing to try booting
with the current top of HEAD?

Best,
Peter

[U-Boot] [PATCH] ppc: Unlock cache-as-ram in a consistent manner

[Kim Phillips]

On Fri, 24 Jul 2009 15:46:16 +0200
Wolfgang Denk <wd@denx.de> wrote:

> Dear Peter,
> 
> In message <20090723190101.C8F8A832E416@gemini.denx.de> I wrote:
> >
> > In message <1247269570-11406-1-git-send-email-ptyser@xes-inc.com> you wrote:
> > > Previously, non-e500 architectures only unlocked their data cache which
> > > was used as early RAM when booting to Linux using the "bootm" command.
> > > This change causes all PPC boards with CONFIG_SYS_INIT_RAM_LOCK defined
> > > to unlock their data cache during U-Boot's initialization.  This
> > > improves U-Boot performance and provides a common cache state when
> > > booting to different OSes.
> ...
> > Hm... tested on TQM834x - it's still booting, but flash recognition
> > stopped working:
> 
> I git-bisected the problem on TQM834x:
> 
> 982adfc610669482a32127282fe489857a92cfe3 is first bad commit
> commit 982adfc610669482a32127282fe489857a92cfe3
> Author: Peter Tyser <ptyser@xes-inc.com>
> Date:   Fri Jul 10 18:46:10 2009 -0500
> 
>     ppc: Unlock cache-as-ram in a consistent manner
>     
>     Previously, non-e500 architectures only unlocked their data cache which
>     was used as early RAM when booting to Linux using the "bootm" command.
>     This change causes all PPC boards with CONFIG_SYS_INIT_RAM_LOCK defined
>     to unlock their data cache during U-Boot's initialization.  This
>     improves U-Boot performance and provides a common cache state when
>     booting to different OSes.
>     
>     Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> 
> :040000 040000 bf1093b8403580234125df8e97d948c318e8965f 5dce3a5e28ea46706aba44ec62e88584883d0cc4 M   lib_ppc
> 
> 
> Please suggest how to continue. Shall I revert this commit?

with this patch, this mpc8313 board does this:

U-Boot 2009.06-00524-g28958b8 (Jul 23 2009 - 18:33:11) MPC83XX

Reset Status:

CPU:   e300c3, MPC8313E, Rev: 1.0 at 333.333 MHz, CSB: 166.667 MHz
Board: Freescale MPC8313ERDB
I2C:   ready
DRAM:  128 MB
FLASH: ## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB
*** failed ***
### ERROR ### Please RESET the board ###

and when reverted, it boots normally, so the board wants to agree that
this patch is reverted.

Kim

[U-Boot] [PATCH] ppc: Unlock cache-as-ram in a consistent manner

[Ira W. Snyder]

On Fri, Jul 24, 2009 at 09:41:21AM -0500, Peter Tyser wrote:
> On Fri, 2009-07-24 at 15:46 +0200, Wolfgang Denk wrote:
> > Dear Peter,
> > 
> > In message <20090723190101.C8F8A832E416@gemini.denx.de> I wrote:
> > >
> > > In message <1247269570-11406-1-git-send-email-ptyser@xes-inc.com> you wrote:
> > > > Previously, non-e500 architectures only unlocked their data cache which
> > > > was used as early RAM when booting to Linux using the "bootm" command.
> > > > This change causes all PPC boards with CONFIG_SYS_INIT_RAM_LOCK defined
> > > > to unlock their data cache during U-Boot's initialization.  This
> > > > improves U-Boot performance and provides a common cache state when
> > > > booting to different OSes.
> > ...
> > > Hm... tested on TQM834x - it's still booting, but flash recognition
> > > stopped working:
> > 
> > I git-bisected the problem on TQM834x:
> > 
> > 982adfc610669482a32127282fe489857a92cfe3 is first bad commit
> > commit 982adfc610669482a32127282fe489857a92cfe3
> > Author: Peter Tyser <ptyser@xes-inc.com>
> > Date:   Fri Jul 10 18:46:10 2009 -0500
> > 
> >     ppc: Unlock cache-as-ram in a consistent manner
> >     
> >     Previously, non-e500 architectures only unlocked their data cache which
> >     was used as early RAM when booting to Linux using the "bootm" command.
> >     This change causes all PPC boards with CONFIG_SYS_INIT_RAM_LOCK defined
> >     to unlock their data cache during U-Boot's initialization.  This
> >     improves U-Boot performance and provides a common cache state when
> >     booting to different OSes.
> >     
> >     Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> > 
> > :040000 040000 bf1093b8403580234125df8e97d948c318e8965f 5dce3a5e28ea46706aba44ec62e88584883d0cc4 M   lib_ppc
> > 
> > 
> > Please suggest how to continue. Shall I revert this commit?
> 
> Did you try making the change Kim suggested?  Or backing out
> 9993e196da707a0a1cd4584f1fcef12382c1c144 completely as a test?
> 
> Does anyone else have an 83xx board they'd be willing to try booting
> with the current top of HEAD?
> 

Sure. MPC8349EMDS eval board here. It fails to boot, giving the
following output.

U-Boot 2009.06-00525-gf33b325 (Jul 24 2009 - 09:34:25) MPC83XX

Reset Status: Software Hard, External/Internal Soft, External/Internal Hard

CPU:   e300c1, MPC8349EA, Rev: 3.0 at 528 MHz, CSB: 264 MHz
Board: Freescale MPC8349EMDS
I2C:   ready
SPI:   ready
DRAM:  256 MB (DDR1, 64-bit, ECC off, 264 MHz)
FLASH: ## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB
*** failed ***
### ERROR ### Please RESET the board ###


Thanks,
Ira

[U-Boot] [PATCH] ppc: Unlock cache-as-ram in a consistent manner

[Kumar Gala]

On Jul 24, 2009, at 8:46 AM, Wolfgang Denk wrote:

> Dear Peter,
>
> In message <20090723190101.C8F8A832E416@gemini.denx.de> I wrote:
>>
>> In message <1247269570-11406-1-git-send-email-ptyser@xes-inc.com>  
>> you wrote:
>>> Previously, non-e500 architectures only unlocked their data cache  
>>> which
>>> was used as early RAM when booting to Linux using the "bootm"  
>>> command.
>>> This change causes all PPC boards with CONFIG_SYS_INIT_RAM_LOCK  
>>> defined
>>> to unlock their data cache during U-Boot's initialization.  This
>>> improves U-Boot performance and provides a common cache state when
>>> booting to different OSes.
> ...
>> Hm... tested on TQM834x - it's still booting, but flash recognition
>> stopped working:
>
> I git-bisected the problem on TQM834x:
>
> 982adfc610669482a32127282fe489857a92cfe3 is first bad commit
> commit 982adfc610669482a32127282fe489857a92cfe3
> Author: Peter Tyser <ptyser@xes-inc.com>
> Date:   Fri Jul 10 18:46:10 2009 -0500
>
>    ppc: Unlock cache-as-ram in a consistent manner
>
>    Previously, non-e500 architectures only unlocked their data cache  
> which
>    was used as early RAM when booting to Linux using the "bootm"  
> command.
>    This change causes all PPC boards with CONFIG_SYS_INIT_RAM_LOCK  
> defined
>    to unlock their data cache during U-Boot's initialization.  This
>    improves U-Boot performance and provides a common cache state when
>    booting to different OSes.
>
>    Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
>
> :040000 040000 bf1093b8403580234125df8e97d948c318e8965f  
> 5dce3a5e28ea46706aba44ec62e88584883d0cc4 M   lib_ppc
>
>
> Please suggest how to continue. Shall I revert this commit?

Revert it for now.  I think the problem is that the  
unlock_ram_in_cache is technically buggy on 83xx/74xx_7xx/86xx  
platforms.  We end up flash invalidating the d-cache I think we lose  
data by doing that.  This just happens to work when we call it via  
bootm.

- k

[U-Boot] [PATCH] ppc: Unlock cache-as-ram in a consistent manner

[Scott Wood]

On Fri, Jul 24, 2009 at 11:40:09AM -0500, Kim Phillips wrote:
> with this patch, this mpc8313 board does this:
> 
> U-Boot 2009.06-00524-g28958b8 (Jul 23 2009 - 18:33:11) MPC83XX
> 
> Reset Status:
> 
> CPU:   e300c3, MPC8313E, Rev: 1.0 at 333.333 MHz, CSB: 166.667 MHz
> Board: Freescale MPC8313ERDB
> I2C:   ready
> DRAM:  128 MB
> FLASH: ## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB
> *** failed ***
> ### ERROR ### Please RESET the board ###
> 
> and when reverted, it boots normally, so the board wants to agree that
> this patch is reverted.

Flash is mapped cacheable on 8313erdb (and some other 83xx boards) -- it
shares a BAT with the locked cache area.

-Scott

[U-Boot] [PATCH] ppc: Unlock cache-as-ram in a consistent manner

[Liu Dave-R63238]

> > with this patch, this mpc8313 board does this:
> > 
> > U-Boot 2009.06-00524-g28958b8 (Jul 23 2009 - 18:33:11) MPC83XX
> > 
> > Reset Status:
> > 
> > CPU:   e300c3, MPC8313E, Rev: 1.0 at 333.333 MHz, CSB: 166.667 MHz
> > Board: Freescale MPC8313ERDB
> > I2C:   ready
> > DRAM:  128 MB
> > FLASH: ## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB
> > *** failed ***
> > ### ERROR ### Please RESET the board ###
> > 
> > and when reverted, it boots normally, so the board wants to 
> agree that
> > this patch is reverted.
> 
> Flash is mapped cacheable on 8313erdb (and some other 83xx 
> boards) -- it
> shares a BAT with the locked cache area.

Yes. Scott is right.
The rootcause is the classic PPC has not enough BAT.

[U-Boot] [PATCH] ppc: Unlock cache-as-ram in a consistent manner

[Scott Wood]

Liu Dave-R63238 wrote:
>>> with this patch, this mpc8313 board does this:
>>>
>>> U-Boot 2009.06-00524-g28958b8 (Jul 23 2009 - 18:33:11) MPC83XX
>>>
>>> Reset Status:
>>>
>>> CPU:   e300c3, MPC8313E, Rev: 1.0 at 333.333 MHz, CSB: 166.667 MHz
>>> Board: Freescale MPC8313ERDB
>>> I2C:   ready
>>> DRAM:  128 MB
>>> FLASH: ## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB
>>> *** failed ***
>>> ### ERROR ### Please RESET the board ###
>>>
>>> and when reverted, it boots normally, so the board wants to 
>> agree that
>>> this patch is reverted.
>> Flash is mapped cacheable on 8313erdb (and some other 83xx 
>> boards) -- it
>> shares a BAT with the locked cache area.
> 
> Yes. Scott is right.
> The rootcause is the classic PPC has not enough BAT.

8313erdb has an unused BAT7 (not counting the ones that would normally 
be used for PCI2), and there are other 83xx boards that look like they 
get it right.

-Scott

[U-Boot] [PATCH] ppc: Unlock cache-as-ram in a consistent manner

[Liu Dave-R63238]

> >>> with this patch, this mpc8313 board does this:
> >>>
> >>> U-Boot 2009.06-00524-g28958b8 (Jul 23 2009 - 18:33:11) MPC83XX
> >>>
> >>> Reset Status:
> >>>
> >>> CPU:   e300c3, MPC8313E, Rev: 1.0 at 333.333 MHz, CSB: 166.667 MHz
> >>> Board: Freescale MPC8313ERDB
> >>> I2C:   ready
> >>> DRAM:  128 MB
> >>> FLASH: ## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB
> >>> *** failed ***
> >>> ### ERROR ### Please RESET the board ###
> >>>
> >>> and when reverted, it boots normally, so the board wants to 
> >> agree that
> >>> this patch is reverted.
> >> Flash is mapped cacheable on 8313erdb (and some other 83xx 
> >> boards) -- it
> >> shares a BAT with the locked cache area.
> > 
> > Yes. Scott is right.
> > The rootcause is the classic PPC has not enough BAT.
> 
> 8313erdb has an unused BAT7 (not counting the ones that would 
> normally 
> be used for PCI2), and there are other 83xx boards that look 
> like they get it right.

I believe the 8313erdb is ported from 8349emds.
The 8349emds, itx has same problem as 8313erdb.

We disable the MMU when we use the PCI express in current code.
I remember we had to diable the MMU due to no enough BAT to
cover PCI and PCI express and so on.

Thanks, Dave