Page 1 of 1

[PSPgo] Start eboot from ef0 and load something in ms0

Posted: Thu Apr 26, 2012 4:28 am
by fLaSh
Sup all;

I'm trying to create an PRX loader to load another PRX but in different stored.. like the title says..
I alredy tried it.. but the PSP crash when trying to access to MS (eboot from ef0)..

I think the problem is related to something with the method on how to access .. because the "original PSP only" supports an stored..

This method can be good to running plugins like mp3play, since the PSP can not read\write the stored in simultaneously (can result in crash).
Sorry for my poor English..

Any help?

Thanks

Re: [PSPgo] Start eboot from ef0 and load something in ms0

Posted: Thu Apr 26, 2012 9:31 am
by m0skit0
Post the relevant code.

Re: [PSPgo] Start eboot from ef0 and load something in ms0

Posted: Thu Apr 26, 2012 6:40 pm
by West-Li
if you want to check if the load path is ms0:/ or ef0:/ use sceKernelGetModel();. If you dont use 0x1000 (kernel mode) you can use also kernel-user library (kuKernelGetModel();). Post here your source code. I dont understand what do you want.

Re: [PSPgo] Start eboot from ef0 and load something in ms0

Posted: Fri Apr 27, 2012 5:54 am
by JJS
I think the OP refers to the fact that you cannot access the "real" memory stick if your homebrew is started from the internal flash on a PSP Go. That is because "ms0" refers to the internal flash then (ms0 = ef0) for backward compatibility.

We had a discussion about this previously on here. Also I think PRO CFW patches this so that ef0 and ms0 always refer to the actual devices (a bit hazy on this though so I might be wrong).

Re: [PSPgo] Start eboot from ef0 and load something in ms0

Posted: Sat Apr 28, 2012 11:40 pm
by fLaSh
Thanks for all replays!

@m0skit0
You can test it.. if you have a PSPgo and a M2 Card..
With the plugin mp3player_lite.prx.. in the mp3player.ini change the music dir to ms0:\MUSIC .. you can see, on xmb works in a game the PSP crash...

@JJS
Yeah, ill wait for news about it, thanks :)

Re: [PSPgo] Start eboot from ef0 and load something in ms0

Posted: Wed May 02, 2012 9:17 am
by Coldbird
This is normal...

And it's official Sony behaviour...

The state of ef0 outside of VSH / POPS runlevel is undefined! You should NEVER access ef0 unless your plugin runs in XMB or POPS.

