Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Hi
I have Toshiba MK5061GSYN hard disk , I could read all CP normally without any error.
Crucial P list & list are perfectly fine. Only CP BB ,BD & F0 are having errors.
Disk give ID gets initialized normally but gives read errors randomly ( UNC). Reading through utility also does not makes much improvement.
disk is very slow as well.
Is there any co relation between BB, BD & FO CP with this ? There is no importance mark .
Unlike other hard disks there are nodules and little can be done. I think CP's are stored on PCB .
What could be the reason and what should I do.
While selecting reading through utility I have not selected G-list damage option.
Experts in Toshiba pls. help.
Thank you

Attachments

higgsboson wrote:While selecting reading through utility I have not selected G-list damage option.

Try PBA access (solve G-list damage

FWIW, in a thread at the HDD Oracle I examined the firmware resources for an MKxxxxGAS drive and found that there were several checksum algorithms in use. For example, some modules had an 8-bit checksum while others used XOR8 or XOR16. Perhaps that is the reason that your three modules appear to read OK but fail the checksum test?

Also FWIW, the 0xBB CP ("SH") occurs in both the ROM and SA in the MKxxxxGAS while CP 0xBD ("ZF") appears to be resident in ROM.

If you upload your drive's firmware resources (ROM, SA modules, tracks) I could examine those suspect CPs for you.

BTW, ISTM that your G-list has 211 (= 0xD3) defects.

Hi fzabkar & jermy

Thanks a tom for all the help. thanks fzabkar for giving valuable knowledge of Toshiba architecture which will be useful for all members. Using G-list option in utility is not making much improvement.
I am attaching all service area components except SA tracks which I cant read.
Pls. let me know where exact defect is and what should I do.
Thank you.

Attachments

TOSHIBA MK5061GSYN-MH000C8-318ED0Y9B.rar: (432.04 KiB) Downloaded 1046 times

Most likely a heads problem.

labtech wrote:Most likely a heads problem.

+1, build HM and try to read with each head individual

The ROM has a table of CPs at offset 0x247A8. For each CP, this table defines its ID, mnemonic, size in bytes (in ROM and SA), and relative address in ROM.

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 000247A0 AA 54 4F 00 F8 BF 06 80 ªTO.ø¿.€ 000247B0 A0 03 00 04 90 03 01 00 34 52 43 00 98 C3 06 80 .......4RC.˜Ã.€ 000247C0 60 00 80 00 5A 00 01 00 33 57 43 00 F8 C3 06 80 `.€.Z...3WC.øÃ.€ 000247D0 B0 00 B0 00 AE 00 01 00 99 4D 4F 00 A8 C4 06 80 °.°.®...™MO.¨Ä.€ 000247E0 10 00 00 00 00 00 00 00 44 53 47 00 B8 C4 06 80 ........DSG.¸Ä.€ 000247F0 30 00 30 00 2E 00 01 00 92 43 4F 00 E8 C4 06 80 0.0.....’CO.èÄ.€ 00024800 10 00 10 00 0C 00 01 00 C1 47 4F 00 F8 C4 06 80 ........ÁGO.øÄ.€ 00024810 10 00 10 00 02 00 01 00 95 48 54 00 08 C5 06 80 ........•HT..Å.€ 00024820 10 00 10 00 0C 00 01 00 55 4D 4E 00 18 C5 06 80 ........UMN..Å.€ 00024830 C0 00 40 00 00 00 01 00 56 4D 4E 00 18 C5 06 80 À.@.....VMN..Å.€ 00024840 C0 00 C0 00 92 00 01 00 66 46 42 00 D8 C5 06 80 À.À.’...fFB.ØÅ.€ 00024850 10 00 00 00 00 00 00 00 67 46 42 00 D8 C5 06 80 ........gFB.ØÅ.€ 00024860 10 00 00 00 00 00 00 00 77 53 53 00 E8 C5 06 80 ........wSS.èÅ.€ 00024870 10 00 00 00 00 00 00 00 88 55 44 00 F8 C5 06 80 ........ˆUD.øÅ.€ 00024880 10 00 00 00 00 00 00 00 89 53 4C 00 08 C6 06 80 ........‰SL..Æ.€ 00024890 10 00 00 00 00 00 00 00 BB 53 48 00 18 C6 06 80 ........»SH..Æ.€ 000248A0 00 00 00 2E 00 00 01 00 98 53 4F 00 28 F2 06 80 ........˜SO.(ò.€ 000248B0 20 00 20 00 0C 00 01 00 9A 53 4E 00 48 F2 06 80 . .....šSN.Hò.€ 000248C0 40 00 40 00 3D 00 01 00 9B 57 4F 00 88 F2 06 80 @.@.=...›WO.ˆò.€ 000248D0 F0 00 F0 00 E4 00 01 00 9C 48 47 00 78 F3 06 80 ð.ð.ä...œHG.xó.€ 000248E0 10 00 10 00 06 00 01 00 AE 48 43 00 88 F3 06 80 ........®HC.ˆó.€ 000248F0 10 00 10 00 03 00 01 00 A2 53 56 00 D8 F3 06 80 ........¢SV.Øó.€ 00024900 80 00 80 00 78 00 01 00 A7 53 45 00 58 F4 06 80 €.€.x...§SE.Xô.€ 00024910 50 01 50 01 40 01 01 00 A8 4B 54 00 A8 F5 06 80 P.P.@...¨KT.¨õ.€ 00024920 10 00 10 00 0C 00 01 00 A9 42 57 00 B8 F5 06 80 ........©BW.¸õ.€ 00024930 40 04 40 04 38 04 01 00 B1 57 4E 00 F8 F9 06 80 @.@.8...±WN.øù.€ 00024940 20 00 20 00 10 00 01 00 AF 44 48 00 38 FA 06 80 . .....¯DH.8ú.€ 00024950 A0 03 A0 03 90 03 01 00 F5 44 45 00 A8 AA 07 80 . .....õDE.¨ª.€ 00024960 50 0E 50 0E 46 0E 01 00 B3 46 54 00 D8 FD 06 80 P.P.F...³FT.Øý.€ 00024970 10 00 10 00 06 00 01 00 C4 44 4C 00 F8 FD 06 80 ........ÄDL.øý.€ 00024980 80 01 80 01 7E 01 01 00 C5 56 43 00 78 FF 06 80 €.€.~...ÅVC.xÿ.€ 00024990 80 00 80 00 7E 00 01 00 C6 56 47 00 F8 FF 06 80 €.€.~...ÆVG.øÿ.€ 000249A0 80 00 80 00 7E 00 01 00 C7 50 4F 00 78 00 07 80 €.€.~...ÇPO.x..€ 000249B0 80 00 80 00 7E 00 01 00 C8 48 4D 00 F8 00 07 80 €.€.~...ÈHM.ø..€ 000249C0 30 00 30 00 2E 00 01 00 C9 4F 56 00 28 01 07 80 0.0.....ÉOV.(..€ 000249D0 B0 00 B0 00 AE 00 01 00 CB 44 50 00 D8 01 07 80 °.°.®...ËDP.Ø..€ 000249E0 10 00 10 00 0E 00 01 00 A5 52 5A 00 E8 01 07 80 ........¥RZ.è..€ 000249F0 A0 06 A0 06 9E 06 01 00 D0 41 55 00 88 08 07 80 . .ž...ÐAU.ˆ..€ 00024A00 30 00 30 00 2E 00 01 00 D1 46 52 00 B8 08 07 80 0.0.....ÑFR.¸..€ 00024A10 D0 00 D0 00 CE 00 01 00 B5 43 53 00 88 09 07 80 Ð.Ð.Î...µCS.ˆ..€ 00024A20 E0 01 E0 01 D4 01 01 00 B6 4D 53 00 68 0B 07 80 à.à.Ô...¶MS.h..€ 00024A30 E0 01 E0 01 D4 01 01 00 E0 43 41 00 48 0D 07 80 à.à.Ô...àCA.H..€ 00024A40 30 16 30 16 2E 16 01 00 E1 43 42 00 78 23 07 80 0.0.....áCB.x#.€ 00024A50 30 16 30 16 2E 16 01 00 E2 43 43 00 A8 39 07 80 0.0.....âCC.¨9.€ 00024A60 30 16 30 16 2E 16 01 00 E3 43 44 00 D8 4F 07 80 0.0.....ãCD.ØO.€ 00024A70 30 16 30 16 2E 16 01 00 CD 4C 4F 00 08 66 07 80 0.0.....ÍLO..f.€ 00024A80 20 00 20 00 1E 00 01 00 BD 5A 46 00 28 66 07 80 . .....½ZF.(f.€ 00024A90 70 0D 70 0D 68 0D 01 00 AD 44 4F 00 98 73 07 80 p.p.h...DO.˜s.€ 00024AA0 30 00 30 00 2E 00 01 00 D6 54 47 00 C8 73 07 80 0.0.....ÖTG.Ès.€ 00024AB0 10 00 10 00 0E 00 01 00 D7 4E 43 00 D8 73 07 80 ........×NC.Øs.€ 00024AC0 60 0A 60 0A 5E 0A 01 00 D8 56 50 00 38 7E 07 80 `.`.^...ØVP.8~.€ 00024AD0 10 0C 10 0C 0E 0C 01 00 D9 54 50 00 48 8A 07 80 ........ÙTP.HŠ.€ 00024AE0 40 00 40 00 3E 00 01 00 DA 4F 4D 00 88 8A 07 80 @.@.>...ÚOM.ˆŠ.€ 00024AF0 30 08 30 08 2E 08 01 00 DB 53 44 00 B8 92 07 80 0.0.....ÛSD.¸’.€ 00024B00 10 00 10 00 0E 00 01 00 D4 52 42 00 C8 92 07 80 ........ÔRB.È’.€ 00024B10 F0 00 F0 00 EE 00 01 00 F0 4E 54 00 B8 93 07 80 ð.ð.î...ðNT.¸“.€ 00024B20 D0 0F D0 0F CE 0F 01 00 F1 4C 53 00 88 A3 07 80 Ð.Ð.Î...ñLS.ˆ£.€ 00024B30 00 06 00 06 FE 05 01 00 F2 52 56 00 88 A9 07 80 ....þ...òRV.ˆ©.€ 00024B40 00 01 00 01 FE 00 01 00 F4 57 44 00 F8 B8 07 80 ....þ...ôWD.ø¸.€ 00024B50 30 00 30 00 2E 00 01 00 3B 00 00 00 53 48 00 00 0.0.....;...SH.. 00024B60 18 C6 06 80 20 00 20 00 18 00 00 00 53 5A 00 00 .Æ.€ . .....SZ.. 00024B70 38 C6 06 80 D0 00 D0 00 C6 00 00 00 48 50 00 00 8Æ.€Ð.Ð.Æ...HP.. 00024B80 08 C7 06 80 10 00 10 00 0C 00 00 00 5A 48 00 00 .Ç.€........ZH.. 00024B90 18 C7 06 80 10 2B 00 2D 08 2B 00 00 .Ç.€.+.-.+..

At the end of the table is a group of 4 modules -- SH, SZ, HP, and ZH. These same 4 modules are found in CP 0xBB in the SA.

Each module has an integrity byte at the end. That is, the integrity bytes for the SH, SZ, HP, and ZH modules are 0xC3, 0x09, 0x01 and 0x90, respectively.

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00070620 53 48 8E 7D 89 A2 D0 D0 00 00 00 00 00 00 00 00 SHŽ}‰¢ÐÐ........ 00070630 00 00 00 00 08 08 08 08 08 08 00 00 00 00 00 C3 00070640 53 5A 09 00 00 00 00 00 00 7F 00 00 00 09 00 00 SZ.............. 00070650 00 00 00 00 7F 00 00 00 09 00 00 00 00 00 00 7F ........ 00070700 00 00 00 00 7F 00 00 00 00 00 00 00 00 00 00 09 00070710 48 50 4C 07 32 07 31 07 56 07 80 07 80 07 00 01 HPL.2.1.V.€.€... 00070720 5A 48 50 1D 46 1D 07 FA 15 EA 7A BF 36 E9 0E FE ZHP.F..ú.êz¿6é.þ ........ 00073220 1E E5 5E 0A 4A 1B 05 EC 21 0C 00 00 00 00 00 90

The same section in the 0xBB CP looks like this:

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 53 48 8E 7D 89 A2 D0 D0 00 00 00 00 00 00 00 00 SHŽ}‰¢ÐÐ........ 00000010 00 00 00 00 08 08 08 08 08 08 00 00 00 00 00 00 00000020 53 5A 09 00 00 00 00 00 00 7F 00 00 00 09 00 00 SZ.............. 00000030 00 00 00 00 7F 00 00 00 09 00 00 00 00 00 00 7F ........ 000000E0 00 00 00 00 7F 00 00 00 00 00 00 00 00 00 00 00 000000F0 48 50 4C 07 32 07 31 07 56 07 80 07 80 07 00 00 HPL.2.1.V.€.€... 00000100 5A 48 50 1D 46 1D 07 FA 15 EA 7A BF 36 E9 0E FE ZHP.F..ú.êz¿6é.þ ........ 00002C00 1E E5 5E 0A 4A 1B 05 EC 21 0C 00 00 00 00 00 00 .å^.J..ì!....... ........ 00002DE0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00002DF0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 DA

I suspect that the ROM table defines the extents of each module as follows:

Code:: name size in ROM/SA -------------------- SH 20 / 20 SZ D0 / D0 HP 10 / 10 ZH 2B10 / 2D00

Therefore ISTM that the 0xBB CP should have a size of 0x2E00 bytes. However, the size in the resource dump is 0x3600. That is, the dump contains extra stuff at the end.

I executed various tests against the CP modules in the dump and found that all modules had XOR8 sums of 0x81 with the exception of the following:

I also performed simple 8-bit and 16-bit sums, but there was no pattern in the results.

To test my suspicions, I cut module 0xBB to a size of 0x2E00 bytes (as specified in the ROM table) and found that it now tested correctly.

BB_CUT.BIN: XOR8 checksum = 0x81
So ISTM that this suggests that the tool is incorrectly determining the extents of the 0xBB CP.

If we take a similar approach to CPs 0xBD ("ZF") and 0xF0 ("NT"), we find that their sizes in ROM are 0xD70 and 0xFD0, respectively. However, their sizes in the resource dumps are 0x400 and 0x200. This time it appears that the tool has underestimated the sizes of these CPs.

Here is CP 0xF0:

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 4E 54 00 00 00 00 00 00 00 00 00 00 00 00 00 00 NT.............. 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 the absence of any integrity byte.

In short it seems that there is a bug in the tool, or perhaps some corruption in the directory (?) which the tool is using to locate the modules.

Attachments

BB_cut.rar: (4.83 KiB) Downloaded 959 times

Wo great research work done by fzabkar

This is the most comprehensive information which is not published in any manual . Thank you so much fzabkar.

Even if you have Ferrari or Lamborghini & if you don't have driving skills then it will be of no use.

A big Thank you again

Yes agree higgsboson ,
only tool is not enough you need to master it and should have skills to operate it.
Fzabkar is having in depth knowledge of Toshiba architecture.
So is it some bug in pc3000 udma ? or something is additionally required to read cp ?

what could be the solution to recover data ?

Beautiful explanation by fzabkar
I was not even aware of checksum. It is not listed in manual too.
I am curious how the case is solved.

I think Service area is backed up by pc3000 udma.
Is this some kind of bug in pc3000 udma for this Toshiba model.
ace pls. explain

Diagnostics and checking of fzabkar was 100 % right.
I have selected ATA+COM as reading mode and copied all resouces again. This time reading cp tool more time. ( earlier it was quick)
I have checked checksum of all 3 error giving cp's. While one of the CP is having errors in checksum , other 2 are having good checksum.
I have taken backup of all original CPS .After that I opened these 3 faulty cps and recalculated checksum and saved them on hard disk.
But this has not improved sector access which is still slow with lots of errors.
what should I do now.
I am attaching rom and cp's read by ata+com mode.

Attachments

toshiba new.rar: (1.1 MiB) Downloaded 1152 times

initial.log: (8.92 KiB) Downloaded 1140 times

As mentioned before: it goes without saying there will be bad sectors, but it is a heads issue. Have you tested them individually, yet?

@higgsboson, from the very beginning I suspected that there was a bug in your tool, and I said as much. My subsequent analysis appears to have confirmed the bug. Specifically, your tool is unable to correctly determine the sizes of these 3 CPs -- BB is too big (27-sector dump versus 23 actual sectors) while F0 and BD are too small. That's why their checksums are incorrect. Now you appear to have "repaired" a 27-sector BB CP with a potentially buggy tool, and then written these 27 sectors back to the SA in place of a good 23-sector CP. I can only imagine what kind of corruption this would have caused.

In short, there was no need to "repair" any CP. The problem was in your tool, not in the CPs themselves. Your repairs have now introduced corruption into the SA. That said, I suspect that the drive may use the ROM versions of these same CPs rather than their SA versions, so the corruption may be of no consequence. In fact another forum member tells me that he transplanted those same 3 CPs from a donor to a patient, and still had access to the data. BTW, he confirms that CPs BD and F0 always show an error.

The ROM has a table of CPs at offset 0x247A8.

For example, here is the layout of CP 0xAA ("TO"):

Code:: ASCII ROM ROM SA ID name address size size size3 --------------------------------------------- AA 544F 00 F8BF06 80 A003 0004 9003 01 00 AA "TO" 6BFF8 3A0 400 390

Note that the ROM address in the table is actually a relative address. The actual physical address of the TO module in the ROM is 0x70000 (0x6BFF8 + 0x4008).

Here is the "SH" module (first component of CP 0xBB):

Code:: ASCII ROM ROM SA name address size size size3 --------------------------------------------- 5348 00 00 18C606 80 2000 2000 1800 00 00 "SH" 6C618 20 20 18

There are two count variables in the table:

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F vvvvvvvvvvv -- number of CPs in preceding table (0x3B) 00024B50 30 00 30 00 2E 00 01 00 3B 00 00 00 53 48 00 00 0.0.....;...SH.. 00024B60 18 C6 06 80 20 00 20 00 18 00 00 00 53 5A 00 00 .Æ.€ . .....SZ.. 00024B70 38 C6 06 80 D0 00 D0 00 C6 00 00 00 48 50 00 00 8Æ.€Ð.Ð.Æ...HP.. 00024B80 08 C7 06 80 10 00 10 00 0C 00 00 00 5A 48 00 00 .Ç.€........ZH.. 00024B90 18 C7 06 80 10 2B 00 2D 08 2B 00 00 04 00 00 00 .Ç.€.+.-.+...... number of CPs in preceding table (4) -- ^^^^^^^^^^^

The total number of modules is 0x3B + 0x4 (0x3B CPs in main table plus 4 BB components).

If you carve out each CP from the ROM, you will find that its XOR8 sum is 0x00 (as opposed to 0x81 for its SA version).

FYI, Spildit and I explored an example of Toshiba firmware with his HRT tool in the following thread:

TOSHIBA 2,5 MKxxxxGAS Firmware Research :
http://www.hddoracle.com/viewtopic.php?f=59&t=1254

HRT also has bugs. For example, it was unable to properly read the full ROM contents.

I note that there is no CHS information for the CPs in the ROM table, so I have no idea how PC3K locates the CPs in the SA. If I knew this, then perhaps I could understand why PC3K gets the sizes wrong. Other drives have a directory of SA modules (eg WD's MOD 01 or Samsung's FIT module), but I haven't managed to work out how Toshiba does it.

Thanks a lot fzabkar .
you have done great research on Toshiba architecture. Appreciate all reverse engineering.

what could be the solution in this case. if pc3000 udma cant read rom then there is no way other tools will be able to do it.
only those who have developed proprietory technique can do it
missing BlackST , he has some unique solutions for complex cases.

Hi Team
Update to case --- I have tried to write CP's from backup. I got error while writing BD cp.
continued to image - still drive is slow with errors.
As fzabkar has traced pc3000 udma is unable to read full rom and cp's .I don't have any other tool.
I am confused what to do now.

Attachments

AFAICS you still haven't answered the question whether the bad sectors are on any particular head?

Based on what is seen in the pic and the fact that you can access LBAs, the firmware is in decent shape. Maybe some issues with G-list. But the main problem is bad sectors and a suspect head.

@higgsboson. you misunderstood me. I stated that HRT was unable to read the full ROM (in the HDD Oracle thread). PC3K is OK in this respect. PC3K only has problems reading your 3 CPs, not the ROM. That's all. I only alluded to HRT to illustrate that each tool has its own bugs, and because it was the tool that Spildit used for our analysis.

Hi Sean labtech and fzabkar
Sorry I missed out head test part. Unfortunately utility is not having option to check heads similar to WD and Seagate,
Yes except these 3 cp's resy of the cps' are fine including G list and P list.
only way to head test is through DE. So far I have been able to image approximately 11Gb data from one partition. However it is full of defects. Is there any alternate technique to check heads ?
It seems I can read using all 4 heads so we have following 2 possibilities -

1) All 4 heads are weak & are causing bad sectors.
2) Heads are fine & its corrupted CP's are to blame.

Wishing you a nice weekend.

Attachments

Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Re: Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Re: Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Re: Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Re: Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Re: Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Re: Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Re: Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Re: Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Re: Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Re: Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Re: Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Re: Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Re: Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Re: Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Re: Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Re: Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Re: Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Re: Role of BD / BB & F0 modules in Toshiba GSYN hard disk

Re: Role of BD / BB & F0 modules in Toshiba GSYN hard disk