<html><body><p><i><font size="2">> </font></i><tt><i><font size="2">xscom read/writes are the lowest form of access and everything else is built upon that? </font></i></tt><br><font size="2">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.</font><br><br><tt><font size="2">> Ah, that's interesting. Is that something 'baked in' (for the most part)<br>> that would be the same regardless of what firmware is running on it<br>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.</font></tt><br><font size="2"><br>--<br>Dan Crowell<br>Senior Software Engineer - Power Systems Enablement Firmware<br>IBM Rochester: t/l 553-2987<br>dcrowell@us.ibm.com</font><br><br><img width="16" height="16" src="cid:1__=09BB0E07DFEC1A278f9e8a93df938690918c09B@" border="0" alt="Inactive hide details for "Marty E. Plummer" ---10/14/2019 05:58:15 PM---> On Mon, Oct 14, 2019 at 01:34:07AM +0000, Daniel M C"><font size="2" color="#424282">"Marty E. Plummer" ---10/14/2019 05:58:15 PM---> On Mon, Oct 14, 2019 at 01:34:07AM +0000, Daniel M Crowell wrote: > > think a goodly portion of it</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">"Marty E. Plummer" <hanetzer@startmail.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Daniel M Crowell <dcrowell@us.ibm.com></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">openpower-firmware@lists.ozlabs.org</font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">10/14/2019 05:58 PM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">[EXTERNAL] Re: [OpenPower-Firmware] Hardware documentation</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt><font size="2">> On Mon, Oct 14, 2019 at 01:34:07AM +0000, Daniel M Crowell wrote:<br>> > think a goodly portion of it is directly executed (but I seem to recall<br>> > reading that some of it just calls to the bits of hostboot still in<br>> > memory after it gets loaded, pinged Stewart Smith about that).<br>> There isn't anything in skiboot that requires any hostboot logic to be resident.<br>Maybe I'm thinking of the linux kernel drivers then.<br><br>> > Yeah, its really fun decoding fsidd.C's stuff into something I can make<br>> > use of within a coreboot context.<br>> Well, at the end of the day it all devolves into a memory mappy i/o<br>> operation so there is no reason you couldn't use most of it as-is, right?<br>Overall yeah, but some of the stuff is a bit unusual to me but I seem to<br>be understanding it overall. Correct me if I'm wrong, but it looks like<br>xscom read/writes are the lowest form of access and everything else is<br>built upon that? (Assuming that's access on the same module; if I want<br>the cpu in socket 0 to access some info from socket 1 [assuming you can<br>do that? I think I've seen mentioned] you'd have to use something else?)<br><br><br>> > One thing I'd like to ask: I know with the pvr you can tell if its a<br>> > 12/24 core scale up/out chip. Is there a definitive way one can further<br>> > break this down into a, say, 4c16t nimbus chip (like the ones offered<br>> > with the Talos II/Blackbird machines)?<br>> No, there isn't anything in the processor registers that would tell you that.<br>> You have to rely on the module vpd information to know how many cores<br>> there are and which physical cores are active.<br>Ah, that's interesting. Is that something 'baked in' (for the most part)<br>that would be the same regardless of what firmware is running on it<br>(aside from the active cores bit, that seems like it would change based<br>on GARD/etc)?<br>> --<br>> Dan Crowell<br>> Senior Software Engineer - Power Systems Enablement Firmware<br>> IBM Rochester: t/l 553-2987<br>> dcrowell@us.ibm.com<br><br></font></tt><br><br><BR>
</body></html>