All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 137 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7
Author Message
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: June 2nd, 2015, 23:43 
Offline

Joined: March 15th, 2005, 12:49
Posts: 36
Location: Владивосток
In this case need use update pages from blocks. Controller store blocks in two formats - main and update. update has header 0x80..0x83. updates pages in same place as in main but contain only new data.


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: June 4th, 2015, 8:24 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9693
Location: Australia
I notice that pcimage's disk.image file spans 0x2E5 blocks.

    0xB94000 bytes / 0x4000 bytes per NAND block = 0x2E5 blocks

However, the partition table is indicating that the size of the DOC file system is 0x3E6 blocks.

    (0x7CC0 sectors x 0x200 bytes per sector) / 0x4000 bytes per NAND block = 0x3E6 blocks

That's a difference of just over 4MiB.

I don't know if I've correctly understood the physical-to-logical block mapping algorithm, but my reassembly of the file system matches pcimage's apart from 3 blocks whose associations appear to have been corrupted. I reconstructed block 0 by hand but left the others untouched.

Code:
C:\>DOC_FS_3 01_01.dmp

Logical Block Number 0x0 is not unique
Logical Block Number 0x161 is not unique
Logical Block Number 0x1ED is not unique

File system image saved to DOC_fs.img


Attachments:
DOC_fs_1.rar [3.24 MiB]
Downloaded 137 times

_________________
A backup a day keeps DR away.
Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: June 5th, 2015, 10:13 
Offline

Joined: November 29th, 2006, 10:08
Posts: 6896
Location: UK
Think I have managed to find ECC coding for this chip.

Here's a map with ECC=CHECK...


Attachments:
ECC Check.jpg
ECC Check.jpg [ 332.53 KiB | Viewed 1962 times ]

_________________
PC Image Data Recovery
www.pcimage.co.uk


Last edited by pcimage on June 5th, 2015, 10:18, edited 1 time in total.
Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: June 5th, 2015, 10:13 
Offline

Joined: November 29th, 2006, 10:08
Posts: 6896
Location: UK
And the same page with ECC=ON...

As you'll see, good but not perfect :-(


Attachments:
ECC ON.jpg
ECC ON.jpg [ 331.83 KiB | Viewed 1961 times ]

_________________
PC Image Data Recovery
www.pcimage.co.uk
Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: June 5th, 2015, 10:20 
Offline

Joined: November 29th, 2006, 10:08
Posts: 6896
Location: UK
Multiple readings at slow speeds produce 100% identical dumps.

_________________
PC Image Data Recovery
www.pcimage.co.uk


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: June 5th, 2015, 22:11 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9693
Location: Australia
@pcimage, I assumed that your uploaded 01_01.dump file was an error corrected NAND dump. Is this the case, and if so, are we to understand that it includes data errors, as suggested by your latest screenshots? Otherwise, could we see the raw uncorrected dump?

ISTM that you could, in general, determine the ECC algorithm by testing it against a zero-filled page (0x00). AFAICT, the first 6 bytes of each page are the ECC bytes for that page. In the present case the corresponding ECC pattern for a zero-filled page appears to be 5B 00 C8 05 91 08.

The SA for pages 0 and 1 of each block appears to contain the FTL and wear levelling information in bytes 8 - 15. I have used SA bytes 8 & 9 of page 0 to build the logical-to-physical block map. Any block whose logical block number is 0x8nnn has been treated as free, as have the 0xFFFF blocks. I know that there is something missing in my logic, but I can't see it.

Bytes 6 & 7 of each page appear to reflect the page "type". There are 3 values -- 0x5555, 0x0000 or 0xFFFF. Are these values added by the error correction processs in the data recovery software, or are they as they appear in the original uncorrected raw dump?

Code:
SA bytes    page
06 & 07   frequency
--------  ---------
0x5555        20821
0x0000         1426
0xFFFF        10521
-------   ---------
Total        0x8000

I have extracted the SA bytes of pages 0 and 1 and sorted them according to their logical and physical block numbers (see attachment).


Attachments:
SA.7z [130.33 KiB]
Downloaded 125 times

