Help needed - Serious challange with this one

HaQue wrote:wish I had time to look more tonight, but got actual paying (I Know! where is the fun in that??) jobs to do...

I will try and pick it up tommorrow

Yeah... i know... no fun in that.. eheh..

Thank you HaQue.. i really appreciate your efforts and your time in explaining this..

I have some files that i do believe were inside the dump... would these help in mapping the files for correct block translation? My guess is yes.. but then again...

This is not 100% sure.. but i found a floppy disk that was damaged and i was able to recover it's data. I think belongs to the initial machine setup as i can see this data is inside the dump as well (fragmented but it seems to be there).

The files are here : http://www.joaocesarsilva.com/echo/EchoV104.zip

I wasn't able to compile a full WinCE image with this on Platform Builder because they seem to be incomplete.. it's only a partial or so it seems.. :\ .. nevertheless i leave them here as they might help.

Clearly there is a flaw in the way that the OP is reading the NAND flash.

AISI, the OP's NAND dump looks like this:

Code:: 512-bytes from page #0 first 16-bytes from page #1 512-bytes from page #1 first 16-bytes from page #2 512-bytes from page #2 etc

Instead it should be ...

Code:: 512-bytes from page #0 16 ECC bytes from page #0 512-bytes from page #1 16 ECC bytes from page #1 512-bytes from page #2 etc

I've found a few resources that may help to get an insight into how the DiskOnChip works.

Here is the original M-Systems patent for a "Flash File System" (1993):

http://www.google.com/patents/US5404485
http://patentimages.storage.googleapis. ... 404485.pdf

The "DiskOnChip Software Utilities User Manual" gives some insight into the structure of the TrueFFS file system:

http://sewoon.com/icmaster/Semi/amd/pdf ... .01_UM.pdf
http://www.tri-m.com/products/trim/file ... lities.pdf

The DiskOnChip contains a "Binary Partition", "BDTL Partition" (Block Device Translation Layer), "Secondary Program Loader" (SPL), and "NAND Flash Translation Layer" (NFTL). An "Initial Program Loader" (IPL) resides in a separate IPL ROM and this is accessed via an 8KB BIOS window.

