Re: Cannot Access Memory

[BALATON Zoltan]

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