PSP Flash Chip Facts: The Good, the Bad and the Ugly

[chrismulhearn]

Mr.R: I'm tryin!

I have a rather basic, fundamental question that has probably been answered elsewhere.

Typical consumer flash chips have a built in controller that handles the translation between "logical" addresses and "physical" addresses. This allows them to spread out their writes, avoid bad blocks, avoid having to erase every time they want to write, etc...

Sony must be implementing this themselves, right? But where is that translation data stored?

Or perhaps, since they dont write to flash often, they just treat it as a linear memory space (Physical byte #1 = Logical Byte #1) unless they encounter a bad block, which then they skip?

[Dr. Vegetable]

Does anyone know what voltage this chip uses for its io? CMOS 3.3V?

I believe this is correct.

...since they dont write to flash often, they just treat it as a linear memory space (Physical byte #1 = Logical Byte #1) unless they encounter a bad block, which then they skip?

I am not 100% certain, but I believe this is also correct.

[kuroneko]

Sony must be implementing this themselves, right? But where is that translation data stored?

It's stored in the extra data section of each page, i.e. you have 512 bytes payload and 16 bytes which tell the block driver about ECC, logical sector number and all the other stuff etc.

What happens is, that when the driver starts up it has to read all the extra data sections (usually from the first page of each block). From this data it extracts the logical block number which in turn is used to build up a table (index is LBN, value is PBN). Reading works by simple address translation (LBN->PBN). Writing is usually done using a write before erase strategy, i.e. an emtpy block is filled with the data (new/replacement), then the LBN entry is remapped to the new PBN and the old physical block is erased (and goes either back to the free pool are becomes a bad block).

[chrismulhearn]

Sony must be implementing this themselves, right? But where is that translation data stored?

It's stored in the extra data section of each page, i.e. you have 512 bytes payload and 16 bytes which tell the block driver about ECC, logical sector number and all the other stuff etc.

What happens is, that when the driver starts up it has to read all the extra data sections (usually from the first page of each block). From this data it extracts the logical block number which in turn is used to build up a table (index is LBN, value is PBN). Reading works by simple address translation (LBN->PBN). Writing is usually done using a write before erase strategy, i.e. an emtpy block is filled with the data (new/replacement), then the LBN entry is remapped to the new PBN and the old physical block is erased (and goes either back to the free pool are becomes a bad block).

Where did you get this information? What do you mean by "_usually_ the first page of each block" ? Sometimes Sony puts this 16-byte metadata you describe at the first page of each block, and sometimes they don't? That doesnt seem to make much sense. What is the exact format of this 16 bytes of metadata? And where is this data stored? "blocks" in this device are (I'm not sure which) 512 bytes or 256 bytes, not 512+16=528 bytes.

Futhermore, why do people keep refering to "pages" and "blocks" as if they are two different things, but any datasheet on NAND flash seems to use "blocks" or "pages" to talk about the same thing: the minimum addressable unit.

Thanks folks!

[kuroneko]

Where did you get this information? What do you mean by "_usually_ the first page of each block" ? Sometimes Sony puts this 16-byte metadata you describe at the first page of each block, and sometimes they don't? That doesnt seem to make much sense. What is the exact format of this 16 bytes of metadata? And where is this data stored? "blocks" in this device are (I'm not sure which) 512 bytes or 256 bytes, not 512+16=528 bytes.

