linux to repair bricked drive

[birdy]

Hi,
I'm trying to make a boot CD to repair and flash entire firmware.
To make that i have patch the new libata driver.

http://rapidshare.de/files/29756598/libata-core.c.html

With this patch if a drive is physical present, no need to be right identified to have a scsi link into /dev/

For work with "non bricked drive" this is a start of a linux code source:
1- detect drive
2- force drive into modeB
3- upload in ram $8000000 code  "DC 00 10 00 10 00" to jump into $90001000 (recovery code)
4 - exec code

But in this time the  drive seen to crash, i'm searching why

Idee is to use the "E7 3B 06" to upload a flash function and "E7 3B 07" to exec it.

this is the source code of the start from this software.

http://rapidshare.de/files/29758270/flasher.tar.gz.html

[xt5]

nice work, does your moded libata "see" a "panic mode" drive?

[geebee]

Probutus might be interested in this...

[birdy]

Yes the kernel can detect bricked firmware because it detect physical line direct from the sata chipset.
The patch it's not perfect, must be updated but work.

[probutus]

nice project! I downloaded the source and looked at it but I need to know the exact kernel version from where it was derived (I compared it to 2.6.16.1 and there were loads of changes...)

[birdy]

Hi probutus,

The kernel version is 2.6.17.8.
I have make a bootcode to jump into recovery mode or make a "soft reset" from the drive.
That seen to work, now i need to test the upload code ans exec code

[birdy]

if all work i release than a linux boot cd.
But too time i have problem to "reboot" the drive 

[probutus]

I heard before that the hitachi drive only supports a very limited amount of commands and that it will get confused if it receives a "unknown" one...

I had a look into the libata-core.c and saw that after the drive is detected (in function ata_bus_probe()) the kernel tries to apply a ata_set_mode which transmits the desired DMA/PIO mode to the drive. Maybe this can cause problems...

But if you want to reboot the drive cant you just do a jump to the start of the flash again (afaik 0x9000020) which lets the drive restart (i am no expert in the firmware code; just an idea)  The sata-busreset (soft and hardreset is supported) function in libata-core.c might also be an idea (can be also done via ioctl()) question is: Is the reset command supported in the panic mode firmware?

[birdy]

hi,

A simple jump to $900020 freeze the drive. I have try with the full bootsequence, and freeze too.
It appear (thank to geremia) that a bset 1, 0xD900 make a soft reset from the drive.
The problem is to jump into recovery mode.
to make that whe can :
1 - corrupt the checksum
2 - patch the start of firmware $9000000 to $90001000
And than a soft reset.
I think ideal where to patch the start from firmware with this trick : tray closed = mode recovery tray opened = mode normal.
At end from flash , unpatch this section to normal boot.

I have not tested but on computer start or reboot the bios make a sata busreset but that don't reboot the drive (drive stay in modeB with slax CD after a reboot)

[probutus]

when restarting the drive there is only a softreset applied to the devices connected to the sata bus (this is why the drive stays in modeb after resetting the system). If we apply a hardreset everything should be back in mode a (just a assumption, needs to be verified).

Is there a list of ata/atapi commands available which commands are supported in
1)recovery mode
2)mode a
3)mode b (ok; I assume here everything is possible)
I know from my investigations that if the drive is in mode a and we try to apply the set_xfer_mode command the drive locks up completely.. (this is why the slax cd applies the modeb directly after identification is done). I also had a cd (long time ago) which recognized the drive in mode a and had to be pushed to mode b manually (there I removed the set xfer mode from driver initialization).
If we have a list of supported commands/needed modifications we can modify the atapi-command translation inside the drivers to a)ignore unsupported commands and b)modify supported commands with extra parameters (aka. C0 mod for identify packet device)

[catdog]

Just out of interest, are you able to detect a corrupt hitachi drive in your bios?  My NF3 motherboard freezes at the bios screen and then (infinately) reboots until I remove the drive.  I guess its no problem to hotswap in the drive after the bios has finished loading, but I am just wondering if it is my brand of motherboard that causes the reboot?

