Skip to content
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

Open
MRiCEQB opened this issue Apr 24, 2024 · 13 comments
Open

DC10 - Physical formatting of PSP Go system storage #351

MRiCEQB opened this issue Apr 24, 2024 · 13 comments

Comments

@MRiCEQB
Copy link

MRiCEQB commented Apr 24, 2024

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)).

IMG-20240423-WA0014

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!

@MRiCEQB MRiCEQB changed the title DC10 - Physical formatting of PSP Go mass storage DC10 - Physical formatting of PSP Go system storage Apr 24, 2024
@krazynez
Copy link
Collaborator

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.

@MRiCEQB
Copy link
Author

MRiCEQB commented Apr 24, 2024

Thank you for your reply!
Are you sure that NAND and ef0 are not on the same chip?
The PCB of the Go doesn't hold many chips and there is only one that looks like flash (on the right side the big Samsung chip):

image

Your idea about resizing sounds good - can I go as high as 16GB on one partition?
What happens to the IDStorage if I go too high?

@MRiCEQB
Copy link
Author

MRiCEQB commented Apr 24, 2024

I just took a look at it, but I can't go higher than the default values in the LFlash formatting settings.
I can only manipulate the sizes within that 64MB window :(

@krazynez
Copy link
Collaborator

I just took a look at it, but I can't go higher than the default values in the LFlash formatting settings. I can only manipulate the sizes within that 64MB window :(

yeah..... Go only has 64MB I meant make the values smaller to non standard 512 bs to try to overwrite the bad sectors.

@MRiCEQB
Copy link
Author

MRiCEQB commented Apr 24, 2024

But that wouldn't help me if I'm not mistaken.
Because the OS side of things works now.
What I want to do is do a physical format of the system storage area of the flash chip.

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:

  1. IPL
  2. IDStorage
  3. flash0
  4. flash1
  5. flash2
  6. flash3
  7. System Storage (PSP Go only).

It would be awesome if the LFlash formatting could be expanded to go past the flash3 barrier.

@krazynez
Copy link
Collaborator

But that wouldn't help me if I'm not mistaken. Because the OS side of things works now. What I want to do is do a physical format of the system storage area of the flash chip.

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:

1. IPL

2. IDStorage

3. flash0

4. flash1

5. flash2

6. flash3

7. System Storage (PSP Go only).

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.

@JoseAaronLopezGarcia
Copy link
Contributor

But that wouldn't help me if I'm not mistaken. Because the OS side of things works now. What I want to do is do a physical format of the system storage area of the flash chip.
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:

1. IPL

2. IDStorage

3. flash0

4. flash1

5. flash2

6. flash3

7. System Storage (PSP Go only).

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.

@MRiCEQB
Copy link
Author

MRiCEQB commented Apr 24, 2024

But that wouldn't help me if I'm not mistaken. Because the OS side of things works now. What I want to do is do a physical format of the system storage area of the flash chip.
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:

1. IPL

2. IDStorage

3. flash0

4. flash1

5. flash2

6. flash3

7. System Storage (PSP Go only).

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.

I'm no expert you are correct :(
But I believe what you are saying.
So there are no syscall(s) available to resize/repartition ef0?

@MRiCEQB
Copy link
Author

MRiCEQB commented Apr 24, 2024

But that wouldn't help me if I'm not mistaken. Because the OS side of things works now. What I want to do is do a physical format of the system storage area of the flash chip.
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:

1. IPL

2. IDStorage

3. flash0

4. flash1

5. flash2

6. flash3

7. System Storage (PSP Go only).

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.

Is it not tho?
Looking at the PCB, I only see one flash chip.

@krazynez
Copy link
Collaborator

But that wouldn't help me if I'm not mistaken. Because the OS side of things works now. What I want to do is do a physical format of the system storage area of the flash chip.
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:

1. IPL

2. IDStorage

3. flash0

4. flash1

5. flash2

6. flash3

7. System Storage (PSP Go only).

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.

I'm no expert you are correct :( But I believe what you are saying. So there are no syscall(s) available to resize/repartition ef0?

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.

@MRiCEQB
Copy link
Author

MRiCEQB commented Apr 24, 2024

But that wouldn't help me if I'm not mistaken. Because the OS side of things works now. What I want to do is do a physical format of the system storage area of the flash chip.
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:

1. IPL

2. IDStorage

3. flash0

4. flash1

5. flash2

6. flash3

7. System Storage (PSP Go only).

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.

I'm no expert you are correct :( But I believe what you are saying. So there are no syscall(s) available to resize/repartition ef0?

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
Anything that touches/formats the system strage I'm willing to try.

@krazynez
Copy link
Collaborator

krazynez commented May 2, 2024

But that wouldn't help me if I'm not mistaken. Because the OS side of things works now. What I want to do is do a physical format of the system storage area of the flash chip.
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:

1. IPL

2. IDStorage

3. flash0

4. flash1

5. flash2

6. flash3

7. System Storage (PSP Go only).

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.

I'm no expert you are correct :( But I believe what you are saying. So there are no syscall(s) available to resize/repartition ef0?

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 Anything that touches/formats the system strage I'm willing to try.

Are you in the discord? I have something you can test if you wish.

@krazynez
Copy link
Collaborator

krazynez commented May 4, 2024

Implemented via PSP Tool, however due to eMMC being fully corrupted will no longer format successfully.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Todo
Development

No branches or pull requests

3 participants