PSPLINK

[optixx00]

Yes i have usbgdb enabled. Was using sio for shell and usb for hostfs. i tried to use only usb for shell and hostfs. but got the same problem.
Checked the thlist, server seems to run.

Code: Select all

<Thread List>
UID&#58; 0x0087BF13 - Name&#58; SceKernelModmgrWorker
UID&#58; 0x017EC803 - Name&#58; SceAudioMixer
UID&#58; 0x017E9207 - Name&#58; SceAudioInput
UID&#58; 0x017CFE47 - Name&#58; ScePowerMain
UID&#58; 0x017CB84D - Name&#58; ScePowerBattery
UID&#58; 0x01CD6835 - Name&#58; SceUmdManMount
UID&#58; 0x01CD123D - Name&#58; SceUmdManTask
UID&#58; 0x01CCDC41 - Name&#58; SceUmdManTaskSPKStop
UID&#58; 0x0283F70B - Name&#58; SceMScmMain
UID&#58; 0x0283C10F - Name&#58; SceMScmMedia
UID&#58; 0x0282E129 - Name&#58; SceFatmsDriver
UID&#58; 0x02829B31 - Name&#58; SceFatmsMedia
UID&#58; 0x02822C4F - Name&#58; SceMSstorSleep
UID&#58; 0x02812173 - Name&#58; SceWlanMac
UID&#58; 0x00206A69 - Name&#58; SceImpose
UID&#58; 0x044DB14D - Name&#58; PspLink
UID&#58; 0x044D4E43 - Name&#58; USBThread
UID&#58; 0x044C985B - Name&#58; PspLinkParse
UID&#58; 0x044BD323 - Name&#58; USBShell
UID&#58; 0x044B5B3F - Name&#58; GDBServer

[TyRaNiD]

Try going into gdbcommon/gdb-stub.c and uncomment the _DEBUG define at the top and rebuild, see what if any output you get.

[JiGGaK]

So I built my self a SIO cable and it works well (sioshell works fine). I would really like to debug remotely with gdb but for the life of me I can't get his going.

I have tried both OS X and Linux with similar results. I'm going to use my results on Linux since it sounds like most people are having success with linux.

Slackware 10.2, libusb 0.1.12, psplink0.9g, and a fresh build using the psp toolchain.

I am attempting to debug the sprite sample from the sdk. I have built with the -g flag and copied the elf over to the root of the MS. In psplink I have disabled the USB and WiFi shells, enabled the SIO shell, disabled USB host filling, and enabled USB debugging.

I start usbhostfs_pc -d, then run debug sprite.elf in the shell, then run psp-gdb sprite.elf and type target remote :10001 in gdb.

The output in usbhostfs_pc is:

• Accepting gdb connection from 127.0.0.1
  HOST->GDB (+$Hc-1#09)
  HOST->GDB ($Hc-1#09)
  HOST->GDB ($Hc-1#09)
  HOST->GDB ($Hc-1#09)
  HOST->GDB (-)
  HOST->GDB (-)
  HOST->GDB (-)
  HOST->GDB (+$qC#b4)
  HOST->GDB ($qC#b4)
  HOST->GDB ($qC#b4)
  HOST->GDB ($qC#b4)
  HOST->GDB (-)
  HOST->GDB (-)
  HOST->GDB (-)
  HOST->GDB (+$qOffsets#4b)
  HOST->GDB ($qOffsets#4b)
  HOST->GDB ($qOffsets#4b)
  HOST->GDB ($qOffsets#4b)
  HOST->GDB (-)
  HOST->GDB (-)
  HOST->GDB (-)
  HOST->GDB (+)
  Closing gdb connection

The output in gdb is:

• (gdb) target remote :10001
  Remote debugging using :10001
  Ignoring packet error, continuing...
  Ignoring packet error, continuing...
  Ignoring packet error, continuing...
  Malformed response to offset query, timeout

Nothing happens on the psp.

Any ideas?

Edit: For the hell of it, I grapped the source from svn for psplink and tried uncommenting the DEBUG define in gdb-stub.c. I followed the same procedure above again with nothing happening on the PSP. Similir output is displayed in usbhostfs_pc, and just cause I didn't want to fire up the linux box this is Mac OSX 10.4.6 with libusb 0.1.12 and I tried psplink h (whatever is lattest in svn).

Edit2: Ok, didn't feel like going to work today so I did some more tinkering. And wouldn't you know it, gdb is debugging like a champ. After setting usbhost=1 I started to get somewhere. In hindsight I guess this should have been obvious. I should also note that I got this working on my Linux box with a fresh copy of psplink from svn (and libusb 0.1.12). It still doesn't work in OS X but I have not given up yet!

[CheChin]

question. am i totally off here, or could you in theory use some kind of other usb storage device with this? like, connect a psp with a external hard drive / usb memory stick, using a male->female converter'? would that work?

[weltall]

if that device has a host chip, could work as host and is programmable

[waltrend2]

I also have the problem 2 other members here reported with gdb-psp:

(gdb) target remote :10001
Remote debugging using :10001
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Malformed response to offset query, timeout

Usbhost=1 as well as Usbgdb=1 are set in the ini-file on the psp, the GDBSERVER module is loaded...

A packetsniffer revealed that the psp returns six bytes of 00 on all three requests $Hc-1#09, $qC#b4, $qOffsets#4b, gdb just doesn't complain before getting the offset query reply 00 00 00 00 00 00...

Any ideas anyone?

[Shazz]

Sorry for the delay (and interrupting this GDB discussion...)

So here is a piece of code to demonstrate the issue between PSPLINK and LIBPNG (I tried various pieces of code, some by urchin... same result)

while loading a PNG from host, this step fails (works well from ms0) :

Code: Select all

	// block to handle libpng errors, then check whether the PNG file had a bKGD chunk
	if (setjmp(png_jmpbuf(pPngStruct))) 
	{
	   	png_destroy_read_struct(&pPngStruct, &pPngInfo, NULL);
	   	fclose(fp);
	
	   	return -5;
	}

Tyranid, you can download the sample here : http://tmpstore.free.fr/ps2dev/pngtest.zip

Urchin seems to use a different libpng source from ps2dev svn...

[TyRaNiD]

Shazz, okay I first ran this on my linux box and it worked perfectly, I am assuming displaying a picture was the intention, so I was willing to give it up ;) Okay so I thought I would try it on my xp laptop with a cygwin install, guess what it fails to load the picture with a read error.

So what you may be asking is the problem? Well seems on one of the lseeks it passes a crazy value to the function, in the order of 300billion or so, I get away with it on my linux box because I cast the int64 to off_t which happens to be 32bit on this machine, this trucates the top 32bits off the number and gives what I assume is the expected value, 8. However in cygwin it is 64bit so no truncation is actually done, this crazy value gets passed to lseek which proceeds to either barf or seek to this crazy value where libpng can no longer read more data from. I am making an assumption that mac osx also uses 64bit off_t.

Okay so as of yet I do not know where I can attribute blame, could be in a number of places, newlib, the compiler, libpng etc. However one thing I know is it doesn't seem to be a fault of usbhostfs directly. The lseek prototype is slightly crazy in that is shouldn't have the int unk1 bit there but that doesn't make a difference to the underlying ABI used to pass in 64bit values. On the mips it seems if you have the prototype (int fd, int64_t ofs) it passes fd in a0, and ofs split over a2 and a3 missing out a1 completely (which is why there is the unknown parameter in the prototype :) I apihooked lseek from user mode and the pngtest app is indeed passing bogus values into lseek so that narrows it down to something in the sdk.

So what can you do to fix it ? Well the quickest dirtiest trick you can use is on line 1231 of usbhostfs_pc's code change the cast of (off_t) LE64(cmd->ofs) to (int32_t) LE64(cmd->ofs) instead, that will crop the top 32bits off and it works, at least on my xp box. More tracing will have to be done to try and determine exactly what is causing the real underlying issue though.

Update. I think it is in some way related to psplink as doing an apihook when running it from ms doesn't exhibit this issue. Ill look further.

[Shazz]

Wow what a quick analysis :D

Update. I think it is in some way related to psplink as doing an apihook when running it from ms doesn't exhibit this issue. Ill look further.

That's what makes me wonder too where the problem is.... but for some other loading data from host works.... maybe libpng uses a different way to browse the file content...
I had some issue too with "fread", from host it freezes after some calls, I had to use sceIoRead instead and it solves the issue.

so maybe from newlib glue ?

[TyRaNiD]

Okay think I have found the problem :)

The prototype for the lseek fileio driver was returning an int when it should have been returning int64 so probably other apps which compiled against the pspsdk prototype (which did return int64) was picking up garbage with what ever was left in v1. Obviously this has only worked for so long cause on linux it always removed the top 32bits :)

Try it now, hopefully might fix a few issues.

[Shazz]

perfect.... thx for such a quick patch !

[JiGGaK]

Edit2: Ok, didn't feel like going to work today so I did some more tinkering. And wouldn't you know it, gdb is debugging like a champ. After setting usbhost=1 I started to get somewhere. In hindsight I guess this should have been obvious. I should also note that I got this working on my Linux box with a fresh copy of psplink from svn (and libusb 0.1.12). It still doesn't work in OS X but I have not given up yet!

As I said earlier, I was able to get remote debugging working using a Linux box but I really wanted to get it working from my PowerBook (I like being able to hack anywhere... like on the subway). Tried various different things but nothing seemed to help under Mac OS X so I decided the only way was to install Linux on my PowerBook.

So now I am dual booting Mac OS X and Gentoo. I figured after all of this it would just magically be working since it worked previously from an x86 Linux box but still doesn't work! Maybe a byte endian issue?

Kernel 2.6.17_rc5
libusb 0.1.12

Oh: and I was careful to compile usbhostfs_pc with BUILD_BIGENDIAN set. Actually I tried with this flag set and without, still no go.

Serves me right for buying a mac.

[groepaz]

mmmh never had a problem with making things work in gentoo on my powerbook.... i have to admit i didnt try libusb though :)

[JiGGaK]

mmmh never had a problem with making things work in gentoo on my powerbook.... i have to admit i didnt try libusb though :)

Groepaz... Are you using psplink's GDB server to debug or are you using psplink's built in debugging capabilities?

I can debug using the shell commands in psplink no problem from any platform. The issues I am having are related to remote debugging using GDB in particular.

[groepaz]

actually.... i use pspinside for what i am doing, not psplink :=P

[TyRaNiD]

It has been reported that gdb doesn't work on mac, however I thinking I "might" have worked out why ;) Seems I forget to endian swap the channel number when reading in GDB data. It will work fine for the shell as that uses channel 0 (which is obviously the same no matter what). Committed a fix, can you give it a try?

[JiGGaK]

Committed a fix, can you give it a try?

TyRaNiD... well it almost works! Unless I am doing something wrong.

I am attempting to debug the sprite sample, so I have added the -g flag to CFLAGS to compile in debug info. With your lattest source, psp-gdb doesn't complain about malformed packets anymore, but after attempting to start (with target remote :10001) psp-gdb spits out:

Code: Select all

Remote debugging using :10001
[New thread 0]
_start (args=0, argp=0x0) at crt0.c:105
105     crt0.c: No such file or directory.
        in crt0.c

This happens in both Linux and Mac OS X on my PowerBook, however, some modifications to source are required to get things to compile under Mac OS X (Apple, why must you be different?).

[TyRaNiD]

Well it will do that, you probably no longer have the source to pspsdk (could be considered a bug in psptoolchain). It should be okay though, just set a breakpoint on your main function (break main) and type c to continue and it should stop inside your code with source code. If you want source for those bits then rebuild pspsdk manually and keep the source code around. However do not step through crt0 anyway, it probably wont work and even if it does it might not work very well, blame sony for that little problem ;)

[ahman]

First, I would like to thank TyRaNiD for making such a wonderful debugging tool. I'm trying to include the usbhostfs functionality in iR Shell which will allow launching of homebrews from host0:. Full credit will be given when public release is out.

I've a question on the USB HostFS driver. I'm trying to use sceIoAssign to make host0: appears as ms0:, so that homebrews looking for ms0: can access files under host0. Can you let me know what's the block device name & the filesystem device name to be used when doing the sceIoAssign?

Another note, I found a possible bug in the USB HostFS driver. If I do a sceIoChdir and then do a sceIoRename to a file. The file will be renamed, but will also be moved to the root of usbhostfs_pc driver. It seems the driver didn't use the new changed directory for the target renamed file.

Thanks again for the excellent tool.

[TyRaNiD]

As host is a filesystem device there is no block device you can access, to map the root of host0 to ms0 you can do something like

Code: Select all

sceIoUnassign("ms0:");
sceIoAssign("ms0:", "host0:", NULL, IOASSIGN_RDWR, NULL, 0);

That will create an alias called ms0: for anything under host0:. Of course to map a lower level directory it is abit more difficult as you would need to remap it on the PC. Of course you could try and implement the mount IO call and send that information to the PC to remount the drive but I didn't implement that cause of the concern that someone could potentially remap the drive to anywhere on your filesystem and play tricks on you :)

As for the rename bug Ill try and have a look at it, was never convinced the PSP ever sent me the chdir request anyway but ill see.

[moonlight]

As host is a filesystem device there is no block device you can access, to map the root of host0 to ms0 you can do something like

Code: Select all

sceIoUnassign("ms0:");
sceIoAssign("ms0:", "host0:", NULL, IOASSIGN_RDWR, NULL, 0);

As for the rename bug Ill try and have a look at it, was never convinced the PSP ever sent me the chdir request anyway but ill see.

My tests tell me that the chdir of a io driver is not called :O
But... why is there?

[JiGGaK]

Well it will do that, you probably no longer have the source to pspsdk (could be considered a bug in psptoolchain). It should be okay though, just set a breakpoint on your main function (break main) and type c to continue and it should stop inside your code with source code. ...

Your right... simply continuing past the warning regarding the missing file works fine. Well this is awesome, it works on Mac now! :)

[ahman]

As host is a filesystem device there is no block device you can access, to map the root of host0 to ms0 you can do something like

Code: Select all

sceIoUnassign("ms0:");
sceIoAssign("ms0:", "host0:", NULL, IOASSIGN_RDWR, NULL, 0);

That will create an alias called ms0: for anything under host0:. Of course to map a lower level directory it is abit more difficult as you would need to remap it on the PC. Of course you could try and implement the mount IO call and send that information to the PC to remount the drive but I didn't implement that cause of the concern that someone could potentially remap the drive to anywhere on your filesystem and play tricks on you :)

Thanks! It's works like a charm.

As for the rename bug Ill try and have a look at it, was never convinced the PSP ever sent me the chdir request anyway but ill see.

It will be quite strange if the PSP doesn't send out the chdir request. This is 'cos I did a chdir to a sub-directory. Then, I issued a rename on a file in the sub-dir without the full path. The file in the directory actually got renamed which means the usbhostfs_pc driver were able to locate the file. But the renamed file had been moved to the root of usbhostfs_pc. Just trying to provide more information for your investigation. Thanks again for doing the hard work.

[TyRaNiD]

Okay ive done a quick few tests, firstly chdir doesn't get sent to the io device as pointed out, I cant remember what driver I reversed exactly which indicates that there was a chdir in there, perhaps it was going to be there but it never happened. So looking at rename it looks to be a sort of bug in the PSPs IO driver. It prefixes the first name with the threads current directory, however it doesn't prefix the second directory for what ever reason.

In psplink I never use sceIoChdir anyway cause it is somewhat unreliable and just easier to maintain my own current directory so I have never seen this issue. The ms driver must be doing something special to handle this case. A simplish fix is to assume that if the second name doesn't start with a / it must be relative to the first name, that would certainly fix it but it does seem odd that the IO driver doesn't do it itself. Stupid thing ;)

Ill try and fix it soon.

[TyRaNiD]

Okay fixed it, should work as you would expect now, hopefully no weird side effects ;)

Oh and for the truely lazy out there ive added an optional, simple readline shell to it. Gives you tab completion on directories and filenames, but not commands etc. You need to rebuild usbhostfs_pc with make READLINE_SHELL=1 to get it to work.

[ahman]

I've just tested the fix on Linux host and the rename is working perfectly. Thanks a lot for the quick fix. Your work is highly appreciated!

[Gendal]

Holy crap does this tool make my psp development easier. Thank you!

[Ghoti]

hmmm does anybody has a compiled executable for me? i can't seem to create one or find one, it will be alot of help because the usbhostfs_pc.exe provided with DAX doesn't seem to work :(

if it should what am i supposed to do with the file cause it will start but i can't seem to connect with the psplink system on my pc (no input is possible)

EDIT: i need the pcterm the other one works now but i have not the pcterm.exe, can somebody upload it?

[dot_blank]

when type 'make release' in psplink dir
everything is compiled for you ...including pcterm
which is in its proper dir ...if still you cant compile
i have already built binary ...but please do build
yourself to get yourself familiarized ...i dont like to
hold anyones hands :)

[Ghoti]

:) sorry but the problem is that i don't use cygwin :s i always use visual c++ for programming for the psp so i have not much experience with it and i have not that much time on my hands either but if you could send me the executable then i am very glad (bolleprog [at] hotmail [dot] com)