[UNSOLVED] Bricked PS3 help (twice PSXexploit applied)

Enzo1960 said:
I manually patched nand dump, obtained one checked no errors file that is same as my previous work, so if I flash it in nands I'll obtain same results.
Strange thing that pychecker says file is ok, while PS3 Dumpc Checker says it has ROS0 hash and ROS1 hash errors!
Click to expand...
Ps3 Dump checker is most likely not updated to detect 4.82 ros hash.
The ps3xploit dumps are a different size because they are made with software & the software doesn't allow us to dump the last 16Mb of nand.
The data of a ps3xploit dump is identical to the first 239Mb of a hardware dump.
 
Hello! I searched myself offsets and generate a personal patch based on PS3Xploit dump.
Pychecker says it's ok. Altought PS3 Dump Checker give same 2 errors files are different, so I'll try next days to desolder and reflash nands. If all ok I'll give you details on procedure followed.
 
bguerville said:
Ps3 Dump checker is most likely not updated to detect 4.82 ros hash.
The ps3xploit dumps are a different size because they are made with software & the software doesn't allow us to dump the last 16Mb of nand.
The data of a ps3xploit dump is identical to the first 239Mb of a hardware dump.
Click to expand...
Hello again: I'm reading your reply now. I searched in my 239mb dump a block of 6fffdf size (equal to nofsm patch) with same strings: I found it between 80030 and 78002f.
I saved it as "mypatch.bin".
I used it to patch my complete nand instead of nofsm patch.
Pychecker says all ok. I have no other alternative to desolder nands and flash this new image.
 
I extracted a 6fffdf block size from my PS3xploit dump, from offsets 80030-78002f, and patched with it hardware dump (same work as with nofsm patch). I obteined a valid file, different from previous, pycheck says all ok, PS3 Dump check same 2 errors.
I can desolder and reflash again nands, but, now, I suspect problem could be easily a soldering problem on tsop48 nands.
So, before to do strange things, better is I carefull inspect solders.
Good night from Italy!
 
Hello again! Here results of my quest.
I reflashed nands with my personal patch, obtaing same results of "nofsm" patch. I checked soldering, all ok. I also believed could be an RLOD error, so I reflow PS3 big chips, same results. I desoldered again nands and reflashed with nofsm patch, same result.
So, repeating procedure from very beginning, I obtained this message from Flowrebuilder when it joined nand dumps in one interleaved file:

1 bad block(s) has been found on NAND 0
4 bad block(s) has been found on NAND 1
Could not succesfully extract all Dump files because
probably unscramble operation has failed for this dump.
Part of files has been extracted here:
"C:\tempPS3\nandunitaok.ext"

This means I can use these dumps or this is error?
Could I extract, in any way, useful data from PS3exploit dumps?
My board is SEM-001.

Reading other post on Net seems I must do manual remapping of blocks for this board.
It's a difficult task? I haven't found a guide about this yet...

EDIT:
Waiting I make this try: I joined my 2 nofsm patched bin files again with Flowrebuilder to see what happens: Flowrebuilder give me same bad block numbers for nand, but no errors about unscrambling.
So I compared extracted files in these 2 situations.
Files are almost the same, with only one exception, in "ros" folder.
In "bad" joined nand exist only one subfolder named "ros0", with only 15 files.
In "good" joined nand exists 2 subfolders, "ros0_482.000" and "ros1_482.000", both with 25 files each.
Seems all regular. I verified other files and folders, they are same in files and contents, checked "bootloaders" files, same in dimensions and contents.
 
Last edited:
Enzo1960 said:
Hello again! Here results of my quest.
I reflashed nands with my personal patch, obtaing same results of "nofsm" patch. I checked soldering, all ok. I also believed could be an RLOD error, so I reflow PS3 big chips, same results. I desoldered again nands and reflashed with nofsm patch, same result.
So, repeating procedure from very beginning, I obtained this message from Flowrebuilder when it joined nand dumps in one interleaved file:

1 bad block(s) has been found on NAND 0
4 bad block(s) has been found on NAND 1
Could not succesfully extract all Dump files because
probably unscramble operation has failed for this dump.
Part of files has been extracted here:
"C:\tempPS3\nandunitaok.ext"

