PS2 Open PS2 Loader v1.1.0

[jolek]

IGR in OPNPS2LD-180929.elf (https://www.sendspace.com/file/rpovrm) from here:
https://github.com/ifcaro/Open-PS2-Loader/pull/144#issuecomment-425639280,
seems to work also for me with all devices (USB\SMB\HDD).

Thanks!

Although I haven't checked VMC.

 

[Agrippa]

Hello!
I have to ask the developers of OPNPS2LD about the changes of the USB handling. The last working version is the r1073 one. Actually, I'm using the Maximus32's build available here:

https://github.com/rickgaiser/Open-PS2-Loader/releases

However, any version newer than that (the earliest I could find is r1079) doesn't work. Well, the program is able to load the list of USB games, but is not able to load the game itself. I've turned on the debug colours in settings and here is the colour sequence (with disabled IGR!!):

Pink -> Green (longer time on that one) -> Dark pink (magenta?) -> Golden.

WRC: Rally Evolved hangs on the last one, ICO shifts to black and hangs as well.

The colour sequence is the same as the one in the working build r1073.

I'm testing now r1179 version, but the symptoms are no different in any builds after the r1073 (I've tested 1079, 1081, 1094, 1096, 1108, 1140, 1174, 1180 and more).

My console model is the SCPH-77004. No cheats enabled or whatever. OPL loaded by coldbooted uLE 4.42

I'm looking forward to your response! Greetings to all developers really involved in OPL and PS2 development.

The problem is still unsolved as of r1191 version. What should I do to help fixing the thing?

 

[sp193]

There is no clear explanation as to why some people have issues with (certain) USB devices. I believe it is a hardware compatibility problem or our USBD module has some non-compliance with the USB spec.

If you are having issues with OPL waiting for the device to be detected, then you can try unplugging your device and connecting it back, once it seems to have not done anything for a while.

I used to have some issues with certain devices, back in 2011.

A problem with how you are referring to commits is that you are using builds and referring commits from different repositories, so it is nearly impossible to know what commits you are referring to unless you are specific with the repository. But even so, Github does not list the revision numbers, although there can be ways...

Git commits have hash values as their unique IDs. A commit may have different revision numbers across different repositories.

 

[Agrippa]

Ok, let me clarify some things.

There is no problem with detecting the USB HDD in OPL. Problem is with loading the game, as it hangs on the golden or black screen. In fact, I've tested the wLaunchELF build from 23rd July this year. As the changelog stated it has got new USBHDFSD module. The USB HDD also works with no problems (accessing, copying, etc.) If the OPL and wLE have got common USBHDFSD module then it shouldn't be problem with the module, am I right?

I'm not a programmer, but I've inspected the commits of the OPL. Since the problems have started somewhere with May-June time frame, I've found such a thing:

https://github.com/ifcaro/Open-PS2-Loader/commit/18780d5a2100dd2e0de73afe80f80275cc1b545c

Could it be the source of the problems? If someone would be able to provide me the build from this commit and the one preceding it, I could test it.

 

[sp193]

If the OPL and wLE have got common USBHDFSD module then it shouldn't be problem with the module, am I right?

Not really. OPL doesn't use the modules in the same way that normal software do. There's also this long-running problem, whereby something gets stuck during initialization of the USB device.
The PS2 has a CPU that is dedicated for I/O, known as the IOP. It provides an interface with the peripheraps, and so we load our software drivers on it. The IOP is also always reboot at the beginning of each program, so that compatible modules can be loaded in.

However, since we want to load a game from a USB device, this means that the USB device has to be accessible for the game's ELFs to be loaded. Which requires it to exist in memory during more of the PS2's boot phases. So the USB modules are loaded many times, repeatedly. If your device always had some potential issue with getting recognized, then the odds of getting stuck after a reboot is suddenly so much higher.

I'm not a programmer, but I've inspected the commits of the OPL. Since the problems have started somewhere with May-June time frame, I've found such a thing:

https://github.com/ifcaro/Open-PS2-Loader/commit/18780d5a2100dd2e0de73afe80f80275cc1b545c

Could it be the source of the problems? If someone would be able to provide me the build from this commit and the one preceding it, I could test it.

The recent changes were to relax the restriction on the transfer lengths, by breaking up transfers at the USB transfer function instead of at the SCSI layer; Transfers over USB are still restricted to units of 4KB, due to the USB 1.1 spec. So it's not really something new, but we're just doing things in a different order.

The code is also likely working fine, for probably a lot of other people. Otherwise, the situation should be reversed: we would probably find it incredibly difficult to find devices that will work reliably with the PS2, with the new software design.
Since the change most greatly affects long transfers, we should also expect long transfers (i.e.g file copying) to fail easily. But for reasons, it affects detection of games in OPL. I am not really sure what to make of this. It is not so easy to understand either, as OPL will also just display an empty list, upon encountering any I/O errors with the device.

For your case: if you use an older version of the USB driver code, you will probably be right to say that it'll work. But if it does, it likely starte dworking again, as a product of sheer coincidence. Especially if it is unrelated to this software issue.

There is no problem with detecting the USB HDD in OPL. Problem is with loading the game, as it hangs on the golden or black screen.

I'm suggesting that it might not really a freeze that you cannot work around.

But, you're free to believe what you want though. It is a fact that I have no direct solution for you and neither do I know why it happens, but I can only share my experience with some incompatible USB devices, with you. Maybe someday, somebody who can actually work with the USB spec can help to debug this properly.

The recent problems have different symptoms, so I don't think you are having the same problem. It seems like some people suddenly have issues with getting OPL to detect their USB device. It seems to affect some people and has no known way to work around. The interesting part is that it also seems to come and go, even when unrelated changes are made.

However, I cannot tell whether it is really a USB-related issue or an OPL issue. It's a bit sad, but a lot of bugs are auto-magically associated with OPL because it is one of the most popular pieces of PlayStation 2 software at the moment, although the PS2SDK is used for building PS2 homebrew software in general.
I'm certainly not affected, regardless of the PS2 models or USB device I use. And so, I have this feeling it might be hardware-related.

As for OPL getting stuck between IOP reboots: I did look into it in 2011: https://github.com/ps2dev/ps2sdk/issues/74
However, I don't know why we have some values. But yet the value I used in 2011 was found by trial and error, and is significantly higher than even the Sony value. So something else might be wrong, something I do not understand.
Until then, a workaround is to disconnect and reconnect the USB device.

 

[Agrippa]

Thank you very much for your comprehensive reply.

The recent changes were to relax the restriction on the transfer lengths, by breaking up transfers at the USB transfer function instead of at the SCSI layer; Transfers over USB are still restricted to units of 4KB, due to the USB 1.1 spec. So it's not really something new, but we're just doing things in a different order.

The code is also likely working fine, for probably a lot of other people. Otherwise, the situation should be reversed: we would probably find it incredibly difficult to find devices that will work reliably with the PS2, with the new software design.
Since the change most greatly affects long transfers, we should also expect long transfers (i.e.g file copying) to fail easily. But for reasons, it affects detection of games in OPL. I am not really sure what to make of this. It is not so easy to understand either, as OPL will also just display an empty list, upon encountering any I/O errors with the device.

This is what it does when I insert another USB stick. With new OPL and wLE revisions it displays nothing. Apparently, it works with OPL r1073 and uLE 4.42. Looks like I've got no luck.

For your case: if you use an older version of the USB driver code, you will probably be right to say that it'll work. But if it does, it likely starte dworking again, as a product of sheer coincidence. Especially if it is unrelated to this software issue.

Out of curiosity - is it a coincidence that the things stopped working somewhere after r1073? Have the USB driver update happened then?

But, you're free to believe what you want though. It is a fact that I have no direct solution for you and neither do I know why it happens, but I can only share my experience with some incompatible USB devices, with you. Maybe someday, somebody who can actually work with the USB spec can help to debug this properly.

It's not the matter of believing when it comes about the technology and engineering. I'm here not to believe but to understand. And I understand your point, as a developer of this software.

However, I cannot tell whether it is really a USB-related issue or an OPL issue. It's a bit sad, but a lot of bugs are auto-magically associated with OPL because it is one of the most popular pieces of PlayStation 2 software at the moment, although the PS2SDK is used for building PS2 homebrew software in general.
I'm certainly not affected, regardless of the PS2 models or USB device I use. And so, I have this feeling it might be hardware-related.

Of course it might. However, when it stopped working at the certain point of time I started thinking that the problem lies in software.

As for OPL getting stuck between IOP reboots: I did look into it in 2011: https://github.com/ps2dev/ps2sdk/issues/74
However, I don't know why we have some values. But yet the value I used in 2011 was found by trial and error, and is significantly higher than even the Sony value. So something else might be wrong, something I do not understand.
Until then, a workaround is to disconnect and reconnect the USB device.

I've tried to do this, when the device seems to hang up. It happens on a yellow/gold screen or black screen (after yellow). But the workaround doesn't work for me, unfortunately. Am I right, that the yellow screen is the last IOP reset?

 

[sp193]

This is what it does when I insert another USB stick. With new OPL and wLE revisions it displays nothing. Apparently, it works with OPL r1073 and uLE 4.42. Looks like I've got no luck.

So what exactly are you experiencing? Are you totally unable to use any disks?
If so, then it suddenly becomes more possible to do some tests on. Although I will likely not be able to make a new test during these few days, but we can do something if you are willing to.

Out of curiosity - is it a coincidence that the things stopped working somewhere after r1073? Have the USB driver update happened then?

I don't know which commit you're referring to by "r1073", but the USB drivers have been updated quite a few times. The commit you linked to above was one of the updates to the one within OPL in-game.
As for the PS2SDK side, which is used by OPL's GUI: https://github.com/ps2dev/ps2sdk/commits/master/iop/usb
So yes, it was June 8th, when most of those "breaking" commits were made.

It's not the matter of believing when it comes about the technology and engineering. I'm here not to believe but to understand. And I understand your point, as a developer of this software.

Thank you!

I've tried to do this, when the device seems to hang up. It happens on a yellow/gold screen or black screen (after yellow). But the workaround doesn't work for me, unfortunately. Am I right, that the yellow screen is the last IOP reset?

Yellow is set here. It's unfortunate, but you likely aren't having that older issue.
I'm not really sure how else you can get OPL to get stuck at yellow, unless you use VMC.

 

[Agrippa]

So what exactly are you experiencing? Are you totally unable to use any disks?
If so, then it suddenly becomes more possible to do some tests on. Although I will likely not be able to make a new test during these few days, but we can do something if you are willing to.

I've got two USB storage devices. First one, the 1TB USB HDD - two primary partitions - first is active 60GB FAT32, second is NTFS with the rest of space. The symptoms with new OPL releases is what I described before. (hanging up on yellow or black screen). The second one is just a generic 8GB USB flash disk (so slow and unstable, but compatible with all other devices such as PS3, or Bravia TV). The new OPL releases are not able to start the flash disk (after the manual starting, the list of games is empty). Anyway, I'm using mainly the USB HDD - the flash disk is just for the testing only.

I don't know which commit you're referring to by "r1073", but the USB drivers have been updated quite a few times. The commit you linked to above was one of the updates to the one within OPL in-game.
As for the PS2SDK side, which is used by OPL's GUI: https://github.com/ps2dev/ps2sdk/commits/master/iop/usb
So yes, it was June 8th, when most of those "breaking" commits were made.

Excuse me, I've made so much mess with the versions numbering. Let's forget about the old number as it was from different repository (Maximus32). Now I've found the r1060 from the ifcaro's one (commit 5f34603). Let's assume it's the last working version, as I'm not able to find slightly newer revisions than that to make some comparisons. Both USB devices are working with that version.

