Hi, First, the second flash is mapped at 0x1.a000.0000, not at 0x1.e000.0000 as I posted in my first mail. > > 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. > They certainly have similarities yes. > 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...) > Looking at the 2 prom regions, 1 seems to be empty (the one at 0x1.8000.0000) and contains data (the one at 0x1.a000.0000). Can someone with a working DEC 3000 verify this ? (exa 180000000 -N:32 and exa 1a0000000 -N:32) I don't think they are interleaved like on the VAX. > 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. > That's why I wanted to load a program in memory using DEPOSIT commands and run the program using the START command. This program would then download a new firmware image and flash it. > 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. I'm afraid I don't have the soldering skills to desolder QFPs properly. > - 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/) > Good idea. Cheers, Peter (p2).
Attachment:
signature.asc
Description: Digital signature