Fixing the "TOD Clock Bit Error" Problem...

There has been some discussion the the Sun Support forums that

replacing a dead M48T02 or M48T12 NVRAM chip resulted in an error message reading:

       FAILURE:  TOD (f2007fa) Bit Failure, Exp = 000000ff, Obs = 0000007f

An additional message appears later in the boot sequence reading:

               Power-On SelfTest FAILED ... Replace TOD/NVRAM

This message is related to a manufacturing change by ST Microelectronics, the biggest manufacturer of the M48T01/12 chips, as part of Y2K compliance modifications.  ST indicated that while their changes did not change the specifications of the chip, the Y2K version more strictly enforces the specifications, so chip initialization and query programs written to looser adherence the the specs may or may not work with the new version of the chip.

 

This seems to be the case with some PROM versions in older Sun SparcStation boxes.  Depending on ROM version and machine type, some older Sun boxes report these errors with the new rev of the chip.

There are two other symptoms related to these new NVRAM chips:

1) Machines that detect this situation, by design, halt the autoboot process.  While you can manually boot these machines from the PROM's OK prompt, they will not boot automatically after a  power cycle.

2) Even though the new NVRAM chips keep time properly while the machine is running, the value in the display registers of the chip will NOT be properly updated to the UNIX clock because the boot process does not initialize the clock.  The internal clock in the chip runs correctly, but the boot process, thinking the clock chip is faulty, never updates the display registers with the current imbedded clock

values.  The values that get presented to UNIX are the display values that were there the last time the machine was halted.

I have not found a solution for the stopped clock phenomena.  I do have a solution for the autoboot problem.  The solution is to intercept the boot process before normal error checking routines.  Sun has a mechanism built into the PROM to provide to allow for device configuration and option setting.  It the PROM's  nvramrc vraiable.  The nvramrc variable is actually a sequence of PROM commands that are executed before boot and is traditionally used to configure

video adapters, change SCSI settings, device aliases, etc.  But you can build your own boot process within the nvramrc sequence and bypass the error trap preventing the autoboot problem.  The nvramrc sequence I've been using looks like this:

                           probe-all

                           install-console

                           banner

                           boot

What this sequence does, in a nutshell, is to tell the PROM to identify all install devices (probe-all), identify and initiate the appropriate console device (install-console), display the start-up banner messages (banner), and boot the OS on the default boot device (boot).

Need help populating the nvramrc variable?  Then go the nvramrc configuration page.