-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DC10 - Physical formatting of PSP Go system storage #351
Comments
NAND and ef0 are not on the same chipset formatting ef0 would not do anything. You can (back up your nand first) adjust the lflash values and try to force a format of the bad blocks with adjusted values. Then resize them to defaults and format again. Bad blocks are expected though so some bad blocks are just from manufacturing defects. |
Thank you for your reply! Your idea about resizing sounds good - can I go as high as 16GB on one partition? |
I just took a look at it, but I can't go higher than the default values in the LFlash formatting settings. |
yeah..... Go only has 64MB I meant make the values smaller to non standard 512 bs to try to overwrite the bad sectors. |
But that wouldn't help me if I'm not mistaken. My hope is that skips the bad blocks I have in that area which (probably) prevent me from formatting it within the VSH. My understanding of the NAND layout is like this:
It would be awesome if the LFlash formatting could be expanded to go past the flash3 barrier. |
Okay your not really getting what nand is it seem, however adding formatting ef0 would produce the same results that xmb does as we use Sony syscalls for all functionality. |
He has a point though, I always thought ef0 was part of nand in PSP Go. It makes sense, why have two separate chips. |
I'm no expert you are correct :( |
Is it not tho? |
there is to format but not resize, though I wonder what would happen if it was formatted as fat16 instead of 32 would be interesting. |
If you can implement that, I'm happy to try it :D |
Are you in the discord? I have something you can test if you wish. |
Implemented via PSP Tool, however due to eMMC being fully corrupted will no longer format successfully. |
New Feature
I have a PSP Go, where the NAND has suffered severe deterioration over time, in form of bad blocks.
It started with corrupted save games and got to a point, where the PSP was requesting me to format the system storage upon boot.
After some time and multiple reformats later, it wasn't able to recover the system storage again and just gave out an error while trying to format it again (Format failed. (802E100A)).
It got worse and worse over the span of a few months, until the PSP didn't boot anymore.
I read online that people fixed their regular PSPs bad blocks with DC in the past, thanks to the "Format LFlash" feature, which probably causes the PSP (or the NAND controller) to skip bad blocks after formatting.
Thanks to your work on DC10 and Baryon Sweeper, I was able to ressurrect this PSP Go from the dead by formatting the LFLash and doing a clean install of the FW.
Unfortunately the system storage formatting error remained and there is nothing I can do as a user to fix it with the available software.
My first idea was to replace the NAND, but the part seems to be custom made for the PSP Go and prices for spare parts (in form of defective boards/consoles) have risen over time, since the PSP Go became a rare system, due to its short life span and low sales.
My last hope is this feature request here, with which I would like to suggest an additional option in the "NAND Operations" menu, which enables the user to do a physical format of the system storage (ef0:), in the same way that the "FLash Format" feature formats the LFlash.
My hope is that such a physical format will signal the NAND (or its Controller), to skip the bad blocks in the system storage and allow the PSP to format the space again.
If such a feature is feasible to implement into DC10, I would be forever grateful.
Please let me know what you think about it, or if you need further information or if you have anything to test.
Thank you and please keep up the great work!
The text was updated successfully, but these errors were encountered: