uClinux on the PSP

[hlide]

OK so I wrote code that assumed both caches were 64K. Now, I noticed that as soon as I started running kernel + programs in a cached memory segment (instead of 0xAxxx,xxxx where _everything_ was uncached) when I invoked programs from the shell, weird things would happen every now and then, programs would crash... the first time i ran them. But then the second time they'd work. Even though they were the exact same program being loaded into the exact same memory location over and over.

Naturally I thought "well its because I'm not flushing the caches, when I load the user program into memory, the kernel isn't flushing the icache, so who knows what could be lingering in there."

So I wrote my cache flushing functions, and noticed that the problem was still there. But I also noticed that when the linux kernel would load an executable (and by "load" i mean copy off of the ramdisk into a different spot it allocated for it) it would ONLY flush the instruction cache. But if we dont flush the data cache, then some program code could still be sitting in the data cache, and the instruction cache would come along and scoop old program code out of RAM...

so I thought, "maybe I'll just explicity flush the data cache first, any time anyone flushes the instruction cache." And that solved the problem.

Weird huh? Maybe the kernel is assuming theres some "coherency" between those two caches [because in this case, there definitely isn't.] ?

did you activate or desactivate some features ? you need to provide to kernel some informations about allegrex architecture :

has_cpu_icache : 16KB
has_cpu_dcache : 16KB
has_cpu_no_scache
etc.

[chrismulhearn]

I left a little note to myself to make sure I checked exactly that. I believe the flags you are talking about are ultimately there for the implementation of the cache management functions. Since I wrote all new cache flushing functions, I don't *believe* there is any need for flags like has_cpu_icache to have a sane meaning.

But you may be right, I'll look into that, thanks for the tip [and all the help!!!]

In any case, FYI it seems to be working [and about 10 times faster than it was without the cache!] so I'm moving on to write a framebuffer device driver. The driver will rely on whatever video geometry was setup before jumping into the kernel... good enough for me!

[crazyc]

• - 18, 1C and 1D are like a CREATE DIRTY EXCLUSIVE operation
  - 19 is a HIT INVALIDATE operation
  - 1A is a HIT WRITEBACK operation
  - 1B is a HIT WRITEBACK AND INVALIDATE operation
  - 1E and 1F are a FILL operation because of the first test

A function in the ME kernel in firmware 3.02 uses 0x16 and 0x1c. It applies 0x1c to a location on the stack then uses that memory and that just above it frequently. It then uses 0x16 to the same address before it returns. So 0x1c as CREATE DIRTY EXCLUSIVE or LOCK and 0x16 as UNLOCK seems to make sense. It also uses 0xa and 0x1e but

[hlide]

• - 18, 1C and 1D are like a CREATE DIRTY EXCLUSIVE operation
  - 19 is a HIT INVALIDATE operation
  - 1A is a HIT WRITEBACK operation
  - 1B is a HIT WRITEBACK AND INVALIDATE operation
  - 1E and 1F are a FILL operation because of the first test

A function in the ME kernel in firmware 3.02 uses 0x16 and 0x1c. It applies 0x1c to a location on the stack then uses that memory and that just above it frequently. It then uses 0x16 to the same address before it returns. So 0x1c as CREATE DIRTY EXCLUSIVE or LOCK and 0x16 as UNLOCK seems to make sense. It also uses 0xa and 0x1e but

0x16 : INDEX UNLOCK ? because i would be tempted to think a cache operation between 10 and 17 is relative to INDEX.

0x1C seems to be used as a CREATE DIRTY EXCLUSIVE AND LOCK for the very reason the allocated values in stack don't need to be filled. So we can consider they're using a cache line as a fast memory to make something temporary.

0x0A : icache, address. We need another code to test the range of 0x08 until 0x0F.

0x1E : dcache, address. FILL. Prefetch data ?

[crazyc]

It also uses 0xa and 0x1e but

Oops, I meant to say "but it isn't clear what they do except that they both refer to addresses."

0x16 : INDEX UNLOCK ? because i would be tempted to think a cache operation between 10 and 17 is relative to INDEX.

Code: Select all

cache   0x16, 0(sp) 
addiu   t7, sp, 0x40
cache   0x16, 0(t7)    

This is from the disassembly. Although consistency would imply 0x16 refers to an index, sp is probably not an index here. Especially since the set up look like this:

Code: Select all

cache   0x1C, 0(sp)
addiu   v1, sp, 0x40
cache   0x1C, 0(v1)

[futaris]

Do let us know when you've put the framebuffer and SDL stuff up. Also, are there plans for a svn or cvs server or project on sourceforge or similar?

[chrismulhearn]

Will do.

Does anyone know how to poll the state of the keypad keys directly?

I realized that "SDL" (and presumably, a lot of other graphics/gui toolkits that have been ported to use the Framebuffer) requires a "Virtual console" for keyboard IO. My initial port of SDL just commented out all the keyboard stuff, but I decided I needed to look into why I wasn't having any virtual console device drivers attached to /dev/tty0.

Anyways, I still don't claim to understand the entire plumbing behind TTYs, Consoles, etc, but now I have virtual console support on /dev/tty0 and an almost-working framebuffer console driver. Right now all the fonts are being rendered as just all black though.

Within the week I hope to have framebuffer console setup, and input via two mechanisms, one, a slow annoying process of hitting the keypad keys multiple times per key, and the other, just treating input on /dev/ttyS0 as keystrokes. so a terminal connected to the headphone serial jack will be something of a "keyboard", though stuff like key _state_ (held down, etc) will have to be emulated and will most likely be crappy. And I think i just decided not to bother with that for now.

Anyways the major goal is to make this useful for people who don't have the serial port hardware, and assuming I get the framebuffer fonts working, and figure out how to directly poll the PSP keys, then this should be a fully functional linux handheld (with SDL support!) in a matter of days.

I do plan on setting up CVS. I'll probably make the userland CVS accessible to anyone who asks, and the kernel CVS I'll make accessible to anyone who emails me a useful patch to the kernel.

I'm also going to put up a wiki. But first, framebuffer console!

[hlide]

Does anyone know how to poll the state of the keypad keys directly?

it seems keypad is queried through an SPI driver. But I don't know all the details.

[chrismulhearn]

That stinks... Well I guess I can use the hokey remote control as a "keyboard" for now, but then I lose my serial console.

[J.F.]

You know, you could probably use an IR keyboard with this fairly easily. Chris wrote some code for using UART5 (in this thread) that could be used for receiving keycodes.

I have a Palm 3169ww IR keyboard that works with the IrDAmon test program. I should probably try Chris' code to check how that works. Given directly accessing UART5 allows you to handle IR keyboards, support for some of the more common ones should probably be in your port.

[chrismulhearn]

sure, utimately someone will definitely write a driver for that.

But right now the point is trying to get some base functionality for people who haven't aquired any nifty hardware like what you describe. Those who are willing to come up w/ extra hardware to use this thing can, for now, just use a serial port console, so the PDA keyboard doesn't actually accomplish anything for me at the moment.

Furthermore, a common use for this will probably be just booting into games written in SDL or GTK. It would be silly to require those people to buy additional hardware.

I will definitely write a driver for that when I have the time though, or maybe someone else will!! Thanks

EDIT: I changed my mind, I'm getting one of those keyboards. :) Then I wont feel in a mad rush to get the keypad working.

-Chris

[J.F.]

sure, utimately someone will definitely write a driver for that.

But right now the point is trying to get some base functionality for people who haven't aquired any nifty hardware like what you describe. Those who are willing to come up w/ extra hardware to use this thing can, for now, just use a serial port console, so the PDA keyboard doesn't actually accomplish anything for me at the moment.

Furthermore, a common use for this will probably be just booting into games written in SDL or GTK. It would be silly to require those people to buy additional hardware.

I will definitely write a driver for that when I have the time though, or maybe someone else will!! Thanks

EDIT: I changed my mind, I'm getting one of those keyboards. :) Then I wont feel in a mad rush to get the keypad working.

-Chris

:)

