HITACHI-ARM FIRMWARE RECOVERY.

[fzabkar]

HUS724040ALA640-MFAOA8G0

~~~~
I don't understand, who helped me create a LOD?

If you are asking for someone to create a loader for you, then you might like to try this tool:

http://www.hddoracle.com/viewtopic.php?f=59&t=2696&p=20039&hilit=hitachi+loader+tool#p20039

It's untested, so it may not work.

[iphdd]

The firmware uploaded above is the one click backup firmware of PC3K

I'm talking about generating and creating LDR

Not at Loader LDR

[saltwater]

Hi there!
It's a relative old post, but i need help too for creating loader.

The drive came with no ID, spins up, and some head movements puts itself DRDY, but no SA access.
I swap heads, the result is a same, no ID.
After i edited NvRAM from 03-02-01-00 to 02-02-01-00 then had ID, downloaded SA copy 1 and had LBA access with heads 1-2-3.
Now i'm stuck with this case, no matter how i change NvRam, the drive not initialising.
I have tried create loader by own (using SA copy 1) and upload to SeDiv, but the drive still not have ID. Maybe i f.cked up my loader, i think i don't understand right the srtucture of ARM loader file.
I wrote a letter here for drHDD, but as i seen he visited hddguru 3 months ago.
So please somebody help me create a loader to rewrite SA with SeDiv.
I have MRT too, but MRT is not have possibility for upload microcode to RAM.
We tried initialise drive with PC3K using copy 1 source and rewrite SA in my friend's lab, but no luck.
So i think my last hope left using hddguru community asking for help.
I uploaded SA copy here if it helps:

Modules.zip

(1 MiB) Downloaded 479 times

Thank you!

[pepe]

there are some common mistakes in this process, i can probably recover it but the question is wether that one missing surface is worth starting it over...

[saltwater]

Hi there.
@fzabkar tool won't work for you because you are missing modules on your dump/resource.
You USAG have reference to modules that are missing from your package/attachment :

loader.png

This was some years ago and i don't remember very well the procedure as well but i can hook a ARM Hitachi to my HRT in a moment to see if i refresh my mind over this ...

Hi!
Yes, i tried this tool too, with same result as yours.
Comparing the patient USAG module with another same donor drive USAG module and module package (module names/number) are a same.
fzakbar's tool is created for A7E ARM drives. It' not a miracle that tool is not handle CLA3 Hitachi drives.
Strange that PC3K, MRT, and Sediv can't create loader files using module source as theese tools can create loader for WD, Sea, etc....drives.

[saltwater]

Spildit, thank you for your time!
If i understand right, if we create a pcr file with PC3k, and i rename it to LOD extension will it be good for upload to RAM by Sediv?
I have a donor drive with same model number, and fw microcode.
Tried hot swap using this method (with no luck):
1.Donor in sleep mode, and uploaded modules to RAM wich contents are not a same with patient modules:
psht*
rdmt*
rpop*
seci*
altt*
zone*
srvp*
srvm*
chnm*
idnt*
smrt*
feat*
cnfg*
wwnm*
2.Upload patient NvRam to donor PCB (donor PCB is still in sleep mode)
3.Put donor PCB (with contents os patient modules in RAM and NvRAM) to patient drive
4.Wake patient drive with donor PCB
5....after some clicks the patient drive gets DRDY status, but i still can't read or write SA.

I don't understand why, because comparing the patient and donor drives USAG modules are same.

[pepe]

create a pcr file with PC3k, and i rename it to LOD extension will it be good for upload to RAM by Sediv

surely not, since pcr is not a loader format, it is for database export/import.
Perfectly no need for hotswap if you can upload loader...

[saltwater]

I have read all pages of this topic several times, and read hddoracle topic too, and other i found on internet! Now i'm ask here, because i'm stuck with this case, and hope somebody can help.

Tried initialize disk with PC3K using original modules, and the result: no SA access....

I created 4 types of loader by own, as i wrote above. Tried upload with Sediv, but no one worked.

Take look!

CLALDR.zip

(1 MiB) Downloaded 766 times

[fzabkar]

I'll have a look when I can. It's always the case with my tools that I need to modify them to account for different families as I become aware of them.

