Dallas DS1742W-120, things I've learned

vvuk

Administrator
Aug 25, 2021
39
33
18
From everything I can read it's the original SGI-used parts that are out of spec. Which is strange, but the numbers don't lie. I really hate how flexible the pins are on the dallas chips -- even the original. Super soft, they don't feel like a regular DIP IC at all.
 

vvuk

Administrator
Aug 25, 2021
39
33
18
Just swapped the (still working, apparently) -120 in an Origin 350 with one of the 120+s that I got. Also had to use an adapter; identical socket as in the Fuel. Interestingly, @mach_kernel got a set of chips from the same ebay seller and didn't need to use an adapter. So.. I don't know. But I did the same thing I did before -- "activated" the 120+ by writing 0's a few times, verified the clock was ticking, then read the previous chip, wrote it to the new one, and installed the new one. No problems.
 
  • Like
Reactions: Elf

3ddoc

Member
Jan 17, 2020
46
20
8
I have a o350 that is missing the watchdog battery, what would you charge me to clone one for me, I could send you the the chip to clone from and one I pulled from an o300 if that can be erased and programmed.
 

vvuk

Administrator
Aug 25, 2021
39
33
18
Which one, the Dallas? Or the ST with the snaphat? I'll shoot you a message.
 

weblacky

Active member
Jan 13, 2020
181
45
28
Seattle, WA
Please insert a BLANK RTC...it WILL provision it fine. Fuel doesn't have an issue and O365 might not, Tezro has a HUGE issue with failing to blank and provision an RTC from another Tezro (old data) and fails. vvuk only cloned his functional rtc so he didn't have to re-setup variables/parameters...nor have his serial reprogrammed. But in a BLANK L1 RTC with a functional snaphat battery on the controller, it should auto-program by itself, including serial number.

I've only heard of ferial programming issues if you have a DEAD controller snaphat battery AND a dead L1 RTC and you try to replace just the L1 RTC, first.

If you ensure you have a working snaphat setup, you should just need a blank L1 RTC and it should "just work". It should be programmed on first boot, then dump you into POD, then just reboot and you should be good to go.
 

vvuk

Administrator
Aug 25, 2021
39
33
18
vvuk only cloned his functional rtc so he didn't have to re-setup variables/parameters...nor have his serial reprogrammed. But in a BLANK L1 RTC with a functional snaphat battery on the controller, it should auto-program by itself, including serial number.
No, I used a blank/new DS1742W. A blank one does get re-provisioned properly, as you say, but only as long as it's "enabled". But as I described earlier in the thread -- the issue is that these are shipped in a "shut down" state if they really are brand new, and need to be initialized and have the oscillator turned on. The simplest way is to use a programmer to just write zeros (twice, weirdly). Without doing so the machine just won't come on; L1 won't even boot. Not clear why -- the chip reads as all 0xff until zeros have been written (which also corresponds to the "oscillator off" state), and maybe the early boot doesn't like that. The IP35 early bootloader could indeed just initialize it, but it's possible that it doesn't actually init the clock register and then gets confused that the clock isn't working -- and thus aborts.
 

weblacky

Active member
Jan 13, 2020
181
45
28
Seattle, WA
The freshness seal was not a new feature, it was in the original version these machines came with) so it should have shorted and linked the battery on first use.

Also after it didn’t fit the first time, didn’t you fiddle with it in a programmer before it was ever successfully placed in an SGI? What’s to say if you’d been able to insert it the first time, without issue, that the freshness seal wouldn’t have worked?
 
Last edited:

vvuk

Administrator
Aug 25, 2021
39
33
18
Possibly -- but don't know what to tell you. A brand new inserted chip does not work -- @Xav101 and @mach_kernel both recently went through this with various O350s. A chip that has had 0s written to it (but otherwise has not had a copy of any data written to it) works from that point on.
 

About us

  • Silicon Graphics User Group (SGUG) is a community for users, developers, and admirers of Silicon Graphics (SGI) products. We aim to be a friendly hobbyist community for discussing all aspects of SGIs, including use, software development, the IRIX Operating System, and troubleshooting, as well as facilitating hardware exchange.

User Menu