I picked up a bunch of old Sparc hardware a few weeks ago. A SPARC 5, a SPA= >RC 20 and an Ultra 2.
None of them will boot a Solaris kernel. Tried Solaris 2.6 and 2.7.
All of them report "The IDPROM contents are invalid" or similar. Is that th= >e common cause of them not booting?
I suspect the main reason your SS20 doesn't boot is from bad memory
though.
Hi all,
I picked up a bunch of old Sparc hardware a few weeks ago. A SPARC 5,
a SPARC 20 and an Ultra 2.
None of them will boot a Solaris kernel. Tried Solaris 2.6 and 2.7.
All of them report "The IDPROM contents are invalid" or similar. Isthat the common cause of them not booting?
On 2016-12-28, Foggy <ihardcas@gmail.com> wrote:
Hi all,
I picked up a bunch of old Sparc hardware a few weeks ago. A SPARC 5,
a SPARC 20 and an Ultra 2.
None of them will boot a Solaris kernel. Tried Solaris 2.6 and 2.7.
O.K. First off, I believe that all of the Ultra SPARCs require
at least Solaris 8 or 9.
DoN. Nichols wrote:
On 2016-12-28, Foggy <ihardcas@gmail.com> wrote:
Hi all,
I picked up a bunch of old Sparc hardware a few weeks ago. A SPARC 5,
a SPARC 20 and an Ultra 2.
None of them will boot a Solaris kernel. Tried Solaris 2.6 and 2.7.
O.K. First off, I believe that all of the Ultra SPARCs require
at least Solaris 8 or 9.
2.5.1 was the first release with UltraSPARC support, IIRC.
DoN. Nichols wrote:
On 2016-12-28, Foggy <ihardcas@gmail.com> wrote:
Hi all,
I picked up a bunch of old Sparc hardware a few weeks ago. A SPARC 5,
a SPARC 20 and an Ultra 2.
None of them will boot a Solaris kernel. Tried Solaris 2.6 and 2.7.
O.K. First off, I believe that all of the Ultra SPARCs require
at least Solaris 8 or 9.
2.5.1 was the first release with UltraSPARC support, IIRC.
I picked up a bunch of old Sparc hardware a few weeks ago. A SPARC 5,
a SPARC 20 and an Ultra 2.
None of them will boot a Solaris kernel. Tried Solaris 2.6 and 2.7.
All of them report "The IDPROM contents are invalid" or similar.
Is that the common cause of them not booting?
On 2016-12-29, Drazen Kacar <dave@fly.srk.fer.hr> wrote:
DoN. Nichols wrote:
On 2016-12-28, Foggy <ihardcas@gmail.com> wrote:
Hi all,
I picked up a bunch of old Sparc hardware a few weeks ago. A SPARC 5,
a SPARC 20 and an Ultra 2.
None of them will boot a Solaris kernel. Tried Solaris 2.6 and 2.7.
O.K. First off, I believe that all of the Ultra SPARCs require
at least Solaris 8 or 9.
2.5.1 was the first release with UltraSPARC support, IIRC.
My error, then.
Now -- I have a couple of SS-5 boxen which I would like to be
able to run Solaris 10 on. :-) (No expectations, however.)
Hi all,
I picked up a bunch of old Sparc hardware a few weeks ago. A SPARC 5, a SPARC 20 and an Ultra 2.
None of them will boot a Solaris kernel. Tried Solaris 2.6 and 2.7.
All of them report "The IDPROM contents are invalid" or similar. Is that the common cause of them not booting?
cheers!
ih
"DoN. Nichols" <BPdnicholsBP@d-and-d.com> writes:
On 2016-12-29, Drazen Kacar <dave@fly.srk.fer.hr> wrote:
DoN. Nichols wrote:
Now -- I have a couple of SS-5 boxen which I would like to be
able to run Solaris 10 on. :-) (No expectations, however.)
Not possible. Sun4m (SS5, SS10, SS20) was dropped in Solaris 10
when the 32 bit kernel was dropped for SPARC.
Am 12/28/2016 08:19 PM, schrieb Foggy:
Hi all,
I picked up a bunch of old Sparc hardware a few weeks ago. A SPARC 5, a SPARC 20 and an Ultra 2.
None of them will boot a Solaris kernel. Tried Solaris 2.6 and 2.7.
All of them report "The IDPROM contents are invalid" or similar. Is that the common cause of them not booting?
cheers!
ih
Regarding the SS5 and SS20 (according to Mark Hendersons 'Sun NVRAM
Hostid FAQ') you can try the following procedure. I have done this >successfully several times. Power up the machine and press Stop-A.
At the "ok" prompt execute the following (08:00:20:e3:e4:e5 is an
example of the machines ethernet address)
Of course, my oldest Sun box (long retired, now) is a Sun
1/120 (MC68010 CPU) -- no chance for anything even semi-recent to
work there. :-)
On 1 Jan 2017 03:05:18 GMT
"DoN. Nichols" <BPdnicholsBP@d-and-d.com> wrote:
Of course, my oldest Sun box (long retired, now) is a Sun
1/120 (MC68010 CPU) -- no chance for anything even semi-recent to
work there. :-)
A 2/120 or a 1U ?
I believe that some versions of NetBSD can run on the 2/120 which might be fairly recent.
My old 2/120 in ComputerVision
casing
still has the last SunOs I put on it in the 1980s, and its
current owner & I plan to see if it will fire up later this year.
BTW do you have any spares for it? Could do with more memory to run
the CADCAM programs that are on there. (CIS Medusa for CADCAM
aficionados.)
2/120 -- on casters -- deskside cabinet. Intel Multibus cage
inside. Sun2 arcitecture. As I got it -- with a SCSI interfaced
drive inside, and a rather early QIC tape drive for loading the OS.
My old 2/120 in ComputerVision casing
Computervison? That does not ring a bell for me.
I'm trying to remember what the max memory was for that
system. The CPU could address up to a maximum of 16 MB, and I think
that the memory map in there topped out at either 4 MB or 8 MB -- a
bit thin for CAD/CAM work.
What flavor of G-code do the available
post-processors produce from it? (That is -- for what machines and controllers?) Are they flexible enough so they could be modified to
output for LinuxCNC (used to be EMC from NIST -- Extensible Machiine Controller -- before someone else claimed ownership of the EMC
name. :-)
I don't think that I have ans spares which would fit, unless I
stole them from the (also MultiBus) COSMOS CMS-16 which ran a Unisoft
port of v7 unix on a MC68000 (too old to run a virtual memory unix,
just plain swapping. :-)
On 29 Jan 2017 03:04:08 GMT
"DoN. Nichols" <BPdnicholsBP@d-and-d.com> wrote:
2/120 -- on casters -- deskside cabinet. Intel Multibus cage
inside. Sun2 architecture. As I got it -- with a SCSI interfaced
drive inside, and a rather early QIC tape drive for loading the OS.
QIC-4 IIRC. I could transfer stuff between work Suns & home on tape
until I had a Sparc1+ on my desk. Upgrading at home to a 3/50 then 3/60
with QIC-24 tape drives sorted that out.
My old 2/120 in ComputerVision casing
Computervison? That does not ring a bell for me.
Computervision, a CADCAM company in Boston, licensed the Sun-2 and then
-3 for their various product lines. I don't think they ever got CADDS
to run on the -2 but we got our Medusa line to work satisfactorily so
when CV announced the new hardware that is what I demonstrated. Even
better on the -3 of course. The CPU board in mine is a Sun one and the
other boards are standard Multibus from several vendors. I think that
only the casing is different because it has many serial ports which Sun
would not have needed but CV did. So apart from the sheet-metal all CV
did was assemble it.
I'm trying to remember what the max memory was for that
system. The CPU could address up to a maximum of 16 MB, and I think
that the memory map in there topped out at either 4 MB or 8 MB -- a
bit thin for CAD/CAM work.
I had 7 x 1 MB boards in mine which were replaced by a single 2 MB board after it left my hands. Taking out the Sky floating-point board would have allowed 8 MB -- but been a retrograde step for my purposes.
What flavor of G-code do the available
post-processors produce from it? (That is -- for what machines and
controllers?) Are they flexible enough so they could be modified to
output for LinuxCNC (used to be EMC from NIST -- Extensible Machiine
Controller -- before someone else claimed ownership of the EMC
name. :-)
It's a 1986 version (because it has the best user interface -- guess
what I worked on...) I don't think it could drive anything at all in
2017.
I don't think that I have any spares which would fit, unless I stole
them from the (also MultiBus) COSMOS CMS-16/UNX which ran a Unisoft port
of v7 unix on a MC68000 (too old to run a virtual memory unix, just
plain swapping. :-)
Ahhhh, the museum also has a machine with Unisoft V7 on the Lark
discs. That's a Unix I haven't used so perhaps I could come back to
you with some questions later.
There are also several Sun-3 Multibus systems we
have already robbed for spare Multibus cards, so another tour with screwdriver in hand is called for. Sparcs they have counted in
dozens...
... and some original EDSAC components ;-)
On 2017-01-29, Mike Causer <m.r.causer@goglemail.com> wrote:
On 29 Jan 2017 03:04:08 GMT
"DoN. Nichols" <BPdnicholsBP@d-and-d.com> wrote:
2/120 -- on casters -- deskside cabinet. Intel Multibus cage
inside. Sun2 architecture. As I got it -- with a SCSI interfaced
drive inside, and a rather early QIC tape drive for loading the OS.
QIC-4 IIRC. I could transfer stuff between work Suns & home on tape
until I had a Sparc1+ on my desk. Upgrading at home to a 3/50 then 3/60 with QIC-24 tape drives sorted that out.
O.K. Of course, the drives kept getting higher density. IIRC,
the SUN-3 machines were 60 MB, and the early SPARC drives were 150 MB.
(Then the Exabyte drives came along. :-)
My old 2/120 in ComputerVision casing
Computervison? That does not ring a bell for me.
Computervision, a CADCAM company in Boston, licensed the Sun-2 and then
-3 for their various product lines. I don't think they ever got CADDS
to run on the -2 but we got our Medusa line to work satisfactorily so
when CV announced the new hardware that is what I demonstrated. Even better on the -3 of course. The CPU board in mine is a Sun one and the other boards are standard Multibus from several vendors. I think that
only the casing is different because it has many serial ports which Sun would not have needed but CV did. So apart from the sheet-metal all CV
did was assemble it.
O.K. Sort of reminds me of the first I heard of Silicon
Graphics. They (at that time) advertised/claimed "The fastest graphics
under the Sun" -- as they made fast high-resolution framebuffers for the
Suns of the time. I knew about it because they came to the lab to demo
their gear -- and were using a fancy CAD system to do so. I have no
idea whether there was anything CAM on it, as that was before I
experienced my first CNC hardware -- a Bridgeport clone running Anilam's
CNC conversion.
I'm trying to remember what the max memory was for that
system. The CPU could address up to a maximum of 16 MB, and I think
that the memory map in there topped out at either 4 MB or 8 MB -- a
bit thin for CAD/CAM work.
I had 7 x 1 MB boards in mine which were replaced by a single 2 MB board after it left my hands. Taking out the Sky floating-point board would have allowed 8 MB -- but been a retrograde step for my purposes.
O.K. The 8 MB sounds right then. I guess the 4MB came from my
memory of the 3B1/7300 systems with the same CPU chip. (But a SysVr2
version with BSD and SysVr4 additions. :-)
What flavor of G-code do the available
post-processors produce from it? (That is -- for what machines and
controllers?) Are they flexible enough so they could be modified to
output for LinuxCNC (used to be EMC from NIST -- Extensible Machiine
Controller -- before someone else claimed ownership of the EMC
name. :-)
It's a 1986 version (because it has the best user interface -- guess
what I worked on...) I don't think it could drive anything at all in
2017.
Well ... I've been converting an old Bridgeport BOSS-3 mill
(apparently BOSS-1 and BOSS-2 never escaped the factory), and I think
that it was from 1977 or so, so it might have worked.
I don't think that I have any spares which would fit, unless I stole
them from the (also MultiBus) COSMOS CMS-16/UNX which ran a Unisoft port >> of v7 unix on a MC68000 (too old to run a virtual memory unix, just
plain swapping. :-)
Ahhhh, the museum also has a machine with Unisoft V7 on the Lark
discs. That's a Unix I haven't used so perhaps I could come back to
you with some questions later.
O.K. It was a very slow OS -- on the 8 MHz MC-68000 (compared
to the 10 Mhz in the 3B1/7300 and the Sun-2/120). I at about the same
time got a Tektronix 6130 (National Semiconductor 16032 CPU IIRC) which
had an open guest account but which would not turn on until I found a
hidden fuse buried in the power supply. It came with no known
passwords, and had been used as a training tool. I was able to get the
hash of the root password (before the days of /etc/shadow) and wrote a program to run just a single salt on the hashing of trial passwords from
all three systems -- the AT&T 7300/3B1, the COSMOS CMS-16/UNX, and the
TEK 6300 itself. I combined the three /etc/dict/word files to improve
my chances. (And I discovered that theĀ loader would work because the library was scrambled. I had to copy it into the guest home directory, re-hash it (I forget the term that was used, but BSD needed it whenever
the library was modified, and this was a BSD 4.2). Anyway, the 3B1/7300
ran the fastest, the Tek 6300 a bit slower, and the Unisoft v7 in the
COSMOS CMS-16/UNX was deadly slow. (Granted it was 8 MHZ 68000 instead
of 10 MHz 68010, so it should be a bit slower anyway, but not *that*
slow.) I eventually figured out why. This was a port of v7 unix from
the PDP-11. Well ... examining some assembly language output from the compilers, I discovered that the COSMOS CMS-16/UNX with its v7 port was treating the MC 68000 as a PDP-11. If the PDP-11 didn't have the instructions, they were not used. (The only exceptions were the LNK and
ULINK instructions for building and destroying the stack for
subroutines. The real killer was array indexing. It calculated the
offsets into the index one part at a time, while the AT&T
UnixPC/7300/3B1 used the instruction in the MC-68010 where you could do
a two-dimensional array by simply putting size of an object in one
register, X and Y dimensions of the array in two other registers, and X
and Y address in two more, and then calling a single instruction. Zap,
the offset to get what you want.
I didn't bother digging any deeper to see what else they were
doing the slow way.
But -- I did learn a lot about unix from that system. It was my
first personal unix box (bought at a hamfest) and I eventually had it
running two Fujitsu SMD interface 84 MB 8" drives. (I was limited to
the few drives for which drivers were already compiled into the kernel.)
No .o files for re-compiling the kernel with that one. Maybe you have
it.
Another pain was that the offset from GMT time was compiled into
the kernel, with no easy way to change it. I finally discovered where
it hid in the kernel, and did a change on a running kernel (after saving
a copy of the old one to be safe). It also was just about the time of
the change of DST dates, so even after I moved it to the proper coast,
it was still wrong near the beginning and end of DST period. :-) I did
get the sources for the system which is still used, and compiled that
for programs which *I* wrote, but I didn't have the sources to
re-compile a lot of the regular programs which came with the system, including cron. :-)
There are also several Sun-3 Multibus systems we have already robbed for spare Multibus cards, so another tour with screwdriver in hand is called for. Sparcs they have counted in
dozens...
... and some original EDSAC components ;-)
Good Luck,
DoN.
--
Remove oil spill source from e-mail
Email: <BPdnicholsBP@d-and-d.com> | (KV4PH) Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---
My 2/120 has two 80MB ESDI drives on a SCSI adapter behind the 20 MB
tape drive and an external cabinet containing two Hitachi 124 MB 10" SMD disks. I helped debug the NetBSD port and the TME 2/120 emulator on this system. I also have a 2/50 and a 2/75 that will net boot from the 2/120.
On 2017-01-30, m. thompson <michael.99.thompson@gmail.com> wrote:
[ ... ]
My 2/120 has two 80MB ESDI drives on a SCSI adapter behind the 20 MB
tape drive and an external cabinet containing two Hitachi 124 MB 10" SMD disks. I helped debug the NetBSD port and the TME 2/120 emulator on this system. I also have a 2/50 and a 2/75 that will net boot from the 2/120.
Sounds like a pretty good example of the machine.
Was the framebuffer a B&W or color to start with -- before the
fancy one for the CAD/CAM system.
Enjoy,
DoN.
--
Remove oil spill source from e-mail
Email: <BPdnicholsBP@d-and-d.com> | (KV4PH) Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---
On Monday, January 30, 2017 at 11:42:22 PM UTC-5, DoN. Nichols wrote:
On 2017-01-30, m. thompson <michael.99.thompson@gmail.com> wrote:
[ ... ]
My 2/120 has two 80MB ESDI drives on a SCSI adapter behind the 20 MBSounds like a pretty good example of the machine.
tape drive and an external cabinet containing two Hitachi 124 MB 10" SMD >> > disks. I helped debug the NetBSD port and the TME 2/120 emulator on this >> > system. I also have a 2/50 and a 2/75 that will net boot from the 2/120. >>
Was the framebuffer a B&W or color to start with -- before the
fancy one for the CAD/CAM system.
My 2/120 has two 80MB ESDI drives on a SCSI adapter behind the 20 MB tape drive and an external cabinet containing two Hitachi 124 MB 10" SMD disks. I helped debug the NetBSD port and the TME 2/120 emulator on this system. I also have a 2/50 and a 2/75that will net boot from the 2/120.
Foggy <ihardcas@gmail.com> writes:
I picked up a bunch of old Sparc hardware a few weeks ago. A SPARC 5,
a SPARC 20 and an Ultra 2.
None of them will boot a Solaris kernel. Tried Solaris 2.6 and 2.7.
I think Solaris 8 should support SPARC 5 & 20 too and the Ultra 2
should work even on later releases (depending on the actual
CPU)
All of them report "The IDPROM contents are invalid" or similar.
Is that the common cause of them not booting?
That could be the case as it is using the Hostid and the platform
name to load the proper kernel modules.
Casper
On 12/31/16 11:53 AM, Casper H.S. Dik wrote:
Foggy <ihardcas@gmail.com> writes:
I picked up a bunch of old Sparc hardware a few weeks ago. A SPARC 5,
a SPARC 20 and an Ultra 2.
None of them will boot a Solaris kernel. Tried Solaris 2.6 and 2.7.
I think Solaris 8 should support SPARC 5 & 20 too and the Ultra 2
should work even on later releases (depending on the actual
CPU)
For S10, >200Mhz IIRC ?
YTC#1 <bdp@ytc1-spambin.co.uk> writes:
On 12/31/16 11:53 AM, Casper H.S. Dik wrote:
Foggy <ihardcas@gmail.com> writes:
I picked up a bunch of old Sparc hardware a few weeks ago. A SPARC 5,
a SPARC 20 and an Ultra 2.
None of them will boot a Solaris kernel. Tried Solaris 2.6 and 2.7.
I think Solaris 8 should support SPARC 5 & 20 too and the Ultra 2
should work even on later releases (depending on the actual
CPU)
For S10, >200Mhz IIRC ?
I think all sun4m are supported; perhaps the amount of memory
is more critical. 200MHz S10? I think the SuperSPARCs never
went further than 90MHz. HyperSPARC went to 200MHz but thatHyperSPARC. That brings back memories, had that in some SS20s (googles),
was after market (not sure it was supported in S10s?
Casper
I think all sun4m are supported; perhaps the amount of memory
is more critical. 200MHz S10? I think the SuperSPARCs never
went further than 90MHz. HyperSPARC went to 200MHz but that
was after market (not sure it was supported in S10s?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 293 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 239:59:41 |
| Calls: | 6,624 |
| Files: | 12,173 |
| Messages: | 5,320,015 |