Yellow is set here. It's unfortunate, but you likely aren't having that older issue.
I'm not really sure how else you can get OPL to get stuck at yellow, unless you use VMC.

Nope, I'm not using the VMC. Every additional features are disabled during the testing, the IGR also.

 

[sp193]

I've got two USB storage devices.

Thank you for the clarification.

The second one is just a generic 8GB USB flash disk (so slow and unstable, but compatible with all other devices such as PS3, or Bravia TV). The new OPL releases are not able to start the flash disk (after the manual starting, the list of games is empty).

Am I correct to say that this same device is the one that will not have any content listed, if you tried to access it with new LaunchELF versions?
If so, could you please try to see if this LaunchELF modification will allow the contents to be listed? Previously, we just assumed that up to 4096 bytes are transferred, for every completed transfer. Now, we rely on what the USBD module reports. So this build has a modified USBHDFSD module that will use the older method of tracking the transferred data progress on its own.

The reason why nothing was done about this issue, was because the old tests had contradicting results and hence everything ended up being inconclusive. We can start over, although I cannot guarantee that there will be any difference.

I remember we tried to limit transfer lengths at the SCSI layer to 4KB (the original limitation), replace the FAT driver with the old version, as well as trying to hardcode the transferred data length (which is what we're trying now). But nothing helped, except for rolling back everything, which defeats the purpose of any of the changes made in the first place.

Nope, I'm not using the VMC. Every additional features are disabled during the testing, the IGR also.

Then are you sure it's not orange, but yellow? I think it's more likely you saw the orange screen instead, which would mean it got stuck during the 2nd IOP reboot, when the game tries to use its own IOPRP image.

For this HDD enclosure, I suspect it might have issues with transfers longer than 32768. Linux has a workaround for some devices, by limiting the transfer length to 32KB (64 sectors), but we have no such device black list. Hence it is perhaps preferable to restrict the maximum transfer lengths for all devices instead: https://www.sendspace.com/file/ocefjl

 

[Agrippa]

Am I correct to say that this same device is the one that will not have any content listed, if you tried to access it with new LaunchELF versions?
If so, could you please try to see if this LaunchELF modification will allow the contents to be listed? Previously, we just assumed that up to 4096 bytes are transferred, for every completed transfer. Now, we rely on what the USBD module reports. So this build has a modified USBHDFSD module that will use the older method of tracking the transferred data progress on its own.

The reason why nothing was done about this issue, was because the old tests had contradicting results and hence everything ended up being inconclusive. We can start over, although I cannot guarantee that there will be any difference.

I remember we tried to limit transfer lengths at the SCSI layer to 4KB (the original limitation), replace the FAT driver with the old version, as well as trying to hardcode the transferred data length (which is what we're trying now). But nothing helped, except for rolling back everything, which defeats the purpose of any of the changes made in the first place.

Yes, you're correct, it won't. But with the modification you have submitted, there are no changes - it still doesn't list the contents.

Then are you sure it's not orange, but yellow? I think it's more likely you saw the orange screen instead, which would mean it got stuck during the 2nd IOP reboot, when the game tries to use its own IOPRP image.

For this HDD enclosure, I suspect it might have issues with transfers longer than 32768. Linux has a workaround for some devices, by limiting the transfer length to 32KB (64 sectors), but we have no such device black list. Hence it is perhaps preferable to restrict the maximum transfer lengths for all devices instead:

Yeah right, it's the orange, like the one on the bottom of the Armenian flag. But again, your modification changed nothing. The symptoms are the same.

Some details of the USB devices I have got. 8GB USB flash disk:

USB Device ID: VID = 058F PID = 6387

Device Vendor: Generic
Device Name: Mass Storage
Device Revision: 0103

Manufacturer: Generic
Product Model: Flash Disk
Product Revision: 8.07

Controller Vendor: Alcor Micro
Controller Part-Number: SC908AN/AU6989AN [E603] - F/W D827
Flash ID code:  45DE9892 - SanDisk SDTNRCAMA-008G - 1CE/Single Channel [TLC-8K] -> Total Capacity = 8GB

USB hard disk:

USB Device ID: VID = 152D PID = 2539

Device Vendor: Jmicron Corp.
Device Name: Usb production
Device Revision: 0100

Manufacturer: ST1000LM
Product Model: 024 HN-M101MBB
Product Revision: 0000

Controller Part-Number: Unknown

Unfortunately, it doesn't retrieve exact model of USB-SATA chipset. :/

 

[sp193]

Yes, you're correct, it won't. But with the modification you have submitted, there are no changes - it still doesn't list the contents.

Sorry, but could you please clarify something? What does not list the contents? Is it LaunchELF that will list nothing, or OPL? Or both?

If it is only OPL, please try this custom copy of OPL: https://www.sendspace.com/file/lbz9l6
For at least this time, we can use the same test for the two disks.

Some details of the USB devices I have got. 8GB USB flash disk:

I didn't think it would help, but there were some matches in the Linux unusual device list. Thanks!

USB Device ID: VID = 058F PID = 6387

Device Vendor: Generic
Device Name: Mass Storage
Device Revision: 0103

Manufacturer: Generic
Product Model: Flash Disk
Product Revision: 8.07

Controller Vendor: Alcor Micro
Controller Part-Number: SC908AN/AU6989AN [E603] - F/W D827
Flash ID code:  45DE9892 - SanDisk SDTNRCAMA-008G - 1CE/Single Channel [TLC-8K] -> Total Capacity = 8GB

I realized that I entered the wrong number for limiting the transfer length. I entered 32768 instead of 64 (sectors of 512B).

Linux seems to have a workaround for a similar device with the same VID and PID: https://elixir.bootlin.com/linux/latest/source/drivers/usb/storage/unusual_devs.h#L764. This should work now.

USB hard disk:

USB Device ID: VID = 152D PID = 2539

Device Vendor: Jmicron Corp.
Device Name: Usb production
Device Revision: 0100

Manufacturer: ST1000LM
Product Model: 024 HN-M101MBB
Product Revision: 0000

Controller Part-Number: Unknown

For this test, I am setting a minimum transfer length by using the cache functions if the FAT driver requests less than 4096 bytes. This was another thing that became possible, once extended reads/writes became possible - since the cache would generally not be used for reading/writing files.
However, it likely wouldn't have made a difference for LaunchELF, which is why I needed you to clarify whether the issue with not listing anything was only with OPL, or with both OPL and LaunchELF.

Unfortunately, it doesn't retrieve exact model of USB-SATA chipset. :/

Unless it is well sealed up or you do not want to open it, you could open it up to look at the device.
But I probably don't have the same chipset used in any device, given how I could never replicate this bug.

 

[Agrippa]

Sorry, but could you please clarify something? What does not list the contents? Is it LaunchELF that will list nothing, or OPL? Or both?

If it is only OPL, please try this custom copy of OPL: https://www.sendspace.com/file/lbz9l6
For at least this time, we can use the same test for the two disks.

USB 8GB flash disk:
ULE-fixed-4K: doesn't list the contents of the drive (empty mass:/),
OPNPS2LD-32KB: doesn't list the games after starting the device (no sign of loading on the bottom-right part of the screen),
OPNPS2LD-181012: doesn't list the games after starting the device (no sign of loading on the bottom-right part of the screen).

USB Hard Disk:
ULE-fixed-4K: lists the contents of the drive,
OPNPS2LD-32KB: games are listed, loading hangs on the orange/black screen (depends on game), no HDD activity after that,
OPNPS2LD-181012: games are listed, loading hangs on the orange/black screen (depends on game), no HDD activity after that.

For this test, I am setting a minimum transfer length by using the cache functions if the FAT driver requests less than 4096 bytes. This was another thing that became possible, once extended reads/writes became possible - since the cache would generally not be used for reading/writing files.
However, it likely wouldn't have made a difference for LaunchELF, which is why I needed you to clarify whether the issue with not listing anything was only with OPL, or with both OPL and LaunchELF.

Some info about the file system on the devices:
Flash Disk:
bytes per sector - 512,
cluster size - 8 sectors, 4096 bytes

Hard Disk:
bytes per sector - 4096
cluster size - 8 sectors, 32768 bytes

Unless it is well sealed up or you do not want to open it, you could open it up to look at the device.
But I probably don't have the same chipset used in any device, given how I could never replicate this bug.

Unfortunately, there is not even one screw on the case. I can't open it.

 

[jolek]

I don't know if I can help, but I also have 2 flashdrives that are not fully compatible with OPL and with some PS2 homebrew.
First is very old... K k Kingson 2GB DTI (with 4,00 KB\4 096 bytes cluster):

My PHAT PS2 hates it (have many problems with it).

"Works" with probably most of the wLe\uLe commits.
OPNPS2LD-32KB: games are listed, BSOD after last debug color.
OPNPS2LD-181012: games are listed, BSOD after last debug color.
The same situation is with r1193.

Second is INTENSO Alu Line, 64 GB (with 32,0 KB\32 768 bytes cluster size):

Doesn't work with ULE-fixed-4K, wLe 23/07/2018 (doesn't list the contents of the drive).
Doesn't work with OPL (tested only r1193, OPNPS2LD-181012, OPNPS2LD-32KB) -
doesn't list the games after starting the device

I also have tried OPNPS2LD-181012, OPNPS2LD-32KB with other flash drives.
Games seems to boots without any problem.

 

[sp193]

USB 8GB flash disk:
ULE-fixed-4K: doesn't list the contents of the drive (empty mass:/),
OPNPS2LD-32KB: doesn't list the games after starting the device (no sign of loading on the bottom-right part of the screen),
OPNPS2LD-181012: doesn't list the games after starting the device (no sign of loading on the bottom-right part of the screen).

How strange. So it might be having issues with even getting detected.
Are you able to connect your PS2 to your network (or directly to your PC), so that some log messages can be gathered? If so, I can come up with some test for printing what USBHDFSD does when it detects this USB device.
What OS are you using?

USB Hard Disk:
ULE-fixed-4K: lists the contents of the drive,
OPNPS2LD-32KB: games are listed, loading hangs on the orange/black screen (depends on game), no HDD activity after that,
OPNPS2LD-181012: games are listed, loading hangs on the orange/black screen (depends on game), no HDD activity after that.



Some info about the file system on the devices:
Flash Disk:
bytes per sector - 512,
cluster size - 8 sectors, 4096 bytes

Hard Disk:
bytes per sector - 4096
cluster size - 8 sectors, 32768 bytes

Advance Format Disks seem to normally support emulation of 512 bytes per sector. Even if they really have 4096 bytes per sector.
But in case your enclosure advertises a larger (logical) sector size like 4096 (for compatibility with higher capacities beyond 2TB, for example), then please try this: https://www.sendspace.com/file/i0fvzu
I have limited the maximum transfer length in-game to 1.

Unfortunately, there is not even one screw on the case. I can't open it.

That's okay. Thanks though!

I don't know if I can help, but I also have 2 flashdrives that are not fully compatible with OPL and with some PS2 homebrew.
First is very old... K k Kingson 2GB DTI (with 4,00 KB\4 096 bytes cluster):

Yes, you can help too. Especially once we find some potential fix for this, you can help us to cross-verify if it is applicable for your devices.

Although filesystems have a cluster size, we don't actually follow the cluster size for the cache system or for data transfers, other than using it as a unit of space allocation.
For example, the scache.c file of USBHDFSD will always cache sectors in units of 4096 bytes, regardless of what your cluster size is. So if you have 512-byte sectors, then 1 cache block will contain 4096/512 = 8 sectors. If you have 4096-byte sectors, than 1 cache block will contain 4096/4096 = 1 sector.

My PHAT PS2 hates it (have many problems with it).

Does this mean that your slim PS2 has totally no problems with it?
For some reason, the slim and fat PS2s give slightly different behaviour when it comes to USB...
Like how FMCB would boot faster on a slim PS2, when USB drivers are available.

Second is INTENSO Alu Line, 64 GB (with 32,0 KB\32 768 bytes cluster size):


Doesn't work with ULE-fixed-4K, wLe 23/07/2018 (doesn't list the contents of the drive).
Doesn't work with OPL (tested only r1193, OPNPS2LD-181012, OPNPS2LD-32KB) -
doesn't list the games after starting the device

I also have tried OPNPS2LD-181012, OPNPS2LD-32KB with other flash drives.
Games seems to boots without any problem.

Likewise, if I were to make a test that prints debug messages from the PS2 to the PC, will you be willing to help test it?

 

[jolek]

Does this mean that your slim PS2 has totally no problems with it?

Well, you know some typical Kingson issues.

For some reason, the slim and fat PS2s give slightly different behaviour when it comes to USB...
Like how FMCB would boot faster on a slim PS2, when USB drivers are available.

Even FMV performance in games. With slim console i'm getting almost smooth playback.
With PHAT...
Maybe we need to burn some fat in that PHAT console(s)?

Likewise, if I were to make a test that prints debug messages from the PS2 to the PC, will you be willing to help test it?

YOU NEED LAB RATS!!!
OKEY! I'M IN!

Maybe these tests will also helps somehow to improve compatibility\performance
with PHATs.

Although, during workdays I'm out of home, so I have only slim next to me.
During weekend, I can do a test with phat.

What OS you've got in mind?
On both PC I've Win XP, Win 10\Linux mint 19 only @ home.

EDIT: with limited transfer length in-game to 1 ("OPNPS2LD-181014-1sector.elf") games and performance is quite slow.
Tried with flash disks that so far doesn't have any major problem with OPL.
With "incompatible" flash drives still the symptoms are as they were before.
No game list or BSOD after debug colors.

 

