Hello,

Is there anyone who have pinouts of 88i6745n JTAG?
or PASS for RAR file: http://www.griol.com/ftp/WD/88I6745.rar ?
or a way to rewrite broken ROM in 88i6745n ?
or a way to boot from external U12 EEPROM 24p10, 24p20 ?

B.R.
Dex

It seems that nobody wants to help me, so I've find JTAG pins by my self!
Hope that somebody will be interested.

JTAG pins are on board CON1 and it seems that is same on all boards?!!
I tested on 2061-701335-c00 Marvell 88i6545 and 2061-701499-e00 Marvell 88i6745n.
Both chips have same ID 0x259663d3 !!!

Here is connection to 2061-701499-e00.



And closeup connection to JTAG test points.



And closeup connection to JTAG CON1.




B.R.
Dejan

Good work

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

I like it too

_________________
All went well until I plugged the drive in.

OK. I was interested in rewriting damaged EEPROM(ROM) inside Marvell 88i6745n.
It seems that lots of people here have solution for it, but they wont to share?!!!
Am I on wrong forum? Isn't information have to be free?
Anyway, that means that I have to find by myself solution,... if someone wants to hellp, it will be nice.

First we can use OPENOCD
http://openocd.berlios.de/
Last version is 0.5.0 but I'm using 0.4.0
For those with Linux, I do not have to explain what to do.
For those with Windows, look on Google for: openocd 0.4.0 windows installer

Next we have to find some JTAG interface. Look in OPENOCD what JTAG interfaces are
supported and get one.

I'm using simple LPT Xilinx III cable which can be made at home.


CONNECTION TO Marvell 88i6745n:
---------------------------------
As you can see in my previous post there are JTAG pins:

Pins that MUST be used!

GND
TDI
TMS
CLK in
TDO

Pins that can be used or not depend on your JTAG interface!

Vcc 3.3v - for powering JTAG interface or for reference.
CLK out - for VERY FAST JTAG interface that support CLK out
RST - for JTAG interface that support RST


For Xilinx III JTAG interface only GND, TDI, TMS, CLK in, TDO, Vcc 3.3 is used!
-----------------------------------------

Starting:
--------
1. Copy to openocd\bin "feroceon.cfg" from openocd\target
2. Copy or create jtag.cfg to openocd\bin depend on your JTAG interface.

In my case for Xilinx III JTAG interface file is:

#*******************************
#daemon configuration
telnet_port 4444
gdb_port 3333

#interface
interface parport
parport_cable dlc5
parport_port 0x378
#*******************************

3. Copy to openocd\bin "putty.exe" or use your favorite telnet.
http://www.putty.org/

4. In my example I used only board (removed from HDD) that have corrupted EEPROM(ROM)
2061-701499-e00 Marvell 88i6745n.
I'm not sure is it important but I have set board to test mode (First 3 pins are soldered to GND)
Connect JTAG interface to board.
Connect SATA power to board.

5. Go to openocd\bin and type: openocd.exe -f jtag.cfg.txt -f feroceon.cfg

If everything is ok you have to get something like this:



As you can see device ID is 0x259663d3 and since OPENOCD do not have appropriate loader
we can use "feroceon.cfg".

If you get ANY other error try to read OPENOCD documents!!!

6. Now run telnet. Go to openocd\bin and type: putty.exe
Once opened, in "Host name (or IP address)" type: local host
select in "Connection type" Telnet
in "Port" type: 4444
and hit "Open" button

If everything is ok, it will open new window like this:



7. In telnet type: halt

If everything is ok, it will look something like this:



That means that you have FULL controll over Marvell 88i6745n !!!

B.R.

Dejan

[OFF TOPIC]
Are you the Dejan who plays with SIM card and phones ?
[OFF TOPIC]
Great Job by the way !

_________________
Lemmy