[probutus]

I REALLY dont want to piss anyone off but this is a TECHNICAL thread; if you have trouble with your drive please post in the SUPPORT section

[catdog]

probutus: I am not looking for support as I have repaired a couple of these drives using an external programmer - obviously a software method would be preferable compared with this task.  Its still partially on topic since it makes it more difficult to run a linux utility if the PC wont POST - I am just trying to get an understanding of exactly how "dead" these drives are and whether they respond to the bios on other PCs.

Back to the technical chat...

[probutus]

@catdog: ok, understood; I only want to prevent this great thread from going OT and thus getting 'useless'.
About recovery mode: When you flash a drive the first modification is to set the checksum to 0x00000 to prevent the drive going to recovery mode since till now not much is known about this mode (and were here to find out  ).

The drive only goes to recovery mode if it detects that the calculated checksum over the flash mismatches the calculated one and this is in nearly 100% of all flashing attempts NOT the case since the checksum has been 'switched off' with 0x00000.

So if you have a flashed drive and the checksum is already 0x00000 the drive wont go to recovery mode but hang somewhere else so that recovery mode is useless...

Back to topic: Has someone a list of supported commands and needed modifications for the recovery mode available? (commands supported in mode a would also be interesting...)

[xt5]

Back to topic: Has someone a list of supported commands and needed modifications for the recovery mode available? (commands supported in mode a would also be interesting...)

Code:

ATA CMDS supported in panic mode:

08h DEVICE RESET (only 8163/4B)
A1h IDENTIFY PACKET DEVICE
90h EXECUTE DEVICE DIAGNOSTIC (only 3120L)

ATAPI CMDS supported in panic mode:

E7h VENDOR SPECIFIC
  E7 XX XX XX 3B 06 XX XX XX XX LL LL (copy code to the 0x80000000 region)
   LL LL = PAYLOAD LENGTH
   the payload must come with his checksum (sum16 LE) in the last 2 bytes.

  E7 XX XX XX 3B 07 P0 P1 P2 P3 P4 P5 (exec code @0x80000000 region)
   P0...P5 = customs parameters

12h INQUIRY
  12 XX XX XX LL
   LL length of data expected (upto 96 bytes)

the questions are:
does the birdy mod to libata-core works can perform flawlessly a "ATAPI INQUIRY" CMD?
does that mod disable the automatic "REQUEST SENSE" after ATAPI CMDs?

If the response to that 2 question is positive, I don't see any problem in repair/upgrade/downgrade a firm (I've done it succefully in a "panic mode" 8164B).

about put the drive in panic mode using a simple JUMP to 90001000 wont work because the MCU state is really unknown when you jump to that location, to figure how to "softreset" into panic mode, a deep look at 0x40000000 can give us some clues (but seems a very hard task).

a way to force the drive to get in panic mode can be putting ground to the higher address line to make the checksum test to fail without corrupting the flash, but I really don't know how to do this electrically safe.

the other way can be patching the code when it calculate the checksum and check for tray status to select "panic mode", reading birdy's documentation on his hack  seems to be 0xD930 bit 1, and that guide me to another question, has anybody figured the MN103 internal registers??

I only know at the moment:

0xD930: port XX input data register
  bit 1: tray status

0xD990: port YY output data register
  bit 8: LED (on 8163/4B)

0xDC00-0xDCFF: timers related registers

[birdy]

Code:

ATAPI CMDS supported in panic mode:

E7h VENDOR SPECIFIC
  E7 XX XX XX 3B 06 XX XX XX XX LL LL (copy code to the 0x80000000 region)
   LL LL = PAYLOAD LENGTH
   the payload must come with his checksum (sum16 LE) in the last 2 bytes.

  E7 XX XX XX 3B 07 P0 P1 P2 P3 P4 P5 (exec code @0x80000000 region)
   P0...P5 = customs parameters

12h INQUIRY
  12 XX XX XX LL
   LL length of data expected (upto 96 bytes)

thanks,
I want make test about this function, upload and exec can help to flash the drive.


