attempting to return from interrupt - failing

Technical discussion on the newly released and hard to find PS3.

Moderators: cheriff, emoon

Post Reply
nbauernf
Posts: 11
Joined: Tue Nov 18, 2008 11:35 am
Location: Carnegie Mellon University

attempting to return from interrupt - failing

Post by nbauernf »

Hey, So I'm trying to return from an interrupt. I have a fairly similar setup to the otheros demo, if that helps anyone help me =).

At this point all exception/interrupt vectors funnel into a generic exception handler (very very similar to the otheros demo in this respect). When I enable external interrupts (an MSR bit toggle), I'm definitely getting an exception at the 0x900 vector which is a decrementer interrupt. This is exactly what I would expect to have happen.

However, if I simply do this:
0x900:
rfid

I can't seem to properly recover from the interrupt. I'm not sure what's happening, but a few things have come to mind - but it's just so hard to find these answers and testing ideas takes a little bit of extra time due to the need to carry a usb key back and forth between my laptop and the ps3. (I can't wait to get far enough to do a network boot or something without needing to re-flash the rom over and over...)

One thing I wonder is: am I simply getting decrementer interrupts over and over and over again because on the rfid I renable them, but the decrementer register remains at 0? I can test this in two ways, which should both have the same result under this hypothesis (and I'm going to test it both ways, just not tonight yet). The first way is that I will simply flip the bit off in SRR1 (the saved old MSR value). The second way is to set the decrementer register to a higher value - to allow some other instructions to be executed - if that's the problem.

Then in x86 land it's basically common to tell the system that you've handled a timer interrupt - to let it know you're ready to process another one if it has one (probably true of other types of interrupts - but I did not deal with them). Does the powerpc specification talk about this in any way? I feel that this is likely not the problem due to the fact that I should be able to return from one without any other problems, but would never have a second occur.

Or, is there something completely different that I'm missing? (and btw, the otheros demo - at least v1.0 and mcload 1.0 for sure - do not enable interrupts.)

Thanks for the help! I hope someone out there has some insight for me! I'm not used to the powerpc architecture... at all. I always felt that the x86/x86-64 architecture was so natural, but it appears it was simply because I was always accidentally taught the idiosyncrasies of the common and cheap hardware that became so common.

Nate
nbauernf
Posts: 11
Joined: Tue Nov 18, 2008 11:35 am
Location: Carnegie Mellon University

Post by nbauernf »

fyi - turning back off the MSR_EE bit before rfid'ing definitely is recoverable. which suggests it's simply a problem of infinite calls to the handler.

so maybe I was just being silly not setting the decremeter register. - no time to do it tonight (gotta work in the morning).

Any other ideas would still be welcome!

By the way, is there an instruction analogous to pusha and popa in pcc-assembly? Or is there maybe a document/website I can be pointed to that explains how most OS's handle [recoverable] powerpc exceptions/interrupts? (and I know that the linux kernel is capable - but it can be hard to read through when you don't know what you're looking for)

Also, has anyone else put something together similar to (open source or not) the otheros demos?

Thanks again,
Nate
nbauernf
Posts: 11
Joined: Tue Nov 18, 2008 11:35 am
Location: Carnegie Mellon University

Post by nbauernf »

FYI: turns out to be the decremeter register always had the high bit on. Setting it to some other value did the trick.
User avatar
mc
Posts: 211
Joined: Wed Jan 12, 2005 7:32 am
Location: Linköping

Post by mc »

nbauernf wrote:By the way, is there an instruction analogous to pusha and popa in pcc-assembly?
Not really. There exist "store multiple" and "load multiple" instructions, but
they only handle the 32 least significant bits, and are generally slower than
storing the registers individually anyway. They are just there for backwards
compatibility. Simply store the registers you need stored, and load them
back when you are done. You can make a subroutine if you like, just
remember to store lr first. ;-)
Flying at a high speed
Having the courage
Getting over crisis
I rescue the people
Post Reply