Low-level interrupt control

mik · Post by **mik** » Tue Apr 14, 2009 7:36 am

Hi,
I'm experimenting with interrupts using Jackson's ucLinux port and I'm asking me how did you find out that the hardware registers 0xbc300000 and 0xbc300010 are used to mask the interrupts (I'm referring to http://forums.ps2dev.org/viewtopic.php? ... c&start=90, crazyc's post)?

I'm trying to enable just UART1, which, I suppose, is the interrupt triggered by the joypad. I did some tests and got the following:

Code: Select all

Test on 0xbc300000

0x80000000		Ok
0x40000000		Stopped at boot
0x20000000		Ok
0x10000000		Ok
	
0x08000000		Ok
0x04000000		Ok
0x02000000		Ok
0x01000000		Ok
		
0x00800000		Stopped at boot, worked the second boot
0x00400000		Switched psp off, worked the second boot &#40;strange sounds from umd drive&#41;
0x00200000		Ok
0x00100000		Ok
		
0x00080000		Boot ok, but console unresponsive, 2nd try stopped at boot, 3rd try stopped at boot, 4th try 
						&#40;first accessing memory stick&#41; boot ok but console unresponsive
0x00040000		Ok
0x00020000		Ok
0x00010000		Ok
		
0x00008000		Ok
0x00004000		Ok
0x00002000		Ok
0x00001000		Ok
		
0x00000800		Ok
0x00000400		Ok
0x00000200		Ok
0x00000100		Ok
		
0x00000080		Stop after loading mem stick driver, led remains red; same after 2nd try
0x00000040		Ok
0x00000020		Stopped at boot, same at second try
0x00000010		Unknown IRQ&#58; pend=00000400 st0=00000010 st1=00000000 &#40;after fb driver loaded&#41;, same in 2nd try
		
0x00000008		Ok
0x00000004		Ok
0x00000002		Ok
0x00000001		Ok

Basically, just enabled 1 int at a time and looked how far the kernel boot process proceeds. Ok, this is kinda brute force and stupid, so if you could shed some light on this I'd be glad...
Thx

J.F. · Post by **J.F.** » Tue Apr 14, 2009 8:48 am

The info on the int regs was derived from looking at the PSP's regular int handler code. If you're at all familiar with low-level coding of things like int handlers, it was fairly obvious what the registers were.

mik · Post by **mik** » Tue Apr 14, 2009 3:55 pm

I am unfamiliar with it and also pretty curious, thats why I'm asking :-)
You mean that it can be derived by looking only at the static assembly in sceKernelSuspendIntr for example or would it be needed to run pspinside on a 1.5 firmware?
Thx

J.F. · Post by **J.F.** » Tue Apr 14, 2009 4:49 pm

Just look over this. It has all the info for that needed... if you're ready for such low-level tasks. ;)

http://hitmen.c02.at/files/yapspd/psp_d ... .html#sec9

mik · Post by **mik** » Tue Apr 14, 2009 5:23 pm

J.F. wrote:Just look over this. It has all the info for that needed... if you're ready for such low-level tasks. ;)

Well, I have to start somewhere :)

http://hitmen.c02.at/files/yapspd/psp_d ... .html#sec9

Jap, thanks, I knew the doc and I need some time to digest it ;)
Just to be sure, the interrupt handler code in yapspd is derived from (parts of) the assembly dump in interruptman.prx? I guess this needed some patience to come up with...
Although it looks quite ambitious, I guess I can learn a lot by looking at both sources (asm and pseudo).
Thx

J.F. · Post by **J.F.** » Wed Apr 15, 2009 7:44 am

Things like int handlers are the more complex parts of any kernel. It helps to have previous experience with such things on other computers. Many programmers start with 8 bit systems where ints are more simple, then move on to 16 bit systems which may have a simple controller, then work up to the full-blown int controllers found in modern PCs. Once you've worked on all that, the PSP int controller isn't too bad.

mik · Post by **mik** » Wed Apr 15, 2009 4:44 pm

J.F. wrote:Things like int handlers are the more complex parts of any kernel. It helps to have previous experience with such things on other computers. Many programmers start with 8 bit systems where ints are more simple, then move on to 16 bit systems which may have a simple controller, then work up to the full-blown int controllers found in modern PCs. Once you've worked on all that, the PSP int controller isn't too bad.

Yap, recently I was studying the initialization parts of the linux kernel by looking at the code and its quite difficult to keep the overview (lxr helps a lot). Although I have a CS background, hardware is really not my field, so I have a hard time to figure out all the details. I'm tyring to fill that gap ("See Mips run" has a chapter about interrupt handling), but probably I need some additional info. If you have some pointers (e.g. books) where I could start I'd appreciate it (I know google, but without the right (and specific) keywords you get flooded with information and to find and pick the relevant one is sometimes impossible...)
Thx

J.F. · Post by **J.F.** » Thu Apr 16, 2009 5:38 am

I learned by doing... the only books I read were language specifications. That's half the problem - I'm constantly pestered by kids asking how they can acquire my skills... in a month. They aren't happy when I tell them to spend 20 years programming. :D

mik · Post by **mik** » Thu Apr 16, 2009 6:58 am

Well, maybe because its not a completely valid argument :-P
Today, due to the increasing complexity of technology, it is more difficult to get your feet on the ground than it was 20 years ago. On the other hand, today it's probably easier (and faster) to find the needed information, but the time and effort required to digest it, remained stable.

Back to the topic...
Since someone wise did already the hard job of reconstructing the data structures and logic flow of the int handler code, I thought I could learn from it by both looking at the assembly and at the pseudo code in the yapspd. I'm not only interested how this specific interrupt handler code works, but I'd like to acquire the knowledge to solve (in some distant future) such puzzles on my own.
Quick question: from which firmware is the code in yapspd reconstructed? The memory addresses don't match to the assembly I'm looking at (from owf 1.50).
Eg:

default_irq_handler(void) /* 88020F74 (interruptman:0x2274) */

is, I *suppose*

; Subroutine sub_00002224 - Address 0x00002224
sub_00002224:

in the assembly (I derived that from the context of both representations, but it would be much easier to understand whats going on, if I could compare and navigate by the addresses).
Thx

jean · Post by **jean** » Thu Apr 16, 2009 10:39 pm

Well, maybe because its not a completely valid argument :-P

It is. This month it is 21 years since my first listing (written on an Olivetti PC128s - a BBC Acorn italian replica). Since then i read many books, but the most i've learned, it's taken from experience. Today, children want all and immediately, while it took me a year to figure out exactly how VGA framebuffer was organized for resolutions upper to 320x200x8. And I did it WITHOUT Internet - only some obscure and inaccurate description from a geek like me downloaded in DAYS from a BBS. No sites, no forums, no guides, no nothing. Only me, my PC and a friend with the same interests.
...just to give my two cents...

mik · Post by **mik** » Thu Apr 16, 2009 11:17 pm

Only me, my PC and a friend with the same interests.

It's incredibly fruitful if you can exchange ideas, I experience that everyday at work... but unfortunately nobody in my near surroundings is interested in coding for the PSP. So I have to rely on the exchange within this forum.
I'm currently reading it from behind, nice to see the evolution. Nevertheless, I didn't yet find an answer to the question I've posed before...

J.F. · Post by **J.F.** » Fri Apr 17, 2009 6:16 am

If you can't make do with the uclinux port code, the thread mentioned above, and the yet another page linked above, you'll have to spell out what you're trying to do more clearly and succinctly.

BTW, in the yet another doc, code mentioned that isn't part of the listing isn't important - ignore calls to it. The part of the code someone would be interested in is all there.

mik · Post by **mik** » Fri Apr 17, 2009 5:14 pm

Ok, sorry if my request was not clear, I'll try to formulate it more explicitly.

I'd like to follow/read the code in http://hitmen.c02.at/files/yapspd/psp_d ... l#sec9.5.2 and trace it back to the assembly of firmware 1.5 I have.

I don't do this to understand the functionality of the code (for now), but to:
- retrain/refresh my rusty mips ;)
- learn how people do actually reverse engineering (I know it's not trivial, this example shows it...) and come up with the code as shown in yapspd

Simple as that... I know, I may trivialize, but this is due too my inexperience on this topic.

Edit: You may ask: "All this for using the interrupt controller? That's not needed!"
I know, but the journey is the goal ;) Gather experience, dig deep and discover what's behind the curtain.

J.F. · Post by **J.F.** » Fri Apr 17, 2009 8:20 pm

Well, the first step is to get the MIPS manuals and learn MIPS assembly. Otherwise it's hard to tell anything for the code. :D

mik · Post by **mik** » Fri Apr 17, 2009 8:51 pm

J.F. wrote:Well, the first step is to get the MIPS manuals and learn MIPS assembly. Otherwise it's hard to tell anything for the code. :D

Been there, done that. The next step is to learn by doing, as you formulated earlier.
So, (I'm asking this now for the third time :) from which version of the firmware is the code in http://hitmen.c02.at/files/yapspd/psp_d ... l#sec9.5.2 (section 9.5.2.2) derived from?
Thx