[Qemu-devel] BookE MMU question

[Qemu-devel] BookE MMU question

[BALATON Zoltan]

Hello,

While trying to get my recently posted Sam460ex emulation working (more 
details on that here: 
http://lists.nongnu.org/archive/html/qemu-ppc/2017-08/msg00112.html)
I'm stuck at a point with BookE MMU behaviour that seems to differ from 
real hardware but I don't know much about it so I hope someone with more 
knowledge can spot the problem or give some hints where to look for it.

When trying to boot AROS it currently fails when mmu_init() is run from 
https://github.com/ezrec/AROS-mirror/blob/ABI_V1/AROS/arch/ppc-sam440/kernel/mmu.c
(around line 273 I think).

With a lot of debug enabled I see this:

[KRN] MMU Init
[KRN] lowest = 007f74e8, base = 00800000, highest = 00c081f0
[KRN] Kernel size: 4128KB code, 34KB data
[KRN] Executing at ff841658, stack at ff7fd260, bss at ff7fd848, data at ff7fffb8
[KRN] TLB0f: -I---rwxrwx 00000000 - 0fffffff : 00000000: 0:00000290 1:00000000 2:0000043f
[KRN] TLB02: -I-G-rw-rw- 80000000 - 8fffffff : 80000000: 0:80000290 1:8000000c 2:0000051b
[KRN] TLB03: -I-G-rw-rw- 90000000 - 9fffffff : 90000000: 0:90000290 1:9000000c 2:0000051b
[KRN] TLB04: -I-G-rw-rw- a0000000 - afffffff : a0000000: 0:a0000290 1:a000000d 2:0000051b
[KRN] TLB05: -I-G-rw-rw- b0000000 - bfffffff : b0000000: 0:b0000290 1:b000000d 2:0000051b
[KRN] TLB06: -I-G-rw-rw- c0000000 - cfffffff : c0000000: 0:c0000290 1:c000000d 2:0000051b
[KRN] TLB01: -I-G-rw-rw- d0000000 - dfffffff : 00000000: 0:d0000290 1:0000000c 2:0000051b
[KRN] TLB07: -I-G-rw-rw- e0000000 - e0ffffff : 00000000: 0:e0000270 1:0000000d 2:0000051b
[KRN] TLB08: -I-G-rw-rw- e1000000 - e1ffffff : 20000000: 0:e1000270 1:2000000d 2:0000051b
[KRN] TLB0e: -I-G-rwxrwx e2000000 - e20fffff : bff00000: 0:e2000250 1:bff00004 2:0000053f
[KRN] TLB09: -I-G-rw-rw- e3000000 - e30003ff : 10000000: 0:e3000200 1:1000000d 2:0000051b
[KRN] TLB0a: -I-G-rw-rw- e3001000 - e30013ff : 30000000: 0:e3001200 1:3000000d 2:0000051b
[KRN] TLB0b: -I-G-rw-rw- e4000000 - e4003fff : 08010000: 0:e4000220 1:0801000c 2:0000051b
[KRN] TLB0c: -I---rwxrwx e5000000 - e50fffff : 00000000: 0:e5000250 1:00000004 2:0000043f
[KRN] TLB0d: -I-G-rwxrwx ef000000 - efffffff : ef000000: 0:ef000270 1:ef000004 2:0000053f
[KRN] TLB00: -I---rwxrwx ff000000 - ffffffff : 00000000: 0:ff000270 1:00000000 2:0000043f
[KRN] map_region(007f7000, ff7f7000, 00009000, 081b):
[KRN] TLB00: 007f7000 - 007f7fff : ff7f7000 - ff7f7fff:

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
ppcemb_tlb_check: TLB 1 address ff7fd648 PID 0 <=> d0000000 f0000000 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 2 address ff7fd648 PID 0 <=> 80000000 f0000000 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 3 address ff7fd648 PID 0 <=> 90000000 f0000000 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 4 address ff7fd648 PID 0 <=> a0000000 f0000000 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 5 address ff7fd648 PID 0 <=> b0000000 f0000000 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 6 address ff7fd648 PID 0 <=> c0000000 f0000000 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 7 address ff7fd648 PID 0 <=> e0000000 ff000000 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 8 address ff7fd648 PID 0 <=> e1000000 ff000000 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 9 address ff7fd648 PID 0 <=> e3000000 fffffc00 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 10 address ff7fd648 PID 0 <=> e3001000 fffffc00 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 11 address ff7fd648 PID 0 <=> e4000000 ffffc000 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 12 address ff7fd648 PID 0 <=> e5000000 fff00000 0 7f
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 13 address ff7fd648 PID 0 <=> ef000000 ff000000 0 7f
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 14 address ff7fd648 PID 0 <=> e2000000 fff00000 0 7f
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 15 address ff7fd648 PID 0 <=> 00000000 f0000000 0 7f
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
mmubooke_get_physical_address: access refused ff7fd648 => ffffffffffffffff 0 -1

Apparently this works on real hardware (although I could not check because 
I don't have access to it and found no logs proving it) but fails in 
emulation so it may be a bug or some difference in emulation. Does anyone 
have any idea? Could this be related to caching/shadow TLBs on real 
hardware that are not emulated? How could this be fixed in QEMU?

Regards,
BALATON Zoltan

Re: [Qemu-devel] BookE MMU question

[KONRAD Frederic]

Hi,

I think you need to go more in detail in what this map_region
function does.. 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 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.

Fred


On 08/18/2017 03:48 PM, BALATON Zoltan wrote:
> Hello,
> 
> While trying to get my recently posted Sam460ex emulation working 
> (more details on that here: 
> http://lists.nongnu.org/archive/html/qemu-ppc/2017-08/msg00112.html)
> I'm stuck at a point with BookE MMU behaviour that seems to 
> differ from real hardware but I don't know much about it so I 
> hope someone with more knowledge can spot the problem or give 
> some hints where to look for it.
> 
> When trying to boot AROS it currently fails when mmu_init() is 
> run from 
> https://github.com/ezrec/AROS-mirror/blob/ABI_V1/AROS/arch/ppc-sam440/kernel/mmu.c 
> 
> (around line 273 I think).
> 
> With a lot of debug enabled I see this:
> 
> [KRN] MMU Init
> [KRN] lowest = 007f74e8, base = 00800000, highest = 00c081f0
> [KRN] Kernel size: 4128KB code, 34KB data
> [KRN] Executing at ff841658, stack at ff7fd260, bss at ff7fd848, 
> data at ff7fffb8
> [KRN] TLB0f: -I---rwxrwx 00000000 - 0fffffff : 00000000: 
> 0:00000290 1:00000000 2:0000043f
> [KRN] TLB02: -I-G-rw-rw- 80000000 - 8fffffff : 80000000: 
> 0:80000290 1:8000000c 2:0000051b
> [KRN] TLB03: -I-G-rw-rw- 90000000 - 9fffffff : 90000000: 
> 0:90000290 1:9000000c 2:0000051b
> [KRN] TLB04: -I-G-rw-rw- a0000000 - afffffff : a0000000: 
> 0:a0000290 1:a000000d 2:0000051b
> [KRN] TLB05: -I-G-rw-rw- b0000000 - bfffffff : b0000000: 
> 0:b0000290 1:b000000d 2:0000051b
> [KRN] TLB06: -I-G-rw-rw- c0000000 - cfffffff : c0000000: 
> 0:c0000290 1:c000000d 2:0000051b
> [KRN] TLB01: -I-G-rw-rw- d0000000 - dfffffff : 00000000: 
> 0:d0000290 1:0000000c 2:0000051b
> [KRN] TLB07: -I-G-rw-rw- e0000000 - e0ffffff : 00000000: 
> 0:e0000270 1:0000000d 2:0000051b
> [KRN] TLB08: -I-G-rw-rw- e1000000 - e1ffffff : 20000000: 
> 0:e1000270 1:2000000d 2:0000051b
> [KRN] TLB0e: -I-G-rwxrwx e2000000 - e20fffff : bff00000: 
> 0:e2000250 1:bff00004 2:0000053f
> [KRN] TLB09: -I-G-rw-rw- e3000000 - e30003ff : 10000000: 
> 0:e3000200 1:1000000d 2:0000051b
> [KRN] TLB0a: -I-G-rw-rw- e3001000 - e30013ff : 30000000: 
> 0:e3001200 1:3000000d 2:0000051b
> [KRN] TLB0b: -I-G-rw-rw- e4000000 - e4003fff : 08010000: 
> 0:e4000220 1:0801000c 2:0000051b
> [KRN] TLB0c: -I---rwxrwx e5000000 - e50fffff : 00000000: 
> 0:e5000250 1:00000004 2:0000043f
> [KRN] TLB0d: -I-G-rwxrwx ef000000 - efffffff : ef000000: 
> 0:ef000270 1:ef000004 2:0000053f
> [KRN] TLB00: -I---rwxrwx ff000000 - ffffffff : 00000000: 
> 0:ff000270 1:00000000 2:0000043f
> [KRN] map_region(007f7000, ff7f7000, 00009000, 081b):
> [KRN] TLB00: 007f7000 - 007f7fff : ff7f7000 - ff7f7fff:
> 
> 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
> ppcemb_tlb_check: TLB 1 address ff7fd648 PID 0 <=> d0000000 
> f0000000 0 3b
> mmubooke_check_tlb: TLB entry not found
> ppcemb_tlb_check: TLB 2 address ff7fd648 PID 0 <=> 80000000 
> f0000000 0 3b
> mmubooke_check_tlb: TLB entry not found
> ppcemb_tlb_check: TLB 3 address ff7fd648 PID 0 <=> 90000000 
> f0000000 0 3b
> mmubooke_check_tlb: TLB entry not found
> ppcemb_tlb_check: TLB 4 address ff7fd648 PID 0 <=> a0000000 
> f0000000 0 3b
> mmubooke_check_tlb: TLB entry not found
> ppcemb_tlb_check: TLB 5 address ff7fd648 PID 0 <=> b0000000 
> f0000000 0 3b
> mmubooke_check_tlb: TLB entry not found
> ppcemb_tlb_check: TLB 6 address ff7fd648 PID 0 <=> c0000000 
> f0000000 0 3b
> mmubooke_check_tlb: TLB entry not found
> ppcemb_tlb_check: TLB 7 address ff7fd648 PID 0 <=> e0000000 
> ff000000 0 3b
> mmubooke_check_tlb: TLB entry not found
> ppcemb_tlb_check: TLB 8 address ff7fd648 PID 0 <=> e1000000 
> ff000000 0 3b
> mmubooke_check_tlb: TLB entry not found
> ppcemb_tlb_check: TLB 9 address ff7fd648 PID 0 <=> e3000000 
> fffffc00 0 3b
> mmubooke_check_tlb: TLB entry not found
> ppcemb_tlb_check: TLB 10 address ff7fd648 PID 0 <=> e3001000 
> fffffc00 0 3b
> mmubooke_check_tlb: TLB entry not found
> ppcemb_tlb_check: TLB 11 address ff7fd648 PID 0 <=> e4000000 
> ffffc000 0 3b
> mmubooke_check_tlb: TLB entry not found
> ppcemb_tlb_check: TLB 12 address ff7fd648 PID 0 <=> e5000000 
> fff00000 0 7f
> mmubooke_check_tlb: TLB entry not found
> ppcemb_tlb_check: TLB 13 address ff7fd648 PID 0 <=> ef000000 
> ff000000 0 7f
> mmubooke_check_tlb: TLB entry not found
> ppcemb_tlb_check: TLB 14 address ff7fd648 PID 0 <=> e2000000 
> fff00000 0 7f
> mmubooke_check_tlb: TLB entry not found
> ppcemb_tlb_check: TLB 15 address ff7fd648 PID 0 <=> 00000000 
> f0000000 0 7f
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_check_tlb: TLB entry not found
> mmubooke_get_physical_address: access refused ff7fd648 => 
> ffffffffffffffff 0 -1
> 
> Apparently this works on real hardware (although I could not 
> check because I don't have access to it and found no logs proving 
> it) but fails in emulation so it may be a bug or some difference 
> in emulation. Does anyone have any idea? Could this be related to 
> caching/shadow TLBs on real hardware that are not emulated? How 
> could this be fixed in QEMU?
> 
> Regards,
> BALATON Zoltan
> 

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

[BALATON Zoltan]

On Sun, 20 Aug 2017, KONRAD Frederic wrote:
> Hi,
>
> I think you need to go more in detail in what this map_region
> function does..

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.

>
> Fred
>
>
> On 08/18/2017 03:48 PM, BALATON Zoltan wrote:
>> Hello,
>> 
>> While trying to get my recently posted Sam460ex emulation working (more 
>> details on that here: 
>> http://lists.nongnu.org/archive/html/qemu-ppc/2017-08/msg00112.html)
>> I'm stuck at a point with BookE MMU behaviour that seems to differ from 
>> real hardware but I don't know much about it so I hope someone with more 
>> knowledge can spot the problem or give some hints where to look for it.
>> 
>> When trying to boot AROS it currently fails when mmu_init() is run from 
>> https://github.com/ezrec/AROS-mirror/blob/ABI_V1/AROS/arch/ppc-sam440/kernel/mmu.c 
>> (around line 273 I think).
>> 
>> With a lot of debug enabled I see this:
>> 
>> [KRN] MMU Init
>> [KRN] lowest = 007f74e8, base = 00800000, highest = 00c081f0
>> [KRN] Kernel size: 4128KB code, 34KB data
>> [KRN] Executing at ff841658, stack at ff7fd260, bss at ff7fd848, data at 
>> ff7fffb8
>> [KRN] TLB0f: -I---rwxrwx 00000000 - 0fffffff : 00000000: 0:00000290 
>> 1:00000000 2:0000043f
>> [KRN] TLB02: -I-G-rw-rw- 80000000 - 8fffffff : 80000000: 0:80000290 
>> 1:8000000c 2:0000051b
>> [KRN] TLB03: -I-G-rw-rw- 90000000 - 9fffffff : 90000000: 0:90000290 
>> 1:9000000c 2:0000051b
>> [KRN] TLB04: -I-G-rw-rw- a0000000 - afffffff : a0000000: 0:a0000290 
>> 1:a000000d 2:0000051b
>> [KRN] TLB05: -I-G-rw-rw- b0000000 - bfffffff : b0000000: 0:b0000290 
>> 1:b000000d 2:0000051b
>> [KRN] TLB06: -I-G-rw-rw- c0000000 - cfffffff : c0000000: 0:c0000290 
>> 1:c000000d 2:0000051b
>> [KRN] TLB01: -I-G-rw-rw- d0000000 - dfffffff : 00000000: 0:d0000290 
>> 1:0000000c 2:0000051b
>> [KRN] TLB07: -I-G-rw-rw- e0000000 - e0ffffff : 00000000: 0:e0000270 
>> 1:0000000d 2:0000051b
>> [KRN] TLB08: -I-G-rw-rw- e1000000 - e1ffffff : 20000000: 0:e1000270 
>> 1:2000000d 2:0000051b
>> [KRN] TLB0e: -I-G-rwxrwx e2000000 - e20fffff : bff00000: 0:e2000250 
>> 1:bff00004 2:0000053f
>> [KRN] TLB09: -I-G-rw-rw- e3000000 - e30003ff : 10000000: 0:e3000200 
>> 1:1000000d 2:0000051b
>> [KRN] TLB0a: -I-G-rw-rw- e3001000 - e30013ff : 30000000: 0:e3001200 
>> 1:3000000d 2:0000051b
>> [KRN] TLB0b: -I-G-rw-rw- e4000000 - e4003fff : 08010000: 0:e4000220 
>> 1:0801000c 2:0000051b
>> [KRN] TLB0c: -I---rwxrwx e5000000 - e50fffff : 00000000: 0:e5000250 
>> 1:00000004 2:0000043f
>> [KRN] TLB0d: -I-G-rwxrwx ef000000 - efffffff : ef000000: 0:ef000270 
>> 1:ef000004 2:0000053f
>> [KRN] TLB00: -I---rwxrwx ff000000 - ffffffff : 00000000: 0:ff000270 
>> 1:00000000 2:0000043f
>> [KRN] map_region(007f7000, ff7f7000, 00009000, 081b):
>> [KRN] TLB00: 007f7000 - 007f7fff : ff7f7000 - ff7f7fff:
>> 
>> 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
>> ppcemb_tlb_check: TLB 1 address ff7fd648 PID 0 <=> d0000000 f0000000 0 3b
>> mmubooke_check_tlb: TLB entry not found
>> ppcemb_tlb_check: TLB 2 address ff7fd648 PID 0 <=> 80000000 f0000000 0 3b
>> mmubooke_check_tlb: TLB entry not found
>> ppcemb_tlb_check: TLB 3 address ff7fd648 PID 0 <=> 90000000 f0000000 0 3b
>> mmubooke_check_tlb: TLB entry not found
>> ppcemb_tlb_check: TLB 4 address ff7fd648 PID 0 <=> a0000000 f0000000 0 3b
>> mmubooke_check_tlb: TLB entry not found
>> ppcemb_tlb_check: TLB 5 address ff7fd648 PID 0 <=> b0000000 f0000000 0 3b
>> mmubooke_check_tlb: TLB entry not found
>> ppcemb_tlb_check: TLB 6 address ff7fd648 PID 0 <=> c0000000 f0000000 0 3b
>> mmubooke_check_tlb: TLB entry not found
>> ppcemb_tlb_check: TLB 7 address ff7fd648 PID 0 <=> e0000000 ff000000 0 3b
>> mmubooke_check_tlb: TLB entry not found
>> ppcemb_tlb_check: TLB 8 address ff7fd648 PID 0 <=> e1000000 ff000000 0 3b
>> mmubooke_check_tlb: TLB entry not found
>> ppcemb_tlb_check: TLB 9 address ff7fd648 PID 0 <=> e3000000 fffffc00 0 3b
>> mmubooke_check_tlb: TLB entry not found
>> ppcemb_tlb_check: TLB 10 address ff7fd648 PID 0 <=> e3001000 fffffc00 0 3b
>> mmubooke_check_tlb: TLB entry not found
>> ppcemb_tlb_check: TLB 11 address ff7fd648 PID 0 <=> e4000000 ffffc000 0 3b
>> mmubooke_check_tlb: TLB entry not found
>> ppcemb_tlb_check: TLB 12 address ff7fd648 PID 0 <=> e5000000 fff00000 0 7f
>> mmubooke_check_tlb: TLB entry not found
>> ppcemb_tlb_check: TLB 13 address ff7fd648 PID 0 <=> ef000000 ff000000 0 7f
>> mmubooke_check_tlb: TLB entry not found
>> ppcemb_tlb_check: TLB 14 address ff7fd648 PID 0 <=> e2000000 fff00000 0 7f
>> mmubooke_check_tlb: TLB entry not found
>> ppcemb_tlb_check: TLB 15 address ff7fd648 PID 0 <=> 00000000 f0000000 0 7f
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_check_tlb: TLB entry not found
>> mmubooke_get_physical_address: access refused ff7fd648 => ffffffffffffffff 
>> 0 -1
>> 
>> Apparently this works on real hardware (although I could not check because 
>> I don't have access to it and found no logs proving it) but fails in 
>> emulation so it may be a bug or some difference in emulation. Does anyone 
>> have any idea? Could this be related to caching/shadow TLBs on real 
>> hardware that are not emulated? How could this be fixed in QEMU?
>> 
>> Regards,
>> BALATON Zoltan
>> 
>
>

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

[Mark Cave-Ayland]

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
https://github.com/ezrec/AROS-mirror/blob/ABI_V1/AROS/arch/ppc-sam440/kernel/mmu.c
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.


ATB,

Mark.

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

[BALATON Zoltan]

On Sun, 20 Aug 2017, Mark Cave-Ayland wrote:
> 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
> https://github.com/ezrec/AROS-mirror/blob/ABI_V1/AROS/arch/ppc-sam440/kernel/mmu.c
> 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

Unfortunately I can't test what it does on real hardware, that's why I was 
asking if there's anyone with this board who can do some testing. Without 
that I'm not sure how it should work, I can only test what it does on 
QEMU.

> 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

This did not need a lot of fortune. It builds with a few simple fixes and 
a lot of disk space and patience. I've tried adding more debug log to show 
what the loop has selected.

> 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.

I've tried with the additional debug and the results are a bit unexpected 
because now I get:

[KRN] lowest = 007f74e8, base = 00800000, highest = 00c08260
[...]
[KRN] TLB00: -I---rwxrwx ff000000 - ffffffff : 00000000: 0:ff000270 1:00000000 2:0000043f
[...]
[KRN] Executing at ff841690, stack at ff7fd260, bss at ff7fd848, data at ff7fffb8

ppcemb_tlb_check: TLB 0 address ff841690 PID 0 <=> ff000000 ff000000 0 7f
mmubooke_check_tlb: good TLB!
mmubooke_get_physical_address: access granted ff841690 => 0000000000841690 7 0
tlb_set_page_with_attrs: vaddr=ff841400 paddr=0x0000000000841400 prot=7 idx=1
ppcemb_tlb_check: TLB 0 address ff840c9c PID 0 <=> ff000000 ff000000 0 7f
mmubooke_check_tlb: good TLB!
mmubooke_get_physical_address: access granted ff840c9c => 0000000000840c9c 7 0
tlb_set_page_with_attrs: vaddr=ff840c00 paddr=0x0000000000840c00 prot=7 idx=1

[KRN] map_region(00800000, ff800000, 00410000, 082f):

ppcemb_tlb_check: TLB 0 address ff871b7c PID 0 <=> ff000000 ff000000 0 7f
mmubooke_check_tlb: good TLB!
mmubooke_get_physical_address: access granted ff871b7c => 0000000000871b7c 7 0
tlb_set_page_with_attrs: vaddr=ff871800 paddr=0x0000000000871800 prot=7 idx=1

[KRN] i = 2, allowable_pages[i].mask = 000fffff:

ppcemb_tlb_check: TLB 0 address ff840e0c PID 0 <=> ff000000 ff000000 0 7f
mmubooke_check_tlb: good TLB!
mmubooke_get_physical_address: access granted ff840e0c => 0000000000840e0c 7 0
tlb_set_page_with_attrs: vaddr=ff840c00 paddr=0x0000000000840c00 prot=7 idx=1
ppcemb_tlb_check: TLB 0 address ff840a18 PID 0 <=> ff000000 ff000000 0 7f
mmubooke_check_tlb: good TLB!
mmubooke_get_physical_address: access granted ff840a18 => 0000000000840a18 7 0
tlb_set_page_with_attrs: vaddr=ff840800 paddr=0x0000000000840800 prot=7 idx=1

[KRN] TLB00: 00800000 - 008fffff : ff800000 - ff8fffff:

helper_440_tlbwe word 0 entry 0 value ff800250
tlb_flush_nocheck: (count: 37)
helper_440_tlbwe word 1 entry 0 value 00800000
tlb_flush_nocheck: (count: 38)
helper_440_tlbwe word 2 entry 0 value 0000082f
ppcemb_tlb_check: TLB 0 address ff7fd648 PID 0 <=> ff800000 fff00000 0 7d
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 1 address ff7fd648 PID 0 <=> d0000000 f0000000 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 2 address ff7fd648 PID 0 <=> 80000000 f0000000 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 3 address ff7fd648 PID 0 <=> 90000000 f0000000 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 4 address ff7fd648 PID 0 <=> a0000000 f0000000 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 5 address ff7fd648 PID 0 <=> b0000000 f0000000 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 6 address ff7fd648 PID 0 <=> c0000000 f0000000 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 7 address ff7fd648 PID 0 <=> e0000000 ff000000 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 8 address ff7fd648 PID 0 <=> e1000000 ff000000 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 9 address ff7fd648 PID 0 <=> e3000000 fffffc00 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 10 address ff7fd648 PID 0 <=> e3001000 fffffc00 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 11 address ff7fd648 PID 0 <=> e4000000 ffffc000 0 3b
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 12 address ff7fd648 PID 0 <=> e5000000 fff00000 0 7f
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 13 address ff7fd648 PID 0 <=> ef000000 ff000000 0 7f
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 14 address ff7fd648 PID 0 <=> e2000000 fff00000 0 7f
mmubooke_check_tlb: TLB entry not found
ppcemb_tlb_check: TLB 15 address ff7fd648 PID 0 <=> 00000000 f0000000 0 7f
mmubooke_check_tlb: TLB entry not found
mmubooke_check_tlb: TLB entry not found
[...]
mmubooke_get_physical_address: access refused ff7fd648 => ffffffffffffffff 0 -1

The unexpected part is that now the kernel base at 00800000 is tried to be 
mapped not the data area. Actually this matches the order in mmu.c:273, so 
I'm not sure why I got the error with the data area first. Maybe because 
previously I've tried to change the order of these map_region calls to see 
if that changes anything and this may have been left in the binary somehow 
after reverting this change (although I've rebuild multiple times after 
the revert).

Anyway, this makes more sense because if the TLB 0 entry is replaced like 
the above log shows then there will be no mapping for the ff7fd648 address 
until the next map_region call maps it. On real hardware this seems to 
work but on QEMU this causes an exception. Any idea why? My guesses are 
that on real hardware either the initial TLB entries are different so this 
call does not replace the entry used to look up addresses needed for 
running this code or the TLB changes are not effective until the last 
isync is executed to flush shadow TLB regs which still contain mappings 
that allow this code to run. To confirm this I'd need logs from real 
hardware though.

Any idea how to fix this problem?

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

That's what I wanted to avoid and hoped someone already with this 
knowledge can spot the problem easily. I don't have much time to spend on 
learning everything about PPC features and their QEMU implementation so I 
rather asked.

Thank you,
BALATON Zoltan

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

[Mark Cave-Ayland]

On 20/08/17 14:35, BALATON Zoltan wrote:

> Anyway, this makes more sense because if the TLB 0 entry is replaced
> like the above log shows then there will be no mapping for the ff7fd648
> address until the next map_region call maps it. On real hardware this
> seems to work but on QEMU this causes an exception. Any idea why? My
> guesses are that on real hardware either the initial TLB entries are
> different so this call does not replace the entry used to look up
> addresses needed for running this code or the TLB changes are not
> effective until the last isync is executed to flush shadow TLB regs
> which still contain mappings that allow this code to run. To confirm
> this I'd need logs from real hardware though.
> 
> Any idea how to fix this problem?

Just glancing at the code again it looks like the choice of slot is
determined by alloc_tlb(). It seems there are 64 TLB slots stored in
tlb_info as 2 x 32-bit bitmaps where a 1 bit indicates the slot is free
and a 0 bit indicates the slot is in use.

>From alloc_tlb() you can see that it uses clz (count leading zeros) in
order to locate the next free TLB slot in the bitmap, returning the slot
number as an integer (tlb) which is then passed into tlbwe.

So I'd suggest adding debugging to alloc_tlb() to find out why TLB slot
0 is being chosen again for the 0x80000000 mapping even though
free_tlb() hasn't been called for that entry.

>> And of course read the BookE specification to understand exactly what
>> types of TLB mapping are available, particularly with respect to page
>> size.
> 
> That's what I wanted to avoid and hoped someone already with this
> knowledge can spot the problem easily. I don't have much time to spend
> on learning everything about PPC features and their QEMU implementation
> so I rather asked.

Sometimes when debugging MMU issues there is no other choice :)


ATB,

Mark.

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

[BALATON Zoltan]

On Sun, 20 Aug 2017, Mark Cave-Ayland wrote:
> Just glancing at the code again it looks like the choice of slot is
> determined by alloc_tlb(). It seems there are 64 TLB slots stored in
> tlb_info as 2 x 32-bit bitmaps where a 1 bit indicates the slot is free
> and a 0 bit indicates the slot is in use.
>
> From alloc_tlb() you can see that it uses clz (count leading zeros) in
> order to locate the next free TLB slot in the bitmap, returning the slot
> number as an integer (tlb) which is then passed into tlbwe.
>
> So I'd suggest adding debugging to alloc_tlb() to find out why TLB slot
> 0 is being chosen again for the 0x80000000 mapping even though
> free_tlb() hasn't been called for that entry.

I've tried that but it only confirmed what I thought. This is the first 
map_region call so nothing is allocated yet and it just picks the first 
slot:

[KRN] i = 2, allowable_pages[i].mask = 000fffff; tlb_info ffffffff:ffffffff => 7fffffff:ffffffff

(The numbers after tlb_info are bitmap[0]:bitmap[1] before and after the 
alloc_tlb() call.) So this looks OK just does not work on QEMU and I don't 
know why it works on real hardware (or if it works there at all but I 
assume it does).

I've also tried to change mmubooke_create_initial_mapping_uboot() in 
sam460ex.c to use another TLB slot than 0 for the initial mapping hoping 
it may avoid the problem but that does not work because U-Boot clears TLB 
slots 1-63 so it has to be slot 0. Because of this I think it cannot be 
another slot on real hardware either and it probably works due to caching 
TLB entries in shadow TLB until the isync call at the end of mmu_init(). 
How could that be matched in QEMU?

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

[Mark Cave-Ayland]

On 20/08/17 22:59, BALATON Zoltan wrote:

>> So I'd suggest adding debugging to alloc_tlb() to find out why TLB slot
>> 0 is being chosen again for the 0x80000000 mapping even though
>> free_tlb() hasn't been called for that entry.
> 
> I've tried that but it only confirmed what I thought. This is the first
> map_region call so nothing is allocated yet and it just picks the first
> slot:
> 
> [KRN] i = 2, allowable_pages[i].mask = 000fffff; tlb_info
> ffffffff:ffffffff => 7fffffff:ffffffff
> 
> (The numbers after tlb_info are bitmap[0]:bitmap[1] before and after the
> alloc_tlb() call.) So this looks OK just does not work on QEMU and I
> don't know why it works on real hardware (or if it works there at all
> but I assume it does).

I'm slightly confused here as I thought you'd said you changed the order
of the mappings? But if its the first entry then I presume you mean
we're back to this one, which is definitely the first mapping according
to the source.

ppcemb_tlb_check: TLB 0 address ff7fd648 PID 0 <=> ff7f7000 fffff000 03b
mmubooke_check_tlb: TLB entry not found

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

In that case the working is as follows:

- You request a region of size 0x9000
- map_region() rounds this up to the next biggest size from
  allowable_pages() which is 64KB (0xffff) with
  allowable_pages.code == 0x30
- The 0x30 code (which indicates the page size) is encoded into the
  first tlbwe instruction

The first thing I'd check is to follow through QEMU's tlbwe and make
sure that the 0x30 gets decoded correctly back to a TLB size of 0x10000
as indicated by allowable_pages - at the moment it looks as if QEMU is
interpreting the 0x30 as a page size of 0x1000 instead.


ATB,

Mark.

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

[BALATON Zoltan]

On Sun, 20 Aug 2017, Mark Cave-Ayland wrote:
> On 20/08/17 22:59, BALATON Zoltan wrote:
>
>>> So I'd suggest adding debugging to alloc_tlb() to find out why TLB slot
>>> 0 is being chosen again for the 0x80000000 mapping even though
>>> free_tlb() hasn't been called for that entry.
>>
>> I've tried that but it only confirmed what I thought. This is the first
>> map_region call so nothing is allocated yet and it just picks the first
>> slot:
>>
>> [KRN] i = 2, allowable_pages[i].mask = 000fffff; tlb_info
>> ffffffff:ffffffff => 7fffffff:ffffffff
>>
>> (The numbers after tlb_info are bitmap[0]:bitmap[1] before and after the
>> alloc_tlb() call.) So this looks OK just does not work on QEMU and I
>> don't know why it works on real hardware (or if it works there at all
>> but I assume it does).
>
> I'm slightly confused here as I thought you'd said you changed the order
> of the mappings? But if its the first entry then I presume you mean
> we're back to this one, which is definitely the first mapping according
> to the source.
>
> ppcemb_tlb_check: TLB 0 address ff7fd648 PID 0 <=> ff7f7000 fffff000 03b
> mmubooke_check_tlb: TLB entry not found
>
> [KRN] map_region(007f7000, ff7f7000, 00009000, 081b):
> [KRN] TLB00: 007f7000 - 007f7fff : ff7f7000 - ff7f7fff:

Forget this, this was by mistake, we don't even reach this because the 
mapping of 00800000 is already failing. That needs to be fixed first.

> In that case the working is as follows:
>
> - You request a region of size 0x9000
> - map_region() rounds this up to the next biggest size from
>  allowable_pages() which is 64KB (0xffff) with
>  allowable_pages.code == 0x30
> - The 0x30 code (which indicates the page size) is encoded into the
>  first tlbwe instruction
>
> The first thing I'd check is to follow through QEMU's tlbwe and make
> sure that the 0x30 gets decoded correctly back to a TLB size of 0x10000
> as indicated by allowable_pages - at the moment it looks as if QEMU is
> interpreting the 0x30 as a page size of 0x1000 instead.

I've run out of time for now, I'll check this when the first problem is 
solved and this will still be a problem by then.

Thanks,
BALATON Zoltan