February 3rd, 2012
1:11 pm
OCZ Vertex / ASUS P6T Flash Upgrade process & Issues

Posted under 64 Bit
Tags , , , , , , , , ,

This was done in order to resolve ongoing reliability issues with the OCZ Vertex and SATA port errors from the P6T as detailed here.

This post also follows on from my earlier post here concerning hot swap issues, where I went into some detail of the P6T flashing process. Reference should be made to that post for more details of P6T flashing.

The following steps were performed:-

  1. I identified the current firmware version of my OCZ Vertex. To do this start device manager, find the disk under Disk drives, and open its properties. Then select the Harware Ids property and the version number of the firmware will be shown. There were hints in the forums of a more detailed revision number, but I could not find it. My initial version was 1.5.
  2. I also tried to run the OCZ Toolbox which allows identification and upgrade of the firmware, and also auto downloads the correct new version. I nice idea if it had worked! In my case it failed to find the OCZ Vertex either before or after the upgrade process.
  3. I did note that a number of posts suggested switching the SATA mode to AHCI in both the bios and windows. This OCZ post details the process, which (for the windows part) simply involves changing the value of HKLM\System\CurrentControlSet\Services\msahci\Start in the registry from 3 (=IDE mode) to 0 (= AHCI mode). However, when I tried this at this stage, the system froze at boot time. Fortunately, I was able to switch the setting back in the BIOS, boot into safe mode, and set the registry setting back to 3, to restore the system to a working state.
  4. The latest version for my Vertex was 1.7, but it is not possible to upgrade directly from 1.5 to 1.7. It is necessary to upgrade to 1.6 first. Finding all the historical versions of the firmware is not easy on the OCZ site – the main download area only has the most recent version. Older version may be found from a forum post here which has all the historical downloads.
  5. For my Vertex, here is  the 1.6 upgrade and here is the 1.7 upgrade.
  6. Note that as per the 1.6 upgrade, I had the ‘filename error’ which meant that I had an older version which needed a destructive upgrade to 1.6 due to a change in the NAND/wear levelling algorithm. This would mean loss of all data on the drive and a restore afterwards, and the use of a different kit for upgrading. The upgrade also could not be done with the drive in use as the system disk. The links in the previous paragraph give all the instructions and the alternative versions of the upgrade.
  7. I then made 2 full backups with Acronis, plus another daily file backup, to be sure I would be able to restore the drive.
  8. As per the instructions, I jumpered the drive to set it into standalone/upgrade mode, and booted from the previous version of Windows 7 which I still had available on a standard Hard drive. I kept this available just in case, and on this occasion I was very glad I did.
  9. The destructive upgrade is available as 16_win_vertex.zip. Unfortunately the zip contains 2 versions of the update, 641102VTX.exe and 661102VTXR.exe. There are no release notes to say which version to use or what they are (!) I wondered if they related to the internal firmware/drive version from which you were upgrading, but I didn’t know that either as I have said earlier. Another forum post hinted that as may be expected, the 661102VTXR.exe was a later version and the ’R’ indicated revised. I decided to try this one.
  10. Having jumpered and rebooted, the drive correctly identified itself as YATAPDONG BAREFOOT, and I proceeded with the upgrade, which went successfully.
  11. I then immediately upgraded from 1.6 to 1.7 using 17_updaters_1.zip.  This time, a standard non-destructive upgrade could be done (not that it mattered in my case), which mean burning an ISO on a CD, and booting that to do the upgrade. The zip contained ISOs for a number of OCZ products plus some release notes this time, so I burnt the ISO for the Vertex. I booted it and did the upgrade, which went with no problems. One point is that I cannot recall whether I removed the jumper on the drive before or after this final upgrade. I am fairly sure that it was after, in which case the upgrade does not mind whether the jumper is present, but if there are any issues it should be tried without the jumper present as would be normal for a non destructive upgrade.
  12. Following this, I booted the system. Initially it could not see the Vertex, so I rebooted into the bios, found it was then visible, and did a bios save and another reboot. This time the drive was visible but not formatted.
  13. I then booted Acronis from its rescue CD and restored the backup, plus the Master Boot Record. This proceeded normally.
  14. After rebooting, the system came up and ran fine, however it did present the boot manager from the other disk, and the system had to be selected from there. To prevent the need for this, I copied the boot files back to the new SSD using bcdboot as per this post here. It was also necessary to reset the boot order in the bios so that the SSD was chosen first, otherwise the boot manager is still presented even after you have run bcdboot.

 

Now I had a working system with the updated SSD, I decided to reflash the P6T as well. Previously I had had hot swap and SATA issues with later bios versions, as detail here. However, since then I had disabled the onboard JMicron controller which was giving problems, and replaced it with a Startech controller, as detailed in the update to this post here. Therefore, the original issues which were preventing the use of a later bios were no longer present, so I opted to flash to the latest version which at the time of upgrade was version 1408 :-

  1. I used the in-bios EZ-Flash, and the process and precautions are detailed in the original section of this post here.
  2. I re-applied the required motherboard settings as per the process, and rebooted successfully.
  3. I then retried switching into AHCI mode, as detail above when I tried it prior to the upgrade. This time it worked correctly with no problems. In the bios, I just set the onboard SATA to AHCI. The JMicron controller was disabled, and the Startech controller was not touched as this was an add-in card just used for SATA backups. It is possible that now either the onboard ICH10 SATA or JMicron SATA might work and hot swap reliably in eSATA mode with AHCI enabled, but as I was happy enough with the Startech I decided to leave this issue well alone for now.
  4. As a final test, I re-ran the Windows Experience tests to see if AHCI had improved performance, and indeed the primary hard disk figure had increased from 7.1 to 7.3, which is good considering the fact that my original OCZ Vertex is now an old  technology which has been set to End-Of-Life by OCZ. The system certainly felt snappier, but this is highly subjective as I had not run before and after benchmarks – the goal of the whole excercise was reliability rather than speed.

