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

Re: DEC 3000 problems


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.


Peter (p2).

Attachment: signature.asc
Description: Digital signature

Reply to: