This is a issue i never faced and also ace support can't answer ...

ST2000DM001 1CH164-510 fw cc27 , when i modify head map in rom , than the drive do not spin anymore.

than i took another donor - same model same date same fw - and same issue - once i modify head map in rom, ddrive do not spin.

Could you upload the before-and-after ROM images?

_________________
A backup a day keeps DR away.

here it is

And terminal output.

_________________
If you can keep your head when all about you are losing theirs, you probably don't fully understand the situation. ... Mr Kipling

https://www.mjm.co.uk/

are you CALC CRC in SAP Block After Modification Done ?
if So i think Head Stuck . not other issue
i face such Error in DM and VM Series During My intial Research For Cut head in These Familes and new F3 Structure
So better be sure that you calc CRC and head not Stuck on platter

_________________
http://www.hpwlab.com

It looks correct to me.

_________________
A backup a day keeps DR away.

The original ROM consists of 2 identical halves, 0 - 0x7FFFF and 0x80000 - 0xFFFFF. PC3K has confined its edits to the first half. Would it make any difference if these changes were repeated in the second half of the ROM?

I don't understand the reason, but the "RAM load point" (?) has been changed. The header checksum is 0x0000 in both the original and modified ROM.

The other thing I don't understand is the "active flag". AIUI, this flag should differ in each half of the ROM, with the largest value taking boot precedence. However, in both the original and modified ROMs, these flags are the same (0x00) in each half.


The head map has been changed from "00 10 20 30" to "10 10 10 10" in the first copy of the SAP (0x70000 - 0x74FFFF), but not in the second.


The 16-bit CRC for the SAP segment has been recalculated so that the checksum is 0x0000. However, there is a lonely word (0xA4AB) just prior to the CRC. Is this a second checksum, possibly calculated over the SAP contents (0x70008 - 0x74FFF7)? If so, could this be the problem?

_________________
A backup a day keeps DR away.

i detail better:

1) the drive spin up normally with original head map

2) any kind of modification in rom in patient but also in DONOR (same model,fw,date,P/N) make them NOT SPIN
and terminal like this:
"Boot 0x40M"

3) there is no calc of CRC in SAP pop-up , i think the CRC it is auto calculated from utility.

AISI, the SAP segment consists of two parts, each part with its own 16-bit checksum (?). There is a 16-bit CRC at the very end, making for 3 checksums in total.

8-byte header for SAP part #1


0x1C00 data bytes for SAP part #1, including 16-bit checksum at end


8-byte header for SAP part #2


0x33E8 data bytes for SAP part #2, including 16-bit checksum at end


8-byte CRC-16


If I sum the 16-bit data words of SAP part #1, I get 0x0000. However, if I do the same for SAP part #2, I get a non-zero result. This is for the original SAP.

I don't know why the second checksum doesn't add up, but ISTM that the no-spin problem might be solved by recalculating the part #1 checksum at offset 0x71C06, and then recalculating the 16-bit CRC for the entire SAP segment.

_________________
A backup a day keeps DR away.

if you can make an image corrected i can try in real and give feedback

I would try changing the checksum word from 0x997C to 0xF97C:

00071C00 00 00 00 00 00 00 7C F9 80 A0 CF 00 00 20 00 40

Then recalculate the overall SAP CRC, if necessary.

_________________
A backup a day keeps DR away.

i have tryed another donor - same FW (CC27) and same issue.
i think it is a fw incompatibility and ace didn't even know about it..

ok - case solved
used at the end grenada utility instead of F3 general utility and the crc is correct auto and it works.
hope can help other people

very good fzabkar to notice the crc issue!

+1 ,
No One Can Beat Frank in ROM Analysis .Also Frank That Seagate Case You Once Helped Me Worked But Then It Had Further Firmware Issues And i Returned It ,Too Much Firmware Tempering Was Done In That Drive .

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

+1 You need to select proper family. Else ROM mod does not work properly. Even i have struggled ones with same issue

Got a similar problem on a Bacall drive.
After changing headmap, it stopped spinning.
Ace team checked it and told me that it's a specific ROM situation and still no solution...

_________________
http://www.pclab.com.pt facebook.com/PCLAB.A.T
ACELab partner

Well,
Are you guys aware that even the common f3 utility should function properly .I recently encountered a situation that acelab ver 6.3.16 was reading 512kb roms as 1024k .To this acelab points to me in their forums that in the common utility its fixed these days to 1024 size and if i need tool to autoetect it i should set to 0x0000000 ,This is Wrong totally ,It should auto detect the rom to proper size and the if the user wants he should be able to select a size .Very wrong approach ,What sense does it make that a function is working in specific utility and not in common utility .We should all email acelab and tell them that they should fix this in the common utility

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

+1 just select the right family or set auto or specific size in F3 common.

_________________
Digitalsupport Data Recovery
https://digitalsupport.dk

Well,
Utility should be able to figure this out ,Even lousy softwares do ,this is PC 3000 we are talking about

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

That's what they told positivebit, but they were wrong. Perhaps you should upload your before-and-after ROM images and let others examine them.

_________________
A backup a day keeps DR away.