All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 137 posts ]  Go to page 1, 2, 3, 4, 5 ... 7  Next
Author Message
 Post subject: Help needed - Serious challange with this one
PostPosted: May 8th, 2015, 19:22 
Offline
User avatar

Joined: May 8th, 2015, 19:08
Posts: 40
Location: Portugal
Hello all..
i have a serious problem with a industrial knitting machine. This machine works on a Windows CE 3.00 platform that for it's own turn, is compiled on a 16MB DiskOnChip 2000 variant with a k9f2808u0b Samsung (16MB) nand flash. Unfortunatly. This DiskOnChip (from MSystems) has a damaged boot (or so it seems).. and no longer boots the machine. I dont actually don't know if it is the boot... but i suspect so.

So.. what is the problem.. you may say? Well.. the Italian knitting machine's manufacturer has gone bankrupt... and the machine no longer has support. As the diskonchip has failed.. i have no software for it or Operating System for that matter! Also.. the MSystems is no longer available... and although it has been acquired by sandisk, sandisk does not give support has well on data retrieval.

All i have is a raw flash dump that i've made on the diskonchip's Samsung k9f2808u0b NAND IC. This is based on TFFS .. but although i have read almost everything that there is on the web about this (including XDA and other wll known places) i seem to be unable to extract the internal NAND image files. I have used, RvSkills, NAND extractor, etc... without success.. i guess it's lack of experience and the right tools for it.

When we open the raw dump with a hex editor... the data seems to be there... and i do see several known signatures but i don't seem to be able to retrieve the file structure as i cant figure the page/block translation scheme. I really need this machine working.. and this is my only solution.. any help would be highly appreciated.

Inside this it should be several windows CE files based on a x86 platform.. such as loadcepc.exe, nk.bin, eboot.bin.. etc.. but the only file really needed is the nk.bin so that i can reconstruct the whole OS again.

Any help? Please?

I'll leave the dump here : http://www.joaocesarsilva.com/dump.rar


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 10th, 2015, 17:51 
Offline

Joined: March 19th, 2015, 15:01
Posts: 1387
Location: isreal
there isn't in the market (ebay or whatever second hand) to buy this machine ?
buy another one (same machine) and you got yourself a copy of the operating system and the software


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 10th, 2015, 18:30 
Offline
User avatar

Joined: May 8th, 2015, 19:08
Posts: 40
Location: Portugal
No... There is not. This machine has 4 meters long... Its a industrial type machine..


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 10th, 2015, 18:34 
Offline

Joined: March 19th, 2015, 15:01
Posts: 1387
Location: isreal
you are the only one on the entire planet who bought this machine ?


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 10th, 2015, 19:06 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 15461
Location: Australia
I'm not familiar with the translation scheme, or FTL in general, so I can't help there.

However, ISTM that you are not reading the ECC bytes correctly. Every page appears to echo the first 16 data bytes in the ECC bytes. Therefore the first thing I did was to strip the last 16 bytes from each 528-byte page.

The NK.BIN file has a size of 0x485713 (4740883) bytes. Its start cluster is either 0x18D or 0x1EA. I can see the MBR, MSDOS 5.0 FAT16 boot sector, and both copies of the 16-bit FAT.

Would you mind uploading detailed photos of the DiskOnChip PCB?

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 10th, 2015, 19:12 
Offline
User avatar

Joined: May 8th, 2015, 19:08
Posts: 40
Location: Portugal
jermy wrote:
you are the only one on the entire planet who bought this machine ?


