On Fri, Feb 08, 2002 at 07:12:43PM -0800, Chuck McManis wrote:
> 	2) I need a VMS program that can dump the flash into a binary file (I can 
> probably cons up one on NetBSD to write it out.) I've got licenses for all 
> the compilers so source code is ok (even COBOL ;-)

This worked on my 4k60:

Run: tip |tee cons.log
Then enter: EX/P/L/U/N:20000 20040000
And find something else to do while it dumps over 9600bps.

More ethusiastic ways would be the console "X" command, or writing a
small driver to copy the memory out a device.

> 	3) While $37 (actually $45 w tax etc) isn't a huge investment risk, I'd 
> like to figure out if there is some way to "test" this without actually 
> writing the flash. After all, its a pain in the but to re-flash via a 
> remote pod.
> 
If the OS was able to diddle in the firmware, it stands to reason it
can set things right as well. A diff of dumps and a few deposit commands
may be able to set things right again. Or at least isolating the cause
would allow others to avoid this.

If you do undertake to submit the machine to the corruption, I suggest
scattering asm("halt"); across various portions of /boot, early kernel
bootstrap, and autoconf, to narrow down just where the problem occurs.
i.e., boot up to a halt, power cycle, check for damage, reboot,
continue past checked halts, repeat.

I believe the probe most suspected to have been responsible was dz
at 0x200a0000 (apparently towards of the end of the 512KB firmware on
these machines), and avoiding writing there on NVAX's seems prudent
whether it turns out to have been responsible or not!

/Hugh

> --Chuck
>