[OpenPower-Firmware] Hardware documentation

[Marty E. Plummer]

> 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