Difference between IDPROMs

[Wes Groleau]

References I found said listed IDPROM part numbers for Sun Ultra 10 as
525-1430, 525-1817, and f100-6889. Are they really three different
things? Checking prices, one place has a web page for each, with the
only difference being the part number, and a price of $38 for each.

Another place says original price $95 but they'll give me incredible
savings and sell it to me for fifty-some (same for all three numbers)
A third place give a different price for each, saying original price is
$250-three something, but they'll give me an incredible bargain by
letting me have it for $120-160.

Most of the places won't tell you a price without enough info for a
sales person to bug you.

Anyway, I decided to take a chance on a used one for $20 but still
curious whether there is any difference between the three numbers.

Oh, by the way, if the Ultra ten box is assembled and plugged in, but
"OFF", is there still a trickle path to keep the IDPROM charged? Is
there any chance that if plugged in long enough, I could revive and
reprogram it instead of replacing it?

--
Wes Groleau

Always listen to experts. They'll tell you
what can't be done and why. Then do it.
— Robert A. Heinlein

[DoN. Nichols]

On 2012-03-24, Wes Groleau <Grolea...@FreeShell.org> wrote:
> References I found said listed IDPROM part numbers for Sun Ultra 10 as
> 525-1430, 525-1817, and f100-6889. Are they really three different
> things? Checking prices, one place has a web page for each, with the
> only difference being the part number, and a price of $38 for each.

Two differences possible.

1) The information already written in there may be different
such as the upper bits of the HOSTID, which defines the
particular version of the system. Since the system was
made with several different CPU speeds, it may be this, a
different HOSTID upper part for different CPU speeds.

2) The components which make up the IDPROM -- a merge of a
CMOS RAM, a time-of-day clock chip, and a cell (e.g. component
of a battery), which is used to both preserve the contents of
the RAM when the system is powered down, and to power the clock
chip. (The clock chip is halted when a new one is received, and
when the system powers up, it starts the chip keeping time.)
This makes them last longer on the shelf -- and if there were a
utility included to set the halt bit again, it would allow a
system to go into storage for longer times without problems.

But -- Sun used a bug in the original chip to accomplish
something -- I don't know what. The new chips no longer have
that bug, and the system requires a different ROM in it to deal
with the fact that it no longer has the bug to work with. So,
newer chips won't work on older systems. At a guess, that may
be the difference between the 525-???? ones and the f100-6889.

O.K. A web search found this site:

<http://www.sunshack.org/data/sh/2.1.8/infoserver.central/data/syshbk/Devices/IDPROM/IDPROM_Parts.html>

which shows that all the versions listed for the Ultra-5 and Ultra-10
are the same physical chip --- 48T59 NVRAM, so it must be differences in
the information included -- likely CPU speed and perhaps other changes
in the system board.

> Another place says original price $95 but they'll give me incredible
> savings and sell it to me for fifty-some (same for all three numbers)
> A third place give a different price for each, saying original price is
> $250-three something, but they'll give me an incredible bargain by
> letting me have it for $120-160.
>
> Most of the places won't tell you a price without enough info for a
> sales person to bug you.
>
> Anyway, I decided to take a chance on a used one for $20 but still
> curious whether there is any difference between the three numbers.

Used ones will have been run for some unknown time, and it is
unlikely that anyone who pulled them from the systems bothered entering
the fcode to re-write the halt bit, so they will continue aging on the
shelf. They are better in a system which is powered up and running.

> Oh, by the way, if the Ultra ten box is assembled and plugged in, but
> "OFF", is there still a trickle path to keep the IDPROM charged?

I don't know whether there is power to keep the clock running.
At best, if there is, it will keep the clock from discharging the cell
built in -- but *cannot* recharge it, as it is a primary cell (not
rechargeable).

> Is
> there any chance that if plugged in long enough, I could revive and
> reprogram it instead of replacing it?