>the questions are:
>does the birdy mod to libata-core works can perform flawlessly a "ATAPI INQUIRY" CMD?
>does that mod disable the automatic "REQUEST SENSE" after ATAPI CMDs?

This mod is very easy : If is a drive physicaly present than linux make a scsi entry in /dev/ (sda .. sdb or another)
But than the kernel make nothing else, no inquiry, nothing
In this way the kernel give us only a way to send command to the drive.


>If the response to that 2 question is positive, I don't see any problem in repair/upgrade/downgrade a firm (I've done it succefully in a "panic mode" 8164B).

>about put the drive in panic mode using a simple JUMP to 90001000 wont work because the MCU state is really unknown when you jump to that location, to figure how >to "softreset" into panic mode, a deep look at 0x40000000 can give us some clues (but seems a very hard task).

I have try at first to copy the boot sequence from $90000000 to $9000011A because it reset all registry and the PSW. Without sucess.
But it's possible to make a soft reset by put bit 1 from register D900.
Than the idee is for 'no bricked drive' to reflash the boot sequence at $90000000 with the tray tweak (closed=recovery) than reset the drive.

>a way to force the drive to get in panic mode can be putting ground to the higher address line to make the checksum test to fail without corrupting the flash, but I really don't know how to do this electrically safe.

We must make that for bricked drive, because all flasher set the checksum to 0. That a problem, because the firmware jmp in 'normal mode' and than freeze.
But the checksum is a high memory value > $30000 and the chesum test and recovery mode at low value <$2000.
30000 = 110000000000000000 than if we put only one adress bit low (connect to gnd) the checksum is read an another memory adress and fail.

I have read in this thread that bricked drive fail in bios, the reason is that the drive is not in 'recovery mode' (because the checksum is set to 0).
The bios wait for only for inquiry, this function work in real recovery mode.

>the other way can be patching the code when it calculate the checksum and check for tray status to select "panic mode", reading birdy's documentation on his hack  seems to be 0xD930 bit 1, and that guide me to another question, has anybody figured the MN103 internal registers??

I have 'virtually bricked' my drive with this tweak ;-)

code at $90000090

$90: movbu (D930),D0  // 34 30 D9
$93: btst 1,D0              // F8 EC 01
$96: bne $9000009C     // C9 07
$98: jmp $90001000     // DC 68 0F 00 00
$9C: jmp $90006040    // DC 14 5F 00 00

>I only know at the moment:

0xD930: port XX input data register
  bit 1: tray status

0xD990: port YY output data register
  bit 8: LED (on 8163/4B)

0xDC00-0xDCFF: timers related registers
[/quote]

[birdy]

