Is erasure of the HDD by an electromagnetic pulse generator death of the HDD?

Pedantic hell. I state a fact.

The electronic circuit board that is part of the hard disk drive contains
the drives firmware in an eprom! This is why you can flash a new firmware to
correct for errors when a manufacturer issues the firmware update.

http://www.databe.com/articles/article4.html

Firmware IS NOT contained on the drive platters in any way, shape or form!



--

Richard Urban
Microsoft MVP
Windows Desktop Experience & Security


"M.I.5¾" wrote in message
...

"Richard Urban" wrote in message
...
Firmware is exactly as it implies - code that is held within a chip - not
on the hard drive.


If you want to be pedantic.

"Richard Urban" wrote in message
...
Pedantic hell. I state a fact.

The electronic circuit board that is part of the hard disk drive contains
the drives firmware in an eprom! This is why you can flash a new firmware
to correct for errors when a manufacturer issues the firmware update.

http://www.databe.com/articles/article4.html

Firmware IS NOT contained on the drive platters in any way, shape or form!


You can't 'flash' firmware into an EPROM. I have checked several hard disc
drives and not one contains an EPROM on it (even very old 10 MB drives).
The absence of a chip with a quartz window on it is the give away.

Any modern drive permits the 'firmware' on the drive to be replaced.

'Matching the code' as your reference puts it is marketing bull****. If the
firmware on the drive is corrupt, the disc won't start.

M.I.5¾ wrote:
"Richard Urban" wrote in message
...
Pedantic hell. I state a fact.

The electronic circuit board that is part of the hard disk drive contains
the drives firmware in an eprom! This is why you can flash a new firmware
to correct for errors when a manufacturer issues the firmware update.

http://www.databe.com/articles/article4.html

Firmware IS NOT contained on the drive platters in any way, shape or form!


You can't 'flash' firmware into an EPROM. I have checked several hard disc
drives and not one contains an EPROM on it (even very old 10 MB drives).
The absence of a chip with a quartz window on it is the give away.

Any modern drive permits the 'firmware' on the drive to be replaced.

'Matching the code' as your reference puts it is marketing bull****. If the
firmware on the drive is corrupt, the disc won't start.


Really ? I picked up the first drive I could lay my hands on.

Seagate ST380011A IDE 80GB and it has a 25P05AV on it. I needed a
magnifying glass to get the part number off it.

http://media.digikey.com/photos/Numo...P05-AVMN6T.JPG

Look next to the controller chip, for an 8 pin DIP. It is an
EEPROM (electrical erasable) with a serial SPI interface.

http://search.digikey.com/scripts/Dk...=497-1621-1-ND

(PDF datasheet here. Can't find it on st.com or Numonyx.)

100,000 Erase/Program Cycles.

http://www.alldatasheet.com/datashee...M25P05-AV.html

Either a controller has EEPROM inside, or in this case, a pretty small
chip next to the controller, has the goods. The space is 64K x 8
or 64KB (512 kilobit), which is plenty to code up either a bootstrap loader
or to hold an entire controller code. Twenty years ago, we did this
in 4KB (and we had room left over). So I don't see 64KB being a problem,
either way (bootstrap or the whole thing). There is no GUI and no .NET in there :-)

This doesn't resolve your current discussion, about what is
held on "track -1", so carry on debating... There are web pages
that discuss the contents of that area of the platters, but who
do you believe. The story could easily change with each generation
of disk. What was true yesterday, could be false tomorrow.

You can get 8 pin DIP flash with 2MB storage. So there are
bigger ones if needed. The 64KB size found on my disk drive,
is also used on video cards to hold the VESA BIOS. 128KB chips
are used on Macintosh versions of video cards. So those little
chips have been around. I flash upgraded my Mac video card with
128KB chip, to run in a PC as the video card. I'm typing on that
video card right now :-)

Paul

"Paul" wrote in message ...
M.I.5¾ wrote:
"Richard Urban" wrote in message
...
Pedantic hell. I state a fact.

The electronic circuit board that is part of the hard disk drive
contains the drives firmware in an eprom! This is why you can flash a
new firmware to correct for errors when a manufacturer issues the
firmware update.

http://www.databe.com/articles/article4.html

Firmware IS NOT contained on the drive platters in any way, shape or
form!


You can't 'flash' firmware into an EPROM. I have checked several hard
disc drives and not one contains an EPROM on it (even very old 10 MB
drives). The absence of a chip with a quartz window on it is the give
away.

Any modern drive permits the 'firmware' on the drive to be replaced.

'Matching the code' as your reference puts it is marketing bull****. If
the firmware on the drive is corrupt, the disc won't start.


Really ? I picked up the first drive I could lay my hands on.

Seagate ST380011A IDE 80GB and it has a 25P05AV on it. I needed a
magnifying glass to get the part number off it.

http://media.digikey.com/photos/Numo...P05-AVMN6T.JPG

Look next to the controller chip, for an 8 pin DIP. It is an
EEPROM (electrical erasable) with a serial SPI interface.


So not an EPROM then (no erase window)

http://search.digikey.com/scripts/Dk...=497-1621-1-ND

(PDF datasheet here. Can't find it on st.com or Numonyx.)

100,000 Erase/Program Cycles.


It's not an EEPROM either. It's actually a FLASH memory chip and not a very
large one at that. Not really large enough to hold drive firmware (by
today's standards) but amply large enough to hold the drive parameters that
tell the rest of the controller how this drive is different to the others in
the range.

http://www.alldatasheet.com/datashee...M25P05-AV.html

Either a controller has EEPROM inside, or in this case, a pretty small
chip next to the controller, has the goods. The space is 64K x 8
or 64KB (512 kilobit), which is plenty to code up either a bootstrap
loader
or to hold an entire controller code. Twenty years ago, we did this
in 4KB (and we had room left over). So I don't see 64KB being a problem,
either way (bootstrap or the whole thing). There is no GUI and no .NET in
there :-)

This doesn't resolve your current discussion, about what is
held on "track -1", so carry on debating... There are web pages
that discuss the contents of that area of the platters, but who
do you believe. The story could easily change with each generation
of disk. What was true yesterday, could be false tomorrow.


If you have an old, but working, redundant drive that you no longer have a
use for, take the cover off the hard drive part. Now if you power it up,
you can watch the read/write head reading the 'firmware' off the drive
platters before the drive is available for use. If you put a 'scope on the
output of the sense amplifier (assuming you can find it) you can see the
code being read.

M.I.5¾ wrote:


If you have an old, but working, redundant drive that you no longer have a
use for, take the cover off the hard drive part. Now if you power it up,
you can watch the read/write head reading the 'firmware' off the drive
platters before the drive is available for use. If you put a 'scope on the
output of the sense amplifier (assuming you can find it) you can see the
code being read.

We can't really answer the question with any certainty, if the docs
for the chips aren't available for public consumption. I took the
nine digit number off my hard drive microcontroller chip, and that
didn't dig up any docs. A site called hddworld had a variety of
nine digit number chips listed. I also found some web sites dealing
in left over inventory, who seemed to have some of them. If they were
custom ROM masks, they shouldn't have escaped into the hands of jobbers.

It could be, that these are mask ROM chips. Could be. There is no
way to know for sure, unless ST.com (SGS Thompson) admits to making them in
some way.

A 64KB EEPROM would be big enough to hold a bootstrap code.
Or a bootstrap could be held inside the microcontroller, in
mask ROM (where only the top mask need be applied to establish
a bit pattern, when manufacturing them). I don't see an easy way
to prove this one way or another, due to the lack of public
documentation.

So what can I say ?

1) I'll assume there is a general purpose micro inside the
controller chip. This gives maximum flexibility in any case.
There is no benefit to making the thing entirely hard wired
logic, especially as the ATA command set is complex, and
a programmable device gives the flexibility needed to interpret
those commands.

2) A microcontroller cannot run without *some* code. The code
cannot be fetched entirely from the platter. The microcontroller
doesn't know how to program the motor controller IC, to start
accelerating the platter. So some code is needed prior to
reading the first byte off the platter.

3) At least some initial code ("bootstrap" code) should be stored
on the PCB. On one of my broken hard drives, where the heads were
gone, the microcontroller reported a hard drive model of "Falcon"
and said my drive was "10GB". In fact the drive had a proper model
number (a Maxtor drive), and the capacity was 40GB. So the PCB
itself was responsible for reporting "Falcon" and "10GB".
That to me suggests that some code is stored on the PCB. In terms
of technology choices, mask ROM inside the chip could be used
to store an initial program. Or, an SPI chip (similar to those
used on the newest motherboards), could be used. But without
some docs, I don't see a way to say definitely how it is done.

(Picture of one of those 9 digit ST chips.)

http://www.techarp.com/showarticle.a...tno=302&pgno=3

(An instance of Maxtor and "Falcon". Sure, this says code is stored
in the system area. I don't argue that it isn't possible. But something
must be used to prepare the microcontroller to be able to read the
system area, and that means bootstrap code on the controller board
itself.) And 64K is enough to do that.

http://www.easyrecovery.ie/datarecov...A+133+HDD.html

If the 64KB device was used for parameter storage

1) It is a slow part, with a serial interface. If you were storing
parameters in it, you might not have power long enough to finish.

2) If it has 100K cycle write rating, and the disk has a minimum
50000 start/stop cycle rating, you run the risk of wearing it
out, if it is written each time the drive was powered. The industry
boiler plate rating is 50000 cycles, meaning most drives can
complete more cycles than that.

It makes more sense for it to hold code, or relatively static
parameters. Things like bad blocks, make more sense to hold in
the system area (track -1).

Paul

M.I.5¾ wrote:


If you have an old, but working, redundant drive that you no longer have a
use for, take the cover off the hard drive part. Now if you power it up,
you can watch the read/write head reading the 'firmware' off the drive
platters before the drive is available for use. If you put a 'scope on the
output of the sense amplifier (assuming you can find it) you can see the
code being read.

We can't really answer the question with any certainty, if the docs
for the chips aren't available for public consumption. I took the
nine digit number off my hard drive microcontroller chip, and that
didn't dig up any docs. A site called hddworld had a variety of
nine digit number chips listed. I also found some web sites dealing
in left over inventory, who seemed to have some of them. If they were
custom ROM masks, they shouldn't have escaped into the hands of jobbers.

It could be, that these are mask ROM chips. Could be. There is no
way to know for sure, unless ST.com (SGS Thompson) admits to making them in
some way.

A 64KB EEPROM would be big enough to hold a bootstrap code.
Or a bootstrap could be held inside the microcontroller, in
mask ROM (where only the top mask need be applied to establish
a bit pattern, when manufacturing them). I don't see an easy way
to prove this one way or another, due to the lack of public
documentation.

So what can I say ?

1) I'll assume there is a general purpose micro inside the
controller chip. This gives maximum flexibility in any case.
There is no benefit to making the thing entirely hard wired
logic, especially as the ATA command set is complex, and
a programmable device gives the flexibility needed to interpret
those commands.

2) A microcontroller cannot run without *some* code. The code
cannot be fetched entirely from the platter. The microcontroller
doesn't know how to program the motor controller IC, to start
accelerating the platter. So some code is needed prior to
reading the first byte off the platter.

3) At least some initial code ("bootstrap" code) should be stored
on the PCB. On one of my broken hard drives, where the heads were
gone, the microcontroller reported a hard drive model of "Falcon"
and said my drive was "10GB". In fact the drive had a proper model
number (a Maxtor drive), and the capacity was 40GB. So the PCB
itself was responsible for reporting "Falcon" and "10GB".
That to me suggests that some code is stored on the PCB. In terms
of technology choices, mask ROM inside the chip could be used
to store an initial program. Or, an SPI chip (similar to those
used on the newest motherboards), could be used. But without
some docs, I don't see a way to say definitely how it is done.

(Picture of one of those 9 digit ST chips.)

http://www.techarp.com/showarticle.a...tno=302&pgno=3

(An instance of Maxtor and "Falcon". Sure, this says code is stored
in the system area. I don't argue that it isn't possible. But something
must be used to prepare the microcontroller to be able to read the
system area, and that means bootstrap code on the controller board
itself.) And 64K is enough to do that.

http://www.easyrecovery.ie/datarecov...A+133+HDD.html

If the 64KB device was used for parameter storage

1) It is a slow part, with a serial interface. If you were storing
parameters in it, you might not have power long enough to finish.

2) If it has 100K cycle write rating, and the disk has a minimum
50000 start/stop cycle rating, you run the risk of wearing it
out, if it is written each time the drive was powered. The industry
boiler plate rating is 50000 cycles, meaning most drives can
complete more cycles than that.

It makes more sense for it to hold code, or relatively static
parameters. Things like bad blocks, make more sense to hold in
the system area (track -1).

Paul

"Paul" wrote in message ...
M.I.5¾ wrote:


If you have an old, but working, redundant drive that you no longer have
a use for, take the cover off the hard drive part. Now if you power it
up, you can watch the read/write head reading the 'firmware' off the
drive platters before the drive is available for use. If you put a
'scope on the output of the sense amplifier (assuming you can find it)
you can see the code being read.

We can't really answer the question with any certainty, if the docs
for the chips aren't available for public consumption. I took the
nine digit number off my hard drive microcontroller chip, and that
didn't dig up any docs. A site called hddworld had a variety of
nine digit number chips listed. I also found some web sites dealing
in left over inventory, who seemed to have some of them. If they were
custom ROM masks, they shouldn't have escaped into the hands of jobbers.

It could be, that these are mask ROM chips. Could be. There is no
way to know for sure, unless ST.com (SGS Thompson) admits to making them
in
some way.

A 64KB EEPROM would be big enough to hold a bootstrap code.
Or a bootstrap could be held inside the microcontroller, in
mask ROM (where only the top mask need be applied to establish
a bit pattern, when manufacturing them). I don't see an easy way
to prove this one way or another, due to the lack of public
documentation.

So what can I say ?

1) I'll assume there is a general purpose micro inside the
controller chip. This gives maximum flexibility in any case.
There is no benefit to making the thing entirely hard wired
logic, especially as the ATA command set is complex, and
a programmable device gives the flexibility needed to interpret
those commands.

2) A microcontroller cannot run without *some* code. The code
cannot be fetched entirely from the platter. The microcontroller
doesn't know how to program the motor controller IC, to start
accelerating the platter. So some code is needed prior to
reading the first byte off the platter.

3) At least some initial code ("bootstrap" code) should be stored
on the PCB. On one of my broken hard drives, where the heads were
gone, the microcontroller reported a hard drive model of "Falcon"
and said my drive was "10GB". In fact the drive had a proper model
number (a Maxtor drive), and the capacity was 40GB. So the PCB
itself was responsible for reporting "Falcon" and "10GB".
That to me suggests that some code is stored on the PCB. In terms
of technology choices, mask ROM inside the chip could be used
to store an initial program. Or, an SPI chip (similar to those
used on the newest motherboards), could be used. But without
some docs, I don't see a way to say definitely how it is done.

(Picture of one of those 9 digit ST chips.)

http://www.techarp.com/showarticle.a...tno=302&pgno=3

(An instance of Maxtor and "Falcon". Sure, this says code is stored
in the system area. I don't argue that it isn't possible. But something
must be used to prepare the microcontroller to be able to read the
system area, and that means bootstrap code on the controller board
itself.) And 64K is enough to do that.

http://www.easyrecovery.ie/datarecov...A+133+HDD.html

If the 64KB device was used for parameter storage

1) It is a slow part, with a serial interface. If you were storing
parameters in it, you might not have power long enough to finish.

2) If it has 100K cycle write rating, and the disk has a minimum
50000 start/stop cycle rating, you run the risk of wearing it
out, if it is written each time the drive was powered. The industry
boiler plate rating is 50000 cycles, meaning most drives can
complete more cycles than that.

It makes more sense for it to hold code, or relatively static
parameters. Things like bad blocks, make more sense to hold in
the system area (track -1).