Actually only 2 of these machines were sold world wide... And i cant locate the other one... Sadly.. :(

fzabkar wrote:
Would you mind uploading detailed photos of the DiskOnChip PCB?


I dont have the photos right now... But i will post them in a few hours... (Thanks for your help)


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 10th, 2015, 19:13 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 3844
Location: Adelaide, Australia
finding another owner of a machine like this is a challenge. I have worked on a lot of these types of things: leather cutting machines running win95 and Mastercam software from 1999, Cardboard cutting machines running win3.1 and custom software... these things always seem to be the only ones on the planet.. Owners generally don't have a web presence and you might be next door to another one but never know it.

How did you dump the NAND? was it chip off using VNR, PC3K or Soft Center NR? something else? With a quick a cursory look, The 55AA bytes look to be in the wrong place.

can you give any more info on the model of the machine, and for completeness high res photo of card outside, pcb both sides (this is more for longevity purposes for the forum thread so in the future there is a good context)

Also a photo of the machine, and model numbers, info on the PC or SBC running it, so we have some context and maybe someone here knows someone or has more Google-fu than others.

also chip numbers and config to dump might be interesting/handy.

I have some ideas, thanks for uploading dump that is useful to try them out..

you could try finding ANY disk image from any other machine running a D-O-C card that boots a similar PC to compare boot.

you could also try buying a few DOC cards and performing DR on them.. a lot of times they are only formatted and you can get back everything. This would be a last straw method. Or search for another owner of the machine.. it can be done!


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 10th, 2015, 19:41 
Offline
User avatar

Joined: May 8th, 2015, 19:08
Posts: 40
Location: Portugal
This is a tablet high resolution photo of the disk on chip that the dump has originated from :

Image

I will post several pictures from the boards and the machine itself on the next posts


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 10th, 2015, 19:52 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 15461
Location: Australia
HaQue wrote:
With a quick a cursory look, The 55AA bytes look to be in the wrong place.

The beginning of the dump appears to consist of 0x20 sectors of IPL code for the DOC device. AFAICT, this is the 8KB window for the BIOS.

This is followed by two TFFS blocks (0x4000, 0x4800) with a 0x55AA signature at the beginning. I can also see an MBR and MSDOS 5.0 FAT16 boot sector with the 0x55AA signatures at the end. Therefore ISTM that everything is probably structurally OK.

This is the datasheet for the NAND:

K9F2808U0B, 16M(16,777,216) x 8bit + spare 512Kx8, 528-byte page, NAND Flash Memory
http://www.ic72.com/pdf_file/k/52564.pdf

... and the datasheet for the DOC:

DiskOnChip 2000 DIP - from 16MByte to 1GByte:
http://web.archive.org/web/200709290949 ... Rev3.9.pdf

Assuming that the OP's DOC is the same device, then it should have been possible to read the 8KB IPL code with an EEPROM reader using a standard 32-pin JEDEC pinout. That would have at least verified some basic functionality.

I'm not sure if uploading a 3MB file is permissible here, but if the OP permits, I could upload my edited no-ECC version of the DOC dump to my web space.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 10th, 2015, 19:55 
Offline
User avatar

Joined: May 8th, 2015, 19:08
Posts: 40
Location: Portugal
Board pictures :

Main board = GENE 4310
Secondary board = Dinema (italian) PCB 1367

Image
Image
Image
Image

Machine pictures :
Brand = Omega
Model = Echo
Type = Knitting machine

Image
Image
Image


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 10th, 2015, 20:00 
Offline
User avatar

Joined: May 8th, 2015, 19:08
Posts: 40
Location: Portugal
I can arrange a FTP account on my server if required.
I have also posted some pictures .. but as they require admin approval they are still not available to see on this post.. maybe in a few moments.

As fzabkar said... the datasheets are correct. And the DOC is the 16MB version as per the nand specifications..

I am really amazed how you manage to see all that info from the dump.. i have been trying for so long.. :\ :|


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 10th, 2015, 20:11 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 15461
Location: Australia
Here is the DOC dump with the bogus ECC bytes removed:
http://www.users.on.net/~fzabkar/temp/NOECC.rar

_________________
A backup a day keeps DR away.


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

Joined: May 8th, 2015, 19:08
Posts: 40
Location: Portugal
So... i should burn this directly to the nand or using any other tool... like the DOC image utils? I am sorry.. but i am a "newbie" or at least i feel like it.. :)

If you could extract the nk.bin ... that would be great...


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 10th, 2015, 20:33 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 15461
Location: Australia
It would make no sense to copy this to another NAND since the data have been wear levelled. You need to extract the file information by translating the NAND blocks to actual disc LBAs. Unfortunately I don't know how to do this.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 10th, 2015, 20:37 
Offline
User avatar

Joined: May 8th, 2015, 19:08
Posts: 40
Location: Portugal
Ohh .. i see. So.. that's a problem i can't solve as well.. the translation procedure is out of my league... :'(


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 10th, 2015, 22:48 
Offline
User avatar

Joined: September 8th, 2009, 18:21
Posts: 15461
Location: Australia
This is a standard MS-DOS 3.30 (or later) MBR:

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

