forums.ps2dev.org

Out of curiosity on the ps2 ee kernel I did a dump of the system memory and dissassembled it with a view to get a better idea of it's inner workings. So i wrote a loop thats dumps from 0x80000000 to a file on host: (i got about 4 megs). This ran this through ee-objdump (stopped early, the .s was 11 Megs, all the end were nops anyway)
Now i know my data isn't corrupted because I can see at the positions of the v_tlb_refil and v_common vectors coherent snippets of code to read the coop0 cause register, mask it off and jump somewhere based on that. Also at the v_counter and v_debug vectors are jumps so some other nearby mem address.
So far so good.

The problem comes when follwowing one of these jumps. for instance,
at the v_counter interrupt: so i follow this to: Am i missing something here, or are we trying to write 16bytes to 0xFFFFE0?
perhaps the dissassembly is off, later on the same mem location is read back and it is sourrounded by legit-looking code. So whats doing with this? If i treat the -32 as a valid mem address, things make sense, but i'm not sure it is??
Any ideas?
thanks.
- cheriff

We've never been able to figure that address out. My guess is it's a custom TLB entry the kernel provides.

BTW, it's a lot easier to dump your BIOS and pull out the KERNEL file using one of the romfs tools.

thanks mrbrown, i suspected as much.
OK, yeah, i had a look at the tlb entries, and there does seem to be one that maps from some of the top end of the virtual address space.
not entirely sure why you'd do this, but thats probably just me. I guess something like being able to switch the detination of all these reads / writes with one tlb update.. i dunno.

Anyway. i got back to my dis-assembly and very quickly came up across other funky stuff:

following the common vector (I want to get to the syscalls' code, eventually):

• 1. save off k0 to 0x80012a38
  2. t9 = cause reg mask'd by 0b1111100 (in the case of a syscall, t9 is now 0x20)
  3. then jump to 0x80010000 + 0x2a00 + 20

which turns out to be:whats going on with this, doesn't look like a handling routine, but i know i'm missing something, only thing is... what?
am i wrong in assuming that lui zeros out the lower 16 bits when loading the upper?

ta.
- cheriff

no you are correct, lui will zero out bits 0..15

mrbrown wrote:We've never been able to figure that address out. My guess is it's a custom TLB entry the kernel provides.

BTW, it's a lot easier to dump your BIOS and pull out the KERNEL file using one of the romfs tools.

-32($zero) is mapped to 0x80080000-32 = 0x8007FFE0.

Actually, it was pretty easy to figure this out.