forums.ps2dev.org

[hlide]

[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]

[hlide]

[crazyc]

[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]

[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.]

[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.]

[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.]

[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):

[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."]

[J.F.]

[quote="hlide"]

[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 :

[hlide]

[J.F.]

[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!