experiments with HDD logicboards

[BlueCop]

I don't have another seagate but i plan to buy another premium perhaps i willl get lucky.

if someone else has a seagate then perhaps we can exchange dumps of the flash chips if i can figure out something simple to dump them

[BlueCop]

I just tried hooking it up to my willem on the 25CXX slot and it didn't read the chip. i tried various settings. anyone know of something cheap i could build the read this SPI FLASH?

I took about a 3.5 SATA harddrive i have. it is manfactored by western digital. it also has a SPI flashrom on it as well.

[uberfry]

I just tried hooking it up to my willem on the 25CXX slot and it didn't read the chip. i tried various settings. anyone know of something cheap i could build the read this SPI FLASH?

give me the datasheet and i will code you something when i get home

EDIT: nvm, i found the datasheet...u mind if u have to use it in dos? ;P

[MacDennis]

what about the 512 Kbit flash memory on the Seagate? what do you think it stores.
as arakon pointed out it is a 25P05avg
http://www.st.com/stonline/products/literature/ds/8624.pdf

Hmm.. missed that chip and the post about it Yeah, I guess 512Kbit COULD be enough to store the complete FW ... interesting

First, to me that chip is way too small to hold the FW. In theory it could but I seriously doubt it.
Second, the FW can't be executed directly from a SPI device so it would have to be 'downloaded' first into RAM and being executed there on each boot. Also very, very unlikely.

Serial flash devices are a good candidate to hold configuration / calibration data.

I was also very surprised about the first reports about the SDRAM holding the FW, this is also very unlikely and luckily has been proven to be false. Motor driver holding the FW flash? I would be very, very surprised. Just look at the electronic components which surrounds this chip. My guess is that the CPU simply has an embedded flash device. An external solution might be cheaper but there's not much room left on the board.

Probably the only way to fool the console is to manipulate the inquiry device string in real-time. Which is in theory possible. BUT, if the console hold a table with allowed devices AND a corresponding HDD size then you're simply out of luck trying to use a bigger HDD. If I designed the kernel and I wanted to give you guys a headache, I would have done that. 

*edit*
See: http://www.iccd-conference.org/proceedings/2001/12000262.pdf

Integration of the Hard Disk Controller (HDC) today has taken on an extensive amount of functionality. From the host interface, error correction code, disk sequencer, microprocessor(s), servo control logic, buffer controller, to the embedded memory, the HDC has become a true system on a chip. Depending on the product, embedded DRAM is used as buffering for data between the host and media and possibly for storing controller firmware. By bringing all these blocks into one chip, pin counts can be reduced and higher data flow speeds can be obtained by decreasing the interconnect delays.

[Geremia]

what about the 512 Kbit flash memory on the Seagate? what do you think it stores.
as arakon pointed out it is a 25P05avg
http://www.st.com/stonline/products/literature/ds/8624.pdf

i would attempt to dump this chip from my seagate but i am not sure if my willem can read that type of chip. I just got the thing and am not very famialiar with it.

I might try to build something to work with ponyprog. i know it supports SPI eeproms perhaps this spi flash might be readable.

Willem can read but probably can't write because of the 256byte page program mode required by the 25p05 (willem max 128byte page, just a software limitation). I've some 25P10 from maxtor drives, and can't write.

[uberfry]

Code:

/*

PA0 = xCS
PA1 = SCK
PA2 = SI
PA3 = SO

*/

#include "avr/io.h"

void READ(int ADDRESS, unsigned char * BUFFER)
{
for(I = 0; I <= 7; I++)
{
PORTA &= ~ 0b1110;
if((I == 6) | (I == 7))
{
PORTA |= 0b110;
}
else
{
PORTA |= 0b10;
}
}

for(I = 8; I <= 23; I++)
{
PORTA &= ~ 0b1110;
if(ADDRESS && BIN)
{
PORTA |= 0b110;
}
else
{
PORTA |= 0b10;
}
BIN <<= 1;
}

BIN = 1;
PORTA &= ~0b1110;
for(I = 24; I <= 31; I++)
{
PORTA |= 0b10;
if (PINA && 0b1000)
{
* BUFFER |= BIN;
}
PORTA &= ~ 0b10;
BIN <== 1;
}
}

