[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DEC 3000 problems



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


Reply to: