Re: fix for mirabox(armada370)

[SUENAGA Hiroki <hsuenaga%iij.ad.jp@localhost>]

On 2015/03/26 16:39, Matt Thomas wrote:

>> this patch may fix a issue of NSLU2. due to TLB Entry
>> isn't cleared, userland processes possibly access to
>> incorrect physical page and causes mysterious crash.
> 
> Since the nSLU2 doesn't use arm32_tlb.c that seems unlikely.

oh, bad news...

>> I confirmed my MIRABOX(ARMADA 370) works fine after
>> applying this patch.
>
> That's ok.  Wonder why my MIRABOX worked without this change.

Hum... Is your code base is not modified from repository?
I found a commented line in tlb_invalidate_addr()

121                 armreg_tlbimva_write(va);
122 #endif
123                 //armreg_tlbiall_write(asid);
124         }

If there were debug codes such as line 123 was enabled, the
TLB is flushed frequently and it may hide the problem. or
there were another debug/diag code enabled, the codes may
use additional TLB entries, and stale TLB entries are gone.

My MIRABOX always failed to complete boot process.
I wonder too...

> Is cpufunc_asm_pj4b.S really needed.  I've patched it to use 
> cpufuncs_armv7 and the mirabox runs fine.  If the pb4b is
> really armv7, then asm_pj4b is just redundant.

Yes, at least current code base.

PJ4B has customized L2 cache that supports DMA between the
chache and integrated devices in SoC. The cache is controlled
by memory mapped registers, isn't by coprosessor operations.
I think there should be L2 cache management code in
cpufunc_asm_pj4b.S...

I don't yet understand that L2 cache management is
really needed or isn't. If L2 cache coherency is
guaranteed by SoC, cpufunc_asm_pj4b.S is just redundant.

Old Sheeva core was not working correctly without L2 cache
management code in cpufunc_asm_sheeva.S.

-- 
SUENAGA Hiroki <hsuenaga%iij.ad.jp@localhost>

PGP: 66B3 8939 6758 20BA F243  89EC 557A 8CFB ABA9 5E92