uClinux on the PSP

Djakku · Post by **Djakku** » Tue Mar 20, 2007 5:14 am

Yeah but even if you want to boot linux on the psp you have to use that HACK you're talking about. There is no way someone is gonna flash his psp with a linux OS and even if it possible that person would still need the famous EBOOT to BOOT the application.
But hey I have no idea of coding so maybe I'm talking nonsense here. The missing and needed documentation are (if I understood the problem correctly) about the hardware itself, since there is no UMD drive (for instance) anywhere else the psp, coding a Linux driver without any pure hardware knowledge is close to impossible. The way the wifi card is used with any other homebrew is not the same way it is used under the XMB and even if you know perfectly how to make it work via the psp firmware, for linux you have to write the driver in order to make it interface with the psp.
I think knowledge of the eboot fuctionnalities are essential but for this project, it far from enough...
It like installing linux on a machine, you need their driver right? And if you don't have the driver, your hardware will not work.
Or maybe I you think about computer with two or more OS installed. One may have all the drivers and work correcty (for instance the latest XP) but that same computer might not run the same under linux if the linux driver are not installed.
XMB could be you windows if you like and uclinux is .... Linux! :)

jtilghman · Post by **jtilghman** » Tue Mar 20, 2007 5:45 am

Ok, very true..

Now I see what you mean.

Well, I think it would great have linux on the PSP.

But just so i can understand more of what I am or I am not talking about, i am teaching myself to code for PSP using XBM and eboot.

This way maybe i wont sound as dumb when I post about this stuff.. :)

Thanks,
John

hlide · Post by **hlide** » Tue Mar 20, 2007 6:05 am

well if you just want to be able tu run only linux applications (user code), another possibility is to code something like colinux (a user linux running on a non-linux host like windows). I don't know if it is easy to do so, but at last you don't have the hardware problem since it is "emulated". colinux source is available I believe.

Or just have a cygwin equivalent too.

But I agree : it is not the same thing as to have a true linux.

crazyc · Post by **crazyc** » Tue Mar 20, 2007 7:17 am

For this to have any usefulness whatsoever, it needs WIFI support and Memory Stick support.

These two problems appear to be closely related as the wifi seems to be connected to the memory stick host controller. Figuring out how to program that controller is the hard part, but if that is solved then the libertas command documentation should make it easy to finish.

cloudhunter · Post by **cloudhunter** » Tue Mar 20, 2007 10:50 pm

Djakku wrote: I think knowledge of the eboot fuctionnalities are essential but for this project, it far from enough...

Unfortunately though, once Linux is loaded it takes over the system... meaning that the SDK is no longer available to the system. The way that they managed to get the IR keyboard working is to initialise the IR port, then to assume it's initialised and to use it... however, that was a relatively simple serial device, and nowhere near as complex as the MS or Wifi controllers.

Like hilde said, it may be possible to create a "colinux" type wrapper... In which the SDK handles the hardware and linux interfaces with it (much how the hypervisor works on the PS3 I imagine). However, the source probably won't be applicable as it is a totally different hardware platform. It wouldn't be an easy task, and it's probably easier just to access the hardware directly.

Cloudy

chrismulhearn · Post by **chrismulhearn** » Thu Mar 22, 2007 2:10 am

Yes, we've discussed this in the past. I was considering writing wrappers to PSP OS system calls, but leaving the PSP OS kicking around will "waste" memory too.

Not to mention its unclear how the return mechanism in the PSP system call layer is written, would we be guaranteed to return to the location we invoked the call from? Or might there be a time-based scheduler that gets invoked before the return that would end up throwing us into the middle of nowhere? Well, you'd think ultimately we'd get back to where we initiated the system call, but anyways, theres some thinking to do here.

I think once my classes are over for the summer I'll just have to trace my way through the PSP OS system calls and see whats what. Again, maybe all we need to understand is how to communicate with the WIFI after a connection with a network has already been established we could establish the connection in the bootloader while the PSP OS is still available to us) Maybe that would make our task easier? I have no idea. All speculation. Hopefully someone will start tinkering with this stuff, otherwise its gonna have to wait til May.

-Chris.

cloudhunter · Post by **cloudhunter** » Thu Mar 22, 2007 9:52 am

Unfortunately though, that approach would render apps that use wifi directly useless... And would waste battery establishing a connection when it's not always needed. However, it could be a start... At least until direct hardware access is figured out.

Cloudy

chrismulhearn · Post by **chrismulhearn** » Fri Mar 23, 2007 1:05 am

Apps that use wifi directly?

The purpose of a Device Driver model, and some may say an Operating System in general, is to abstract access to such devices. No properly written applicate will "use wifi directly". And if we weren't in uClinux, it wouldn't even be possible for an application to "use wifi directly".

Perhaps you mean "use the wifi interface directly." Well, here we have the same argument. The point of a network stack sitting on top of device drivers is to abstract access to the network. A properly written application will not "use the wifi interface directly", rather, it will communicate with the network stack of the kernel to open TCP connections, read and write the resulting sockets, etc. I can't imagine a single application that we'd want on this unit that would "use the wifi interface directly."

Djakku · Post by **Djakku** » Fri Mar 23, 2007 9:16 am

I'm just spilling some thought but program like airodump-ng dump all the wifi wave transmitted from one computer to another so maybe by analysing the dumped cap file from a psp to a acess point, you could actually understand how the driver behave?
by using you psp to surf of with pspradio or any other apps, if you activate airodump-ng you will dump all the packets transmitter from the psp to the access point. you can also do it with pspftp server and so and then maybe find some info...? again I'm just spilling ideas.

cloudhunter · Post by **cloudhunter** » Fri Mar 23, 2007 9:38 am

Forgive me, I didn't explain myself properly.

What I meant is apps like network sniffers etc, that use the interface directly...

For normal network access though, communicating after the wireless has been set up would be fine... It wouldn't be too difficult to reset the PSP in order to change connections, or to disconnect ;)

Cloudy

hck-dev · Post by **hck-dev** » Fri Mar 23, 2007 7:21 pm

Listen. I dont mean to be rude but. The eboot's dont really matter, the main thing is to get the eboot to load up the bootloader, and to also allow certain hardware to activate. Possibly place code into certian point within the memory apart from that there nothing else we need to do to the eboots.

Now, wht we do need to do is to possibly make some modifications to the bootloader, and then start making device drivers. Thats wht needs to be done. Apart frm that dont watse time with the eboot, concentrate on getting the drivers up.

I could also do some reasearch into the arcitecture; so we could optimise the code. So... what now. Me personally would like to talk to Chris about somethinng, so i can get some serious Linux developers, as i have done with my Nokia Linux Project.

So we need people to concentrate on the making drivers, btw. is the platform ready for posrting apps??.

Thanks.

cloudhunter · Post by **cloudhunter** » Fri Mar 23, 2007 9:34 pm

Well, at the moment it doesn't even have a memory stick system driver... so unless you want to embed all your apps inside a root filesystem image, then I really don't think it's practical yet.

I have full confidence in Chris though... Shame there aren't more people working on it though.

Cloudy

hlide · Post by **hlide** » Fri Mar 23, 2007 10:34 pm

cloudhunter wrote:Well, at the moment it doesn't even have a memory stick system driver... so unless you want to embed all your apps inside a root filesystem image, then I really don't think it's practical yet.

I have full confidence in Chris though... Shame there aren't more people working on it though.

Cloudy

ShaDe, you mean, because i don't see what we should be shameful not to work on it.

Just a question, can your kernel handle all the interrupts ? i mean those specific to PSP ? because you would need them for nearly anything about hardware PSP.

EDIT: i mean, having a general mechanism to handle any interrupt regardless the interrupt meaning as does the firmware.

cloudhunter · Post by **cloudhunter** » Sat Mar 24, 2007 12:39 pm

hlide wrote: ShaDe, you mean, because i don't see what we should be shameful not to work on it.

