forums.ps2dev.org

[cheriff]

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:

[mrbrown]

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.
_________________
"He was warned..."

[cheriff]

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:

[blackdroid]

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

[misfire]