[fzabkar]

I believe I just need to limit the loader to these modules:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19

000001EE  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 53 41 47 30 30 30 5F  ..................USAG000_
00000208  5F 5F 00 00 00 00 00 00 55 53 41 47 00 00 04 00 00 F0 03 00 00 00 04 00 00 00  __......USAG.....ð........
00000222  00 00 00 00 00 00 00 00 52 41 4D 49 AA CD 08 00 00 F0 03 00 00 00 99 00 00 D0  ........RAMIªÍ...ð....™..Ð
0000023C  01 00 00 B0 00 00 00 00 52 41 4D 30 AA CC A1 00 00 F0 03 00 00 00 D0 02 00 10  ...°....RAM0ªÌ¡..ð....Ð...
00000256  84 00 00 A0 05 00 00 00 52 50 4F 50 CC 00 79 03 00 F0 03 00 00 00 02 00 F0 4B  „.. ....RPOPÌ.y..ð......ðK
00000270  08 00 A4 01 00 00 00 00 5A 4F 4E 45 CC 00 66 04 00 F0 03 00 00 00 62 00 00 12  ..¤.....ZONEÌ.f..ð....b...
0000028A  8E 00 00 C4 00 00 00 00 53 52 56 50 CC 00 75 03 00 F0 03 00 00 00 04 00 00 D6  Ž..Ä....SRVPÌ.u..ð.......Ö
000002A4  8E 00 10 00 00 00 00 00 53 52 56 4D CC 00 7B 03 00 F0 03 00 00 00 14 00 00 DE  Ž.......SRVMÌ.{..ð.......Þ
000002BE  8E 00 04 1F 00 00 00 00 43 48 4E 4D CC 00 C1 03 00 F0 03 00 00 00 A5 00 00 C8  Ž.......CHNMÌ.Á..ð....¥..È
000002D8  8C 00 00 43 01 00 00 00 49 44 4E 54 CC 00 73 03 00 F0 03 00 00 00 02 00 00 1A  Œ..C....IDNTÌ.s..ð........
000002F2  9C 00 40 02 00 00 00 00 43 4E 46 47 CC 00 71 03 00 F0 03 00 00 00 02 00 00 60  œ.@.....CNFGÌ.q..ð.......`
0000030C  8C 00 A4 01 00 00 00 00 57 57 4E 4D CC 00 C8 04 00 F0 03 00 00 00 01 00 00 1D  Œ.¤.....WWNMÌ.È..ð........
00000326  9C 00 36 00 00 00 00 00 53 50 54 52 00 00 00 12 00 F0 03 00 00 00 02 00 00 00  œ.6.....SPTR.....ð........
00000340  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ..........................

[pepe]

the loaders are malformed imo. Drive should abort them, wondering how Spildit managed to start his drive using those.

pepe

[fzabkar]

Tried initialize disk with PC3K using original modules, and the result: no SA access....

I created 4 types of loader by own, as i wrote above.

CLALDR.zip

Were these loaders created by PC3K? Or did you use a PC3K loader from another drive and then patch it?

[fzabkar]

the loaders are malformed imo. Drive should abort them, wondering how Spildit managed to start his drive using those.

I was expecting my loader to fail because I don't understand the structure of the DLD0 header.

[fzabkar]

0x5FC is the size of loader file in sectors. I don't know what 0xFB3A6788 is, but I suspect it could be a checksum/CRC. My tool leaves this as 0, so that's one reason I expected my loader to be rejected.

@saltwater's PC3K patched loader (?) does not correctly compute the loader's size, so that's another reason it would fail.

This is the relevant section of my code:

Code:

' Update header sector and write it to loader file

hdrbuff0[ 0 ] = &H30444C44                      ' DLD0 signature

' Determine sizes of modules

nousagsiz = 0                                   ' total size of all SA modules excluding USAG (in sectors)

For i = 1 To 16
   nousagsiz += modsiz( i )
Next i

ldrsiz = nousagsiz + modsiz( 0 ) + 1            ' total size of loader (in sectors)

hdrbuff0[ 4 ] = ldrsiz                          ' size of loader (in sectors)
' hdrbuff0[ 5 ] = ????
hdrbuff0[ 8 ] = &H2Bul                          '  unknown
hdrbuff0[ 9 ] = &H01ul                          ' USAG at sector #1 in loader
hdrbuff0[ &HA ] = nousagsiz                     ' size of all modules except USAG (in sectors)
hdrbuff0[ &H10 ] = &HE0ul                       '  unknown
hdrbuff0[ &H18 ] = &HFFul                       '  unknown

' Write header sector

Put #lf, , hdrbuff0[ 0 ], &H80

Last edited by fzabkar on January 26th, 2023, 15:57, edited 1 time in total.

[saltwater]

0x5FC is the size of loader file in sectors. I don't know what 0xFB3A6788 is, but I suspect it could be a checksum/CRC. My tool leaves this as 0, so that's one reason I expected my loader to be rejected.

@saltwater's PC3K patched loader (?) does not correctly compute the loader's size, so that's another reason it would fail.

This is the relevant section of my code:

Code:

' Update header sector and write it to loader file

hdrbuff0[ 0 ] = &H30444C44                      ' DLD0 signature

' Determine sizes of modules

nousagsiz = 0                                   ' total size of all SA modules excluding USAG (in sectors)



For i = 1 To 16
   nousagsiz += modsiz( i )
Next i

ldrsiz = nousagsiz + modsiz( 0 ) + 1            ' total size of loader (in sectors)

hdrbuff0[ 4 ] = ldrsiz                          ' size of loader (in sectors)
' hdrbuff0[ 5 ] = ????
hdrbuff0[ 8 ] = &H2Bul                          '  unknown
hdrbuff0[ 9 ] = &H01ul                          ' USAG at sector #1 in loader
hdrbuff0[ &HA ] = nousagsiz                     ' size of all modules except USAG (in sectors)
hdrbuff0[ &H10 ] = &HE0ul                       '  unknown
hdrbuff0[ &H18 ] = &HFFul                       '  unknown

' Write header sector

Put #lf, , hdrbuff0[ 0 ], &H80

Hello Frank, nice to see you.
My loaders created by own using modules from copy 1, but sadly they not worked.
The drive only init itself (after maybe 20 seconds) when i set head map in NvRam from 03-02-01-00 to 02-02-01-00.
When it's initialised itself, i have set NvRAM back to 03-02-01-00, and tried write back modules to copy 0. I think this leads the drive to mess, and that was my fault i think.
With PC3K with my friend we tried init the drive using saved backup modules, but the SA were still not writable.

[pepe]

Honestly ... maybe you should outsources to @Pepe ...

maybe... but i expect the SA to be badly corrupted, so i would probably need the mods backed up initially, i hope there's a sufficient set of them...

pepe

[fzabkar]

I don't know what 0xFB3A6788 is, but I suspect it could be a checksum/CRC. My tool leaves this as 0, so that's one reason I expected my loader to be rejected.

It's a simple little-endian 32-bit checksum over all the dwords. I was looking at a very early version of my code. My latest version (ie the one that Spildit used) computes this correctly.

[fzabkar]

I created 4 types of loader by own, as i wrote above. Tried upload with Sediv, but no one worked.

Try these headers.

loader2.bin

Code:

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

00000000  44 4C 44 30 00 00 00 00 00 00 00 00 00 00 00 00  DLD0............
00000010  96 04 00 00 FD 15 13 03 00 00 00 00 00 00 00 00
00000020  2B 00 00 00 01 00 00 00 91 04 00 00 00 00 00 00
00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000040  E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000050  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000060  FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

loader3.bin

Code:

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

00000000  44 4C 44 30 00 00 00 00 00 00 00 00 00 00 00 00  DLD0............
00000010  C8 04 00 00 B8 F8 0B 94 00 00 00 00 00 00 00 00
00000020  2B 00 00 00 01 00 00 00 C3 04 00 00 00 00 00 00
00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000040  E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000050  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000060  FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

[saltwater]

Hi fzakbar!

I tried your updated loader, but they not worked

I also tried it with healthy drive with same fw version, but it's not worked too.

[fzabkar]

Firmware updates often include loaders, so that might help to understand their structure.