Hi everyone,
I'm thinking about implementing a different filesystem for accessing the memory stick, FAT is really not good for flash devices anyway, i'm able to redirect access to ms0 to my own driver, and it works in a test homebrew.
But i can't find a way to make the redirect stable , so that XMB will use it.
I'm using CF 3.40, in 1.50 kernel mode, to bypass the protection against redirecting ms0 of newer firmwares.
Need some advice for a filesystem project
I don't think that it's really needed, i already can open the raw memstick using sceIoOpen("msstor0:",PSP_O_RDWR,0), so it should be possible to write a driver that acces the raw memory, and call sceAssign("ms0", "my_fs",NULL,IOASSIGN_RDWR,NULL,0)adrahil wrote:You'll need to reimplement fatmsmod.prx & co.
At this moment i have a prototype driver loaded as a plugin by the custom firmware, it registers the "my_fs" driver, but i can't find a way to call it with my homebrew, if i do
sceIoOpen("my_fs:/whatever",PSP_O_RDWR|PSP_O_CREAT,777)
i got a NODEV error.
Is there anything i'm missing to use a driver registered from a plugin?
It worked perfectly when i was loading the module with pspSdkLoadStartModule from the homebrew
I've solved this problem, it happens using the 1.50 kernel mode, switching to 3.40 fixes it, but now i need to find out how to circumvent the ms0 redirect protectionalexp wrote: At this moment i have a prototype driver loaded as a plugin by the custom firmware, it registers the "my_fs" driver, but i can't find a way to call it with my homebrew, if i do
sceIoOpen("my_fs:/whatever",PSP_O_RDWR|PSP_O_CREAT,777)
i got a NODEV error.
Is there anything i'm missing to use a driver registered from a plugin?
It worked perfectly when i was loading the module with pspSdkLoadStartModule from the homebrew
Why don't you just delete the current fatms driver, and call your driver the same?
I mean, something like:
sceIoDelDrv("fatms");
sceIoAddDrv(&my_driver); // named "fatms" too
sceIoAssign("ms0:", "msstor0p1:", "fatms0:", IOASSIGN_RDWR, NULL, 0);
Also, the option of replacing fatmsmod of the flash with yours (at least in 3.XX kernel) would be fine, you wouldn't need the assign, because some other module would do it for you.
Btw, can i ask which filesystem are you gonna to implement? Just for curiosity :p
I mean, something like:
sceIoDelDrv("fatms");
sceIoAddDrv(&my_driver); // named "fatms" too
sceIoAssign("ms0:", "msstor0p1:", "fatms0:", IOASSIGN_RDWR, NULL, 0);
Also, the option of replacing fatmsmod of the flash with yours (at least in 3.XX kernel) would be fine, you wouldn't need the assign, because some other module would do it for you.
Btw, can i ask which filesystem are you gonna to implement? Just for curiosity :p
I'm now working on a custom log structured filesytem, which is more adapt to flash memory. It's not easy to implement other log structured filesytem (such as jffs2 or yaffs), because we have no access to the raw memory card, only a block device interface to it. I'm working both to a FUSE implementation of the filesytem under linux and to the psp driver
No plan for a windows port, sorry
No plan for a windows port, sorry
hi,
i'm having a bit of problems with my fileystem and i feel i'm missing something.
I'm loading my code as a custom firmware plugin, so in XMB i got correct filesystem size, but if i try to select for example PHOTO, i only get a request for /DCIM, which is not present, so i return 0x80010002 (no such file or directory). I think that i should be getting other dopen request, such as /PSP/PHOTO, so i suspect i'm missing something, should i override something else apart ms0: to make XMB happy?
Thanks a lot for your help guys
Alessandro
i'm having a bit of problems with my fileystem and i feel i'm missing something.
I'm loading my code as a custom firmware plugin, so in XMB i got correct filesystem size, but if i try to select for example PHOTO, i only get a request for /DCIM, which is not present, so i return 0x80010002 (no such file or directory). I think that i should be getting other dopen request, such as /PSP/PHOTO, so i suspect i'm missing something, should i override something else apart ms0: to make XMB happy?
Thanks a lot for your help guys
Alessandro
I think there were two fatms drivers. fatms, and fatmsOem (or something like that). Also, i think you should handle the ioctl and devctl of the original drivers...alexp wrote:hi,
i'm having a bit of problems with my fileystem and i feel i'm missing something.
I'm loading my code as a custom firmware plugin, so in XMB i got correct filesystem size, but if i try to select for example PHOTO, i only get a request for /DCIM, which is not present, so i return 0x80010002 (no such file or directory). I think that i should be getting other dopen request, such as /PSP/PHOTO, so i suspect i'm missing something, should i override something else apart ms0: to make XMB happy?
Thanks a lot for your help guys
Alessandro
I'm not writing a new fatms driver, I'm just doing something like this in my plugin:kururin wrote: I think there were two fatms drivers. fatms, and fatmsOem (or something like that). Also, i think you should handle the ioctl and devctl of the original drivers...
sceIoUnassign("msoem0:");
sceIoAssign("msoem0:","pspfs0:",NULL,0, IOASSIGN_RDWR , 0);
sceIoUnassign("ms0:");
sceIoAssign("ms0:","pspfs0:",NULL,0, IOASSIGN_RDWR , 0);
sceIoUnassign("fatms0:");
Strangely enough if i do
sceIoAssign("fatms0:","pspfs0:",NULL,0, IOASSIGN_RDWR , 0);
the memory stick disappear from the xmb menu, anyone knows why?
Alessandro
I'm facing other strange behaviours, i hope someone can explain them to me
i have a DCIM directory in the root of my filesystem, it contains
.
..
101MSDCF <- directory
if i select the MC from the PHOTO menu in XMB, after a dopen & dread call to my filestem i get a call to getstat for /PSP/GAME/101MSDCF%/EBOOT.PBP, is there any reason for that? and most important, then i don't get any more calls, while i was expecting a call to dread for listing the file inside 101MSDCF
Any ideas will be really appreciated, the project is now going fairly well, it's possible from linux to create a directory tree and files around it
i have a DCIM directory in the root of my filesystem, it contains
.
..
101MSDCF <- directory
if i select the MC from the PHOTO menu in XMB, after a dopen & dread call to my filestem i get a call to getstat for /PSP/GAME/101MSDCF%/EBOOT.PBP, is there any reason for that? and most important, then i don't get any more calls, while i was expecting a call to dread for listing the file inside 101MSDCF
Any ideas will be really appreciated, the project is now going fairly well, it's possible from linux to create a directory tree and files around it
hi,
in the end i was successfull in my file system writing attempt, and during the development i found out the meaning of some new devctl and ioctl codes, I want to release the code, so i was wondering what kind of license i can use,
pspsdk is BSD license, i'd like to release my code under GPL2/3 is that possible?
in the end i was successfull in my file system writing attempt, and during the development i found out the meaning of some new devctl and ioctl codes, I want to release the code, so i was wondering what kind of license i can use,
pspsdk is BSD license, i'd like to release my code under GPL2/3 is that possible?
Here it is my really_not_yet_ready filesystem code, i hope it can be useful to anyone
http://allievi.sssup.it/tatiana/pspfs-0.1.tar.bz2
http://allievi.sssup.it/tatiana/pspfs-0.1.tar.bz2
