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
> ---
>
> 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:
> dcbzr0, r3
> addir3, r3, 32
> bdnz1b
>
>
> - /* Lock the data cache */
> - mfspr r0, HID0
> - ori r0, r0, HID0_DLOCK
> - sync
> - mtspr HID0, r0
> - sync
> blr
>
>
> #ifndef MINIMAL_SPL