[sp193]

So for those disks that suddenly could not have their contents listed after June 8th 2018, please download this package and follow these instructions.

1. Copy usbtest.elf to a place where you can launch it on the PlayStation 2.
2. Copy planetty/planetty.exe to your PC.
3. Run usbtest.elf on the PlayStation 2.
4. Start planetty, specifying the IP address of the PlayStation 2. Redirect the output to a file, for easy submission. For example, if your PS2 is at 192.168.0.182: planetty 192.168.0.182 > result.log
5. Press the START button when prompted, to begin the test.
6. The software will load the USB modules and wait for 10s, before listing the contents of the USB disk.
7. Break the output of planetty with CTRL+C.

usbtest.elf will use your IP configuration in mc:/SYS-CONF/IPCONFIG.DAT.
If IPCONFIG.DAT is absent, it will attempt to use DHCP.
The IP address obtained will be displayed on the screeen.

If you have issues with getting planetty to capture log messages from the PlayStation 2, you may need to disable your firewall (e.g. Windows Firewall).

Sample output:

D:\>planetty.exe 192.168.0.182
FreeUsbd v.0.1.2
USB HDD FileSystem Driver v1.6
USBHDFSD: registerDriver=0
USBHDFSD: probe: devId=2
USBHDFSD: mass_stor_findDevice devId 2
USBHDFSD: bNumInterfaces 1
USBHDFSD: bInterfaceClass 8 bInterfaceSubClass 6 bInterfaceProtocol 50
USBHDFSD: connect: devId=2
USBHDFSD: mass_stor_findDevice devId 2
USBHDFSD: register Input endpoint id =1 addr=81 packetSize=64
USBHDFSD: register Output endpoint id =2 addr=02 packetSize=64
USBHDFSD: connect ok: epI=1, epO=2
Listing contents of mass0:/...
USBHDFSD: configuring devices...
USBHDFSD: setting configuration controlEp=0, confNum=1
USBHDFSD: callback: res 0, bytes 0, arg 1f7c50
USBHDFSD: setting interface controlEp=0, interface=0 altSetting=0
USBHDFSD: callback: res 0, bytes 0, arg 1f7c50
USBHDFSD: mass_stor_warmup
USBHDFSD: callback: res 0, bytes 1, arg 1f7bc0
USBHDFSD: usb_bulk_get_max_lun 0
USBHDFSD: cbw_scsi_inquiry
USBHDFSD: callback: res 0, bytes 31, arg 1f7bd8
USBHDFSD: callback: res 0, bytes 13, arg 1f7ba8
USBHDFSD: bulk csw result: 0, csw.status: 0
USBHDFSD: Vendor: SanDisk
USBHDFSD: Product: Cruzer Fit
USBHDFSD: Revision: 1.22
USBHDFSD: cbw_scsi_test_unit_ready
USBHDFSD: callback: res 0, bytes 31, arg 1f7bd8
USBHDFSD: callback: res 0, bytes 13, arg 1f7ba8
USBHDFSD: bulk csw result: 0, csw.status: 0
USBHDFSD: cbw_scsi_read_capacity
USBHDFSD: callback: res 0, bytes 31, arg 1f7bd8
USBHDFSD: callback: res 0, bytes 13, arg 1f7ba8
USBHDFSD: bulk csw result: 0, csw.status: 0
USBHDFSD: sectorSize 512 maxLBA 15633407
USBHDFSD: cbw_scsi_read_sector - 0x00000000 fab00 0x0008
USBHDFSD: callback: res 0, bytes 31, arg 1f7b78
USBHDFSD: callback: res 0, bytes 13, arg 1f7b48
USBHDFSD: bulk csw result: 0, csw.status: 0
USBHDFSD: boot signature 55 AA
USBHDFSD: cbw_scsi_read_sector - 0x00000800 fab00 0x0008
USBHDFSD: callback: res 0, bytes 31, arg 1f7b50
USBHDFSD: callback: res 0, bytes 13, arg 1f7b20
USBHDFSD: bulk csw result: 0, csw.status: 0
USBHDFSD: Fat type 32 Id FAT32
USBHDFSD: cbw_scsi_read_sector - 0x000010f8 fab00 0x0008
USBHDFSD: callback: res 0, bytes 31, arg 1f7a18
USBHDFSD: callback: res 0, bytes 13, arg 1f79e8
USBHDFSD: bulk csw result: 0, csw.status: 0
USBHDFSD: cbw_scsi_read_sector - 0x00008800 fab00 0x0008
USBHDFSD: callback: res 0, bytes 31, arg 1f7aa8
USBHDFSD: callback: res 0, bytes 13, arg 1f7a78
USBHDFSD: bulk csw result: 0, csw.status: 0
  HDLGameInstaller
  4b3b3dbae597f3ffdf8ba403a36f194f.png
  28055cc2-s.jpg
  4489500.jpg
  51251385_p0.jpg
  57998015_p0.jpg
  [181014]usbtest.7z
  usbtest.elf

