Seagate ROM regen
- Thread starter pclab
- Start date
nader_21007
New member
This is a solution from a guy called Fraser Corrance, Google groups,DataRecoveryCertification :
I have had some success rebuilding the ROM on Seagate drives from the first half of the F3 generation. Grenada and later families don't seem to have these backup copies of the ROM files in the SA. Hepburn, Pharaoh, and Muskie families have the easiest ROMs to rebuild using this method. If you take the PCB from a drive that meets the following matching criteria:
Put the donor PCB on the patient drive and power it up. Read the ROM using The drive should be stuck in BSY and will not come ready. Go to the terminal screen, get a T> prompt and enter r1 to read the backup copy of the RAP from the SA. Open the Service information objects window by pressing Ctrl + Alt +1, select the YModem tab, and press OK. In the new tab that opens, left click anywhere in the HEX data, press Ctrl + A to select all of the HEX data, and control Ctrl + c to copy it to the clipboard. Select the Work with Flash ROM image and read the ROM over boot code. Open the RAP file, left click anywhere in the HEX data, and press Ctrl + v to paste the data from the clipboard into the RAP file, and write the data back to the drive's ROM. Repower the drive and see if it comes RDY. If it does not, you might need to find a donor that is a closer match or possibly repeat the process to recover the patient drive's SAP file using r3F to read it over YModem.
I don't fully remember if the SAP file is 3F in other families so you may want to check the system file directory of your patient drive before moving the PCB to the patient drive.
If you compare drives that meet pretty much the same criteria that you use to match drives containing compatible heads and look through the AFH values for the zone that containing the SA, you will notice that they are pretty much the same. I figure since the SA has a much lower areal density than the UA zones, the AFH values don't need the same degree of fine tuning to get the heads to read it. Once you have access to the SA you will be able to rebuild the ROM used the backup copies.
I have never had any luck at all modifying the ROM of drives from the Brinks family. I am guessing that it probably has something to do with some check sums that probably need to be recalculated after the ROM is modified/repaired.
I have had some success rebuilding the ROM on Seagate drives from the first half of the F3 generation. Grenada and later families don't seem to have these backup copies of the ROM files in the SA. Hepburn, Pharaoh, and Muskie families have the easiest ROMs to rebuild using this method. If you take the PCB from a drive that meets the following matching criteria:
- Model number
- Firmware version
- Country of origin
Put the donor PCB on the patient drive and power it up. Read the ROM using The drive should be stuck in BSY and will not come ready. Go to the terminal screen, get a T> prompt and enter r1 to read the backup copy of the RAP from the SA. Open the Service information objects window by pressing Ctrl + Alt +1, select the YModem tab, and press OK. In the new tab that opens, left click anywhere in the HEX data, press Ctrl + A to select all of the HEX data, and control Ctrl + c to copy it to the clipboard. Select the Work with Flash ROM image and read the ROM over boot code. Open the RAP file, left click anywhere in the HEX data, and press Ctrl + v to paste the data from the clipboard into the RAP file, and write the data back to the drive's ROM. Repower the drive and see if it comes RDY. If it does not, you might need to find a donor that is a closer match or possibly repeat the process to recover the patient drive's SAP file using r3F to read it over YModem.
I don't fully remember if the SAP file is 3F in other families so you may want to check the system file directory of your patient drive before moving the PCB to the patient drive.
If you compare drives that meet pretty much the same criteria that you use to match drives containing compatible heads and look through the AFH values for the zone that containing the SA, you will notice that they are pretty much the same. I figure since the SA has a much lower areal density than the UA zones, the AFH values don't need the same degree of fine tuning to get the heads to read it. Once you have access to the SA you will be able to rebuild the ROM used the backup copies.
I have never had any luck at all modifying the ROM of drives from the Brinks family. I am guessing that it probably has something to do with some check sums that probably need to be recalculated after the ROM is modified/repaired.