00638000  FA 33 C0 8E D0 BC 00 7C 8B F4 50 07 50 1F FB FC  ú3ÀŽÐ¼.|‹ôP.P.ûü
00638010  BF 00 06 B9 00 01 F2 A5 EA 1D 06 00 00 BE BE 07  ¿..¹..ò¥ê....¾¾.
00638020  B3 04 80 3C 80 74 0E 80 3C 00 75 1C 83 C6 10 FE  ³.€<€t.€<.u.ƒÆ.þ
00638030  CB 75 EF CD 18 8B 14 8B 4C 02 8B EE 83 C6 10 FE  ËuïÍ.‹.‹L.‹îƒÆ.þ
00638040  CB 74 1A 80 3C 00 74 F4 BE 8B 06 AC 3C 00 74 0B  Ët.€<.tô¾‹.¬<.t.
00638050  56 BB 07 00 B4 0E CD 10 5E EB F0 EB FE BF 05 00  V»..´.Í.^ëðëþ¿..
00638060  BB 00 7C B8 01 02 57 CD 13 5F 73 0C 33 C0 CD 13  ».|¸..WÍ._s.3ÀÍ.
00638070  4F 75 ED BE A3 06 EB D3 BE C2 06 BF FE 7D 81 3D  Ouí¾£.ëÓ¾Â.¿þ}.=
00638080  55 AA 75 C7 8B F5 EA 00 7C 00 00 49 6E 76 61 6C  UªuÇ‹õê.|..Inval
00638090  69 64 20 70 61 72 74 69 74 69 6F 6E 20 74 61 62  id partition tab
006380A0  6C 65 00 45 72 72 6F 72 20 6C 6F 61 64 69 6E 67  le.Error loading
006380B0  20 6F 70 65 72 61 74 69 6E 67 20 73 79 73 74 65   operating syste
006380C0  6D 00 4D 69 73 73 69 6E 67 20 6F 70 65 72 61 74  m.Missing operat
006380D0  69 6E 67 20 73 79 73 74 65 6D 00 00 00 00 00 00  ing system......
006380E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
........
006381A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
006381B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 01  ..............€.
006381C0  01 00 04 0F C2 E5 02 00 00 00 BE 7C 00 00 00 00  ....Âå....¾|....
006381D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
006381E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
006381F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA  ..............Uª

There is a single "DOS 3.0+ 16-bit FAT" partition (type 04) beginning at sector 2 with a size of 0x7CBE sectors.

http://thestarman.pcministry.com/asm/mbr/STDMBR.htm
https://www.win.tue.nl/~aeb/partitions/ ... pes-1.html

Here is the MS-DOS 5.0 FAT16 boot sector:

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

