Conference proxy::ftvax

Hi,

some DANGEROUS commands may help you ( if they work on a 610; I tested them
on 310/410 )

on the 310 type : 
>>> T
....
RBD> <esc><del>SET MODEL 610
RBD> <esc><del>SET SERver    ( or NOSERver if multiuser )
RBD> quit
>>> INIT

and try to use it as a 610 CPU with a valid ethernet address

Regards,

		Alain

    Alain,
    
    Thanks for your input and we are currently escalating this to you,
    using the information on ROUTER at our TSC.
    
    What we need to do is re enter the Ethernet address, we have 3 CPUs
    that report Ethernet address not loaded, and we have one CPU that has an
    ethernet address BUT gives us a an EEPROM Invalid header.
    
    Where can we go now???  Please can you help.
    
    Best regards,
    Colin S.

    RE: .2
    
       There are procedures to reload the Ethernet address using commands
    similar to those referenced in .1.  As I recall, it's eight load 
    instructions followed by the correct XFC instruction for the specific
    Model (in your case a 610).  I believe Lee Wolfe documented this pro-
    cedure approximately three years ago.  You might ask him if he retained
    a copy by sending MAIL to PROXY::WOLFE.  
    
    Greg
    

    Here's the procedure as described by Paul Cote in January of 1993:
    
    
             <<< PROXY::WRKD:[NOTES$LIBRARY]VAXFT_SUPPORT.NOTE;1 >>>
                               -< vaxft_support >-
================================================================================
Note 50.1                    Cirrus Ethernet Issues                      1 of 13
RESYNC::PCOTE "So I shot the jury"                   61 lines  19-JAN-1993 11:04
                   -< Ethernet address restoration Document >-
--------------------------------------------------------------------------------


	THIS DOCUMENT HAS BEEN WRITTEN TO AID THE USER IN REINSTALLING
		   EHTERNET ADDRESSES AFTER CORRUPTION

	When replacing a CPU module in a CIRRUS system, It is necessary to
copy the Ethernet address from the old module to the newly installed module, 
or more accurately, from the old zone to the new zone. This is done be issuing 
a NEW CPU command on the zone with the newly installed module. 

	Several problems can occur if the installation is not done correctly
and the E-net address is erased from both zones. E-net data should be copied 
down prior to the installation in case an error occurs. These 8 longword 
addresses can be re-deposited by the process below. This E-net address can 
then be propagated to the other zone by issuing a NEW CPU command from the 
zone that needs updating.

	In the unlikely event that the E-net addresses in both zones have
been corrupted, and the E-net address was never recorded, it will be necessary 
to obtain a new E-net address from SASE. This address will be run through the
ENET_ROM_DATA program to yield the 8 longwords for "direct deposit" from the 
formatted E-net address (XX-XX-XX-XX-XX-XX). ENET_ROM_DATA program can also be
obtained from SASE on request.
 
	In addition to the deposit of the 8 longwords, address location
20000CF8 must be modified. This is the header control word and it should
equal 00030000.

PROCEDURE:

	>>>T/R

		RBD>D 20000CF8 00030000  
		RBD>D 20000D00 1st longword
		RBD>D + 2nd longword
		        .
			.
		RBD>D + 8th longword

	Next the checksum needs to be validated. To do this, R0 must hold
the address of the checksum. For the E-net active area (area 11), the 
address is 20000CF0. R2 must be zero indicating the CPU's EEPROM is to be
modified. These EEPROM addresses are the same for all CIRRUS models.
	The XFC command will load the PC with the first address of the 
validation routine in the diagnostic monitor and start execution. The
validation routine start address is different for the various system
models.
		These are the proper XFC addresses.

		20054EEE	- 310 (KA520)
		20054F99	- 110 (KA520)
		20064628	- 410,610,612 (KA550)

		
	>>>T/R
		RBD>D/G/L 0 20000CF0
		RBD>D/G/L 2 0
		RBD>XFC	XXXXXXXX	(choose proper address above)
		RBD>QUIT

    Hi Greg,
    
    Many thanks for the information, that has allowed us to resolve our
    ethernet address problem.
    
    The system has been rebooted OK.
    
    Again many thanks, to you and Alain.
    
    Regards,
    Colin S.