Just a question, can your kernel handle all the interrupts ? i mean those specific to PSP ? because you would need them for nearly anything about hardware PSP.

EDIT: i mean, having a general mechanism to handle any interrupt regardless the interrupt meaning as does the firmware.

I don't mean that it is a shame not to work on it... I just mean it's such a promising project that it's a shame more work isn't being done, as it could turn out pretty useful.

Cloudy

chrismulhearn · Post by **chrismulhearn** » Sun Mar 25, 2007 3:32 pm

hlide, you seem to be very vocal about your will to not work on the project. Thats strange, why post anything at all on this thread? Well, you were certainly helpful with the cache, so whatever. Anyways.

Regarding the interrupts, well, interrupts/exceptions are really the key to the whole thing. If interrupt/exception plumbing wasn't in the kernel, then we wouldn't be having timers running the scheduler or applications invoking system calls. But maybe you are talking about the more higher level plumbing, do the interrupts make it from the generic handler to their associated device driver? No. But not because that poses any amount of difficulty. We just don't have any device drivers! Maybe I don't understand your question.

hck-dev, what I think we _need_ is memory stick support and wifi support. As we stand now, we have no way to communicate with the outside world, and no way to have any non-transient storage. Hlide will now say that this will be impossible, and maybe he/she/it's are right, but the topic hasn't been explored anywhere near enough to make that determination.

As far as "eboots don't really matter", well, interacting with the PSP OS is really the only way we are going to figure out how this cpu is interfacing with these devices that we have no documentation for, and we need to know this before we can begin writing device drivers. So you see, PSP applications matter a _lot_ at the moment. Ultimately, when we have learned all we can about these devices, you'll be right, we can forget it all entirely and stay in linuxland.

Anyways, I'll mention it again: If anyone feels like reverse engineering stuff, (oh, i dunno, stepping through system call implementations in the PSP OS when invoking reads/writes on network sockets from a homebrew app, etc, or when invoking reads/writes on a file on the memory stick, whatever) play with the wifi and memory stick, it'll be fun, and it will make this project waaaay more useful.

-Chris

hlide · Post by **hlide** » Sun Mar 25, 2007 11:50 pm

chrismulhearn wrote:Regarding the interrupts, well, interrupts/exceptions are really the key to the whole thing. If interrupt/exception plumbing wasn't in the kernel, then we wouldn't be having timers running the scheduler or applications invoking system calls. But maybe you are talking about the more higher level plumbing, do the interrupts make it from the generic handler to their associated device driver? No. But not because that poses any amount of difficulty. We just don't have any device drivers! Maybe I don't understand your question.

why don't you have a look upon :

\linux-2.4.19-01092007\arch\mipsnommu\vr4181\common
\linux-2.4.19-01092007\include\asm-mipsnommu\vr4181

i'm pretty sure it should be something like them for psp.

well this source is a mess. I don't know what is used or not. you cannot have a global view. And apparently you cannot use psptoolchain et gcc 4.x to compile it.

NOTE: i'm not saying YOUR source is a mess, but linux source is a mess to deal with.

chrismulhearn · Post by **chrismulhearn** » Mon Mar 26, 2007 3:12 am

???? why are we talking about this. You pointed out one architecture's interrupt plumbing. Theres about 50 other examples, all equally valid. The point of the code you are looking at is to A. bundle up some hardware specific initialization stuff, and B. to handle dispatching interrupts to the things that are interested in them.

There is a "request_irq()" and "do_irq()" (think those are the functions) generic method that will work fine. A driver tells the kernel that it is interested in irq X and registers a callback for it, and so the low level generic interrupt handler do_irq() will invoke that callback (and callbacks for any other drivers interested in the irq) when the interrupt occurs. do_irq() is invoked by sim_handle_interrupt() in sim_irq.c, which is invoked by sim_handle_int, which is probably invoked by sim_handle_exception or someting like that.

But more importantly, I'm completely confused as to why you are so interested in this, and why you think its helpful to point out other bits of completely unrelated code that is doing interrupt dispatch. Don't worry about it, its a piece of cake. If you want to learn about it, well, get Understanding the Linux Kernel and Linux Device Drivers, both published by o'reilley.

Clearly we first need to know how to talk to this hardware.

hlide · Post by **hlide** » Mon Mar 26, 2007 8:17 am

PSP has a very similar way to handle intr :

8 mips IRQ (common to all MIPS)
32 sys IRQ (specific to PSP) mapped at INT0

sys IRQ #4 handles 32 GPIO irqs

each of the first 4 sys IRQs seem to handle 8 IRQ

some GPIO addresses are here :
http://forums.ps2dev.org/viewtopic.php? ... light=gpio
http://forums.ps2dev.org/viewtopic.php? ... light=gpio
http://forums.ps2dev.org/viewtopic.php? ... light=gpio

hlide · Post by **hlide** » Mon Mar 26, 2007 8:58 am

those registers needs much more reverse engineering.

0xbc300000 : upper 2 bits 'enable' ?, upper bits=mask ? (used in irq handler)
0xbc300008 : upper bits=mask,low 4 bits='ack,enable' ? (used in irq handler)
0xbc300010 : mask ? (used in irq handler)
0xbc300018 : mask ? (used in irq handler)

IP0-7 are mips irqs (common to all mips)

64, 64, etc. are intr number reported by firmware when handling them, they have no real meaning for the harwdare part indeed.

they are just speculations but irqs look like !

8 mips irqs + 32 sys irqs + ...
----------------------------------

Code: Select all

|
+- IP0 64 SOFT1 &#40;MIPS IRQ&#41;   
|
+- IP1 65 SOFT2 &#40;MIPS IRQ&#41;
|
+- IP2 CASCADE IRQ &#40;MIPS IRQ -> SYS IRQ&#41;
|  |
|  +- 0 CASCADE UART_ALL &#40;SYS IRQ -> UART IRQ ?&#41; 
|  |  |
|  |  +- 32 UART1   
|  |  +- 33 UART2   
|  |  +- 34 UART3   
|  |  +- 35 UART4   
|  |  +- 36 UART5
|  |  +- 37 UART6   
|  |  +- 38             
|  |  +- 39
|  |
|  +- 1 CASCADE SPI_ALL &#40;SYS IRQ -> SPI IRQ ?&#41;
|  |  |
|  |  +- 40 SPI1   
|  |  +- 41 SPI2   
|  |  +- 42 SPI3   
|  |  +- 43 SPI4   
|  |  +- 44 SPI5   
|  |  +- 45 SPI6   
|  |  +- 46             
|  |  +- 47             
|  |
|  +- 2 CASCADE TIM_PERI_ALL &#40;SYS IRQ -> TIM_PERI IRQ ?&#41;   
|  |  |
|  |  +- 48 TIM1_PERI   
|  |  +- 49 TIM2_PERI   
|  |  +- 50 TIM3_PERI   
|  |  +- 51 TIM4_PERI   
|  |  +- 52             
|  |  +- 53             
|  |  +- 54             
|  |  +- 55             
|  |
|  +- 3 CASCADE USB_ALL &#40;SYS IRQ -> USB IRQ ?&#41;
|  |  |
|  |  +- 56         USB_TS    USB Resume
|  |  +- 57         USBCON_TS    USB Ready
|  |  +- 58         USBDIS_TS    USB Connect
|  |  +- 59         USBREADY_TS    USB Disconnect
|  |
|  +- 4 CASCADE GPIO &#40;SYS IRQ -> GPIO IRQ ?&#41;
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |
|  +- 5 ATA
|  +- 6 SPOCK
|  +- 7 CASCADE SMS1 &#40;SYS IRQ -> SMS1 IRQ ?&#41;
|  |  +- 60         SMS1_CON    Memstick Insertion &#40;MSCM1&#41;
|  |  +- 61         SMS1_DISCON    Memstick Removal &#40;MSCM2&#41;
|  +- 8 CASCADE SMS2 &#40;SYS IRQ -> SMS2 IRQ ?&#41;
|  |  +- 62         SMS2_CON    WLAN
|  |  +- 63         SMS2_DISCON    WLAN
|  +- 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 CASCADE DMAC128 &#40;SYS IRQ -> DMAC128 IRQ ?&#41;
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  |  +- ???   
|  +- 22 DMAC_SC1
|  +- 23 DMAC_SC2
|  +- 24 KIRK
|  +- 25 AW
|  +- 26 USB_MAIN   
|  +- 27             
|  +- 28             
|  +- 29             
|  +- 30 VSYNC
|  +- 31 SYS_REG
|
+- IP3 ???
|
+- IP4 ???
|
+- IP5 ???
|
+- IP6 ???
|
+- IP7 66 CPUTIMER

