- Status
Try ...
sf.exe -f 1aa17aqm.d38 -s -x -b -v -a 20 -i HD751LJ
The above command pauses for 20 seconds after the update is complete. You will need to power cycle the drive for the update to take effect.
BTW, I wonder if the "dangerous" warning for hdparm is still valid for drives whose file systems are not visible, and therfore not mountable.
Is the model number now HD751LJ or HD753LJ? I see very few Google hits for the HD751LJ.
sf.exe -f 1aa17aqm.d38 -s -x -b -v -a 20 -i HD751LJ
The above command pauses for 20 seconds after the update is complete. You will need to power cycle the drive for the update to take effect.
BTW, I wonder if the "dangerous" warning for hdparm is still valid for drives whose file systems are not visible, and therfore not mountable.
Is the model number now HD751LJ or HD753LJ? I see very few Google hits for the HD751LJ.
i tried to update to the F3 firmware, and it rejected it due to the drive name being different...
what does the -i part of the line below do???
sf.exe -f 1aa17aqm.d38 -s -x -b -v -a 20 -i HD751LJ
should i replace the HD model with HD103UJ ???
what does the -i part of the line below do???
sf.exe -f 1aa17aqm.d38 -s -x -b -v -a 20 -i HD751LJ
should i replace the HD model with HD103UJ ???
AISI, there are two possible reasons for the original failure of Dell's update.
(1) Dell's OEM firmware is incompatible with Samsung's standard retail models, or
(2) Dell's updater applied the incorrect firmware image to your retail model.
We are hoping for (2), otherwise our efforts will be pointless.
Are you using my most recent upload for F1_FW_17.EST? I omitted to remove the zeros at the end of the file in my first upload, but I amended this a few hours later.
It appears that the drive identifies itself as a HD753LJ after Dell's F1 update, and subsequently as an HD751LJ after the retail F3 update. Since the 750GB F3 model is an HD754JJ, and since the first "J" denotes 4 heads rather than 6, ISTM that the drive determines its identity, not from the firmware code, but from some other code module, possibly in the serial flash memory chip on the PCB, or elsewhere in the reserved System Area on the platters.
BTW, here is the embedded documentation that I extracted from SeaFlash (sf.exe) after unpacking it with UPX:
http://www.users.on.net/~fzabkar/sf_usage.txt
http://www.users.on.net/~fzabkar/sf.exe
http://www.users.on.net/~fzabkar/sf.upx
Seagate's updater uses either of two methods.
(1) the model number, family, and firmware image are specified explicitly ...
sf -m BRINKS -f 4HBXR1B.LOD -i ST3640323AS -s -x -b -v -a 10
(2) ... or the drive's model number and existing firmware are compared against an update matrix in a configuration file.
sf -m BRINKS -f -s -x -b -v -a 10 -h 4hcfgpre.txs
The update matrix is encoded using a simple substitution cipher, ie whenever character X occurs, it is replaced with character Y.
Here are two examples:
http://www.users.on.net/~fzabkar/BR-SD1B.TXT
http://www.users.on.net/~fzabkar/MS-SD1A.TXT
See the following thread for a more detailed explanation:
http://forum.hddguru.com/can-update-sd15-barracuda-7200-t16855.html
I suspect that Samsung's EST file is also encoded. The file doesn't compress, so at first thought it would appear to be packed in some way. However, I have examined the EST files for the retail F3EG and F4EG firmware and I notice that the first 40 bytes are identical. AIUI, this would be extremely unlikely for two packed files.
58 C1 0D 45 EE C2 70 D6 10 DB 49 63 15 AB 15 50 FA E5 42 5C 7D B1 88 41 AE 85 76 5A 9F EC 84 74 95 03 95 19 5B D9 CE A5
Instead I suspect that the file may be encrypted with a Solitaire cipher. I believe this would have the effect of randomising the data so that it is rendered incompressible. But that's only wild speculation on my part.
BTW, the F3 update was a quick fix to an urgent problem. Samsung advises that the update doesn't change the firmware version reported by the drive, which means that in your case the drive continues to report the Dell version (1AA01117).
(1) Dell's OEM firmware is incompatible with Samsung's standard retail models, or
(2) Dell's updater applied the incorrect firmware image to your retail model.
We are hoping for (2), otherwise our efforts will be pointless.
Are you using my most recent upload for F1_FW_17.EST? I omitted to remove the zeros at the end of the file in my first upload, but I amended this a few hours later.
It appears that the drive identifies itself as a HD753LJ after Dell's F1 update, and subsequently as an HD751LJ after the retail F3 update. Since the 750GB F3 model is an HD754JJ, and since the first "J" denotes 4 heads rather than 6, ISTM that the drive determines its identity, not from the firmware code, but from some other code module, possibly in the serial flash memory chip on the PCB, or elsewhere in the reserved System Area on the platters.
BTW, here is the embedded documentation that I extracted from SeaFlash (sf.exe) after unpacking it with UPX:
http://www.users.on.net/~fzabkar/sf_usage.txt
http://www.users.on.net/~fzabkar/sf.exe
http://www.users.on.net/~fzabkar/sf.upx
Seagate's updater uses either of two methods.
(1) the model number, family, and firmware image are specified explicitly ...
sf -m BRINKS -f 4HBXR1B.LOD -i ST3640323AS -s -x -b -v -a 10
(2) ... or the drive's model number and existing firmware are compared against an update matrix in a configuration file.
sf -m BRINKS -f -s -x -b -v -a 10 -h 4hcfgpre.txs
The update matrix is encoded using a simple substitution cipher, ie whenever character X occurs, it is replaced with character Y.
Here are two examples:
http://www.users.on.net/~fzabkar/BR-SD1B.TXT
http://www.users.on.net/~fzabkar/MS-SD1A.TXT
See the following thread for a more detailed explanation:
http://forum.hddguru.com/can-update-sd15-barracuda-7200-t16855.html
I suspect that Samsung's EST file is also encoded. The file doesn't compress, so at first thought it would appear to be packed in some way. However, I have examined the EST files for the retail F3EG and F4EG firmware and I notice that the first 40 bytes are identical. AIUI, this would be extremely unlikely for two packed files.
58 C1 0D 45 EE C2 70 D6 10 DB 49 63 15 AB 15 50 FA E5 42 5C 7D B1 88 41 AE 85 76 5A 9F EC 84 74 95 03 95 19 5B D9 CE A5
Instead I suspect that the file may be encrypted with a Solitaire cipher. I believe this would have the effect of randomising the data so that it is rendered incompressible. But that's only wild speculation on my part.
BTW, the F3 update was a quick fix to an urgent problem. Samsung advises that the update doesn't change the firmware version reported by the drive, which means that in your case the drive continues to report the Dell version (1AA01117).
FWIW, the following specifications would suggest that the last numeric character in the model number may reflect the cache size.
HD102UJ SAMSUNG Spinpoint F1 1TB 7200 RPM 16MB Cache SATA 3.0Gb/s 3.5"
HD103UJ SAMSUNG Spinpoint F1 1TB 7200 RPM 32MB Cache SATA 3.0Gb/s 3.5"
HD752LJ SAMSUNG Spinpoint F1 750GB 7200 RPM 16MB Cache SATA 3.0Gb/s 3.5"
HD753LJ SAMSUNG Spinpoint F1 750GB 7200 RPM 32MB Cache SATA 3.0Gb/s 3.5"
If so, then it would appear that Dell's firmware correctly identifies the cache size and the number of platters, whereas the F3 firmware gets the cache size wrong.
HD102UJ SAMSUNG Spinpoint F1 1TB 7200 RPM 16MB Cache SATA 3.0Gb/s 3.5"
HD103UJ SAMSUNG Spinpoint F1 1TB 7200 RPM 32MB Cache SATA 3.0Gb/s 3.5"
HD752LJ SAMSUNG Spinpoint F1 750GB 7200 RPM 16MB Cache SATA 3.0Gb/s 3.5"
HD753LJ SAMSUNG Spinpoint F1 750GB 7200 RPM 32MB Cache SATA 3.0Gb/s 3.5"
If so, then it would appear that Dell's firmware correctly identifies the cache size and the number of platters, whereas the F3 firmware gets the cache size wrong.
Been trying to force .D38 firmware using hdparm and when chosing --fwdownload-mode3 the hdd power/spin-down och then hdparm says "Done".
After a reboot the drive is still named HD751LJ
So I don't know if the firmware really was uploaded to the hdd or if the .D38 file is wrong....
After a reboot the drive is still named HD751LJ
So I don't know if the firmware really was uploaded to the hdd or if the .D38 file is wrong....
I don't have any more suggestions, just some questions and observations.
(1) Does your drive still report its original serial number?
(2) SeaFlash may not be able to handle a drive which reports a model number with a space in the name, eg "Samsung HD751LJ".
(3) Why did Samsung's tech support advise you to try SpinPoint F3 firmware on an F1 model? Surely this was madness? Does this incorrect (?) advice now impose an obligation upon Samsung to make it right?
(4) The fact that Samsung's F3EG updater claimed to have updated your firmware begs the question, how was it able to circumvent the model screening (???) in the embedded script file? That is, why did you not receive an error such as "no applicable model found"? Have I misinterpreted the function of the script file???
(5) If Samsung identified a problem with Dell's OEM firmware, and if this same problem also exists in retail firmware, then why have Samsung not issued a similar fix to the retail channel?
(1) Does your drive still report its original serial number?
(2) SeaFlash may not be able to handle a drive which reports a model number with a space in the name, eg "Samsung HD751LJ".
(3) Why did Samsung's tech support advise you to try SpinPoint F3 firmware on an F1 model? Surely this was madness? Does this incorrect (?) advice now impose an obligation upon Samsung to make it right?
(4) The fact that Samsung's F3EG updater claimed to have updated your firmware begs the question, how was it able to circumvent the model screening (???) in the embedded script file? That is, why did you not receive an error such as "no applicable model found"? Have I misinterpreted the function of the script file???
(5) If Samsung identified a problem with Dell's OEM firmware, and if this same problem also exists in retail firmware, then why have Samsung not issued a similar fix to the retail channel?
I wonder if you could investigate how the drive identifies itself to BIOS after you enable Power Up In Standby (PUIS). You could use HDAT2 or Hitachi's Feature Tool to do this.
Enabling PUIS will prevent the drive from spinning up until it receives an appropriate "SET FEATURES" ATA command. This means that it will be identifying itself using the information in the serial flash chip on the PCB rather than anything it finds on the platters. In this case I wonder if it will report its original model number. If not, then this would suggest that the flash memory contents were modified by the updater, or subsequently by the drive itself, after a power cycle.
You could then experiment by obtaining another HD103UJ drive, configuring it for PUIS, and then transferring its PUIS-enabled PCB to your original drive. Confirm that your drive now IDs as a HD103UJ in your BIOS. Don't send any command to spin it up, unless your are prepared to sacrifice your new board.
Your original drive will now have Dell firmware on the platters and the original code in flash memory. If you now spin up the drive, I suspect that it may rewrite its own flash data, rendering the board useless as before. Alternatively, it could be that the flash contents are only modified during the firmware update process, in which case the drive will continue to identify itself as a HD103UJ.
In short, it could be that a straight board swap *may* work. To lessen the risk of ruining your replacement board, you could protect its flash memory contents by desoldering the chip's Write Enable pin. That's a relatively simple procedure. Let me know if this approach is of interest to you.
Enabling PUIS will prevent the drive from spinning up until it receives an appropriate "SET FEATURES" ATA command. This means that it will be identifying itself using the information in the serial flash chip on the PCB rather than anything it finds on the platters. In this case I wonder if it will report its original model number. If not, then this would suggest that the flash memory contents were modified by the updater, or subsequently by the drive itself, after a power cycle.
You could then experiment by obtaining another HD103UJ drive, configuring it for PUIS, and then transferring its PUIS-enabled PCB to your original drive. Confirm that your drive now IDs as a HD103UJ in your BIOS. Don't send any command to spin it up, unless your are prepared to sacrifice your new board.
Your original drive will now have Dell firmware on the platters and the original code in flash memory. If you now spin up the drive, I suspect that it may rewrite its own flash data, rendering the board useless as before. Alternatively, it could be that the flash contents are only modified during the firmware update process, in which case the drive will continue to identify itself as a HD103UJ.
In short, it could be that a straight board swap *may* work. To lessen the risk of ruining your replacement board, you could protect its flash memory contents by desoldering the chip's Write Enable pin. That's a relatively simple procedure. Let me know if this approach is of interest to you.
One more idea.
How does your original board ID on your replacement drive, both when PUIS is enabled and disabled? If the drive rewrites the contents of flash memory, then perhaps your donor drive could transparently "repair" the flash contents on your original PCB. (???)
Once again, the above ideas are just wild speculation, so take care.
How does your original board ID on your replacement drive, both when PUIS is enabled and disabled? If the drive rewrites the contents of flash memory, then perhaps your donor drive could transparently "repair" the flash contents on your original PCB. (???)
Once again, the above ideas are just wild speculation, so take care.
FYI, I have been notified via a private message that applying the .D28 firmware file to a HD103UJ model (using Seagate's flasher) bricks the drive. :-(
AISI, this is to be expected because the HD103UJ has 3 platters, and the .D28 firmware is for drives with 2 platters.
AISI, this is to be expected because the HD103UJ has 3 platters, and the .D28 firmware is for drives with 2 platters.
See the following thread:
http://www.tomshardware.co.uk/forum/246721-14-slow-samsung-640gw-hd642jj
"alpinemobile" was able to fix his/her drive simply by replacing the PCB. It appears that in his/her case at least part of the firmware was written to the flash memory on the board.
http://www.tomshardware.co.uk/forum/246721-14-slow-samsung-640gw-hd642jj
"alpinemobile" was able to fix his/her drive simply by replacing the PCB. It appears that in his/her case at least part of the firmware was written to the flash memory on the board.
Hi,
some time ago i have had the same problem with the dell firmware and my samsung hd642jj. It was bricked and renamed to hd753lj.Even though dell's firmware patch functioned without any problem on my other identical hd642jj.
Due to fzabkars fantastic analytical work and his many useful hints and tips i could rescue my hd and the data.
Many thanks to fzabkar!)
So here are my successful steps:
1. I downloaded the firmware a17aqm.d11, d17, d28, d38 from fzabkar's urls. (but i only need to use the d28-version)
2. I only connected the bricked hd to a sata-port. (just for safety reasons)
3. Set bios to ide-compatible mode. (this was the only mode the bios recognized the hd)
4. boot linux from a live dvd (the boot process seems to hang when linux tries to read some sectors of the defect hd; be patient linux will go on booting after it gives up reading the sectors)
5. in linux i mounted a usb stick with the firmware on (in terminal: mount -t vfat /dev/sdb /media/sdb - for example)
6. in terminal: fdisk -l (this will give you the device-name of your hd)
7. in terminal: hdparm --fwdownload-mode7 --yes-i-know-what-am-i-doing --please-destroy-my-drive /media/sdb/A17AQM.D28 /dev/sda
(hints: must be fwdownload-mode7 for me, other modes don't work; /dev/sda was my device-name, maybe others for you; the yes-i-know-what-am-i-doing and please-destroy-my-drive are forced flags from hdparm so you have to write it down with the hdparm command)
The hdparm command finished in just a second and my hd was healed - except its name is now 753lj, doesn't matter could also be ottifant, it's just a name
Hope this can help someone ...
some time ago i have had the same problem with the dell firmware and my samsung hd642jj. It was bricked and renamed to hd753lj.Even though dell's firmware patch functioned without any problem on my other identical hd642jj.
Due to fzabkars fantastic analytical work and his many useful hints and tips i could rescue my hd and the data.
Many thanks to fzabkar!
) So here are my successful steps:
1. I downloaded the firmware a17aqm.d11, d17, d28, d38 from fzabkar's urls. (but i only need to use the d28-version)
2. I only connected the bricked hd to a sata-port. (just for safety reasons)
3. Set bios to ide-compatible mode. (this was the only mode the bios recognized the hd)
4. boot linux from a live dvd (the boot process seems to hang when linux tries to read some sectors of the defect hd; be patient linux will go on booting after it gives up reading the sectors)
5. in linux i mounted a usb stick with the firmware on (in terminal: mount -t vfat /dev/sdb /media/sdb - for example)
6. in terminal: fdisk -l (this will give you the device-name of your hd)
7. in terminal: hdparm --fwdownload-mode7 --yes-i-know-what-am-i-doing --please-destroy-my-drive /media/sdb/A17AQM.D28 /dev/sda
(hints: must be fwdownload-mode7 for me, other modes don't work; /dev/sda was my device-name, maybe others for you; the yes-i-know-what-am-i-doing and please-destroy-my-drive are forced flags from hdparm so you have to write it down with the hdparm command)
The hdparm command finished in just a second and my hd was healed - except its name is now 753lj, doesn't matter could also be ottifant, it's just a name
Hope this can help someone ...
Scott_D_Bowen
Honorable
- Nov 28, 2012
- 837
- 0
- 11,060
Price Cheaper
Honorable
- Jun 10, 2013
- 1
- 0
- 10,510
Back when i faced this issue with my HD103UJ i left it as a bricked HDD. Few months later i purchased the same drive and only recently decided to do a PCB sway again AND with the information @wrzl gave, thought i would put my BIOS into IDE MODE.. and the hard drive now detects as HD103UJ with the bios ending 113.
Now my question is, can i flash the drive with .D38 or will it totally change the model number rendering my working PCB dead? From what i recall flashing the broken drive (when it used to be detectable using SeaGate flasher),, My mistake was to use D28 and that was for a 2 platter drive. This sort of tells me that SeaGate flasher works.. and all i need to do is apply D38 !!??????????????
Now my question is, can i flash the drive with .D38 or will it totally change the model number rendering my working PCB dead? From what i recall flashing the broken drive (when it used to be detectable using SeaGate flasher),, My mistake was to use D28 and that was for a 2 platter drive. This sort of tells me that SeaGate flasher works.. and all i need to do is apply D38 !!??????????????
I've done more research on this problem and I've come to the conclusion that Dell's update rewrites the entire 256KB flash memory (aka "ROM) on the PCB, but does not touch the firmware modules in the System Area (SA) on the platters. This means that the solution should be as simple as locating a PCB with the original ROM code.
Here is my Analysis of Samsung's SpinPoint F3 firmware update:
http://malthus.zapto.org/viewtopic.php?t=679&p=1986#p1986
Here is the structure of the firmware image file:
http://malthus.zapto.org/viewtopic.php?t=679&p=1989#p1989
Notice that it has 3 components -- some loader code, a 256KB ROM image, plus an image of the MOVLY001 SA module. Therefore the SpinPoint F3 update rewrites the ROM code, plus it updates one of the main firmware modules in the SA.
Applying the same analysis to the Dell update, we find that each firmware image contains a loader plus a 256KB ROM image, but nothing else.
For example, the 1AA17AQM.D11 file is structured as follows:
0x00000 - 0x009FF -- LFRD or FLDR loader code
0x00A00 - 0x409FF -- 256KB ROM image
Here is my Analysis of Samsung's SpinPoint F3 firmware update:
http://malthus.zapto.org/viewtopic.php?t=679&p=1986#p1986
Here is the structure of the firmware image file:
http://malthus.zapto.org/viewtopic.php?t=679&p=1989#p1989
Notice that it has 3 components -- some loader code, a 256KB ROM image, plus an image of the MOVLY001 SA module. Therefore the SpinPoint F3 update rewrites the ROM code, plus it updates one of the main firmware modules in the SA.
Applying the same analysis to the Dell update, we find that each firmware image contains a loader plus a 256KB ROM image, but nothing else.
For example, the 1AA17AQM.D11 file is structured as follows:
0x00000 - 0x009FF -- LFRD or FLDR loader code
0x00A00 - 0x409FF -- 256KB ROM image
Nafis Fahim
Honorable
- Dec 3, 2013
- 3
- 0
- 10,510
- Status
TRENDING THREADS
-
News Windows 11 will reportedly display a watermark if your PC does not support AI requirements- Started by Admin
- Replies: 21
-
-
Discussion What's your favourite video game you've been playing?- Started by amdfangirl
- Replies: 3K
-
Facebook
Twitter
Instagram