No! However, there are web sites which will tell you how to
perform surgery on the chip housing to mount an external cell in place
of the now dead one. If you don't have the hostid and the ethernet MAC
address from before noted down, you will have to jump through hoops to
generate bogus (but acceptable) new ones which won't confuse the system.

Note that one of the SPARC based semi-clones, the Solbourne
S4000 and S4000DX did things *right*. The HOSTID and ethernet MAC
address were burned into a small bipolar ROM, and the NVRAM/clock chip
was kept powered by a coin cell in a holder on the sytem board. You
could lose NVRAM settings, but nothing so critical as the HOSTID and MAC
address.

Now -- some later machines, such as the Sun Blade 1000/2000 and
Sun Fire 280R use a SEEPROM (Serial EEPROM) which does not need power to
retain its data, and a separate clock chip. The web site says that the
Sun Blade 1500 and 2500 use the same SEEPROM, with four different part
numbers for the four speeds of systems -- and they don't bother
mentioning the Sun Fire 280R, which uses the same system board as the
Sun Blade 1000/2000.

And machines like the Sun Fire V120 have the HOSTID and ethernet
MAC address on a front-panel plug-in card, so you can transfer license
code to a replacement system while you swap the disk drives to keep
going as quickly as possible.

So -- Sun finally got that right. But too late, I fear, since
Oracle has taken over the helm.

Good Luck,
DoN.

--
Remove oil spill source from e-mail
Email: <BPdnic...@d-and-d.com> | 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 ---

[Wes Groleau]

On 03-24-2012 21:51, DoN. Nichols wrote:
> No! However, there are web sites which will tell you how to
> perform surgery on the chip housing to mount an external cell in place
> of the now dead one. If you don't have the hostid and the ethernet MAC
> address from before noted down, you will have to jump through hoops to
> generate bogus (but acceptable) new ones which won't confuse the system.

The "hoops" of typing FORTH commands seem less daunting to me than
prying open an NVRAM and soldering in a watch battery. :-)

MAC is no big deal, since it will not be directly connected to the
Internet and there are no other Suns in the house.

Is hostid an issue when I intend to reload with Solaris 10 ?

[Doug McIntyre]

Wes Groleau <Grolea...@FreeShell.org> writes:
>On 03-24-2012 21:51, DoN. Nichols wrote:
> > No! However, there are web sites which will tell you how to
> > perform surgery on the chip housing to mount an external cell in place
> > of the now dead one. If you don't have the hostid and the ethernet MAC
> > address from before noted down, you will have to jump through hoops to
> > generate bogus (but acceptable) new ones which won't confuse the system.

>The "hoops" of typing FORTH commands seem less daunting to me than
>prying open an NVRAM and soldering in a watch battery. :-)

>MAC is no big deal, since it will not be directly connected to the
>Internet and there are no other Suns in the house.

>Is hostid an issue when I intend to reload with Solaris 10 ?

No, hostid is only used for a few 3rd party software licensing
(ie. flexlm based systems and the like).
Solaris doesn't use it in any fashion.

The MAC address stays on your gateway router anyway. It isn't
broadcast beyond that. So even if you duplicate a MAC address two hops
away, it won't matter.

[Volker Borchert]

Doug McIntyre wrote:
> The MAC address stays on your gateway router anyway. It isn't
> broadcast beyond that. So even if you duplicate a MAC address two hops
> away, it won't matter.

Maybe so, but ... I wouldn't bet on those said systems staying two hops
apart forever ... aren't there any private MACs similar to RFC1918 IPs?

--

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mc...@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert <v_bor...@despammed.com>

[Wes Groleau]

On 03-25-2012 00:43, Doug McIntyre wrote:

> Wes Groleau<Grolea...@FreeShell.org> writes:
>> Is hostid an issue when I intend to reload with Solaris 10 ?
>
> No, hostid is only used for a few 3rd party software licensing
> (ie. flexlm based systems and the like).
> Solaris doesn't use it in any fashion.

Thanks. good to know.

> The MAC address stays on your gateway router anyway. It isn't
> broadcast beyond that. So even if you duplicate a MAC address two hops
> away, it won't matter.

