I broke on "booke206_initial_map_tsize" and found the "dt_end" to be set to 0x0190_0000, which is far smaller than the u-boot elf entry point.
I looked in the E500 Core Reference Manual and it says that at reset the first entry of the tlb should be a size of 4k but the p2020 says 4G. It seems there are some inconsistencies between some of these models.
I believe this solves my issue. At least I know what's going wrong now and to some extent why.
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