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.

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.

_________________
A backup a day keeps DR away.

Think I have managed to find ECC coding for this chip.

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

_________________
PC Image Data Recovery
http://www.pcimage.co.uk

New!! HDD-PCB.COM for all your PCB and donor HDD requirements!

And the same page with ECC=ON...

As you'll see, good but not perfect

_________________
PC Image Data Recovery
http://www.pcimage.co.uk

New!! HDD-PCB.COM for all your PCB and donor HDD requirements!

Multiple readings at slow speeds produce 100% identical dumps.

_________________
PC Image Data Recovery
http://www.pcimage.co.uk

New!! HDD-PCB.COM for all your PCB and donor HDD requirements!

@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?


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

_________________
A backup a day keeps DR away.

An update block updates a block from the image.

any correction with wrong ecc damage data. in this case correction no need.

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
http://www.pcimage.co.uk

New!! HDD-PCB.COM for all your PCB and donor HDD requirements!

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.


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

_________________
A backup a day keeps DR away.

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.

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.

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.



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

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.

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.


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

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.

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.