VSH: ef0 = internal, ms0 = m2 micro
POPS: ef0 = internal, ms0 = m2 micro
GAME (ISO, UMD, EBOOT): ef0 = undefined (don't use it!), ms0 = start device or memory stick (if running a umd)

Summing up, you can only access one device in game mode.

Re: [PSPgo] Start eboot from ef0 and load something in ms0

Posted: Wed May 02, 2012 2:02 pm
by Yoti
Coldbird wrote: VSH: ef0 = internal, ms0 = m2 micro
So, homebrew with 0x800 attrib may get access to ef0 & ms0?

Re: [PSPgo] Start eboot from ef0 and load something in ms0

Posted: Wed May 02, 2012 9:15 pm
by fLaSh
@Coldbird
humm.. with pmplayer-advance you can choise the source to play on a PSPgo (ef or ms)..

See http://code.google.com/p/pmplayer-advance
directory.c

Code: Select all

int open_directory(const char* dir, char* sdir, int show_hidden, int show_unknown, file_type_ext_struct* file_type_ext_table, directory_item_struct** list) {
	int item_count;
	if ( strncmp(dir,"ms0:", 4) == 0 )
		item_count = open_ms_directory(dir, sdir, show_hidden, show_unknown, file_type_ext_table, list);
	else if ( strncmp(dir,"ef0:", 4) == 0 )
		item_count = open_usb_net_directory(dir, sdir, show_unknown, show_unknown, file_type_ext_table, list);
	else if ( strncmp(dir,"usbhost0:", 9) == 0 || strncmp(dir,"nethost0:", 9) == 0)
		item_count = open_usb_net_directory(dir, sdir, show_unknown, show_unknown, file_type_ext_table, list);
	else {
I tried to understand, but my skills are not very good .. i'm older programmer but not in C/C++ .. i'm learning :)

Thanks :)

Re: [PSPgo] Start eboot from ef0 and load something in ms0

Posted: Thu May 03, 2012 7:55 pm
by RNB_PSP

Re: [PSPgo] Start eboot from ef0 and load something in ms0

Posted: Sat Aug 09, 2014 2:17 pm
by suloku
I know this is old, but I couldn't find any information regarding this topic anywhere, even though Xplora 2 can be booted from ef0 and still access both ef0 and memory stick, and since I've discovered how it does it I'll leave the information here.

When the xmb launches a homebrew from the internal storage it uses apitype 0x152, which prevents all access from the application to the memory stick. When it launches a hombrew from the memory stick it uses apitype 0x141, which allows access to ef0 and ms0.

The trick is: there's nothing that prevents us from executing an aplication from ef0 with apitype 0x141 ( sctrlKernelLoadExecVSHWithApitype(apitype, path, &param) ), so that's it. This is what I think Xplora 2 does: the ef0:/PSP/GAME/XPLORA/EBOOT.PBP is just a simple loader that loads ef0:/XPLORA/EBOOT.PBP with apitype 0x141, which is the main app and with this double boot process it achieves access to ef0 and ms0.

Of course, you can just put your homebrew in the memory stick and your life would be easier.

Also, regarding plugins, when a prx plugin resides in ef0 (i.e. ef0:/seplugins/myplugin.prx) it will be patched by the custom firmware so all ms0, fatms0 and fatms references remap to ef0, fatef0 and fatef even when launching from the memory stick (and thus having teoricall access to ms0 and ef0). I think this is done for compatibility reasons. This won't happen if the plugin resides in the memory stick (ms0:/seplugins/myplugin.prx). Here's the patch function from the Pro CFW source code

Pro CFW source code plugins.c:

Code: Select all

static void patch_devicename(SceUID modid)
{
	SceModule2 *mod;
	int i;

	mod = (SceModule2*)sctrlKernelFindModuleByUID(modid);

	if(mod == NULL) {
		return;
	}

	for(i=0; i<mod->nsegment; ++i) {
		u32 addr;
		u32 end;

		end = mod->segmentaddr[i] + mod->segmentsize[i];

		for(addr = mod->segmentaddr[i]; addr < end; addr += 4) {
			char *str = (char*)addr;

			if (0 == strncmp(str, "ms0", 3)) {
				str[0] = 'e';
				str[1] = 'f';
			} else if (0 == strncmp(str, "fatms", 5)) {
				str[3] = 'e';
				str[4] = 'f';
			}
		}
	}

	sync_cache();
}
Note: remember that you can have a game.txt in ef0:/seplugins that contains plugins stored in the memory stick, but those plugins will only be loaded when using apitypes compatible with both ef0 and ms0
Note 2: if there is a game.txt in ef0:/seplugins and a game.txt in ms0:/seplugins each one will be used for the corresponding devices, with independent configurations.

So if you want to do something like " sceIoDopen("ms0:/PSP/GAME);" it will actually try to open "ef0:/PSP/GAME". To bypass this is simple:

Code: Select all

sprintf(path, "ms0:/ISO");
if (kuKernelGetModel() == 4 && IsApiIS() == 0){ //This ensures that we only bypass the patch when runing under an apitype that can access the memory stick
	buf[0]='m';
	buf[1]='s';	
}
sceIoDopen(path);
//////////////////////////////////
// Will report if we are running under internal storage (ef0) or not
int IsApiIS()
{
	int InitApitype = kuKernelInitApitype();

	if (InitApitype == 0x125){//NP9660/ISO MODE
		return 1;
	}else if (InitApitype == 0x155){//POPS
		return 1;
	}else if (InitApitype == 0x151){//UPDATER
		return 1;
	}else if (InitApitype == 0x152){//GAME
		return 1;
	}else{
		return 0;
	}
}
With this one can access the memory stick from a plugin that is stored in the internal storage, just be careful with the paths and the fact that the PSPGo might not have a memory stick inserted (one can check it with MScmIsMediumInserted() (pspmscm.h). Remember that as I wrote earlier, if the plugin is running under an apitype that forbids the memory stick (i.e. launching a game from internal storage) all the ms0 references will still be remaped to the internal storage.