crazyc · Post by **crazyc** » Mon Mar 26, 2007 1:34 pm

hlide wrote:those registers needs much more reverse engineering.

0xbc300000 : upper 2 bits 'enable' ?, upper bits=mask ? (used in irq handler)
0xbc300008 : upper bits=mask,low 4 bits='ack,enable' ? (used in irq handler)
0xbc300010 : mask ? (used in irq handler)
0xbc300018 : mask ? (used in irq handler)

Actually 0xbc300000 and 0xbc300010 are the status and ack bitmasks and 0xbc300008 and 0xbc300018 are the enable bitmasks for irqs 0-31 and 32-63 respectively.

hlide · Post by **hlide** » Mon Mar 26, 2007 3:49 pm

thanx CrazyC

any clues about 0xbc300004, 0xbc30000c and 0xbc300014 ?

0xbc300000 : status and ack bitmask for 0-31 ?
0xbc300004 : ???
0xbc300008 : enable bitmask for 0-31 ?
0xbc30000c : ???
0xbc300010 : status and ack bitmask for 32-63 ?
0xbc300014 : ???
0xbc300018 : enable bitmask for 32-63 ?
0xbc30001c : ???

hck-dev · Post by **hck-dev** » Mon Mar 26, 2007 6:41 pm

the O'Reilly books is a nice recommendation for all devs workin or instrested on this project, as i myself was going to buy them yesterday before i saw ur post :p.

Secondly i have some whiteppaers on the psps hardware full of pages i think its something like 300+ pages.

So ill send a link when i other machine.

hck-dev · Post by **hck-dev** » Mon Mar 26, 2007 6:45 pm

yea jus found it. only 157 pages, but hey.

http://www.jess2.net/code/PSP/psp_doc.pdf

Hope everyone can make use of it

chrismulhearn · Post by **chrismulhearn** » Tue Mar 27, 2007 12:08 am

I'm thinking about writing a little snooping utility to see what HW addresses are being stimulated when particular interrupts fire, stuff like that.

This would work by wrapping their exception handler with one of our own. Then it would work like this:

Store the next instruction that we are supposed to execute from the REAL exception handler somewhere in memory. Take a look at it, if when executed its going to do some stuff to the interrupt controller or to the memmapped hardware region, record it somewhere. Stick a break instruction at its original location. Jump into their exception handler.

Now we will execute until we hit our break, at which point we return to our toplevel exception routine. I guess the first thing we should do is actually make sure it was a BREAK exception, because maybe their exception handler will throw an exception and we'll get confused. Then we stick their original instruction back, and do the switcheroo with the next instruction. Crap, we'd have to deal with branches and delay-slots and stuff, too. Hmmm. Anyways this is starting to confuse me, can anyone think of an easier way to snoop whats going on during the execution of their exception handler? Clearly we need to be tossing an exception every instruction (or at leasts immediately following all jumps) to examine the state of things, but maybe this Break technique isn't really the way to do it, maybe theres an easier way?

crazyc · Post by **crazyc** » Tue Mar 27, 2007 12:17 am

hlide wrote:thanx CrazyC

any clues about 0xbc300004, 0xbc30000c and 0xbc300014 ?

