forums.ps2dev.org

[nullp01nter]

[TyRaNiD]

Damn that looks great, might have to build one myself. Few questions though, is the audio passed straight through (I assume it is)? And is it actually bus powered, i.e. would we even need to init the power from the SIO port to use it, if not that would cut 2 seconds off psplink reboot times ;)

Nice work.

[nullp01nter]

[TyRaNiD]

Have you actually tried to use psplink with the power init removed? If you edit sio.c in pspsdk and remove the last two function calls from pspDebugSioInit does it still work? If it does I'll be even more interested ;P

edit: Oh and what is driver support like for the usb chip? Need anything special?

[jimparis]

[crazyc]

I just made something similar out of a cell phone data cable from Radio Shack. It uses a Prolific PL2303 and outputs 3.3V on the TX line, seems to work fine with no pulldown. The same cable also works for SIO with a PS2. BTW, the remote connector is ~5 PCI pins wide :).

[xflash]

Hello,

A really great thanks for your job! PSPlink is indeed a "must have" for anyone who wants to test/debug those productions.
I'm Wifi powered. (My soldering skills are .... too old :) ), I met some problems with an SDL app I wrote. It's freezing, when I launch it with psplink, but works fine from Vsh.
No traces to give, SDL redirects them, and stdout.txt and stderr.txt are empty ?!?
Any idea?


xFlash

[bulb]

I have two issues with PSPLink.

1. Sometimes I can't exec ELF module that I have just copied. Usually I have to disable and reenable USB. Problems with buffer flushing?

2. Problems with file I/O that happen all the time. Whenever I write the file (from ELF module), it occupies size on the stick, but is nowhere to be found.

[NoHexPleaseI'mBritish]

Great piece of software, I can really see this speeding my development times up. The fact I can now actually see my printf statements alone is a major time-saver.

I have a couple of issues though, that could be me not doing something right, or maybe its just how PSPLink is.

Firstly, i'm using WiFi mode.

When I copy my .ELF over to the PSP, then type exec myapp.elf, it starts up on the PSP just fine.

If I type exec to re-execute the same file or exec anotherapp.elf then it restarts PSPlink, killing the wifi connection and USB. Then it starts the app while the wifi in PSPLink is still init'ing. In my PSPGL app this means nothing is visible and the psp buttons don't work, but I can still hear my background music playing. Also if I type reset then it goes to a black screen and freezes for about 20 seconds and then the PSP powers off.

I thought it might have been something in my app, so I tried with Hello World and get the same results.

Am I building my ELF's wrong or something?

[TyRaNiD]

bulb, there are issues with the use of usb and ms at the same time, there is no real way around that, that is just how the psp's drivers work. You are best to umount the usb drive and reset psplink (it will close usb on exit anyway) then rerun.

NoHexPleaseI'mBritish, I rarely use the exec command these days, I almost always use ld myfile.elf when I want to run a different executable once the shell comes up, exec works oki on sio but isn't so good on wifi as you have found out, if you need to pass complex arguments each time then either using pcterm (for a decent history) or create a script will suffice. As for the reset causing the psp to shut down I have seen this error before, it seems to be releated to having a kernel thread still running in user space. Absolutely no idea why it does this, it seems most likely to be a bug in the psp kernel somewhere, it gets itself stuck when resetting the system which then eventually kicks the watchdog off ;( Ensure your applications you are running are user mode only and that will fix the issue (but I know if you are running other apps this isn't always possible).

[TyRaNiD]

I have now added a version of GDB which runs over WIFI to PSPLINK. At the moment unfortunately it doesn't play nice with the WIFI shell for what ever reason so it is for SIO users only atm :( You will need to update newlib and pspsdk in order to use it (as usual :P)

With previous work from lovely2 the wifi GDB should be far better than previous versions, it is now a separate prx file which loads the debugee for you so you no longer need to use the inbuilt stub or for that matter kernel mode at all. It operates in a similar fashion to gdbserver does on *nix machines, you set it going with the "debug program.elf [args]" command in the shell then connect to it in GDB using the target remote command on port 6999.

Other improvements is it can now debug both ELF and PRX files and will handle the relocations as appropriate. I am going to try and implement threading support as well so you can manage the entire application from the PC which will be nice.

Anyway if you get a chance to test it obvisouly post any bug reports (and I am sure there will be some).

[optixx00]

Just got my SIO Cable working, but i can't start an elf. Any ideas.

[TyRaNiD]

I have seen this before and it is down to buffering issues between the USB mass storage and the ms driver. Whenever you copy across a new app unmount or disconnect the usb drive and reset PSPLINK. Then it should run fine.

[optixx00]

Thx, the reset did it. Oh man wonderful tool. This makes psp dev work like charm. Quick turn around times and give practical debugging support. Great !

Is there a trick to reinit the SIO connection on psp side , as i lost the connection e.g. after plugging the sio cable off. At the moment iam forced to do an hard reset, holding power button for seconds.

[TyRaNiD]

Unfortunately not, I haven't got around to doing some more reversing of the hprm driver to allow the SIO to reinit. Maybe sometime :)

[raf]

[sandberg]

TyRaNiD, there seems to be problems with compiling psplink against the lastest sdk ? You've made changes to the prototypes in pspusb.h, which requires sceUsbDeactivate to take the product ID for the default USB driver as an argument, like for sceUsbActivate. This causes psplink to give compiler errors.

Works fine when passing 0x168 as in the call to sceUsbActivate.
_________________
Br, Sandberg

[Orion_]

I tried with eboot loader 9 and wifi hack for 2.0 firmware and psplink don't work :/
should I get back to 1.5 firmware ?

[TyRaNiD]

psplink relies on kernel mode access so it only works on 1.0 and 1.5 firmware, sorry.

[Debug]

When I try to compile PSPLINK I get what seems like a pretty bad error:

[TyRaNiD]

you have got an old old toolchain build, you will need to update it to get it to build correctly.

[Debug]

I see, thanks. Unfortunately, I updated the toolchain from svn to make sure, then I ran ./toolchian.sh -p. It was going fine until here:

[Oobles]

Yes, you need to run the full toolchain script, not just the SDK. The operands are now part of GCC, so you need to rebuild it.

[TyRaNiD]

Okay this is going to need testing. I have added a USB based host filing system to PSPLINK, it uses libusb to communicate with the PSP from user mode, it claims to work on most *nix like systems though I have had issues with it before so this is a good time for people to try it ;) For info I run x86 linux on a 2.6 kernel, and it works fine for me. There is a libusb port for windows but lacking an easily accessible windows machine with dev tools on it I haven't yet tested it on that.

Brief description of how it works, you enable hostfs on the PSP by setting usbhost=1 in the psplink.ini file, you then run up a tool on your PC which uses libusb to communicate with the PSP and serve file data. It supports mapping upto 8 directories (and more if you change the PC side code define) so you can access different directories under host0 or host5 for example. All commands are supported, though devctl and ioctl have not been fully implemented yet, got some plans for those.

It wont like you blocking on the PC side read so no blocking sockets yet but for the most part it should do what people need in a host filing system.

I have tested with USB 1.1 and 2.0 and they both seem to work fine, 1.1 gets around 1Mb/s and 2 around 10Mb/s, so best plug it into a 2.0 host port ;)

Oh and final thing, if you are building on a big-endian machine (i.e. a mac) then make the PC side tool with 'make BUILD_BIGENDIAN=1', that will ensure all integer values are swapped around correctly, however I haven't tested it so YMMV.

Report any bugs to /dev/null, thx.

[TyRaNiD]

Update: I decided to try my hand at getting the hostfs to work on a windows box and I suceeded, so I thought I might as well post the info. You will need to build in cygwin as there are too many unixism for it to build correctly on vanilla win32 or mingw.

Download the latest snapshot of the libusb-win32 driver (not the filter driver) from libusb-win32.sourceforge.net. Extract to a directory.

Start up psplink with the hostfs driver enabled, Windows should try and install a driver, just ignore that for now. In the bin directory of libusb run inf-wizard, follow the instructions, select the PSP Type-B device, and choose the bin directory as your output. This should have produced a *.inf and *.cat file. Complete the windows driver installation but tell it you will specify the directory, point it at the bin directory and it should pick it up and install the driver.

Now copy include/usb.h and lib/gcc/libusb.a from the extracted directory and copy them into the usbhostfs_pc directory in cygwin.

Open up cygwin and navigate to the usbhostfs_pc directory, you will now need to edit a few bits.
Edit Makefile, add -I. to CFLAGS and then add the line LDFLAGS=-L.
Edit main.c, on line 1669 change the final parameter of euid_usb_bulk_read from 0 to INFINITE.
Type make and it should build. Then run as normal.

There is of course a caveat, seems that on linux bulk reads fail with a 0 byte read when the USB device is disconnected, but on Windows it doesn't seem to do anything at all, i can probably get around it by implementing a goodbye command from the USB device to tell the PC side it should shutdown, but then again that'll teach you for using Windows ;) the fix is obviously to shutdown the hostfs app once the psp has rebooted and rerun it.

[pspkrazy]

Amazing job.

Everyone can now use your debug tool with ease and power.

Great.

PS : Are you planning to make an usb shell ? It will be great for poeple like me who don't have a SIO cable (cause wifi sucks a little).

[TyRaNiD]

Probably, I have left in what I think I need to support a shell in the current driver, my main issue is really with implementing on the PC side, libusb doesn't seem the best thing for actually doing what I need it to do. Will look into it later.

[psx-frogger]

Hi Tyranid,

Thanks for this great tool.

I saw on the svn that the Pdf documentation is talking abouit version 0.9b.

Have you released the 0.9b version ?

Regards

Psx-frogger

[TyRaNiD]

Technically the subversion code is 0.9b, will probably not release a 0.9b until I have a USB shell and that will probably be 0.9c, or more depending what I feel like. For now just use the subversion version.

[johnmph]

Hello TyRaNiD, beautiful tool ;-)

In your find_syscall_addr function (apihook.c), you use a u32 pointer to access syscall table (u32 *syscalls) :