From nobody@nowhere Mon Jan 10 01:21:48 2000 Xref: ditsydh.syd.dit.CSIRO.AU comp.sys.sun.hardware:3599 comp.sys.sun.misc:3737 comp.sys.sun.wanted:1110 alt.sys.sun:7089 Newsgroups: comp.sys.sun.hardware,comp.sys.sun.misc,comp.sys.sun.wanted,alt.sys.sun,um.sun Path: ditsydh.syd.dit.CSIRO.AU!dmssyd.syd.dms.CSIRO.AU!metro!munnari.oz.au!sgiblab!sdd.hp.com!uakari.primate.wisc.edu!ames!nsisrv!news2!roten From: roten@CUBA.gsfc.nasa.gov (Charles Roten) Subject: I need a source for Sun 386i/250 TIMEKEEPER (tm) RAMs .. HEEELLLLP ! Message-ID: Summary: Info on the 386i mailinglist & ftp sites included ! Lines: 79 Sender: usenet@nsisrv.gsfc.nasa.gov (Usenet) Nntp-Posting-Host: cuba.gsfc.nasa.gov Organization: /cuba_b/dirbe/roten/.organization X-Newsreader: GNU Emacs 18.57.1, GNUS 3.13, NNTP 3.10 Date: Fri, 25 Sep 1992 18:33:42 GMT I'll try this again, since it seems my post of 2 days ago did not make it past GSFC's "nntpserver" (HAH ! :-( ). A few months ago, a Sun 386i/250 that has been running very stably under SunOS 4.0.2 for almost 4 years began to exhibit a strange problem. The system clock would stop every few minutes ! It required use of the 'date' command to restart it. A query to the 386i mailinglist, and examination of it's archives, yielded the following information: The most likely cause of the problem is the exhaustion of the lithium cell aboard the TIMEKEEPER (tm) RAM on the motherboard. The simplest fix is just to pull it from it's socket, put in a new one, and reinitialize it. The part is made by SGS-Thomson Microelectronics. One netter (now absent) got a replacement from Pioneer Standard Electronics (no address given :-( ). The part number is MK48T02BU-25. THIS IS THE INFO I NEED: ------------------------ Contact info for a place where I can get this part, hopefully close to the DC metro area. Failing that, the address and phone number for Pioneer Standard Electronics. How to reinitialize the new part once it is inserted. Now .. for those of you who run 386i's and just jumped out of your chairs shrieking " _WHAT_ _386i_ _MAILING_ _LIST_ !?!?!?!? " You subscribe by email to either sun-386i@compaq.com or sun-386i-owner@wotan.compaq.com I forget which. :-( There are three large ftp archives of 386i-specific stuff I know of. The first two, compaq.com:/pub/sun-386i and vernam.cs.uwm.edu:/sun386i hold archives for the mailing list, X11R5 (pl 16) 386i binaries, gcc 2.1 386i binaries, and the second site holds the upgrade from SunOS 4.0.1 to SunOS 4.0.2 for the 386i. You _DO_ need the upgrade if you are running 4.0.1 .. it is a _DOG_! The third site, akbar.cac.washington.edu:/local/bin.sun386 akbar.cac.washington.edu:/local/include.sun386 akbar.cac.washington.edu:/local/lib.sun386 has mostly older (1989-90) binaries (like emacs 18.54, perl, etc), scripts, and libraries for the 386i. Thanks in advance, Charles. -- Charles Roten | Hughes-STX, Incorporated | roten@cuba.gsfc.nasa.gov | 'Use the Source, Luke!' 7601 Ora-Glen Dr., Greenbelt, MD 20706 | 301-513-7805 (w), 301-317-0872 (h) | Obi-Wan Stallman From uunet!uu7.psi.com!wxsat!sun-da Tue May 18 16:36:41 1993 To: Sun-386i@ssg.com Subject: NVRAM availability in the UK Reply-To: uunet!ssg.com!sun-admn Organization: System Support Group Content-Length: 1558 X-Lines: 44 The following is forwarded by the Sun-386i mail list daemon: Subject: NVRAM availability in the UK From: Date: Tue, 18 May 93 11:44:11 BST There has been some postings recently on the availability of the SGS-Thomson TIMEKEEPER NVRAM used in the 386i. I recently got hold of a new NVRAM chip here in the UK, which in retrospect, looking at some of the prices which have been posted ($150) looks like a good deal.... RS-Components (Radio-Spares) stock the SGS-Thomson MK48TO2B-20 (200ns). The actual NVRAM in my 250 was a MK48TO2B-25 (250ns), which they didn't stock, however the "-20" is a higher spec device and works perfectly in my 386i. Incidently, RS also stock the MK48ZO2B-25, *don't* buy it as it is purely NVRAM and doesn't have the TIMEKEEPER functionality, one letter makes the world of a difference :-) Anyway, the price was just over 13 pounds (sterling) + VAT. RS don't sell directly to the public, but they do have a mail order division called ElectroMail who will sell you stuff over the phone. If anybody is interested, I'll either post, or mail them, ElectroMail's phone number and the RS stock number of the MK48TO2B-20..... I don't have them handy just now! I hope this is of some use to somebody. Regards --Andrew From bzs@cs.bu.edu Mon Jan 10 01:21:48 2000 Received: from sirus.itc.yorku.ca by ditsydh.syd.dit.csiro.au with SMTP id AA27432 (5.64+/IDA/DIT-0.9 for ken); Wed, 3 Aug 94 14:22:52 +1000 Received: from cs.bu.edu by Sirus with smtp (Smail3.1.28.1 #9) id m0qVVc6-0003xDC; Tue, 2 Aug 94 21:59 EDT Received: from csa.bu.edu by cs.bu.edu (8.6.4/Spike-2.1) id VAA07768; Tue, 2 Aug 1994 21:56:10 -0400 From: bzs@cs.bu.edu (Barry Shein) Received: from localhost by csa.bu.edu (8.6.4/Spike-2.1) id VAA20781; Tue, 2 Aug 1994 21:57:04 -0400 Date: Tue, 2 Aug 1994 21:57:04 -0400 Message-Id: <199408030157.VAA20781@csa.bu.edu> To: stefan@centaur.astro.utoronto.ca Cc: henrich@crh.cl.msu.edu, leisner@sdsp.mc.xerox.com, sun-386i@itc.yorku.ca In-Reply-To: <9407272109.AA21564@centaur.astro.utoronto.ca> (message from Stefan Mochnacki on Wed, 27 Jul 94 17:09:47 EDT) Subject: Re: Where did the name 'RoadRunner' come from? (I can't believe I'm still on this list) (Then again I'm probably still on the xerox dandelion list) (but hey gabbing like this is fun I suppose) >Within a year or so, the SPARCStations came out, but unfortunately the 486i >upgrade did not. There was some rumour that the 486 would outperform >an SS1. I think the most likely explanation for Sun's dropping the >386i/Intel-based line was that I was around Sun a lot in those days tho didn't work for them so probably heard more than most people who did :-) Here was what I gathered at the time tho I wouldn't claim it to be gospel and there probably is no one reason for a lot of these decisions as much as we'd like to think there was: 1. Clearly the relatively new 386 with its reasonable MMU (hence, ability to run something like SunOS, 286's really couldn't w/o making a lot of software compromises) and huge customer '86 base attracted interest at Sun in general at the time. Whoever brought the subject up first probably didn't have to explain very hard why they were looking at the 386 to base a product around. 2. At the time the decision was being made (around 1986?) Sun was on Motorola. Sun had projected an image of being able to produce inexpensive and powerful Unix systems by leveraging commodity parts. The Moto CPU was commodity, the Intel CPU was even more commodity (if that makes sense, but huge volumes were being shipped.) The same was true for most Sun peripherals on the Moto line; off the shelf SIMMs, generic ethernet chips and disk controllers, etc. Little if anything that Sun sold in their Sun3 or Sun2 product line was directly manufactured at Sun, it was more of an assembly and integration strategy (CPU boards of course were Sun's, but they mostly just pieced together generic chips etc and the occasional custom ASIC etc.) 3. Hence, at that point in time with the new-ish 386 seeming reasonably fast for its time and capable of running SunOS/Unix it made technical and architectural sense anyhow, of course that's not quite the same as business sense but... 4. The story goes that something which preceded the decision was some Sun salesperson in Manahattan's experience. He was not awfully busy, Suns were not especially selling like hotcakes in Manhattan being mostly academic/engineering systems at the time. Once you wrote your orders for Columbia and NYU and maybe CCNY you were about done with Manhattan as far as Sun was concerned in those early days. So he arranged a demo (of a Moto machine, Sun3) over at one of the big brokerage houses. As the story goes, they flipped, they'd never seen a system that could do multiple jobs on one screen before (this pre-dates Windoze, or at least pre-dates it for folks like this.) They pointed to the brokers' desks with their jumble of PC systems, often a half-dozen monitors, and said basically ``can youse guys do 'dis kinda thing?'' And if so we'll order 500, etc., and so will our competitors no doubt. Hey, a *business* niche! That was something new for Sun pretty much and the kind of thing some of their execs no doubt dreamt about. One of the big pieces was Quotron, the real-time stock quote service, and some other pieces, getting at their in-house db's and so on. This was brought back to Sun Central (whatever) and they got interested. Although perhaps not the first time a '386 system was suggested this seemed like an opportunity. Given a '386 running SunOS that could run DOS in a window maybe they could pull it off and not have to quite port every app these guys needed, they'd just run in a DOS window (this pre-dates any chance of running a DOS emulator on a non '86 system.) 5. Sun pulled that off and the bet was good, they got a lot of orders for the 386i in brokerage houses and similar. 6. Obviously there was interest elsewhere, that was good too. 7. No doubt Sun was thinking gee, maybe we can drop this Moto thing altogether. Moto was a good and loyal company but I'm sure there were problems, particularly with Moto's commitment to the 68K product line. It wasn't really making Moto rich, even with Apple's orders, for a chip manufacturer it really wasn't all that many units even if it seems like a lot of computers to the rest of us. 8. Sun was supposed to have released the 486i, not the 386i, in the first place. But the 486 was slipping and became too late for their schedule so Sun went with the 386. 9. The 486 continued to slip. 10. The 386 ceased to be very fast not long after Sun began shipping these things. 11. The 486 continued to slip. 12. RISC started to become the rage among engineering circles. Rumors abounded that Moto was going to drop the 68K entirely in favor of a new 88K RISC chip. They even fired their 68K VP (or some such thing), it was kind of a mess, Moto 68K development budgets all but disappeared, Sun went with a higher clock speed 68020 because any 68030 or 68040 was fading into the vague future. 13. The 486 slipped some more. 14. It became clear to Sun that, in the words of Beavis & Butthead who didn't yet exist: This sucked. 15. Sun in that interim was roughly doubling sales every year. The idea of developing their own CPU chip became reasonable. Maybe all-commodity was a great idea when sinking $50M into developing a new CPU was unthinkable but maybe now it's a reasonable idea. 16. No one else really had much anything of a RISC chip, but the technology seemed like a winner. It was a gamble but other than small start-up MIPS (and maybe the Titan @ DEC which didn't go anywhere anyhow) it looked like Sun could be first with this technology. 17. Sun sunk the money and Sparc was born. 18. It was better than the 386 and the 68K in terms of speed and scalability. It was exciting. It could be licensed to multiple suppliers, Sun could probably free themselves from this dependence on the shifting sands of folks like Moto and Intel (and Nat'l Semi and everyone else they might have considered playing with but didn't.) 19. As someone pointed out, Sun at this point has 3 architectures, Moto, 386 and Sparc. McNealy comes up with the "put all the wood behind one arrow" strategy. Support of 3 architectures is too expensive and the suppliers of the other two are not really acting in Sun's best interest (which is understandable, but still true nonetheless.) 20. The 486 still isn't available in sufficient quantities to make a 486i feasible. Sales have already topped for the 386i. Support is expensive. Weaknesses of the 386i implementation are beginning to show through, comparatively. For example, the relatively slow screen speed probably wasn't very fixable w/o a major investment since they're byte-swapping everything going to/from the frame buffer to compensate for the pixrect library's big-endian orientation. You can't really support random PC peripherals very easily and few people actually use this supposed feature. The DOS emulation is "ok" but probably doesn't really replace having a DOS machine since many DOS apps don't quite work right or at all, fixing that would be very expensive, maybe impossible at some point due to the way people write DOS apps (to this day people are goring themselves on this problem.) As is often the case with Unix on x86, even today, put the pieces together and it's just not all that cheap. The mere CPU cost doesn't dominate the system cost (if anything, the monitor and graphics subsystem does, and if you need roughly 1Kx1K until recently that was exotic and expensive in the x86 world so you were getting nowhere on making a cheap system.) Typically 386i's were over $10K, easily around $15K (disk was still pretty expensive.) So other than for some niche players what was the point really? You can't make it fast, you can't make it cheap, you can't make it work quite right, and unless Intel gets their act together on their promises you can't make it at all. I'd say the rest was history. -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD From vicor!vicor.com!TEG@uucp-gw-2.pa.dec.com Mon Jan 10 01:21:48 2000 Received: from sirus.itc.yorku.ca by ditsydh.syd.dit.csiro.au with SMTP id AA23051 (5.64+/IDA/DIT-0.9 for ken); Fri, 5 Aug 94 04:21:25 +1000 Received: from uucp-gw-2.pa.dec.com by Sirus with smtp (Smail3.1.28.1 #9) id m0qW5Ol-0003xjC; Thu, 4 Aug 94 12:12 EDT Received: by uucp-gw-2.pa.dec.com; id AA20830; Thu, 4 Aug 94 09:06:34 -0700 Received: from stimpy.vicor.com by vicor.com (4.1/SMI-4.1) id AA10334; Thu, 4 Aug 94 09:06:04 PDT Received: by stimpy.vicor.com (4.1/SMI-4.1) id AA13576; Thu, 4 Aug 94 09:05:35 PDT Date: Thu, 4 Aug 94 09:05:35 PDT From: TEG@vicor.com Message-Id: <9408041605.AA13576@stimpy.vicor.com> To: bzs@cs.bu.edu, sun-386i@itc.yorku.ca Subject: Re: Where did the name 'RoadRunner' come from? A couple of notes about Barry Shein's message: The 386i was not the first Sun product that could do DOS emulation... Sun had the SunIPC Board (not to be confused with later products using the IPC acronym) which did DOS emulation early on in the Sun3 product line (way before the 386i came to be). It was basically a VME card with an Intel (80286?) on board that could run DOS in a window. Once everything moved to Sparc, they started offering an SBUS 486 DOS emulator card to accelerate the SunPC emulator for Sparcs. Also, my take on the evolution was that Sun was growing rapidly and just started going in multiple directions. I think the first SPARC systems (4/110 upgrade board for 3/110) was an Any Bechtolsheim (sp?) pet project which wasn't intended (at first) to become Suns only product line. I think the 386i was just a "hedge" in case Motorolla wasn't able to evolve the 680X0 processor line properly. In any case, from a customer standpoint, Sun seemed to be going through some confusing growing pains during the limited lifespan of the 386i. I don't think the 386i was meant to have a 486 CPU from inception, but there definately was a 486 upgrade CPU board that was partially announced, but never was debugged enough to get shipped. The early versions I saw were having problems with the new SCSI-II controllers (as apposed to the SCSI-I on the 386i motherboard). -Tom Griner TEG@vicor.com From bzs@cs.bu.edu Mon Jan 10 01:21:48 2000 Received: from sirus.itc.yorku.ca by ditsydh.syd.dit.csiro.au with SMTP id AA09404 (5.64+/IDA/DIT-0.9 for ken); Sun, 7 Aug 94 09:07:33 +1000 Received: from cs.bu.edu by Sirus with smtp (Smail3.1.28.1 #9) id m0qWsns-0003y8C; Sat, 6 Aug 94 16:57 EDT Received: from csa.bu.edu by cs.bu.edu (8.6.4/Spike-2.1) id QAA11163; Sat, 6 Aug 1994 16:55:21 -0400 From: bzs@cs.bu.edu (Barry Shein) Received: from localhost by csa.bu.edu (8.6.4/Spike-2.1) id QAA17499; Sat, 6 Aug 1994 16:56:21 -0400 Date: Sat, 6 Aug 1994 16:56:21 -0400 Message-Id: <199408062056.QAA17499@csa.bu.edu> To: TEG@vicor.com Cc: sun-386i@itc.yorku.ca In-Reply-To: <9408041605.AA13576@stimpy.vicor.com> (TEG@vicor.com) Subject: Re: Where did the name 'RoadRunner' come from? From: TEG@vicor.com >A couple of notes about Barry Shein's message: > >The 386i was not the first Sun product that could do DOS emulation... >Sun had the SunIPC Board (not to be confused with later products >using the IPC acronym) which did DOS emulation early on in the Sun3 >product line (way before the 386i came to be). It was basically >a VME card with an Intel (80286?) on board that could run DOS in >a window. Right, I remember it well, definitely had a '286 incarnation (there may have been an earlier '086 incarnation.) Not the most convenient product since fewer and fewer Sun desktop machines had VME slots as time went on. That is, the Sun3/60+Sun3/50 which were the volume sales machines didn't. The Sun3/75 and Sun3/160 did have VME slots, the 3/75 only had one spare VME slot and it was kind of funky (would only take some subset of boards, not enough power or incomplete VME implementation or both) and that one slot was hotly contested real-estate (only way to go above 4MB or add color? stuff like that.) The 3/160 was expensive for a personal computer (really a deskside server tho it was what I used, loved it), probably in the $25K or more range for any useable set-up. There were also some odd-ball VME Sun workstations that never got much volume probably due to their late introduction and generally high pricing comparatively (e.g. the 3/150 and 3/110, these basically presaged the 4/110, a deskside Sparc with fewer slots than the x/160 so lower priced, but more slots than the 3/75 which was kind of a botch, I think they had 4 which made a big difference, you could have both color AND something else, and probably took more memory on the CPU card so that didn't immediately compete for slots, my own memory might be a little off here but that's the drift.) But the point is you can see where a VME based x86 card fell out of favor, it was kind of a workstation product (you needed a screen to make DOS useful, it was not a shareable resource so didn't work that well on a server which is where most of the VME slots probably were in your dept, etc.) But it did exist. Again, the 286 quickly became a problem tho I suppose if the market were there it would have become a 386 and then 486 but it wasn't so it didn't. As you say it all moved to the SBUS. >Also, my take on the evolution was that Sun was growing rapidly >and just started going in multiple directions. I think the >first SPARC systems (4/110 upgrade board for 3/110) was an >Any Bechtolsheim (sp?) pet project which wasn't intended >(at first) to become Suns only product line. I think the 386i >was just a "hedge" in case Motorolla wasn't able to evolve >the 680X0 processor line properly. In any case, from a >customer standpoint, Sun seemed to be going through some >confusing growing pains during the limited lifespan of the 386i. I think all these things are simultaneously true. Yes, a hedge on the Moto processor was no doubt very important, and they chose a 386 and not, oh, the NS32x32 because there was a big market for running x86 code. >I don't think the 386i was meant to have a 486 CPU from inception, >but there definately was a 486 upgrade CPU board that was partially >announced, but never was debugged enough to get shipped. The early >versions I saw were having problems with the new SCSI-II controllers >(as apposed to the SCSI-I on the 386i motherboard). I'm about 98% sure it was and Sun never intended to release a 386 based product but got stuck by Intel's delays. I remember this being public knowledge and even spin you got if you were a large purchaser (which I was at the time), oh, the 386 is only temporary and was never intended, when the 486 is available REAL SOON NOW we'll upgrade you and boy will this box be hot! This is one thing that caused some friction between some customers and Sun over the 386i, they felt they had been promised the 486 when they bought the 386i and this was only an interim implementation. So when Sun cancelled out on the upgrade (and finally the whole line) some folks got pretty angry. For example, you'd hear this at the Sun User Group executive sessions where execs (McNealy et al usually) would sit on stage and open the floor to questions. They never denied it, they just apologized, basically, and tried to offer some good trade-in programs on Sparcstations and other systems (they still do.) Well, hey, it's possible there was some window where the 486 wasn't yet planned but let's say by the time they were talking to customers about the 386i it was ``really supposed to be a 486i but for Intel's delay on chip supplies''. -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD From eosdata.gsfc.nasa.gov!croten@ssg.com Mon Jan 10 01:21:48 2000 Received: from sirus.itc.yorku.ca by ditsydh.syd.dit.csiro.au with SMTP id AA23715 (5.64+/IDA/DIT-0.9 for ken); Fri, 12 Aug 94 08:47:17 +1000 Received: from uu7.psi.com by Sirus with smtp (Smail3.1.28.1 #9) id m0qYgXj-0003wzC; Thu, 11 Aug 94 16:16 EDT Received: from eosdata.gsfc.nasa.gov by uu7.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA12285 for ; Thu, 11 Aug 94 16:08:02 -0400 Received: by ssg.com (5.65c/3.2.083191-System Support Group) id AA29675; Thu, 11 Aug 1994 18:48:50 GMT Received: from eosdata-f.gsfc.nasa.gov by uu7.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA04532 for sun-386i; Thu, 11 Aug 94 13:53:06 -0400 Received: by eosdata.gsfc.nasa.gov (940406.SGI/931108.SGI.ANONFTP) for sun-386i@ssg.com id AA25229; Thu, 11 Aug 94 13:52:14 -0400 Date: Thu, 11 Aug 94 13:52:14 -0400 From: croten@eosdata.gsfc.nasa.gov (Charles Roten) Message-Id: <9408111752.AA25229@eosdata.gsfc.nasa.gov> To: sun-386i@ssg.com (Sun386i Mailing List) Subject: Timekeeper RAM problems .. and possible solutions More about the Timekeeper RAM. I spoke to a SGS-Thompson techie last week, about the problems with the Timekeeper RAM, part number MK48TO2BU-25. The conversation was _highly_ illuminating. As we spoke, it developed that: 1: The 386i is prone to a high degree of line noise generation. This is _not_ conventional RFI, but crud injected into the _power_ _line_. So much so that a shortwave radio on the same line suffers an inordinate amount of interference, _until_ a line conditioner is placed between the 386i and the wall socket. Then, the problem _dissappears_. 2: The Timekeeper RAM is sensitive to negative voltage on its data and address pins. More than -0.3 volts and the lithium cell begins to drain. 3: The Timekeeper RAM is spec'ed for a service life of _10_ _years_ (!!) I'll betcha most 386i users take that with a generous grain of salt. :^) But wait. There's more ... 4: A Timekeeper RAM with a faster response time might be more robust versus negative-voltage interference. Now, if electrical noise of the cited intensity is injected into the _power_ line, then inside the box, it must be much worse. Hence, it seems sensible to imagine random fluctuations zapping the data and address pins of the Timekeeper RAM with sporadic surges which drop the voltage to less than -0.3 volts from time to time. I replaced my _fourth_ Timekeeper RAM with a spare last week, and reprogrammed it. The _new_ Timekeeper RAM immediately began to show signs of incipient failure .. ie., system clock slowness. Two days ago, I responded to a perceived high level of dust in the system box with a shutdown and a _thorough_ cleaning. I was up 'till 4 am this morning putting the system back together. And Lo and Behold! The Timekeeper RAM was acting properly again! The system clock, which _had_ been recording one second for every three, was dead on time at 11:00 this morning. It is a known fact that the design of the fans in the 386i was flawed. Maybe, the resulting dust problem excabrates the failure of the Timekeeper RAM, through an increase in the internal noise, or heat, or both. And, maybe preventive maintaince can forstall this. Perhaps a more robust version of the Timekeeper RAM may be less failure prone. Also, as the SGS-Thompson chap and I discussed, a zener diode buffer might serve to protect the Timekeeper RAM from excessive negative voltages. Comments, anyone? Charles D. Roten | Hughes STX Inc. croten@nyx.cs.du.edu | NASA GSFC (Hurrah DAAC!) croten@eosdata.gsfc.nasa.gov | (301) 286-4413 (w), (301) 317-0872 (h) From @PORTLAND.CAPS.MAINE.EDU:houser@usm.maine.edu Mon Jan 10 01:21:48 2000 Received: from sirus.itc.yorku.ca by ditsydh.syd.dit.csiro.au with SMTP id AA08859 (5.64+/IDA/DIT-0.9 for ken); Tue, 16 Aug 94 09:37:19 +1000 Received: from PORTLAND.CAPS.MAINE.EDU by Sirus with smtp (Smail3.1.28.1 #9) id m0qa8TX-0003y6C; Mon, 15 Aug 94 16:17 EDT Date: Mon, 15 Aug 94 16:17 EDT Received: from payson.usmacs.maine.edu by PORTLAND.CAPS.MAINE.EDU (IBM VM SMTP V2R2) with TCP; Mon, 15 Aug 94 16:15:42 EDT Received: from PAYSON/TEMPQ by payson.usmacs.maine.edu (Mercury 1.12); Mon, 15 Aug 94 16:16:45 EST5EDT Received: from TEMPQ by PAYSON (Mercury 1.12); Mon, 15 Aug 94 16:16:35 EST5EDT Received: from [130.111.129.42] by payson.usmacs.maine.edu (Mercury 1.12); Mon, 15 Aug 94 16:16:23 EST5EDT X-Sender: steve@payson.usmacs.maine.edu Mime-Version: 1.0 To: sun-386i@itc.yorku.ca (Sun386i Mailing List) From: houser@usm.maine.edu (Stephen Houser) Subject: sun386i FAQ Message-Id: <80FFD62B26@payson.usmacs.maine.edu> Sun386i (RoadRunner) Frequently Asked Questions This FAQ dfescribes the Sun386i computer, common problems, solutions, software available, hardware available, and almost anything else people on the sun386i mailing list have discussed over the past few years. Please feel free to make your own contributions and help fix any bugs. Last Updated: August 12, 1994/Stephen Houser (houser@usm.maine.edu) ======================= 0-0. Table of Contents ======================= 1-0. General Information about the FAQs and the Sun386i 1-1. Where is the FAQ? 1-2. Who do I ask questions? 1-3. What is a sun386i, RoadRunner, etc. 1-4. Where did the 386i get the name 'RoadRunner'? 2-0. Software for the Sun386i 2-1. Anonymous FTP sites for the Sun386i 2-2. SunOS 4.0.2 Upgrade, Where can I get it? 2-3. SunOS 4.0.2 Problems installing from tape 2-4. Synopsis of available 'free' software 2-5. GCC 2.2.2 2-6. GCC 2.5.8 2-7. GhostScript 2.6.1 2-8. GDB 4.7 (does not work) 2-9. GNU EMACS 18.58 2-10. PERL version 4.036 2-11. XWindows version 11 release 5 2-12. XWindows version 11 release 6 2-13. GnuPlot 3.5 2-14. HP LJ III printcap 2-15. PPP (ppp-sunos4.1.pl6.tar.Z) on a 386i 2-16. SNAP Cannot Create New Users 2-17. Removing NIS YellowPages 3-0. Hardware for the Sun386i 3-1. NVRAM Problems and Solutions (lots of problems) 3-2. NVRAM Suppliers (Sun Battery) 3-3. Memory Expansion 3-4. 486 upgrade for the 386i 3-5. Large SCSI disks 3-6. Running around topless (i.e. without a framebuffer/monitor) =========================================== 1-0. General Information about the Sun386i =========================================== ----------------------------------------------------------------------- 1-1. Where is the FAQ ----------------------------------------------------------------------- I (Stephen Houser) maintain the FAQ and try to post it to the= list semi-regularly (i.e. every so often). If you are really desperate look in the ftp sites listed in this copy of the FAQ. If you are really really desperate and cannot find it there...= I have anonymous ftp setup on my own (working machine) with the current= FAQ and perhaps a few other files (as I compile them, and before the other sites get them). ftp://cxc1.msu.edu/386i/list_archive Michigan State University Charles Henrich http://rs560.msu.edu/~henrich ftp://sahsun.usmacs.maine.edu/pub/sun386i (temporary site) University of Southern Maine Stephen Houser http://csir1.usmacs.maine.edu/~houser I'm also working on an HTML version of the FAQ so you can perhaps find it via my home page URL given above. ----------------------------------------------------------------------- 1-2. Who do I ask questions? ----------------------------------------------------------------------- There is a mailing list for Sun 386i users maintaned by; forgotten@some.unknown.site.drat! In other words, I forgot, please tell me, my mail to ...-request seems to bounce To get added to the list (or subtracted) send mail to: sun-386i-request@itc.yorku.ca -- bounces?!? For general things, like postings, and all that send mail to: sun-386i@itc.yorku.ca ----------------------------------------------------------------------- 1-3. What is a sun386i, RoadRunner, etc. ----------------------------------------------------------------------- It's an Intel 80386-based UNIX computer produced for a short while by Sun Microsystems. There are 2 standard models the 150, and the 250. Sun386i 150 - A 20Mhz 80386? Sun386i 250 - 25Mhz 80386 CPU, 80387 Co-processor, 327 or 91 Mb CDC Wren IV Hard disk, 1 Rs232 port, 1 Centronics printer port, standard (AUI) Ethernet port, 3 Sun (??) bus expansion slots, 5 PC AT ISA bus expansion slots. ----------------------------------------------------------------------- 1-4. Where did the 386i get the name 'RoadRunner'? ----------------------------------------------------------------------- ... under construction ... ============================== 2-0. Software for the Sun386i ============================== ----------------------------------------------------------------------- 2-1. Are there any anonymous FTP sites for the Sun386i? ----------------------------------------------------------------------- Here are the URLs of the popular sites that I know of. They contain both binaries and archives of the mailing list: ftp://cxc1.msu.edu/386i Michigan State University Charles Henrich http://rs560.msu.edu/~henrich ftp://ftp.primus.com/pub/sun386 Primus Control (who maintains it??> ftp://usc.edu/archive/usenet/systems/sun/sun-386i (maintainer?) ----------------------------------------------------------------------- 2-2. SunOS 4.0.2 Upgrade; Where can I get it? ----------------------------------------------------------------------- ftp://cxc1.msu.edu/386i/software/sunos4.02 INSTALL README diskette.[1-8] Contains images of eight floppies used to upgrade both the runtime operating system and the development system. On of the disks is a replacement diagnostics disk, that does not seem to boot? Get the README file along with the INSTALL and diskette.* files. It describes step-by-step how to make floppies from the images and how to install the upgrade. You will need to have a working SunOS 4.0.1 system to do the upgrade. ----------------------------------------------------------------------- 2-3. SunOS 4.0.2 Problems installing from tape ----------------------------------------------------------------------- From the July 1990 Software Technical Bulletin (Sun publication), SunOS Sun386i Patch - page 39-40: ------------------------------------------------------------------ Patch for the loadc command for those running SunOS Sun386i 4.0.2. Symptom: Clusters upgraded by SunOS Sun386i 4.0.2 cannnot be loaded from tape using the loadc command. Problem: For those running SunOS Sun386i 4.0.2, the following error message is encountered when using the load or the loadc commands to load any clusters modified as part of the SunOS Sun386i 4.0.2 release. This occurs for those using tape media only, and does not occur when using the diskette media. "The wrong tape is in the drive." The above error message always occurs, and after the user has correctly inserted the SunOS Sun386i 4.0.2 release tape which the system requested. This problem occurs after reinserting the requested tape. Without the below workaround to this problem, the user cannot load the following clusters: advanced_admin base_devel man_pages config networking_plus proflibs sysV_commands sunview_devel Also, loading either or both of the below 'special' global names will fail: appl devel Workaround: Use the below procedure to work around the loadc problem (ie. patches the program). 1. Log in as root or change to superuser (represented by the sharp character, #, below). Then issue the commands shown in the following steps. 2. # mount -o remount /usr <-- make /usr writeable 3. # cd /usr/lib/load 4. # cp load load.old 5. # sed -e '361s/)/|*"$1 $NAME"*)/' load.old > load 6. # sum load 7. If the checksum from the sum command is as shown below, 61115 14 then enter the commands shown next. # rm load.old # sync; sync; reboot 8. If the checksum from the sum command is not as shown below, 61115 14 then enter the following command # cp load.old load and return to step 5 above. After rebooting, the system should now allow the clusters listed above to be loaded without further difficulty. ----------------------------------------------------------------------- 2-4. Free software ----------------------------------------------------------------------- Here is a short list of current versions that work on the RoadRunner, and perhaps are avaliable in binary form for anonymous ftp from some nice person. Many programs compile without incident, those that cased us problems are noted, and have seperate compilation directions. For the most part many GNU programs do work, allthough they usually need a little tweaking. If you don't see what you like ask on the list and let's get more programs added to this list. Most of these that have been checked were done so with the GNU gcc compiler. Using the distributed Sun cc compiler may not work (especially with X windows). GCC 2.5.8 (C/C++ compiler) GCC 2.2.2 (C compiler) BASH 1.12 (shell replacement, like ksh) EMACS 19.24 (text editor/operating system) GhostScript 2.6.1 (PostScript interpreter) PERL 4.036 (text processing languange) PATCH 2.1 (file patcher) GZIP 1.2.4 (compression) ZOO 2.0.1 (compression) XMODEM 3.9 (file transfer) ZIP 1.0 (PC-compatible compression) UNZIP 5.0 (PC-compatible compression) Oleo 1.5 (spreadsheet) ISpell 4.0 (spell checker) GnuPlot 3.5 (graph plotting program) TeX 3.1415 (C version 6.1) (text formatting system) LaTeX2e 1994/06/01 patch level 3 Dvipsk 5.55a (TeX drivers for PostScript) Xdvik 1.8 (Tex previewer for X Windows) XWindows 11 release 5 patchlevel 25 (X Window system) XMosaic 2.1 (WWW client for X) XV 3.00 (Graphic viewer for X) XView 3.20 (Window manager for X) XWindows 11 release 6 (work in progress) Here is a list of some programs that DO NOT WORK on the RoadRunner. There may be people working on getting them to go, post to the list with any information or insight that might make them work! GDB 4.2 (see notes below, does not work?) If you have compiled some of these or others and had to jump through hoops, post it so we can include the directions here. ----------------------------------------------------------------------- 2-5. GCC 2.2.2 ----------------------------------------------------------------------- Gcc 2.2.2 is an older version of the GNU Gcc compiler. The directions are kept here because you will need an 'older' version such as this one to compile some of the newer versions of Gcc. For some reason the Sun supplied cc compiler loops indefinately when compiling newer versions of Gcc. Gcc 2.2.2 compiles without any problems on Sun386i with SunOS 4.0.2: ./configure sun386i make LANGUAGES=3Dc make stage1 make CC=3D"stage1/gcc -Bstage1/" CFLAGS=3D"-g -O" make stage2 make CC=3D"stage2/gcc -Bstage2/" CFLAGS=3D"-g -O" make compare make CC=3D"stage2/gcc -Bstage2/" CFLAGS=3D"-g -O" install make install-fixincludes After you have done all this, you can remove (erase) the source tree for gcc-2.2.2 and begin compiling a newer version of gcc. GCC Pointers... --------------- See GCC 2.5.8 ----------------------------------------------------------------------- 2-6. GCC 2.5.8 ----------------------------------------------------------------------- To compile newer versions of Gcc (like 2.5.8) you will need an older version of GCC (like version 2.2.2). For some reason the compile of 2.2+ hangs when using the Sun supplied compiler. Gcc 2.2.2 is the last version of Gcc know to compile with the Sun supplied cc compiler. ./configure sun386i make LANGUAGES=3Dc make stage1 make CC=3D"stage1/gcc -Bstage1/" CFLAGS=3D"-g -O" make stage2 make CC=3D"stage2/gcc -Bstage2/" CFLAGS=3D"-g -O" make compare make install CC=3D"stage2/gcc -Bstage2/" CFLAGS=3D"-g -O" Somehow 'setjmp.h' appears to get munged. I fixed it with the following changes to the private copy GCC keeps in: '/usr/local/lib/gcc-lib/sun386i/2.5.8/include/setjmp.h' --------------------------- CUT HERE ---------------------------- 47,53d46 < typedef int jmp_buf[_JBLEN]; < < /* < * One extra word for the "signal mask saved here" flag. < */ < typedef int sigjmp_buf[_JBLEN+1]; < 74a68,74 > > typedef int jmp_buf[_JBLEN]; > > /* > * One extra word for the "signal mask saved here" flag. > */ > typedef int sigjmp_buf[_JBLEN+1]; --------------------------- CUT HERE ---------------------------- GCC Pointers... --------------- ftp://cxc1.msu.edu/386i/software gcc-2.5.8.sun386i.bin.filelist gcc-2.5.8.sun386i.bin.tar.gz Sun386i version of GCC version 2.5.8. Compiled with GCC 2.4.5. gcc-2.5.8.sun386i.setjmp-fix 'setjmp.h' fix file (including comments on the problem) ftp://prep.ai.mit.edu/pub/gnu/ gcc-2.5.8.tar.gz GCC 2.5.8 sources as distributed from GNU. ----------------------------------------------------------------------- 2-7. Ghostscript 2.6.1 ----------------------------------------------------------------------- Yes, you can get GhostScript 2.6.1 to work on the Road Runner! First you should get all the fixes that have been put out by the GhostScript maintainers (from prep.ai.mit.edu or some other GNU site). Apply these fixes with patch. Then you will need to fix the file 'gdevmem.h' with the following patch: --------------------------- CUT HERE ---------------------------- *** gdevmem.h.~1~ Wed May 26 21:52:04 1993 --- gdevmem.h Mon Dec 13 13:39:30 1993 *************** *** 119,124 **** --- 119,125 ---- (byte **)0, /* line_ptrs (filled in by mem_open) */\ 0, /* invert (filled in for mono) */\ 0, (byte *)0, /* palette (filled in for color) */\ + 0, /* target */\ 0 /* memory_procs */\ } --------------------------- CUT HERE ---------------------------- If you don't use the patch you will mos likely get something that looks like the following, when trying to display fonts (here using the example program 'prfont.ps'): $ gs prfont.ps Initializing... done. Ghostscript 2.6.1 (5/28/93) Copyright (C) 1990-1993 Aladdin Enterprises, Menlo Park, CA. All rights reserved. Ghostscript comes with NO WARRANTY: see the file COPYING for details. Loading Times-Roman font from ptmr.gsf... 199192 187947 0 done. GS>/Times-Roman DoFont Segmentation fault The rumor is the GhostScript people were notified. As of June 10, 1994 when I fetched fix-04 this problem was still there. Perhaps they will eventually fix it in the offocial sources. GhostScript Pointers... ------------------------ ftp://cxc1.msu.edu/386i/software ghostscript-2.6.1.sun386i.bin.tar.gz Sun386i version of GhostScript version 2.6.1, patched up to fix #04, and 'gdevmem.h' fix. Compiled with GCC 2.5.8. ghostscript-2.6.1.gdevmem-fix 'gdevmem.h' fix file (including comments about the problem) ftp://prep.ai.mit.edu/pub/gnu/ ghostscript-fonts-2.6.1.tar.gz GhostScript fonts for use with GhostScript 2.6.1. ghostscript-2.6.1.tar.gz GhostScript 2.6.1 source code as distributed from GNU. ghostscript-2.6.1.fix-01.gz ghostscript-2.6.1.fix-02.gz ghostscript-2.6.1.fix-03.gz ghostscript-2.6.1.fix-04.gz GhostScript 2.6.1 source code fixes as distributed from GNU. ----------------------------------------------------------------------- 2-8. GDB 4.7 (does not work) ----------------------------------------------------------------------- When compiling gdb-4.7 i get the following errors on files gdb/solib.c and gdb/sun386-nat.c (all others files compiled fine) cc -c -g -I. -I. -I./../include solib.c "solib.c", line 261: rtc_sp undefined "solib.c", line 264: N_COMM undefined "solib.c", line 269: n_un undefined "solib.c", line 269: n_strx undefined "solib.c", line 272: member of structure or union required "solib.c", line 272: cannot recover from earlier errors: goodbye! *** Error code 1 cc -c -g -I. -I. -I./../include sun386-nat.c "sun386-nat.c", line 208: unknown size "sun386-nat.c", line 209: unknown size "sun386-nat.c", line 214: PTRACE_GETREGS undefined "sun386-nat.c", line 214: inferior_pid undefined "sun386-nat.c", line 215: PTRACE_ARG3_TYPE undefined "sun386-nat.c", line 216: PTRACE_GETFPREGS undefined "sun386-nat.c", line 219: unknown size "sun386-nat.c", line 221: f_st undefined "sun386-nat.c", line 221: FP0_REGNUM undefined "sun386-nat.c", line 222: member of structure or union required "sun386-nat.c", line 222: cannot recover from earlier errors: goodbye! *** Error code 1 >From what i could guess, in the first case the errors are due to the non standard format of sun386 a.out files (coff ``mixed'' with a.out at least in the headers) but i could not find a satisfactory solution (except commenting out the affected code). The second one in did not completely understand. Apparently the is ``not'' included because of the #define _EXEC_ in tm-sun386.h. I tried to compile gdb because I had problems compiling gcc-2.3.3: first i got a warning from as when compiling cse.c (first pass, compiling with stock compiler): cc -c -DIN_GCC -g -I. -I. -I./config cse.c Assembler: cse.c aline 16087 : Warning: Table overflow: some optimizations lost (Labels) Then it hanged when first using the generated cc1 to compile libgcc2.a it seems that cc1 is stuck in a cpu-bound loop: if [ -f libgcc2.ready ] ; then true; else touch libgcc2.ready; fi rm -f tmplibgcc2.a ; ar rc tmplibgcc2.a ${name}.o; rm -f ${name}.o; done _muldi3 <= Here it HANGS!!! (cc1 neverterminates) Any help would be GRATELY appreciated. [Unresolved - Stephen] ----------------------------------------------------------------------- 2-9. GNU EMACS 18.59 ----------------------------------------------------------------------- I had no problems compiling GNU Emacs on the 386i. I used GCC 2.3.2 running on SunOS 4.0.2. Here is a simplifed explanation of how to do it... - Get the compressed file (emacs-18.59.tar.z) and expand it into a directory to compile under. [Note: .z is different than .Z, the small one uses GNU's gzip program not the UNIX compress program] $ zcat emacs-18.59.tar.z | tar xvf - - Edit the makefile and change any directories you do not like... (I changed /usr/local/emacs to /usr/local/lib/emacs, cause I did not want to clutter up my /usr/local directory) LIBDIR=/usr/local/lib/emacs BINDOR=/usr/local/bin MANDIR=/usr/local/man - If you want an optimized editor, edit ./src/ymakefile and specify it by changing the CFLAGS line to reflect that.... change: CFLAGS= C_DEBUG_SWITCH ... to: CFLAGS= C_OPTIMIZE_SWITCH ..... - Copy ./src/config/h-dist to ./src/config.h and edit it to include 386i include files. $ cp src/config.h-dist src/config.h These lines replace the #include lines in config.h #include "s-sunos4-0.h" #include "m-sun386.h" You may want to check other settings in config.h for XWindow capability, that is if you want it. #define HAVE_X_WINDOWS - Make the sucker... (or just do the next step and install at the same time) $ make all - Install it.... $ make install That's all there is to it. My version appears to work fine, I have used it for editing, sending mail, etc. I have not tried some of the news reading functions, etc. So you are on your own there, I imagine it works. GNU EMACS Pointers... --------------------- ----------------------------------------------------------------------- 2-10. PERL version 4.036 ----------------------------------------------------------------------- I give up, what do I have to tweak to get perl-4.036 to compile on my sun386i? It dies looking to link with h_errno - In the Configure script. When you are prompted for additional libraries enter: "-ldbm -lm -lresolv" - When you run the tests, it'll complain about a missing program. Copy that missing program by hand to (presumably) /usr/local/bin, and re-run the tests. These two hacks were the only things I had to do to install perl-4.036 on my 386i with SunOS 4.0.2. PERL Pointers... ---------------- ----------------------------------------------------------------------- 2-11. XWindows version 11 release 5 ----------------------------------------------------------------------- XWindows 11 release 5 can be compiled on the roadrunner. A few importlant things should be said first; 1. Use GCC, the sun compiler will not work; Edit 'site.def' and define HasGcc to be "YES" #define HasGcc YES Edit 'sun.cf' and define the right SunOS 4.0.2, and other things. 2. Xload is messed up, it cannot find some 'kvm' routines. You can hand edit the make file and add -lkvm on the SYS_LIBRARIES= line, and it should compile fine. SYS_LIBRARIES = -lkvm 3. When you start you make, use -DNOSTDHDRS for the make; make World BOOTSTRAPCFLAGS="-DNOSTDHDRS" I have compiled almost every patchlevel of X11R5 up to patch #26 with this method and have had no problems other than those mentioned. X11R5 Pointers... ----------------- ftp://cxc1.msu.edu/386i/software X11R5.26.sun386i.bin.tar.filelist X11R5.26.sun386i.bin.tar.Z X11R5 binaries for sun386i (and a filelist). =20 X11R5.26.sun386i.man.tar.filelist X11R5.26.sun386i.man.tar.Z X11R5 manual pages for X11R5. ----------------------------------------------------------------------- 2-12. XWindows version 11 release 6 ----------------------------------------------------------------------- Problems building shared libraries with GCC caused my build to die, and I have not had the time to look into the problem. Anyone get it to work yet? X11R6 Pointers... ----------------- ---------------------------------------------------------------------- 2-13. GnuPlot 3.5 ---------------------------------------------------------------------- GnuPlot has 2 problems compiling on the 386i: 1. Header file inclusion is really messed up 2. The 386i enforces non-writeable data segments Patches to version 3.5 of GnuPlot are available. The patches include commenting out the redundant (and erroneous) #includes of time structures, and a fix to gnuplot_x11 (where they try to sscanf() constant character string). ... under construction, the file below may not be available ... GnuPlot Pointers... ------------------- ftp://sahsun.usmacs.maine.edu/pub/sun386i gnuplot-patches.tar.Z Patches to GnuPlot source files to make them compile correctly on the sun386i. ---------------------------------------------------------------------- 2-14. HP LaserJet Printcap Entries ---------------------------------------------------------------------- Printcap Entry: --------------------------- CUT HERE ---------------------------- lp|LaserJetIII:\ :pw#80:\ :lp=/dev/pp0:\ :sd=/var/spool/(null):\ :br#9600:\ :fs#06030:\ :fc#0300:\ :of=/usr/lib/hplaserjet: --------------------------- CUT HERE ---------------------------- hplaserjet filter script: --------------------------- CUT HERE ---------------------------- #!/bin/csh -f # # @(#)hplaserjet 1.1 88/10/27 Sun Microsystems Inc 1988 # # # This is the output filter form use with HP laserjets I and II. # It is called via the of entry in the generic_hp printcap entry # All it does is send the escape sequence to the printer, so that: # CR is mapped to CR # LF is mapped to CR LF # FF is mapped to CR FF /usr/bin/echo -n 'k2G' #enable wraparound /usr/bin/echo -n 's0C' /usr/bin/cat if ($status == 0) then exit 0 else exit 1 endif --------------------------- CUT HERE ---------------------------- Note that I've substituted and for the actual characters in the script. Edit the actual two characters in each line before trying to use the script, of course. [Rick Emerson] ---------------------------------------------------------------------- 2-15. PPP (ppp-sunos4.1.pl6.tar.Z) on a 386i ---------------------------------------------------------------------- Here is a summary of the steps I had to go through to bring up PPP on my 386i. 1) PPP Software: I used the ppp-sunos4.1.pl6.tar.Z package and installed it as is. 2) setting up the modem: I have a Multitech II V32bis/V42bis modem, the only non-default set-up I required was to get it to use hardware RTS/CTS flow control. 3) dialing up: at work we have a Telebit netblazer, with a couple of dial-back modems. I use a combination of a shell script and tcl/expect to dial up work, wait for the dial-back, run ppp (and then kill the now spurious tip process which eats lots of CPU). Here's the shell script, ppp-start is the expect script and all the rest is just messing around to kill the tip process(es) I use to communicate with the modem, but which get confused and gobble CPU when ppp is actually running. --------------------------- CUT HERE ---------------------------- #!/bin/sh find() { ps -ax | egrep " $1 " | egrep -v "egrep" |\ sed 's/^\([ 0-9]*\) .*/\1'/ } PPP=`find ppp` TIP=`find tip` if [ ! -z "$PPP" -o ! -z "$TIP" ]; then echo "ppp or tip already running, ppp: $PPP, tip: $$TIP" exit 1 fi ppp-start & while true; do PPP=`find ppp` if [ ! -z "$PPP" ]; then break; fi sleep 30 done PIDS=`find tip` echo "Killing tip processes: $PIDS" kill $PIDS exit 0 --------------------------- CUT HERE ---------------------------- Here's the expect script: --------------------------- CUT HERE ---------------------------- #!/usr/local/bin/expect spawn tip UNIX-mtechII expect "*connected*" send "ATZ\r" expect "OK" send "ATX1\r" expect "OK" # use RTS/CTS send "AT&E4\r" expect "OK" send "ATDT\r" expect "NO CARRIER" send "AT&E4\r" expect "OK" send "ATX1\r" expect "OK" set timeout 60 expect "*RING*" exec ppp mru 1500 192.5.254.52:192.5.254.47 /dev/cua0 --------------------------- CUT HERE ---------------------------- I'm not sure the second set of AT&E4 and ATX1 are really necessary, they got put in when I was debugging and never got taken out! As you've probably guessed this scripts are modelled on those supplied Karl Fox in the ppp release I used. I just preferred to use expect in place of his chat program. So far, so good. IP routing, or put another way, now the real work/fun starts! My 386i, dredd, has two ip interfaces - ie0 (which is broken 'cos I don't have an ethernet or a transceiver at home) and ppp0, after booting sunos gives me two routes: Destination Gateway Flags Refcnt Use Interface 192.5.254.0 dredd U 21 1480 ie0 loopback localhost U 24 181 lo0 The first of these will never work, cos there's no ethernet, but all is well since I don't try and talk to anything else over the ethernet - or so I thought, removing it appears to trash yp!? Karl's suggestions for routed use two routes in the /etc/gateways file: net 0.0.0.0 gateway gatekeeper.ansa.co.uk metric 1 passive host dredd gateway dredd metric 0 passive on startup, routed then does the following: installs these routes and *deletes* 192.5.254.0 via ie0 it's a good job it deletes 192.5.254.0 via dredd over ie0 'cos it won't work. Now here comes the snag, as soon as I try and use ppp0, routed re-installs my new routes (from /etc/gateways) and also re-installs the ie0 (or forgets to remove it if it is added by ip). Once the ie0 route is back, all my data vanishes down my ie0 interface which is good approximation to /dev/null. Or rather all data destined for machines on the same subnet as me (i.e. at work) gets trashed, I can talk to the rest of the internet (see end). So, the solution I adopted is to avoid using routed and manaully install the routes I require as follows: /usr/etc/route -n add 0.0.0.0 gatekeeper.ansa.co.uk 1 /usr/etc/route add dredd dredd 0 /usr/etc/route -n delete 192.5.254.0 dredd This works and when running ppp adds its own route: gatekeeper.ansa.co.u dredd UH 0 0 ppp0 and at this point I can access the rest of the internet and all the machines at work. I suspect routed/IP gets confused because my home machine is on the same network (i.e. 192.5.254) as all the other's at work. Karl's setup at morningstar has all of the PPP machines on a differnet subnet. Given that IP has no way of telling that my machine is special (other than via its IP address) I'm happy to beleive this is the case. Ideally I'd like to move our PPP machines onto a differnet subnet and then be able to use routed. Can anyone offer any advice as to whether this is a correct understanding of what is happening? The fun was experimenting with things like removing the 192.5.254.0 via dredd over ie0 route before adding the new routes and then trying to use yellow pages. I even managed to blow away my X server a couple of times by trashing its network from underneath it - a good job I wasn't installing this for anyone else! [Cosmos Nicolaou] PPP Pointers... --------------- ---------------------------------------------------------------------- 2-16. SNAP Cannot Create New Users ---------------------------------------------------------------------- I can no longer create users with SNAP or from the login screen. The Sun386 claims I should speak with my system administrator concerning the publickey file. Well. I AM the system administrator, and the manuals don't help much. The publickey seems like it's in fairly good shape. The books also suggested I should use newkey. Done already - and with no results. Yes I have had this problem.. The way I found out what was causing it was trial and error and many sleepless nights.. :) OK.. Have you edited ANY of the files that snap needs to change, so that a new user can be added.. These files include, passwd, group, etc... If you used either edit or vi on the files snap will no longer WANT to change or add to the files.. The way I found to get around all of this.. is to use sunview and then the edit file option/program. Edit the passwd and group file and then save them back to the disk. For SOME UNKNOWN reason snap wants to see something on the bottom of the file or the way the file has been saved before it will attempt to add or delete users... Hope this helps... Its the way I fixed snap on my machine... [Brett] ---------------------------------------------------------------------- Forget SNAP ! Setting up new users is trivial. 1. Edit /etc/passwd with "vipw". Add a line for the new user, with no encrypted password. Make sure UID numbers are correct (i.e. same as that user has on other machines wich may cross-mount the user's home directory.) 2. Go to ~users, run the script "copy_home", suitably modified to suit your needs (mine does a chown -R on the new user's home directory, among other things.). 3. Put a logical link for the new user into the /exports directory system if that user wants to mount his or her filesystem remotely. Put into /etc/exports. Run exportfs -a. (This could very easily be put into copy_home). 4. Edit /etc/aliases if mail is involved. Run "newaliases" (though I think sendmail updates the compiled aliases files automatically anyway). 5. Log in as the new user, set up a temporary password with "passwd", test the account (e.g. mail). Note that the model users' home directory in ~users/defaults can be edited to your heart's content. This procedure is much better in my view than running SNAP. And you could automate quite a bit of it in the "copy_home" script. If SNAP is the only reason you keep YP running, get rid of both ASAP! You're much better off learning about this stuff than being kept in ignorance by SNAP. The 386i is quite a nice UNIX box without all this YP/SNAP stuff intended once upon a time to quell the fears of UNIX-phobes in the business world. [Stefan Mochnacki] ---------------------------------------------------------------------- 2-17. Removing NIS YellowPages ---------------------------------------------------------------------- Temporarily remount your /usr partition write-enabled and rename /usr/etc/ypbind and /usr/etc/ypserv to something else (see Ch.14, p.369 of "System and Network Administration", Part No. 800-1733-10, Rev. A, 9 May 1988). Addresses and netmasks may need to be more explicitly stated in "ifconfig" statements and the like, and corresponding "if" and "fi" statements need to be commented out. [Stefan Mochnacki] ============================== 3-0. Hardware for the Sun386i ============================== ----------------------------------------------------------------------- 3-1. NVRAM Problems and Solutions (lots of problems) ----------------------------------------------------------------------- A Bad, or nearly bad NVRAM/TIMER chip causes many, very strange, problems on the 386i. The most common problems are listed below: * On power up, after the Auto booting in progress.... it conplains that "ethernet is not properly connected, boot can not continue." Usually a disk address and loading vmunix message will appear. * A claim by the system during bootup that something is newly connected to the ethernet port. * Later in the bootup, because it has falsely concluded that there's something connected there, additional tweaking is done on the port. It is this that leads to the "ie0: init failed: no intr:" message. * Most conspicuously, volatility of the non-volatile RAM (NVRAM). * With the system up, it is easy to examine the content of NVRAM, using maybe od or some such. The timer is in the last few words. You should see it counting on successive examinations if it's working ok. * The system will die a strange, tortured death (beginning around six hours after bootup by one account). One by one, windows would die or partially die, until there was nothing left. These problems indicate you will need to replace the NVRAM/TIMER. The exact part number is MK48T02B25 2Kx8 Zeropower (TM) / Timekeeper (TM) RAM by SGS-Thomson Microelectronics. It fits in a socket on the CPU board (no soldering required). After it's installed its content have to be initialized, of course. It's possible to boot up with garbage in most of the bytes, after which a procedure can be used to initialize all of it. The procedure and some helpful utilities have been posted to the 386i list, they are collected in SUN-NVRAM.TXT on some 386i ftp sites. NVRAM Pointers... ----------------- ftp://sahsun.usmacs.maine.edu/pub/sun386i/sun-nvram.txt Copy of NVRAM utilities created by John E. Kreznar. ----------------------------------------------------------------------- 3-2. NVRAM Suppliers (Sun Battery) ----------------------------------------------------------------------- Solar Systems, phone #'s: 800-253-5764 if you are in the States or 206-869-9354. This is an aftermarket product and cost approximately $150 US last year. They ship overnight COD. ... A good (cheaper!) supplier would be nice if people have them... ----------------------------------------------------------------------- 3-3. Sun386i Memory Expansion ----------------------------------------------------------------------- "It looks like the 386i SIMMs are 80 ns, whereas the spec for the PC is 100 or 120ns. Does anyone know if these 386i simms will work OK in the PC?" Yes; they should be OK. I have swapped SIMMs between my 386 PC and the 386i model 250 several times. My 386i runs OK with 100ns SIMMs. [John ] Mine also works fine with PC SIMMs [Stephen Houser] ----------------------------------------------------------------------- 3-4. Is there a 486 upgrade for the 386i? ----------------------------------------------------------------------- Nope. The Cyrix was rumored to work, but no one will admit they have one running. There were also rumors of Sun producing a 486 upgrade motherboard, to which one person replied: I have definately seen some (actually running) albeit within Sun's offices. Apparently they made a few dozen prototypes and actually shipped a couple to really power desparate customers before the Sparc project killed the whole intel based line. The product was offered only as a CPU board swap for existing systems. As far as I know the ones made all had some problems above and beyond what goes on with a normal 386i which may explain why nobody claims to be running one today. [TEG@vicor.com] ----------------------------------------------------------------------- 3-5. Large SCSI disks... ----------------------------------------------------------------------- Larger drives will work fine on a Sun. You are still limited to 2GB filesystems (i.e partitions) by SunOS and Solaris. The only "gotcha" is that you cannot low level format this drive with the format program. The sd device driver times out before the format is complete and slams a scsi bus reset which then aborts the format on the drive leaving it in a unuseable state. As long as you don't format the drive you should be safe. So get a pre-formatted drive, or format it on another Sun (Sparc?) that does not have this problem. Here are some disks people are using in their RoadRunners (capacities are 'formatted' capacity): Seagate, ST702N (Wren V), 702MB (really 600MB) Have only used 400MB of it so far (in one partition). Used the SPARC format.dat entry. ST43400N (Elite 3), 3.15 Gig Have only been able to use 75 sectors per cylinder giving 2 Gig formatted capacity. The drive has a variable number of sectors per cylinder [75-109?] Micropolis, 1908-15, 1381MB CDC, Wren IV, 330 Meg Wren V, 600 Meg Wren VI, 600 Meg Fujitsu, 2623SA, 680 Meg M2263SA, 670 Meg M2266SA, 1.2 Gig M2624FA, 520 Meg Disk Drive Pointers... ---------------------- ftp://sahsun.usmacs.maine.edu/pub/sun386i sun-disks.txt Copy of 'format.dat' entries for large SCSI disks. ----------------------------------------------------------------------- 3-6. Running around topless (i.e. without a framebuffer/monitor) ----------------------------------------------------------------------- ... under construction ... --------------------------------------------------------------------- This is the end of the FAQ. Stephen Houser This is the end of the FAQ. Stephen Houser Stephen ______________________________________________________________________ Stephen Houser (N1QWF) http://csir1.usmacs.maine.edu/~houser University of Southern Maine Academic Computing Services 144 Luther Bonney Hall BITNET: houser@portland 96 falmouth Street Internet: houser@usm.maine.edu Portland, Maine 04103 AT&T: (207)780-4588 From ozone@spies.com Mon Jan 10 01:21:48 2000 Received: from sirus.itc.yorku.ca by ditsydh.syd.dit.csiro.au with SMTP id AA04573 (5.64+/IDA/DIT-0.9 for ken); Thu, 22 Sep 94 10:36:57 +1000 Received: from wiretap.spies.com by sirus with smtp (Smail3.1.28.1 #5) id m0qncqc-0011iwC; Wed, 21 Sep 94 20:21 EST Received: by wiretap.spies.com (4.1/SMI-4.1/JBS) id AA07973; Wed, 21 Sep 94 17:20:53 PDT Date: Wed, 21 Sep 94 17:20:53 PDT From: ozone@wiretap.spies.com (James Hultman) Message-Id: <9409220020.AA07973@wiretap.spies.com> To: sun-386i@itc.yorku.ca Subject: I HAVE PROOF This is an actual Sun document. SRDB 2246 states: Year: 1990 Month: December Title: Sun386i: Mom & Pop Sun386i: Mom & Pop ------- --- --- In the Sun Price List, Sun386i/150, 150X, or 250 upgrade to Sun486i have the same order number UG-RR-350. It indicates that the upgrade includes CPU board, 486i POP board and cables. The 486i upgrade board has been designed to be compatible with all memory on all Sun386i systems ever shipped. The Mother board holds memory and AT Bus and other logic. This is referred to as MOM. POP is the actual CPU Module which holds the 486 chip and plugs into the mother board. From wagner@weru.ksu.edu Mon Jan 10 01:21:48 2000 Received: from sirus.itc.yorku.ca by ditsydh.syd.dit.csiro.au with SMTP id AA01164 (5.64+/IDA/DIT-0.9 for ken); Thu, 22 Sep 94 14:36:59 +1000 Received: from zingg.weru.ksu.edu by sirus with smtp (Smail3.1.28.1 #5) id m0qngdK-0011ixC; Thu, 22 Sep 94 00:23 EST Received: from localhost (wagner@localhost) by zingg.weru.ksu.edu (8.5/8.5) id XAA12547; Wed, 21 Sep 1994 23:21:55 -0500 Date: Wed, 21 Sep 1994 23:21:55 -0500 From: Larry Wagner Message-Id: <199409220421.XAA12547@zingg.weru.ksu.edu> To: sun-386i@itc.yorku.ca Subject: Re: I HAVE PROOF X-Sun-Charset: US-ASCII > From ozone@spies.com Wed Sep 21 19:33 CDT 1994 > > This is an actual Sun document. SRDB 2246 states: > > Year: 1990 > Month: December > Title: Sun386i: Mom & Pop > > Sun386i: Mom & Pop > ------- --- --- > > In the Sun Price List, Sun386i/150, 150X, or 250 upgrade to Sun486i have the > same order number UG-RR-350. It indicates that the upgrade includes CPU board, > 486i POP board and cables. > Well, you at least had an order number. The Sun salesdroids I talked to always said there wasn't one yet. They did know that the list price would be $4995 and sent me a glossy 1 page brochure that discussed the upgrade. The brochure (printed 1/90) said: 25MHz 80486 processor delivers 12-MIPS (the 25MHz 386i/250 with cached memory board was only rated at 5-MIPS) floating pt performance would be up to 5 times better over the 80387 24MB memory capacity (8MB on motherboard plus up to 16MB with original 386i memory boards) Synchronous SCSI implementation delivers 2 to 4 times I/O throughput of 386i (Anyone who has used a 386i as an NFS file server for PC's via PC/NFS or for other workstations would really have appreciated this - there was nothing like typing away on the console and not have the screen update for several seconds when heavy disk I/O was being performed) "Your existing applications run on the SUN 486 upgrade - faster than ever before - with no changes" (direct quote from brochure. They even claimed that more than 100 UNIX software products from Sun and third-party vendors were available at the time for the 386i) "Your investment in the Sun386i workstation is fully protected with the Sun 486 upgrade." Another amusing quote since Sun didn't actually follow through with protecting our investment in the 386i - the real shame is they had produced the product and then didn't make it available (-: Hmm, if they had made it available, we probably would have eventually upgraded both of our 386i's and we would have been discussing putting in a clock-doubled 486 processor instead of trying to get upgraded past the 386 CPU today! Maybe someone knows what Sun did with those that were manufactured and never sold (I was told once that it was a significant number). Better yet, someone finds out and they just mysteriously start showing up in the mail to those that wanted one (or more) (-: Larry E. Wagner | wagner@weru.ksu.edu USDA-ARS Wind Erosion Research Unit | wagner@ksu.ksu.edu 105B East Waters Hall, KSU | phone: (913) 532-6807 Manhattan, KS 66506 | fax: (913) 532-6528 From alembic.crystel.com!cz@ssg.com Mon Jan 10 01:21:48 2000 Received: from sirus by ditsydh.syd.dit.CSIRO.AU (8.6.8.1/1.06S) id QAA20925; Sun, 4 Dec 1994 16:22:47 +1100 Received: from uu7.psi.com by sirus with smtp (Smail3.1.28.1 #5) id m0rE9lv-0011j6C; Sun, 4 Dec 94 00:46 EST Received: from alembic.crystel.com by uu7.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA25267 for ; Sat, 3 Dec 94 23:41:00 -0500 Received: by ssg.com (5.65c/3.2.083191-System Support Group) id AA12305; Sun, 4 Dec 1994 02:47:43 GMT Received: from alembic.crystel.com by uu7.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA17117 for sun-386i; Sat, 3 Dec 94 21:40:00 -0500 Received: by alembic.crystel.com (NX5.67c/NX3.0M) id AA06797; Sat, 3 Dec 94 21:39:35 -0500 Date: Sat, 3 Dec 94 21:39:35 -0500 From: Chris Zach Message-Id: <9412040239.AA06797@alembic.crystel.com> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: sun-386i@ssg.com Subject: Gutted the Timekeeper--Now what Well, after reading that recent post about taking the timekeeper chip apart, I dragged out my spare 386i, and opened it up. In the past, I was getting the fameous blank error on startup, followed by the ie0 no intr error. The status bar would also be yellow while booting, and the system would never acknowledge the ethernet. I opened it up, pulled the timekeeper chip. and went at it with a dremel cutting tool. I took off the battery//clock unit, figured out the polarity on the chip//tested the batteries (200mv, dead), and wrote everything down. >From there, it was a trip to radio shack to get a dual AAA battery case and some wire wrap hookup wire. I reattached the clock pins to the timekeeper chip, and wired the power leads from the chip to the AAA battery holder. Taped it all together, put it back in the 386i, and fired it up. It seems to have worked. No errors before booting, the status bar is green, but I still get the "ie0 no intr error". I suspect this is because the timekeeper is now full of garbage, and needs to be reconfigured. The question is how do I reconfigure the chip software wise? I can't find the NVRAM FAQ on the archive sites, perhaps someone can post a message stating what needs to be done. As for the battery replacement: If I had known which end of the chip was the power end, It would have been extremely simple. All one has to do is use a dremel cutting tool to sand down the end of the chip between the chip and the battery. Make sure you cut the wires leading to the battery with the dremel, then just solder two wires to the chip's leads and hook the other ends to a 3volt battery source. Mount the battery in the 386i with velcro, and you are in business. Based on the life of the lithium batteries on the TimeKeeper, I would estimate that AAA alkalines would last around 5-10 years before needing replacement. And replacement is simple. Total cost of this project was 1 hour of time, and about $6.00 in parts. I could post detailed instructions if anyone is interested. Sure beats $25-100 for a new chip. Chris Zach From tim@timwood.slip.netcom.com Mon Jan 10 01:21:48 2000 Received: from sirus by ditsydh.syd.dit.CSIRO.AU (8.6.8.1/1.06S) id GAA00930; Tue, 6 Dec 1994 06:15:10 +1100 Received: from timwood.slip.netcom.com by sirus with smtp (Smail3.1.28.1 #5) id m0rEiZz-0011j6C; Mon, 5 Dec 94 13:56 EST Received: by timwood.slip.netcom.com (4.0/SMI-4.0) id AA12380; Mon, 5 Dec 94 09:46:23 PST Date: Mon, 5 Dec 94 09:46:23 PST From: tim@timwood.slip.netcom.com (Tim Wood) Message-Id: <9412051746.AA12380@timwood.slip.netcom.com> Received: from unknown(192.168.127.3) by axolotl via smap (V1.3mjr) id sma012369; Mon Dec 5 09:45:43 1994 To: sun-386i@itc.yorku.ca Subject: Re: Gutted the Timekeeper--Now what X-Sun-Charset: US-ASCII > From alembic.crystel.com!cz@ssg.com Sun Dec 4 16:17:25 1994 > > [NVRAM surgery saga deleted] > The question is how do I reconfigure the chip software wise? I can't find > the NVRAM FAQ on the archive sites, perhaps someone can post a message > stating what needs to be done. Here is the FAQ I have put away for that NVRAM rainy day. It consists of two shell scripts, a C program and a data file. I also include another script I wrote for loading a new NVRAM. All these should reside on the root file system for accessing in single-user mode when the chip start to show signs of failing. Note: I have not tested this stuff by writing the NVRAM itself, just by comparing input and output from regular files. HTH, -TW --- Date: Sat, 30 May 92 23:25:42 PDT From: jkreznar (John E. Kreznar) To: uunet!sun-386i@compaq.com Subject: NVRAM Utilities By popular demand, here is my little suite of NVRAM utilities. I suppose I ought to wrap this stuff with shar or something, but I don't have time now to learn how to do that. The following one-line csh script, which I have in an executable file called dumpnvram, writes to standard output an od-derived dump of nvram; sed is used to swap bytes and separate them. od -xv /dev/eeprom | head -128 | sed "s/ \([^ ].\)\(..\)/ \2 \1/g" The following one-line csh script, which I have in an executable file called refdump, writes to standard output an nvram image compatible in format with that from dumpnvram above, but derived instead from the file nvram.source, given later in this posting. cut -f1 nvram.source | xtob | od -xv | sed "s/ \([^ ].\)\(..\)/ \2 \1/g" Thus, for example, you can give refdump > temp to produce a reference nvram image, and then give dumpnvram | diff - temp to compare actual nvram content with this reference. The "xtob" filter used above in refdump, and in my procedure to initialize nvram, is given by the following trivial C program, xtob.c: /* Filter reads pairs of hexadecimal digits and writes corresponding bytes. */ #include #include unsigned int getbyte (); unsigned int gethexdigit (); void main (int argc, char ** argv, char ** envp) { while (1) printf ("%c", getbyte ()); exit (0); } unsigned int getbyte () { return (gethexdigit () << 4) + gethexdigit (); } unsigned int gethexdigit () { int chr; while (1) { if ((chr=getchar()) == EOF) exit(EXIT_SUCCESS); if (chr >= '0' && chr <= '9') return chr - '0'; else if (chr >= 'a' && chr <= 'f') return chr - 'a' + 10; } } End of C program. Here is a makefile for xtob: xtob: xtob.c gcc -g -Bstatic -o xtob xtob.c Finally, the remainder of this posting is my file "nvram.source" itself. As you can see, it is derived from a piece of Sun internal email. Sun FSE Chris Demke was kind enough to send it to me during my first episode of this problem last September. It has little information beyond that in the PROM manual, but it is machine-readable. I took the original piece of email, prefixed each line with a tab character, and then keyed in actual nvram bytes in hexadecimal. My comments within the file explain why I did this. Although this is good enough to work, I'm not at all sure I've got it right. For example, I have zeros in several checksum fields. Does the PROM ignore fields with incorrect checksum? If so, how exactly is the checksum supposed to be computed? I have not been able to boot from floppy. Might the reason be something I've got wrong in this file? 91 Sep Thu 19 10:54 This file was obtained by editing the indicated piece of e-mail. My goal was to obtain a file retaining all the descriptive commentary present in the original (plus more I may add) while also including the actual data to be stored in NVRAM, and in a way that permits loading NVRAM directly from this ``source'' file using a simple procedure. To do this, I adopted the following simple ``assembler language'': Any line of this file beginning with a string of hexadecimal digits represents information to be stored in successive bytes of NVRAM. Such lines must begin with an even number of digits, two per byte. Anything in the line following the last hexadecimal digit is regarded as a comment and is ignored. By convention, I use tab as the first character following the data. An implication of this is that ALL bytes of the data must be represented, even unused ranges, i.e., I have nothing like the ``org'' pseudo-op of many assembler languages. The NVRAM has 2K bytes, so the total number of hexadecimal digits at the beginning of lines in this file must total 4096. (An exception might be if an unused range at the very end is not coded.) So the following simple pipeline will load the NVRAM directly from this file: cut -f1 nvram.source | xtob > /dev/eeprom where xtob is the simple hex to binary filter defined in this directory. (I tried awk and dc but couldn't get either to output zero-bytes.) From: uunet!West.Sun.COM!Christopher.Demke (Christopher Demke - FSE Sun SFValley - 818-905-0200) To: Jkreznar@ininx.com Before starting an install or any time that you appear to be having a problem with a RR be sure to check all of the NVRAM settings first. Most likely the unknown tape drive message occured because it was not identified by the NVRAM. This was assembeled from various emails on the subject, thanks to all the contributing sources wherever you are. NVRAM is modified in the same manner as other SUN systems. 00000000 00 - 03 Invalid- written in CPU diags 000000000000 04 - 09 Write counters for diag area of NVRAM (should all be the same) 0000 000000 0c - 0e Diag checksum (intended to be the same) 00 31b4d928 10 - 13 date of last hardware system upgrade in seconds since 1-Jan-70 (fun) (That's 28d9b431=685356081, or ~1991 Sep Fri 20 01:40 PDT. - jek) The following areas are identical to other Sun's 08 14 Memory installed (in hex) 08 15 Memory to test (in hex) 00 16 Screen size - 00=1152x900, 12=1024x1024, 13=1600x1280, 14=1440x1440 00 17 Watchdog reset action - 00=go to monitor level, 01= Power-on reset 00 18 Operating system bootup - 00=poll, 12=specify boot device 73 19 Boot device - 1st. character s 64 1a Boot device - 2nd. character d 00 1b Controller number 02 1c Unit number 00 1d partition number 00 1e non-sun keyboard type (currently ignored) 01 1f primary terminal 00=use serial port A, any other=use video monitor 00 20 Sun banner 00=display, 12=use custom 00 21 Keyboard click 00=OFF, 12=ON 66 22 Diag boot device - 1st. character f 64 23 2nd. character d 00 24 controller 00 25 Unit number 00 26 Partition number 00 28 - 4f Diag path 2f7374616e642f6469616700 /stand/diag 000000000000000000000000 00000000000000000000000000000000 50 50 Hi-res size - number of columns 18 51 Hi-res size - number of rows 000000000000 00 58 Port A baud rate 00=9600 (default), 12=specify rate 25 59 Rate high byte (see page 363 of docubox-brown section) 80 5a Rate low byte (see page 363 of docubox-brown section) 00 5b Port A assert DTR/RTS 00=Yes, 12=NO 000000000000000000000000 68 - b7 ASCII banner 437573746f6d2042616e6e6572 "Custom Banner" 0000000000000000000000 00000000000000000000000000000000 80-8f 00000000000000000000000000000000 90-9f 00000000000000000000000000000000 a0-af 0000000000000000 aa55 b8 - b9 Test pattern to provide a known data test pattern to test NVRAM data lines b8 should be AA, b9 should be 55 000000000000 00000000000000000000000000000000 c0-cf 00000000000000000000000000000000 d0-df 00000000000000000000000000000000 e0-ef 00000000000000000000000000000000 f0-ff THE FOLLOWING AREA IS WHERE PROBLEMS USUALLY START 01 100 CPU (should be 01=present) 08 101 number of mb memory 00 102 Disk type 00=none, 01=91mb, 02=327mb 01 103 Diskette drive 00=none, 01=present 83 104 Display type 00=none, 80=hi-res color, 81=lo-res color, 82 =lo-res mono, 83=hi-res mono 01 105 Cartridge tape 00=none, 01=present 01 106 Floating point 00=none, 01=present 71 107 Checksum 71 is my WAG --jek 00000000000000 108 - 19e Not used 00 10f Update flag (diag. exec use only) 10 110 CPU rev. level (should be 10) 03 111 CPU artwork 01=1.5 (none in field) 02=2.0 03-3.0 ********************************************************************** correct values for location 111 are: 0x01 -- p1.5 cpu board 0x02 -- p2 cpu board 0x03 -- p3 cpu board 501-1241 p1.5 cpu n/a (you should not have this board) 501-1241 20MHz p2 cpu 150 501-1324 25MHz p2 cpu 250 501-1414 20MHz p3 cpu 150 501-1413 25MHz p3 cpu 250 ********************************************************************** 00 112 ECO rev. level (should be either 00 or 02) ********************************************************************** correct values for location 112 are: 0x00 -- p1.5 cpu board 0x00 -- p2 board with babe-01 0x02 -- p2 board with babe-02 0x00 -- p3 cpu board (all) to determine whether you have a p2 with a babe-01 or a babe-02, look at the revision number on the cpu card part number label. the babe-01 to babe-02 switch was made at different revision levels for 20MHZ and 25MHz p2 cpu cards. babe-02 should be found in rev 16 and later 20MHz p2 cpu cards. babe-02 should be found in rev 27 and later 25MHz p2 cpu cards. (or you can look at the BABE and see if it is a -02) I couldn't find the label, but I see no babe; 0300 is my guess. - jek ********************************************************************** 00000000000000000000000000 113 - 11f Reserved for kernel 00000000000000000000000000000000 120 - 118b unused/reserved 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 000000000000000000000000 SEE PAGES 366-367 FOR ADDITIONAL INFO ON THE FOLLOWING SETTINGS: 00 18c key table selector 58=use NVRAM key tables, any other=use prom tables 00 18d MVRAM locale specifier (used by OS) 00 18e keyboard ID 00 18f Custom logo selector 12=use NVRAM logo bit-map, any other=Sun logo map 00000000000000000000000000000000 190 - 20f NVRAM lower case key table 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 210 - 28f NVRAM upper case key table 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 290 - 48f Custom logo 00000000000000000000000000000000 (from setting 18f to 12) 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00 490 LED register copy (used during POST phase) 00 491 POST loop on test 07 492 Prom mode control 07=normal, 06=diag 00 493 Default colors for foreground and background (not used) 02 494 Auto configuration messages during boot 00=none, 01=Sun3 (unix expert), 02=verbose (02 allows normal booting messages to appear on start-up) 0000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 000000000000 500 - 505 Write count - reserved (should be the same) 0000 000000 508 - 50a Checksum (should be the same) 0000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 600 - 700 Scratchpad 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 SOFTWARE AREA OF NVRAM 000000000000 700 - 705 Write count 0000 000000 708 - 70a Checksum 0000000000 (usually 0's) 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 I hope this helps all you RR people out there. Ken Harris --- TW's script: #!/bin/sh # ldnvram - dump out an NVRAM image as a series of adb longword-write # commands (for reloading new NVRAM chips). Adapted from dumpnvram by # John E. Kreznar, jkreznar@ininx.com, uunet!ininx!jkreznar, 4/4/94 TW if [ $# != 1 ]; then echo "Usage: ldnvram | adb -w " exit 1 fi od -Xvw4 $1 x | head -512 | sed 's/ /\?W /' TW's Data file (output of dumpnvram): 0000000 14 00 00 00 00 00 00 00 00 00 00 00 23 23 23 00 0000020 00 00 00 00 00 20 00 12 12 73 64 00 02 00 00 00 0000040 00 00 73 64 00 02 00 00 2f 73 74 61 6e 64 2f 65 0000060 78 65 63 75 74 69 76 65 00 00 00 00 00 00 00 00 0000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000120 00 00 00 00 00 00 00 00 00 25 80 00 00 00 00 00 0000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000260 00 00 00 00 00 00 00 00 55 aa 00 00 00 00 00 00 0000300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000320 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000340 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000400 01 08 01 01 82 01 00 8f 00 00 00 00 00 00 00 aa 0000420 10 03 00 01 00 00 00 00 00 00 00 00 00 00 00 00 0000440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000460 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000500 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000520 00 00 43 00 00 00 52 00 00 00 00 00 00 00 00 00 0000540 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000560 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000600 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000620 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000640 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000660 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000700 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000720 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000740 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 43 0000760 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7e 0001000 00 01 02 00 00 00 00 00 00 00 00 00 00 00 00 00 0001020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001320 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001340 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001460 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001500 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001520 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001540 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001560 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001600 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001620 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001640 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001660 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001700 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001720 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001740 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0001760 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002220 00 00 07 00 02 00 00 00 00 00 00 00 00 00 00 00 0002240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002320 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002340 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002460 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002500 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002520 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0002540 00 00 00 00 ff 00 00 00 ff 00 00 00 57 01 fe ff 0002560 02 00 00 00 00 00 00 00 b6 1f fe ff 68 00 00 00 0002600 97 00 00 00 94 05 00 fd 23 1f fe ff 0d 00 00 00 0002620 ff ff 00 00 a0 05 00 fd a3 78 fe ff 0d 00 00 00 0002640 b0 05 00 fd b4 05 00 fd 23 1f fe ff 0d 00 00 00 0002660 00 07 00 00 c0 05 00 fd a3 78 fe ff 0d 00 00 00 0002700 cc 05 00 fd 81 78 fe ff 0d 00 00 00 e4 05 00 fd 0002720 77 79 fe ff 0a 00 00 00 ec 05 00 fd f0 05 00 fd 0002740 0a 00 00 00 9c 06 00 fd f3 2d fe ff 72 6e ff ff 0002760 06 00 00 00 74 8d ff ff 00 00 00 00 00 00 00 00 0003000 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 0003020 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 0003040 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 0003060 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 0003100 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 0003120 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 0003140 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 0003160 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 0003200 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 0003220 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 0003240 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 0003260 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 0003300 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 0003320 80 80 80 80 17 00 16 00 00 00 30 00 00 00 20 00 0003340 00 00 00 00 00 00 10 00 00 00 40 00 00 00 40 00 0003360 00 00 40 00 31 aa aa 55 65 8d ff ff 01 ac fe ff 0003400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0003420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0003440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0003460 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0003500 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0003520 00 00 00 78 56 34 12 00 00 00 00 00 00 00 00 00 0003540 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0003560 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0003600 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 0003620 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0003640 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0003660 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0003700 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0003720 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0003740 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0003760 00 00 00 00 00 00 00 00 00 44 20 17 05 04 04 94 Note that the output of dumpnvram does *not* form the input to ldnvram. From hysell@itc.Kodak.COM Mon Jan 10 01:21:48 2000 Received: from sirus by ditsydh.syd.dit.CSIRO.AU (8.6.8.1/1.06S) id XAA28790; Fri, 9 Dec 1994 23:44:11 +1100 Received: from Kodak.COM by sirus with smtp (Smail3.1.28.1 #5) id m0rG5BE-0011jDC; Fri, 9 Dec 94 08:16 EST Received: from itc.kodak.com by Kodak.COM (5.61+/2.1-Eastman Kodak) id AA04066; Fri, 9 Dec 94 07:16:33 -0500 Reply-To: hysell@itc.Kodak.COM Received: from runner.itc.kodak.com by mailroom.itc.kodak.com with SMTP id AA00629 (5.65c/IDA-1.4.4 for ); Fri, 9 Dec 1994 07:15:00 -0500 Received: by runner.itc.Kodak.COM (4.1/SMI-4.1) id AA01394; Fri, 9 Dec 94 07:14:56 EST Date: Fri, 9 Dec 94 07:14:56 EST From: hysell@itc.Kodak.COM (John D. Hysell) Message-Id: <9412091214.AA01394@runner.itc.Kodak.COM> To: sun-386i@itc.yorku.ca Subject: Re: NVRAM replacement/repair Don Howard says: >I've managed to get the Timekeeper NVRAM chip out of my machine and separated >the ram from the batteries. I understand there has been recent discussion on >the list regarding replacing the batteries. I'd appreciate it if someone >could send me the description of this process. I guess I mostly need to know >the voltages and polarities to be applied to the leads coming from the ram >package. Well, I think I started this mess (but haven't done more on it for a week due to other more pressing business, so others may have passed ahead and may offer more information...) After you pry the battery pack off of the memory chip, you should see 2 wires sticking out of the top and bottom ends of the pack. The flatter wires are the 6 VDC power leads (you should be able to see some voltage here, but far less than 6 volts if the batteries are really dead. Use this voltage to determine polarity - if I remember, negative is on the right while looking down onto the chip. CAVEAT READER - my memory is not all that good - check it yourself! I am told that the second pair of wires is for a crystal or resonator that the chip uses for its timing base. I plan to soak my old battery pack in solvent and disolve away the potting material to see what is in there. (I have a second dead Timekeeper, so I can destroy one for curiosity's sake...) You need to re-attach the timing device to the bottom pins, and apply a 6vdc power source to the top two pins. - I plan on using a 6vdc lithium pack that are commonly used for 35mm cameras and 386/486 PCs - that should last a good long time in this application and be simple/cheap to replace again later. good luck. From MMLDHaywar@aol.com Mon Jan 10 01:21:48 2000 Received: from sirus by ditsydh.syd.dit.CSIRO.AU (8.6.8.1/1.06S) id HAA08251; Sat, 17 Dec 1994 07:29:53 +1100 From: MMLDHaywar@aol.com Received: from mail04.mail.aol.com by sirus with smtp (Smail3.1.28.1 #5) id m0rIjZA-0011j6C; Fri, 16 Dec 94 15:47 EST Received: by mail04.mail.aol.com (1.38.193.5/16.2) id AA02294; Fri, 16 Dec 1994 14:44:03 -0500 Date: Fri, 16 Dec 1994 14:44:03 -0500 Message-Id: <941216144402_7889506@aol.com> To: sun-386i@itc.yorku.ca Subject: NVRAM innards Results of further NVRAM adventures. I hope you read this in a fixed font. Upon taking the chip apart, we found: +--------------------------+ | | to xtal -| Ram Chip |-to battery + to xtal -| |-to battery - +---> |o | | +--------------------------+ |pin 1 mark upside down battery pack: |pin 1 mark | +--------------------------+ +---> |o | from xtal -| XTAL BATTERY |-from battery - from xtal -| "MC 38" "Li 3v BR1225" |-from battery + | | +--------------------------+ We haven't put it back together yet, and probably won't until after 1/1/95, but I thought I'd pass this along in the meantime. It looks like we might be able to use the crystal. Don Hayward mmldhayward@aol.com Mote Marine Laboratory Sarasota FL 34237 813-388-4441