_________________
A backup a day keeps DR away.
Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: June 5th, 2015, 23:14 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 2927
Location: Adelaide, Australia
GreyDKang wrote:
In this case need use update pages from blocks. Controller store blocks in two formats - main and update. update has header 0x80..0x83. updates pages in same place as in main but contain only new data.


An update block updates a block from the image.


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: June 6th, 2015, 3:07 
Offline

Joined: March 15th, 2005, 12:49
Posts: 36
Location: Владивосток
any correction with wrong ecc damage data. in this case correction no need.


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: June 6th, 2015, 8:06 
Offline

Joined: November 29th, 2006, 10:08
Posts: 6896
Location: UK
I didn't do any correction in the uploaded dump, it's entirely possible that FE has misinterpreted the ECC in this case and it's a red herring.

_________________
PC Image Data Recovery
www.pcimage.co.uk


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: June 7th, 2015, 5:33 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9693
Location: Australia
pcimage wrote:
I didn't do any correction in the uploaded dump, it's entirely possible that FE has misinterpreted the ECC in this case and it's a red herring.

IIUC, your disk.image reconstruction and recovered files are based on the same raw, uncorrected dump, in which case the OP's machine would be running on an uncorrected version of NK.BIN. The size of this file (4740883 bytes) corresponds to 960 sectors or 290 blocks. That's about 30% of the capacity of the flash chip. Moreover, I compared your dump against the OP's original PC3K dump (after removing the SA bytes) and found a massive number of bit differences, yet you have found that repeated reads produce 100% consistent results. That seems very strange to me.

If I were testing the ECC algorithm, I would start with a known good zero-filled template (pages 0,1,2 of logical block 0x0000) and make various single-bit and 2-bit changes to both the data area and the ECC bytes.

Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
........
000001F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000200  5B 00 C8 05 91 08 55 55 00 00 FF FF 00 00 FF FF

00000210  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
........
00000400  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000410  5B 00 C8 05 91 08 55 55 01 00 00 00 69 3C 69 3C

00000420  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
........
00000610  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000620  5B 00 C8 05 91 08 55 55 FF FF FF FF FF FF FF FF
........

If you would like to try them, I have created a few ECC test patterns that could help you analyse the ECC algorithm. They include walking ones patterns with single-bit an 2-bit errors, walking bit flips in the ECC bytes, and error free pages using the 0xFFFF, 0x5555, and 0x0000 page "types".


Attachments:
ECC_test_patterns.rar [18.42 KiB]
Downloaded 123 times

_________________
A backup a day keeps DR away.
Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: June 7th, 2015, 17:13 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9693
Location: Australia
pcimage wrote:
Think I have managed to find ECC coding for this chip.

Am I to understand that the determination of the ECC algorithm is a matter of experimentation rather than an automatic selection by the software?

ISTM that a logical approach would be for the software to maintain a database of known ECC algorithms, together with the ECC bytes that each algorithm generates for zero-filled or all-ones pages. Then all that the software would need to do would be to scan the dump for a zero-filled page and look up its ECC bytes in the database.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: June 7th, 2015, 23:14 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 2927
Location: Adelaide, Australia
fzabkar wrote:
pcimage wrote:
Think I have managed to find ECC coding for this chip.

Am I to understand that the determination of the ECC algorithm is a matter of experimentation rather than an automatic selection by the software?

ISTM that a logical approach would be for the software to maintain a database of known ECC algorithms, together with the ECC bytes that each algorithm generates for zero-filled or all-ones pages. Then all that the software would need to do would be to scan the dump for a zero-filled page and look up its ECC bytes in the database.


Yes that would be logical, and even partly possible IF there was documentation given out by the vendors. Almost all of the ECC, XOR and mix ago's need to be reverse engineered as the dump of the chip is being analysed. Things that help is previous experience, and building apon that... and then databases are built of this experience.

There is approx. 10 major controller vendors we see regularly. they all do things similar but not the same. they change things whenever they like. Controller and chip combos can have many different schemes. Out of the 500 or so devices I have catalogued, devices I have bought over the last 2-3 years.. there is maybe a 2% rate of ecc/xor/mix schemes duplicated.

