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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot