improve BDM HDD detection logic

[xan1242]

Pull Request checklist

Note: these are not necessarily requirements

• I reformatted the code with clang-format
• I checked to make sure my submission worked
• I am the author of submission or have permission from the original author
• Requires update of the PS2SDK or other dependencies
• Others (please specify below)

Pull Request description

Improved the BDM HDD detection logic.

Instead of assuming mass0 for the HDD, it will now try to find the first unmounted device, which should resolve the edge case of the user having another BDM device without an OPL config on it.

Fixes: #1696

[rickgaiser]

This is a bad assumption:
find the first inaccessible device - this one should be the HDD.
It can be another slow booting device, or no device at all

The following 2 functions should be responsible for the HDD loading and detection:
if (hddLoadModules() >= 0 && bdmHDDIsPresent())

The fix for not properly detecting / waiting for the HDD should be somewhere in those 2 functions.

[xan1242]

hddLoadModules succeeds even if there is no HDD in the system. This simply checks for the IOP module loads.

bdmHDDIsPresent succeeds only if the HDD is actually physically there (as it relies on the UDMA mode detection code which uses ata_device_identify, which is all we really need). This naturally needs the hddLoadModules to work.

Due to the nature of the BDM support and how it's written, I don't see a better way of finding out the mass device number other than this. Is there a way to get the device info without the item list?

I see it being attempted at the autolaunch here:

https://github.com/ps2homebrew/Open-PS2-Loader/blob/master/src/opl.c#L1988-L2007

But the conundrum is that there is a delay until the device actually shows up, so this won't work without delaying the entire boot process.

So the way I see it, the two options are:

• keep it this way - assume that the slowest device is the HDD, with not much of a boot up delay, but it may break if the user has a slow USB device (e.g. USB spinning HDD, slow USB controller, slow firewire device, etc.) (at which point you have to ask HOW is the user even using OPL in this case, we shouldn't assume anything, I know)
• delay entire boot sequence after HDD module loads and then find out which one it is via the same process as autolaunch

I personally don't have an issue with the second option, but it might alert some people to ask "why is OPL booting up slower than usual now?".

As a matter of fact - I'd go as far to say that that assumption is pretty safe because:

• USB devices are powered on constantly on the console
• Most USB mass storage devices show up instantly
• I haven't been able to verify this but I assume same is valid for Firewire
• MX4SIO is a low powered device, constantly on, usually instantly accessible

HDD really is the slowest here, speaking from the hardware perspective. If there is an outlier with a slow USB device, then that burden is mostly on the user anyway (as it always was with OPL).

EDIT: the only other thing I can think of that doesn't delay the boot times is to double-check after the device has been located using the current logic (a hybrid of the two approaches I mentioned). If it isn't the HDD, then simply continue to search which device it actually is.

[rickgaiser]

bdmHDDIsPresent should have been hddIsPresent, as it has nothing to do with BDM and communicates directly to the xhdd0 device.

Perhaps I don't understand the core issue correctly, but why do we need to know if a BDM device is a HDD device? Just like in windows, you don't need to know if your D drive is SATA/PATA/SCSI/USB/FireWire/Etc... it's just D:.

For those cases where you do need to know, you can ask any BDM device what type of device it is, for example here:

Open-PS2-Loader/src/bdmsupport.c

Line 811 in d8855f1

fileXioIoctl2(dir, USBMASS_IOCTL_GET_DRIVERNAME, NULL, 0, &pDeviceData->bdmDriver, sizeof(pDeviceData->bdmDriver) - 1);

Also since "mass:" was confusing for way too long a time, since recently new device names have been added that are exclusive to a specific device. More info here:
ps2dev/ps2sdk#812

So instead of "massX:", you can now also use "ataX:" for HDD devices.

But the conundrum is that there is a delay until the device actually shows up

As soon as the HDD is ready (after 5 seconds?), it will register as a BDM device with exFat support. This should trigger a BDM even to OPL, here:

Open-PS2-Loader/src/bdmsupport.c

Lines 71 to 74 in d8855f1

	static void bdmEventHandler(void *packet, void *opt)
	{
	BdmGeneration++;
	}

And that should show the games list.

But I'm guessing in this case the issue is a config issue? Where the config that tells OPL what drivers to load, is stored on the HDD?

[xan1242]

533483b

Check this commit please, this should be it now. (I've been writing it before I read your comment, sorry)

I suppose moving the HDD presence checks would be smarter to put in the hddsupport, I agree. I'll go and do that in a commit shortly...

But the core issue is that of the chicken and the egg - HDD has the config, so we need HDD modules to load the config to even see if we need them.

[rickgaiser]

Ready to merge?

[xan1242]

Yes. It's ready.