Hi all, I'm planning to work on drivers for Chris's uclinux port. And I hope to get some ideas on memory stick driver and WIFI.
But I'm not sure how the official firmwares access the MS, through DMA or what?
Can any one give some code on how it works?
I'm expecting chris's new kernel version, it will have ir keyboard and screen working.
btw, I've terminated my work on the USB-serial (pl2303) driver since PSP seems to have a client-only controller. I'm not sure on this point wether it supports On The Go protocol. But I tested on a PSP USB Camera, I tried to connect the device directly to PC by a female-female connector, it acts like a host device and refused to work correctly even when I feed Window$ with a *blank* sample USB driver from DDK. The camera should have a host controller, or sony devs must be nuts, hoping to make their accessories not capable with PCs while the PSP supports OTG. maybe they really are. I'm not sure on this either.
On The Go: briefly, it's a protocol which enables USB accessories to connect each other without a host controller. It requires a specific hardware mode to support the protocol. See www.usb.org for details.
I have a mirror site up for uClinux on PSP. http://218.79.106.23
I'll update the link if my IP address has changed.
UPDATE:
Server up. WebCVS working, but I still have no idea how to add files to cvsroot and set up a cvs server...
Anyone could have a test on download speed? Thanks.
PSP drivers for uclinux
PSP drivers for uclinux
Last edited by gbj1 on Sat Feb 10, 2007 10:06 pm, edited 3 times in total.
Hi,
I'm just guessing here, but I think access to the UMD and the Memory Stick should be possible through the ATA controller. I'm referring to the module ata.prx of the psp kernel. If this is really a full functional ata interface then it would be possible to access the drives through the control registers. I think the registers 0xbd700000 through 0xbd700008 used by the module ata.prx look promising.
Unfortunately I could not succeed in doing anything with them. They also seem to be in a non-standard order. I guess the address 0xbd70002 and 0xbd70006 hold the STATUS and ALTERNATE STATUS variables since both read the value 0x40 (= READY) and all others are 0 when I access them from uClinux.
I wanted to experiment with initializing the controller in the bootloader through the API functions but sceAtaInit() and others are only available in the 1.0 firmware. So the only function I tried in the bootloader is sceSysregAtaIoEnable(). The effect is that the memory addresses in question all read 0.
The psp_doc.pdf also mentions that the ATA interface can raise an interrupt. As far as I know (could be wrong here) the controller would acknowledge a command with it.
I'm not sure if this is any help at all. Maybe I'm completely off track here.
I'm just guessing here, but I think access to the UMD and the Memory Stick should be possible through the ATA controller. I'm referring to the module ata.prx of the psp kernel. If this is really a full functional ata interface then it would be possible to access the drives through the control registers. I think the registers 0xbd700000 through 0xbd700008 used by the module ata.prx look promising.
Unfortunately I could not succeed in doing anything with them. They also seem to be in a non-standard order. I guess the address 0xbd70002 and 0xbd70006 hold the STATUS and ALTERNATE STATUS variables since both read the value 0x40 (= READY) and all others are 0 when I access them from uClinux.
I wanted to experiment with initializing the controller in the bootloader through the API functions but sceAtaInit() and others are only available in the 1.0 firmware. So the only function I tried in the bootloader is sceSysregAtaIoEnable(). The effect is that the memory addresses in question all read 0.
The psp_doc.pdf also mentions that the ATA interface can raise an interrupt. As far as I know (could be wrong here) the controller would acknowledge a command with it.
I'm not sure if this is any help at all. Maybe I'm completely off track here.
Sounds great.
I noticed a series of sexy prx(es) called sceMS*, do they stand for MemoryStick? Their API names show that the _firmware_ accesses the memory stick through DMA (refer to moonlight's doc).
Based on your experiment, I suppose probably the sceSysregAtaIoEnable() just _enables_ the controller's function(ie. a power wake-up, cache allocation, enable interrupts, etc) but not the actual _startup_
1.5 seems to have a totally different way to start the controller, not just a single call().
I guess, the access is on-demand. When there is a need to access the stick, some drivers are loaded and the controller is initilized. After that, everything goes dormant until next interrupt is held.
EDIT1:
If you could trace some actual read/write actions and see what happens, you will probably see how it works. I have some experience on coding on ARM & x86 processors, but not very familiar with MIPS. I feel **very** bad while tracing the disasm code.
I noticed a series of sexy prx(es) called sceMS*, do they stand for MemoryStick? Their API names show that the _firmware_ accesses the memory stick through DMA (refer to moonlight's doc).
Based on your experiment, I suppose probably the sceSysregAtaIoEnable() just _enables_ the controller's function(ie. a power wake-up, cache allocation, enable interrupts, etc) but not the actual _startup_
1.5 seems to have a totally different way to start the controller, not just a single call().
I guess, the access is on-demand. When there is a need to access the stick, some drivers are loaded and the controller is initilized. After that, everything goes dormant until next interrupt is held.
EDIT1:
If you could trace some actual read/write actions and see what happens, you will probably see how it works. I have some experience on coding on ARM & x86 processors, but not very familiar with MIPS. I feel **very** bad while tracing the disasm code.
Re: PSP drivers for uclinux
OLPC has a linux libertas driver in their git repository. Hopefully the usb and psp firmwares use similar interfaces. http://dev.laptop.org/git.do?p=olpc-2.6 ... s/libertasgbj1 wrote:Hi all, I'm planning to work on drivers for Chris's uclinux port. And I hope to get some ideas on memory stick driver and WIFI.
It's very helpful, at least, we won't need to write Marvell's WLAN protocol stack from start point any more.OLPC has a linux libertas driver in their git repository. Hopefully the usb and psp firmwares use similar interfaces.
It also has a 8388 usb driver, it seems to be used to download the firmware to the WIFI chip. Doos PSP's chip require the same thing? I'm compiling the source and see if there is still some libs remaining to be ported to uClinux.
Great help, crazyc!
Look in wlan.prx (1.50) or wlanfirm_magpie.prx (3.02), the firmware is in there.gbj1 wrote:It's very helpful, at least, we won't need to write Marvell's WLAN protocol stack from start point any more.OLPC has a linux libertas driver in their git repository. Hopefully the usb and psp firmwares use similar interfaces.
It also has a 8388 usb driver, it seems to be used to download the firmware to the WIFI chip. Doos PSP's chip require the same thing? I'm compiling the source and see if there is still some libs remaining to be ported to uClinux.
Great help, crazyc!
I'm a bit worried on the driver.
first, the driver is designed for 2.6x kernel, but we are running on 2.4 currently, it might cause problem(now just failed to compile, I'm currently working on).
second, I'm not sure if sony ordered a customized WIFI chip from Marvell. At least, I can't trace any USB activities with the chip during the firmware accesses the WLAN.
first, the driver is designed for 2.6x kernel, but we are running on 2.4 currently, it might cause problem(now just failed to compile, I'm currently working on).
second, I'm not sure if sony ordered a customized WIFI chip from Marvell. At least, I can't trace any USB activities with the chip during the firmware accesses the WLAN.
Some random answers to the stuff asked here:
- WLAN chip firmware is accessed through hardware access to the WLAN and not through usb. wlanfirm_magpie contains, as crazyc said, the new WLAN firmware and its flashing (present from FW 2.6 iirc). It simply calls some function "sceWlanDrv_driver_E50312AB", which places the firmware update onto the list of commands to execute, or something like this.
- MS access is HELL. If you're motivated, try looking at sceMscm* stuff in mscm.prx module. This handles the hardware communication basics, and fatmsmod.prx actually does the filesystem related stuff. These drivers are loaded all the time and get unloaded only on reboot. (After which they reload)
to anybody: correct me if i'm wrong, but i shouldn't be. :)
- WLAN chip firmware is accessed through hardware access to the WLAN and not through usb. wlanfirm_magpie contains, as crazyc said, the new WLAN firmware and its flashing (present from FW 2.6 iirc). It simply calls some function "sceWlanDrv_driver_E50312AB", which places the firmware update onto the list of commands to execute, or something like this.
- MS access is HELL. If you're motivated, try looking at sceMscm* stuff in mscm.prx module. This handles the hardware communication basics, and fatmsmod.prx actually does the filesystem related stuff. These drivers are loaded all the time and get unloaded only on reboot. (After which they reload)
to anybody: correct me if i'm wrong, but i shouldn't be. :)
I traced the functionsc WlanDrv_driver_E50312AB but I cannot see it actually transmitting lots of data to the chip. Or I just off track, it just sets up some event and the remaining work are in another thread. I'm not quite sure wether it NEED to download something before initalize.
I'm acquiring license from sony to access Memory Stick related information on their site.
I'm acquiring license from sony to access Memory Stick related information on their site.
As I said before, I'm actually doing what you've said.I'm acquiring license from sony to access Memory Stick related information on their site.
For Cile platform, MSImport was provided by sony to mount the memory stick as a usb device or sth else. No source code is available. Linux devs just patch the linux kernel to support these kind of special device. We don't have direct control stack yet.
I have one of the usb-serial patch for Clle to support MSImport on my site.