AFAICT, the SPL occupies a fixed location at the beginning of the NAND and is not subject to wear levelling.

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 EB 2D 55 AA 60 B6 42 00 14 84 04 02 53 50 4C 5F ë-Uª`¶B..„..SPL_ 00000010 44 69 73 6B 4F 6E 43 68 69 70 20 28 63 29 20 4D DiskOnChip (c) M 00000020 2D 53 79 73 74 65 6D 73 00 00 00 00 40 00 00 55 -Systems....@..U

The following archive contains a "DOC105.EXB - V3.3.5(V1.05) - DiskOnChip 2000 bootimage file":

http://web.archive.org/web/199711131045 ... doc105.exe

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 EB 2D 55 AA 10 00 00 00 00 00 01 05 53 50 4C 5F ë-Uª........SPL_ 00000010 66 6F 72 5F 44 4F 43 5F 32 30 30 30 20 28 63 29 for_DOC_2000 (c) 00000020 31 39 39 36 20 4D 2D 73 79 73 74 65 6D 73 00 55 1996 M-systems.U

The file has a size of 0xA800, so I'm guessing that this comprises the SPL.

Elsewhere in the OP's NAND dump I see ...

TrueFFS-BIOS -- Version 3.3.9 for DiskOnChip 2000 (V4.2) Copyright (C) M-Systems, 1992-2000

There is a picture missing that shows this as DOC 4.2 (2000 variant)

As the machine works on x86 based platform the real boot image should be the doc42.086 or doc42p.086 (for plug and play OS)

I believe that 3.3.9 is the TFFS version for this 4.2 Boot version..

These are located at :

Full 4.2 Pack : ftp://ftp.emacinc.com/Archive/PCSBC/DOC_Drivers/
Boot images for 4.2 on x86 platforms : ftp://ftp.emacinc.com/Archive/PCSBC/DOC_Drivers/8086/

Is this the machine you own ?

This request may sound silly, but once the company that is in the building next to ours once had a issue with a corrupted firmware of a machine that wasn't supported anymore (no web presence, company bankrupt...) After googling a bit they ended up finding a ex-worker on LinkedIn of the manufacturer of those machines and he was able to retrive the latest firmware and get it back to work again.

Google for Omega Echo webtex.ag and try sending those guys an inquiry!

or FTL time.

Good luck!

P.S: Excuse this english, been all day trying to correct the pads of a tsop48, I can't even...

Attachments

This machine has only one cart... The one we are refering to has 2 carts so the hardware is not the same. That means that the software and firmware are expected to be different as well. Since the manufacturer is the same, the story must be very similar.

There are several omega models.. Such as nikita, echo and zip. I dont know if there is any chance of compability... But hey... Making a contact doesnt hurt..

Thanks for your help.. I appreciate it..

The DOC PCB has a 3.3V LDO regulator IC at the bottom left corner. Therefore I suspect that the DOC is a 5V part. Measuring the Vcc and Gnd pins at the IC socket on the main board should confirm this.

LM3480IM3-3.3, Texas Instruments, 3.3V, 100mA, LDO regulator, marking L0A, SOT-23
http://www.ti.com/lit/ds/symlink/lm3480.pdf

I would first check whether the regulator is working.

The NFDC-2148 flash controller appears to contain the IPL boot code in its internal memory. Therefore ISTM that one way to test whether the controller is alive would be to read the DOC as a standard 32-pin JEDEC flash EEPROM in a regular chip reader. You could select any device with the same voltage and pinout, eg SST28SF040A.

http://www.metatech.com.hk/datasheet/ss ... -10-DS.pdf

Of course you will only retrieve 8KB of data (the rest of the address space would be aliased).

Attachments

Hi OP:
I will put this question alone, as I think you have previously missed it:

can you say what process and hardware you used to dump the chip?

HaQue wrote:Hi OP:
I will put this question alone, as I think you have previously missed it:

can you say what process and hardware you used to dump the chip?

I've already asked him, he was going to ask that to the guy who did it.

Two questions for you master HaQue:

a)Doesn't VNR has a bitmap viewer that can help on this ?

b)Can the voltage used to do the dump have any influence on the errors found?

DRUG wrote:a)Doesn't VNR has a bitmap viewer that can help on this ?

it does, that's why he asked the question

DRUG wrote:b)Can the voltage used to do the dump have any influence on the errors found?

yes, http://rusolut.com/analysis-of-bit-errors-in-nand/

fzabkar wrote:The DOC PCB has a 3.3V LDO regulator IC at the bottom left corner. Therefore I suspect that the DOC is a 5V part. Measuring the Vcc and Gnd pins at the IC socket on the main board should confirm this.

I would first check whether the regulator is working.

The LM is OK.. it was burned... so we have replaced it and tested it. Since this was done, and we didnt knew the extend of the damage we managed to get a new board from another equal DOC bought from germany. The new DOC board was equal to the original (all references equal.. same controller, resistors, etc).. so.. 100% sure the LM is ok.

fzabkar wrote:The NFDC-2148 flash controller appears to contain the IPL boot code in its internal memory. Therefore ISTM that one way to test whether the controller is alive would be to read the DOC as a standard 32-pin JEDEC flash EEPROM in a regular chip reader. You could select any device with the same voltage and pinout, eg SST28SF040A.

Of course you will only retrieve 8KB of data (the rest of the address space would be aliased).

We have replaced this controler by another one from a new board (as mentioned above) as we have suspected it had totally burned because the LM was initially faulty. Is it possible that the failure from this DOC was because this controller became also damaged and that the new controller's IPL was blank or based on a non x86 platform?!? Are you sure that the IPL is on the NFDC-2148? The donor controller (2148) as mentioned above was from another equal DOC that we managed to get.. (but i cant make sure what it had inside.. so i dont quite know if the donor controller had a x86 platform originally.. to be quite honest... we didnt even knew this had a ROM within.. i know... what a dumb thing to find out now.. :\ )

HaQue wrote:can you say what process and hardware you used to dump the chip?

I wasnt able to get in touch with the guy who did the nand backup (was done in a offchip procedure though).. tomorrow i think i can get that info and will post it here ASAP.

DRUG wrote:
HaQue wrote:Hi OP:
I will put this question alone, as I think you have previously missed it:

can you say what process and hardware you used to dump the chip?

I've already asked him, he was going to ask that to the guy who did it.

Two questions for you master HaQue:

a)Doesn't VNR has a bitmap viewer that can help on this ?

b)Can the voltage used to do the dump have any influence on the errors found?

a) Yes, as jermy say, it is why I asked. I already loaded Francs edited version, and the original in VNR and both just don't look right.

b) The link jermy posted is the best resource for this. though this dump looks very sound with possibly no bit errors at all, just the config used to dump appears to be wrong.

I'm not sure of anything, but AIUI the DOC hooks into BIOS during its search for adapters. BIOS finds an 8KB window, loads the IPL (Initial Program Loader) boot code, and this code then loads the SPL code (Secondary Program Loader). The SPL code appears to be located at address 0 in the NAND, so this would suggest that the IPL must be outside the NAND, in which case the only other place is the controller.

Just for curiosity... i made a test run on photorec tool with the following geometry :

Sectors : 2
Heads : 16
Cylinders : 996

Photorec - www.cgsecurity.org

in a command line (windows) :
photorec_win dump.dmp (no ecc) ->advanced options : brute force : change geometry

It managed to get me all the files inside the dump. The size and time stamp seem to be ok.. but the internals seem to be corrupted.

This is one printscreen from one of the grabbed inodes :

I had a look at the following firmware file:

ftp://ftp.emacinc.com/Archive/PCSBC/DOC ... /doc42.086

ISTM that it is structured as follows:

Code:: 0x0000 - 0x01FF IPL code 0x0200 - 0x03FF copy of IPL code 0x0400 - 0x1FFF SPL code 0x2000 - 0x27FF TFFS code 0x2800 - 0x8FFF more TFFS code 0x9000 - 0xAFFF block of repeating 0x90 with 0x55AA signature at start

Here is the IPL code:

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 55 AA 10 EB 3C 00 00 28 43 29 4D 2D 53 79 73 74 Uª.ë<..(C)M-Syst 00000010 65 6D 73 31 39 39 38 00 00 00 21 00 00 04 00 1C ems1998...!..... 00000020 55 24 50 6E 50 01 02 00 00 00 1E 6D 1A 01 10 00 U$PnP......m.... 00000030 00 00 00 00 80 01 94 00 00 00 00 00 00 00 00 00 00000040 00 9C 50 53 51 52 56 57 55 1E 06 BA C0 1F 33 C0 00000050 8E C0 33 FF 83 C2 40 8E DA 81 FA 00 A0 74 1A 33 00000060 F6 B9 00 02 FC AD 0B C0 75 E8 E2 F9 83 FF 00 75 00000070 02 1E 07 47 83 FF 30 72 DB 83 FF 30 73 05 BA 00 00000080 58 8E C2 0E 1F 8B EC 83 EC 04 8C C0 8C 46 FE C7 00000090 46 FC AB 00 0E E8 13 00 8B 46 FE 8E C0 33 FF B9 000000A0 00 60 33 C0 FC F3 AB 8B E5 EB 74 55 8B EC 8B 46 000000B0 04 8E D8 BB 00 00 C6 87 03 10 00 C6 87 02 10 85 000000C0 C6 87 02 10 85 BE 00 08 B1 FF E8 5D 00 FC 32 E4 000000D0 B1 00 E8 55 00 2E 8B 0E 1E 00 33 FF F7 C1 FF 01 000000E0 75 23 C6 87 04 10 0D 2E 8B 16 1C 00 03 D7 D0 EE 000000F0 88 14 88 34 33 D2 88 14 C6 87 1E 10 00 C6 87 04 00000100 10 09 E8 36 00 84 87 0D 10 AC 02 E0 AA 4E E2 CC 00000110 2E 3A 26 20 00 75 06 5D 06 33 C0 50 CB 5D CB 07 00000120 1F 5D 5F 5E 5A 59 5B 58 9D CB C6 87 04 10 0B 88 00000130 0C C6 87 1E 10 00 C6 87 04 10 09 F6 87 20 10 80 00000140 F6 87 20 10 80 F6 87 20 10 80 F6 87 20 10 80 F6 00000150 87 04 10 80 74 F9 F6 87 20 10 80 F6 87 20 10 80 00000160 C3 1C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000170 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

The "55AA" signature at the start appears to be consistent with other BIOS adapter code.

For example, here is the BIOS entry for my graphics card at address C000:0:

Code:: -d c000:0 1ff C000:0000 55 AA 60 E9 53 02 32 2E-30 30 2E 35 30 20 2D 30 U.`.S.2.00.50 -0 C000:0010 98 01 AC 01 DE 01 F2 01-8F 55 8F 04 8F 04 49 42 .........U....IB C000:0020 4D 20 43 4F 4D 50 41 54-49 42 4C 45 31 32 2F 32 M COMPATIBLE12/2 C000:0030 38 2F 32 30 30 30 2D 31-36 3A 34 34 3A 33 31 20 8/2000-16:44:31 C000:0040 3F 01 02 01 3E 01 40 01-65 01 39 10 00 73 57 01 ?...>.@.e.9..sW. C000:0050 97 01 30 00 5A 64 80 42-00 B3 45 80 53 00 37 61 ..0.Zd.B..E.S.7a C000:0060 80 64 00 37 22 80 85 00-37 61 80 64 00 37 61 80 .d.7"...7a.d.7a. C000:0070 64 00 37 61 80 64 00 37-61 80 64 00 54 43 80 64 d.7a.d.7a.d.TC.d C000:0080 00 53 43 80 64 00 55 43-80 64 00 52 43 80 64 00 .SC.d.UC.d.RC.d. C000:0090 3F 42 80 64 00 54 43 80-64 00 54 43 80 64 00 54 ?B.d.TC.d.TC.d.T C000:00A0 43 80 64 00 10 01 09 A3-00 00 00 00 00 43 43 43 C.d..........CCC C000:00B0 00 00 00 00 00 1E 1E 1E-00 00 00 00 00 2A 2A 2A .............*** C000:00C0 00 00 00 00 00 06 06 06-00 00 00 00 00 00 00 00 ................ C000:00D0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ C000:00E0 00 00 00 00 00 00 16 B2-F6 0D 00 11 40 21 ED BA ............@!.. C000:00F0 08 2A 05 E3 00 00 00 80-D1 00 B9 00 B3 00 00 00 .*.............. C000:0100 00 00 53 69 53 20 37 33-30 20 41 47 50 20 54 72 ..SiS 730 AGP Tr C000:0110 75 65 20 43 6F 6C 6F 72-20 47 72 61 70 68 69 63 ue Color Graphic C000:0120 73 20 61 6E 64 20 56 69-64 65 6F 20 41 63 63 65 s and Video Acce C000:0130 6C 65 72 61 74 6F 72 00-00 00 00 00 00 00 0E 00 lerator......... C000:0140 0F 20 42 79 74 65 73 20-56 69 64 65 6F 20 4D 65 . Bytes Video Me C000:0150 6D 6F 72 79 2C 14 00 07-42 49 4F 53 20 56 65 72 mory,...BIOS Ver C000:0160 73 69 6F 6E 20 32 2E 30-30 2E 35 30 20 20 16 00 sion 2.00.50 .. C000:0170 53 75 70 70 6F 72 74 20-56 45 53 41 20 42 49 4F Support VESA BIO C000:0180 53 20 45 78 74 65 6E 73-69 6F 6E 20 56 65 72 20 S Extension Ver C000:0190 33 2E 30 0D 0A 25 00 07-53 69 53 00 00 00 00 00 3.0..%..SiS..... C000:01A0 00 00 00 00 00 00 00 00-00 00 00 00 53 69 6C 69 ............Sili C000:01B0 63 6F 6E 20 49 6E 74 65-67 72 61 74 65 64 20 53 con Integrated S C000:01C0 79 73 74 65 6D 73 20 43-6F 72 70 2E 00 00 00 00 ystems Corp..... C000:01D0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 37 33 ..............73 C000:01E0 30 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 0............... C000:01F0 00 00 32 2E 30 30 2E 35-30 00 00 00 64 00 00 00 ..2.00.50...d...