That's what I thought, with about five percent uncertainty. :-)

--
Wes Groleau

Pat's Polemics
http://Ideas.Lang-Learn.us/barrett

[Wes Groleau]

On 03-25-2012 14:00, Volker Borchert wrote:
> Doug McIntyre wrote:
>> The MAC address stays on your gateway router anyway. It isn't
>> broadcast beyond that. So even if you duplicate a MAC address two hops
>> away, it won't matter.
>
> Maybe so, but ... I wouldn't bet on those said systems staying two hops
> apart forever ... aren't there any private MACs similar to RFC1918 IPs?

The probability that I will sell this Sun to someone who has other Suns
is low. The probability that one of his other Suns will have the MAC I
choose is even lower.

I don't know the probability that he'll ignore my warning to check for
conflict, but by that time, I won't care.

--
Wes Groleau

Even if you do learn to speak correct English,
whom are you going to speak it to?
— Clarence Darrow

[Wes Groleau]

On 03-25-2012 14:00, Volker Borchert wrote:

> Doug McIntyre wrote:
>> The MAC address stays on your gateway router anyway. It isn't
>> broadcast beyond that. So even if you duplicate a MAC address two hops
>> away, it won't matter.
>
> Maybe so, but ... I wouldn't bet on those said systems staying two hops
> apart forever ... aren't there any private MACs similar to RFC1918 IPs?

That wouldn't help. RFC1918 provides groups of addresses to use within
a LAN. If another LAN adds a machine having the same RFC1918 IP as one
they already had, the effects are similar to adding a machine with a MAC
that they already have.

[DoN. Nichols]

On 2012-03-25, Wes Groleau <Grolea...@FreeShell.org> wrote:
> On 03-24-2012 21:51, DoN. Nichols wrote:
> > No! However, there are web sites which will tell you how to
> > perform surgery on the chip housing to mount an external cell in place
> > of the now dead one. If you don't have the hostid and the ethernet MAC
> > address from before noted down, you will have to jump through hoops to
> > generate bogus (but acceptable) new ones which won't confuse the system.
>
> The "hoops" of typing FORTH commands seem less daunting to me than
> prying open an NVRAM and soldering in a watch battery. :-)

You still have to do the hoops even with a new chip -- unless it
is specifically programmed to be a Ultra-10 chip (right HostID). With
the old chip, as soon as you turn it off, you will lose whatever you
have put into the NVRAM once the chip reaches "that age".

> MAC is no big deal, since it will not be directly connected to the
> Internet and there are no other Suns in the house.

O.K. Until someone else gets the system.

> Is hostid an issue when I intend to reload with Solaris 10 ?

Yes. The first nybble of the HostID -- or maybe the first byte
-- defines what kind of system it is. The OS uses that to determine the
interfaces which should be built in, and the addresses at which they are
located. With the wrong HostID, you can wind up with the OS not being
able to find critical things. (For example, most UltraSPARC machines
expect to talk to disk drives through either SCSI or Fibre Channel. The
Ultra-5 and Ultra-10 are uncommon in that they used IDE (PATA) drives
instead. The lower part of the HostID doesn't matter -- unless you have
licensed software keyed to the hostid. :-)

This URL has ways of programming the values -- but it is a bit
old, since it does not seem to mention any of the UltraSPARC systems.

<http://www.squirrel.com/sun-nvram-hostid.faq.html>

And this one has a program which is shown being used on an
Ultra-5/Ultra-10 (They use the same system board -- only the case is
different.)

<http://unix.derkeiler.com/Mailing-Lists/SunManagers/2005-04/0117.html>

Make the first two nybbles of the hostid match what is shown,
and pick your own remaining digits -- ideally somewhat high in the range
so you don't duplicate another system.

[DoN. Nichols]

