Hey, guys.
I've been spare my little time on psp emu.
I was trying to booting emu up with IPL, and program stopped when encountered following strange instructions.
I found reference in binutils-psp, it's named as 'mfic' and 'mtic'.
Does anyone know about Allegrex specific opcode?
(0x70000024, 0x70000026)
And another question.
I found memory address while disasm process, It's 0xBC000000~0xBF000000
What is this for? some kind of DMA or something?
Any information would be appreciated.
Thanks.
xeph
Little help here - allegrex specific opcode and memory map
Re: Little help here - allegrex specific opcode and memory m
most likely "move from/to interrupt controller". what they *exactly* do, noone knows for sure. i think they are used to enable/disable certain kinds interruptsxeph wrote:Hey, guys.
I've been spare my little time on psp emu.
I was trying to booting emu up with IPL, and program stopped when encountered following strange instructions.
I found reference in binutils-psp, it's named as 'mfic' and 'mtic'.
Does anyone know about Allegrex specific opcode?
(0x70000024, 0x70000026)
this is ram which is used for the mips exception vectors.xeph wrote: And another question.
I found memory address while disasm process, It's 0xBC000000~0xBF000000
What is this for? some kind of DMA or something?
however, i'd forget the idea of running the ipl in an emu right now. maybe in a year or two when decent emus exist :)
Good luck with these two instructions... looks like very little information is available about them, and I wonder where they got the "mfic" and "mtic" names from?
These two instructions are not documented in Sony's official Allegrex user manual or instructions manual, and neither are they supported in the official toolchain (GCC to which Allegrex support has been added, almost the same as we have with the homebrew toolchain), its not in the instructions table in the official binutils source code. I can see two possibilities: either its an obsolete instruction that might have been replaced by another, and the IPL is still using some older code, or else Sony have a different compiler than the one they are giving to developpers, that support some secret instructions known only to them... (I lean more towards the obsolete instruction explaination though)
So, I don't think we know nothing more about them than what you found in the binutils source. If they are properly named, then it would be instructions similar to mtc0 and mfc0, and mtic would copy data from a CPU general register to some other unknown register set, and mfic would copy data from that unknown register set to a CPU general register.
When you wrote "0x70000024" and "0x70000026", is it only the opcode,
or the actual instruction with its register parameters?
Because then, the mfic one would attempt to write into the $zero register, which makes no sense....
If you ever find out more about these two instructions, let me know, as I too am trying to do an emulator capable of running the IPL and firmware.
I am doing this as a tool to help me analyse the communications between the IPL/firmware and the memory mapped devices. Its still extremely early in development (got my PSP only two weeks ago!) and can't run anything yet, but I suppose we could exchange some information as we both learn things!
As for the memory addresses, this is what I know so far about the readable memory ranges:
The 0xBC*, 0xBD* and 0xBE* addresses appear to be memory mapped devices, see the "hardware accesses.txt" file on groepaz's website (www.hitmen-console.org), it lists what modules access what memory areas.
I don't know yet for the 0xBC000000 to 0xBCEFFFFF range,.
0xBFC00000 up to I don't know where is the fixed address exception vector (the one used for resets and during boot time untill the firmware sets his own eception vector, at an address set in one fo the COP0 registers). According the PSPInside, there shoudl be at least 1 Meg of RAM at that address, and I suppose there is more than that since the IPL writes code at the 0xBFD0000 address. Perhaps even the whole "missing" 4 Megs: the PSP is supposed to have 32 megs of main RAM, yet there are 4 megs of kernel memory and 24 of user memory... where are the other 4 megs?
These two instructions are not documented in Sony's official Allegrex user manual or instructions manual, and neither are they supported in the official toolchain (GCC to which Allegrex support has been added, almost the same as we have with the homebrew toolchain), its not in the instructions table in the official binutils source code. I can see two possibilities: either its an obsolete instruction that might have been replaced by another, and the IPL is still using some older code, or else Sony have a different compiler than the one they are giving to developpers, that support some secret instructions known only to them... (I lean more towards the obsolete instruction explaination though)
So, I don't think we know nothing more about them than what you found in the binutils source. If they are properly named, then it would be instructions similar to mtc0 and mfc0, and mtic would copy data from a CPU general register to some other unknown register set, and mfic would copy data from that unknown register set to a CPU general register.
When you wrote "0x70000024" and "0x70000026", is it only the opcode,
or the actual instruction with its register parameters?
Because then, the mfic one would attempt to write into the $zero register, which makes no sense....
If you ever find out more about these two instructions, let me know, as I too am trying to do an emulator capable of running the IPL and firmware.
I am doing this as a tool to help me analyse the communications between the IPL/firmware and the memory mapped devices. Its still extremely early in development (got my PSP only two weeks ago!) and can't run anything yet, but I suppose we could exchange some information as we both learn things!
As for the memory addresses, this is what I know so far about the readable memory ranges:
The 0xBC*, 0xBD* and 0xBE* addresses appear to be memory mapped devices, see the "hardware accesses.txt" file on groepaz's website (www.hitmen-console.org), it lists what modules access what memory areas.
I don't know yet for the 0xBC000000 to 0xBCEFFFFF range,.
0xBFC00000 up to I don't know where is the fixed address exception vector (the one used for resets and during boot time untill the firmware sets his own eception vector, at an address set in one fo the COP0 registers). According the PSPInside, there shoudl be at least 1 Meg of RAM at that address, and I suppose there is more than that since the IPL writes code at the 0xBFD0000 address. Perhaps even the whole "missing" 4 Megs: the PSP is supposed to have 32 megs of main RAM, yet there are 4 megs of kernel memory and 24 of user memory... where are the other 4 megs?
I made up the names of mtic and mfic when I added them to the psp toolchain, they are supposed to mean move to and from the interrupt controller. The reason I know their purpose was to disable/enable interrupts is because if you reverse the functions which do that (i.e. sceKernelSuspendInterrupts) the functions are basically.
mfic $v0, $0 # Copy state of INTC to $v0 for return
mtic $0, $0 # Set INTC status to 0
and resume is
mtic $a0, $0 # Set previous state
The extra $0 is probably in the end is probably superfluous, I chose that instruction format cause I wasn't 100% sure there wasn't other INTC regs, in the end I don't think there is but hey :)
And I would vote for Sony having their own toolchain personally, adding new instructions to gcc would be trivial and by doing it like this devs can't accidently start adding stuff like this into their own code. Similarly I wuold be very interested to know if they document the debug controller instructions in the official literature.
Anyway case closed.
mfic $v0, $0 # Copy state of INTC to $v0 for return
mtic $0, $0 # Set INTC status to 0
and resume is
mtic $a0, $0 # Set previous state
The extra $0 is probably in the end is probably superfluous, I chose that instruction format cause I wasn't 100% sure there wasn't other INTC regs, in the end I don't think there is but hey :)
And I would vote for Sony having their own toolchain personally, adding new instructions to gcc would be trivial and by doing it like this devs can't accidently start adding stuff like this into their own code. Similarly I wuold be very interested to know if they document the debug controller instructions in the official literature.
Anyway case closed.
Thanks for the information.
What's bitrev? Does it means "Bit Reversal"?
And I have no idea about how it works.
Anyway, I've been run some tests(ran some opcodes, dump registers and sp area, etc)
Following opcodes are what i've found so far,
word: bits 32............................................................0
mftic.
0x70020024 0111 0000 0000 0010 0000 0000 0010 0100 (mfic $v0, $0)
0x70040026 0111 0000 0000 0100 0000 0000 0010 0110 (mtic $a0, $0)
0x7003003D 0111 0000 0000 0011 0000 0000 0011 1101 (Unknown)
0x7083003D 0111 0000 1000 0011 0000 0000 0011 1101
0x7002083D 0111 0000 0000 0010 0000 1000 0011 1101
Here's interest thing.
When i tested "mtic $v0, $0" and $v0 is 0x044F5F53, app stopped, psp turned off itself
bitrev.
0x7C042420 (bitrev, in toolchain, unknown, Reversal?)
0x7C031C20 (same as above)
0x7C061620 0111 1100 0000 0110 0001 0110 0010 0000 (same as above)
0x7C82F000 0111 1100 1000 0010 1111 0000 0000 0000 (unknown)
0x7D4D0040 0111 1101 0100 1101 0000 0000 0100 0000 (unknown)
...
0x7F11F884 0111 1111 0001 0001 1111 1000 1000 0100 (unknown)
What's bitrev? Does it means "Bit Reversal"?
And I have no idea about how it works.
Anyway, I've been run some tests(ran some opcodes, dump registers and sp area, etc)
Following opcodes are what i've found so far,
word: bits 32............................................................0
mftic.
0x70020024 0111 0000 0000 0010 0000 0000 0010 0100 (mfic $v0, $0)
0x70040026 0111 0000 0000 0100 0000 0000 0010 0110 (mtic $a0, $0)
0x7003003D 0111 0000 0000 0011 0000 0000 0011 1101 (Unknown)
0x7083003D 0111 0000 1000 0011 0000 0000 0011 1101
0x7002083D 0111 0000 0000 0010 0000 1000 0011 1101
Here's interest thing.
When i tested "mtic $v0, $0" and $v0 is 0x044F5F53, app stopped, psp turned off itself
bitrev.
0x7C042420 (bitrev, in toolchain, unknown, Reversal?)
0x7C031C20 (same as above)
0x7C061620 0111 1100 0000 0110 0001 0110 0010 0000 (same as above)
0x7C82F000 0111 1100 1000 0010 1111 0000 0000 0000 (unknown)
0x7D4D0040 0111 1101 0100 1101 0000 0000 0100 0000 (unknown)
...
0x7F11F884 0111 1111 0001 0001 1111 1000 1000 0100 (unknown)
bitrev: reverse the bits inside the word, so that bit 0 becomes 31, and bit 31 becomes bit 0, bit 1 becomes 30 and 30 becomes 1, and so on
7000003D: mfdr
7080003D: mtdr
They are in the toolchain (homebrew) I don't know what they are, again move from/to registers but I don't know which ones. These are no more documented than the mfic/mtic instructions in son'ys documents, but they are supported by their toolchain I think. I suppose Tyranid might know.
Tyranid: thanks for the info :) now I wont be stuck when I stumble upon these instructions! Maybe you're right about them having their own toolchain. What you say makes sense.
The debug controller instructions you are talking about, you mean the dbreak, dret, mfdr and mtdr instructions? No they aren't documented. No instruction in the SPECIAL2 group are (higher 6 bits = 011100). I think seeing them in sony's binutils though (not sure, I don't have it here at home, only at work). Whatever you know about these would help: I was wondering what they were for. Debug controller... what does this thing do?
From the name only, that sounds like something that should be in the devkit... do they seem to have any effect on a retail PSP?
7000003D: mfdr
7080003D: mtdr
They are in the toolchain (homebrew) I don't know what they are, again move from/to registers but I don't know which ones. These are no more documented than the mfic/mtic instructions in son'ys documents, but they are supported by their toolchain I think. I suppose Tyranid might know.
Tyranid: thanks for the info :) now I wont be stuck when I stumble upon these instructions! Maybe you're right about them having their own toolchain. What you say makes sense.
The debug controller instructions you are talking about, you mean the dbreak, dret, mfdr and mtdr instructions? No they aren't documented. No instruction in the SPECIAL2 group are (higher 6 bits = 011100). I think seeing them in sony's binutils though (not sure, I don't have it here at home, only at work). Whatever you know about these would help: I was wondering what they were for. Debug controller... what does this thing do?
From the name only, that sounds like something that should be in the devkit... do they seem to have any effect on a retail PSP?
korskarn, yah stuff like dbreak etc is what I mean by the debug controller. They seem to come from some MIPSIV processors, and if you look through exception manager on 1.5 (they aren't there on 1.0 for what ever reason) they seem to make sense. Binutils has them in already, all I did to enable them was say they are available on the allegrex target. A nice friend pointed them out to me at one point :)
I think the idea is you install a debug handler somewhere (Think it might have been 0xBD000000 or so), then call dbreak which switches the processor into debug mode from where you can enable hardware breakpoints etc. Unfortunately it doesn't actually seem to work on a retail unit unless there is something special I need to enable like a special bit flag in cop0 somewhere. Would be nice if it did work, but perhaps Sony removed whatever is needed somewhere down the line. They don't crash the psp though, they seem to act as NOPs when encountered.
A document which describes them is http://www.necelam.com/docs/files/1375_V2.pdf which is an NEC MIPS document.
I think the idea is you install a debug handler somewhere (Think it might have been 0xBD000000 or so), then call dbreak which switches the processor into debug mode from where you can enable hardware breakpoints etc. Unfortunately it doesn't actually seem to work on a retail unit unless there is something special I need to enable like a special bit flag in cop0 somewhere. Would be nice if it did work, but perhaps Sony removed whatever is needed somewhere down the line. They don't crash the psp though, they seem to act as NOPs when encountered.
A document which describes them is http://www.necelam.com/docs/files/1375_V2.pdf which is an NEC MIPS document.
I'm finally stuck.
The problem is AES Crypto.
I've managed to mount flash0, then IPL runs, IPL Loaded encrypted file ("/kd/pspcnf_tbl.txt")
then stuck on semaphore which is in IPL.
I have no idea about solve this problem.
The problem is AES Crypto.
I've managed to mount flash0, then IPL runs, IPL Loaded encrypted file ("/kd/pspcnf_tbl.txt")
then stuck on semaphore which is in IPL.
Code: Select all
RAM:884013C4 loc_884013C4: # CODE XREF: semaphore+7Cj
RAM:884013C4 lw $v0, 0xBDE0001C
RAM:884013CC andi $v0, 0x33
RAM:884013D0 beqz $v0, loc_884013C4
RAM:884013D4 nopYou're probably not going to be able to get around this. Some limited info about the crypto hw is here (see memlmd.c). If your goal is to just be able to trace IPL execution, you could have your PC send the buffers to a real PSP and have it do the crypto for you :)xeph wrote:I'm finally stuck.
The problem is AES Crypto.
bitrev rd, rtxeph wrote: I just wondering about the rest of bits. What they do for? Register? Imm?
I think they're too much for registers.
Any ideas?
Bits 0-10 are always 1010010000 (left = most significant)
Bits 11-15 are the rs register (where the result is stored)
Bits 16-20 are the rt register
Bits 21-25 are always 00000
Bits 26-31 are always 011111 (left = most significant)
TyRaNiD: I suppose the debug instructions would have some effect only on a devkit, which can be connected to a PC and work with a debugger.
xeph: yes decryption is done by some hardware. If you want to run the IPL / firmware on an emu, you will have to pre-decrypt it via some tool running on the PSP (see the PRX decrypt sample in the SDK). Since the firmware might not allow to load unencrypted kernel modules, you may have to modify the module that does this check. Unless someone figures out the decryption algorithm...
urchin: good question, I too have seen this word in the reversed engineered memlmd.c, but I have no idea what that is.