No Comments »

July 29th, 2010
3:51 pm
Configuring SSDs for use under Windows XP

Posted under Windows XP
Tags , , ,

Update 7/10/2010

I had some further issues when trying to realign the boot partition of an OCZ Vertex 30GB SSD on an Intel D510 dual core atom ‘always on’ silent pc running Windows XP Pro.
I tried the technique used before below, using diskpar to create the partition and then using Acronis True Image 2010 to restore first the NTFS partition, then restoring the MBR and track 0 as a second subsequent operation. In order run diskpar standalone, I created a bootable CD containing diskpar using Bart PE, as I found that booting a Windows XP CD into recovery mode does not give you full command prompt capabilities – you cannot run an arbitrary .EXE utility at all (a real surprise to learn) – you can only use the commands listed. All this was done as below (see here) so as to force Acronis to re-use the partition created by diskpar. Unfortunately allthough the process went smoothly the resulting system would not boot, citing NTLDR/boot loader problems.

I then upgraded to Acronis True Image Home 2011 and also Acronis Disk Director 11, as these were both supposed to be SSD friendly and handle the alignment correctly. I deleted the partition and restored the original backup with the incorrect alignment, allowing Acronis to create the partition itself, and the system booted fine as before. I then used Disk Director to slightly shrink the partition to ensure that there was space to allow it to realign – there should have been a few MB on the end anyway, but I shrank it by 100MB to be really sure.

I then did a full standalone backup of the system disk with the shrunken partition. I found that just restoring that backup (shrunken but with the wrong alignment) with True Image 2011 was not enough – the incorrect alignment was still present on the SSD, i.e. it appeared that True Image always gives priority to the partition details in the backup. In hindsight it may have been possible to override the partition settings during the restore to cause Acronis to fix the alignment by using ‘new’ partition settings but I did not try – if so, this might have fixed the alignment problem in one go.

However, Disk Director 11 was able to delete and then recreate the partition correctly, i.e. when it created a new partition on the SSD it automatically used the correct alignment (1048576 bytes or 1MB), as confirmed afterwards by diskpar. I created a partition to fill the disk, as I knew that True Image would happily restore the slightly smaller shrunken one to a larger one. I then used the same technique as above with True Image Home 2011, i.e. restore the NTFS partition first without the MBR and track 0, then restore MBR and track 0 as a second operation after the restore.

This time, it all worked fine and I ended up with a bootable system with the correct partition alignment. I’m not sure what the issue was – perhaps the shrinking first fixed it. I do know that this technique has worked fine for me previously as below, when I backed up a 2.5" laptop hard drive via Acronis True Image, created an aligned partition on a new SSD with diskpar, and then restored the backup to the SSD with the same trick.

The resulting lessons learned seem to be as follows:-

  1. Use Disk Director 11 with SSDs, alignment will be correct, and you can easily do it standalone by creating a Disk Director boot CD.
  2. Using True Image 2011 is also recommended – it is stated to be SSD friendly and is better all around.
  3. However, care is needed when restoring an SSD backup with the wrong alignment, as by default even True Image 2011 keeps the wrong alignment. Either the technique above is needed or it may be possible to get Acronis to use ‘new’ partition settings to override the ones in the backup, in which case the restore can all be done in a single step.
  4. to be safe, when correcting wrong SSD alignment, shrink partition first by say a few 10s of MB to be sure (I used 100MB) to ensure there is no funny truncation when it is restored and realigned.

I have not done any performance comparisons before and after the realignment, but have confirmed that the alignment is now correct. Whilst I have seen posts on the internet that suggest lower alignment values than 1MB, both Windows 7 when it installs to an SSD, and Disk Director 11 use 1MB (1048576 bytes), so I am sticking with this value.

 

Original Post

Partition alignment is important for SSD performance to avoid unnecessary read/write cycles. Windows 7 appears to handle this but Windows XP does not. The partition alignment must be set manually when creating it (with diskpar or diskpart – diskpar seems to be preferred as it displays the partition offset in bytes so that the resulting offset can be accurately seen, even though diskpart is newer and has more features)

When restoring or cloning disks with Acronis True Image Home 2010, the original partition alignment is kept providing the operation does not recreate the partitions. See the Acronis forums here for details.

The OCZ forums have some articles on how to create correctly aligned partitions here and here.

Another step by step guide to cloning to an SSD with Acronis may be found here. When doing this, do not (as I did) forget the step which says to set the restore partition as primary and active in Acronis! In my case, Acronis made the wrong partition active so the SSD would not boot. It was simple enough to change – boot a system which can see the disk, then use disk management, right click the correct boot partition and select set as active. It is not necessary to repartition the SSD and re-restore the Acronis backup.

A good balanced article about optimising Windows XP for SSD use is here. There is a lot of misinformation around for example about the performance effects of swap files, which is based on misunderstandings about windows swap file usage, and also based on older SSDs with short service lives. The more informed wisdom appears to say that you should not disable the swap file as it will not make a significant difference.

No Comments »