Loading of wifi modules in V2+

[cswindle]

Hi All

Here are the details of getting wifi modules loaded in V2+ (used by eLoader). The NID that is used was found by PspPet at the following page:

http://forums.ps2dev.org/viewtopic.php? ... da47ad4941

0x1579a159,sceUtilityLoadNetModule
0x64d50c56,sceUtilityUnloadNetModule

These are the procedures that GTA uses to load/unload the adhoc modules. After investigation it seems that there is only one parameter used for the procedure and we found that the following are the values that can be used:

PSP_NET_MODULE_COMMON 1
PSP_NET_MODULE_ADHOC 2
PSP_NET_MODULE_INET 3
PSP_NET_MODULE_PARSEURI 4
PSP_NET_MODULE_PARSEHTTP 5
PSP_NET_MODULE_HTTP 6
PSP_NET_MODULE_SSL 7

All of these modules are able to be loaded using this method via the GTA loader, however with the TIFF exploit we were not able to get module inet loaded and we needed to use vshKernelLoadModuleVSH to load it in the eLoader.

We also found that the stack size for sceNetApctlInit needs to be increased in v2+ to above 0x1400, which the loader does dynamically.


Chris

[Fanjita]

Note that it's probably still best to implement any wifi code using the traditional v1.5-compatible methods, as these functions are only available in v2.0+.

The eLoader attempts to automatically map the common patterns for using wifi in v1.5 into these user-mode-friendly calls on v2.0+, as follows:

- If the app's import table indicates that any wifi modules are imported, then the appropriate set of libraries are loaded by eLoader before the app is started, e.g. sceNetInet => load PSP_NET_MODULE_INET. These are loaded in the obvious dependency order, which is from lowest library ID to highest.

- Because eLoader skips any kernel-mode initialisation functions, some of your app's wifi init code may be skipped. Most common code samples for wifi seem to do all the initialisation within the user mode threads, so this shouldn't be an issue, although I suspect that Peldet is one app that falls foul of this.

- Import tables are fixed up by eLoader once the dynamic modules have been loaded - there's no need for the app to do any fixup. This is usually done by the app's kernel mode init functions anyway, so shouldn't be a problem.

- The wifi libs are automatically unloaded when sceKernelExitGame() is called, or if the user forces an exit with the eLoader's 3-finger-salute (L+R+START). I suspect that the current exit crashes with some code (such as PSPRadio) are because their ExitGame handlers also attempt to unload the wifi modules.

- Finally, we found that (particularly in v2.5+), some combinations of clock speeds would prevent the ApctlInit() function from completing successfully. Conversely, it seems that you're unable to set some clock speed combos when the wifi circuit is active. To deal with this, the eLoader will automatically override the most common non-working speed setting (CPU/RAM/BUS = 333/333/166) to 300/333/166 for apps that import wifi modules. You may need to experiment with the speed settings that your app uses, to be sure that they work on v2.5+.

[danzel]

@Fanjita - yeah, peldet is probably doing some dumb things with the wifi, it should really be updated sometime....

One thing, both webnab and afkim just lock up when you try quit with L+R+Start, their quit handlers just contain sceKernelExitGame(); return 0;
(They are written in c++ if it makes a difference)

I modified the exit call back to:

Code: Select all

/* Exit callback */
int exit_callback(int arg1, int arg2, void *common)
{
	pspSdkInetTerm();
	sceNetApctlDisconnect();
	sceNetApctlTerm();
	
	sceKernelExitGame();
	return 0;
}

And set up a key combination to call it and that made it quit properly (not sure if the inet term, disconnect, term functions are needed, haven't tested without)

But the L+R+Start one still doesn't. (black screen, power off)

Any ideas?