On Sun, 2004-10-17 17:21:23 +0200, Peter 'p2' De Schrijver <p2@mind.be> wrote in message <[🔎] 20041017152123.GB18876@mind.be>: [Corrupted FEPROM on T3000 Alpha machine] > If read the manual correctly, there are 2 flash chips in the system, 1 mapped > at 0x1.8000.0000 and 1 mapped at 0x1.e000.0000. I guess only 1 of those > is corrupted. Is this true ? If so, which one ? Does the SRM code reside > in the same flash or in the other flash ? Ie. if I would erase the > corrupted flash, would I still be able to get to the SRM prompt ? The > reason I ask is that I'm thinking of recovering the flash by writing a > small program I can upload using SRM deposit commands. That program > would then load a correct flash image using xmodem over the console > serial port and write it to the flash. Is this approach doable ? The > only other way I see is to use the SROM mini console port, but I have no > idea how that port works. Well, maybe I can put some hints from the VAX machines on the table. Basically, I think that these early Alphas, the DECstations and the 3100 aren't all that different. On the VAXen, there are typically one to four EPROMs or FEPROMs that are mapped to 0x20040000. These ROMs don't show up one-after-another in the memory region, but alternating. However, ROM checksums are calculated on a per-ROM basis. So I guess that if you erase one (physical) ROM, you actually delete half of the whloe firmware (not the first or second half, but every second byte, word or longword...) Another problem restoring the broken chip's contents (or only the block that's actually broken right now) might be that the FEPROM is used directly (instead of a copy of it's contents to RAM). If you erase one block, you may receive some bad luck and your DEPOSIT command refuses to work... The firmware update package for a VAX 4000m90 gets loaded and then runs independantly, not using the ROM contents while it's actually flashing. I'm now half-way through with the VAX flashing program, maybe (once I'm done with it) the information I get from that will help you... So from here, I guess you've got these alternatives: - Rip off the ROMs (or solder them out) and check (for sure) if the ROMs show up in memory space intermixed or one-after-the-other, and simply re-program them externally. - If they're not intermixed, you may have a chance with DEPOSITing values to flash them. - Could you send me the ROM's contents? Either a firmware updateing program or a EXAMINEd ROM dump would do. DEC did some cool things to their desktop machine's ROMs: they possibly contain some ID bytes at their start (within the first kilobyte IIRC) so you can find out how they're connected to the address decoder. Just use EXAMINE with /n:xxx of write an Alpha backend for the firmware dumper I wrote for my VAXen (it's already prepared for accepting other backends, find it at http://cvs.sourceforge.net/viewcvs.py/linux-vax/usr/firmware_dumper/) As I said, DEPOSITing the new image may be risky, but it's a good chance. If you fsck it up, you still have the chance to solder the ROMs out. (If you don't have a FLASH/EPROM burner, maybe I can help you there, too). However, first get a firmware dump (with physical memory addresses) to find out how bytes are spread between the ROMs if they're intermixed... MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Attachment:
signature.asc
Description: Digital signature