[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] BookE MMU question

From: Mark Cave-Ayland
Subject: Re: [Qemu-ppc] [Qemu-devel] BookE MMU question
Date: Sun, 20 Aug 2017 08:20:45 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

On 20/08/17 00:19, BALATON Zoltan wrote:

> This function is defined in AROS/arch/ppc-sam440/kernel/mmu.c:95 at the
> link below. I think it basically generates tlbwe instructions to set up
> a TLB entry to map the region to a virtual address.
>> eg: what is in the MAS registers before the tlbwe
>> happen (checking field by field) and what is the tlb which is
>> created / expected.
> I don't know what MAS registers are. Is that specific to BOOKE206? The
> PPC440 core in this board has POWERPC_MMU_BOOKE, not 206 but I don't
> know what's the difference between these. The TLB entries before and
> after the tlbwe instructions are logged below and I think TLB 0 should
> match the address that is tried to be accessed (ff7fd648) but it fails
> and returns refused. Does it ignore the new TLB entry just set for some
> reason?
>> I got a pretty similar problem with a MAV V2 MMU and fixed size
>> tlb.. But I don't think it affects your device.. I'm not totally
>> sure though.
> Do you have more info on this? Is it this patch: "booke206: fix tlbnps
> for fixed size TLB"? Unfortunately I don't understand that code well
> enough to tell if it's the same problem but your changes are specific to
> mmu_booke206 so they won't fix this problem with mmu_booke for sure.
> Thanks for the suggestions but I think I need more help with this.

I've only spent a small amount of time in PPC MMU land via OpenBIOS but
the obvious thing that stands out here is this:

helper_440_tlbwe word 0 entry 0 value ff7f7210
tlb_flush_nocheck: (count: 36)
helper_440_tlbwe word 1 entry 0 value 007f7000
tlb_flush_nocheck: (count: 37)
helper_440_tlbwe word 2 entry 0 value 0000081b
ppcemb_tlb_check: TLB 0 address ff7fd648 PID 0 <=> ff7f7000 fffff000 0 3b
mmubooke_check_tlb: TLB entry not found

[KRN] map_region(007f7000, ff7f7000, 00009000, 081b):
[KRN] TLB00: 007f7000 - 007f7fff : ff7f7000 - ff7f7fff:

Here you can see that map_region() in
is requesting to map a region of size 0x9000 but the size of the
resulting TLB entry is only 0x1000 (4KB) which I believe is default PPC
page size.

So I would suggest 2 things here:

1) Confirm AROS's map_region() iterates once for the 0xff7f7000 mapping

On the plus side, it seems that you are fortunate to be able to builg
the AROS sources yourself. Make sure that the while (length) {} loop in
map_region() iterates only once for the 0xff7f7000 mapping, i.e. only
one TLB entry is expected to be created for map_region(007f7000,
ff7f7000, 00009000, 081b).

My reading of the comments in the source hints that it should be (i.e.
references to minimising the number of TLB entries) however it's always
worth checking to be sure.

2) Check the mask in QEMU's ppcemb_tlb_check()

If the above loop iterates only once then you'll need to figure out why
the region size in the TLB is set to 0x1000 rather than 0x9000. I see
that ppcemb_tlb_check() applies a mask to the address based upon
tlb->size, so I'd work backwards and see where that is being set.

And of course read the BookE specification to understand exactly what
types of TLB mapping are available, particularly with respect to page size.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]