[jwhat]

Hi SGI'ers,

as part of Dallas DS1742W chip initialisation/swapping Khral posted on how he used TL866 MiniPro programmer to read a valid Tezro's DS1742W chip and and then used this dump to restore/initialise a new Dallas chip.

This helps bypass the entire Dallas initialisation problem, as you can now plug in the Dallas with restored configuration and then use l1 interface (either via l1cmd if your machines boots or l2 controller) to reset the machines serial back to the correct machine specific value.

I have now done some additional testing with the TL866A on a number of Dallas chips.

For those who want to test this stuff first be aware that TL866 is officially made by: XGecu (www.autoelectric.cn).
On their web site they indicate that the TL866A/CS variation is now "End of Life" and that the device to get is "TL866II Plus". This supports Dallas (as DS1220 which is NVRAM version only without RTC like the DS1742W). The new version also supports many more additional chips than the TL866A/CS version.

I did test reads of DS1742W-120 chips taken out of real SGI equipment and these all read/write ok, with caveat that they will get verification failures at address: 07F8 . This is in range where the RTC stores its values (07F8-07FF), so the values can change between write / read. So when doing write probably best to leave this range out.

I also tested the potentially "fake" ebay sourced DS1742W-120+ chips (see this thread), these fail to verify at different address ranges, which indicates that they are likely manufacturing faulty chips, not total fakes.

Having the programmer means it is easy to test any sourced Dallas chips to verify if they are ok or not and if not working get immediate refund. It is also easy to take readings of RTC to see if this is operating or not by just reading the correct address range.

My next step in testing will be to pull Dallas from Fuel and copy it to good SGI Dallas and then run the Fuel eeprom init on the backup chip to see the result. Now I know I am using backup chip and still have known good chip I think it is safe to try this to see if this helps with L1 issues I have been having with my Fuel.

Hope this is helpful info to others with Dallas DS1742W issues and thank you Khral for the testing with the TL866 EEPROM programmer.

Cheers from Oz,


John.

[weblacky]

Yo,
Two things to check for us if you can (using datasheet): https://datasheets.maximintegrated.com/en/ds/DS1742.pdf

With chips you get from eBay that you determine are genuine.