00638400  EB 3C 90 4D 53 44 4F 53 35 2E 30 00 02 04 01 00  ë<.MSDOS5.0.....
00638410  02 F0 00 BE 7C F8 20 00 02 00 10 00 02 00 00 00  .ð.¾|ø .........
00638420  00 00 00 00 80 00 29 00 00 00 00 20 20 20 20 20  ....€.)....     
00638430  20 20 20 20 20 20 46 41 54 31 36 20 20 20 FA 33        FAT16   ú3
00638440  C0 8E D0 BC 00 7C 16 07 BB 78 00 36 C5 37 1E 56  ÀŽÐ¼.|..»x.6Å7.V
00638450  16 53 BF 3E 7C B9 0B 00 FC F3 A4 06 1F C6 45 FE  .S¿>|¹..üó¤..ÆEþ
00638460  0F 8B 0E 18 7C 88 4D F9 89 47 02 C7 07 3E 7C FB  .‹..|ˆMù‰G.Ç.>|û
00638470  CD 13 72 79 33 C0 39 06 13 7C 74 08 8B 0E 13 7C  Í.ry3À9..|t.‹..|
00638480  89 0E 20 7C A0 10 7C F7 26 16 7C 03 06 1C 7C 13  ‰. | .|÷&.|...|.
00638490  16 1E 7C 03 06 0E 7C 83 D2 00 A3 50 7C 89 16 52  ..|...|ƒÒ.£P|‰.R
006384A0  7C A3 49 7C 89 16 4B 7C B8 20 00 F7 26 11 7C 8B  |£I|‰.K|¸ .÷&.|‹
006384B0  1E 0B 7C 03 C3 48 F7 F3 01 06 49 7C 83 16 4B 7C  ..|.ÃH÷ó..I|ƒ.K|
006384C0  00 BB 00 05 8B 16 52 7C A1 50 7C E8 92 00 72 1D  .»..‹.R|¡P|è’.r.
006384D0  B0 01 E8 AC 00 72 16 8B FB B9 0B 00 BE E6 7D F3  °.è¬.r.‹û¹..¾æ}ó
006384E0  A6 75 0A 8D 7F 20 B9 0B 00 F3 A6 74 18 BE 9E 7D  ¦u... ¹..ó¦t.¾ž}
006384F0  E8 5F 00 33 C0 CD 16 5E 1F 8F 04 8F 44 02 CD 19  è_.3ÀÍ.^....D.Í.
00638500  58 58 58 EB E8 8B 47 1A 48 48 8A 1E 0D 7C 32 FF  XXXëè‹G.HHŠ..|2ÿ
00638510  F7 E3 03 06 49 7C 13 16 4B 7C BB 00 07 B9 03 00  ÷ã..I|..K|»..¹..
00638520  50 52 51 E8 3A 00 72 D8 B0 01 E8 54 00 59 5A 58  PRQè:.rØ°.èT.YZX
00638530  72 BB 05 01 00 83 D2 00 03 1E 0B 7C E2 E2 8A 2E  r»...ƒÒ....|ââŠ.
00638540  15 7C 8A 16 24 7C 8B 1E 49 7C A1 4B 7C EA 00 00  .|Š.$|‹.I|¡K|ê..
00638550  70 00 AC 0A C0 74 29 B4 0E BB 07 00 CD 10 EB F2  p.¬.Àt)´.»..Í.ëò
00638560  3B 16 18 7C 73 19 F7 36 18 7C FE C2 88 16 4F 7C  ;..|s.÷6.|þˆ.O|
00638570  33 D2 F7 36 1A 7C 88 16 25 7C A3 4D 7C F8 C3 F9  3Ò÷6.|ˆ.%|£M|øÃù
00638580  C3 B4 02 8B 16 4D 7C B1 06 D2 E6 0A 36 4F 7C 8B  ô.‹.M|±.Òæ.6O|‹
00638590  CA 86 E9 8A 16 24 7C 8A 36 25 7C CD 13 C3 0D 0A  ʆéŠ.$|Š6%|Í.Ã..
006385A0  4E 6F 6E 2D 53 79 73 74 65 6D 20 64 69 73 6B 20  Non-System disk
006385B0  6F 72 20 64 69 73 6B 20 65 72 72 6F 72 0D 0A 52  or disk error..R
006385C0  65 70 6C 61 63 65 20 61 6E 64 20 70 72 65 73 73  eplace and press
006385D0  20 61 6E 79 20 6B 65 79 20 77 68 65 6E 20 72 65   any key when re
006385E0  61 64 79 0D 0A 00 49 4F 20 20 20 20 20 20 53 59  ady...IO      SY
006385F0  53 4D 53 44 4F 53 20 20 20 53 59 53 00 00 55 AA  SMSDOS   SYS..Uª

The size of the volume matches the partition table (0x7CBE).

The cluster size is 4 sectors at 512 bytes per sector.

There are 2 FATs, each comprising 0x20 (32) sectors.

The number of 32-byte root directory entries is 0xF0 (240).

https://staff.washington.edu/dittrich/m ... gen103.pdf

One copy of the FAT is at 0x638600 - 0x63BFFF, the other is at 0xAF4600 - 0xAF7FFF. Only the first 29 of 32 sectors appear to be present in each block, the remaining 3 sectors are elsewhere. The two FAT copies are identical.

Searching for "NK <6 spaces> BIN" finds several directory entries for NK.BIN.

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

002E6C80  4E 4B 20 20 20 20 20 20 42 49 4E 20 00 00 00 00  NK      BIN ....
002E6C90  00 00 00 00 00 00 14 5D 4E 2E 00 00 00 00 00 00  .......]N.......

00772C80  4E 4B 20 20 20 20 20 20 42 49 4E 20 00 00 00 00  NK      BIN ....
00772C90  00 00 00 00 00 00 59 7D 7C 2C 8D 01 13 57 48 00  ......Y}|,...WH.

00776C80  4E 4B 20 20 20 20 20 20 42 49 4E 20 00 00 00 00  NK      BIN ....
00776C90  00 00 00 00 00 00 59 7D 7C 2C 8D 01 13 57 48 00  ......Y}|,...WH.

0077AC80  4E 4B 20 20 20 20 20 20 42 49 4E 20 00 00 00 00  NK      BIN ....
0077AC90  00 00 00 00 00 00 59 7D 7C 2C 8D 01 13 57 48 00  ......Y}|,...WH.

