[U-Boot] powerpc: why call unlock_ram_in_cache() only for e500 cores and linux?

[Peter Tyser]

For the powerpc architecture there are 2 locations that I see caches
being unlocked for those boards which lock a cache for use as early
memory:

- lib_ppc/board.c, line 757 in board_init_r() 
#if defined(CONFIG_SYS_INIT_RAM_LOCK) && defined(CONFIG_E500)
	unlock_ram_in_cache();	/* it's time to unlock D-cache in e500 */
#endif


- lib_ppc/bootm.c, line 74 in boot_jump_linux()
#if defined(CONFIG_SYS_INIT_RAM_LOCK) && !defined(CONFIG_E500)
unlock_ram_in_cache();
#endif


I had a few questions about this and was hoping someone had some
insight:

1. Why is the cache only unlocked for e500 cores in board.c?
It seems like the cache should be unlocked for all processor types in
board.c.  I was under the impression any data which was initially
stored/referenced in the "cache as RAM" early in the boot process was
not needed after relocating to SDRAM.  I've tried unlocking an mpc8640's
cache in board.c and the board appears to function normally to
(somewhat) support this.

2. Why is the cache only unlocked when booting Linux for non-e500
processors?
Shouldn't the cache be unlocked before booting all OSes?  For example,
from what I can tell, the reference VxWorks BSP for the mpc8641 expects
the caches to be unlocked/enabled when booting and has "issues" when
booting with the L1 cache locked.


It seems like unlocking the cache for all CPUs in lib_ppc/board.c would
provide a slight performance boost as well as a bit of consistency,
while I'm not aware of any downsides.  Based on the git changelogs, it
looks like the 86xx and 83xx architectures used to have some bugs
related to unlock_ram_in_cache()
(d685b74c64a38849f1a129b3ab846fbf67dd937e "use r4 instead of r2 in
lock_ram_in_cache and unlock_ram_in_cache").  Perhaps these bugs were
the reason that caches were only unlocked for e500 cores?

Thanks for any insight,
Peter