0xbc300000 : status and ack bitmask for 0-31 ?
0xbc300004 : ???
0xbc300008 : enable bitmask for 0-31 ?
0xbc30000c : ???
0xbc300010 : status and ack bitmask for 32-63 ?
0xbc300014 : ???
0xbc300018 : enable bitmask for 32-63 ?
0xbc30001c : ???

Within interruptman, 0xbc3000[0-1]4 is only read inside of sceKernelIsInterruptOccurred and never written, perhaps as an alternate status? I don't see 0xbc3000[0-1]c used anywhere. Also I may be wrong about 0xbc3000[0-1] as only 0xbc300000 is written and only if the interrupt is 30 or 31.

crazyc · Post by **crazyc** » Tue Mar 27, 2007 12:34 am

I'm thinking about writing a little snooping utility to see what HW addresses are being stimulated when particular interrupts fire, stuff like that.

What I was thinking, although doing it would be rather difficult with all the kernel mode function calls that would have to be fixed up, would be to attempt to get the driver running in user mode. Every time a hw register is written an exception would fire and the state of the driver could then be captured, then the handler would do the write, then return.

hlide · Post by **hlide** » Tue Mar 27, 2007 4:05 am

hck-dev wrote:yea jus found it. only 157 pages, but hey.

http://www.jess2.net/code/PSP/psp_doc.pdf

Hope everyone can make use of it

the well known groepaz's document indeed

chrismulhearn · Post by **chrismulhearn** » Thu Apr 12, 2007 4:19 am

If anyone is really looking to help the project and doesn't know what exactly they should do, I have a good idea. Get a "live CD" development environment going: A bootable linux system iso that takes all the hassle out of installing the toolchain/kernel/userland libraries/etc.

So the xiptech toolchain, uClibC, SDL, (any other libraries we start throwing in), and the kernel would all be on the ISO already compiled etc.

I'm not sure how those "live cd" linux things work, where do you write your non-transient storage? I guess /bin /etc all that could be on the ISO, but /usr/local and /home/ could be actual partitions... Or even just filesystem images that are files on your regular OS's drive.

For example, for a windows user with C: as their primary IDE master, we would mount /dev/hda1 /mnt
mount -o loop /mnt/usrlocal.img /usr/local
mount -o loop /mnt/home.img /home

This way you could read/write /usr/local/ and /home (and thats where all your psp linux development would happen) and if you were a windows user who didn't want to do any drive partitioning, you wouldnt have to!

Just a thought, let me know if anyone is interested, it could help get rid of some of the initial learning curve.

alexp · Post by **alexp** » Tue Apr 17, 2007 12:53 am

Linux Live CDs usually uses compressed read only images for filesystem data and writable filesystems on ramdisks, then unionfs is used to make make then a single filesystem.
Actually, i don't think that a live cd will help a windows user to work on linux for psp. Porting linux will at least need a good experience with linux itself.

Anyway, me and a bunch of friends are waiting for our brand new PSPs, we're all computer engineering students and we'll try to contribute to the project. I'm currently studying MIPS programming on PS2 now.

chrismulhearn · Post by **chrismulhearn** » Tue Apr 17, 2007 2:35 am

Right well clearly the ramdisk solution wouldn't work, we need non-transient storage.

Its not that getting linux installed is difficult, its that people have a lot of trouble installing the toolchain. Scattered dependencies and things make it complicated for people.

Perhaps your comment about "porting linux" is true, but at some point in the near future this will be a stable enough platform for application programmers/porters to play too.

So just because someone doesn't want to repartition their hard drive to install a new OS, patch and compile their own toolchain and patch and compile their own userland libraries does not mean they would not be able to help bring applications to this platform.

If anyone wants to make a live CD with /usr/local and /home mounted from files on some existing (perhaps non-linux) volume and the toolchain installed, I'd be much obliged. An existing fancy distro's livecd would probably be a good starting point so we'd have all their fancy hardware autodetection etc.
-Chris

forums.ps2dev.org

uClinux on the PSP

huh?

Something simple to do