HTS541010A7E630 (NEWEST MODEL)

[shahij]

Confusing Head Map Info:

h map.png (15.07 KiB) Viewed 30389 times

The HDD has no ID, ready in a sec

What would you say?

[data-medics]

Corrupted NVRAM perhaps???? Have you tried editing it to be something more typical like 00 01 02 03 ?

More likely I'd guess it's just not properly reading the headmap from the family given how new it is.

[fzabkar]

Can you upload the ROM/NVRAM? I can test the checksum for you.

[shahij]

Yes, I changed the HEAD Map like 01 02 03 04, still no id, it ids by utility (Unknown family)

Here is the attachment

HGST HTS541010A7E630-SE0OA4A0-S00000SSGBJLEF.rar

(136.44 KiB) Downloaded 995 times

[fzabkar]

The checksum is OK.

Code:

C:\>xorchksm -16 nv-ram.nvr

nv-ram.nvr: XOR16 checksum = 0x0000

This looks like the head map:

Code:

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

00000690                          00 01 02 03 0F 0F 0F 0F
000006A0  0F 0F

The software is expecting to find it here:

Code:

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

00000680              20 00 E8 03 E3 78 05 04 0A 00

[shahij]

So, the tool is not working properly to access the Head Map correctly.

[fzabkar]

So, the tool is not working properly to access the Head Map correctly.

That's right. You probably corrupted your NVRAM. Can we see what it looks like now?

[shahij]

No, I didn't corrupt the NVRAM. It came this way. I went to Edit NVRAM to see its status. And I see this invalid headmap and posted. I tested by inputting n saving 00 01 02 03 0F and so on to see hdd status. Found Same behaviour. And the values were inputted back to original. After I posted the nvram, its remained same so far. No furthere task is done

[fzabkar]

No, I didn't corrupt the NVRAM. It came this way. I went to Edit NVRAM to see its status. And I see this invalid headmap and posted. I tested by inputting n saving 00 01 02 03 0F and so on to see hdd status. Found Same behaviour. And the values were inputted back to original. After I posted the nvram, its remained same so far. No furthere task is done

You misunderstood me.

I was suggesting that the original ROM and NVRAM were OK and that you corrupted the NVRAM when you edited the wrong "head map" bytes.

[shahij]

Ok.got it.
I restored back the bytes to its original status (as attached nvram), and the original one shows like the op picture.
Now the hdd is in its original form it came.
So, if i m not wrong, according to your analysis, the tool is reading incorrectly this one. N in the original state the rom/nvr is ok.
What would u suggest?

[Kum Ruzvelt]

Try to plug only PCB or desolder NV-RAM and read on external programmer.
But I think it is head problem.

[fzabkar]

I have no idea what to do. All I'm suggesting is that perhaps your model has a slightly different structure for the NVRAM.

FWIW, here are the head map bytes from an HTS725050A7E630:

Code:

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

00000680              00 01 0F 0F 0F 0F 0F 0F 0F 0F

They appear to be at the same location where your tool expects to find them in your HTS541010A7E630 dump. Perhaps you have selected the wrong family?

[fzabkar]

HTS541010A9E680 head map

Code:

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

00000680              00 01 02 03 0F 0F 0F 0F 0F 0F

[egalasso]

Seems like it could be a power up in stand-by feature set.

[fzabkar]

Seems like it could be a power up in stand-by feature set.

The ROM contains the model number, so wouldn't the drive still ID with a limited set of Identify Device data?

HTS541010A7E630
APPLE HDD HTS541010A7E630

[egalasso]

Seems like it could be a power up in stand-by feature set.

The ROM contains the model number, so wouldn't the drive still ID with a limited set of Identify Device data?

HTS541010A7E630
APPLE HDD HTS541010A7E630

I don't remember ever getting a proper ID from a Hitachi with power up in standby.

[fzabkar]

The ATA standard specifies that a PUIS drive should respond to the Identify Device command with a partial ID, so you should still see something, even if most of the fields are blank. Of course it won't be a full ID because most of the data will be on the platters.

Anyway why isn't the tool reporting that PUIS is enabled, if that is indeed the case?

[fzabkar]

7.16.7.2 Word 0: General configuration

If the device is an ATA device, then bit 15 shall be cleared to zero.

If bit 2 of word 0 is set to one, then the content of the IDENTIFY DEVICE data is incomplete. This may occur if the device supports the Power-up in Standby feature set and required data is contained on the device media. The content of IDENTIFY DEVICE data word 0 and word 2 shall be valid.

Code:

7.16.7.4 Word 2: Specific configuration 

Word 2 shall be set as defined in table 47.

Table 47 - Specific configuration 

Value   Description 
---------------------------------------------------------------------------------
37C8h   Device requires SET FEATURES subcommand to spin-up after power-up and
        IDENTIFY DEVICE data is incomplete (see 4.14). 

738Ch   Device requires SET FEATURES subcommand to spin-up after power-up and
        IDENTIFY DEVICE data is complete (see 4.14). 

8C73h   Device does not require SET FEATURES subcommand to spin-up after power-up
        and IDENTIFY DEVICE data is incomplete (see 4.14). 

C837h   Device does not require SET FEATURES subcommand to spin-up after power-up
        and IDENTIFY DEVICE data is complete (see 4.14). 

All other values Reserved.

[jermy]

EDIT

Seems like it could be a power up in stand-by feature set.

Nop

Code:

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

00000DD0                 00

[fzabkar]

Hmm, I just noticed a pattern that looks like it might not be a concidence.

Code:

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

00000DC0                                      10 32 FE 76
00000DD0  98 BA DC 54

If you swap the nibbles in each byte, and rearrange the byte order, you get ...

01 23 45 67 89 AB CD EF

The same pattern appears in other NVRAMs.