Actually I think very few people know how to do that
I personally don't know that
From my understanding to re-flash it you have to run some kind of procedure inside the drive which unlikely exists in the kernel code
I think you need a loader of some kind to flash it
Anyway the kernel code usually located at FFFF0000
The internal flash projection usually lives at FFF00000 (addressing has to be ebabled)
Something like this
Kernel:FFFF0C32 LDR R0, =Flash_Base ; jumptable FFFF0C20 case 1
Kernel:FFFF0C34 LDRH R1, [R0,#2]
Kernel:FFFF0C36 LSRS R1, R1, #1
Kernel:FFFF0C38 LSLS R1, R1, #1
Kernel:FFFF0C3A STRH R1, [R0,#2]
Kernel:FFFF0C3C LDRH R1, [R0,#2]
Kernel:FFFF0C3E MOVS R2, #0x80 ; 'А'
Kernel:FFFF0C40 ORRS R1, R2
Kernel:FFFF0C42 STRH R1, [R0,#2]
Kernel:FFFF0C44 LDR R0, =0xFFF00000
Kernel:FFFF0C46 B loc_FFFF0C5E

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

But I don't think that FFF00000 will contain exact flash image because flash has a header and it cannot be run as is

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

I remembered anecdote about "elusive Joe"
Why we need break through the wall when we can get inside from the side?

This pass much easy :


External Rom + two resistors the key to success

Any way, nice work, i like

_________________
Angel Data Recovery

I have some 701590 PCBs with killed internal flash
Do you know who to make external flash work on those?

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

PM sent...

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

@Doomer
It is called "bootstrap" it is OTP or mask programmable ROM.
It is on addr 0xffff0000 in size of less than 0x2000

@All
To dump bootstrap from Marvell chip, after "halt" from OPENOCD type
dump_image ffff0000.bin 0xffff0000 0x10000

If everything is ok, it will be something like this:



And file "ffff0000.bin" will be created in openocd\bin dir.

In my case SHA1 of "ffff0000.bin" is 5ab6b58869a6cf40aaa60626e8440c0abc186ae8

Now you can use any ARM disassembler to analize code!!!

Some addresses:
0xffff0000 HW RESET vector
0x04000000-0x04007fff internal SRAM for STACK.
0x00000000-SDRAM 8-32Mb ???
0x1c00xxxx-ports?

0x1c00a6xx serial port
0x1c00a8xx I/O port ?

For "ffff0000.bin" sha1=5ab6b58869a6cf40aaa60626e8440c0abc186ae8
CODE rutines:

FFFF1A70: start tiny console thumb
FFFF01B4: start tiny console arm
FFFF1944: send_asciiz_string
FFFF1A16: receive_and_resend_CMD
FFFF18E2: send_byte
FFFF1A06: receive_byte
etc etc

Function "start tiny console"
After HW reset, CPU test port 0x1C00A84E. If bit 13 is set it runs "start tiny console"!!!

Tiny console have only 3 function:
----------------------------------
r <32bit address> ;read one half word(16 bit) from address
w <32bit address> <16bit data> ;write one half word(16 bit) to address
j <32bit address> ;jump or call code on address

With those 3 functions we can do everyting with CPU on low level.

Problem is how to set bit 13 on 0x1C00A84E.
Port 0x1C00A84E is connected to 4 pin (8 pin on 3.5'') jumper header, so bit 13 have to be
connected to some pin or by using some combination of jumper header!!!

I tested tiny console by calling it using JTAG:

Connect COM or USB to COM port with 3.3v levels to board:



Set you COM port on PC to 115200 8 N 1 using Hyper Terminal and run.
Now, run openocd:
halt
reg sp_usr 0x4005000
reg pc 0xffff1a70
resume

If everything is ok, it will be something like this:



Hyper Terminal will be prompted! Now you can switch to Hyper Terminal and type for test:



If we can find a way to run tiny console, then we can access CPU without JTAG!


B.R

Dejan

I doubt that
More likely it will live on CON1

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

mine drive has 4 commands

Kernel:FFFF19C6 Kernel_s_cmd ; CODE XREF: Kernel_debug_mode+70j
Kernel:FFFF19C6 LDR R1, =unk_1C00A020
Kernel:FFFF19C8 MOVS R0, #6
Kernel:FFFF19CA STRH R0, [R1,#0x1A]
Kernel:FFFF19CC
Kernel:FFFF19CC loc_FFFF19CC ; CODE XREF: Kernel_debug_mode+98j
Kernel:FFFF19CC LDRH R0, [R7,#4]
Kernel:FFFF19CE LSLS R0, R0, #0x1F
Kernel:FFFF19D0 BPL loc_FFFF19CC
Kernel:FFFF19D2 LDRH R0, [R7,#4]
Kernel:FFFF19D4 ORRS R0, R6
Kernel:FFFF19D6 STRH R0, [R7,#4]
Kernel:FFFF19D8 B loc_FFFF1966

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

You might like port 1C00A846, especially bit 2 in it
If you manage to enter this mode - flashing will be much easier
But I would hate to go there through jtag

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

Image of internal FLASH(EEPROM) is on address: 0xfff00000, size 0x30000.
Bootstrap looks for first part of FLASH. We can call it "kernel loader"

Header of "kernel loader" is on 0x00000000 of Flash (physical addr: 0xfff00000)
in size of 0x20 with CHK
---------------------------
0x5a ;Header ID
04,0,0 ;?
0xd,0xc,0,0 ;=0x00000c0d size of "kernel loader" + CHK
0xc,0xc,0,0 ;=0x00000c0c size of "kernel loader"
0x20,1,0,0 ;=0x00000120 start of "kernel loader" data in FLASH (physical addr 0xfff00120)
0x80,0xa,1,0 ;=0x00010a80 physical addr where "kernel loader" have to be loaded
0x80,0xa,1,0 ;=0x00010a80 physical addr of execute start once "kernel loader" is loaded
0,0,0 ;?
0xd1 ;Header ID CHK 8-bit cheksum of first 0x1f bytes of "kernel loader" header

For this case bootstrap loads "kernel loader" to addr: 0x0x00010a80 in size 0x00000c0c
calculate 8 bit cheksum and compare with next byte (offset + 0x00000c0c)

IF both cheksum are OK then bootstrap RUNS "kernel loader" (in this case from 0x00010a80),
OTHERWISE it runs "terminal" rutine.

For "ffff0000.bin" sha1=5ab6b58869a6cf40aaa60626e8440c0abc186ae8
"terminal" rutine:= 0xFFFF0A50

This rutine using same serial port like "tiny console" only protocol is different.
Once started it sends every second byte 0x15 to serial port and waits for appropriate
command.

So, if on your WD board, in internal FLASH is corrupted part of "kernel loader", then you can
simple connect board on serial port. If everything is ok, bord will start to send 0x15, and
you can using "terminal" protocol to repair internal FLASH without JTAG!!!

In my case "kernel loader" data is correct and I have to find other solution.

B.R.

Dejan

It's called X-modem. And Hyperterminal is hacker's best friend


Which is never the case
If "loader" is corrupted then almost definitely the rest of the flash is corrupted too
And uploading just a flash to memory using x-modem will not help because "loader" from loaded flash image will try to access mapped internal flash at 0xFFF00000 but it remains corrupted.


Which is usually the case - incompatible flash from another drive kills PCB logically

We back to port 1C00A846
Anyway if you find where 1C00A846 is connected it might be useful. It must be related to resistors which responsible for external flash
But of course next step will be reversing drive's FW to find internal flash writing commands and then creating loader which will program internal flash from a file. You still want to do that?

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

I recon he will :@)

_________________
All went well until I plugged the drive in.

"Tiny Console" is activated!

Connect resistor 4k7 to P1 test point (+3.3v) and E6 test point.



Connect Rx and Tx line to COM port.



Connect SATA POWER conector.

Run Hyper Terminal on PC with setings 115200 8 N 1.



And that is it!!!

B.R.

Dejan

So you made "5" (or maybe it was 0x1C00A84E)
If you make it "3" you'll get X-Modem
Great work

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.