Well, you know some typical Kingson issues.

But who knows what the problem really is. Sony also made mistakes, which probably caused software that use USB to become a little more complicated.

Even FMV performance in games. With slim console i'm getting almost smooth playback.
With PHAT...
Maybe we need to burn some fat in that PHAT console(s)?

lollol.

YOU NEED LAB RATS!!!
OKEY! I'M IN!

Thanks!

Although, during workdays I'm out of home, so I have only slim next to me.
During weekend, I can do a test with phat.

Likewise, I have no PS2s with me during the week.

What OS you've got in mind?
On both PC I've Win XP, Win 10\Linux mint 19 only @ home.

I knew you use Windows, but I think @Agrippa uses Linux.
Anyway, I have included ports of planetty for both Linux and Windows.

EDIT: with limited transfer length in-game to 1 ("OPNPS2LD-181014-1sector.elf") games and performance is quite slow.
Tried with flash disks that so far doesn't have any major problem with OPL.
With "incompatible" flash drives still the symptoms are as they were before.
No game list or BSOD after debug colors.

Yes, it'll be very slow. But the purpose was to determine if @Agrippa's USB enclosure was having issues with long transfers
So for the rest who have devices that cannot be detected at all, this will do nothing.

 

[Agrippa]

Advance Format Disks seem to normally support emulation of 512 bytes per sector. Even if they really have 4096 bytes per sector.
But in case your enclosure advertises a larger (logical) sector size like 4096 (for compatibility with higher capacities beyond 2TB, for example), then please try this: https://www.sendspace.com/file/i0fvzu
I have limited the maximum transfer length in-game to 1.

The second partition on the USB HDD is the NTFS one, so I'm able to run the "fsutil fsinfo ntfsinfo" command. It says:

Bytes per sector: 4096
Bytes per physical sector: Not Supported

So, it doesn't look like it supports 512 bytes emulation (of course it could be enclosure specific behaviour). For example, my PC HDD shows:

Bytes per sector: 512
Bytes per physical sector: 4096

Anyway, I've tried this build and there's still the same hanging on the last screen.

Although filesystems have a cluster size, we don't actually follow the cluster size for the cache system or for data transfers, other than using it as a unit of space allocation.
For example, the scache.c file of USBHDFSD will always cache sectors in units of 4096 bytes, regardless of what your cluster size is. So if you have 512-byte sectors, then 1 cache block will contain 4096/512 = 8 sectors. If you have 4096-byte sectors, than 1 cache block will contain 4096/4096 = 1 sector.

Ok, so the cluster size shouldn't matter, looks like.

I knew you use Windows, but I think @Agrippa uses Linux.
Anyway, I have included ports of planetty for both Linux and Windows.

No, I'm Windows user too.

Yes, it'll be very slow. But the purpose was to determine if @Agrippa's USB enclosure was having issues with long transfers
So for the rest who have devices that cannot be detected at all, this will do nothing.

As I've written before, it changed nothing. But I've tested both devices using your test file, for the sake of clarity. Here are the results:

USB HDD:

FreeUsbd v.0.1.2

USB HDD FileSystem Driver v1.6

USBHDFSD: registerDriver=0 

USBHDFSD: probe: devId=2

USBHDFSD: mass_stor_findDevice devId 2

USBHDFSD: bNumInterfaces 1

USBHDFSD: bInterfaceClass 8 bInterfaceSubClass 6 bInterfaceProtocol 50

USBHDFSD: connect: devId=2

USBHDFSD: mass_stor_findDevice devId 2

USBHDFSD: register Input endpoint id =1 addr=81 packetSize=64

USBHDFSD: register Output endpoint id =2 addr=02 packetSize=64

USBHDFSD: connect ok: epI=1, epO=2 

Listing contents of mass0:/...
USBHDFSD: configuring devices... 

USBHDFSD: setting configuration controlEp=0, confNum=1 

USBHDFSD: callback: res 0, bytes 0, arg 1f7c50 

USBHDFSD: setting interface controlEp=0, interface=0 altSetting=0

USBHDFSD: callback: res 0, bytes 0, arg 1f7c50 

USBHDFSD: mass_stor_warmup

USBHDFSD: callback: res 0, bytes 1, arg 1f7bc0 

USBHDFSD: usb_bulk_get_max_lun 0

USBHDFSD: cbw_scsi_inquiry

USBHDFSD: callback: res 0, bytes 31, arg 1f7bd8 

USBHDFSD: callback: res 0, bytes 13, arg 1f7ba8 

USBHDFSD: bulk csw result: 0, csw.status: 0

USBHDFSD: Vendor: ST1000LM

USBHDFSD: Product: 024 HN-M101MBB  

USBHDFSD: Revision: 0000

USBHDFSD: cbw_scsi_test_unit_ready

USBHDFSD: callback: res 0, bytes 31, arg 1f7bd8 

