Launching from HDD fail if wLaunchELF is launched from mass

[AKuHAK]

Faced strange bug, which is not presented in earlier ps2toolchain versions. When I launch the current development build from a USB stick, then I cannot launch apps from the internal HDD anymore (just return back to OSD browser). This bug only appears if launched from mass, if I launch from MemoryCard or from HDD itself, then I can load elfs from HDD with no problem. Can't figure out where is the problem, but it seems that this is not wlaunchELF problem. If someone can test if OPL has a similar issue? @rickgaiser can it be related to the changes in ps2toolchain?

[rickgaiser]

Just yesterday I had an issue where OPL would not start a game when loaded from ps2link. The problems started in this line of code in OPL, right before launching a game: memset((void *)0x00084000, 0, 0x00100000 - 0x00084000);

As it turns out, even after OPL seems to reset everything, there is still EE code present and active from ps2link in that memory region. Like a thread is still running, and exception hooks are still in place. Booting any game would couse EE-IOP communication to freeze, after that memset. I don't know how this ever worked before and I would have never thought this was the problem. So it took me a lot of time to figure this out.

Using the "packed" version of OPL this issue is was solved. Probably becouse it loads the executable in a different way, and properly resets the EE state.

How is wLE loaded each time? And who makes sure the EE and IOP are in a well defined state after loading? The loader or wLE?

[sp193]

The standard way of starting another program is via ExecPS2(). This will do things like terminating all threads and semaphores, de-regsitering all handlers and resetting the EE peripherals. Similar to OPL, software like PS2Link remain active by not using this syscall and/or patching the kernel. PS2Link installs various handlers to offer the debugging capabilities, which includes a 2nd SIF handler to communicate with its IOP side. So if it simply gets overwritten without de-registering its handlers, bad things may happen. I suppose using the packed version made the problem disappear because it will call ExecPS2() to jump to the decompressed program's entry point.

As for who's responsible for cleaning up... I think that's a difficult question. The EE is always "cleaned up" with ExecPS2() and with some additional logic, but the IOP is a different story. Sony seems to have shifted the responsibility before:

1. Stock OSDSYS, and when games are booted from discs: LoadExecPS2() is used to boot the target ELF. The default IOP modules are always loaded and so are the modules used for loading the ELF (e.g. MCMAN). The very first OSDSYS version did not reboot the IOP. LoadExecPS2() has been used by the OSD to load the IOP with certain module sets for the next ELF.
2. HDD Browser: the browser always resets the IOP before booting the program from the HDD, leaving no additional device modules. It may reset the IOP with the game's IOPRP image. I suppose this is necessary because the game is not guaranteed to be compatible with the browser's IOP modules and neither is it supposed to access IOP services before the IOP is reboot to contain compatible modules.

In our homebrew world, I've seen a mixture of both patterns - subject to when the software was written and who wrote it. Some software will fail to work, if there is no access to the device which the ELF was booted from. Given that we usually deal with devices that aren't supported by the boot ROM and may be loading modules that are not compatible with the modules from other software, doing (2) is likely more appropriate.