[U-Boot] [PATCH] 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 --- 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 */ /*
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)
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
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
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.
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
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
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
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
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
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
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
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
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.
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
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
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
participants (7)
-
Ira W. Snyder -
Kim Phillips -
Kumar Gala -
Liu Dave-R63238 -
Peter Tyser -
Scott Wood -
Wolfgang Denk