PSPLink on 2.71 TA-082

[fulg]

I'm trying to make PSPLink work under 2.71 (for us poor TA-082 owners).

After getting and building the latest toolchain + PSPSDK + PSPLink from SVN, I made a quick usermode PRX that launches the kernel PRX of PSPLink (so I can boot it under 2.71 patched with HENC) and that seems to work fine. To my surprise, many things work correctly, and can already connect via WIFI or launch remote-hosted binaries through the USB shell!

However there are a few annoyances. For example PSPLink cannot reset itself because it uses sceKernelLoadExec to relaunch itself, and that fails under 2.71. I've had the function return various values (weird ones like 139, 140 and 142 (?), in addition to real errors like ILLEGAL_PERM_CALL) but never managed to make it do anything useful.

I've tried loading an ELF from user/kernel PRXs, loading a PBP from user/kernel PRXs, nothing worked so far. PSPDev seems to tell me that the function just isn't available, but I can't say I completely understand how to read this info :)

For now, trying to start a debug session will instantly crash. I can see the usbgdb prx being loaded, but the PSP will crash before the session is started. (I can see the "PSPLink GDBServer (c) 2k6 TyRaNiD/Lovely2" but not the "GDBServer: Loaded host0:/foobar.elf - UID 0x12345678" message).

Already I can see that PSPLink would be tremendously useful for PSP development, but until I can reset without crashing the PSP to load another ELF/PRX, it's not very useful.

So I guess my questions are:

- Is there a way to make sceKernelLoadExec work under 2.71 (patched with HENC)?

- Has anyone ever tried to make PSPLink work under 2.71, or is this simply impossible?

PS: Be gentle, this is my first week of coding for PSP :)

Thanks

[moonlight]

I'm trying to make PSPLink work under 2.71 (for us poor TA-082 owners).

After getting and building the latest toolchain + PSPSDK + PSPLink from SVN, I made a quick usermode PRX that launches the kernel PRX of PSPLink (so I can boot it under 2.71 patched with HENC) and that seems to work fine. To my surprise, many things work correctly, and can already connect via WIFI or launch remote-hosted binaries through the USB shell!

However there are a few annoyances. For example PSPLink cannot reset itself because it uses sceKernelLoadExec to relaunch itself, and that fails under 2.71. I've had the function return various values (weird ones like 139, 140 and 142 (?), in addition to real errors like ILLEGAL_PERM_CALL) but never managed to make it do anything useful.

I've tried loading an ELF from user/kernel PRXs, loading a PBP from user/kernel PRXs, nothing worked so far. PSPDev seems to tell me that the function just isn't available, but I can't say I completely understand how to read this info :)

For now, trying to start a debug session will instantly crash. I can see the usbgdb prx being loaded, but the PSP will crash before the session is started. (I can see the "PSPLink GDBServer (c) 2k6 TyRaNiD/Lovely2" but not the "GDBServer: Loaded host0:/foobar.elf - UID 0x12345678" message).

Already I can see that PSPLink would be tremendously useful for PSP development, but until I can reset without crashing the PSP to load another ELF/PRX, it's not very useful.

So I guess my questions are:

- Is there a way to make sceKernelLoadExec work under 2.71 (patched with HENC)?

- Has anyone ever tried to make PSPLink work under 2.71, or is this simply impossible?

PS: Be gentle, this is my first week of coding for PSP :)

Thanks

well, for loadexec you can use the function sceKernelLoadExecVSHMs2, but in 2.71 this only works with executables inside a pbp.
Also if you are porting psplink you'll soon encounter some problems regarding loadmodule... There is almost a function for loading each thing.
These are not the true names of the nids, but it is how i call them: sceKernelLoadModuleDisc, sceKernelLoadModuleDiscUpdater, sceKernelLoadModuleMs1, sceKernelLoadModuleMs2, sceKernelLoadModuleMs3, sceKernelLoadModuleDNAS (used by socom 2 game...), and there even some more functions, one of them specifically to load vshmain.prx :D

I'll release with HEN-D / SE-C some libraries and the includes of those functions.

