I have used wdidle3 but the autopark persisted due to APM. I am currently running a script to set APM to 254 on every boot. Does anyone know if WD has any new firmware that allows us to permanently disable APM or leave it at 254?
I have read Nasty Intelli Park on WD Scorpio Blue 1T 2.5’’ but the latest WD Marvel is not able to extract data from my hard disk. Still working on that. And to those who were on that thread, were you able to patch the firmware? 
Thanks in advance.
beLIEve wrote:
…And to those who were on that thread, were you able to patch the firmware?
You do realize the thread you referred to was last active almost 20 months ago, right?
Yes. I’m hoping that 20 months later, someone manage to figure out how to fix this
May be so…but the chances of them still hanging out around here 20 months later…and looking at your thread is really small But good luck.
I’m still here.
I have done a little more detective work on the structure of MOD 02. If someone could read MOD 02 before and after making changes with wdidle3, then I may be able to identify the exact byte that needs to be edited on all ROYL models.
Thanks fzabkar. Will explore that. Can I know what application you’re using to extract out the data you gave? Any freeware? The latest WD Marvel Beta has English interface, FYI. I couldn’t even view SMART details with it, perhaps because I’m using AHCI. My problem is, my OS won’t boot up if I set AHCI to IDE. I’ve tried changing some other value apart from APM the other day, and after a power cycle, that value gets reset as well. I wonder if the firmware copies these from another location or simply reset them when it’s booting up. This will make things tougher.
The only freeware tools I know require IDE access. Try booting from a USB drive running FreeDOS, and then use NazYura’s tools tor retrieve MOD 02. Alternatively, if you can get MHDD to see your drive in IDE mode, then I can write a script for you to retrieve MOD 02 and others. To this end, you will need version 4.5 of MHDD, not 4.6.
Thanks fzabkar. I’ll try with the tools you mentioned and update you again.
I think I managed to grab MOD 02 with MHDD 4.5 with the script given by Nirvanowiec in http://forum.hddguru.com/viewtopic.php?f=1&t=8374&start=20
I did 4 tests. Noticed that 2 bytes were changed in each of the 3 tests. From http://www.salvationdata.com/blog/wp-content/uploads/2009/08/081909_0942_FixIdentifi5.png the byte at 0xF seems like the CRC
Nice work!
The 4 bytes at offsets 0x0C - 0x0F constitute a 32-bit little endian checksum. These bytes are chosen so that the sum of all the 32-bit little endian double-words is 0.
Offset 0x40F appears to hold the idle3 timer value. The units appear to correspond to 0.1 second increments. For example, a value of 0x50 (= 80 decimal) corresponds to 8.0 seconds.
0x00 Disable IDLE3
0x50 Enable IDLE3 at 8 seconds
0x5A Enable IDLE3 at 9 seconds
The first 0x30 bytes of MOD 02 constitute the module’s header.
Offset 0x30 is the beginning of a table containing 0x002F sections.
The first section begins at offset 0x00EE and has a size of 0x0019 bytes. The next section begins at 0x0107 and has a size of 0x0018 bytes, and so on.
Offset 0x62 points to the section that contains our idle3 timer byte. This section begins at 0x03F9 and has a size of 0x0067 bytes. The idle3 timer is located at offset 0x16 within this section.
00 01 98 3A 0F 0F 01
00000400 02 02 0A 01 01 0A 02 02 04 0A 00 FF FF 02 03 5A
00000410 01 1E 0A 60 08 04 40 0B 02 00 00 00 00 00 FF FF
00000420 10 00 00 00 00 03 0A 40 42 0F 00 E0 C8 10 00 C8
00000430 00 00 00 05 0A A0 0F A0 05 46 3C 02 00 05 05 B0
00000440 D0 10 00 00 00 C8 00 00 00 D0 07 00 00 0A 00 00
00000450 00 01 01 1E 64 00 10 00 00 60 27 3C 00 00 00 08
00000000 52 4F 59 4C 01 00 30 00 02 00 05 00 66 65 2B 5F
00000010 30 30 30 38 30 30 30 30 07 07 07 00 00 00 00 00
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030 2F 00 EE 00 19 00 07 01 18 00 1F 01 83 00 A2 01
00000040 45 00 FB 02 17 00 12 03 13 00 38 03 07 00 3F 03
00000050 11 00 50 03 4F 00 9F 03 17 00 B6 03 31 00 E7 03
00000060 12 00 F9 03 67 00 60 04 3B 00 9B 04 13 00 AE 04
Here is a full set of resources for another WD10JPVT drive:
If you extract the 02.rpm module, you will find the following:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 52 4F 59 4C 01 00 30 00 02 00 05 00 40 27 85 4D ROYL
00000010 30 30 30 38 30 30 30 30 07 07 07 00 00 00 00 00 00080000........
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030 29 00 D6 00 19 00 EF 00 18 00 07 01 6E 00 75 01
00000040 43 00 C4 02 14 00 D8 02 12 00 FC 02 06 00 02 03
00000050 11 00 13 03 2D 00 40 03 12 00 52 03 30 00 82 03
00000060 12 00 94 03 51 00 E5 03 3B 00 20 04 11 00 31 04
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000390 00 01 98 3A 0F 0F 01 02 02 0A 01 01
000003A0 0A 02 02 04 01 00 FF FF 02 03 50 01 1E 0A 80 08
000003B0 04 40 0B 02 00 00 00 00 00 FF FF 10 00 00 00 00
000003C0 01 0A 40 42 0F 00 E0 C8 10 00 00 00 00 00 05 0A
000003D0 A0 0F 05 05 B0 D0 10 00 90 01 00 00 D0 07 00 00
000003E0 00 00 00 00 02
In this case offset 0x62 is pointing to location 0x0394, and the size of the section is 0x0051 bytes. Offset 0x16 within this section has a value of 0x50. This corresponds to 8 seconds, ie the default.
Therefore ISTM that a similar procedure might apply to other ROYL models. To this end, you could examine the resources for other drives at the HDD Guru file area:
http://files.hddguru.com/download/PC-3000-UDMA%20Support/
As for the APM setting in HDAT2, I expect that this setting would be written to the drive’s RAM and would therefore be volatile. The firmware modules (MOD 02 and others) are written to the System Area on the platters, although some are stored in flash memory on the PCB.
If the value of IDLE3 is stored in Mod 02’s 0x40F, what are the chances of the default APM value of 0x60 stored in 0x459?
Update : I posted this before I saw your reply. Let me go through that and update again.
WD10JPVT-00A1YT0 : APM Level : 0080h ( http://bbs.kakaku.com/bbs/K0000274641/SortID=15451303/)
WD10JPVT-22A1YT0 : APM Level : 0060h ( http://hardforum.com/archive/index.php/t-1766137.html)
WD10JPVT-75A1YT0 : APM Level : 128 (=0080h http://computer-pc-alive.com/laptop-notebook-computer/dell_7720_notebook_hardware.htm)
I checked the 02.rpm in the WD10JPVT-75A1YT0 link you gave, too many 0x80. Might take a while longer to figure out, or I might not figure out at all in the end. Those that autopark are probably on 0x60.
Thanks for all your help, efforts, and time, Franc.
Update : Found a potential match at 0x413.
0x40b : FFFF020350011E0A600804400B02 (WD10JPVX-22JC3T0)
0x3a6 : FFFF020350011E0A800804400B02 (WD10JPVT-75A1YT0)
Looks like that’s the one. Record Number 13 offset 0x1A. Other records are not matching at similar offset. Changing from 0x60 to 0x80 should revert to the non-autopark behavior in older 1TB drives and allow WdIdle3 to have full control.
I digged back some old WD 2.5" drives with Idle3 and APM but their Mod 02 records are far off with the ones for the 1TB. Since the 1TB drives are relatively new, I assume that their record offset should match as you pointed out for Idle3.
Let me consider carefully if I should try this out. I don’t want to brick my brand new HDD nor void my warranty.
You appear to be confusing the APM setting in the ATA standard with the idle3 timer in MOD 02. These are not the same thing.
Sorry, I think I may have misunderstood you. IIUC, you are saying that the default APM setting is stored within the same section of MOD 02 as the idle3 timer, at offset 0x1A. That does seem plausible.
Sorry once again.
No worries Franc. Couldn’t have reached this far without your guidance and the research you’ve done.
I need to source some out of warranty drives to test to be sure. My very old ones does not seem to use Record 13 and “No DRQ” with MHDD. I used NazYura’s to obtain Mod 02 on those drives.
Looks like writing the mod back to the disk will be a bigger challenge. Couldn’t find much examples. How do I do that? Is changing $b0 to $b1 good enough?
reset
waitnbsy
regs = $45 $0b $00 $44 $57 $a0 $80
waitnbsy
regs = $d6 $01 $be $4f $c2 $a0 $b1
waitnbsy
checkdrq
sectorsfrom = RD_02.bin
regs = $d5 $04 $bf $4f $c2 $a0 $b1
waitnbsy
checkdrq
sectorsto = MOD_02.bin
Thanks
There are several ways to approach this problem. One is to use HDDHackr to hack the drive. This produces an UNDO.BIN file that contains MOD 0D and MOD 02. You would then edit UNDO.BIN and use HDDHackr to undo the hack.
http://www.users.on.net/~fzabkar/HDD/HddHackr_analysis.html
What you are proposing to do with MHDD is incorrect. WD’s Vendor Specific Commands are tunnelled through to the drive via the ATA SMART Read Log and Write Log commands. Log 0xBE is used to send the VSC, while log 0xBF is used for transferring the data.
The RD_02.bin contains the VSC for reading MOD 02. Instead we need to create a new file, say WRT_02.bin, which contains the VSC for writing MOD 02. It consists of the command data padded with zeros. We then follow this with a SMART Write Log command using your edited MOD_02.bin. In MHDD you would use the “sectorsfrom” command rather than “sectorsto”.
Before doing anything you need to retrieve the full MOD 02 contents. At the moment you have retrieved only the first 4 sectors. Offset 0x0A contains the size of the modules in sectors, namely 5.
; VSC enable
reset
waitnbsy
regs = $45 $0b $00 $44 $57 $a0 $80
waitnbsy
; write module 02 to SA
regs = $d6 $01 $be $4f $c2 $a0 $b0
waitnbsy
checkdrq
sectorsfrom = wrt_02.bin
waitnbsy
regs = $d6 $05 $bf $4f $c2 $a0 $b0
waitnbsy
checkdrq
sectorsfrom = MOD_02.bin
; end of script
wrt_02.bin --> 0x0000 08 00 02 00 02 00 00 00 00 00 00 00 00 00 00 00
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 08 00 02 00 02 00 00 00 00 00 00 00 00 00 00 00
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
........
000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Note that the above script assumes that MOD 02 has a size of 5 sectors. This is not always true, so the script may produce bad results in those cases where the size is different.
BTW, I haven’t tried this script, so I would be very cautious. In fact I believe HDDHackr might be the safest approach.
When calculating the module’s checksum, you could use the following free tool:
| Forums | News and Announcements | Register | Help | Forum Guidelines |
Copyright © 2021 Western Digital Technologies, Inc. All rights
reserved.
|
Trademarks
|
Privacy
|
Community Terms of Service
|
Site Terms of Use
|
Copyright
|
Contact WD
|