I couldn't find anything that looks like IPL code in your NAND dump. That said, something doesn't look right with the start of the dump. Every second 0x100 sized block is zero filled. I would have expected a contiguous block of code. In fact if I reassemble the SPL section by removing the empty 0x100-byte blocks from your NAND dump, the result is almost identical to the SPL code in the doc42.086 file.

Attachments

SPL.rar: (3.64 KiB) Downloaded 1045 times

Could you dump an image of a new, working DiskOnChip via DOS using the GETMIMG utility? Hopefully the only content of the image file will be the firmware, an empty formatted FAT16 volume, and maybe the FTL.

I've examined the doc42.086 file again. This time I looked for 8-bit checksums.

Code:: address range checksum function ------------------------------------------------------------------------- 0x0000 - 0x01FF 0x00 IPL code 0x0200 - 0x03FF 0x00 copy of IPL code 0x0400 - 0x042F 0x22 header of SPL code 0x0430 - 0x1FFF 0x33 SPL code 0x2000 - 0x27FF 0x00 TFFS code 0x2800 - 0x8FFF 0x00 more TFFS code 0x9000 - 0xAFFF 0x00 block of repeating 0x90 with 0x55AA signature

Comparing against your own NAND dump ...

Code:: address in SPL.DMP 0x0400 - 0x042F 0x22 header of SPL code 0x0430 - 0x1FFF 0xF2 * SPL code