0083EC80  4E 4B 20 20 20 20 20 20 42 49 4E 20 00 00 00 00  NK      BIN ....
0083EC90  00 00 00 00 00 00 59 7D 7C 2C 8D 01 13 57 48 00  ......Y}|,...WH.

00842C80  4E 4B 20 20 20 20 20 20 42 49 4E 20 00 00 00 00  NK      BIN ....
00842C90  00 00 00 00 00 00 59 7D 7C 2C 8D 01 13 57 48 00  ......Y}|,...WH.

00FCD480  4E 4B 20 20 20 20 20 20 42 49 4E 20 00 00 00 00  NK      BIN ....
00FCD490  00 00 00 00 00 00 59 7D 7C 2C EA 01 13 57 48 00  ......Y}|,ê..WH.

An analysis of the FATs suggests that the actual starting cluster for NK.BIN is 0x1EA (not 0x18D) and the last cluster is 0xAF4.

The size of the file is 0x90B clusters (0xAF4 - 0x1EA + 1 = 0x90B = 2315).

The size in bytes (from the file's directory entry) is 0x485713 (4740883 bytes).

The difference between the two numbers is less than 1 cluster, so clearly the file is not fragmented.

0x90B x 2048 - 4740883 = 237 bytes

So, in short, the NK.BIN file appears to be intact, but you are still left with the task of piecing it together.

_________________
A backup a day keeps DR away.


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 11th, 2015, 4:14 
Offline
User avatar

Joined: May 8th, 2015, 19:08
Posts: 40
Location: Portugal
I guess we need someone then that has FTL file carving capabilities. Anyone?

Thanks for your help... I really appreciate it!


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 11th, 2015, 7:02 
Offline
User avatar

Joined: May 13th, 2010, 11:17
Posts: 2785
Location: Kuwait
joanorsky wrote:
I guess we need someone then that has FTL file carving capabilities. Anyone?

Thanks for your help... I really appreciate it!


Is there any FW update or something for this machine? even if old ver?
i think this would help

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein


Top
 Profile  
 
 Post subject: Re: Help needed - Serious challange with this one
PostPosted: May 11th, 2015, 10:20 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 3844
Location: Adelaide, Australia
Normally, file carving isn't the way to recover from flash. The reason I ask about the chip dumping is because dumping the chip properly can make recovery very much easier. As Franc has shown, there is a problem with the way it was dumped.

Usually you would have bytes called spare area that holds the FTL information. The actual FTL can be tricky or impossible to see as a whole because it is mad up of both hardware (ecc engines, xor engines) and the bytes in the spare area (block numbers, page numbers, page rotations, block conditions, ecc , and more) there is a huge amount of schemes used, and DATA Recovery is performed using only a subset of these attributes of the FTL.

sometimes it can be as simple as looking at each page sequentially, or each page will have a block number and you just piece it together. Other times some info is actually stored by the OS or another special area of the chip such as in TLC chips, and putting it together is a whole lot harder.

Normally there will be some relationship of the Spare area bytes. So if you cut out each spare area bytes and put each spare area 1 after the other, you can see easily the patterns. ever SA might have the 4th and 5th byte FF FF followed by a number that you can tell increments. you can then guess that the incremented number is a page number or block number. I don't see any relationship with the bytes of this dumps SA. Franc could be right and this could be ECC. ECC looks like random data. So this means we should be looking for a translation table that maps the physical pages/blocks to the data image/images. as the TT holds the information instead of the spare area.

If you look in a hex editor, and set the bytes displayed across as the page size (normally a hex editor is 16 bytes across) then these patterns show up quite well. VNR has a bitmap view that is excellent for this work.

The reason you need to find a TT or get block numbers from Spare area is that data is not stored in sequential strings of sectors because of performance and wear levelling reasons. it is quite valid to have blocks in a row 0x22, 0x1E1, 0x01, 0x23.... but once sorted, and spare area stripped off, the data lines back up to an image and file recovery or file carving can be performed. Think of it like shuffling pages of a book, and the spare area is the chapter/page numbers.

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


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

Joined: May 8th, 2015, 19:08
Posts: 40
Location: Portugal
einstein9 wrote:
joanorsky wrote:
I guess we need someone then that has FTL file carving capabilities. Anyone?

Thanks for your help... I really appreciate it!


Is there any FW update or something for this machine? even if old ver?
i think this would help


For my terrible bad luck... There are no firmware or upgrades available for this..


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

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 38 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