NVRAM Checksum Issue (Solved)
#11
RE: NVRAM Checksum Issue (Solved)
(11-01-2018, 08:55 PM)CB_HK Wrote:  the current configuration is for Channel 0 to run all the SCSI drives (using a loop back connector instead of terminators in the bottom corner). The IO3B connector is attached to a bulkhead port only. When I reverted this layout and split the drive bays, 2 on Channel 0 and 2 on Channel 1, nothing would show on 1.
OK, so channel 1 (external, to bulkhead) is the one that's broken and channel 0 (to all internal drive bays) works? In that case you should be able to use the internal disks, right? or does it fail to POST and just sit there?

I would think twice before risking to destroy an otherwise functional IO3B just to gain a secondary SCSI channel.

NB: I realized later that the picture I posted was an old one from the IO3 of my 4D/380VGX, not the IO3B from the Crimson. The layout is nearly identical, except for a jumper block somewhere.
jan-jaap
SGI Collector

Trade Count: (0)
Posts: 1,048
Threads: 37
Joined: Jun 2018
Location: Netherlands
Website Find Reply
11-02-2018, 08:26 AM
#12
RE: NVRAM Checksum Issue (Solved)
(11-02-2018, 08:26 AM)jan-jaap Wrote:  
(11-01-2018, 08:55 PM)CB_HK Wrote:  the current configuration is for Channel 0 to run all the SCSI drives (using a loop back connector instead of terminators in the bottom corner). The IO3B connector is attached to a bulkhead port only. When I reverted this layout and split the drive bays, 2 on Channel 0 and 2 on Channel 1, nothing would show on 1.
OK, so channel 1 (external, to bulkhead) is the one that's broken and channel 0 (to all internal drive bays) works? In that case you should be able to use the internal disks, right? or does it fail to POST and just sit there?

I would think twice before risking to destroy an otherwise functional IO3B just to gain a secondary SCSI channel.

NB: I realized later that the picture I posted was an old one from the IO3 of my 4D/380VGX, not the IO3B from the Crimson. The layout is nearly identical, except for a jumper block somewhere.

I’m going to keep looking into the issue and weigh my options. On one hand you’re absolutely correct: I have a working channel and should likely leave things well enough alone. On the other I have a strong desire to repair what’s broken. I’m not planning on doing anything until I spend some time thinking about it.

I’m checking with someone right now about getting a spare IO3B board. That would be the easiest solution and then I wouldn’t feel as compelled to break out the desoldering iron.

Onyx  Vault L  Crimson  Indigo  Personaliris  Octane2  1600SW   Indigo2 R10000/IMPACT  Indigo2  Indy  Challenge S  Tezro Rack
CB_HK
Crimson

Trade Count: (7)
Posts: 231
Threads: 43
Joined: May 2018
Location: Las Vegas, NV
Find Reply
11-02-2018, 03:45 PM
#13
RE: NVRAM Checksum Issue (Solved)
(10-15-2018, 03:56 AM)CB_HK Wrote:  UPDATE

I have solved my issue with the Dallas RTC inside my Crimson by disconnecting the internal lithium batteries and attaching a new coin cell battery holder with leads.

Hi CB,

thanks for summarising your NVRAM fix and apologies I only saw this post now, years after the fact. I'd like to contribute to this discussion by tossing in my slightly different solution -- of course YMMV.

I decided to be a bit "cool" about it after realising the battery GND in the DS1216 is permanently connected to the IO3B's GND. So I simply went ahead and soldered the GND pin from the external battery holder directly to an unused connector near the front edge of the IO3B, labelled J2 (see pic, GND pin highlighted in red). This was apparently intended for some kind of coax (network?) cable. This, together with a dab of silicone, gave the battery holder a bit of mechanical stability and did away with an extra wire (for what it's worth).

Having said that, and I think this was omitted in the previous summary, I had to also ground the 2nd battery's positive lead in the DS1216, as I still got garbage after (manually) resetting the NVRAM variables (see console screenshot). I'm not sure if my DS1216 was particularly touchy, but it's probably a good idea given the fact that the chip will switch over to the 2nd battery if one fails -- which apparently happened when I connected the external one, for reasons I can't fathom.

Due to cramped space, and because I didn't feel like melting the socket to a pulp, I routed GND from one of the two round solder pads near pins 1 & 16 of the DS1216 (see piccie). These pads are intended to configure the socket to power 64k instead of 16k RAMs; the square ones are VCC (do NOT connect here!), while the round ones are permanently connected to GND. I found this route easier than soldering another wire to the chip's GND pins (8 and 9) on the opposite end. I just found the solder pads gave more space to manipulate the iron without melting everything, even with a fine tip. Again, YMMV and you may not even find this to be an issue.

So to summarise:
  • Negative pin from external battery soldered to J2's GND (see piccie)
  • Positive pin from external battery soldered to DS1216B pin 4 (BAT1, see pinout)
  • DS1216B pin 14 (BAT2) grounded via round solder pad near pins 1 / 16.
It's important that BOTH old potted batteries are fully disconnected to prevent shorting one to GND via pin 14, while the other could potentially short the external battery, which is now connected in parallel. Check for non-continuity between GND and pins 4 resp. 14!

Anyway, I hope this helps and makes things a bit easier.  Good luck to all those who face this procedure.  It's not really hard, you just have to be meticulous about it.

Best regards,

--Roland


Attached Files Image(s)
                           

-----------------------------------------------------------
Indigo Indy  PowerSeries-4D310 Crimson     Wants --> Onyx  Iris 1000 Personaliris Indigo2 R10000/IMPACT

"Calculating machines cannot express free will, at last not as long as they function correctly" [W. Knödel, Programmieren von Ziffernrechenanlagen, 1961]
"The most powerful optimization tool in existence may be the delete key." [Eric S. Raymond, "The Art of UNIX Programming", 2003]
"END OF LINE" [TRON, 1982]
(This post was last modified: 03-16-2022, 07:20 PM by GanjaTron.)
GanjaTron
Crimson

Trade Count: (0)
Posts: 36
Threads: 6
Joined: Jul 2020
Location: Switzerland
Find Reply
03-16-2022, 07:07 PM


Forum Jump:


Users browsing this thread: 1 Guest(s)