This is how NAND based block drivers work since the advent of SmartMedia :) While the format of the extra data changes (Samsung has a guideline for this but you're not forced to use it, except maybe the block status) the principle is the same.

As for the location of the extra data, this has nothing to do with Sony. The chose to use FAT12 with a cluster size of 16K which conveniently matches the erase block size (a sensible thing to do in this case). So basically the extra data content is the same for each page except for the ECC of the data (there may be exceptions). Therefore it doesn't really matter which page you extract the extra data from, the first is just as convenient as any other.

The PSP MCP uses a 32MB NAND with the following layout:

Code: Select all

512+16 bytes per page
    32 pages per block (16K+512)
  2048 blocks per device (32MB+1MB)

The main data (512n) is accessed in read mode 0 and 1, the extra data can be reached through read mode 2.

The format of this area was posted in this thread already, just skip back a few postings. Note that the IPL area deviates from the mapping scheme, it is always in the first MB of the NAND. The fact that mapping is used became clear (except that I was expecting it anyway) when I had the chance to look through an incomplete NAND dump (extra data missing). The block arrangement just didn't make sense for an unmapped FAT FS (e.g. FATs at different ends of the devices, boot sectors after the corresponding tables etc).

Futhermore, why do people keep refering to "pages" and "blocks" as if they are two different things, but any datasheet on NAND flash seems to use "blocks" or "pages" to talk about the same thing: the minimum addressable unit.

No, read it again. A block is the smallest erasable unit, a page the smallest writable (programmable). Usually a block holds 32 pages (for the latest small page NAND devices, including the MCP used for the PSP), the newer large page NAND devices have 64 pages each (i.e. 64*(2K+64)).

HTH

[Mathieulh]

ryoko_no_usagi , this might help you :)

http://www.sonyxteam.com/modules.php?na ... opic&t=365

I quoted it just in case you were too lazy to click on the link ;)

from every piece of informations I gathered, here is how the psp updater's elf work:

from 0 to 1% overwrites the IPL using the SCENAND API (The IPL is locates within the data.psp file for updates prior to 2.00 and within the data.psar file in the form of a file called kboot.bin in the updates after 2.00, for the debug units it's given separately with the psar file and it's called kbooti.bin)

Then the updater format the FAT12 flash0 drive to remove every current files on it and starts writting the flash0 files of the newer firmware using fat access thanks to the Scelo API .(that's from 2 to 98%) then from 99 to 100% it will create the new flash1 folders (if not existing) and update the system.dreg and ireg files.
finally it reboots the vshell.

All you need to create a nice 1.50 to 1.00 downgrader is to dump the 1.00 ipl, overwrite it in a 1.50 psp using the scenand API (don't forget to set scenandsetflag to 1 otherwise the nand will remain write protected) then use Scelo API to remove the 1.50 fw files, and then copying the 1.00 fw files from the MS to the flash0 drive, using fat access.
Don't touch the flash1 you wont need to, the fw will generate a new one from himself.

Here you know how to create a working 1.50 to 1.00 downgrader

Don't worry the official sony updater doesn't touch anything else than the IPL within the NAND non fat area (I checked every single opcodes in it and I didn't find anything that suggest me otherwise)

I hope I helped

BTW you can also extract the IPL from the 1.0bogus decrypted data.psp (it's a copyrighted file so I can't share it howevever you can decrypt it using a regular 1.00 psp (1.50 wont work as it doesn't have the keys to decrypt it)) then copy the fw files from the 1.00bogus and you will have the first retail psp to ever run this firmware
(the 1.00 psp were bricked using the untouched official 1.00bogus update from sony, because the updater didn't use scenand to overwrite the IPL as it was meant to be flashed in a debug unit psp and those use external kbooti.bin)

Don't every forget, to each fw version his IPL, do not mix up a fw version with another IPL otherwise the psp wont boot !

BTW Beware that this method still remain untested as you read those lines, however the chances for it not to work (according to the many analysis I have performed on most of the decrypted data.psp) is almost unexistant (there is still a few chances that I might be wrong or mistaken by some unknown factors and that my information wouldn't be 100% accurate but I highly doubt it)

I also wanted to contact yoshihiro regarding the nand dumper sources however he isn't able to do a thing right now thanks to private matters.

Therefore I'll at least give you the current nand dumper binaries, I hope you will make good use of those before you can get the sources.

here it is: http://www.sonyxteam.com/nand/nanddumper.rar

All the credits goes to yoshihiro who coded this very dumper.

BTW there are 2 binaries, one is to dump per pages while the other is to dump per blocks.

about the 1MB missing extra data you can still try to use scenandreadextraonly however I am not entierly sure of the results.

[ryoko_no_usagi]

Thanks for the information, although your approach is not something I really want to attempt. The plus side of only writing the initial part with sceNand and the rest with sceIo is that block remapping etc. are automatic. The downside is that an additional factor of uncertainty is introduced...

I think I prefer to rewrite the whole thing with sceNand...

My problem right now is that I get a read-error on a certain block. I haven't had time to investigate yet. I don't remember getting this when I last worked on the Nand (which was some 1-2 months ago) but maybe I simply didn't pay close attention to read errors then. Unless I figure out exactly what this read error means, I'm not going forward with my flash rewriter. It seems something strange is up with this block. In fact it is the same block that I flagged earlier in this thread as "interesting" because the spare area block_addr is different. sceNandIsBadBlock() does not flag it as bad...

All of the sceNand-API is pretty clear to me, although I still miss a few details (such as the nature of this particular read error.) sceNandReadExtraOnly() reads the whole spare area to a buffer, including the the user area ECC. For some reason, the user area ECC is excluded when reading with sceNandReadBlock/Pages() functions. My guess is that it's calculated and verified by hardware, so less reason to pass it along when reading blocks, and I haven't seen any software calculations for it and it would make sense speed-wise. I still have some reversing left to do though...

[Mathieulh]

Yoshihiro allready tried to dump the whole nand (using the dumper I posted ahead) and write it back into a psp with no success, but that might be because it misses the extra data.

about only writting the IPL using scenand and then writting the rest using SceIo I can assure you that that's exactely what the official sony updater does, it doesn't do anything else than the procedure I described on my previous post (I spent a LOT of time looking at the disassembled decrypted 2.00 data.psp (the old one) to be about 99.9% sure about that...) . Thus only writting the IPL and then using SceIo to write the fw files is way safer than overwritting the whole nand and keeps the original region and psp serial number of the targeted psp (that's not the case by overwritting the whole nand)
However it might still be handful to understand how the remaining non fat area within the NAND chip works.

I have no clues about the bad block you encounter, try to share your dumper here and I'll dump my own nand and tell you if I do encounter the same error. The fact that sceNandIsBadBlock doesn't report your block as bad is weired, this shouldn't occur...

[ryoko_no_usagi]

Obviously if the spare area metadata is missing there is no way that rewriting the flash could work!

The "bad" block I encounter is after the IPL so maybe it's possible to write just the IPL and ignore the rest. Whether to do sceIo or sceNand for the FAT area is not really important since the FAT area is completely mapped and understood, but yeah, do it with sceIo should be safer.

Since I'm not going to test the software myself, I will not release anything that I'm not very confident will work, and even if you assure me that only the IPL part is rewritten by the updater, I still want to have a better understanding of the remaining data.

It's not really weird that sceNandIsBadBlock() wouldn't report the block as bad. After all, sceNandIsBadBlock() only reads the spare area and checks the block_stat byte. If the error is because (and this is just an example) user area ECC failure then sceNandIsBadBlock wouldn't complain.

Another possibility is that that block is OTP and that this is indicated when reading (the error code is set from looking at a hardware register.) You talk about region code. Can you share any more info on that? Looking only at the dump I didn't notice anything that looked like region code, certainly not in the block in question (in fact the data there looks quite "weird" to me...) but if region is specified in this way it would make sense to put it in an OTP block for security...

Anyway, I compared a dump of my 1.5 with that from your 1.5 that was floating around before, and the data after the IPL is different in the two dumps. Not all of it, in fact some of the data is identical and the general structure seems the same, but specific data is different and in different locations...

It would be interesting to see the spare area data from your fw for that block...

[johnmph]

Code: Select all

#define	SAVE_FILE

int main (int argc, char *argv[])
{
 u32 blkTotal, blkSize, blkRead, blkWrite, blkReadF, blkWriteF;
 u32 pagePerBlk, pageSize, pageSizeE, pageAddr, extraSize;
 u8 *block;
 int fd, x, y;


 // Init display and HOME button
 pspDebugScreenInit();
 pspDebugScreenClear();
 SetupCallbacks();

 // Setup Pad
 sceCtrlSetSamplingCycle(0);
 sceCtrlSetSamplingMode(0);

 // Initialize variables
 extraSize = 16;
 blkTotal = sceNandGetTotalBlocks();
 pagePerBlk = sceNandGetPagesPerBlock();
 pageSize = sceNandGetPageSize();
 pageSizeE = pageSize + extraSize;

 blkSize = pageSizeE * pagePerBlk;
 blkRead = blkWrite = 0;
 blkReadF = blkWriteF = 0;

 printf("Total blocks : %d\nPage per block : %d\nSize of a page (without extra) : %d\nSize of a page (with extra) : %d\nSize of a block : %d\n\n",blkTotal,pagePerBlk,pageSize,pageSizeE,blkSize);

#ifdef SAVE_FILE

 // Open file
 fd = sceIoOpen("ms0:/nand.bin",PSP_O_WRONLY | PSP_O_CREAT | PSP_O_TRUNC,0777);
 if &#40;fd < 0&#41; return 1;

#endif

 // Get buffer for a block
 block = &#40;u8 *&#41; malloc&#40;blkSize&#41;;
 if &#40;!&#40;block&#41;&#41;
 &#123;
  sceIoClose&#40;fd&#41;;
  return 2;
 &#125;

 printf&#40;"Begin ...\n"&#41;;

 // Read loop
 for &#40;x=0;x<blkTotal;x++&#41;
 &#123;
  // Look nand
  sceNandLock&#40;0&#41;;

  // Get the page address
  pageAddr = x * pagePerBlk;

  // Check block
  if &#40;sceNandIsBadBlock&#40;pageAddr&#41;&#41; printf&#40;"Bad block &#58; %d\n",x&#41;;
  /*if &#40;!&#40;sceNandIsBadBlock&#40;pageAddr&#41;&#41;&#41;
  &#123;*/
   // Update good block counter
   blkRead++;

   // Read the block
   //if &#40;sceNandReadBlockWithRetry&#40;pageAddr,block,&block&#91;sceNandGetPageSize&#40;&#41; * pagePerBlk&#93;&#41; >= 0&#41;
   //if &#40;sceNandReadPages&#40;pageAddr,block,&block&#91;sceNandGetPageSize&#40;&#41; * pagePerBlk&#93;,32&#41; >= 0&#41;		// Same
   for &#40;y=0;y<pagePerBlk;y++&#41;
   &#123;
	//sceNandReadPages&#40;pageAddr + y,&block&#91;pageSizeE * y&#93;,&block&#91;pageSizeE * y&#93; + pageSize,1&#41;;
    sceNandReadPages&#40;pageAddr + y,&block&#91;pageSizeE * y&#93;,NULL,1&#41;;
    sceNandReadExtraOnly&#40;pageAddr + y,&block&#91;pageSizeE * y&#93; + pageSize&#41;;
   &#125;
 //  &#123;
#ifdef SAVE_FILE

	// Write block in file
	sceIoWrite&#40;fd,block,blkSize&#41;;

#endif

    // Update write block counter
	blkWrite++;
   /*&#125;
   else
   &#123;
	blkWriteF++;

	printf&#40;"Unable to read block &#58; %d\n",x&#41;;
	waitButton&#40;PSP_CTRL_CROSS,0&#41;;
   &#125;
  &#125;
  else
  &#123;
   blkReadF++;

   printf&#40;"Invalid block found &#58; %d\n",x&#41;;
   waitButton&#40;PSP_CTRL_CROSS,0&#41;;
  &#125;
*/
  // Unlock nand
  sceNandUnlock&#40;&#41;;
 &#125;

#ifdef SAVE_FILE

 // Close file
 sceIoClose&#40;fd&#41;;

#endif

 // Free buffer
 free&#40;block&#41;;

 printf&#40;"Terminated\nBlocks read &#58; %d\nBlocks written &#58; %d\nBad blocks &#58; %d\nBlock read failed &#58; %d\n",blkRead,blkWrite,blkReadF,blkWriteF&#41;;
&#125;

I think also like you that bad block is just an one time programmable block for information like region.

I have a bad block (1342) and 100 blocks which cannot be read (maybe alternate blocks for defective blocks).

If you want to write all flash with nand api, i think you must write only the good blocks (no alternate/bad blocks) and verify before each block that you write if the destination block is not an defective block and if it's the case, you must move it to an alternate block and write the information (logical address, ..) in extra data.

You can also read extra data with sceNandReadPages (second buffer) but you will not have the first four bytes.

Maybe that these extra data are the same ones that for the nand of a memory stick (see doc on the memory stick).

[ryoko_no_usagi]

After some pondering, I realized that the read error I'm getting is the standard "user ECC incorrect" (80230003) and the reason I get that is because I read the whole block using sceNandReadBlock(), but this section appears to only use page mapping, because most of the block is all 1s and so reading the whole block causes that error.

From your description it would seem that those 100 blocks you say you can't read are simply empty blocks (all 1s) and so the hardware ECC calculations fail and the read returns an error (even though nothing is wrong.)

My PSP does not have any bad blocks, and I was planning to make my reflasher read the nand and only accept bad-block-free nands where the ECC indicates no bit errors. Empty blocks I would simply skip (or erase). It seems that for the above section, writing per page should be done instead.

Of course one also has to make sure the target nand has no bad blocks either, or things are gonna get screwed up. Doing what Mathieulh suggested and write the FAT area with sceIo instead would work arond that though.

[kuroneko]

From your description it would seem that those 100 blocks you say you can't read are simply empty blocks (all 1s) and so the hardware ECC calculations fail and the read returns an error (even though nothing is wrong.)

That's odd. What if the user data is all 1s (as opposed to simply empty)? Perfectly possible and I certainly wouldn't want to fail the ECC check for that ...

If it really is an empty block (all 1s in user and extra data) then you definitely won't get an ECC error (the ECC for all 1s is (usually) 0xFFFFFF, so any check will pass). It looks more like they simply misuse this error code to stop you from reading unassigned blocks (which is fair enough).

[ryoko_no_usagi]

The ECC for all 1s is actually all 0s, so it does give an ECC error if the block is completely empty.

Oh, and that "weird" block is starting to make more sense to me now :)

[kuroneko]

The ECC for all 1s is actually all 0s, so it does give an ECC error if the block is completely empty.

This surely depends on your algorithm. All the ones I've seen are written so that all 0s or all 1s result in 0xFFFFFF (512bytes), i.e. the actual ECC is returned as (ECC xor -1). Which means it is zero but is stored as -1.

I'm not trying to argue this issue, personally I don't get why even and odd pairs are stored interleaved, it's a pain to extract later for correction. Maybe it's more convenient for a h/w implementation.

Edit: I just had a look at some extra data samples, and it seems that Sony is doing it differently from everybody else, e.g. the value 0x005000 results in an ECC value of 0xF082, while my code results in 0xFF7D which is the inverted ECC value (0xF000 is the fill pattern for the 12bit ECC).

Apologies. They are really going out of their way ;)

[Mathieulh]

The psp region and serial number are located within the nand non-fat area (using an ecrypted form) Beside I still think that writing the flash my way is the most efficient, the safest and the only one allowing to flash non-retail fws (useful to sce licenced developers) finally a scenand-free way to write the ipl would be to use the IPL:// drive (yes this drive exists !) but when i dump its content i only dump the ram where i should dump the ipl in its binary form and i didn t test to write the ipl on it, thus I need your help to get further understanding of the IPL:// device (all I know is that it can be used by sony to write into the IPL area (this device is to write the ipl in), that the data.psp updater mounts it and that its path is hardcoded within the data.psar file.

I think it's another way used by sony to flash the IPL in replacement of scenand.

[Mathieulh]

just a little update: I successfully downgraded my psp-1004 (european) to fw 1.00 using the method I described above :) (I know I have been foolish :p ) beware I only tested it on my psp there are no way to know if it will work on yours !

[danzel]

hahaha nice work :D

[ryoko_no_usagi]

Oh cool! Congrats! I'm not gonna attempt this myself though, because, well, a) I have no use for 1.0 (or a brick!) and b) I don't have a source 1.0 firmware :)

I'm really interested in the region lock though. That's something I need to investigate further.

[Mathieulh]

You are going to need a lot of luck to find where the region is located, because even if you know that it's located within the non-fat nand area in an encrypted form, it's still a lot of data to investigate, especially as we do not know what the region's encryption is based on, (it could be encrypted using the psp serial number, the psp dictionnary (within the nand) and any other stuffs that could make it encrypted using a unique key per psps...) Beside I can tell you for sure that the region is not within the psp EEPROM as Yoshihiro allready managed to dump its content and and wrote a european EEPROM data into a USA psp and it didn't change the region, that's the proof the region isn't there, beside the EEPROM content changes ALL THE TIME, my guess is that it's used for service supply, it tells them what are the lastest programs/games you ran, what was your ram checksum when you last switched off your psp, how many times you did write to the nand (witch might means the number of times you updated your psp, unless of course you did some weired stuff with your nand that sony isn't aware off, but even if it's the case it's not accurate due to the fact that it must count flash1 (the settings) too.
It might also supply other pieces of informations I am not aware of.
My guess is the EEPROM is totally blank the first time you switch on your psp and then the psp hardware (and maybe software) generate an EEPROM image and write stuffs in it.

It would be way more convenient and effective for sony to store both the region and the serial within the nand where it's a better place to hide those, beside the nand is written within the factory (separetely for each nand) using some kind of jtag interface on the psp mobo, so generating a costum serial number and a specific region at each nand flash isn't difficult.

Finally I don't see the point in changing the psp region as if you can run code in a psp (kernel mode of course) then you can easely override the psp region limitations using software.

[Dr. Vegetable]

Could the "IPL://" device be used to rewrite the IPL from user mode?

[Mathieulh]

Could the "IPL://" device be used to rewrite the IPL from user mode?

Well it might (it's very likely) , however the problem would be to access the flash0:// device and using a game exploit (such as the one in GTA) isn't possible because the word "flash" is illegal (this is because of sony who added a "security" fix in the 1.51 fw thanks to people using wipeout browser to access the flash... ) so using it to assign it or anything else will most likely freeze your psp

(I got this nice piece of information thanks to yoshihiro who spent a lot of time working on the gta exploit)

[KPOT0B]

But the updater gets access to flash0:// somehow. Guess does it from userspace. Does that means that there rights for app also encripted in?

[Dr. Vegetable]

...the problem would be to access the flash0:// device and using a game exploit (such as the one in GTA) isn't possible because the word "flash" is illegal...

Do you know at which point they check for the word "flash"? Is the device itself disabled, or do they simply reject any saved game that contains the string "flash"?

[Fanjita]

But the updater gets access to flash0:// somehow. Guess does it from userspace. Does that means that there rights for app also encripted in?

The updater runs in a dedicated mode, with a different set of modules loaded, compared to VSH or GAME.

So there's no reason why it would need to be subject to the same restrictions on flash access.

[Mathieulh]

...the problem would be to access the flash0:// device and using a game exploit (such as the one in GTA) isn't possible because the word "flash" is illegal...

Do you know at which point they check for the word "flash"? Is the device itself disabled, or do they simply reject any saved game that contains the string "flash"?

All I know is that the limitation comes from the firmware itself that disable the flash device and set the string "flash" as illegal as soon as a game is started, that means that even the game conceptors have no way to access the flash, that's probably why you can find modules on UMDs.
Beside now since SDK 2.0.0 the game programmers are forced by sony to run their games in user mode (for instance GTA is a full user mode game) , no more kernel mode games are allowed by SCE, still old full kernel mode games remain such as ridge racers or wipeout but they cannot access the flash either if you run those usin fw 1.51 or higher.

There might still be other ways to access the flash in usermode such as using vsh functions but they remain unknown for now.

BTW: I think Fanjita is right about the dedicaced mode however it must be pretty close to the kernel mode, it needs at least to use scenand, sceIo, have access to the vsh modules, access rco files....

I also believe that the kernel mode (or a similar mode) can only be accessed from 2.00 (or higher) fw if the elf is running from the ms0://PSP/UPDATE/ folder and I think that the ms0://PSP/UPDATE/ folder is restricted to the "update key" and only elfs encrypted with this key are allowed to run from that folder.
Other elfs are forced to run in usermode only (exept the ones from the update folder and the ones located on the disc0:// device.... ) (the limitation is set within the IPL, browse a 2.00 (or higher) decrypted IPL and see for yourselves)

[TyRaNiD]

No games afaik run in kernel mode, not even ridge racer. And anything running in the update folder runs in VSH mode which gives a few more permissions and functions.

[Mathieulh]

Thanks for the infos tyranid, I thought that ridge racers ran in kernel mode, I guess I was mistaken :/

[Fanjita]

Games (or at the very least, GTA) have full read access to the flash. They just can't write to flash0.

The thing that seems to be missing is that they can't use sceIoAssign to remount and thereby enable write access. They also don't have access to the flashfat device.

But you can use sceIoOpen on "flash0:/*" and "flash1:/*" without any extra steps required, those devices appear to be present by default.

[Mathieulh]

it might be possible to code a driver that would mount back the flash0 and flash1 devices however I doubt that we can load decrypted drivers using gta (might be possible tough....)

A way to figure out how sony mounts the flash devices and uses the IPL:// device would be to log a running update (by loading a driver in the 1.50 psp and then loading the 2.00 update's elf for instance)

Also, yoshihiro gave me the information that in order to run an update from an running eboot you need to reload the vsh modules as the updater needs those because unless the eboot runs from ms0://PSP/GAME/UPDATE/ the vsh modules get unloaded.

Anyway logging an update durring its updating process might be very helpful and gives us more intels than spending hours on a disassembled updater's elf.

BTW: You still need to be careful doing that, the logging driver mustn't use too much ressources otherwise it's very likely that the updater hangs durring its process (and brick your psp)

[Mathieulh]

A few more infos about the updater, the updater itself doesn't do the "update" job, it's only a frontend that calls embebed modules within the data.psp file to flash the data.psar content to the nand, there are 10 of those modules (in the 2.00 updater) those are:

- sceChkuppkg (I am not sure about this one, but my guess is that it performs checksums of the eboot.pbp file as well as the data.psar file and checks for the data.psar file version)

- sceLflashFatfmt (One of the most interesting modules, it's the one that actually uses SceIo to write fw files to flash0://)

- IplUpdater (that's the most interesting module, that's the one that uses scenand to write the IPL in ;) )

- sceTestMode (that's a driver, but I don't know what it's for, it still obscure to me however afaik it doesn't write to the nand)

- sceSuspendCanceler (that's the module that disables the sleep mode, nothing much interesting about it tough)

- scePSAR (that's no more than the psar lib, that's the module responsible for decrypting the psar file (using fw keys) and accessing its content)

- LeptonUpdater for 103 (I don't know what the heck this module is but I assume it's to run on a psp 1.0.3 (aka psp 1.00)

- LeptonUpdater for 150 (the same module for 1.50 and higher fws)

- sceReboot That's the driver that reboots your psp when you press X (at the end of the update) or when you choose to cancel the update, BTW this module slightly changes from the 1.50 updater to the 2.00 updater)

- sceUmdEx (that's the UMD driver, to be more specific that's the one that will suspend the update if the UMD is removed, and resume it if the UMD is back into its reader)


I hope it helped :)

Mathieulh Allways at your disposal ;)

UPDATE: It appears that LeptonUpdater modules are meant to update the flash1:// content (as the original flash1 get patched to keep the previous settings, it needs a specific modules per flash1 version)

UPDATE (again) : I checked the 2.60 update a little an there seems to be 2 more modules that are:

- coldreset_updater

- SecureRtcReset

I still don't know what those modules are for :/

I guess you will have to find it yourselves :)