mirror of
https://github.com/brain-hackers/u-boot-brain
synced 2024-07-05 18:56:15 +09:00
e1390801a3
The initial intension of having mips_cache_lock() was to use the cache as memory for temporary stack use so that a C environment can be set up as early as possible. But now mips_cache_lock() follow lowlevel_init(). We've already have the real memory initilaized at this point, therefore we could/should use it. No reason to lock at all. Other problems: Cache locking is not consistent across MIPS implementaions. Some imple- mentations don't support locking at all. The style of locking varies - some support per line locking, others per way, etc. Some parts use bits in status registers instead of cache ops. Current mips_cache_lock() is not necessarily general-purpose. And this is worthy of special mention; once U-Boot/MIPS locks the lines, they are never get unlocked, so the code relies on whatever gets loaded after U-Boot to re-initialize the cache and clear the locks. We're sup- posed to have CFG_INIT_RAM_LOCK and unlock_ram_in_cache() implemented, but leave the situation as it is for a long time. For these reasons, I proposed the removal of mips_cache_lock() from the global start-up code. This patch adds CFG_INIT_RAM_LOCK_MIPS to make existing users aware that *things have changed*. If he wants the same behavior as before, he needs to have CFG_INIT_RAM_LOCK_MIPS in his config file. If we don't have any regression report through several releases, then we'll remove codes entirely. Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp> Acked-by: Andrew Dyer <amdyer@gmail.com> |
||
|---|---|---|
| .. | ||
| asc_serial.c | ||
| asc_serial.h | ||
| au1x00_eth.c | ||
| au1x00_serial.c | ||
| au1x00_usb_ohci.c | ||
| au1x00_usb_ohci.h | ||
| cache.S | ||
| config.mk | ||
| cpu.c | ||
| incaip_clock.c | ||
| incaip_wdt.S | ||
| interrupts.c | ||
| Makefile | ||
| start.S | ||