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