diff mbox series

mpc83xx: Fix dcache setup in lock_ram_in_cache

Message ID 20201111125414.25033-1-joakim.tjernlund@infinera.com
State Rejected
Delegated to: Tom Rini
Headers show
Series mpc83xx: Fix dcache setup in lock_ram_in_cache | expand

Commit Message

Joakim Tjernlund Nov. 11, 2020, 12:54 p.m. UTC
Lock dcache before clearing INIT_RAM.
More importantly, invalidate dcache contents before using it as RAM.

Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
---

 Something odd happend, on a stable mpc8321 board, small unrelated code
 changes made the board unbootable. Debugging with an emulator
 it looked like something pulled away the dcache while it was
 in early boot stages.
 I found that if I let the emulator init the DDR before executing,
 all was OK again.
 To me this looked like there was some garbage in the dcache causing
 some DDR access. All this led me to lock_ram_in_cache and the
 the resluting changes in this patch.

 86xx could possible need the same fix

 arch/powerpc/cpu/mpc83xx/start.S | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

Comments

Joakim Tjernlund Nov. 13, 2020, 2:37 p.m. UTC | #1
You can disregard this patch, unless you think this is a good idea in general.
The patch caused the same problem on another 83xx of very similar design.

ATM, it looks like disabling the icache while executing in flash(turn of once in RAM)
works for all boards.
Seems like something goes terribly wrong with the CPUs cache and the CPU just RESET itself

 Jocke

On Wed, 2020-11-11 at 13:54 +0100, Joakim Tjernlund wrote:
> Lock dcache before clearing INIT_RAM.
> More importantly, invalidate dcache contents before using it as RAM.
> 
> Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
> ---
> 
>  Something odd happend, on a stable mpc8321 board, small unrelated code
>  changes made the board unbootable. Debugging with an emulator
>  it looked like something pulled away the dcache while it was
>  in early boot stages.
>  I found that if I let the emulator init the DDR before executing,
>  all was OK again.
>  To me this looked like there was some garbage in the dcache causing
>  some DDR access. All this led me to lock_ram_in_cache and the
>  the resluting changes in this patch.
> 
>  86xx could possible need the same fix
> 
>  arch/powerpc/cpu/mpc83xx/start.S | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/powerpc/cpu/mpc83xx/start.S b/arch/powerpc/cpu/mpc83xx/start.S
> index c00bb31363..a1f3b56433 100644
> --- a/arch/powerpc/cpu/mpc83xx/start.S
> +++ b/arch/powerpc/cpu/mpc83xx/start.S
> @@ -1071,18 +1071,22 @@ lock_ram_in_cache:
>  	ori	r3, r3, (CONFIG_SYS_INIT_RAM_ADDR & ~31)@l
>  	li	r4, ((CONFIG_SYS_INIT_RAM_SIZE & ~31) + \
>  		     (CONFIG_SYS_INIT_RAM_ADDR & 31) + 31) / 32
> +	/* Lock the data cache */
> +	mfspr	r0, HID0
> +	ori	r0, r0, HID0_DLOCK|HID0_DCFI
> +	sync
> +	mtspr	HID0, r0
> +	rlwinm	r0, r0, 0, ~HID0_DCFI /* Clear HID0_DCFI */
> +	sync
> +	mtspr	HID0, r0
> +	sync
> +
>  	mtctr	r4
>  1:
>  	dcbz	r0, r3
>  	addi	r3, r3, 32
>  	bdnz	1b
>  
> 
> -	/* Lock the data cache */
> -	mfspr	r0, HID0
> -	ori	r0, r0, HID0_DLOCK
> -	sync
> -	mtspr	HID0, r0
> -	sync
>  	blr
>  
> 
>  #ifndef MINIMAL_SPL
diff mbox series

Patch

diff --git a/arch/powerpc/cpu/mpc83xx/start.S b/arch/powerpc/cpu/mpc83xx/start.S
index c00bb31363..a1f3b56433 100644
--- a/arch/powerpc/cpu/mpc83xx/start.S
+++ b/arch/powerpc/cpu/mpc83xx/start.S
@@ -1071,18 +1071,22 @@  lock_ram_in_cache:
 	ori	r3, r3, (CONFIG_SYS_INIT_RAM_ADDR & ~31)@l
 	li	r4, ((CONFIG_SYS_INIT_RAM_SIZE & ~31) + \
 		     (CONFIG_SYS_INIT_RAM_ADDR & 31) + 31) / 32
+	/* Lock the data cache */
+	mfspr	r0, HID0
+	ori	r0, r0, HID0_DLOCK|HID0_DCFI
+	sync
+	mtspr	HID0, r0
+	rlwinm	r0, r0, 0, ~HID0_DCFI /* Clear HID0_DCFI */
+	sync
+	mtspr	HID0, r0
+	sync
+
 	mtctr	r4
 1:
 	dcbz	r0, r3
 	addi	r3, r3, 32
 	bdnz	1b
 
-	/* Lock the data cache */
-	mfspr	r0, HID0
-	ori	r0, r0, HID0_DLOCK
-	sync
-	mtspr	HID0, r0
-	sync
 	blr
 
 #ifndef MINIMAL_SPL