qemu-ppc
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cannot Access Memory

From: Jesse Millwood
Subject: Re: Cannot Access Memory
Date: Tue, 05 Oct 2021 19:02:44 -0400
User-agent: Cyrus-JMAP/3.5.0-alpha0-1322-g921842b88a-fm-20210929.001-g921842b8
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.

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?

Thanks


----- Original message -----
From: BALATON Zoltan <balaton@eik.bme.hu>
To: Jesse Millwood <jesse_dev@fastmail.com>
Cc: qemu-ppc@nongnu.org
Subject: Re: Cannot Access Memory
Date: Tuesday, October 05, 2021 3:07 PM

On Tue, 5 Oct 2021, Jesse Millwood wrote:
> Balaton,
> Thanks for the -d suggestion. I tried with the ones you suggested and only received this:
> (qemu) c
> (qemu) invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 00000000
>
> I did add cpu and exec to the logs and at the beginning I do see this: invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 00000000
> Trace 0: 0x7fed70000100 [00000000/00000000/24000002/ff000000]
> NIP 00000000   LR 00000000 CTR 00000000 XER 00000000 CPU#0
> MSR 00000000 HID0 00000000  HF 24000002 iidx 1 didx 1
> TB 00000000 00244586 DECR 0
> GPR00 0000000000000000 0000000000fffff8 0000000000000000 0000000001800000
> GPR04 0000000000000000 0000000000000000 0000000045504150 0000000004000000
> GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> CR 00000000  [ -  -  -  -  -  -  -  -  ]             RES ffffffff
> SRR0 fff80000  SRR1 00000000    PVR 80210022 VRSAVE 00000000
> SPRG0 00000000 SPRG1 00000000  SPRG2 00000000  SPRG3 00000000
> SPRG4 00000000 SPRG5 00000000  SPRG6 00000000  SPRG7 00000000
> CSRR0 00000000 CSRR1 00000000 MCSRR0 00000000 MCSRR1 00000000
>  TCR 00000000   TSR 00000000    ESR 00000000   DEAR fff80000
>  PIR 00000000 DECAR 00000000   IVPR 00000000   EPCR 00000000
> MCSR 00000000 SPRG8 00000000    EPR 00000000
> MCAR 00000000  PID1 00000000   PID2 00000000    SVR 00000000
> MAS0 00000001  MAS1 80000000   MAS2 fff80000   MAS3 00000000
> MAS4 00000000  MAS6 00000000   MAS7 00000000    PID 00000000
> MMUCFG 00000000 TLB0CFG 04110200 TLB1CFG 101cc010
> Trace 0: 0x7fed70000100 [00000000/00000000/24000002/ff000000]
> NIP 00000000   LR 00000000 CTR 00000000 XER 00000000 CPU#0
> MSR 00000000 HID0 00000000  HF 24000002 iidx 1 didx 1
> TB 00000000 00273019 DECR 0
> GPR00 0000000000000000 0000000000fffff8 0000000000000000 0000000001800000
> GPR04 0000000000000000 0000000000000000 0000000045504150 0000000004000000
> GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> CR 00000000  [ -  -  -  -  -  -  -  -  ]             RES ffffffff
> SRR0 00000000  SRR1 00080000    PVR 80210022 VRSAVE 00000000
> SPRG0 00000000 SPRG1 00000000  SPRG2 00000000  SPRG3 00000000
> SPRG4 00000000 SPRG5 00000000  SPRG6 00000000  SPRG7 00000000
> CSRR0 00000000 CSRR1 00000000 MCSRR0 00000000 MCSRR1 00000000
>  TCR 00000000   TSR 00000000    ESR 08000000   DEAR fff80000
>  PIR 00000000 DECAR 00000000   IVPR 00000000   EPCR 00000000
> MCSR 00000000 SPRG8 00000000    EPR 00000000
> MCAR 00000000  PID1 00000000   PID2 00000000    SVR 00000000
> MAS0 00000001  MAS1 80000000   MAS2 fff80000   MAS3 00000000
> MAS4 00000000  MAS6 00000000   MAS7 00000000    PID 00000000
> MMUCFG 00000000 TLB0CFG 04110200 TLB1CFG 101cc010
>
> Where the nip goes back down to 0, which is not what I expected. I can 
> see the first SRR0 register is set to my entry point of the elf. I do 
> see that the exception syndrome register and data exception syndrome 
> register are set as well. I don't really understand why I only see 32

Maybe try adding -d int that should show exceptions and explain how you 
get there, probably it goes to fff80000 but gets the same cannot access 
problem you get with gdb maybe because it's not mapped. If there's no real 
mode should there be an MMU mapping set up by the board code? It seems to 
add an initial mapping in mmubooke_create_initial_mapping() called from 
ppce500_cpu_reset() in hw/ppc/e500.c. Does that cover the area occupied by 
your firmware image or it has some assumptions about memory layout that 
does not hold with your case? (Like it expects things to get loaded with 
-kernel -initrd -dtb so that dtb is last but your elf image loads above 
that? Could be I'm all wrong, just guessing but maybe it gives you some 
ideas where to look.)

Regards,
BALATON Zoltan



reply via email to
[Prev in Thread] Current Thread [Next in Thread]