I just wrote that...modify just a little bit to be able to write ;X (Hint: Read instruction = 11; Write instruction = 10)

Oh, btw, this will only work with an AVR

[TheSpecialist]

First, to me that chip is way too small to hold the FW. In theory it could but I seriously doubt it.

Download that firmware ISO from hddguru => it contains several 64kb firmwares, for modern HD's, so it IS possible ... But that 'non executable' point is a good point and indeed makes it even less likely ...

[MODFREAKz]

TheSpecialist, these MPU can not contain the SN and hash data, becouse if I exchange the boards, the hard disk (hardware unit) always keep the S/N data (same number like manufacturer sticker)
I think this important data is stored on the disk or e.g. this IC.
http://www.freepler.de/userdaten/38928917/bilder/xbox360/05.jpg

My guess is that the CPU simply has an embedded flash device.
An external solution might be cheaper but there's not much room left on the board.

I think you are right, this is the best and logical method to store the FW.



Today I have bought Hitachi 60GB (HTS541060G9SA00) hard disk.
I hope the post is quick enough, I would like to open it!!!   

here nice pic 
http://www.freepler.de/userdaten/38928917/bilder/xbox360/sata_pata_char.gif

[TheSpecialist]

TheSpecialist, these MPU can not contain the SN and hash data, becouse if I exchange the boards, the hard disk (hardware unit) always keep the S/N data (same number like manufacturer sticker)
I think this important data is stored on the disk or e.g. this IC.
http://www.freepler.de/userdaten/38928917/bilder/xbox360/05.jpg

Very interesting and the big question that arises is of course: WHERE is that S/N stored ?

[BlueCop]

Hi, *
   for a reference data:
1. All HDDs store SN and Model# in the plates, areas called UBA which is not accessible via LBA. but there are special HDD low levle tools which can access these area. in most case you can modify these info.
2. The FW revision # are mostly stored in the FW flash, whether it's inside the controller, or in the plates, depends on the HDD model. in most case you can't modify it. If you can, you will need to modify the checksum in the same time.

I don't believe that the SDRAM contents any info like these.
In the mean time, I am preparing a FPGA to emulate the HDD info which I did months ago. I want to emulate the model#, SN, and FW revision#, but keep all the other data un changed with the new and "larger" HDD. This will only work if the 360 checks model#, SN, and FW rev# only. but this shall be true in most cases.
I will be back when I got some results.

^from earlier in the thread.

PC3000 software/hardware is capable of puting many harddrive models into factory mode. it costs like $600 bucks though. In the factory mode it can read/write firmwares and hidden areas on the disk.

http://www.acedre.com/pc3000.html

Germania: what settings did you use to read out such chips. i only really want reading anyway.

uberfry: forgive me ignorance but i need a little direction on how to use your program

[TheSpecialist]

So, if the S/N is really stored in that UBA area (which indeed seems likely as it isn't on the board according to TMF's experiments) and this area is writeable with some specific tools, then we MIGHT not have to change any FW at all ... But I guess tools like this are not publicly released by the manufacturers ? Anita999, can you elaborate on this ?

BTW, a very n00bish question, hehe, but what EXACTLY is 'low level' ? Is this like a manufacturer specific ATA command set ? How do you 'send' low level commands to a drive ?

[TheSpecialist]

@Bluecop: about your suggestion that the FW could be stored as data on the disk itself: it seems that this actually IS possible and is often the case ! Well, for at least a part of the FW:

From: http://www.heise.de/ct/english/05/08/172/

The hard disk manufacturers have repeatedly assured the public that they have not built into their devices backdoors in the form of secret master keys and are hence themselves unable to unlock a password-secured hard disk. Even swapping the electronics of the protected hard disk for that of an unprotected one will not suffice to outwit the protection, because large sections of the firmware and the password itself are stored on the hard disk itself and not as one might have expected in flash memory on the motherboard.

They're talking about 'large sections' of the FW. Of course, the drive needs to know how to retrieve the FW from disk, so there's still need for a piece of that FW on chip (at least, that is my interpretation). I don't know how much code is needed to retrieve a FW from disk and load it to mem, maybe it's possible to do it in a 0,5 kb piece of code ? (although I seriously doubt this)

Also interesting: http://www.actionfront.com/ts_whitepaper.aspx =>