It's a really slick keyboard, and definitely easier than making your own serial port cable. I know most folks won't have any need for one, but if someone is going to be doing work in or on uClinux for the PSP, it would probably be in their best interest to have an IR keyboard of some kind.

[hagisbasheruk]

I have been following this post since i first heard of the port,i am glad you are getting an IR keyboard

[chrismulhearn]

Wow, this is slick.

The PSP can sit right on their little cradle, and the IR transmitter flips up to be right over the PSP's IR iface.

this is totally awesome.

I dont suppose anyone knows the addresses for the IR uart?

Also, i wonder if it is enabled by default in the system config area. Well, maybe if I can't figure out how to do that without the SDK, I can just have the bootloader enable IR before jumping into linux and killing the psp os.

[J.F.]

Wow, this is slick.

The PSP can sit right on their little cradle, and the IR transmitter flips up to be right over the PSP's IR iface.

this is totally awesome.

Yep, and the IR on it is actually strong enough that the PSP (mine at least) can pick up the keyboard from a foot away. It just has to be point in somewhat the right direction. :)

The scan codes for the 3169ww are pretty simple, too. It just sends six bytes for each key up or key down.

Key down:
0xFF 0xC0 key /key alt-key 0xC1

Key up:
0xFF 0xC0 (key + 0x80) /(key + 0x80) (alt-key + 0x80) 0xC1

