[OpenPower-Firmware] Hardware documentation

[Daniel M Crowell]

> xscom read/writes are the lowest form of access and everything else is
built upon that?
Correct, when running from the host itself xscom is where everything really
starts.  That is how a core accesses all of the scom registers.  You only
have xscom access to the hardware that is part of the current SMP fabric.
That means that when Hostboot starts you can only xscom registers on the
master processor.  Once you get the SMP up you can then xscom other
processors.  Prior to the SMP being alive you have to use some kind of
side-band interface.  Prior to P9 this was direct FSI access through the
fsi2pib engine.  You use xscom on the master processor to drive the local
FSI master to modify registers in the remote CFAM logic to access the
scoms.  That path still works, except that is it mostly disabled when you
have the secure jumper installed.  Instead you send messages to the remote
SBE (again over FSI) to do the scoms for you or often to run entire
procedures.

> Ah, that's interesting. Is that something 'baked in' (for the most part)
> that would be the same regardless of what firmware is running on it
Not exactly what you mean but I think the answer is yes.  There is a
keyword in the module vpd (PG) that is filled in when the module is
initially tested.  That tells you which cores (or other pieces of logic
potentially) tested good and can be used.  Physically every processor chip
could have 24 cores but physics dictates that you rarely get all 24 of them
to yield.  The PG keyword is what tells us which physical resources in the
chip we can use.  The initial SBE image that is shipped with the module
will have the list of good cores programmed into it so that it always
starts a good core.  Once Hostboot takes over we can reprogram the SBE
image to choose a different core if we find a problem with the first one.
The contents of the VPD are really firmware agnostic, other than the
firmware understanding how to interpret the data.  There is nothing baked
into the processor hardware itself that knows what is good or bad, firmware
has to interpret the VPD and use that to finish the boot.

--
Dan Crowell
Senior Software Engineer - Power Systems Enablement Firmware
IBM Rochester: t/l 553-2987
dcrowell at us.ibm.com



From:	"Marty E. Plummer" <hanetzer at startmail.com>
To:	Daniel M Crowell <dcrowell at us.ibm.com>
Cc:	openpower-firmware at lists.ozlabs.org
Date:	10/14/2019 05:58 PM
Subject:	[EXTERNAL] Re: [OpenPower-Firmware] Hardware documentation



> On Mon, Oct 14, 2019 at 01:34:07AM +0000, Daniel M Crowell wrote:
> > think a goodly portion of it is directly executed (but I seem to recall
> > reading that some of it just calls to the bits of hostboot still in
> > memory after it gets loaded, pinged Stewart Smith about that).
> There isn't anything in skiboot that requires any hostboot logic to be
resident.
Maybe I'm thinking of the linux kernel drivers then.

> > Yeah, its really fun decoding fsidd.C's stuff into something I can make
> > use of within a coreboot context.
> Well, at the end of the day it all devolves into a memory mappy i/o
> operation so there is no reason you couldn't use most of it as-is, right?
Overall yeah, but some of the stuff is a bit unusual to me but I seem to
be understanding it overall. Correct me if I'm wrong, but it looks like
xscom read/writes are the lowest form of access and everything else is
built upon that? (Assuming that's access on the same module; if I want
the cpu in socket 0 to access some info from socket 1 [assuming you can
do that? I think I've seen mentioned] you'd have to use something else?)


> > One thing I'd like to ask: I know with the pvr you can tell if its a
> > 12/24 core scale up/out chip. Is there a definitive way one can further
> > break this down into a, say, 4c16t nimbus chip (like the ones offered
> > with the Talos II/Blackbird machines)?
> No, there isn't anything in the processor registers that would tell you
that.
> You have to rely on the module vpd information to know how many cores
> there are and which physical cores are active.
Ah, that's interesting. Is that something 'baked in' (for the most part)
that would be the same regardless of what firmware is running on it
(aside from the active cores bit, that seems like it would change based
on GARD/etc)?
> --
> Dan Crowell
> Senior Software Engineer - Power Systems Enablement Firmware
> IBM Rochester: t/l 553-2987
> dcrowell at us.ibm.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openpower-firmware/attachments/20191015/6e77fa2e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openpower-firmware/attachments/20191015/6e77fa2e/attachment.gif>