Shinya Kuribayashi wrote:
> Shinya Kuribayashi wrote:
>>> But simply deleting it is definitely not a good idea, as it would most
>>> probably break existing board support.
>> I still think this removal will not break any existing targets, but yes
>> agreed. I'll try to introduce a #ifdef alternative.
>
> Patch attached. Any comments are still appreciated. Thanks.
>
> ================>
> [MIPS] mips_cache_lock: Introduce CFG_INIT_RAM_LOCK
>
> From: Shinya Kuribayashi <[EMAIL PROTECTED]>
>
> We don't have to lock cache lines for stack use. Meanwhile, once U-Boot
> locks cache, but never gets them unlocked. So the code relies on whatever
> gets loaded after U-Boot to re-initialize the cache and clear the locks.
> For these reasons, I proposed the removal of mips_cache_lock() from the
> global start-up routines.
>
> This patch makes mips_cache_lock() user-selectable so that we don't break
> any existing board support. Let's see how things go for a while.
>
> Signed-off-by: Shinya Kuribayashi <[EMAIL PROTECTED]>
> ---
>
> cpu/mips/cache.S | 2 ++
> cpu/mips/start.S | 2 ++
> include/configs/dbau1x00.h | 1 +
> include/configs/gth2.h | 1 +
> include/configs/incaip.h | 1 +
> include/configs/pb1x00.h | 1 +
> include/configs/purple.h | 2 ++
> include/configs/qemu-mips.h | 1 +
> include/configs/tb0229.h | 1 +
> 9 files changed, 12 insertions(+), 0 deletions(-)
After careful thought, I changed my mind. I'd like to change the default
behavior. The one who makes no regression does none of the work B-)
I hope the patche below is acceptable for the next release.
================>
[MIPS] Request for the 'mips_cache_lock()' removal
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 <[EMAIL PROTECTED]>
---
cpu/mips/cache.S | 2 ++
cpu/mips/start.S | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/cpu/mips/cache.S b/cpu/mips/cache.S
index 443240e..67ee19f 100644
--- a/cpu/mips/cache.S
+++ b/cpu/mips/cache.S
@@ -238,6 +238,7 @@ dcache_disable:
.end dcache_disable
+#ifdef CFG_INIT_RAM_LOCK_MIPS
/*******************************************************************************
*
* mips_cache_lock - lock RAM area pointed to by a0 in cache.
@@ -263,3 +264,4 @@ mips_cache_lock:
j ra
.end mips_cache_lock
+#endif /* CFG_INIT_RAM_LOCK_MIPS */
diff --git a/cpu/mips/start.S b/cpu/mips/start.S
index c92b162..930f9b3 100644
--- a/cpu/mips/start.S
+++ b/cpu/mips/start.S
@@ -267,10 +267,12 @@ reset:
/* Set up temporary stack.
*/
+#ifdef CFG_INIT_RAM_LOCK_MIPS
li a0, CFG_INIT_SP_OFFSET
la t9, mips_cache_lock
jalr t9
nop
+#endif
li t0, CFG_SDRAM_BASE + CFG_INIT_SP_OFFSET
la sp, 0(t0)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
U-Boot-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/u-boot-users