In the field, the drive may acquire additional defects due to corrosion, handling, or other causes. These are typically identified in a table of exceptions (sometimes called the P-list and the G-list, for primary defects and grown defects, respectively). This table, the table of parameters, and the firmware are typically stored on the disk itself in the outermost tracks. These tracks are referred to as the system area, maintenance tracks, diskware, negative cylinders, etc. However, some drive models store the table in non-volatile memory on the printed circuit board. Clearly this table of exceptions is uniquely linked to the media in a particular drive. The table for one drive will not, in general, be the same for the media from another drive.

and also interesting, from this same paper:

4.1.1 Replace the PCB
The simplest hardware repair is to remove the failed PCB (printed circuit board) and replace it with one from a functioning drive. This can be done outside the cleanroom because there is no need to open the HDA.

If this method is successful, and there are is no other hardware problem, the drive can be powered on. It will spin-up, the heads will seek, the firmware and parameters tables will be read from the system area of the disk and all of the data should be accessible.

This method can fail if the drive stores the parameters tables on non-volative memory on the PCB. However, it is possible in some cases to transplant this memory chip from the failed drive's PCB to the donor PCB. This method can fail if the donor drive's PCB does not contain a very similar version of the PRML read channel to the one on the failed drive. This is because the channel settings in the parameters table might not work for the new chip. This method can also fail if there is additional damage to the drive that prevents it from seeking to the system area and reading the drive's firmware and parameter tables.

4.1.2 Replace the Firmware
In a working drive, the power-on sequence is usually similar to the following steps.

1. The chips return basic power-on status information.

2. If everything is all right, the spindle motor spins up to its target RPM (revolutions per minute), such as 10,000. Up to this point, the heads have been parked and held in place by the actuator latch against a crash stop. Parking may be in the landing zone, which is a portion of the disk surface at the extreme ID (inner diameter). Or the heads may be parked off the extreme OD of the disk on a ramp in ramp-loading drives.

3. When the target RPM is reached, the actuator latch disengages and the electronic subsystems start reading the signal coming back from one of the heads. The signal is searched for the servo wedges. Recall that these repeat 50 to 200 times on each revolution of the disk. At this point, the drive has been under the control of relatively simple programs (firmware) stored in ROM on the PCB.

4. When the servo has been found and synchronized to, the drive is now able to seek to the system area of the drive. This is typically at the extreme OD of at least one of the disk surfaces.

5. The firmware (disk ware) that resides here is then read. It contains larger programs, which control the drive more precisely, that are to be written to and executed from the drive's RAM. This area also contains the parameters tables that provide information about the physical characteristics of the heads, the optimized channel settings, the layout of the data, and where any defective sectors have been re-mapped.

6. At this point, the drive may do some additional self-tests and re-calibrations. It will then signal that it is ready to accept commands.

Clearly, anything that stops the drive from reading the firmware complicates part-replacement considerably. If the media near the landing zone is damaged, the servo might not be acquired. If there is a scratch at the OD that destroys the system area, the parameters for the hyper-tuned drive are lost, along with the firmware and defect management information.

One technique that sometimes works on failed drives is to power-on a good drive and let it load the firmware and tables into RAM. Then this hot PCB is connected to the HDA of the failed drive. It is also possible to get a snapshot of the donor drive's RAM contents and write this to the RAM of the failed drive.

For either method of getting the firmware loaded into the failed drive, the best outcome is that the drive will spin up, its own servo will be re-synchronized, and seeking will be possible. Of course, the wrong defects will probably be mapped out because the defect table from the donor drive will be in RAM.

So, that 'system area' of the harddisk is the location of our interest A google search on it shows a lot of interesting info, it's a bit late now, hehe, gonna look more into this tomorrow.

Also VERY interesting is that there is software to 'repair' info in that system area, like 'device name and size' See for example => http://www.hdd-tools.com/products/rrs/

[BlueCop]

I had another Seagate 300GB PATA drive i took a look at today. it also has a 25P05VP 512Kbit serial flash similar to the one on my 360 drive.

they both also have a ST chip that is labled SMOOTH. i think it is this http://www.st.com/stonline/prodpres/dedicate/datastor/powcomb/powcomb.htm looking at the datasheet. i think it is the chip even though it isn't labeled with that part number.