Really simple - you can see this clearly in IrDAmon. From there, it's just a matter of making a keymap.

[chrismulhearn]

Thanks for all the help man

Where can i get irdamon, w/ source?

Also, does your keyboards "on" light come on? I think i may have a dud. :( Maybe theres an on switch I'm not noticing?

edit: found IRDAmon. keyboard works, even though its "on" light doesnt.

[J.F.]

Thanks for all the help man

Where can i get irdamon, w/ source?

Also, does your keyboards "on" light come on? I think i may have a dud. :( Maybe theres an on switch I'm not noticing?

edit: found IRDAmon. keyboard works, even though its "on" light doesnt.

Dr. Vegetable posted a link here on PS2Dev. :) You'll find it here. It comes with full source. He posted a link to a related program called "IrDAtype" that is just the IrDAmon with decoding for the Belkin IR keyboard (what he has).

As to the other question: there's an "on" light on these keyboards? Damned if I've seen a light on mine. Ah... in the upper left edge of the keyboard... doesn't do squat on mine either. If I had to guess, I'd say they found that the batteries last A LOT longer with the light off than with it on, so they just disabled it in the firmware.

EDIT: I just noticed you said you found IrDAmon... oh well. Guess I need to read these posts more carefully. :) Well, at least you know your keyboard isn't acting any different than mine.

You might notice that Fn+/ doesn't give keycodes for "/", it gives battery info. It seems to be the only key combo I've seen that does something special. For example, Fn+Del gives the stream for Fn and Del. Fn + / is not Fn and /, it's Fn and something different that the user manual says is info about the battery.

[chrismulhearn]

oh man this is gonna be sweet.

I can do direct IO to read the IR data if I first do this:

sceCtrlSetSamplingCycle(0);
sceCtrlSetSamplingMode(PSP_CTRL_MODE_DIGITAL);
int fd = sceIoOpen("irda0:", PSP_O_RDWR, 0);

I don't do any with the "fd", the Open syscall must just also enable the hardware in the sys config area. For now, I'll just have my bootloader call those functions before jumping into Linux, and then Linux will just assume the bootloader initialized the hardware. I don't mind using the SDK in the bootloader, but i obviously can't use it once in Linux because linux replaces the cpu exception handler (so no more entry into PSP os)

So once the hardware is initialized, direct access can be done at

0xbe540000 (tx/rx buff)
0xbe540018 (status)

So now all thats left is writing the linux keyboard driver to handle this incoming data. RAD.

[J.F.]

I kinda thought you could use the "official" libs to initialize the hardware. The only thing I don't know about is the interrupt handler. The UARTs HAVE to have an interrupt handler, and I suppose there's some info on it in the site somewhere... maybe one of those posts on hardware regs hilde's always doing. :)

Like any other UART, I suspect the ones in the PSP generate an int on transmitting a byte, receiving a byte, or on an error (overflow, for example). If you look at the way the irda file handler and the IrDAmon app work together, it's clear the PSP is accumulating the bytes in a buffer filled by an interrupt routine, then passing on what has come in all at once to the app.

[hlide]

:)

well i don't really investigate so much about interrupt on SC processor side.

COP0 can only deal with 8 IRQs (IRQ7 being count timer and triggered when COP0.$9 == COP0.$12).

I think there is a cascade IRQ (probably IRQ0 since it always 1 most of time) which gives at most 32 extra IRQs for all the peripherals.

when using mtic/mfic insns, we are probably dealing directly with the masking of those 32 IRQs.

arch\mipsnommu\vr4181\common may give us a hint how psp is doing.

[J.F.]

I noticed in the psp kernel code (gotten off Chris' site last night) that he's using his old polled code for the serial. It busy loops for a given period waiting on bytes. That's fine for now while the kernel is still being worked on, but an interrupt driven routine will be needed later. Ditto for the IrDA.

Looking at the YAPPD, the first exception in the table is for software and hardware interrupts. Looking at the Interrupt Cause section (9.5.2.1), #0 is set if any of the UARTs caused the int, and #32 thru #37 tells you which UARTs specifically generated an int. The relevant code for determining the int # seems to be here (from 9.5.2.2):

Code: Select all

    /*
        find number of irq (and put it in a0)
    */
    v0=(IRQFRAME*)k0->cop0status & 0x2fffffe0;
    COP0STAT.12=v0; // status 
    if(( (v0 & (IRQFRAME*)k0->cop0cause) &0x8300)!=0)
    &#123;         v1=&#40;&#40;v1< <5&#41;|v1&#41;< <0x10;
        v1=clz&#40;v1&#41;; // count left zeros
        k1=66-v1; /* 66=highest irq number */
        v0=88022218&#40;struct88022630&#91;0&#93;.unk00,struct88022630&#91;0&#93;.unk04&#41;;
        a0=k1;
    &#125;

I think there's enough info in the YAPPD to make an interrupt handler that will take care of the int documented there. That would be:

Code: Select all

0 	  	UART_ALL 	 
1 	  	SPI_ALL 	 
2 	  	TIM_PERI_ALL 	 
3 	  	USB_ALL 	 
4 	32 	GPIO 	GPIO
5 	  	ATA 	ATA/ATAPI
6 	16 	SPOCK 	UMD MAN
7 	  	SMS1 	Memstick (MSCM0)
8 	  	SMS2 	WLAN
9 	  	MG 	 
10 	  	AUDIO1 	 
11 	  	AUDIO2 	 
12 	  	IIC 	I2C
13 	  	KEY 	 
14 	  	SIRCS 	IrDA
15 	  	TIM0_SYS 	Systimer 0
16 	  	TIM1_SYS 	Systimer 1
17 	  	TIM2_SYS 	Systimer 2
18 	  	TIM3_SYS 	Systimer 3
19 	  	COUNT 	Thread0
20 	  	EMC_SM 	NAND
21 	10 	DMAC128 	DMACPLUS
22 	  	DMAC_SC1 	DMA0
23 	  	DMAC_SC2 	DMA1
24 	  	KIRK 	MEMLMD
25 	32 	AW 	GE
26 	  	USB_MAIN 	 
27 	  	  	 
28 	  	  	 
29 	  	  	 
30 	32 	VSYNC 	Display VBlank
31 	  	SYS_REG 	ME Codec
32 	  	UART1 	 
33 	  	UART2 	 
34 	  	UART3 	 
35 	  	UART4 	 
36 	  	UART5 	HP Remote
37 	  	UART6 	 
38 	  	  	 
39 	  	  	 
40 	  	SPI1 	 
41 	  	SPI2 	 
42 	  	SPI3 	 
43 	  	SPI4 	 
44 	  	SPI5 	 
45 	  	SPI6 	 
46 	  	  	 
47 	  	  	 
48 	  	TIM1_PERI 	 
49 	  	TIM2_PERI 	 
50 	  	TIM3_PERI 	 
51 	  	TIM4_PERI 	 
52 	  	  	 
53 	  	  	 
54 	  	  	 
55 	  	  	 
56 	  	USB_TS 	USB Resume
57 	  	USBCON_TS 	USB Ready
58 	  	USBDIS_TS 	USB Connect
59 	  	USBREADY_TS 	USB Disconnect
60 	  	SMS1_CON 	Memstick Insertion (MSCM1)
61 	  	SMS1_DISCON 	Memstick Removal (MSCM2)
62 	  	SMS2_CON 	WLAN
63 	  	SMS2_DISCON 	WLAN
64 	  	SOFT1 	 
65 	  	SOFT2 	Thread1
66 	  	CPUTIMER 	Interrupt

Looking at the list, it seems IrDA has it's own interrupt flag along with the UART. Probably from the IR physical layer so that the IRDA handler in the PSP has a quicker dispatch to avoid losing any data. Just guessing here...

[chrismulhearn]

I actually only busy-waiting on Writes, and since the serial port console will probably be unused by most people, includng myself, I'm not really spending any time looking into the UART interrupts. If someone else wants make the UART code interrupt driven, they can send me a patch. :)

The serial recieve code is driven by a timer resource that you register with the kernel, and serial is certainly slow enough where this is adequate. Since the keyboard is input-only, I'll just poll it. If there is no data available when the timer fires, it simply exits. No busy waiting.

Now that I think about it, I dont remember how I implemented it, but the serial console/tty code MAY busy wait a little bit each polled read (dependant on the Timeout value passed to serialport_read) but if i did put a timeout there, it was a mistake and should just be 0.

[hlide]

[quote="J.F."]

Code: Select all

    /*
        find number of irq (and put it in a0)
    */
    v0=(IRQFRAME*)k0->cop0status & 0x2fffffe0;
    COP0STAT.12=v0; // status 
    if(( (v0 & (IRQFRAME*)k0->cop0cause) &0x8300)!=0)
    &#123;         v1=&#40;&#40;v1< <5&#41;|v1&#41;< <0x10;
        v1=clz&#40;v1&#41;; // count left zeros
        k1=66-v1; /* 66=highest irq number */
        v0=88022218&#40;struct88022630&#91;0&#93;.unk00,struct88022630&#91;0&#93;.unk04&#41;;
        a0=k1;
    &#125;

v1 = ?
v1 = ((v1 * 32)|v1)*512 ?

it checks if (soft)ip0 or (soft)ip1 or ip7 is triggered. So it isn't what we are looking at : indeed the answer would be in the else statement.

but it is unreadable...

NOTE:
it would make sense if :

64 SOFT1 <-- ip0
65 SOFT2 Thread1 <-- ip1
66 CPUTIMER Interrupt <-- ip7

[J.F.]

Code: Select all

    /*
        find number of irq (and put it in a0)
    */
    v0=(IRQFRAME*)k0->cop0status & 0x2fffffe0;
    COP0STAT.12=v0; // status 
    if(( (v0 & (IRQFRAME*)k0->cop0cause) &0x8300)!=0)
    &#123;         v1=&#40;&#40;v1< <5&#41;|v1&#41;< <0x10;
        v1=clz&#40;v1&#41;; // count left zeros
        k1=66-v1; /* 66=highest irq number */
        v0=88022218&#40;struct88022630&#91;0&#93;.unk00,struct88022630&#91;0&#93;.unk04&#41;;
        a0=k1;
    &#125;

v1 = ?
v1 = ((v1 * 32)|v1)*512 ?

it checks if (soft)ip0 or (soft)ip1 or ip7 is triggered. So it isn't what we are looking at : indeed the answer would be in the else statement.

but it is unreadable...

NOTE:
it would make sense if :

64 SOFT1 <-- ip0
65 SOFT2 Thread1 <-- ip1
66 CPUTIMER Interrupt <-- ip7

Yes, I noticed after looking at it for a while. The interrupt code is a real mess... I'm going to try and work back to the hardware to find all the real int status flags and what-not.

edit: with just a quick look through, it seems that the registers in question are
0xbc300000 - control1
0xbc300008 - status1
0xbc300010 - control2
0xbc300018 - status2

Seems like 08 and 18 are the flags showing which irqs are outstanding... you probably write them to clear the int. 00 and 10 seem to be controls and/or enables. I'll keep at it and post more as I figure it out.

[J.F.]

Okay... ints seem to be like this:

bc300000 = enables for irq0-31
bc300008 = status for irq0-31
bc300010 = enables for irq32-63
bc300018 = status for irq32-63

Priority is from 0 to 63.

Int handler:
- enabled0 = bc300000 & 0xfffffff0, effectively telling the int handler that the ALL ints are to be ignored
- enabled1 = bc300010
- pending0 = bc300008
- pending1 = bc300018
- outstanding0 = enabled0 & pending0
- outstanding1 = enabled1 & pending1
- if outstanding0 and outstanding1 are both 0, spurious int
- if outstanding0
-- write pending0 | 0x0f to bc300008 to clear ints
-- find most significant outstanding0 int (the handler does this by reversing the bits and counting the leading 0's to get the int #)
- else if outstanding1
-- write pending1 to bc300018 to clear ints
-- find most significant outstanding1 int (same as above, but add 32 to clz)
- do specific handler for the irq found

There's more in the int handler, but that is the pseudo-code to handle the IRQs.

[chrismulhearn]

very nice!

Now.... anyone wanna take a crack at the wifi hardware? ;-D

If we get the WIFI working, and remember we have the SDK at our disposal the whole bootloading process [maybe we could even discover a network in the bootloader at first, to keep things "simple", and require a reboot if you go out of range or something...] then we could have SDL-based web browser, SDL-based email... hell this uClinux port could actually be useful! ;)

[hlide]

which cascade irq on CPU is used to handle those 64 irq ? ip2 ? a cpu can raise an interrupt (exception #0) only through its irqs. I remember Adrahil told me that masking ip2 prevents from gpio watchdog to avoid shutdown. I wouldn't be surprised ip2 is cascade irq.

those registers are probably the keys for activating 64 irqs. Nonetheless there is a small subtility :

there is 32 main interrupts, first 4 of which group 8 specific interrupts :

Code: Select all

|
+- IP2 CASCADE IRQ
|  |
|  +- 0 UART_ALL   
|  |  |
|  |  +- 32 UART1    
|  |  +- 33 UART2    
|  |  +- 34 UART3    
|  |  +- 35 UART4    
|  |  +- 36 UART5
|  |  +- 37 UART6    
|  |  +- 38              
|  |  +- 39
|  |
|  +- 1 SPI_ALL
|  |  |
|  |  +- 40 SPI1    
|  |  +- 41 SPI2    
|  |  +- 42 SPI3    
|  |  +- 43 SPI4    
|  |  +- 44 SPI5    
|  |  +- 45 SPI6    
|  |  +- 46              
|  |  +- 47              
|  |
|  +- 2 TIM_PERI_ALL    
|  |  |
|  |  +- 48 TIM1_PERI    
|  |  +- 49 TIM2_PERI    
|  |  +- 50 TIM3_PERI    
|  |  +- 51 TIM4_PERI    
|  |  +- 52              
|  |  +- 53              
|  |  +- 54              
|  |  +- 55              
|  |
|  +- 3 USB_ALL
|  |  |
|  |  +- 56         USB_TS    USB Resume
|  |  +- 57         USBCON_TS    USB Ready
|  |  +- 58         USBDIS_TS    USB Connect
|  |  +- 59         USBREADY_TS    USB Disconnect
|  |  +- 60         SMS1_CON    Memstick Insertion (MSCM1)
|  |  +- 61         SMS1_DISCON    Memstick Removal (MSCM2)
|  |  +- 62         SMS2_CON    WLAN
|  |  +- 63         SMS2_DISCON    WLAN
|  |
|  +- 4 GPIO
|  +- 5 ATA
|  +- 6 SPOCK
|  +- 7 SMS1
|  +- 8 SMS2
|  +- 9 MG    
|  +- 10 AUDIO1    
|  +- 11 AUDIO2    
|  +- 12 IIC
|  +- 13 KEY    
|  +- 14 SIRCS
|  +- 15 TIM0_SYS
|  +- 16 TIM1_SYS
|  +- 17 TIM2_SYS
|  +- 18 TIM3_SYS
|  +- 19 COUNT
|  +- 20 EMC_SM
|  +- 21 DMAC128
|  +- 22 DMAC_SC1
|  +- 23 DMAC_SC2
|  +- 24 KIRK
|  +- 25 AW
|  +- 26 USB_MAIN    
|  +- 27              
|  +- 28              
|  +- 29              
|  +- 30 VSYNC
|  +- 31 SYS_REG
|
+- IP0 64 SOFT1    
|
+- IP1 65 SOFT2
|
+- IP7 66 CPUTIMER

[hlide]

- enabled0 = bc300000 & 0xfffffff0, effectively telling the int handler that the ALL ints are to be ignored

is that so ? so it would be 64 - 4 interrupts through those registers.

My assumptions :

- ip2 is "cascade" irq for 32 main irqs
- 1st main irq is "cascade" irq for 8 specific irqs
- 2nd main irq is "cascade" irq for 8 specific irqs
- 3rd main irq is "cascade" irq for 8 specific irqs
- 4th main irq is "cascade" irq for 8 specific irqs

if you want to disable the 32 specific irqs it may make sense to mask the first 4 bits.

Otherwise you would not have 64 (32+32) irq but only 60 irqs (28+32).

[J.F.]

- enabled0 = bc300000 & 0xfffffff0, effectively telling the int handler that the ALL ints are to be ignored

is that so ? so it would be 64 - 4 interrupts through those registers.

My assumptions :

- ip2 is "cascade" irq for 32 main irqs
- 1st main irq is "cascade" irq for 8 specific irqs
- 2nd main irq is "cascade" irq for 8 specific irqs
- 3rd main irq is "cascade" irq for 8 specific irqs
- 4th main irq is "cascade" irq for 8 specific irqs

if you want to disable the 32 specific irqs it may make sense to mask the first 4 bits.

Otherwise you would not have 64 (32+32) irq but only 60 irqs (28+32).

Well, the int handler treats it as 28+32. Like I said, they fetch bc300000 to get which ints are enabled for the first 32 irqs, but THEN they mask off the first 4 bits. That tells me those bits are set (enabled), but they are going to ignore them in favor of the individual irqs, which are lower priority.

But that means you're probably right about the cascading - the four groups of eight irqs in the second register are probably bulk enabled by setting the first four bits, one per group. That would be the only reasonable reason to enable the bits, then ignore them in the handler rather than simply disable them and not worry about the masking in the handler.

[chrismulhearn]

Thanks for the suggestion about the keyboard.

I wrote the driver tonight and it frigging rocks.

Manually creating the key translation map, on the other hand, did not rock. hehehe.

Once i neaten it up tomorrow [few keys are wrong etc] i'll post the newest kernel. now with framebuffer console + keyboard support!