Also, some other problems: umd cannot be accessed when booting from memory stick (it's a sony protection). And semawm (required for usb mass storage) cannot be loaded because it is sign checked. These two problems will be gone in HEN-D/SE-C

[TyRaNiD]

That is some good work, I havent even looked at psplink above v1.5 cause of the problems associated with stuff like you have pointed out (and the lack of a working 2.71 psp ;P) Still I would expect it is theoretically possible to do it even if it requires proper hacking of the kernel to make it work.

Does 2.71 + HENC work in devhook in a similar way or it is not even worth playing with that stuff if I were to start looking at developing psplink for use under 2.71?

[moonlight]

That is some good work, I havent even looked at psplink above v1.5 cause of the problems associated with stuff like you have pointed out (and the lack of a working 2.71 psp ;P) Still I would expect it is theoretically possible to do it even if it requires proper hacking of the kernel to make it work.

Does 2.71 + HENC work in devhook in a similar way or it is not even worth playing with that stuff if I were to start looking at developing psplink for use under 2.71?

HEN C for devhook is exactly the same than the normal one, except the reboot stuff removed because devhook does already those things.

[TyRaNiD]

Hmm well i've got it to load under devhook + henc, guess I need to see if I can fix the problems in it ;)

[moonlight]

Hmm well i've got it to load under devhook + henc, guess I need to see if I can fix the problems in it ;)

Anyways i'll release hen d this week fixing a few bugs regarding the noplainmodulecheck patch, breaking the security of umd not being accesible when booting from ms, and enabling sign checked modules of the flash to be loaded (this doesn't affect devhook which uses not sign checked modules in the firmware dump).

Current limitation of hen is that standalone static elf loading is not possible. Only if it is inside a pbp and it is a user elf, it can be loaded with the 2.XX function ModuleMgrForKernel_49C5B9E1 that i call sceKernelLoadModuleMs2.
Except for bugs that are mostly fixed in hen d, the rest of user prx's and kernel prx's can be loaded with the normal sceKernelLoadModule.

Sine it may help you, i'll ive you a list of loadmodule functions in 2.XX (all are false nids):

#define sceKernelLoadModuleDisc ModuleMgrForKernel_A1A78C58
#define sceKernelLoadModuleDiscUpdater ModuleMgrForKernel_896C15B6
#define sceKernelLoadModuleMs1 ModuleMgrForKernel_6723BBFF
#define sceKernelLoadModuleMs2 ModuleMgrForKernel_49C5B9E1
#define sceKernelLoadModuleMs3 ModuleMgrForKernel_ECC2EAA9
#define sceKernelLoadModuleWithApitype2 ModuleMgrForKernel_6DE9FF11
#define sceKernelLoadModuleDNAS ModuleMgrForUser_FEF27DC1

The header of all of them are the same as usual loadmodule, except the apitype2 one which has an integer parameter at the beginning that represents the type of load. With sceKernelLoadModulwWithApitype2 you can imitate the rest of functions with the apropiated apitype parameter:

0x00 -> sceKernelLoadModule (ModuleMgrForKernel)
0x10 -> sceKernelLoadModule (ModuleMgrForUser)
0x20 -> sceKernelLoadModuleVSH
0x120 -> sceKernelLoadModuleDisc
0x121 -> sceKernelLoadModuleDiscUpdater
0x140 -> sceKernelLoadModuleMs1
0x141 -> sceKernelLoadModuleMs2
0x142 -> sceKernelLoadModuleMs3
0x13 -> sceKernelLoadModuleDNAS

Ms functions can load things only inside a pbp, and the rest cannot load anything inside a pbp :)

[moonlight]

Ups, duplicated.

[TyRaNiD]

Hmm okay well i've at least tried to add some fixes but cant seem to get stuff to do much. I've tried using LoadExecVSHMs2 to do the reset (which is a prx inside a PBP) but no go, I am doing:

Code: Select all

struct SceKernelLoadExecVSHParam param;

    memset(&param, 0, sizeof(param));
    param.size = sizeof(param);
    param.args = strlen(g_context.bootfile)+1;
    param.argp = (char*) g_context.bootfile;
    param.key = "game";
    param.vshmain_args_size = 0;
    param.vshmain_args = NULL;

    printf("Exec: %08X\n", sceKernelLoadExecVSHMs2(g_context.bootfile, &param));

this returns SCE_KERNEL_ERROR_ILLEGAL_PERM_CALL, can it be only used inside a VSH thread?

I also cannot seem to load plain user modules from psplink using normal LoadModule, not sure if this was what you were alluding to before, I get a INVALID_PRX_TYPE error, though kernel prxes work fine :)

[moonlight]

Hmm okay well i've at least tried to add some fixes but cant seem to get stuff to do much. I've tried using LoadExecVSHMs2 to do the reset (which is a prx inside a PBP) but no go, I am doing:

Code: Select all

struct SceKernelLoadExecVSHParam param;

    memset(&param, 0, sizeof(param));
    param.size = sizeof(param);
    param.args = strlen(g_context.bootfile)+1;
    param.argp = (char*) g_context.bootfile;
    param.key = "game";
    param.vshmain_args_size = 0;
    param.vshmain_args = NULL;

    printf("Exec: %08X\n", sceKernelLoadExecVSHMs2(g_context.bootfile, &param));

this returns SCE_KERNEL_ERROR_ILLEGAL_PERM_CALL, can it be only used inside a VSH thread?

I also cannot seem to load plain user modules from psplink using normal LoadModule, not sure if this was what you were alluding to before, I get a INVALID_PRX_TYPE error, though kernel prxes work fine :)

There is a bug loading big user prx's that is fixed in hen d (well and another that is fixed in se already but not in hen, regarding a patch bad done in a delay slot instruction)

LoadExeccVSHMs1/2/3 and all the sceKernelLoadExecVSH functions returns 0x80020149 if they are called directly from the kernel without passing through vshKernelLoadExecVSH*

The fix (it fixes at the same time all VShLoadExec functions, except ExitVSHVSH)

Code: Select all

#define BEQ_ZERO_ZERO_PC 0x1000000b

void PatchExecVSH()
{
	u32 *mod = (u32 *)sceKernelFindModuleByName("sceLoadExec");
	
	if (mod)
	{
		u32 text_addr = *(mod+27);
		_sw(BEQ_ZERO_ZERO_PC, text_addr+0x1DBC);
		_sw(0, text_addr+0x1DFC);
	}
}

[TyRaNiD]

Yes well I was being an idiot ;) Thought I had patched out the correct locations but in fact I hadn't :P Then I hadn't nul terminated the path which causes it to dump me back to the VSH. Still reset now works okay at least with a patch. Any likelyhood this will be a patch in HEN-D or should I just patch it myself? Are you going to release a version for devhook as well?

Oh and what might be the fix to correct the loading of user prxes? That is probably the only immediate issue as it is preventing my user module from starting which contains my exception handler (I could fix it to not need it but hey :P)

Oh and is sceKernelExitGame supposed to not work in kernel mode ?

[moonlight]

Yes well I was being an idiot ;) Thought I had patched out the correct locations but in fact I hadn't :P Then I hadn't nul terminated the path which causes it to dump me back to the VSH. Still reset now works okay at least with a patch. Any likelyhood this will be a patch in HEN-D or should I just patch it myself? Are you going to release a version of devhook as well?

Oh and what might be the fix to correct the loading of user prxes? That is probably the only immediate issue as it is preventing my user module from starting which contains my exception handler (I could fix it to not need it but hey :P)

Oh and is sceKernelExitGame supposed to not work in kernel mode ?

I'll probably release a way of using the loadexec functions, don't know if with that patch or with an api that fakes the user level and k1 values to avoid the function reject it.
Devhook version will be included always since it takes 30 seconds to build it from the other :) Here is an updated hen for devhook with the two plainmodule issues patched:

http://moonlight.lan.st/systemctrl_dh.prx

[TyRaNiD]

Cool that works great :)

[moonlight]

I forgot to replay the ExitGame thing. I'm unsure if it works in kernel mode, anyways you can always use the sceKernelExitVSHKernel function (LoadExecForKernel_6D302D3D) and set its only parameter to NULL.

[TyRaNiD]

Well i've put up a version of psplinkusb (the next gen one) into subversion branches which seems to work reasonably well on 2.71 devhook plus the module moonlight supplied, I guess it will probably work under firmware which provides equivalent functionality. Somethings still dont work, but the core functionality is there, even gdb seems to mostly work even though I get a few quirks due to having to use prx files instead of static elfs (gdb is very very stupid :P)

Now people should be able to dev properly even on 2.71 ;)

[fulg]

Now people should be able to dev properly even on 2.71 ;)

Wow, awesome! Thanks a bunch! Just gave it a quick trial run and it works great. I'll send patches (or ask questions) if I see anything funny going on.

Now if only Zelda wasn't this much fun, I'd put in more PSP dev time... :)