USBHDFSD: callback: res 0, bytes 13, arg 1f7ba8 

USBHDFSD: bulk csw result: 0, csw.status: 0

USBHDFSD: cbw_scsi_read_capacity

USBHDFSD: callback: res 0, bytes 31, arg 1f7bd8 

USBHDFSD: callback: res 0, bytes 13, arg 1f7ba8 

USBHDFSD: bulk csw result: 0, csw.status: 0

USBHDFSD: sectorSize 4096 maxLBA 244190645

USBHDFSD: cbw_scsi_read_sector - 0x00000000 fab00 0x0001

USBHDFSD: callback: res 0, bytes 31, arg 1f7b78 

USBHDFSD: callback: res 0, bytes 13, arg 1f7b48 

USBHDFSD: bulk csw result: 0, csw.status: 0

USBHDFSD: boot signature 55 AA

USBHDFSD: cbw_scsi_read_sector - 0x00000100 fab00 0x0001

USBHDFSD: callback: res 0, bytes 31, arg 1f7b50 

USBHDFSD: callback: res 0, bytes 13, arg 1f7b20 

USBHDFSD: bulk csw result: 0, csw.status: 0

USBHDFSD: Fat type 32 Id FAT32   

USBHDFSD: cbw_scsi_read_sector - 0x00000120 fab00 0x0001

USBHDFSD: callback: res 0, bytes 31, arg 1f7a18 

USBHDFSD: callback: res 0, bytes 13, arg 1f79e8 

USBHDFSD: bulk csw result: 0, csw.status: 0

USBHDFSD: cbw_scsi_read_sector - 0x00001020 fab00 0x0001

USBHDFSD: callback: res 0, bytes 31, arg 1f7aa8 

USBHDFSD: callback: res 0, bytes 13, arg 1f7a78 

USBHDFSD: bulk csw result: 0, csw.status: 0

   ART
   CD
   CFG
   CFG-DEV
   CHT
   DVD
   THM
   VMC
   ULE-fixed-4K.elf
   OPNPS2LD-32KB.ELF
   OPNPS2LD-181012.ELF
   usbtest.elf
   OPNPS2LD-181014-1sector.elf

USB Flash Disk:

FreeUsbd v.0.1.2

USB HDD FileSystem Driver v1.6

USBHDFSD: registerDriver=0 

USBHDFSD: probe: devId=2

USBHDFSD: mass_stor_findDevice devId 2

USBHDFSD: bNumInterfaces 1

USBHDFSD: bInterfaceClass 8 bInterfaceSubClass 6 bInterfaceProtocol 50

USBHDFSD: mass_stor_findDevice devId 2

USBHDFSD: register Output endpoint id =1 addr=01 packetSize=64

USBHDFSD: register Input endpoint id =2 addr=82 packetSize=64

USBHDFSD: connect ok: epI=2, epO=1 

Listing contents of mass0:/...
USBHDFSD: configuring devices... 

USBHDFSD: setting configuration controlEp=0, confNum=1 

USBHDFSD: callback: res 0, bytes 0, arg 1f7c50 

USBHDFSD: setting interface controlEp=0, interface=0 altSetting=0

USBHDFSD: callback: res 4, bytes 0, arg 1f7c50 

USBHDFSD: Error - sending set_interface 4

Unable to open mass0:/ - -19

 

[jolek]

So for those disks that suddenly could not have their contents listed after June 8th 2018, please download this package and follow these instructions.

1. Copy usbtest.elf to a place where you can launch it on the PlayStation 2.
2. Copy planetty/planetty.exe to your PC.
3. Run usbtest.elf on the PlayStation 2.
4. Start planetty, specifying the IP address of the PlayStation 2. Redirect the output to a file, for easy submission. For example, if your PS2 is at 192.168.0.182: planetty 192.168.0.182 > result.log
5. Press the START button when prompted, to begin the test.
6. The software will load the USB modules and wait for 10s, before listing the contents of the USB disk.
7. Break the output of planetty with CTRL+C.

usbtest.elf will use your IP configuration in mc:/SYS-CONF/IPCONFIG.DAT.
If IPCONFIG.DAT is absent, it will attempt to use DHCP.
The IP address obtained will be displayed on the screeen.

If you have issues with getting planetty to capture log messages from the PlayStation 2, you may need to disable your firewall (e.g. Windows Firewall).

Thanks for instruction.

For those that having problems with making "IPCONFIG.DAT",
here is a small example:
PS2_IP Netmask Gateway
e.g:
192.168.0.10 255.255.255.0 192.168.0.1
Exemplary file can be download from the attachment.

BTW does the " > result.log" has to be at the of the "planetty"
in widows cmd:

planetty.exe 192.168.0.10 > result.log

kingstone result.log:

FreeUsbd v.0.1.2
USB HDD FileSystem Driver v1.6
USBHDFSD: registerDriver=0
USBHDFSD: probe: devId=1
USBHDFSD: mass_stor_findDevice devId 1
USBHDFSD: bNumInterfaces 1
USBHDFSD: bInterfaceClass 8 bInterfaceSubClass 6 bInterfaceProtocol 50
USBHDFSD: connect: devId=1
USBHDFSD: mass_stor_findDevice devId 1
USBHDFSD: register Input endpoint id =1 addr=81 packetSize=64
USBHDFSD: register Output endpoint id =2 addr=02 packetSize=64
USBHDFSD: connect ok: epI=1, epO=2
Listing contents of mass0:/...
USBHDFSD: configuring devices...
USBHDFSD: setting configuration controlEp=0, confNum=1
USBHDFSD: callback: res 0, bytes 0, arg 1f7c50
USBHDFSD: setting interface controlEp=0, interface=0 altSetting=0
USBHDFSD: callback: res 0, bytes 0, arg 1f7c50
USBHDFSD: mass_stor_warmup
USBHDFSD: callback: res 0, bytes 1, arg 1f7bc0
USBHDFSD: usb_bulk_get_max_lun 0
USBHDFSD: cbw_scsi_inquiry
USBHDFSD: callback: res 0, bytes 31, arg 1f7bd8
USBHDFSD: callback: res 0, bytes 13, arg 1f7ba8
USBHDFSD: bulk csw result: 0, csw.status: 0
USBHDFSD: Vendor: Kingston
USBHDFSD: Product: DataTraveler 2.0
USBHDFSD: Revision: 1.00
USBHDFSD: cbw_scsi_test_unit_ready
USBHDFSD: callback: res 0, bytes 31, arg 1f7bd8
USBHDFSD: callback: res 0, bytes 13, arg 1f7ba8
USBHDFSD: bulk csw result: 0, csw.status: 0
USBHDFSD: cbw_scsi_read_capacity
USBHDFSD: callback: res 0, bytes 31, arg 1f7bd8
USBHDFSD: callback: res 0, bytes 13, arg 1f7ba8
USBHDFSD: bulk csw result: 0, csw.status: 0
USBHDFSD: sectorSize 512 maxLBA 3987455
USBHDFSD: cbw_scsi_read_sector - 0x00000000 fab00 0x0008
USBHDFSD: callback: res 0, bytes 31, arg 1f7b78
USBHDFSD: callback: res 0, bytes 13, arg 1f7b48
USBHDFSD: bulk csw result: 0, csw.status: 0
USBHDFSD: boot signature 55 AA
USBHDFSD: cbw_scsi_read_sector - 0x00000038 fab00 0x0008
USBHDFSD: callback: res 0, bytes 31, arg 1f7b50
USBHDFSD: callback: res 0, bytes 13, arg 1f7b20
USBHDFSD: bulk csw result: 0, csw.status: 0
USBHDFSD: Fat type 32 Id FAT32 
USBHDFSD: cbw_scsi_read_sector - 0x00000058 fab00 0x0008
USBHDFSD: callback: res 0, bytes 31, arg 1f7a18
USBHDFSD: callback: res 0, bytes 13, arg 1f79e8
USBHDFSD: bulk csw result: 0, csw.status: 0
USBHDFSD: cbw_scsi_read_sector - 0x00001eb0 fab00 0x0008
USBHDFSD: callback: res 0, bytes 31, arg 1f7aa8
USBHDFSD: callback: res 0, bytes 13, arg 1f7a78
USBHDFSD: bulk csw result: 0, csw.status: 0
ART
CD
CFG
CFG-DEV
CHT
USBHDFSD: cbw_scsi_read_sector - 0x00001eb8 fab00 0x0008
USBHDFSD: callback: res 0, bytes 31, arg 1f7820
USBHDFSD: callback: res 0, bytes 13, arg 1f77f0
USBHDFSD: bulk csw result: 0, csw.status: 0
DVD
THM
VMC

After i pressed START to exit, I've got BSOD with that pendrive.

intenso result.log:

FreeUsbd v.0.1.2
USB HDD FileSystem Driver v1.6
USBHDFSD: registerDriver=0
USBHDFSD: probe: devId=1
USBHDFSD: mass_stor_findDevice devId 1
USBHDFSD: bNumInterfaces 1
USBHDFSD: bInterfaceClass 8 bInterfaceSubClass 6 bInterfaceProtocol 50
USBHDFSD: connect: devId=1
USBHDFSD: mass_stor_findDevice devId 1
USBHDFSD: register Output endpoint id =1 addr=01 packetSize=64
USBHDFSD: register Input endpoint id =2 addr=82 packetSize=64
USBHDFSD: connect ok: epI=2, epO=1
Listing contents of mass0:/...
USBHDFSD: configuring devices...
USBHDFSD: setting configuration controlEp=0, confNum=1
USBHDFSD: callback: res 0, bytes 0, arg 1f7c50
USBHDFSD: setting interface controlEp=0, interface=0 altSetting=0
USBHDFSD: callback: res 4, bytes 0, arg 1f7c50
USBHDFSD: Error - sending set_interface 4
Unable to open mass0:/ - -19

I knew you use Windows, but I think @Agrippa uses Linux.
Anyway, I have included ports of planetty for both Linux and Windows.

On both PC I've Win XP, Win 10\Linux mint 19 only @ home.

Yes, it'll be very slow. But the purpose was to determine if @Agrippa's USB enclosure was having issues with long transfers
So for the rest who have devices that cannot be detected at all, this will do nothing.

Thanks for detailed answer.

 

[sp193]

Thank you both. So this is an interesting thing. The breaking commit was this one, when I made USBHDFSD check for and act when the set device/set interface commands failed. This probably meant that the set interface step always failed for some devices, but we just never knew that because it used to have no consequence.

But I don't know (yet) whether the set interface process is actually optional (and hence why it was never treated as an unrecoverable error, despite the error message it will print). I don't know whether the same thing goes for the set device step either.

I plan to look at the Linux source code at some later time to see what they're doing there. If all else fails, I shall just revert that change and update the comment to reflect this finding.
Or if somebody else already knows of the answers to these questions, that would be great:

• Is the host always supposed to do set configuration & set interface?
• If not, how should the interface determine when to do those actions?
• Is the device allowed to fail (i.e. stall the control pipe) when it does not support those actions?
• If the device is allowed to fail those actions, should the host deem it as an unrecoverable error and just move on? Or should it retry?

BTW does the " > result.log" has to be at the of the "planetty"
in widows cmd:

planetty.exe 192.168.0.10 > result.log

No. But because it allows the log file to be easily generated and I know that a lot of people nowadays have no idea how to use the command line properly, I made it part of the example.
If you don't redirect output (i.e. just run planetty.exe 192.168.0.10), then it will print whatever it receives onto the screen.

 

[Agrippa]

I'm glad I could contribute something to trace the problem.

Have we got any debug version of the OPL to find the other problem with the hanging on the last debug screen?