[specialmio]

I have this:
Desolder the two NAND from mainboard ..... Read with my wellon vp-990 programmer and save the dump0.bin and dump1.bin.... Erase and blanc check NAND .... Re-program NAND with dump0.bin and dump1.bin.... Solder on mainboard and ps3 work perfectly

I consider that my dump is valid and my programmer read and write perfectly ....I'm sure the problem is the algorithm in flow rebuilder

[Sarah1331]

Originally Posted by specialmio I have this: Desolder the two NAND from mainboard ..... Read with my wellon vp-990 programmer and save the dump0.bin and dump1.bin.... Erase and blanc check NAND .... Re-program NAND with dump0.bin and dump1.bin.... Solder on mainboard and ps3 work perfectly I consider that my dump is valid and my programmer read and write perfectly ....I'm sure the problem is the algorithm in flow rebuilder

No it's not your not getting it
Bad block is physical error 99% of time its broken hardware read up on badblocks when syscon finds badblock it remaps the data to a good block and keeps that info stored so it knows where to find the data

So If you read the NAND..
E.g
If Block 10 is bad and been remapped to block 13

Your dump still has block 10 data in block 13

If you erase the NAND and repair the NAND or replace the tsop

Flash the dump back it still has data of block 10 at 13

You need to remap the block will you listen this is why I don't want to make a tut because people won't listen and accept its harder than it sounds

You need to join the two nands find bad blocks and remap to correct location
Patch the image
Split the nands
Write the images back to good NANDs

If you are using same nands with badblocks then you need to
join the two nands find bad blocks and remap to correct location
Patch the image
Put the bad blocks that you put in correct location
back where you just found them
Split the nands
Write the images back to nands with bad blocks so it all matches up again

Flo rebuilder is fine you need to manually find bad blocks and remap them this is the hard part



Sent from my iPhone 5 using Tapatalk

[specialmio]

I nor can to join two dump .... Flow rebuilder give me error and can to continue

[cuIstomizer]

Originally Posted by specialmio I nor can to join two dump .... Flow rebuilder give me error and can to continue

When you join two dumps (even if they're bad blocks) you can continue ...

From experience, flowrebuilder's process continues after the error message. You'll always have your two dumps in one file but you miss the files in the folder xxxx.Ext. (files like metldr, bootloader ...)

In effect, mapping block is very very harder and you'll spend a lot of time.

Good luck

[Sarah1331]

I said this all along the error is that florebuilder hasn't extracted data



Sent from my iPhone 5 using Tapatalk

[guerrierodipace]

I am not expert but can someone post more details about bad block on ps3?
how recognize and manage badblock?
In xbox360 there's documentation about.
I found this basic information:
http://www.eetasia.com/ARTICLES/2004...9_MEM_AN06.PDF
http://139.138.48.19/pdf/NAND/Toshib...nGuide.pdf.pdf
http://wiki.laptop.org/go/NAND_Flash_Bad_Block_Table

and naturally samsung ps3 nand datasheet http://www.trisaster.de/file/sony/ps...K9F1G08U0A.pdf

for example I don't know is this apply also at ps3 nand:

The standard factory location for the bad block byte is byte 517 (the 518th byte) of a NAND page. If this byte is FFh, the block is good, otherwise, the block is bad (typically indicated by 00h). This format for marking bad blocks is from SmartMedia card (NAND flash in a removable card package) and was standardized by the SSFDC Forum (Solid State Floppy Disk Card – the former name of SmartMedia). If additional bad blocks form during use, the block is marked bad. Generally, this is possible even if the block that you are marking is considered bad. To distinguish between factory marked bad blocks and blocks that go bad during use, two flag values are defined in the SmartMedia format: 00h (for initial factory marked bad blocks) and F0h (for blocks that go bad during system use). An alternative approach to the “in block” method of keeping track of bad blocks is to maintain a bad block table. However, where to you store a bad block table since blocks could be bad? For NAND TSOP devices only, the first block of the NAND flash (block 0) is guaranteed to be good. Thus, block 0 could be used to hold a bad block table if desired. However, at power up, many systems simply scan the first page of each block to determine whether they are good or bad and build a bad block table in RAM.

maybe is also important distinguish from "native" badblock and "during lifetime" badblock

[Sarah1331]

http://www.free60.org/NAND:Bad_Blocks

Best reading for bad blocks and how Xbox handles badblocks
Xbox is verry neat when handling bad blocks

Ps3 bad blocks are the same yet it handles them differently

Ps it maps it to the next available free block


Sent from my iPhone 5 using Tapatalk

[cuIstomizer]

By experience, bad block=bad wiring ! Cut the 360 clips to do his work and put clamp or dumbbell and it's good !
Windows 64 bits with intel cpu works fine with progskeet 1.2, reading and writing ! (nand test only)
Good luck (PS : no ipa needed, just new Toothbrush to clean).

[guerrierodipace]

Originally Posted by cuIstomizer By experience, bad block=bad wiring ! Cut the 360 clips to do his work and put clamp or dumbbell and it's good ! Windows 64 bits with intel cpu works fine with progskeet 1.2, reading and writing ! (nand test only) Good luck (PS : no ipa needed, just new Toothbrush to clean).

bad block are usual on nands....please....
bad wiring is a different problem, where you have read here about clip?!

[deanclaxton]

Hi Sarah1331,

I have a similar issue - a bricked PS3 with dumped NANDs that contain a bad block (NAND 0).

I'm trying to find out firstly where the bad block is, and secondly where it may have been remapped to.

Im approaching this from a slightly different angle - what I was hoping to do was extract all my console specific data from my SEM-001 nand dumps, and then get hold of a known good dump that I can then try injecting my data back into.

I believe that the console specific data is as follows :

metldr
======
Search interleaved nand dump for "metldr". Found at location 0x40820. Start of header is from 0x40840 - length 0xEDE0. (0x40840 - 0x4F61F)

IED
===
Search hex 0000000600001DD0000000000000000000000070000008 - found at 0x80800. select length 0x10000 (0x80800 - 0x907FF)

ISD
===
Seach hex 0000000300000270000000000000000000000040000000 - found at 0x90800. select length 0x800 (0x90800 - 0x9FFFF)

bootloader_0
============
found at address 0x0 - select length 0x400000. (0x0 - 0x3FFFFF)

bootloader_1
============
Search same header as bootloader_0 (00 00 2E F4 89 EF FD 15 B3 85 0E 3B 2A 73 44 84 in my case) - found at 0xF000000. Select length 0x400000. (0xF000000 - 0xF3FFFFF

vtrm
====
search text "sceivtrm" - found at 0xEC0000 . select length 0x400000 (0xEC0000 - 0x12BFFFF). NOTE - I FOUND THIS AT A DIFFERENT ADDRESS 60GB NAND - MAY BE MOVED????


Specialmio - can you provide me a copy of your working nands?? Or even better, does anyone have SEM-001 nand dumps that have no bad blocks and work??

Next part of my puzzle would be identifying the bad blocks and seeing whether any of my console specific data is affected/remapped.

Then finding where it is re-mapped!

Seems a VERY difficult task as I dont know how Sony remap the bad blocks - do they keep a table somewhere?

Also as the 2 nands are interleaved, and data is read sequentially from the nands, I assume that a bad block in one nand means the data in the other is also relocated - which is fine - in the combined dump it should all be intact/together and readable. The problem is finding where the bad block is located, and where the data has been relocated!

I've soldered TSOP48 sockets on my PS3 and have an off-board programming solution (Infectus with another 2 TSOP sockets on it) so can easily try new firmware to see if I can revive this console (killed with firmware downgrade gone wrong).