On 2012-03-25, Volker Borchert <v_bor...@despammed.com> wrote:
> Doug McIntyre wrote:
>> The MAC address stays on your gateway router anyway. It isn't
>> broadcast beyond that. So even if you duplicate a MAC address two hops
>> away, it won't matter.
>
> Maybe so, but ... I wouldn't bet on those said systems staying two hops
> apart forever ... aren't there any private MACs similar to RFC1918 IPs?

The usual solution is to pick up an old ethernet PC-board for
some old system (probably a PC with an ISA bus so it is less likely to
be needed again), find the MAC address used by that board, and use it,
and pull and destroy the small ROM which defines the MAC address to the
board. This insures that there is no duplication.

Enjoy,

[Hank]

In article <slrnjmvnjv.je...@Katana.d-and-d.com>,

DoN. Nichols <BPdnic...@d-and-d.com> wrote:
>On 2012-03-25, Wes Groleau <Grolea...@FreeShell.org> wrote:
>> On 03-24-2012 21:51, DoN. Nichols wrote:
>> > No! However, there are web sites which will tell you how to
>> > perform surgery on the chip housing to mount an external cell in place
>> > of the now dead one. If you don't have the hostid and the ethernet MAC
>> > address from before noted down, you will have to jump through hoops to
>> > generate bogus (but acceptable) new ones which won't confuse the system.
>>
>> The "hoops" of typing FORTH commands seem less daunting to me than
>> prying open an NVRAM and soldering in a watch battery. :-)
>
> You still have to do the hoops even with a new chip -- unless it
>is specifically programmed to be a Ultra-10 chip (right HostID). With
>the old chip, as soon as you turn it off, you will lose whatever you
>have put into the NVRAM once the chip reaches "that age".
>
>

>> Is hostid an issue when I intend to reload with Solaris 10 ?
>
> Yes. The first nybble of the HostID -- or maybe the first byte
>-- defines what kind of system it is. The OS uses that to determine the
>interfaces which should be built in, and the addresses at which they are
>located. With the wrong HostID, you can wind up with the OS not being
>able to find critical things. (For example, most UltraSPARC machines
>expect to talk to disk drives through either SCSI or Fibre Channel. The
>Ultra-5 and Ultra-10 are uncommon in that they used IDE (PATA) drives
>instead. The lower part of the HostID doesn't matter -- unless you have
>licensed software keyed to the hostid. :-)

On all of the Sparc Ultras, (sun4u), the NVRAM is a Signetics
M48T59-70PC1. Available from Memoryx unprogrammed.

The first byte on an Ultrasparc is 80.
The hostid and MAC are tied together. On the later Suns, the original
ID is on a printed label on the original NVRAM. If programming a bare
NVRAM, just use that number. When I do this, I lift off the label and
stick it on the new NVRAM with Pliobond. I've probably done 10 or 15
of these over the years, and it's a pretty straightforward job.

Can't recall the exact details now, but I think it was "filch an NVRAM
from a scrap U1 for a bare U5/10 motherboard." As I recall, I built
the system up and on bootup, it hollered that the checksum was
incorrect until I rebooted it with the keyboard default reset. I
thought I'd have to reprogram it, but as I recall, I didn't.

>
> This URL has ways of programming the values -- but it is a bit
>old, since it does not seem to mention any of the UltraSPARC systems.
>
> <http://www.squirrel.com/sun-nvram-hostid.faq.html>
>
> And this one has a program which is shown being used on an
>Ultra-5/Ultra-10 (They use the same system board -- only the case is
>different.)
>
><http://unix.derkeiler.com/Mailing-Lists/SunManagers/2005-04/0117.html>
>
> Make the first two nybbles of the hostid match what is shown,
>and pick your own remaining digits -- ideally somewhat high in the range
>so you don't duplicate another system.
>

If the user is replacing the original NVRAM on an Ultra, the data is
on the label, as I mentioned above. Not true for earlier systems like
the SS5/20. As long as the first byte is 80, the other digits
generally don't matter, as long as they don't conflict with the MACs
in the local system.

The arp -a command will show the MAC addresses of everything a system
has communicated with. On this Ultra 60, it begins 08:00:20. Note
that the 80 mentioned earlier appears as 08 in the MAC.

Hank

[Doug McIntyre]

"DoN. Nichols" <BPdnic...@d-and-d.com> writes:
>> Is hostid an issue when I intend to reload with Solaris 10 ?

> Yes. The first nybble of the HostID -- or maybe the first byte
>-- defines what kind of system it is.

I don't believe that has been relavent inside Solaris or the OBP for
quite some time. Like before it was even called Solaris..

Maybe if you had some Sun4 machines..

Hmm, maybe I should disassemble the OBP in the sun4 I have in the
other room..

[Wes Groleau]

On 03-25-2012 23:12, DoN. Nichols wrote:
> On 2012-03-25, Wes Groleau<Grolea...@FreeShell.org> wrote:
>> The "hoops" of typing FORTH commands seem less daunting to me than
>> prying open an NVRAM and soldering in a watch battery. :-)
>
> You still have to do the hoops even with a new chip -- unless it
> is specifically programmed to be a Ultra-10 chip (right HostID). With

Right, but I'd rather do that than hardware hacking.

>> MAC is no big deal, since it will not be directly connected to the
>> Internet and there are no other Suns in the house.
>
> O.K. Until someone else gets the system.

Not likely to happen. Even less likely someone who gets it will already
have the MAC I picked out of thousands of possible values.
But if it will make everyone happy, I could forget the Sun prefix
and copy a MAC from one of the not-worth-fixing things I haven't
thrown away yet. Or in a slim chance of revenge, use the Mac of
of my stolen iPhone. :-)

>> Is hostid an issue when I intend to reload with Solaris 10 ?
>
> Yes. The first nybble of the HostID -- or maybe the first byte
> -- defines what kind of system it is. The OS uses that to determine the
> interfaces which should be built in, and the addresses at which they are
> located. With the wrong HostID, you can wind up with the OS not being
> able to find critical things. (For example, most UltraSPARC machines

Ah, someone else said it doesn't matter, but now that you mention it,
I remember seeing a chart of what hostid to use.

> This URL has ways of programming the values -- but it is a bit
> old, since it does not seem to mention any of the UltraSPARC systems.
>
> <http://www.squirrel.com/sun-nvram-hostid.faq.html>

I think that's the one I used before. Old, but what it was missing, I
found in manuals.


--
Wes Groleau

A bureaucrat is someone who cuts red tape lengthwise.

[Volker Borchert]

Hank wrote:
> The arp -a command will show the MAC addresses of everything a system
> has communicated with. On this Ultra 60, it begins 08:00:20.

Not surprising, as 8:0:20 is one of the vendor prefixes assigned to Sun.

[Hank]

In article <jkrj35$dk8$1...@Gaia.teknon.de>,

Volker Borchert <v_bor...@despammed.com> wrote:
>Hank wrote:
>> The arp -a command will show the MAC addresses of everything a system
>> has communicated with. On this Ultra 60, it begins 08:00:20.
>
>Not surprising, as 8:0:20 is one of the vendor prefixes assigned to Sun.
>

Precisely.

[DoN. Nichols]

On 2012-03-26, Hank <han...@blackhole.lostwells.net> wrote:
> In article <slrnjmvnjv.je...@Katana.d-and-d.com>,
> DoN. Nichols <BPdnic...@d-and-d.com> wrote:
>>On 2012-03-25, Wes Groleau <Grolea...@FreeShell.org> wrote:
>>> On 03-24-2012 21:51, DoN. Nichols wrote:

[ ... ]

>>> Is hostid an issue when I intend to reload with Solaris 10 ?
>>
>> Yes. The first nybble of the HostID -- or maybe the first byte
>>-- defines what kind of system it is. The OS uses that to determine the

[ ... ]

In both the Sun Fire V120, and the Sun Blade 2000, the first
byte is 83, not 80. (Those are both Uttra-II CPUs, IIRC.) I don't have
any Ultra-5 or Ultra-10 systems booted at the moment to check.

Enjoy,