Code:: address in NOECC.DMP 0x4000 - 0x47FF 0x00 TFFS code 0x4800 - 0xA7FF 0xB2 * more TFFS code 0xA800 - 0xBFFF 0x00 block of repeating 0xFF

ISTM that the 0x22 and 0x33 numbers look too "neat" to be coincidental, especially since the two SPL headers contain significantly different data.

I'd say that your NAND dumps have several bit errors in the "SPL code" and "more TFFS code" sections. However, I would be surprised if these were not correctable by ECC.

Here is a comparison of the SPL code sections. The differences occur randomly in single bits.

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000560 0D A1 BC 16 8B 4E FA 8B 16 24 17 FF 5E FC 8B 46 00000160 0D A1 BC 56 8B 4E FA 8B 16 24 17 FF 5E FC 8B 46 ^ 000007F0 C7 06 D2 16 00 00 B8 04 00 50 16 8D 46 FC 50 33 000003F0 C7 06 D2 16 00 00 B8 04 00 50 16 8D 46 FC D0 33 ^ 00000860 C2 B8 1F 00 8B E5 5D C3 55 8B EC 8B 56 04 EB 04 00000460 C2 B8 1F 00 8B E5 5D C3 55 8B EC 8B 56 04 E9 04 ^ 00000B00 FC 16 A1 FA 16 E8 82 0F 89 16 FC 16 A3 FA 16 33 00000700 FC 16 A1 FA 16 E9 82 0F 89 16 FC 16 A3 FA 16 33 ^