I agree that there would at least need to be some bootstrap code to tell the
microcontroller how to retrieve the main code from the platters. I might
expect this to be in mask ROM inside the microcontroller, but the fashion
these days is moving towards FLASH memory based microcontrollers even if
there is no intention to reprogram it. This is now more cost effective than
mask ROM poducts unless very huge numbers of products are required.

The other advantage of FLASH based controllers is if a bug is found after
the controllers have been programmed, where FLASH is easy to recover whereas
mask ROM is basically junk.

"Paul" wrote in message ...
M.I.5¾ wrote:


If you have an old, but working, redundant drive that you no longer have
a use for, take the cover off the hard drive part. Now if you power it
up, you can watch the read/write head reading the 'firmware' off the
drive platters before the drive is available for use. If you put a
'scope on the output of the sense amplifier (assuming you can find it)
you can see the code being read.

We can't really answer the question with any certainty, if the docs
for the chips aren't available for public consumption. I took the
nine digit number off my hard drive microcontroller chip, and that
didn't dig up any docs. A site called hddworld had a variety of
nine digit number chips listed. I also found some web sites dealing
in left over inventory, who seemed to have some of them. If they were
custom ROM masks, they shouldn't have escaped into the hands of jobbers.

It could be, that these are mask ROM chips. Could be. There is no
way to know for sure, unless ST.com (SGS Thompson) admits to making them
in
some way.

A 64KB EEPROM would be big enough to hold a bootstrap code.
Or a bootstrap could be held inside the microcontroller, in
mask ROM (where only the top mask need be applied to establish
a bit pattern, when manufacturing them). I don't see an easy way
to prove this one way or another, due to the lack of public
documentation.

So what can I say ?

1) I'll assume there is a general purpose micro inside the
controller chip. This gives maximum flexibility in any case.
There is no benefit to making the thing entirely hard wired
logic, especially as the ATA command set is complex, and
a programmable device gives the flexibility needed to interpret
those commands.

2) A microcontroller cannot run without *some* code. The code
cannot be fetched entirely from the platter. The microcontroller
doesn't know how to program the motor controller IC, to start
accelerating the platter. So some code is needed prior to
reading the first byte off the platter.

3) At least some initial code ("bootstrap" code) should be stored
on the PCB. On one of my broken hard drives, where the heads were
gone, the microcontroller reported a hard drive model of "Falcon"
and said my drive was "10GB". In fact the drive had a proper model
number (a Maxtor drive), and the capacity was 40GB. So the PCB
itself was responsible for reporting "Falcon" and "10GB".
That to me suggests that some code is stored on the PCB. In terms
of technology choices, mask ROM inside the chip could be used
to store an initial program. Or, an SPI chip (similar to those
used on the newest motherboards), could be used. But without
some docs, I don't see a way to say definitely how it is done.

(Picture of one of those 9 digit ST chips.)

http://www.techarp.com/showarticle.a...tno=302&pgno=3

(An instance of Maxtor and "Falcon". Sure, this says code is stored
in the system area. I don't argue that it isn't possible. But something
must be used to prepare the microcontroller to be able to read the
system area, and that means bootstrap code on the controller board
itself.) And 64K is enough to do that.

http://www.easyrecovery.ie/datarecov...A+133+HDD.html

If the 64KB device was used for parameter storage

1) It is a slow part, with a serial interface. If you were storing
parameters in it, you might not have power long enough to finish.

2) If it has 100K cycle write rating, and the disk has a minimum
50000 start/stop cycle rating, you run the risk of wearing it
out, if it is written each time the drive was powered. The industry
boiler plate rating is 50000 cycles, meaning most drives can
complete more cycles than that.

It makes more sense for it to hold code, or relatively static
parameters. Things like bad blocks, make more sense to hold in
the system area (track -1).


I agree that there would at least need to be some bootstrap code to tell the
microcontroller how to retrieve the main code from the platters. I might
expect this to be in mask ROM inside the microcontroller, but the fashion
these days is moving towards FLASH memory based microcontrollers even if
there is no intention to reprogram it. This is now more cost effective than
mask ROM poducts unless very huge numbers of products are required.

The other advantage of FLASH based controllers is if a bug is found after
the controllers have been programmed, where FLASH is easy to recover whereas
mask ROM is basically junk.