oups on
$9D : jmp 90006040 : DC A3 5F 00 00
mistake :-(

[xt5]

sad to know just now your trick to get in "panic mode", I've intentionally corrupted my flash for that some time ago, and next to that I have fried my drive with a switch  from that time I haven't a 3120L anymore.

This mod is very easy : If is a drive physicaly present than linux make a scsi entry in /dev/ (sda .. sdb or another)
But than the kernel make nothing else, no inquiry, nothing
In this way the kernel give us only a way to send command to the drive.

ok, but I think that a simply INQUIRY won't work because the "request sense" is still there and the drive don't support it. that is why any "normal" atapi layer don't work with panic mode, please test doing a INQUIRY to see if it works.

I have read in this thread that bricked drive fail in bios, the reason is that the drive is not in 'recovery mode' (because the checksum is set to 0).
The bios wait for only for inquiry, this function work in real recovery mode.

many cards also don't detect the drive and hang in his normal status, like my vt6421, I think that it is because the "non normal INQUIRY CMD" in modeA, many SATA CARDs seems to do an "ATAPI INQUIRY" instead of an "ATA IDENTIFY PACKET DEVICE" like any IDE unit, that is why a 8163/4B get detected by almost all motherboards when they are in panic mode.

[birdy]

Yeah i have bricked my drive,

Bad flash.
Now i must wait for a new tsop (Very big thanks geremia) or the willem programmer (it come from thailand, i can wait)

...... 

[birdy]

Hi,

On /include/linux/libata.h if we make this change :

static inline unsigned int sata_dev_present(struct ata_port *ap)
{
   #ifndef Xbox360
   return ((scr_read(ap, SCR_STATUS) & 0xf) == 0x3) ? 1 : 0;
   #else
   return ((((scr_read(ap, SCR_STATUS) & 0xf) == 0x3) || (scr_read(ap, SCR_STATUS) & 0xf) == 0x1)) ? 1 : 0;
   #endif
}

Than a fully bricked drive (without working recovery ... my drive lol) is detected.
This is a copy from my dmesg (with more info, if have add kprintf in source)
(bricked drive on ata 2)

......
.......
EXT3 FS on hda5, internal journal
SCSI subsystem initialized
libata version 1.20 loaded.
sata_sil 0000:00:11.0: version 0.9
ACPI: PCI Interrupt 0000:00:11.0[A] -> GSI 23 (level, low) -> IRQ 20
ata1: SATA max UDMA/100 cmd 0xF8BCAC80 ctl 0xF8BCAC8A bmdma 0xF8BCAC00 irq 20
ata2: SATA max UDMA/100 cmd 0xF8BCACC0 ctl 0xF8BCACCA bmdma 0xF8BCAC08 irq 20
Entering ata_bus_probe
ap->ops->probe_reset set to 1 (line 1395)
Entering ata_drive_probe_reset on line 2481
Probeinit (ap) on 2491
ata1: SATA link down (SStatus 0)
Softreset on 2499 return : 0
Entering : Read IDENTIFY page and configure
scsi0 : sata_sil
Entering ata_bus_probe
ap->ops->probe_reset set to 1 (line 1395)
Entering ata_drive_probe_reset on line 2481
Probeinit (ap) on 2491
Softreset on 2499 return : -5
ata2 is slow to respond, please be patient
ata2 failed to respond (30 secs)
Hardreset on 2518 return : -5
ata2: reset failed (errno=-5)
scsi1 : sata_sil
ACPI: PCI Interrupt 0000:00:12.0[A] -> GSI 22 (level, low) -> IRQ 21
ata3: SATA max UDMA/100 cmd 0xF8BCC880 ctl 0xF8BCC88A bmdma 0xF8BCC800 irq 21
ata4: SATA max UDMA/100 cmd 0xF8BCC8C0 ctl 0xF8BCC8CA bmdma 0xF8BCC808 irq 21
Entering ata_bus_probe
ap->ops->probe_reset set to 1 (line 1395)
Entering ata_drive_probe_reset on line 2481
Probeinit (ap) on 2491
ata3: SATA link down (SStatus 0)
Softreset on 2499 return : 0
Entering : Read IDENTIFY page and configure
scsi2 : sata_sil
Entering ata_bus_probe
ap->ops->probe_reset set to 1 (line 1395)
Entering ata_drive_probe_reset on line 2481
Probeinit (ap) on 2491
ata4: SATA link down (SStatus 0)
Softreset on 2499 return : 0
Entering : Read IDENTIFY page and configure
scsi3 : sata_sil
Adding 1542200k swap on /dev/hda6.  Priority:-1 extents:1 across:1542200k
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
NTFS driver 2.1.27 [Flags: R/O MODULE].
NTFS volume version 3.1.
NTFS volume version 3.1.
loop: loaded (max 8 devices)
hdc: ATAPI 40X DVD-ROM DVD-R-RAM CD-R/RW drive, 2000kB Cache, UDMA(66)
Uniform CD-ROM driver Revision: 3.20
NET: Registered protocol family 17
8139too Fast Ethernet driver 0.9.27
ACPI: PCI Interrupt 0000:02:03.0[A] -> GSI 20 (level, low) -> IRQ 19
eth0: RealTek RTL8139 at 0xf8c26800, 00:13:d3:df:19:c9, IRQ 19
eth0:  Identified 8139 chip type 'RTL-8100B/8139D'
eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
eth0: no IPv6 routers present