EEVblog Electronics Community Forum
Electronics => Repair => Topic started by: martonmiklos on November 06, 2014, 07:54:14 pm
-
Hello all,
I have a dead OCZ Vertex2 SSD built around the Sandforce SF-1222. (PCB PN: PCB-0072-X01) It did not get recognized by the BIOS. I have opened it up and checked the console out.
I had got:
CLI> PINRST
*** ROM 106 Mar 12 2009 20:29:35 ***
FW_SRC 0 SHA PASS!
*** EEPROM 207 Jan 3 2011 18:36:43 BuildServer:FW_Common_Critical_Fixes:P1_EEPROM_2_0_7_drop-290232 ***
Hynix Timing EPch
*** Patch 1.4.1 Apr 8 2011 00:55:09 BuildServer:P1_3_6_1_MP4_Patch1_20110408:P1_3_6_1_MP4_Patch1_20110408-305073 ***
Hynix Timing EPch
RCPch SAK0+Fmgr
And then a lot of binary stuff at 115200. No it does not changes the baud but outputs binary stuff (I have checked it with my Saleae logic analyzer with autobaud).
The board itself did not shown any errors. Then I have removed the I2C EEPROM (ATH052 2ECL written to it -> it should be an 32K AT24C256 http://www.atmel.com/images/atmel-8568-seeprom-at24c256c-datasheet.pdf (http://www.atmel.com/images/atmel-8568-seeprom-at24c256c-datasheet.pdf)) and the console out changed:
CLI> PINRST
*** ROM 106 Mar 12 2009 20:29:35 ***
*** Patch 1.4.1 Apr 8 2011 00:55:09 BuildServer:P1_3_6_1_MP4_Patch1_20110408:P1_3_6_1_MP4_Patch1_20110408-305073 ***
RCPch SAK0+Fmgr
Failed to read EPA=200800C0, using ByteLaneMask=2, ByteLaneTable[0]=1
Failed to read EPA=200800C0, using ByteLaneMask=4, ByteLaneTable[1]=2
Failed to read EPA=200800C0, using ByteLaneMask=1, ByteLaneTable[2]=0
Failed to read EPA=200800C0, using ByteLaneMask=8, ByteLaneTable[3]=3
RCPch SHI
sysclk 150 MHz
JTAG En 0
Link ...
up
And the SSD got recognized as a 25GB drive
The OCZ offers firmware update for their drive, but it does not works until it detects the drive. According to the screenshots available on the web it offers BIOS and Firmware update for the drive.
Does anyone have the similar drive?
-
I had two of them die in about 6 months. They were replaced with different models. There is a reason OCZ went bankrupt and I am pretty sure it was the high RMA rate.
I have no idea if they are repairable.
-
You can try this trick: solder the flash back, but short some of it's signals with tweezers during power on - this should get you into the same mode as w/o flash (so the drive will be detected), but the flash will be available for fw update. Never tried this on this particular model, but it's a common trick to bypass corrupted firmwares.
-
There is a reason OCZ went bankrupt and I am pretty sure it was the high RMA rate.
OCZ is still around
-
There is a reason OCZ went bankrupt and I am pretty sure it was the high RMA rate.
OCZ is still around
The OCZ everyone knows and loved/hated (OCZ Technology) filed bankruptcy in late 2013. Toshiba started a subsidiary called OCZ Storage to buy most of OCZ Technology's assets, and OCZ Technology renamed itself to ZCO.
ZCO - the shell of the "original" OCZ containing its remaining liabilities - was liquidated a couple of months ago.
-
You can try this trick: solder the flash back, but short some of it's signals with tweezers during power on - this should get you into the same mode as w/o flash (so the drive will be detected), but the flash will be available for fw update. Never tried this on this particular model, but it's a common trick to bypass corrupted firmwares.
It is an SPI flash. If I short any of the relevant pins it will not detect so I will end up in the unsoldered state. My problem is that I cannot get the drive to a state where the uploader tool could rewrite the flash.
I see two more possibility:
Social engineering: The tool itself is written in Qt, by an Indian programmer.
The following itresting string can be found in the binary:
update.ocz.com
http://%s/firmware/tools.xml (http://%s/firmware/tools.xml)
tools.xml
minver
http://%s/firmware/fum.php?d=%s&f=%s&v=%s (http://%s/firmware/fum.php?d=%s&f=%s&v=%s)
fwinfo.xml
http://%s/firmware/flood.php?d=%s (http://%s/firmware/flood.php?d=%s)
Pick one preferably unique string: the "fum.php?d="
Do a google search and you will get one result:
http://www.overclock.net/t/1330730/ocz-firmware-2-25-trim-doesnt-work-bug-regression-bad-ocz-experience (http://www.overclock.net/t/1330730/ocz-firmware-2-25-trim-doesnt-work-bug-regression-bad-ocz-experience)
The folks over that forum are trying to downgrade a firmware by mimicing the update.ocz.com.
Ah and they shared a link to a working fum.php url:
http://update.ocztechnology.com/firmware/fum.php?d=latest&f=22853&v=2.22 (http://update.ocztechnology.com/firmware/fum.php?d=latest&f=22853&v=2.22)
Check that XML. Do a quick google search for the "release/sf/ppro" string.
You will have two results the forum above and a qtcentre.org forum entry:
http://www.qtcentre.org/threads/51057-How-to-parse-this-xml-file (http://www.qtcentre.org/threads/51057-How-to-parse-this-xml-file)
If you check his/her posts on the forum: there are a lot of SATA and sql related posts.
So that (s)he should know how the web backend should work, so how could I download my drive's firmware. I have written a PM to him, but he have not answered. He does not seems to be active anymore on that forum.
The second way is the good old reveng:
Disassembling of the updater tool to get out the resource files contents and hope that:
- The actual hardware - firmware association is stored in some kind of db (xml, sqlite, etc.)
- The firmware files are not encrypted and can be written to the flash raw.
The Qt has a resource system to store files in the binary itself. The binwalk shows a lot of LZMA compressed headers which is the same algorithm what is used by the qrc files.
Any idea or more experienced reverse engineering hints are welcome.
-
They were replaced with different models.
You have replaced them on your budget or it was RMA-ed and you got back different drives?
If the first case: do you still have these drives?
If yes: is your drives recognisable by the BIOS/OS?
-
For Vertex 2:
http://update.ocztechnology.com/firmware/fum.php?d=latest&f=12222&v=1.37 (http://update.ocztechnology.com/firmware/fum.php?d=latest&f=12222&v=1.37)
http://update.ocztechnology.com/firmware/release/sf/p1/12222 (http://update.ocztechnology.com/firmware/release/sf/p1/12222)
http://update.ocztechnology.com/firmware/release/sf/p1/12223 (http://update.ocztechnology.com/firmware/release/sf/p1/12223)
-
For Vertex 2:
http://update.ocztechnology.com/firmware/fum.php?d=latest&f=12222&v=1.37 (http://update.ocztechnology.com/firmware/fum.php?d=latest&f=12222&v=1.37)
http://update.ocztechnology.com/firmware/release/sf/p1/12222 (http://update.ocztechnology.com/firmware/release/sf/p1/12222)
http://update.ocztechnology.com/firmware/release/sf/p1/12223 (http://update.ocztechnology.com/firmware/release/sf/p1/12223)
Thanks man! I do not know how did you figured it out, but I would be curious!
Looking into the firmware files it does not seems to be straighforward to figure out where are the EEPROM contents.
I do not know what level of security did they implemented, but it would not be surprising if the EEPROM contents would be encrypted.
Meanwhile I have hooked up my logic analyzer, and figured out that the EEPROM is an I2C one.
The marking says ATH052 2ECL. It should be an AT24C256C:
http://www.atmel.com/Images/doc8568.pdf (http://www.atmel.com/Images/doc8568.pdf)
-
ssd firmware is bigger than 32KB of that eprom, most likely controller chip has its own flash memory
-
I use OCZ vertex II drives. Never had a problem...
-
I have had endless premature failures with OCZ SSD.
I have been really disappointed with their performance life.
I now stump up the extra dosh and purchase Intel and Samsung SSDs.
-
my vertex 2 still works after 4years as system drive but 1 corsair died with the same sandforce controller within a year
-
I know this is a dated thread, but I’ve scoured the web for help with little results. I have a long out-of-warranty OCZ Vertex 2 SSD 120G that is no longer recognized by any BIOS on any machine I try. Research leads me to deduce the culprit as the windows sleep-wake bug that trashed this SSD (both red and green LEDs stuck on during power up).
I don’t need to recover any data, but hope someone could guide me through some JTAG instructions so I could at least unbrick it long enough to update firmware and make it usable again.
Go easy on me as I only know a bit about JTAG, but am great at using step-by-step instructions. I am PC literate and handy with a soldering iron as I have successfully custom built my own JTAG connectors for serial and USB access in a couple of past projects. With instructions I can find my way around Windows based Putty for terminal emulation, and have dabbled with Linux a bit too. I have at my disposal several hobby PCs which I constantly reconfigure for projects as needed (i.e. to run legacy Win XP apps or install versions of Linux). I sure hope someone can help. Thanks.
-
Just to make some notes if someone struggling with the same.
I have been able to read the EEPROM with a Pickit3:
https://dl.dropboxusercontent.com/u/4295670/OCT_PCB-0075-x02_unknown.BIN.zip (https://dl.dropboxusercontent.com/u/4295670/OCT_PCB-0075-x02_unknown.BIN.zip)
I have found an another EEPROM dump here which is quite similar, but from board PCB-0075-02:
http://www.mobile-files.com/forum/showthread.php?345247-%D0%94%D0%B0%D0%BC%D0%BF-%D0%95%D0%9F%D0%A0%D0%9E%D0%9C-U5-AT24C256-%D0%BD%D0%B0-SSD-OCZSSD2-2VTXE60G (http://www.mobile-files.com/forum/showthread.php?345247-%D0%94%D0%B0%D0%BC%D0%BF-%D0%95%D0%9F%D0%A0%D0%9E%D0%9C-U5-AT24C256-%D0%BD%D0%B0-SSD-OCZSSD2-2VTXE60G)
It has a string "hasnladsrudyvlad" at the beginning. It is strange because if I look at the I2C traffic this portion is read separately then the others.
I have managed to erase it, and the UART output is the same when I depopulate it:
CLI> PINRST
*** ROM 106 Mar 12 2009 20:29:35 ***
*** Patch 1.4.1 Apr 8 2011 00:55:09 BuildServer:P1_3_6_1_MP4_Patch1_20110408:P1_3_6_1_MP4_Patch1_20110408-305073 ***
RCPch SAK0+Fmgr
Failed to read EPA=200800C0, using ByteLaneMask=2, ByteLaneTable[0]=1
Failed to read EPA=200800C0, using ByteLaneMask=4, ByteLaneTable[1]=2
Failed to read EPA=200800C0, using ByteLaneMask=1, ByteLaneTable[2]=0
Failed to read EPA=200800C0, using ByteLaneMask=8, ByteLaneTable[3]=3
RCPch SHI
sysclk 150 MHz
JTAG En 0
Link ...
up
I have tried to program back the original contents, but it fails to write it properly. Maybe the EEPROM had been written too many times?
-
what is the part number of the EEPROM? Some can be write-protected (effectively write-once). E.g. the SPD EEPROM on memory modules is commonly write protected to prevent fraudsters re-programming and re-selling cheap modules as faster ones.
-
Hey all!
Did you have any luck in unlocking or fiddling with the firmware via JTAG ?
I have been able to read mine but have no idea how to go about flashing via JTAG or just unlocking the controller so I can get the drive working again.
I have a Vertex II 80Gb that is in panic lock and all else seems to be owrking just that it wont recognize the drive in BIOS.
My terminal output from JTAG is as follows:
CLI> PINRST
*** ROM 106 Mar 12 2009 20:29:35 ***
FW_SRC 0 SHA PASS!
*** EEPROM 207 Jan 3 2011 18:36:47 BuildServer:FW_Common_Critical_Fixes:P1_EEPROM_2_0_7_drop-290232 ***
IMFT25 Timing EPch
*** Patch 1.4.1 Feb 3 2011 11:57:33 BuildServer:FW_Common_Critical_Fixes:P1_3_4_H_Drop-294933 ***
IMFT25 Timing EPch
RCPch SAK0
And after this only gibberish with some readable words like: ".dump.elf" ".clistrings1" ".strtab" and ".symtab"
No idea what to make of it or how to proceed.
Please help if you have any ideas, thanks in advance! :)
-
I know this thread is old, but just want to post something that might be useful for people searching around.
In order to fix the Vertex 2 when not recognized by the BIOS, you will need the manufacturing tool called mp_tool by Sandforce together with the license file *.lic and the firmware package file *.dst. All of these are posted in a site in China so use baidu.com to search for it. The mp_tool is included in an image of 1.2GB or so which you will need to write to a USB drive and boot from the USB drive. The site that posts the tool included the instruction so follow it.
As far as the Vertex 2 SSD goes, you will need to connect P8 and P9 (the two copper pads in the back of the PCB) when powering it up to force it into manufacturing mode to allow the mp_tool to talk to it via the SATA cable. So jump those two pads, connect the power cable and after a few second disconnect the two pads because when the mp_tool talks to the drive, at some point in time it will reboot the drive and you don't want to force it into manufacturing mode at that time.
If your drive configuration is not included in the *.lic file, it gets much harder because you will have to modify the mp_tool itself to overwrite things, which I am not going into details beside the fact that the tool is written in python script and you should be able to decompile it and modify the script as you like.
As far as the serial port goes, there is a tool called ecli.exe that will decode the output and display something readable, which might be useful when the mp_tool fail, you could find out why it fail from the serial output.
-
I know this thread is old, but just want to post something that might be useful for people searching around.
In order to fix the Vertex 2 when not recognized by the BIOS, you will need the manufacturing tool called mp_tool by Sandforce together with the license file *.lic and the firmware package file *.dst. All of these are posted in a site in China so use baidu.com to search for it. The mp_tool is included in an image of 1.2GB or so which you will need to write to a USB drive and boot from the USB drive. The site that posts the tool included the instruction so follow it.
As far as the Vertex 2 SSD goes, you will need to connect P8 and P9 (the two copper pads in the back of the PCB) when powering it up to force it into manufacturing mode to allow the mp_tool to talk to it via the SATA cable. So jump those two pads, connect the power cable and after a few second disconnect the two pads because when the mp_tool talks to the drive, at some point in time it will reboot the drive and you don't want to force it into manufacturing mode at that time.
If your drive configuration is not included in the *.lic file, it gets much harder because you will have to modify the mp_tool itself to overwrite things, which I am not going into details beside the fact that the tool is written in python script and you should be able to decompile it and modify the script as you like.
As far as the serial port goes, there is a tool called ecli.exe that will decode the output and display something readable, which might be useful when the mp_tool fail, you could find out why it fail from the serial output.
Thanks for sharing this knowledge and welcome to the forum.
I've got a couple of OCZ SSD's that have never given an ounce of trouble and of course I hope they never do. :scared:
Anyway, your tips might help someone else out of a hole. :-+
-
I know this thread is old, but just want to post something that might be useful for people searching around.
Thanks for sharing. I picked up a couple of used OCZ Vertex 2 drives for $5 each. Perfect for my small linux lightweight distros that I use on a daily basis.
-
If you plan on using these SSDs with the Sandforce SF-1200 series controller, it is a good idea to download these tools now and save them somewhere for later since they will probably won't be available forever. The links below are completely DOWNLOAD AT YOUR OWN RISK!!!! I recommend using a junk computer for all of these activities since the files are from China so please be very careful using them.
Link to mptool, firmware, and license file download:
http://pan.baidu.com/s/1m9Oia#list/path=%2FSF1222 (http://pan.baidu.com/s/1m9Oia#list/path=%2FSF1222)
(Use Tampermonkey browser add-on to download if you don't have a baidu account. You could copy the link generated by the add-on and use a download manager to connect as many connection as you can at the same time because a connection is normally slow and timeout very quickly before you could download much at all.)
Russian forum where I got the link above from, it also got the link to the instruction:
http://forum.ru-board.com/topic.cgi?forum=84&topic=4797&start=0&limit=1&m=6#1 (http://forum.ru-board.com/topic.cgi?forum=84&topic=4797&start=0&limit=1&m=6#1)
Here is the link to the eCLI application used for SF-2000 series, but seem to work fine with SF-1200 series:
http://www.upantool.com/ssd/tool/sandforce/10232.html (http://www.upantool.com/ssd/tool/sandforce/10232.html)
-
The links below are completely DOWNLOAD AT YOUR OWN RISK!!!!
Understood. Thanks for the links.
-
Could you please send me a link to the tampermonkey script?
Thanks in advance!
-
Could you please send me a link to the tampermonkey script?
Thanks in advance!
https://zukfans.eu/community/threads/how-to-download-pan-baidu-com-links-directly-from-idm.1944/
-
Here is the link to Tampermonkey on Firefox:
https://addons.mozilla.org/en-US/firefox/addon/tampermonkey/
Don't know about other operating systems, but on Ubuntu I just click on "Add to Firefox", restart the browser, then when you click on the download icon from baidu, the browser will just ask you to save the file without having to install any other script.
-
Thanks man! :-+
I have managed to get the mentioned drive back to life.
Side notes:
- The mptool uses some older Fedora distribution, on newer systems (NVIDIA quadro GPU in my case) you might get black screen or 640*480 resolution where you cannot access the buttons properly. Use an older preferably Intel GPU based system (I have used an old Core2 DUO based HP notebook)
- I have used esata adapter which made the retry cycles easy.
- I have wasted a lot of time because I have tried to recover my drive with a blank IIC EEPROM (in this mode it came up in mfg mode by default). I have had to flash back the malformed (bad) contents, put to MFG mode with the P8-P9 jumper and then it went smootly. This particulary breaks the theory that the drive is stopped due the malformed I2C chip contents.
-
Hi, i've tried to resurrect my OCZ Vertex 2 following the provided instructions but I can’t complete the entire procedure. Maybe I do something wrong...
Here below what I’ve done:
- PC powered off;
- Disconnected optical drives and disks except the SSD to restore;
- Switch on the PC while shorting P8-P9 for few seconds (-> green light with a single flash of red light);
- SSD detected by BIOS as “Sandforce”;
- Boot from Live USB;
During boot process, some some errors appear:
ata2: link is slow to respond, please be patient (ready=0)
ata2: device not ready (errno=-16), forcing hardreset
ata2: link is slow to respond, please be patient (ready=0)
ata2: SRST failed (errno=-16)
When I launch MPTool from the Desktop an error appears in the background terminal window:
insmod: error inserting ‘./ssdt_driver.ko’: -1 Operation not permitted
Then I follow the procedure successfully until step 11. In step 12, in the "Manufacturing Config" tab, the “Config Name” field is empty, no option available and the mask is disabled, only the buttons at the bottom are available (Update license, etc…).
Can someone give me some hint?
Thank you in advance!
-
Hi,
When I did the recovery I have soldered a jumper to the P8-9 and only removed when the recovery procedure was at the rebooting drive stage.
The ata2 errors in the dmesg are normal I think (I also have had a few).
I do not remember to the "operation is not permitted" error.
On the manufacturing config tab you have to browse for the pkg file generated in the previous steps. Once you have loaded it it will enable the rest of the widgets.
-
I had one of these OCZ drives which bricked as well. Luckily it was in guarantee but I would stay away now. Having realised the hard way that consumer SSDs can corrupt their internal state during unexpected power down, i've now moved to use the datacentre ranges of SSDs (Intel & Samsung) which have 'supercapacitors' that provide backup power for long enough to complete in-flight writes. These are more expensive but they also have better reliability and typically better performance as well.
-
Hello
I want unbrick my old ocz vertex 2.
Anyone can reupload mptool ? Cause this link http://pan.baidu.com/s/1m9Oia (http://pan.baidu.com/s/1m9Oia) is dead.
Edit:
By vpn link is works.
I made mirror:
https://drive.google.com/drive/folders/0B42B8K8c0zs_MFp1eS1MUnRWYUE?usp=sharing (https://drive.google.com/drive/folders/0B42B8K8c0zs_MFp1eS1MUnRWYUE?usp=sharing)
-
If anyone would have a similar tool for the SF-22xx family and would be able to share it I would deeply appericiate!
-
I've found something...I hope this can help you.
https://yadi.sk/d/ArxahL0xvikaS
-
Hi,
I have PCB-0025-X01
and not found P8 e P9 to solder!
and.... I try to connect serial tag but nothing! |O
any help?
thanks
-
Hello everybody,
A friend have a OCZ vertex Le went i think in panic mode.
I tried to reflash firmware.
I used the tool from ocz toolbox boot onto a usb but the ssd isn't recognized
I have a similar error like alexsio error -16 on boot with tool from ocz when Linux at startup try to open sata channel.
I understood I have to enter a kind of managment mode (MFG mode) but I havn't any p8 p9 where to solder jumper connector. My SSD isn't a Vertex 2 but a Vertex Le based onto a OCZ ICT0027 controller Anandtech said many yaers ago it was something hybrid controller between SF 1200 e SF 1500
I would be gratefull if any of you may help me identifing what connector to jumper to make ssd visible to flashing firmware tool.
Thank you for your kind help.
Diego
-
Hi
I have vertex 2 120GB that i'm trying to re-flash but when i get to the select "flash part number" it does not have my part number (29f64g08cbaaa) but if i change the drive capacity to (100GB) then it shows me the flash part number i have. Does any one have the firmware for my flash number or have a suggestion on a work around.
SSD Info:
Model: OCZSSD2-2VTXE120G
Flash: 29f64g08cbaaa
Controller: Sandforce sf-1222TA3-SBH
Thank you
-
Hi,
first of all I want to thank you for sharing all the information above, which finally allowed me to fix bricked Vertex2!
Here are some observations which may help others trying to do the same:
- I used push button to connect P8 - P9, pressed it before turning PC on, holding all the time until MPtool starts to process (format) it
- In case that SSD is detected by BIOS (as Sandforce because P8 and P9 connected together) but not in MP Tool and the console launched together with MP Tool complains about "insmod: error inserting ‘./ssdt_driver.ko’: -1 Operation not permitted" make sure you enabled AHCI in BIOS or try to use different motherboard (PC) for the procedure. I was not able to get Vertex detected in MP Tool on Gigabyte GA-K8NE mobo (quite old, no AHCI option in BIOS) and MSI MS-7592 ver 7.1 (also old one, no AHCI in BIOS again), both showing "ssdt_driver.ko" error in console. Then I tried much newer Asus Z97M-plus and everything worked as expected.
I have one more question: Is anybody able to tell me which version of Sandforce SF 1222 firmware (or OCZ Vertex2 fw, as the OCZ fw numbering differs from original SF numbering) is fixing this "brick issue" (=prevents from bricking again)?
Here are my notes with some pictures of the procedure: http://buger.dread.cz/ocz-vertex2-unbrick.html (http://buger.dread.cz/ocz-vertex2-unbrick.html)
Thanks again :-)
-
Hi,
I have PCB-0025-X01
and not found P8 e P9 to solder!
and.... I try to connect serial tag but nothing! |O
any help?
thanks
I have the same revision board. No P8 or P9 pins. It's a 60GB one.
I'll investigate but in case anyone knows; where are these P8 and P9 pins connected to?
Any hints are welcome. :)
Thanks guys.
/update1: Okay i think i'm just going to try blocking the SDA signal on startup. (i'll do this by shorting SDA to VCC) wish me luck. ;)
/update2: Just tried it and it indeed goes into MFG mode (bios shows a 25gb Sandforce disc) but i just cannot seem to get the tool to recognize the SSD.
/update3: Okay next i shorted pin 2 and 3 of the Atmel, same issue as before.
Then I tried a different SATA controller on mainboard (marvel) this one actually worked!! So i have my SSD back running again.
Next on the list is to find the correct device ID's so i can use the official OCZ toolbox for updating the firmware etc.
-
I have one more question: Is anybody able to tell me which version of Sandforce SF 1222 firmware (or OCZ Vertex2 fw, as the OCZ fw numbering differs from original SF numbering) is fixing this "brick issue" (=prevents from bricking again)?
I have two Vertex 2 80GB, SF1222 ... latest firmware is v1.37 (as far as I know)
Thanks for the guide and links, I was able to revive one of the SSDs which I bricked after I "forgot" to switch off the sleep on my laptop - The laptop slept, the SSD never woke up again.
I'm not aware of a standalone way to flash the firmware. I think (although not sure), that this link downloads the latest firmware from OCZ (now Toshiba's) server :
http://update.ocztechnology.com/firmware/release/sf/p1/12222 (http://update.ocztechnology.com/firmware/release/sf/p1/12222)
(as referred to in this post - https://www.eevblog.com/forum/repair/ocz-vertex-2-ssd-firmware/msg565210/#msg565210 (https://www.eevblog.com/forum/repair/ocz-vertex-2-ssd-firmware/msg565210/#msg565210) )
If someone knows how to (force) flash that, would be helpful, but obviously need to confirm it's the right file first.
By the looks of things, the OCZ server that provides Firmware update for older SSDs still is online (for how much longer, who knows). Firmware can be updated in linux using a download I found on Arch linux website https://aur.archlinux.org/packages/ocztoolbox/ (https://aur.archlinux.org/packages/ocztoolbox/) :
http://url.muflone.com/ocztoolbox-4.9.0.634_linux.tar.gz (http://url.muflone.com/ocztoolbox-4.9.0.634_linux.tar.gz)
Just download, extract and run the executable.
There are also versions of standalone OCZ Bootable tools, which is based on TinyCoreLinux. It's a bit more fiddly to setup, as you'd need to create a USB stick, that boots, then mounts and boots the .ISO file from the USB stick (the .ISO provided by OCZ doesn't include a bootloader !). What I think is the latest version can be downloaded here :
https://web.archive.org/web/20140716061012/http://ocz.com/consumer/download/firmware/OCZ_PC_Bootable_Tools-5.4.298_UUI.zip (https://web.archive.org/web/20140716061012/http://ocz.com/consumer/download/firmware/OCZ_PC_Bootable_Tools-5.4.298_UUI.zip)
AND, there's a Windows tool which still also seems to work (latest version I think) :
https://web.archive.org/web/20160320062612/http://ocz.com/consumer/download/firmware/OCZToolbox_v4.9.0.634_win32.zip (https://web.archive.org/web/20160320062612/http://ocz.com/consumer/download/firmware/OCZToolbox_v4.9.0.634_win32.zip)
Regarding "MP Tool", it's quite fiddly, but it's really worth persevering with it, because eventually I managed to bring the SSD back, even though I was getting errors in the log window.
Of note is, if you want to at least try to update the firmware (or at least, for any of the OCZ tools to recognise the drive) with any of the above tools, you'd need to setup the Drive information a bit more precisely. Of note are :
"IEEE Company ID" - I believe this should be set to "E83A97" (The hex code for 'OCZ Technology Group')
"Increment" - I set to "0"
"Serial Number" - I wasn't able to get the WWN to match what my "good" drive reported in 'smartctl -a' ... anyway I just entered "fcd03878d", which is part of my serial number.
To confuse matters there's a decimal serial number printed on the SSD case, which doesn't seem to match the Hex one reported in smartctl -a
Maybe there's a setting somewhere in MP Tool to set it up correctly, never used it before, so I don't know.
And "Model Number" - I set to "OCZ-VERTEX2" (again what's reported in smartctl -a
And, also, I don't know if this makes any difference but I changed "Flash Connectivity Test" to False.
With my doing all these things I was able to get both *all* of OCZ tools suggested above to recognise the drive, but unfortunately, they all reported back the the drive had rejected the firmware update. As I can make use of the drive anyway, doesn't really matter, and I'm out of time now.
Hope this is helpful.
-
DonCharisma, many thanks for sharing your experience!
Regarding to the WWN: I have found the following in an SF-2xxx docs:
Serial No.: The serial number to assign to this device in the final stages of the drive’s
manufacturing process. As described in the Diagnostic specification document, this field is a
maximum of 20 characters. SF_Genesis does not manage increment, monitor, or enforce the
serial number assignment scheme internally. It is the responsibility of the manufacture to
maintain and supply serial numbers to the tool appropriately.
WWN: The World Wide Name to assign to this device in the final stages of the drive’s
manufacturing process. SF_Genesis does not manage, increment, monitor, or enforce the
WWN assignment scheme internally. It is the responsibility of the manufacture to maintain and
supply serial numbers to the tool appropriately. The world wide name will have the following
format for SSD drives:
5 + 6 Nibble OUI + 9 Nibbles of Unique ID = 16 Nibbles
This input should be provided as a single continuous string as a hexadecimal number such as:
512AB23000CDFF0A
NOTE: When assigning World Wide Names for SAS drives, four sequential numbers should be allocated for each manufactured drive. The SF_Genesis only requires the first one to be entered at command line. However, it is the responsibility of the OEM partner’s WWN management
system to increment the WWN numbers by four for every drive manufactured.
So serial number and WWN seems to be two different fields.
-
I have one more question: Is anybody able to tell me which version of Sandforce SF 1222 firmware (or OCZ Vertex2 fw, as the OCZ fw numbering differs from original SF numbering) is fixing this "brick issue" (=prevents from bricking again)?
I have two Vertex 2 80GB, SF1222 ... latest firmware is v1.37 (as far as I know)
Thanks for the guide and links, I was able to revive one of the SSDs which I bricked after I "forgot" to switch off the sleep on my laptop - The laptop slept, the SSD never woke up again.
I'm not aware of a standalone way to flash the firmware. I think (although not sure), that this link downloads the latest firmware from OCZ (now Toshiba's) server :
http://update.ocztechnology.com/firmware/release/sf/p1/12222 (http://update.ocztechnology.com/firmware/release/sf/p1/12222)
(as referred to in this post - https://www.eevblog.com/forum/repair/ocz-vertex-2-ssd-firmware/msg565210/#msg565210 (https://www.eevblog.com/forum/repair/ocz-vertex-2-ssd-firmware/msg565210/#msg565210) )
If someone knows how to (force) flash that, would be helpful, but obviously need to confirm it's the right file first.
By the looks of things, the OCZ server that provides Firmware update for older SSDs still is online (for how much longer, who knows). Firmware can be updated in linux using a download I found on Arch linux website https://aur.archlinux.org/packages/ocztoolbox/ (https://aur.archlinux.org/packages/ocztoolbox/) :
http://url.muflone.com/ocztoolbox-4.9.0.634_linux.tar.gz (http://url.muflone.com/ocztoolbox-4.9.0.634_linux.tar.gz)
Just download, extract and run the executable.
There are also versions of standalone OCZ Bootable tools, which is based on TinyCoreLinux. It's a bit more fiddly to setup, as you'd need to create a USB stick, that boots, then mounts and boots the .ISO file from the USB stick (the .ISO provided by OCZ doesn't include a bootloader !). What I think is the latest version can be downloaded here :
https://web.archive.org/web/20140716061012/http://ocz.com/consumer/download/firmware/OCZ_PC_Bootable_Tools-5.4.298_UUI.zip (https://web.archive.org/web/20140716061012/http://ocz.com/consumer/download/firmware/OCZ_PC_Bootable_Tools-5.4.298_UUI.zip)
AND, there's a Windows tool which still also seems to work (latest version I think) :
https://web.archive.org/web/20160320062612/http://ocz.com/consumer/download/firmware/OCZToolbox_v4.9.0.634_win32.zip (https://web.archive.org/web/20160320062612/http://ocz.com/consumer/download/firmware/OCZToolbox_v4.9.0.634_win32.zip)
Regarding "MP Tool", it's quite fiddly, but it's really worth persevering with it, because eventually I managed to bring the SSD back, even though I was getting errors in the log window.
Of note is, if you want to at least try to update the firmware (or at least, for any of the OCZ tools to recognise the drive) with any of the above tools, you'd need to setup the Drive information a bit more precisely. Of note are :
"IEEE Company ID" - I believe this should be set to "E83A97" (The hex code for 'OCZ Technology Group')
"Increment" - I set to "0"
"Serial Number" - I wasn't able to get the WWN to match what my "good" drive reported in 'smartctl -a' ... anyway I just entered "fcd03878d", which is part of my serial number.
To confuse matters there's a decimal serial number printed on the SSD case, which doesn't seem to match the Hex one reported in smartctl -a
Maybe there's a setting somewhere in MP Tool to set it up correctly, never used it before, so I don't know.
And "Model Number" - I set to "OCZ-VERTEX2" (again what's reported in smartctl -a
And, also, I don't know if this makes any difference but I changed "Flash Connectivity Test" to False.
With my doing all these things I was able to get both *all* of OCZ tools suggested above to recognise the drive, but unfortunately, they all reported back the the drive had rejected the firmware update. As I can make use of the drive anyway, doesn't really matter, and I'm out of time now.
Hope this is helpful.
Hey, thanks for the extra info. It really helped to make my resurrected OCZ Vertex 2 60gb be recognized in OCZ Toolbox. But like you said firmware update fails. Maybe the name of the firmware already in the drive can provide some clues? Mine says it's in firmware 346A13F0. I tried some HEX and ASCII converters but it doesn't seem to mean anything. Did you ever manage to flash your drive with regular tools?
-
Hi folks.
I think I have the same problem, but on an Agility 2.
OCZ Agility 2 90GB - PN: OCZSSD2-2AGTE90G
PCB-0025-X01
It stopped working properly after a Windows sleep.
It is seen by the motherboard (ASUS P5Q-EM), sometimes. But then any attempt to access it causes it to 'freeze'.
I have located MPTools - can boot to that from a USB drive.
MPTools doesn't see the drive.
Per bugerdread's post, on the Vertex 2, two jumpers are described (P8, P9) that put that drive into MFG mode so that MPTools will talk to the drive. The Agility 2 does not have these jumpers.
Does anyone know what the equivalent jumpers would be on this PCB? Or, if there is another method for MFG mode (it was suggested to me that putting the drive into an external USB caddy would do the trick - I have yet to try it)?
Also, I saw KBDE's post. I am not an electronics technician, so I'm hoping someone could explain this to me. 'SDA' I know as a Linux drive designation, and 'VCC' is one of the connections on the serial connector on the board.
My technical level: I can properly follow step-by-step guides, use a multimeter, solder, build and configure a PC without killing it in the process.
Any help appreciated.
Cheers,
Stuart.
-
Hello people!
First of all, thank you for all the information in this thread and all the time spent.
I am on the same situation here. A 120GB Vertex 2 without the P8-P9 points.
Apart from being able to get it to mfg mode, I would also like to ask if the OCZ tool works atm, because I read that it only works while connected to internet and it probably was supposed to connect to OCZ servers to download the firmware.
So, if I succeed in getting it in mfg mode and ocz tool recognizes the drive, how am I gonna update it to 1.37 FW?
Thank you in advance.
-
I have a OCZ Vertex 2 60GB SSD. It just died today.
The pcb does not have the P8 and P9 test points.
The SDA that is referred to by KBDE is on the Amtel serial eeprom (U4 on the pcb). The datasheet shows pn 4 as GND, pin 5 as SDA, pin 8 as VCC. You can verify pin 4 (GND) and 8 (VCC) by doing a resistance/continuity test to the jtag interface.
So if you don't have P8 and P9, look at U4 and then find your datasheet. The datasheet will tell you what pin is SDA, VCC and GND.
So you need to short pin 5 to pin 8.
I have downloaded all the files from the google drive share, but I haven't started repair process yet.
I probably won't have time until the weekend to try and restore my drive.
-
I'm not sure how aware people are of this, but these drives and their controllers are well known to cause trouble. Recover any data you can, but don't trust these drives any further than you can throw them. Move on to something less sketchy. If you're running one, back your data up immediately and assume imminent failure.
-
Mine was being used soley as boot drive for Lubuntu. All my critical data is backed up daily onto a separate drive.
If I can get the Vertex fixed, it's going into a test system as a linux boot drive.
-
if you want to play Sandforce, at least from SF2281, since the license calculator already been released for more than one year, you can flash it via a Linux OS
-
Hello everybody,
I have 4 of those SF 1222 ssds with all different flash configurations, three OCZ Vertex 2 and one Cnmemory Phantom 2. But when I try to reflash them with the mptool, it allways fails and I receive error messages like this:
Using SSDT release ssdtMptool1.1.1.
Device enumeration IOCTL failed
Unable to get driver error message
****SSDT Driver Error: Begin****
****SSDT Driver Error: End****
Devices detected = 1
Devices no 0:
Devices have been scanned again. Please select the new devices
Identify Device IOCTL call failed. ErrorCode = 80C0000C
****SSDT Driver Error: Begin****
IDENTIFY DEVICE Failed ata1: status=0xec { Busy }
****SSDT Driver Error: End****
All downloads have completed.
I tried it on two different boards with ahci support as suggested, an OEM MSI MS-7366 Motherbord with Nvidia MCP73 chipset und an ASrock Z68 Extreme3 Gen3. On the ASrock board it failed in the "processing drive" stage and stayed in manufacturing mode. On the MSI board it came to the "rebooting drive" stage and failed there. After that it was not recognised anymore until reboot. It seems that the initial processing should be successful as the BIOS reports the configured capacity and it shows up as "Sandforce IDE Hard Disk".
It would be quite strange if all of the drives are dead, since I got them from different sources and none of the "warranty void if removed" stickers were damaged.
Has anybody here experienced similar problems, e.g. if the Atmel eeprom chip was removed/erased or certain boards were used?
I only found a russian forum thread where this problem was mentioned but they never came back to it: http://forum.ru-board.com/topic.cgi?forum=84&topic=4797&start=1880 (http://forum.ru-board.com/topic.cgi?forum=84&topic=4797&start=1880)
Thank you in advance.
-
Considering the reputation of those drives and the fact that this basically bankrupted OCZ, I'd take into serious consideration all four drives are dead.
-
Hello again,
I finally managed to recover all 4 of the drives. I tried the tool on yet another board and it finally went through without errors. It was on a Dell Optiplex 330, which has the intel G31 Northbride and the intel ICH7 Southbridge. I still don't know why it didn't work on the other 2 boards. :-//
One ssd had a configuration with 16 x MT29F64G08CBAAA flash chips but was listed only as 100GB instead of 120GB written on the drive, I guess that it now has 20GB more space for overprovisioning, which should theoretically increase performance.
Another ssd had 32 x JS29F32G08AAMDB flash chips soldered on but I only found a configuration with 16 of them for a total of 60GB instead of the physical 120GB. If somebody finds a .dst file with its original configuration, please let me know. For now i stick with 60GB, which is better than nothing.
As mentioned before I can't recommend storing anything important on those drives which you can't afford to lose. Also don't use those drives in mission critical environments, as the firmware could crash at any given moment and cause at least a downtime! For me I only plan to use them in hobbyist projects as they are way faster than hard drives and using them avoids unnecessary e-waste.
Thanks for sharing the information on this.
-
I think you will find that the NAND supply voltage is 2.8V. I've always wondered whether this lower voltage makes the SSD more susceptible to Flash Translation Layer corruption during sudden power loss events. It shouldn't be too difficult to reprogram the feedback resistors in the regulator's potential divider for 3.3V ...
-
On account of a failing power supply, my trusty Patriot Inferno 120GB (SF-1222 based) went into panic mode after about 20 random abrupt shutdowns.
Thanks to KBDE's comment about shorting SDA to VCC on the EEPROM, I used an SOIC-8 clip with a jumper between pins 5 and 8 for a seamless no-solder recovery using MP-Tool.
As I'm sure others have noticed, the licence file used in this recovery method is meant for "asiacom", which afterwards causes the OCZ, Patriot, etc. firmware update utilities to fail.
My drive now seems stuck at revision level 346A13F0 instead of 363A13F0, which was the latest released firmware from Patriot Memory.
It's working, so I'm happy, but it would be nice to know if there's a way to apply v3.6.3 or even v3.7.0 (the latest from OCZ AFAIK).
I'm sure the answer is buried in there somewhere!
http://gallery.ru-board.com/topic.cgi?forum=84&topic=4797 (http://gallery.ru-board.com/topic.cgi?forum=84&topic=4797)
http://gallery.ru-board.com/topic.cgi?forum=84&topic=5239 (http://gallery.ru-board.com/topic.cgi?forum=84&topic=5239)
http://gallery.ru-board.com/topic.cgi?forum=84&topic=5360 (http://gallery.ru-board.com/topic.cgi?forum=84&topic=5360)
http://gallery.ru-board.com/topic.cgi?forum=84&topic=5471 (http://gallery.ru-board.com/topic.cgi?forum=84&topic=5471)
-
Worthy bump!
Today I found a Vertex2 SSD in my long-abandoned junk bin. It was junk for the obvious reason as stated elsewhere - it locked up at some point long ago, who knows how... probably by going to sleep (I use sleep on my laptops multiple times a day, like you put your phone to sleep).
Now some untold years later, I figure there had to be a solution to it by now. Googled it, which led me here. And it led me SO VERY CLOSE to the solution... yet, not quite.
Let me do a little give-and-take exchange here. What I have to offer is my experience with my Vertex2, and what I ask is for any shred of hope that another firmware/manufacturing file may be in existence - because that's what's stopped my efforts cold.
So, what I can tell so far is that our tools available here are very much the result of a leak, probably by a company called AsiaCom (which, quick Google, is a company that offers services like this). No company ever really makes its own products - they develop them, specifying what parts are used, what the controller will do, maybe how things are laid out on the board... and they ask consulting companies for that, then they take the result, send it to a contract manufacturer, then take the resulting product and stuff store shelves with it. AsiaCom was just one contract manufacturer, perhaps of several, that actually built and manufacture-programmed the drives for OCZ. Heck, maybe even AsiaCom did some (or much) of the board design itself, with OCZ's input.
That means this one file is just one leak, of one subset of boards that would be used in a drive with the OCZ Vertex2 label on it. That's actually pretty huge - not many products get a leak like that for repairability reasons. Those files are pretty well legal protected, and AsiaCom could pretty easily lose their contract with OCZ if OCZ were still around... but since they're kinda not so much, it's a bit more open to interpretation. My interpretation is that this is awesome and could save a lot of SSDs from the E-waste shredder...
Mine, not so fortunate. Mine seems to be YET ANOTHER revision of the Vertex2 drive design - unlike the two other variants I've seen so far.
My drive is a 90GB model, labeled "OCZ TECH PCB-0075 X01", and it uses MT (Micron) 29F32G08CBABAWP chips - 24 of them, not 16. There is no configuration choice for that - the one that most closely matches is a 50GB model, but uses 16 chips instead (on scale, that seems correct). However, it also uses a SF-1222 chip, not a SF-1200.
Most importantly, this board does NOT have the P8 and P9 pads in positions that would make sense to do the "manufacturing mode" switch. Instead, it has an unpopulated "J3" thru-hole pattern near the UART port and LEDs. On a hunch, I just shorted the pads when powering it up. It detected as "SandForce" and 28GB-or-so, as expected for manufacturing mode. MPTool happily detected it. I also found that you can totally get it in and out of manufacturing mode by hot-plugging the power connector; MPTool detects it (with the jumper for mfg mode if you want it, of course).
However, any attempt by MPTool to "process drive" in manufacturing mode, or to do self test, data log, etc... just runs into a bus error - ATA command failed, "Error in IOCTL SEND ATA Call. Error code = 80c00002". Google led me to a forum thread on that, lots of info, all in Russian. I might spend the night reading over the Russian forum thread through Chrome's translate... (normally a Firefox user ;) )
MPTool reports my drive as currently being "106A11R0", which highly suggests being the firmware version. Being as though I'm trying to flash something to the tune of 346A13F0, that looks like an entirely different version lineage, and explains why I can't find the right config, nor get the tool to talk to it. It's an entirely different animal.
TL;DR:
- there are variants to the Vertex2, one size doesn't fit all, but might fit most.
- this firmware bundle is a leak, possibly old, thus why it doesn't include all variants.
- the leak might be from only one of several contract manufacturers (CMs) that OCZ used
- there are more firmware files to be found - possibly more versions of MPTool as well.
- my board has a jumper, J2, instead of P8 and P9 pads, to enter manufacturing mode.
- my drive is still dead :(
-
Hello FalconFour
I have a Vertex2 SSD with the same board revision, but not at hand right now. Mine had 32 Intel JS29F32G08AAMDB Chips and no configuraion suited to this. However I managed to sucessfully flash it with a configuration for 16 JS29F32G08AAMDB Chips, which meant that it only had a capacity of 60GB instead of 120GB afterwards.
As far as I know Snadforce only produced one revision of their SF-1200 series, the SF1222 mentioned by you. I am aware that flashing the given firmware would mean a downgrade both in terms of software and drive capacity but for me it was still better then having a drive that doesn't work at all. For me the configuration 12024 seems to be the best choice for you.
As far as i remember this drive has two througholes near the SATA connector shorting those out brought my drive into manufacturing mode. If that doesn't work you can short pins 5 and 8 of the Atmel Chip that always brout my drives into manufacturing mode.
Don't forget to set your SATA mode to AHCI because otherwise the drivers for the MPTool can't load. It's also completely normal if your Mainboard takes ages to get past the POST screen. Sometimes the MPTool fails during one of the two reboot stages in this case it might help to restart the flashing process. I also experineced boards where this always fails with a busy drive error, in this case you have to try it on another board, some chipsets seem to timeout before the drive is ready.
If you have further questions feel free to ask and good luck with your drive.
-
Hi,
does anybody still have the mptool 1.1.2 and could you upload it somewhere?
When I download the mptool from the googledrive mirror, I get a "the disc image file is corrupted" message.
Thanks!
-
Please, anyone.
Thanks!
-
Hello friends. I have OCZ Vertex2 120 GB. This is not working at the moment and I am doing the instructions in the whole forum, but when doing Process Drive it gives this error. I choose the one in the picture which is 100 gb instead of 120 gb. What do you think could be the problem? Or do I have to break this SSD away?[attach=1]
-
Make sure you have selected the right Flash Part Number for your SSD and the correct (or lower) amount of flash chips. If so, you could try to deactivate the Flash Connectivity Test option in the Manufacturing Config tab and save it. It might just check for the flash chips an the wrong adresses. But if you do this, I would suggest to check your SSD afterwards whether the whole capacity is usable or not.
-
Sorry for bringing this old thread back.
I am trying to download the files from BAIDU but unfortunately I cant register an account.
Can anybody please re-share these files?
many thanks
-
Sorry for bringing this old thread back.
I am trying to download the files from BAIDU but unfortunately I cant register an account.
Can anybody please re-share these files?
many thanks
+1
-
Here you go:
https://www.dropbox.com/s/9sqy6vt5rljv1n4/SF1xxx.zip?dl=0 (https://www.dropbox.com/s/9sqy6vt5rljv1n4/SF1xxx.zip?dl=0)
-
Hello FalconFour
I have a Vertex2 SSD with the same board revision, but not at hand right now. Mine had 32 Intel JS29F32G08AAMDB Chips and no configuraion suited to this. However I managed to sucessfully flash it with a configuration for 16 JS29F32G08AAMDB Chips, which meant that it only had a capacity of 60GB instead of 120GB afterwards.
As far as I know Snadforce only produced one revision of their SF-1200 series, the SF1222 mentioned by you. I am aware that flashing the given firmware would mean a downgrade both in terms of software and drive capacity but for me it was still better then having a drive that doesn't work at all. For me the configuration 12024 seems to be the best choice for you.
As far as i remember this drive has two througholes near the SATA connector shorting those out brought my drive into manufacturing mode. If that doesn't work you can short pins 5 and 8 of the Atmel Chip that always brout my drives into manufacturing mode.
Don't forget to set your SATA mode to AHCI because otherwise the drivers for the MPTool can't load. It's also completely normal if your Mainboard takes ages to get past the POST screen. Sometimes the MPTool fails during one of the two reboot stages in this case it might help to restart the flashing process. I also experineced boards where this always fails with a busy drive error, in this case you have to try it on another board, some chipsets seem to timeout before the drive is ready.
If you have further questions feel free to ask and good luck with your drive.
I had this exact board with the 32 Intel JS29F32G08AAMDB NAND chips. On a whim, I decided to flash it with the 120GB configuration with the configuration meant for JS29F64G08CAMDB which according to the datasheet is just a two die version of the JS29F32G08AAMDB. It ended up working and I have the full 120GB capacity on the drive verified by filling up the drive, HDtune, and running a Windows install.
My gut feeling is that the PCB is laid out with CS pins for either 32X JS29F32G08AAMDB or 16X JS29F64G08CAMDB since the JS29F64G08CAMDB essentially is just two JS29F32G08AAMDB in one package.
-
Thanks for your advice degreelessengineer,
I tried it out on my SSD as well and I also can confirm it being working. Although I think you meant that you now have 100GB of capacity as the config I found and ended up using (12011), reports 16X JS29F64G08CAMDB but only 100GB of capacity. As mentioned in an earlier post, I think the remaining capacity is getting used as additional overprovisioning area for the drive. But at least now it uses all the flash chips of my board.
This also shows that if you don't find the exact config of your drive in the list you might want to look out for configs with similar sounding chips and compare their respective datasheets. That is if you can find them.
-
Anyone can reupload mptool ? Cause this link https://www.dropbox.com/s/9sqy6vt5rljv1n4/SF1xxx.zip?dl=0 (https://www.dropbox.com/s/9sqy6vt5rljv1n4/SF1xxx.zip?dl=0) is dead.
-
Sure, here is it: https://www.dropbox.com/s/yv54o7491lbg5tl/SF1xxx.zip?dl=0 (https://www.dropbox.com/s/yv54o7491lbg5tl/SF1xxx.zip?dl=0)
-
Thank you so much friend!!! :clap: