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

Main » Forums home » Conventional hard drives

All times are UTC - 5 hours [ DST ]

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

Page 1 of 2

[ 23 posts ]

Go to page 1, 2 Next

Previous topic | Next topic

Author

Message

higgsboson

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

Posted: July 6th, 2016, 10:21

Joined: September 1st, 2012, 6:16
Posts: 198
Location: Universe

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:

Sa3.JPG [ 84.61 KiB | Viewed 22858 times ]

Sa2.JPG [ 87.11 KiB | Viewed 22858 times ]

sa1.JPG [ 87.77 KiB | Viewed 22858 times ]

glist.JPG [ 187.09 KiB | Viewed 22858 times ]

33.JPG [ 81.15 KiB | Viewed 22858 times ]

22.JPG [ 95.78 KiB | Viewed 22858 times ]

Top

jermy

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

Posted: July 6th, 2016, 11:15

Joined: March 19th, 2015, 15:01
Posts: 1388
Location: isreal

higgsboson wrote:

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

Try PBA access (solve G-list damage

Top

fzabkar

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

Posted: July 6th, 2016, 18:15

Joined: September 8th, 2009, 18:21
Posts: 16960
Location: Australia

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.

_________________
A backup a day keeps DR away.

Top

higgsboson

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

Posted: July 7th, 2016, 6:42

Joined: September 1st, 2012, 6:16
Posts: 198
Location: Universe

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

Top

labtech

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

Posted: July 7th, 2016, 7:14

Joined: August 18th, 2010, 17:35
Posts: 3669
Location: Massachusetts, USA

Most likely a heads problem.

_________________
Hard Disk Drive (HDD), Solid State Drive (SSD, SATA, NVMe, etc), USB Flash Drive and RAID Data Recovery Specialist in Massachusetts

Top

jermy

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

Posted: July 7th, 2016, 7:52

Joined: March 19th, 2015, 15:01
Posts: 1388
Location: isreal

labtech wrote:

Most likely a heads problem.

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

Top

fzabkar

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

Posted: July 7th, 2016, 16:14

Joined: September 8th, 2009, 18:21
Posts: 16960
Location: Australia

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

_________________
A backup a day keeps DR away.

Top

higgsboson

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

Posted: July 8th, 2016, 1:27

Joined: September 1st, 2012, 6:16
Posts: 198
Location: Universe

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

Top

athena

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

Posted: July 8th, 2016, 3:09

Joined: May 30th, 2014, 0:54
Posts: 152
Location: Universe

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 ?

Top

terminator2

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

Posted: July 8th, 2016, 5:00

Joined: November 23rd, 2010, 13:32
Posts: 548
Location: brisbane

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

Top

higgsboson

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

Posted: July 8th, 2016, 7:33

Joined: September 1st, 2012, 6:16
Posts: 198
Location: Universe

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

BD.JPG [ 185.26 KiB | Viewed 22660 times ]

initial.log [8.92 KiB]
Downloaded 1140 times

SH checksum.JPG [ 194.2 KiB | Viewed 22660 times ]

BD checksum error.JPG [ 192.66 KiB | Viewed 22660 times ]

BB check sum OK.JPG [ 202.84 KiB | Viewed 22660 times ]

Top

labtech

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

Posted: July 8th, 2016, 11:56

Joined: August 18th, 2010, 17:35
Posts: 3669
Location: Massachusetts, USA

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

_________________
Hard Disk Drive (HDD), Solid State Drive (SSD, SATA, NVMe, etc), USB Flash Drive and RAID Data Recovery Specialist in Massachusetts

Top

fzabkar

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

Posted: July 8th, 2016, 15:37

Joined: September 8th, 2009, 18:21
Posts: 16960
Location: Australia

@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.

_________________
A backup a day keeps DR away.

Top

fzabkar

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

Posted: July 8th, 2016, 16:46

Joined: September 8th, 2009, 18:21
Posts: 16960
Location: Australia

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.

_________________
A backup a day keeps DR away.

Top

terminator2

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

Posted: July 9th, 2016, 9:37

Joined: November 23rd, 2010, 13:32
Posts: 548
Location: brisbane

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.

Top

higgsboson

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

Posted: July 9th, 2016, 10:04

Joined: September 1st, 2012, 6:16
Posts: 198
Location: Universe

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:

Defects.JPG [ 690.59 KiB | Viewed 22575 times ]

Top

pcimage

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

Posted: July 9th, 2016, 10:28

Joined: November 29th, 2006, 10:08
Posts: 7864
Location: UK

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

_________________
PC Image Data Recovery
http://www.pcimage.co.uk

New!! HDD-PCB.COM for all your PCB and donor HDD requirements!

Top

labtech

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

Posted: July 9th, 2016, 10:31

Joined: August 18th, 2010, 17:35
Posts: 3669
Location: Massachusetts, USA

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.

_________________
Hard Disk Drive (HDD), Solid State Drive (SSD, SATA, NVMe, etc), USB Flash Drive and RAID Data Recovery Specialist in Massachusetts

Top

fzabkar

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

Posted: July 9th, 2016, 18:27

Joined: September 8th, 2009, 18:21
Posts: 16960
Location: Australia

@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.

_________________
A backup a day keeps DR away.

Top

higgsboson

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

Posted: July 10th, 2016, 9:16

Joined: September 1st, 2012, 6:16
Posts: 198
Location: Universe

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:

Head 3.JPG [ 180.47 KiB | Viewed 22515 times ]

Head 2.JPG [ 181.21 KiB | Viewed 22515 times ]

Head 1.JPG [ 174.54 KiB | Viewed 22515 times ]

Head 0.JPG [ 183.68 KiB | Viewed 22515 times ]

Top

Page 1 of 2

[ 23 posts ]

Go to page 1, 2 Next

Main » Forums home » Conventional hard drives

All times are UTC - 5 hours [ DST ]

Who is online

Users browsing this forum: Google [Bot] and 143 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum