[OpenPower-Firmware] Hardware documentation

[Marty E. Plummer]

On Tue, Oct 15, 2019 at 06:23:29PM -0500, Daniel M Crowell wrote:
> 
> > 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.
> 
Ok, good to know. Judging by hostboot and skiboot the protocol is more
or less the same for both, just different magic registers.

> > 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.
> 
Interesting. Is there a simple way to read the vpd from say a linux
userspace? Either host or bmc.

On another note, is there any plans to move hostboot/skiboot to the new
elfv2 abi? (well, I don't know when it came out, but as far as I can
tell hostboot uses elfv1)
> --
> 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
> 
> 
>