irq 3 must be enabled or psp will shutdown after 10 seconds?

[chrismulhearn]

Most of my info here came from the "mips r4000 microprocessor user's manual", if anyone is interested.

CP0 has a status register $12.

After loading up homebrew on 1.5 firmware, the cp0 status register is

CP0 $12 = 0x20008601

Bit 0 enables/disables all interrupts. If you disable all interrupts,

CP0 $12 = 0x20008600

the PSP will only continue to operate for about 10 more seconds before powering down completely.

The entire second byte (the 0x86) makes up the 8 interrupt masks. It looks like you can shut all interrupts off except the 3rd one,(which is an external irq) and the psp continues to run. That corresponds with

CP0 $12 = 0x20000401

but change that 4 to a 0 and poof, shuts down after like 10 seconds. Think there is some sort of watchdog? For some reason the cpu needs to handle this interrupt.

I guess if you had a disassembly of the firmware, you could see what the service routine for that does.. I'm pretty sure thats not legal though?

[groepaz]

interisting.... yes there is a watchdog (obviously). and no, why would it be illegal to disassemble the firmware? how do you think all the currently known info was gathered? :)

[chrismulhearn]

If you take a look through some of the court rulings on EFF.org (for example, the Sega and Accolade one) theres definitely some uncertainty over code disassembly, for example, in that Sega case, i *think* they claim that x-raying a ROM *is* a legal way to disassemble (For the purpose of interoperability only) , but downloading the ROM directly produces an unauthorized copy.

Furthermore, Sony could claim that this watchdog is just one more "protection" against copyright violation. (Granted, its real purpose is to make sure that the CPU is alive, but they could CLAIM that it was also a way to make it so unauthorized code would shut down after 10 seconds).

So, I'd be disassembling that firmware in order to learn how to talk to the watchdog, for the purpose of interoperability, so that my code could function even when I remove all resident PSP firmware. But Sony could claim that I'm disassembling that firmware in order to "circumvent" the "protection" that the watchdog afforded them, and thats not legal, as far as I know.

Anyways, do you know how the watchdog works or what? :) What do I need to do in a service routine for that interrupt in order to stop the PSP from rebooting?

[groepaz]

its unknown so far...else it would be in my doc :)

[TyRaNiD]

I traced the watchdog to the one of the power sub interrupts, but that was as far as I could be bothered tracing as in the end I had no use for it. Hope you find it though, could have many useful aspects ;)

[chrismulhearn]

Groepaz: In your "memory map" section of the PSP hardware document, you list a lot of virtual address segments. This seems to imply that CP0 does indeed have paging capabilities?

Do user-mode applications actually access memory/io in terms of the virtual memory map you specified?

[groepaz]

In your "memory map" section of the PSP hardware document, you list a lot of virtual address segments. This seems to imply that CP0 does indeed have paging capabilities?

no. the segments are unrelated to TLB, read up on the mips arch :=)

Do user-mode applications actually access memory/io in terms of the virtual memory map you specified?

user programs run in the KU segment(s), they can not access any other segments (nor i/o)

[chrismulhearn]

Ahah, correct again groepaz.

Hey is there a revision-2 of your hardware doc coming out soon?

[chrismulhearn]

I'm curious about this memory map in the PSP hardware doc, section 7.1

First off, is the memory map is always the same regardless of operating mode? But certain segments are inaccessible to User mode programs?

Next, the map seems to imply that all physical addresses beyond 0x1FFF,FFFF are unreachable. Lets look at the first entry in the table.

Virtual address = 0x0 . . . . . . .
msb = 0 0 0
Physical address= 0x0 . . . . . . .
size = 1024MB

So, in order to be accessing this segment, the most significant top 3 bits need to be 0 0 0?

That means virtual addresses above 0x1FFF,FFFF would be in a different segment than addresses equal to or below it. For example, 0x2000,0000 would have an msb (top 3 bits) of 0 0 1. *But there is no description of a segment that is selected with that msb.*

Therefore, if this is the means by which segments are selected, there is no segment for virtual addresses ranging 0x2000,0000 - 0x3fff,ffff, which corresponds to msb=001. (As soon as you go above this, to 0x4000,0000, you are in a new segment selected w/ msb=010, and that segment *does* exist)

Yet the document claims that this first segment, the one I quoted up top there, starting at 0x0000,0000 is "1024 mb", which implies that it should be able to access all the way to 0x3fff,ffff.

I'm confused!

Also, do you know if there are ways to modify the segmentation? I know X86 has a very configurable segmentation unit (as WELL as paging). The r4000 segmentation seems completely static. But might this Allegrex have a more configurable segmentation unit than the typical r4000, in order to make up for the lack of a TLB (paging unit)?

-Chris

[jtwald]

is there a list of the psp irqs and their standard assignments out there?

[johnmph]

Most of my info here came from the "mips r4000 microprocessor user's manual", if anyone is interested.

CP0 has a status register $12.

After loading up homebrew on 1.5 firmware, the cp0 status register is

CP0 $12 = 0x20008601

Bit 0 enables/disables all interrupts. If you disable all interrupts,

CP0 $12 = 0x20008600

the PSP will only continue to operate for about 10 more seconds before powering down completely.

The entire second byte (the 0x86) makes up the 8 interrupt masks. It looks like you can shut all interrupts off except the 3rd one,(which is an external irq) and the psp continues to run. That corresponds with

CP0 $12 = 0x20000401

but change that 4 to a 0 and poof, shuts down after like 10 seconds. Think there is some sort of watchdog? For some reason the cpu needs to handle this interrupt.

I guess if you had a disassembly of the firmware, you could see what the service routine for that does.. I'm pretty sure thats not legal though?

In sceKernelReboot function, the status register is anded with 0xFFFFFFE0 value :

1d0: 40066000 cop0 a2,zero,24576 ? MFC0 a2(cpu), 12(cop0) ?<- a2 = status (system status)
1d4: 2402ffe0 addiu v0,zero,-32 <- v0 = 0xFFFFFFE0 (-32)
1d8: 00c22024 and a0,a2,v0 <- a0 = a2 & v0
1dc: 40846000 cop0 a0,a0,24576 ? MTC0 a0(cpu), 12(cop0) ? <- status (system status) = a0

[chrismulhearn]

How does that relate? I dont follow.

What is that code snippet from? When does it get executed? On startup? Or on shutdown?

All thats doing is clearing the global interrupt enable (disabling all interrupts) and.. lets see... setting CPU to 32-bit mode.. Setting operating mode to Kernel mode...

Nothin' to do with this stinkin watchdog interrupt! :)

[johnmph]

How does that relate? I dont follow.

What is that code snippet from? When does it get executed? On startup? Or on shutdown?

All thats doing is clearing the global interrupt enable (disabling all interrupts) and.. lets see... setting CPU to 32-bit mode.. Setting operating mode to Kernel mode...

Nothin' to do with this stinkin watchdog interrupt! :)

Taken from sceReboot.prx (sceKernelReboot function) of 1.50 firmware and disassembled with asmdump.

You say that if you disable all interrupts the psp shutdowns after +- 10 seconds but all reboot functions (sceKernelLoadExec, sceKernelExitGame, ...) disables all interrupts without stopping the psp.

[chrismulhearn]

uhhhh, do they leave it off for 10 seconds?

(Thats a rhetorical question, i know you don't know the answer.)

You almost always disable all interrupts on bootup, because you haven't installed + setup your interrupt handlers + their underlying support mechanisms.