I have been trying to lookup the ST controller used in my Seagate drive without luck. i found this page on ST's website
http://www.st.com/stonline/prodpres/dedicate/datastor/hdctrl/nova.htm

its a harddisk controller that seems similar. one of its features is "512KB external ROM or Flash" i don't know if they mean kilobit or kilobyte


this is like the back of my 360 drive. i would like to start using a jumpers and see what if i can explore any factory modes. anyone know what tools i might use to experiment with these modes?

I traced where they go to
1 2 3 4
Pin 1= goes to the the smooth chip. Pin #29 from datasheet: CalCoarse Description:I5 VCM BEMF coarse calibration
Pin 2=ground
Pin 3&4= to the blank IC slot on the top of the board

here are some images i made from the boardscan i previously posted.



There is a similar blank IC spot on my 300GB it has jumper settings as well. here is an image


its pins 3 & 4 trace to the exact same spots on that empty ic spot as the pins 3&4 do on my 360 drives.

i don't know if this information is usefull at all. i just found it interesting.

Germania or uberfry: message me if you might be able to help guide me to dump these chips(one from 360 drive and the other from the 300GB). i have not had much luck with my willem and i am confused about how to use what uberfry posted

Edit:
Found something interesting for Seagate drives. i already have the parts to build it but don't know where the rx and tx lines are.
http://hddguru.com/content/en/articles/2005.10.01-Seagate-RS-232-adapter-schematic/

[uberfry]

BlueCop: well it's easy...but the problem is...I don't know how to use C on a computer (to access ports)
I could write you a code for pascal...but then you'll have to use it under DOS...
Is that ok?

[BlueCop]

uberfry: i am confused on the application. what hardware am i going to use in conjunction with this code?

yes dos, windows, linux. anye would be fine but dos would be great. its been years since i have even touched pascal =)

[chickenpie]

uberfry: i am confused on the application. what hardware am i going to use in conjunction with this code?

your not the only one

[BlueCop]

ok i am going to bed tonight but in the morning. i am going to build one of these seagate terminal adapters.
i found a couple different schematics.

and


I found a program called STMem Win which can interface with the drive(hypertermnial would work fine as well).
This STMen win has a document that lists the commands and their function. the problem is its all in russian. I am using babblefish to translate as much as i can.

It should be something exciting to play with and after reading the HDDguru forums there seems to be several other drives that have terminal interfaces and similar cables work for them.

Edit: i forgot to mention that the RX TX lines that you connect the device to are the 2 pins in the jumper settings that i posted about before.

Salvation DATA has a commercial product that sells for 600 that uses one of these cables and it boasts a big list of capabilites. i got a demo of the software.
http://www.salvationdata.com/view/product_detail.asp?pn=00011

I am hoping that most of the seagate commands with the STMen are usefull  it is also probably possible to extract some commands from the demo program.

[muuh]

uberfry: i am confused on the application. what hardware am i going to use in conjunction with this code?

yes dos, windows, linux. anye would be fine but dos would be great. its been years since i have even touched pascal =)

atmel avr mcu

http://www.atmel.com/dyn/products/param_table.asp?family_id=607&OrderBy=part_no&Direction=ASC

[BlueCop]

muuh: i don't mean to be a idiot here but i am still confused. if you could just lay it out in simple terms. am i going to use one of these chips how? I am sure i can build anything needed but i don't understand how a 25C05 + AVR + program code = dump of the chip.

[BlueCop]

well i couldn't sleep. so i decied to use one of the previously built RS232 circuits i had made for various applications(cable modem terminal, smart card emulator, dumping my dvd player firmware) and put something together that was an even simpler cricuit then the ones i posted about. It was great no soldering =)

here is the output when i turn on the 360 while the hard drive is connected . i will attempt more in the morning. i am getin tired.

Interface task reset
1024k x 16 buffer detected
MLITE - 1_Disk    3.00  03-
Buzz  - 15-05 20:16
Head Mask FFFF - Switch to full int.
              Spin Ready
3.01  03-15-05 20:19
(P)SATA Reset

any fellow russian hackers out there? i need some help translating a help document from the linked archive below. thanks for any assistance

http://files.hddguru.com/index.php?action=downloadfile&filename=st_mem_win_free.zip&directory=_soft/Seagate&