On Jul 24, 2009, at 8:46 AM, Wolfgang Denk wrote: > Dear Peter, > > In message <20090723190101.c8f8a832e...@gemini.denx.de> I wrote: >> >> In message <1247269570-11406-1-git-send-email-pty...@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 <pty...@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 <pty...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
