arm SMP on Cortex-A15
Wojciech Macek
wma at semihalf.com
Fri Mar 21 06:21:05 UTC 2014
No, changing flushD to flushID did not make any difference, but I think it
should be there - D-only flushing might not be sufficient.
Currently, I'm running pmap_kernel_internal attached below. It is doing
unconditional flushID at the end, just like the old comment was saying :)
SMP seems to be stable.
/*
* add a wired page to the kva
* note that in order for the mapping to take effect -- you
* should do a invltlb after doing the pmap_kenter...
*/
static PMAP_INLINE void
pmap_kenter_internal(vm_offset_t va, vm_offset_t pa, int flags)
{
struct l2_bucket *l2b;
pt_entry_t *ptep;
pt_entry_t opte;
PDEBUG(1, printf("pmap_kenter: va = %08x, pa = %08x\n",
(uint32_t) va, (uint32_t) pa));
l2b = pmap_get_l2_bucket(pmap_kernel(), va);
if (l2b == NULL)
l2b = pmap_grow_l2_bucket(pmap_kernel(), va);
KASSERT(l2b != NULL, ("No L2 Bucket"));
ptep = &l2b->l2b_kva[l2pte_index(va)];
opte = *ptep;
if (flags & KENTER_CACHE) {
*ptep = L2_S_PROTO | pa | pte_l2_s_cache_mode | L2_S_REF;
pmap_set_prot(ptep, VM_PROT_READ | VM_PROT_WRITE,
flags & KENTER_USER);
} else {
*ptep = L2_S_PROTO | pa | L2_S_REF;
pmap_set_prot(ptep, VM_PROT_READ|VM_PROT_WRITE|VM_PROT_EXECUTE,
0);
}
PDEBUG(1, printf("pmap_kenter: pte = %08x, opte = %08x, npte = %08x\n",
(uint32_t) ptep, opte, *ptep));
if (!l2pte_valid(opte) && (opte == 0)) {
l2b->l2b_occupancy++;
}
PTE_SYNC(ptep);
cpu_tlb_flushID_SE(va);
cpu_cpwait();
}
2014-03-20 14:02 GMT+01:00 Ian Lepore <ian at freebsd.org>:
> On Thu, 2014-03-20 at 08:42 +0100, Wojciech Macek wrote:
> > Hi Ian,
> >
> > Thanks, I looked at your patch and tried to run it. Unfortunatelly, it is
> > still something wrong on A15 core. Your changes in pmap_kenter_internal
> do
> > cause panics during startup. Apparently we still need to do
> > cpu_tlb_flushID_SE(va) at the end of that function... but that is weird.
> I
> > made this small "fix" and I'm able to boot the system. I'm going to run
> > stress tests now to see if it is stable.
> >
> > Regarding DEBUG, that is really interesting. It you see that on A9 that
> > seems to be even worse, because suggests a flaw in pmap logic...
> >
> > Wojtek
>
> Hmmm, do you have r263251?
>
> I just noticed that my version of the change to pmap_kenter_internal
> uses cpu_tlb_flushD_SE(), yours uses cpu_tlb_flushID_SE(). I wonder if
> changing mine to ID is all it takes to make your system boot?
>
> -- Ian
>
>
>
More information about the freebsd-arm
mailing list