you can either guess and try out ECC schemes or test them.. pretty much the only way.

additionally when a decice comes in, there is no sence of its actuial date range as you would have in a car model. Commonly see brand new devices with 2011 on the PCB and these can look exactly the same for years, with chips being changed/firmware changed etc.

It is not as simple as we would like.


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 8th, 2017, 0:51 
Offline

Joined: May 8th, 2017, 0:08
Posts: 2
Location: Canada
Hi All,

Bumping an old topic here....
and maybe the repair attempt has been given up on....not sure?


However, just in case not.....
I've been doing a lot of work with M-SYSTEMS DiskOnChip 2000 devices over the past few years. I have compiled everything that I've learned, including manuals and software links onto a devoted Web page on my Hobby Website for archiving purposes. It seems that the information on M-SYSTEMS DiskOnChips is slowly disappearing. So I wanted to archive what I could for future users.

http://www.digital-circuitry.com/MyLAB_IC_PROG_DISKONCHIP.htm

Anyhow, the reason I am posting.....
A couple years ago I managed to acquired a very rare official M-SYSTEMS GANG Programmer.
The earlier REV "B" model that runs a special M-SYSTEMS DOS program for automating the duplication of DOC's from a MASTER chip as the source.
These little suckers still sell for around $10,000... so I was lucky to locate one at an auction.

Image

I'm wondering if by using the original DOC from this Knitting machine, and running the "COPY" function on this programmer of mine to make a copy onto another working DOC,
if this would make any difference here with the source image? As I was reading in the early posts that the Source DOC that Joanorsky made may have been DUMPED improperly.


Anyhow,
just thought I would mention it in case it may help in some way with such a rare machine?


Here is a video I found on Youtube that shows the same model of DOC programmer I have.
It's in Chinese but it still Demo's the Programmers functions.

https://youtu.be/AKgdIQE078w

Cheers!
-Gerry


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 8th, 2017, 3:33 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9693
Location: Australia
The chip-to-chip copier would obviate the necessity to account for ECC in the raw dumps. Unfortunately the OP's DOC was physically damaged (problems with its 3.3V regulator?). The other problem was that the file system was corrupt, so a clone's FS would be similarly affected.

BTW, I'm looking forward to your programmer teardown. If you need any help ...

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 8th, 2017, 8:15 
Offline

Joined: May 8th, 2017, 0:08
Posts: 2
Location: Canada
Ahh I see.

Well...it was a shot in the dark.
I wasn't sure it would help, but thought I'd mention it.


LOL...yeah the tear down I did not too long after I got the unit was just to investigate what was inside.
I posted pics of of the internals on that devoted page at the very bottom.

The heart of it was a 6 Layer custom PCB with some voltage regulators, 245 transceivers, and a series of Lattice CPLD's.
All interfaced over to the PCI card slot through a 64 pin IDC header. It will be one hell of Reverse engineering project if I ever start it.

Eventually I want to take a peak at a couple of areas on the PCBA with the XRAY unit at work.
Maybe one day I'll look at starting that....to many other projects on the go right now though. :P


Anyhow,
If anyone has any further manuals or software for M-SYTEMS DiskOnChips that are not already on my site,
I would appreciate you firing me an email so I can add it for hosting.

Later folks,
Cheers!
-Gerry


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 8th, 2017, 21:20 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 2927
Location: Adelaide, Australia
Gerry, this is the poster-child for how you archive technology that's going away. Very appreciative of your work! I looked into M-SYSTEMS a while ago and may have some of the docs you are missing, I will check... but judging by the Google-Fu it would have taken to put your page together, maybe not!

It is staggering the amount of development it would have required to Manufacture all the D-O-C tools, let alone the dev of the devices themselves.


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 8th, 2017, 21:48 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 9693
Location: Australia
I find it strange that the motherboard has an unpopulated 32-pin DOC socket, yet M-Systems has opted to use a HDD rather than their own DOC.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 137 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group