<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" ><font size="2" ><font face="Default Monospace,Courier New,Courier,monospace" >> </font></font><font size="2" face="Default Monospace,Courier New,Courier,monospace" >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).</font></div>
<div dir="ltr" >There isn't anything in skiboot that requires any hostboot logic to be resident.</div>
<div class="mail-signature-container" dir="ltr" > </div>
<div class="mail-signature-container" dir="ltr" ><font size="2" face="Default Monospace,Courier New,Courier,monospace" >> Yeah, its really fun decoding fsidd.C's stuff into something I can make<br>> use of within a coreboot context. </font></div>
<div class="mail-signature-container" dir="ltr" >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?</div>
<div class="mail-signature-container" dir="ltr" > </div>
<div class="mail-signature-container" dir="ltr" > </div>
<div class="mail-signature-container" dir="ltr" ><font size="2" face="Default Monospace,Courier New,Courier,monospace" >> 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)?</font></div>
<div class="mail-signature-container" dir="ltr" >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.</div>
<div class="mail-signature-container" dir="ltr" ><br>--<br>Dan Crowell<br>Senior Software Engineer - Power Systems Enablement Firmware<br>IBM Rochester: t/l 553-2987<br>dcrowell@us.ibm.com</div>
<div dir="ltr" > </div>
<div dir="ltr" > </div>
<blockquote data-history-content-modified="1" data-history-expanded="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: "Marty E. Plummer" <hanetzer@startmail.com><br>To: Daniel M Crowell <dcrowell@us.ibm.com><br>Cc: openpower-firmware@lists.ozlabs.org<br>Subject: [EXTERNAL] Re: [OpenPower-Firmware] Hardware documentation<br>Date: Sat, Oct 12, 2019 9:35 AM<br>
<div><font size="2" face="Default Monospace,Courier New,Courier,monospace" >On Fri, Oct 11, 2019 at 09:53:06AM -0500, Daniel M Crowell wrote:<br>><br>> I definitely feel your pain on the documentation front. There are a few<br>> reasons why these sorts of things don't currently exist. Obviously there<br>> is the usual "developers don't like to write docs" excuse :-). The next<br>> reason is that a lot of this stuff crosses the open/proprietary line. The<br>Fair enough, though I hope more stuff crosses over to the greener side<br>as soon as possible. Were it reasonably possible and forgiving I'd<br>almost be willing to sign an nda over it, with the proviso it wouldn't<br>get in the way of my firmware efforts.<br>> internal hardware specifications are still full of proprietary IP, but the<br>> code is open. There hasn't been a concerted effort (that I know of) to<br>> create completely open hardware specifications because frankly there hasn't<br>> been a lot of interest to this point in anyone external playing around with<br>> this stuff. You are blazing a trail here.<br>><br>And running head first into many, many walls lol. And this is only<br>working to operate with the existing seeprom sbefw/hostboot bootloader.<br>Its going to be even more fun once I get to the point of rewriting<br>those.<br>> There are some specifications out in the OpenPOWER organization. For<br>> example, OpenFSI is here -<br>> <a href="http://openpowerfoundation.org/wp-content/uploads/resources/OpenFSI-spec-100/content/ch01.html" target="_blank">http://openpowerfoundation.org/wp-content/uploads/resources/OpenFSI-spec-100/content/ch01.html</a> <br>> (pretty low-level electrical stuff though)<br>><br>Meaning: not particularly useful for my purposes, right?<br>> We've tried to provide a lot of comments where we can but as with all<br>> long-term projects, there is a lot of inertia-based code. The Hostboot FSI<br>Yeah, its really fun decoding fsidd.C's stuff into something I can make<br>use of within a coreboot context. I've been eyeballing skiboot a bit, I<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>> code is based on the behavior of FSP code from 3 generations ago since the<br>> hardware logic is essentially unchanged. So at the moment the code is the<br>> documentation, for all that is worth. If you point us at some specific<br>> chunk of logic that is too opaque we can try to beef it up with comments.<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>> --<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>><br>><br>> From: "Marty E. Plummer" <hanetzer@startmail.com><br>> To: openpower-firmware@lists.ozlabs.org<br>> Date: 10/10/2019 04:40 AM<br>> Subject: [EXTERNAL] [OpenPower-Firmware] Hardware documentation<br>> Sent by: "OpenPower-Firmware" <openpower-firmware-bounces<br>> +dcrowell=us.ibm.com@lists.ozlabs.org><br>><br>><br>><br>> Hello all.<br>><br>> So, I've gotten to the point I believe I've got code execution working<br>> (at the very least in theory; still need to do *something* easily<br>> detectable like writing a string to the scratch register) and am<br>> investigating what happens during the following isteps. I'm having a<br>> hard time following the execution of the c++ code past kernel.C due to<br>> all the indirections, and was wondering if there was some form of docs<br>> one could use as a reference.<br>><br>> Consider the arm pl011 uart driver, for example; it has a broad overview<br>> of the registers and their functionality specific to that particular<br>> piece of IP. Are there similar documents for fsi/scom/xscom/etc for the<br>> power9 chips? I already have register documents 1-3 for the p9 but they<br>> strike me as too broad, covering almost every thing in what seem to be<br>> very ... unspecific(?) ways. Something like 'to initialize the fsi bus,<br>> write 0xdeadbeef to register 0xdeadcode; to read something write this to<br>> there' and so on.<br>><br>> Thanks,<br>> Marty<br>> _______________________________________________<br>> OpenPower-Firmware mailing list<br>> OpenPower-Firmware@lists.ozlabs.org<br>> <a href="https://lists.ozlabs.org/listinfo/openpower-firmware" target="_blank">https://lists.ozlabs.org/listinfo/openpower-firmware</a><br>><br>><br>><br>> </font><br><br><br> </div></blockquote>
<div dir="ltr" > </div></div><BR>