SUMMARY: CPU manufacture info through OBP

This looks to be my final email on the subject for a while. The topic
was a bit esoteric, so it wasn't suprising that there wasn't a lot of
input.

Basically, UltraSPARC processors have encoded in them their manufacture
site, lot number, and X/Y position in the silicon wafer they are fab'd
from. Sun uses the information internally to gather statistics and
fine-tune the production process.

It could, as The Register article suggests, have an alternate use for
software licensing. Since a hostid number can be modified, this would be
a more secure method of licensing software. (With the warning that if a
CPU is replaced or removed, the ID number would change.) But a piece of
software could handle that case, for example, by giving a grace period
for relicensing in those circumstances.

This caught my interest since the Sun CTO seemed to imply that only the
kernel has access to the numbers. However, with the information below,
you can access them from the OpenBoot Prompt (OBP), before the OS is
loaded. And if you use the tools inside the OBP to disassemble the
routines used to access the numbers, you could probably find a way to do
it under Solaris.

In talking with Sun, I found that they were reluctant to define what the
numbers mean. (For example, which manufacture numbers corresponds to
which facility. Or the ranges on the X and Y values of the wafer
positions.) However, they'll take the issue to engineering and see
whether or not they'll support people grabbing those ID numbers from
within Solaris.

Mind you, someone could probably reverse engineer the code in the OBP
and make it work under the OS. But Sun could also try to squash someone
who does this with the DMCA. (Admittedly, it would be open for
interpretation if it is a copy protection mechanism, but that wouldn't
stop them from trying to use it to chase after you.)

One last tidbit...
Reference was made to a ".sfid-all" command, in addition to the one I
found. This isn't in my version of the OBP, but the name suggests that
if it exists, it grabs the information for all processors on the system.
You can test for the existance of the command by typing "sifting sfid"
at the ok prompt, and seeing if that is one of the commands listed.

Thanks to Trey Nix (EDS) for his input.

Josh McCormick wrote:
> 
> All -
> 
> I am much closer to an answer, and I have additional information which
> may help anyone who was looking into this. (Topic reminder: discovering
> the unique ID on each UltraSPARC CPU that also gives manufacture
> information.) No documentation appears to be published on this, so this
> is a first.
> 
> >From the OBP, enter the "dev" command. Then do the "ls" command. You
> will see the entry for your system's CPUs. For example...
> 
> ok dev
> ok ls
> 
> SUNW,UltraSPARC2a,0
> SUNW,UltraSPARC28,0
> 
> As you can probably see, that lists CPUs 40 and 42 (decimal). This
> machine is an E10k that I'm working off of, which explains the high CPU
> numbers.
> 
> Now, switch to the CPU you want to query. You do this by putting the
> hexidecimal number of the CPU on the stack, and then executing the
> switch-cpu command. (This step can be skipped on uniprocessor boxes.)
> 
> ok 2a
> ok switch-cpu
> 
> To get the information for the selected processor, type ".sfid".
> Example...
> 
> ok .sfid
> Y:6 X:a W:16 L:3196b R:0
> 
> Use the steps above to switch to another CPU. Lather, rinse, repeat.
> 
> This appears to contain, someone coded, the information of the position
> of the CPU on the wafer, where it was manufactured, and the lot number.
> The exact meaning and ranges of these aren't known to me at this time.
> The meaning of the R variable is also unknown. But would seem to be the
> unique CPU identifiers that were discussed.
> 
> If you are good with assembly (and a little good at forth), you can use
> the "see", "dis", and "+dis" commands to figure out what is going on.
> Some recommended commands...
> 
> see .sfid
> see sfid@
> 
> When you see a big hexadecimal number in paranthesis, like (f102571c),
> that is a call to an assembly language routine. An assembly language
> SPARC programmer could figure out what exactly is going on. Who knows?
> Maybe even create a program that would run under Solaris and do the same
> thing.
> 
> This was a great exercise for me, since I haven't dabbled in the Forth
> language (used by the OBP) since I was a child. Anyone have something
> they can add?
> 
> Josh McCormick wrote:
> >
> > I read this article at The Register:
> > URL: http://www.theregus.com/content/3/26331.html
> >
> > Towards the end, the Sun guy bragged about how Sun marks each and every
> > CPU with when and where it was manufacturered, even including its
> > position on the wafer. Real cool. He claimed that there was "no userland
> > interface for this information" and that it was "only readably by the
> > knerl, with no OS call available to obtain that code".
> >
> > Of course, if it is readable by the kernel, and you can read the
> > kernel...
> >
> > Well, I did some searching. The only relevant thing I could find is THIS
> > bugid in SunSolve:
> > 4327284 - Current SFID program cannot effectively detect the wafer
> > number and lot number
> >
> > Basically, it talks about a problem reading the wafer number and the lot
> > number of a CPU through *the OBP*. They were needing an OBP Engineer to
> > modify the "SFID@ .x program" to correctly read the correct register
> > bits.
> >
> > I should be far more skilled in the OBP than I am. Unfortunately, this
> > doesn't make sense to me. But to someone who is a little more of an OBP
> > guru, do you think you can use this information to come up with the
> > proper syntax to pull that information up from the OBP?
> >
> > Example output, I know it'll at least display the Lot Number in a
> > strange way, like...
> > Lot Number      37:14 24 0-16777215
> >
> > This would be a cool toy to have if an expert can change this into a
> > usable syntax. Obviously, you can type "sfid@" at the OBP. But "see
> > sfid@" doesn't give me anything I would call useful. Any gurus out
> > there?
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers