[U-Boot] [PATCH] 74xx: use r4 instead of r2 in lock_ram_in_cache and unlock_ram_in_cache

[Kumar Gala]

On Oct 23, 2008, at 9:20 AM, Liu Dave-R63238 wrote:

>> From: Kumar Gala [mailto:galak at kernel.crashing.org]
>> On Oct 23, 2008, at 8:59 AM, Dave Liu wrote:
>>
>>> The patch is following the commit
>>> 392438406041415fe64ab8748ec5ab5ad01d1cf7
>>>
>>> mpc86xx: use r4 instead of r2 in lock_ram_in_cache and
>>> unlock_ram_in_cache
>>>
>>> This is needed in unlock_ram_in_cache() because it is
>> called from C
>>> and
>>> will corrupt the small data area anchor that is kept in R2.
>>>
>>> lock_ram_in_cache() is modified similarly as good coding
>> practice, but
>>> is not called from C.
>>>
>>> Signed-off-by: Nick Spence <nick.spence at freescale.com>
>>>
>>> also, the r2 is used as global data pointer.
>>>
>>> Signed-off-by: Dave Liu <daveliu at freescale.com>
>>> ---
>>> cpu/74xx_7xx/start.S |    8 ++++----
>>> 1 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/cpu/74xx_7xx/start.S b/cpu/74xx_7xx/start.S
>>> index 07bbe01..b5484e3 100644
>>> --- a/cpu/74xx_7xx/start.S
>>> +++ b/cpu/74xx_7xx/start.S
>>> @@ -857,9 +857,9 @@ lock_ram_in_cache:
>>> 	 */
>>> 	lis	r3, (CONFIG_SYS_INIT_RAM_ADDR & ~31)@h
>>> 	ori	r3, r3, (CONFIG_SYS_INIT_RAM_ADDR & ~31)@l
>>> -	li	r2, ((CONFIG_SYS_INIT_RAM_END & ~31) + \
>>> +	li	r4, ((CONFIG_SYS_INIT_RAM_END & ~31) + \
>>> 		     (CONFIG_SYS_INIT_RAM_ADDR & 31) + 31) / 32
>>> -	mtctr	r2
>>> +	mtctr	r4
>>> 1:
>>> 	dcbz	r0, r3
>>> 	addi	r3, r3, 32
>>> @@ -878,9 +878,9 @@ unlock_ram_in_cache:
>>> 	/* invalidate the INIT_RAM section */
>>> 	lis	r3, (CONFIG_SYS_INIT_RAM_ADDR & ~31)@h
>>> 	ori	r3, r3, (CONFIG_SYS_INIT_RAM_ADDR & ~31)@l
>>> -	li	r2, ((CONFIG_SYS_INIT_RAM_END & ~31) + \
>>> +	li	r4, ((CONFIG_SYS_INIT_RAM_END & ~31) + \
>>> 		     (CONFIG_SYS_INIT_RAM_ADDR & 31) + 31) / 32
>>> -	mtctr	r2
>>> +	mtctr	r4
>>> 1:	icbi	r0, r3
>>> 	addi	r3, r3, 32
>>> 	bdnz	1b
>>
>> Can we change the 31 to CONFIG_SYS_CACHELINE_SIZE-1
>>
>> It doesn't matter much for 7xx/74xx/e600 as the cache line size has
>> always been 32-bytes, but good to make the code a bit more readable
>
> Patch welcomed!

I'm willing to deal with it that way.

Ack on this patch.

- k