| View previous topic :: View next topic |
| Author |
Message |
moonlight
Joined: 26 Oct 2005 Posts: 567
|
Posted: Mon Jun 12, 2006 4:42 am Post subject: sceLflashFatfmtStartFatfmt |
|
|
I've logged the call to this function during an "update" process from 1.50 to 1.50 (contrary to what some people think, the update from 1.50 to 1.50 doesn't brick any psp)
The usage is very simple
| Code: |
int sceLflashFatfmtStartFatfmt(int argc, char *argv[])
|
And the updater did something like this to call it:
| Code: |
char *argv[2];
argv[0] = "fatfmt";
argv[1] = "lflash0:0,0";
vshLflashFatfmtStartFatfmt(2, argv);
|
Note that the updater uses his own version of lflash_fatfmt.prx, and not the one that come with the firmware(which by default is not loaded).
I don't know if there are differences between them.
Also, don't play too much with this function if you don't know what you are doing ;) |
|
| Back to top |
|
 |
dot_blank

Joined: 28 Sep 2005 Posts: 498 Location: Brasil
|
Posted: Mon Jun 12, 2006 10:49 am Post subject: |
|
|
wait so is it sceLflash* or vshLflash* ?
thanx in advance for clearing this up _________________ 10011011 00101010 11010111 10001001 10111010 |
|
| Back to top |
|
 |
moonlight
Joined: 26 Oct 2005 Posts: 567
|
Posted: Mon Jun 12, 2006 3:27 pm Post subject: |
|
|
| dot_blank wrote: | wait so is it sceLflash* or vshLflash* ?
thanx in advance for clearing this up |
They are the same.
All functions from vshbridge simply set the kernel mode, then call the real function from other module. Then, restore the mode and return the result.
The vshbridge lets the vsh modules(like the updater) to call some functions that are available only for kernel mode, like some loadexec functions , some loadmoduleVSH functions and other. Even there is some idstorage function over there.
I guess that the name suggests it: It's like a bridge between the kernel and the vsh. :) |
|
| Back to top |
|
 |
dot_blank

Joined: 28 Sep 2005 Posts: 498 Location: Brasil
|
Posted: Mon Jun 12, 2006 4:52 pm Post subject: |
|
|
yes indeed thank you _________________ 10011011 00101010 11010111 10001001 10111010 |
|
| Back to top |
|
 |
moonlight
Joined: 26 Oct 2005 Posts: 567
|
Posted: Mon Jun 12, 2006 7:06 pm Post subject: |
|
|
Also, the 1.50 updater call to these functions from iplupdate.prx:
sceIplUpdateClearIpl() -- no parameters, it erases the blocks of the ipl.
sceIplUpdateSetIpl() -- no parameters. it writes the 1.50 ipl which is embedded in the own iplupdater.prx (contrary to the +2.00 updaters, where the ipl is in the psar)
The iplupdater also exports sceIplUpdateUpdateIpl, but the updater doesn't import it, and it seems that it's not called, it doesn't seem to be an export available for vsh mode. (maybe it's called inside the iplupdater, but i haven't seen that call). Looking at the dissasembly, that function doesn't write to the flash, not at least using the sceNand functions.
Another difference between the 1.50 updater and the 2.XX updaters, is that the iplupdater from 1.50 doesn't use any verification function from sceNand, like sceNandVerifyEcc, etc. (I don't know if it does another kind of verification).
In theory, and only in theory, we can use the following procedure for a 1.00 downgrader:
- Extract iplupdater.prx and flashfmt.prx from the 1.50 update.
- Load them, and hack in ram the iplupdater.prx writing the 1.00 ipl on its "iplbuffer", which is easy to locate looking at the disassembly.
- call sceLflashFatfmtStartFatfmt
- Write the flash0 files of an 1.00 dump using sceIo
- call sceIplUpdateClearIpl
- call sceIplUpdateSetIpl
Using sony code to write the ipl and formatting the flash prior to writing the files should be safer, but it won't be me who tries it :) |
|
| Back to top |
|
 |
dot_blank

Joined: 28 Sep 2005 Posts: 498 Location: Brasil
|
Posted: Tue Jun 13, 2006 10:38 am Post subject: |
|
|
yes you are most right ...great stuff :) _________________ 10011011 00101010 11010111 10001001 10111010 |
|
| Back to top |
|
 |
|