Re: Cannot Access Memory

[BALATON Zoltan]

On Tue, 5 Oct 2021, Jesse Millwood wrote:
> 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.

Tho others after invalid instruction don't matter as that's just a result 
of trying to execute the non-existent handler for the exception you get 
first. Things have gone astray after that so that does not matter any 
more, the problem is before that. I'd expect that to result in program 
exception for illegal instruction at 0, not sure how you get 0x60 instead 
but it's already wrong that it can't get the first instruction so the rest 
does not really matter.

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

I don't know. Maybe try to print the dt_end in 
booke206_initial_map_tsize() which it says is the top address it's trying 
to map. If this is less than the end of your executable then that's the 
problem. Not sure how this should work. Also your image may expect a 
different machine than what's emulated by the e500 in QEMU so maybe it 
would work differently on real machine. It may help to know how it's 
working on real machine then you can compare that with what happens on 
QEMU. You may need to implement a model of that machine to get a firmware 
image working as the generic e500 machine may not be what it expects to 
run on.

Other than -d flags you can also look at trace-events file in the 
directory where the source for the part you're interested in is and can 
enable those with for example -rrace enable="ppc_excp*" to get more info. 
Or sometimes there are debug defines at the beginning of some files that 
one can enable.

Regards,
BALATON Zoltan