1. The datasheet (Pg 4-5) claims you can STOP the oscillator with MSB Bit 7 @ address 7F8 = 1 (try this and see if your read/verify works, since time won't change afterwards)!!
This will stop the RTC and also prolong whatever battery life you have left (if you intent to get the module, test, and store it). It's not the same as factory fresh storage, but it's LESS drain then keeping the clock going. Frequency test bit can tell you if it's running or not...don't know if it will auto-enable in socket insertion so you MAY have to turn it back on before you insert into Tezro?

2. Battery monitor - The RTC has a bit in registers to show you if battery is good or bad (not a percentage or anything, just an idiot light). Page 7 - MSB @ Address 7FC = 1 when good, 0 when dead/missing.

Those are the only cool features, but useful to know if the battery is still good and to force it into "Storage mode" to prolong shelf-life after initial activation.


Thanks,

[jwhat]

Hi Weblacky,

I did not do a clock test yet, but run this set of tests.

Test 1: Copy NVRAM from one Dallas to another

a. Pull and dump DS1742W-120 from working Fuel and then write this back onto another DS1742W-120 that was out of Numalink or ATI Graphics Chassis (Onyx4 UltimateVision) .
b. Install backup DS1742W-120 back into Fuel and reboot
c. Result was all good, as per Khral testing, Fuel booted up and beyond having to first boot into single user mode to reset the time (due to failing Snaphat) booted up fine.

NOTE: This was using a Dallas chip that I had previously tried in the Fuel without success. So this proves that invalid data content in NVRAM will cause Fuel boot failure.

Test 2: - Try "eeprom Fuel write default" via L2

a. Using the backup Dallas and L2 controller via Fuel l1 USB port try to do a "l1 eeprom Fuel write default"
b. Result: Error saying EEPROM already contains data:

>> ?-192.168.XXX.XXX-L2>l1 eeprom Fuel write default
>> 001a01:
?? MAC EEPROM already contains valid data
>> ?-192.168.XXX.XXX-L2>l1 eeprom
>> 001a01:

So Fuel L1 will not allow you to re-initialise an already initialised Dallas

Test 3: Put a cleared Dallas into Fuel and try the "eeprom Fuel write default"

a. Using programmer clear Dallas by programming with "0F" for all ram with exception of RTC clock data area
b. Put cleared Dallas into Fuel and monitor via L2
c. Via L2 try: "l1 eeprom Fuel write default"
d. Result: get same error as Test 2 ... which is unexpected, having just cleared the chip.
e. Do a check of EEPROM via l2 and surprising it looks like it has valid data including a serial no, it shows that it has already got valid MAC based serial number:

>> ?-192.168.XXX.XXX-L2>l1 eeprom Fuel write default
>> 001a01:
>> MAC EEPROM already contains valid data
...
>> ?-192.168.XXX.XXX-L2>l1 serial
>> 001a01:
>> BSN: MSM019    SSN: 08:00:69:10:52:A1    Time: 02/07/2106 06:28:15    Security: OFF
>> Public Key data in EEPROM is invalid

f. So I checked the L1 logs and found that the Fuel had automatically already initialised the new blank chip.

>> ?-192.168.XXX.XXX-L2>l1 log
>> 001a01:
>> 02/07/06 06:28:15 checksum Error - common header initialized
>> 02/07/06 06:28:15 nvram checksum error - initializing core data.
>> 02/07/06 06:28:15 nvram checksum error - initializing extended data.
>> 02/07/06 06:28:15 nvram checksum error - log pointers invalid, log pointers reset
>> 02/07/06 06:28:15 L1 booting 1.48.1
>> 02/07/06 06:28:15 NVRAM doesn't match EEPROM

So I rebooted Fuel and aside from same issue with having to first go into single user mode to reset the Snaphat clock the machine rebooted perfectly once this was done.

NOTE: I also had to reset the Dallas Clock setting via L2, as time was obviously wrong.

So my conclusion is that there is no need to ever use the fuel: "eeprom Fuel write default" l1 command as the Fuel appears to do the Dallas initialisation perfectly well anyway if you put a cleared / clean Dallas into it. It maybe that the Fuel will let you run this command if you are putting a Dallas into it that has come from other machine (such as Tezro).

So Fuel appears to be a valid way to initialise chips, but alternative of just copying a valid Fuel configuration via EEPROM programmer is an option as well.

Now back to waiting for Snaphats to arrive...

I will try to test the Clock updates on the weekend, as well as seeing if O350 will take a valid Fuel DS1742W as starting point for fixing O350 with expired Dallas.

Cheers from Oz,


John.

[weblacky]

Very interesting. Good idea to blank with the programmer to retry some steps (good coverage). I would guess then with a modded chip a fuel owner would never need to keep an RTC backup image around because the lack of battery power would blank it and the Fuel will initialize it automatically. The only one you showed that was problem was a RTC with old contents. A very real scenario for an eBay buy, but an unrealistic scenario for a modded RTC.

Good confirmation, that at least shows Fuel isn’t going to be a problematic system during RTC failure.

[jwhat]

Hi Weblacky and others,

I have now done test with Numalink Router and cleared Dallas:

1. Put cleared Dallas (filled with "0F") into Numalink Router and power it up
2. Initialised Rack / Slot configuration and do L1 reboot
3. Check serial and run the undocumented "let the carnage begin" l1 command
4. Rechecked serial and log

Summary:
You can put new Dallas into Numalink router and it will auto initialise just like the Fuel.
And you can disable the serial security and clear serial using the "let the carnage begin" l1 command.

Here is interaction log:

>> SGI L2 Controller
>> Current L2 version: 1.62.0
>> 
>> INFO: opened USB control /dev/sgil1_cs
>> INFO: SMP listening on port: 8001
>> INFO: SMP listening on port: 8003
>> ?-192.168.XXX.XXX-L2>INFO: opened USB device at b1;p2/0;d3 (/dev/sgil1_0)
>> 
>> ?-192.168.XXX.XXX-L2>config
>> L2 192.168.XXX.XXX: - ---- (no rack ID set) (LOCAL)
>> L1 192.168.XXX.XXX:0:0  - ---r-- (no rack and slot ID set)
>> ?-192.168.XXX.XXX-L2>192.168.XXX.XXX:0:0 brick rackslot 1 7
>> 000r00:
>> brick rack set to 001 (takes effect on next L1 reboot/power cycle)
>> brick slot set to  07 (takes effect on next L1 reboot/power cycle)
>> ?-192.168.XXX.XXX-L2>192.168.XXX.XXX:0:0 reboot_l1
>> ?-192.168.XXX.XXX-L2>INFO: closed connection to 000r00
>> INFO: opened USB device at b1;p2/0;d4 (/dev/sgil1_0)
>> 
>> ?-192.168.XXX.XXX-L2>config
>> L2 192.168.XXX.XXX: - ---- (no rack ID set) (LOCAL)
>> L1 192.168.XXX.XXX:0:0  - 001r07
>> ?-192.168.XXX.XXX-L2>l1 serial
>> 001r07:
>> BSN: NYY856    SSN:    Time: 10/31/2020 18:20:33
>> ?-192.168.XXX.XXX-L2>serial all
>> 001r07:
>> 
>> Data                            Location      Value
>> ------------------------------  ------------  --------
>> Local System Serial Number      NVRAM          not set
>> Reference System Serial Number  NVRAM
>> Local Brick Serial Number      EEPROM        NYY856
>> Reference Brick Serial Number  NVRAM        NYY856
>> 
>> 
>> EEPROM      Product Name    Serial        Part Number          Rev  T/W
>> ----------  --------------  -------------  --------------------  ---  ------
>> POWER      RPWR            NYY856        030_1631_004          C    00
>> LOGIC      ROUTER          NXA065        030_1634_004          C    00
>> 
>> ?-192.168.XXX.XXX-L2>l1 let the carnage begin
>> ?-192.168.XXX.XXX-L2>l1 serial
>> 001r07:
>> BSN: NYY856    SSN:    Time: 10/31/2020 18:21:09    Security: OFF
>> ?-192.168.XXX.XXX-L2>l1 serial clear
>> ?-192.168.XXX.XXX-L2>l1 serial
>> 001r07:
>> BSN: NYY856    SSN: L0000000    Time: 10/31/2020 18:21:30    Security: OFF
>> ?-192.168.XXX.XXX-L2>power up
>> ?-192.168.XXX.XXX-L2>power down
>> ?-192.168.XXX.XXX-L2>l1 log
>> 001r07:
>> 10/31/20 18:16:44 checksum Error - common header initialized
>> 10/31/20 18:16:44 nvram checksum error - initializing core data.
>> 10/31/20 18:16:45 nvram checksum error - initializing extended data.
>> 10/31/20 18:16:45 nvram checksum error - log pointers invalid, log pointers
>> reset

So more and more it is looking like the machines auto-initialise the Dallas as long as it is cleared.
I will try O350 with cleared Dallas next.

Cheers from Oz,


John

[jwhat]

Hi Weblacky & others,

here is my final test with cleared Dallas on O350.

Same basic steps:

1. Put cleared Dallas (filled with "0F") into O350 and power it up
2. Initialised Rack / Slot configuration and do L1 reboot
3. Check serial and log

Summary:
You can put new Dallas into any of: Fuel, Numalink Router, O350 & Tezro  and it will auto initialise.
Use L2 with valid serial to put valid serials on O350 & Numalink machines while for Fuel & Tezro you can manually set these if you want.

Here is interaction log:

>> SGI L2 Controller
>> Current L2 version: 1.62.0
>> 
>> INFO: opened USB control /dev/sgil1_cs
>> INFO: SMP listening on port: 8001
>> INFO: SMP listening on port: 8003
>> M200XXXX-192.168.XXX.XXX-L2>INFO: opened USB device at b1;p0;d2 (/dev/sgil1_0)
>> 000?00 INFO: System serial number reassigned (8000) to M200XXXX from attached L2.
>> 
>> M200XXXX-192.168.XXX.XXX-L2>config
>> L2 192.168.XXX.XXX: - ---- (no rack ID set) (LOCAL)
>> L1 192.168.XXX.XXX:0:0  - ---c-- (no rack and slot ID set)
>> M200XXXX-192.168.XXX.XXX-L2>192.168.XXX.XXX:0:0 brick rackslot 1 7
>> 000c00:
>> brick rack set to 001 (takes effect on next L1 reboot/power cycle)
>> brick slot set to  07 (takes effect on next L1 reboot/power cycle)
>> M200XXXX-192.168.XXX.XXX-L2>192.168.XXX.XXX:0:0 reboot_l1
>> M200XXXX-192.168.XXX.XXX-L2>INFO: closed connection to 000c00
>> INFO: opened USB device at b1;p0;d3 (/dev/sgil1_0)
>> config
>> L2 192.168.XXX.XXX: - ---- (no rack ID set) (LOCAL)
>> L1 192.168.XXX.XXX:0:0  - 001c07
>> M200XXXX-192.168.XXX.XXX-L2>l1 serial
>> 001c07:
>> BSN: NAL684    SSN: M200XXXX    Time: 11/01/2020 23:43:55
>> M200XXXX-192.168.XXX.XXX-L2>l1 log
>> 001c07:
>> 11/01/20 23:41:34 checksum Error - common header initialized
>> 11/01/20 23:41:34 nvram checksum error - initializing core data.
>> 11/01/20 23:41:34 nvram checksum error - initializing extended data.
>> 11/01/20 23:41:34 nvram checksum error - log pointers invalid, log pointers reset
>> 11/01/20 23:41:34 L1 booting 1.44.0
>> 11/01/20 23:41:34 ChiServ IP59
>> 11/01/20 23:41:34 Checking for Type
>> 11/01/20 23:41:34  -- ChiServ Type set
>> 11/01/20 23:41:36 ** fixing invalid SSN value
>> 11/01/20 23:41:36 ** fixing BSN mismatch
>> 11/01/20 23:41:36 USB0: waiting on open
>> 11/01/20 23:41:41 USB0: opened
>> 11/01/20 23:41:41 USB0: registered for events
>> 11/01/20 23:41:42 INFO: System serial number reassigned (8000) to M200XXXX from attached L2.
>> 11/01/20 23:43:37 L1 booting 1.44.0
>> 11/01/20 23:43:37 ChiServ IP59
>> 11/01/20 23:43:37 Checking for Type
>> 11/01/20 23:43:37  -- ChiServ Type set
>> 11/01/20 23:43:40 USB0: waiting on open
>> 11/01/20 23:43:41 USB0: opened
>> 11/01/20 23:43:41 USB0: registered for events
>> M200XXXX-192.168.XXX.XXX-L2>serial all
>> 001c07:
>> 
>> Data                            Location      Value
>> ------------------------------  ------------  --------
>> Local System Serial Number      NVRAM        M200XXXX
>> Reference System Serial Number  Attached L2  M200XXXX
>> Local Brick Serial Number      EEPROM        NAL684
>> Reference Brick Serial Number  NVRAM        NAL684
>> 
>> 
>> EEPROM      Product Name    Serial        Part Number          Rev  T/W
>> ----------  --------------  -------------  --------------------  ---  ------
>> INTERFACE  2U_INT_53      NAL684        030_1809_003          B    00
>> IO9        IO9            NAJ955        030_1771_005          A    00
>> ODYSSEY    no hardware detected
>> RISER      2U_RISER        NBD099        030_1808_005          A    00
>> NODE        IP59_4CPU      RBS625        030_1989_003          C    00
>> SNOWBALL    no hardware detected
>> PS 1        no hardware detected
>> PS 2        DPS-500EBE      XPD0513004325  060-0178-003          S4
>> 
>> EEPROM    JEDEC-SPD Info          Part Number        Rev  Speed  SGI
>> ---------- ------------------------ ------------------ ---- ------ --------
>> DIMM 0    CE000000000000000CDBD500 M3 46L2820ET3-CA0  3E  10.0  N/A
>> DIMM 2    CE000000000000000CD3D500 M3 46L2820ET3-CA0  3E  10.0  N/A
>> DIMM 4    CE000000000000000C209800 M3 46L2820DT2-CA0  2D  10.0  N/A
>> DIMM 6    CE000000000000000C2B9800 M3 46L2820DT2-CA0  2D  10.0  N/A
>> DIMM 1    CE000000000000000C549800 M3 46L2820DT2-CA0  2D  10.0  N/A
>> DIMM 3    CE000000000000000CDFD500 M3 46L2820ET3-CA0  3E  10.0  N/A
>> DIMM 5    CE000000000000000CD0D500 M3 46L2820ET3-CA0  3E  10.0  N/A
>> DIMM 7    CE000000000000000C379800 M3 46L2820DT2-CA0  2D  10.0  N/A
>> 
>> M200XXXX-192.168.XXX.XXX-L2>power up
>> 001c07 INFO: PIMM type changed, setting the default voltage margins
>> M200XXXX-192.168.XXX.XXX-L2>
>> M200XXXX-192.168.XXX.XXX-L2>
>> entering system console mode (001c07 CPU0), <CTRL_T> to escape to L2
>> Starting PROM Boot process
>> 
>> 
>> IP35 PROM SGI Version 6.210  built 02:33:51 PM Aug 26, 2004
>> Testing/Initializing memory ...............            DONE
>> Copying PROM code to memory ...............            DONE
>> Discovering local IO ......................            DONE
>> Discovering NUMAlink connectivity .........
>> Local hub NUMAlink is down.
>> *** Local network link down
>> DONE
>> Found 1 objects (1 hubs, 0 routers) in 5886 usec
>> Waiting for peers to complete discovery....            DONE
>> No other nodes present; becoming global master
>> Global master is /hw/rack/001/bay/07
>> Intializing any CPUless nodes..............            DONE
>> *** Nasid 0: Memory bank 2 was previously Absent but is now Present & Enabled
>> *** Nasid 0: Memory bank 3 was previously Absent but is now Present & Enabled
>> *** Nasid 0: Memory bank 4 was previously Absent but is now Present & Enabled
>> *** Nasid 0: Memory bank 5 was previously Absent but is now Present & Enabled
>> *** Nasid 0: Memory bank 6 was previously Absent but is now Present & Enabled
>> *** Nasid 0: Memory bank 7 was previously Absent but is now Present & Enabled
>> *** Nasid 0: Memory bank 0 previously had 512 MB but now has 1024 MB
>> *** Nasid 0: Memory bank 1 previously had 512 MB but now has 1024 MB
>> *** Nasid 0: Memory bank 2 previously had 0 MB but now has 1024 MB
>> *** Nasid 0: Memory bank 3 previously had 0 MB but now has 1024 MB
>> *** Nasid 0: Memory bank 4 previously had 0 MB but now has 1024 MB
>> *** Nasid 0: Memory bank 5 previously had 0 MB but now has 1024 MB
>> *** Nasid 0: Memory bank 6 previously had 0 MB but now has 1024 MB
>> *** Nasid 0: Memory bank 7 previously had 0 MB but now has 1024 MB
>> Checking partitioning information .........            DONE
>> No other nodes present; becoming partition master
>> Local slave entering slave loop
>> Local slave entering slave loop
>> Local slave entering slave loop
>> Loading BASEIO prom .......................            DONE
>> 
>> BASEIO PROM Monitor SGI Version 6.210  built 02:30:38 PM Aug 26, 2004 (BE64)
>> 4 CPUs on 1 nodes found.
>> Automatic update of PROM environment disabled
>> Graphics diagnostics
>> 
>> ***WARNING: Master I-brick was /hw/module/001c01/iobrick but is now /hw/module/001c07/iobrick
>> Check for LINK errors or setenv ConsolePath to new value.
>> Installing PROM Device drivers ............
>> On-board (IO9) tigon3 1000BaseT interface
>> Base I/O Ethernet set to /dev/ethernet/tg0
>> Installing Graphics Console...
>> graphics install: searching for pipe 0
>> klgraphics: System has no GFX
>> Probing IOC4 ATA adapter 2
>> IOC4 RevId = 79
>> 
>> Walking SCSI Adapter 0, (pci id 3)
>> 1+ Device Vendor Product: COMPAQ BF14689BC5
>> 2+ Device Vendor Product: SGI ST373307LC
>> 3- 4- 5- 6- 7- 8- 9- 10- 11- 12- 13- 14- 15- = 2 device(s)
>> 
>> 
>> Walking SCSI Adapter 1, (pci id 3)
>> 1- 2- 3- 4- 5- 6- 7- 8- 9- 10- 11- 12- 13- 14- 15- = 0 device(s)
>> 
>> Initializing PROM Device drivers ..........
>>  Initializing Base I/O Ethernet Interface...Failed.  MII Status Register = 0x7949
>> Done.
>>  ---------------Interface Configuration Summary----------------
>>  ASIC|Revision|MAC Address      : 5701|B5|08:00:69:13:eb:30
>>  Link Negotiation|Advertisement  : On|<H10 F10 H100 F100 F1000>
>>  Link|Speed|Duplex|Rx/Tx FlowCtrl: Down|10|Half|Off/Off
>>  --------------------------------------------------------------
>> DONE
>> Cannot connect to keyboard -- check the cable.
>> Cannot open /dev/input/ioc4pckm0 for input
>> Cannot connect to keyboard -- check the cable.
>> Cannot open /dev/input/ioc4pckm0 for input
>> Checking hardware inventory ...............
>> ***Warning: Board in module 001c07 is missing or disabled
>> It previously contained a New Type board, barcode  laser 0
>>  Found new or re-enabled component PCI DEV 2
>>  Found new or re-enabled component PCI DEV 2
>>  Found new or re-enabled component PCI DEV 2
>> DONE
>> 
>> **** System Configuration and Diagnostics Summary ****
>> CONFIG:
>>          No. of NODEs enabled    = 1
>>          No. of NODEs disabled  = 0
>>          No. of CPUs enabled    = 4
>>          No. of CPUs disabled    = 0
>>          Mem enabled            = 8192 MB
>>          Mem disabled            = 0 MB
>>          No. of RTRs enabled    = 0
>>          No. of RTRs disabled    = 0
>> 
>> DIAG RESULTS:
>>          ALL DIAGS PASSED.
>> **** End System Configuration and Diagnostics Summary ****
>> 
>> 
>> System Maintenance Menu
>> 
>> 1) Start System
>> 2) Install System Software
>> 3) Run Diagnostics
>> 4) Recover System
>> 5) Enter Command Monitor

Full log trace is on my blog.

You can see from log that it has the same "nvram checksum error - initializing core data" sequence as other machines and in this case as I had L2 setup with valid serial number the machine took serial from the L2.

So happy to report you do not need a Fuel to revive your Numalink, Tezro or O350 machines, just properly cleared Dallas chip.

Cheers from Oz,

John.