This means I can use these dumps or this is error?
Could I extract, in any way, useful data from PS3exploit dumps?
Click to expand...
You can try this to patch a copy of your PS3exploit dump to a full dump that Flowrebuilder can extract.
 
pink1 said:
You can try this to patch a copy of your PS3exploit dump to a full dump that Flowrebuilder can extract.
Click to expand...
Thanks for reply.
I'm trying to follow these instructions but seems a bit confusing:
I'll try to explain my doubts:
1) Extract the dump....etc.
He refer obviously to PS3exploit dump (it misses bootloader). I don't understand why he do this step: files extracted are not mentioned or used further. Go on.
2) Open dump...etc.
He refer this time obviously to my complete dump (268.435.456 bytes) extracted from nands and joined (interleaved) with errors by Flowrebuilder. No doubt on this because in following steps (3,4,5) he extract bootloader, missing in other, shorter, dump.
Go on.
7) Insert bytes...etc.
He says that incomplete dump ends at 0xEFBFFFF, but incomplete dump by PS3Xploit ends at 0xEEFFFFF !
Following steps 8,9,10,11 and checking filesize ending it obviously doesn't match size and "fixed.bin" doesn't result 268.435.456 bytes.

What's my mistake?

EDIT: I solved simply using in step 7 value for bytecount of 1100000, so I obtained
268.435.456 bytes.
But, using FlowRebuilder, despite of this size, still it says that bootloader are missing. :-(
EDIT2: Furthermore, file so obtained give a lot of errors with pychecker.
 
Last edited:
I doubt that the problem is with the fixed interleaved dumps because you already made 2 of them & validated them successfully with no errors or warnings.
pyps3checker would not validate the files if they were not good.
At this stage, I don't really see how fixing more dumps using different techniques will solve the issue tbph.

If you have a validated fixed dump, deinterleave the fixed dump data, flash the nand chips then dump the nands again, interleave the files with FlowRebuilder & finally the resulting interleaved dump contains errors and/or bad blocks, it looks as if the issue might be related to either the rescrambling & file separation process or the nand reading/writing process.
In any case, you should probably check that those processes are done OK.

To check the scrambling & files separation, I suggest you deinterleave a fixed dump into 2 files then interleave them again & then compare the output result with the original fixed dump.

To check the nand reading/writing, deinterleave a validated fixed dump & write the resulting files to both nand chips. Then dump both nand chips & use a binary/hex comparison tool to compare
1. The nand 1 file produced by deinterleaving the fixed dump with the nand 1 dump file.
2. Same with nand.
 
bguerville said:
I doubt that the problem is with the fixed interleaved dumps because you already made 2 of them & validated them successfully with no errors or warnings.
pyps3checker would not validate the files if they were not good.
At this stage, I don't really see how fixing more dumps using different techniques will solve the issue tbph.

If you have a validated fixed dump, deinterleave the fixed dump data, flash the nand chips then dump the nands again, interleave the files with FlowRebuilder & finally the resulting interleaved dump contains errors and/or bad blocks, it looks as if the issue might be related to either the rescrambling & file separation process or the nand reading/writing process.
In any case, you should probably check that those processes are done OK.

To check the scrambling & files separation, I suggest you deinterleave a fixed dump into 2 files then interleave them again & then compare the output result with the original fixed dump.

To check the nand reading/writing, deinterleave a validated fixed dump & write the resulting files to both nand chips. Then dump both nand chips & use a binary/hex comparison tool to compare
1. The nand 1 file produced by deinterleaving the fixed dump with the nand 1 dump file.
2. Same with nand.
Click to expand...
About a reading/writing problem with nands, I always check and binary compare files in nand before and after writing, no difference found.
I used 2 external programmers with same results: TL86II Plus and RT809H, so I can be sure isn't a problem of reading nand chips.
So I'll follow your words about investigate on rescrambling & separation process. I'll let you know results ASAP.
Thank you again for your time.
 
Enzo1960 said:
About a reading/writing problem with nands, I always check and binary compare files in nand before and after writing, no difference found.
I used 2 external programmers with same results: TL86II Plus and RT809H, so I can be sure isn't a problem of reading nand chips.
So I'll follow your words about investigate on rescrambling & separation process. I'll let you know results ASAP.
Thank you again for your time.
Click to expand...
No problem, take your time. ;)
 
You are using Flowrebuilder 5 or newer, correct? It will remap the bad blocks, if they are real. If the bad blocks are from not reading properly, you need to investigate your setup. I have never used that programmer. But maybe investing in a $20 Teensy 2.0 will solve your problems.

edit - I see now that you verified it's not a reading/writing problem. I'm willing to bet your problem is using old version of flowrebuilder. http://www.psx-place.com/threads/flowrebuilder-5-0-by-judges-finaly-available.2811/
 
Last edited:
playerkp420 said:
You are using Flowrebuilder 5 or newer, correct? It will remap the bad blocks, if they are real. If the bad blocks are from not reading properly, you need to investigate your setup. I have never used that programmer. But maybe investing in a $20 Teensy 2.0 will solve your problems.

edit - I see now that you verified it's not a reading/writing problem. I'm willing to bet your problem is using old version of flowrebuilder. http://www.psx-place.com/threads/flowrebuilder-5-0-by-judges-finaly-available.2811/
Click to expand...
Sorry, I always used this last version of Flowrebuilder. :oops:
 
bguerville said:
No problem, take your time. ;)
Click to expand...
I'm back!
I spent all day ago desoldering and soldering several times nands, so to exclude a contact/soldering problem, no success!
I also rechecked reading and writing in both programmers, same results. I also removed and reinserted internal CR2032 battery.
I've done all tries you suggest, files are identical always.
PS3, when I press power button, turn red led in green for about one second, turn in yellow for 1/10 sec about, then beeps 3 times and led become again red and forever flashing.
I've read about famous problem RLOD, so I also reflowed a while big chips, no results. But I read also that nand flash errors give same RLOD.
In my following tries, to speed up the process, I mounted only power supply, fan, not mounting hard disk, wifi module, brdrive. It's correct? PS3 can boot also (show screen) with these components, right?
I'm very frustrated. :-(
 
I must follow one other way to try to solve this problem.
So I tried, instead of Flowrebuilder 5, again PS3 Flash Tool 2.0 by Abkarino.
I interleaved 2 nands with this tool, and checked result with pychecker.
As previous try with FR I obtained warnings about Ros0/Ros1 hash, but this time obtained also one other warning, cell_ext_os_area Break Section.
This tool also give me 2,5 bad blocks instead 1,4 FR found.
I patched file with nofsm patch, Ros hash solved, but cell_ext_os_area Remains..
What's mean? Can I get it from my dumps?

******* Checking cell_ext_os_area *******
011.01 cell_ext_os_area Header : OK
011.02 cell_ext_os_area 0xFF Filled Area 0 : OK
011.03 cell_ext_os_area Break Section : WARNING!
At offset : 0xE780200
Actual data :
> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Expected data :
> 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF
00 00 00 03 FF FF FF FF FF FF FF FF FF FF FF FF
00 00 00 00 00 00 00 00 00 00 FF FF FF FF FF FF
00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF
00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF

011.04 cell_ext_os_area 0xFF Filled Area 1 : OK

EDIT:
Because few values to change, I manually adjusted it with HxD and patched result, so no errors. Later I flash nands with these bins and let you know what happens.
 
Last edited:
playerkp420 said:
You are using Flowrebuilder 5 or newer, correct? It will remap the bad blocks, if they are real. If the bad blocks are from not reading properly, you need to investigate your setup. I have never used that programmer. But maybe investing in a $20 Teensy 2.0 will solve your problems.

edit - I see now that you verified it's not a reading/writing problem. I'm willing to bet your problem is using old version of flowrebuilder. http://www.psx-place.com/threads/flowrebuilder-5-0-by-judges-finaly-available.2811/
Click to expand...
Just wondering could the blocks not be remapped if to many bad blocks have been remapped on one specific nand to many times?
 
I'm having a BIG DOUBT.
Usually people write in Nands with Teensy, E3Flasher, etc.
Now, because these electronics are obviously cheaper and simpler than dedicated external programmers, they are'nt able to manage bad blocks, so exists programs like Flowrebuilder that builds right flow (correct data / bad blocks) to send at nand(s).
Told that, because external programmers, as I'm now using, manage bad blocks in trasparent manner, perhaps this is my error and cause of all insuccess? Perhaps I have TO NO REMAP bad blocks, due to the fact that bad blocks are already managed by programmer?
What you think about?

So, right procedure should be, in my opinion, after patched the interleaved nand with nofsm or other patch, not to use Flowrebuilder to deinterleave in 2 nands, but use options in programmers to write odd/even bits in different nands.
 
Last edited:
Enzo1960 said:
I'm having a BIG DOUBT.
Usually people write in Nands with Teensy, E3Flasher, etc.
Now, because these electronics are obviously cheaper and simpler than dedicated external programmers, they are'nt able to manage bad blocks, so exists programs like Flowrebuilder that builds right flow (correct data / bad blocks) to send at nand(s).
Told that, because external programmers, as I'm now using, manage bad blocks in trasparent manner, perhaps this is my error and cause of all insuccess? Perhaps I have TO NO REMAP bad blocks, due to the fact that bad blocks are already managed by programmer?
What you think about?

So, right procedure should be, in my opinion, after patched the interleaved nand with nofsm or other patch, not to use Flowrebuilder to deinterleave in 2 nands, but use options in programmers to write odd/even bits in different nands.
Click to expand...

I my "theory" should be right, after written and read again nand I would obtain different results. But this not happens, so this theory is wrong.
I tried last chance: I extracted from my first dump (before to attemp succesfully on cfw flashing) ROS0/ROS1 data and patched in unified nand. I obtained a bin file that passed succesfully pychecker controls, so scrambled it again with FR obtaining nand0, nand1 to flash. I also checked that these patched bin files, rescrambled again, will give me same unified nand.
I resoldered these NANDS, but, same results. I reflowed again big chips, no results.
I decided to abandon repair. Too many time spent, and no result.. :-(
Thanks however all people that offered his help.
 
Hello again!
I ask: can I re-open this old post? Or it is better to create a new one?
I still have unsolved my problem but now I think I'm near the solution.
I desoldered both NANDS, mounted via carefully soldered wires to external SOP48->DIP48 adapters socketed so I can effectuate my tries very fast.
If I've permission, I condivide my experiments...
 
Enzo1960 said:
Hello again!
I ask: can I re-open this old post? Or it is better to create a new one?
I still have unsolved my problem but now I think I'm near the solution.
I desoldered both NANDS, mounted via carefully soldered wires to external SOP48->DIP48 adapters socketed so I can effectuate my tries very fast.
If I've permission, I condivide my experiments...
Click to expand...
Is fine to resurrect threads, we dont close them incase other users wants to write something in them :)

Btw, when trying to access flash with an external socket is needed to add a capacitor to the socket (in the V pins), and a couple of resitors in other pins (some of the control pins) to keep them permanently in either LOW (resitor to ground) or HIGH (resistor to V) states

The point is you dont want that control pins in a "inestable" state because could cause problems or interferences, is better to "lock" them with the resistors
 
sandungas said:
Is fine to resurrect threads, we dont close them incase other users wants to write something in them :)

Btw, when trying to access flash with an external socket is needed to add a capacitor to the socket (in the V pins), and a couple of resitors in other pins (some of the control pins) to keep them permanently in either LOW (resitor to ground) or HIGH (resistor to V) states

The point is you dont want that control pins in a "inestable" state because could cause problems or interferences, is better to "lock" them with the resistors
Click to expand...
Thanks for reply!
You're absolutely right!
I suspect now that all my actual problems can depend from this.
I obtained (I'll write after all story) full checked nands but PS3 give me RLOD when I put them in sockets.
I believe that capacitors leaved in original place could be enough to decouple flash chips, but now I add them also in DIP sockets.
About pull up resistors, I've to study datasheet of NANDs to discover what pins have to be pulled up, and resistors value.
Thank you again, I'll let you know soon results.
 
You must log in or register to reply here.

Similar threads

Back
Top