qemu-ppc
[Top][All Lists]
Advanced

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

Re: Cannot Access Memory


From: Fabiano Rosas
Subject: Re: Cannot Access Memory
Date: Tue, 05 Oct 2021 22:10:15 -0300

"Jesse Millwood" <jesse_dev@fastmail.com> writes:

> Balaton, 
> Thanks for the int suggestion. These tracing flags are really useful. I added 
> the int one and got the following: 
>
> Raise exception at fff80000 => 0000000e (00)
> invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 00000000
> Raise exception at 00000000 => 00000060 (21)
> Raise exception at 00000000 => 00000060 (21)
> Raise exception at 00000000 => 00000060 (21)
> Raise exception at 00000000 => 00000060 (21)
>
> So it looks like the 0xe is the exception that happens at my pc, 0xfff80000. 
> It looks like that 0xe corresponds to the exception vectors definitions enum 
> in ppc/cpu.h? So that 0xe would be an instruction tlb miss? Then the others 
> at 0x60 would be Hypervisor emulation assistance? That doesn't seem right. 

This is common. There was an error during instruction fetch of your
first instruction. While dispatching that, QEMU sets the NIP to whatever
the exception vector is (powerpc_excp -> powerpc_set_excp_state), which
in your case is 0x0 because the IVORs are not set yet (init_proc_e500 ->
init_excp_e200). So it executes at 0x0, which contains 0x00000000, which
is an invalid opcode, so it gets an Emulation Assistance (Program
Interrupt in the older ISA versions) and jumps to that vector, which is
0x0 again and it gets stuck doing that forever.

So I'd say that part looks fine. We "just" need to figure out why it is
getting an ITLB exception at the start.

>
> Good find with the mmubooke_create_initial_mapping() suggestion. That 
> function seems to be doing the following: 
> - ps = 0x10
> - size = 0x800 (the ps shifted for the tsize field)
> - tlb mmu assist 1
>   - Looks like it is setting the valid bit and setting the tlb entries to 16KB
> - tlb mmu assist 2
> - tlb mmu assist 7_3 (I'm not entirely sure why this is 7_3 but I can only 
> guess this is the mas3 register?) 
>   - Seems to set the User read/write/execute bits and supervisor read, write, 
> execute bits
>
> It looks like TLBnCFG_N_ENTRY is set to 0xfff
> So it looks like I would have 0xfff x 16000 entries? So then would only 65MB 
> of memory be mapped then off the bat? 

If you take a look at ppce500_cpu_reset, it sets r7 to
mmubooke_initial_mapsize. And your r7 is 0x4000000, so that seems about
right.

I see some places mentioning a start address of 0xfffffffc which is
where code that sets up more TLB entries should be:
- u-boot src: roms/u-boot/arch/powerpc/cpu/mpc85xx/{u-boot.lds,start.S}
- e500 User Manual: 12.6 TLB States after Reset
- QEMU src: target/ppc/cpu_init.c:init_excp_e200 (although ppce500_cpu_reset 
seems to
override it with your elf entry point).

Maybe that is worth a look.




reply via email to

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