On Fri, 2009-07-10 at 22:37 +0200, Wolfgang Denk wrote: > Dear Kumar Gala, > > In message <4b5a7126-fcdf-4eb0-9181-fb1be571c...@kernel.crashing.org> you > wrote: > > > > On May 22, 2009, at 10:26 AM, Peter Tyser wrote: > > > > > Previously, it was only unlocked when Linux was executed using the > > > "bootm" command. Unlocking it unconditionally improves U-Boot > > > performance and provides a common cache state when booting OSes. > > > > > > Signed-off-by: Peter Tyser <pty...@xes-inc.com> > > > --- > > > lib_ppc/board.c | 8 +++++--- > > > lib_ppc/bootm.c | 3 ++- > > > 2 files changed, 7 insertions(+), 4 deletions(-) > > > > Wolfgang, do you know any reason we can't do the unlock for ALL ppc's > > in board_init_r()? > > Sorry, I don't remember if there was any speciofic reason, or what > that might have been. Maybe the CHANGELOGs contain some hints?
The only platforms the define unlock_ram_in_cache() are 83xx, 85xx, 86xx, and 74xx_7xx. It looks like the most of them had "issues" in their implementation that could explain why there weren't enabled: 83xx - ade50c7fa1b16ef98be17e9c3ae286aecf4f5605, 6eb2a44e27919fdc601e0c05404b298a7602c0e3 86xx - 392438406041415fe64ab8748ec5ab5ad01d1cf7 74xx - d685b74c64a38849f1a129b3ab846fbf67dd937e 85xx - this one works My best guess was all the non-85xx implementations had bugs or other issues that caused U-Boot to become unstable after unlocking the cache. Perhaps those bugs are fixed now, but I only have 86xx hardware to test on. I've been running a few 86xx boards with the cache unlocked with no noticeable problems. Peter _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