Here is a dump we have made a few days ago.. in order to check the structure ourselfs. The dump was made using the DOC tool "getmimg". We had the doc42.086 or doc42p.086 firmware within .. with the 3.3.9 TFFS version as well.

We had only 2 text files within this dump. Both were clear text.. repeated in order to make a few MB. One of the files just had a "t" repeated inside and the other text file had something like (wich has a typo) "eu sei que vais ler isto o codigo e disk-on-CHIP" (translates to : "I know that you are going to see this in the disk-on-CHIP")

Clean dump using DOC tools : http://www.joaocesarsilva.com/echo/clean_dump.rar

HaQue wrote:Hi OP:
I will put this question alone, as I think you have previously missed it:

can you say what process and hardware you used to dump the chip?

I was just informed that the hardware used for this dump was the PC3000 (offchip procedure on the samsung nand). They said that they checked for bit errors and that the dump was ok. No further details were given to me...

joanorsky wrote:
HaQue wrote:Hi OP:
I will put this question alone, as I think you have previously missed it:

can you say what process and hardware you used to dump the chip?

I was just informed that the hardware used for this dump was the PC3000 (offchip procedure on the samsung nand). They said that they checked for bit errors and that the dump was ok. No further details were given to me...

LOL. Obviously there are bit errors and obviously the dump is flawed. Either this person doesn't understand how to use his expensive tool, or the tool is junkware. Ask him how he managed to determine that there are no bit errors when there are no ECC bytes in the dump.

Adding to my previous post ...

The first TFFS code sections are identical. The second TFFS sections differ in length and content, so a bit-for-bit comparison is not possible.

Previously I compared two copies of the FAT in the data area. These were identical. ISTM that the bit errors may be confined to the static area of the NAND, ie the firmware area. IMO this seems reasonable since NAND flash has finite data retention (10 years according to the datasheet). The user area would be subject to wear levelling and would be refreshed from time to time. Perhaps it would be advisable to refresh the NAND's firmware partition using the appropriate DOC utility.

FWIW, the number of used clusters is 5863. This means that the used space amounts to approximately 12MB.

5863 clusters x 4 sectors per cluster x 512 bytes per sector = 12 007 424 bytes

Help needed - Serious challange with this one

Re: Help needed - Serious challange with this one

Re: Help needed - Serious challange with this one

Re: Help needed - Serious challange with this one

Re: Help needed - Serious challange with this one

Re: Help needed - Serious challange with this one

Re: Help needed - Serious challange with this one

Re: Help needed - Serious challange with this one

Re: Help needed - Serious challange with this one

Re: Help needed - Serious challange with this one

Re: Help needed - Serious challange with this one

Re: Help needed - Serious challange with this one

Re: Help needed - Serious challange with this one

Re: Help needed - Serious challange with this one

Re: Help needed - Serious challange with this one

Re: Help needed - Serious challange with this one

Re: Help needed - Serious challange with this one

Re: Help needed - Serious challange with this one

Re: Help needed - Serious challange with this one

Re: Help needed - Serious challange with this one

Re: Help needed - Serious challange with this one