<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 5, 2018 at 5:05 PM, Stewart Smith <span dir="ltr"><<a href="mailto:stewart@linux.vnet.ibm.com" target="_blank">stewart@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">"Tanous, Ed" <<a href="mailto:ed.tanous@intel.com">ed.tanous@intel.com</a>> writes:<br>
> Does POWER have any way of reporting detailed boot progress?  If, for<br>
> example, the USB link training starts processor init flows, is that<br>
> logged in a POWER system?  On x86, it would be logged as a POST code.<br>
<br>
</span>On POWER (currently at least) there's a few things in play.<br>
<br>
On OpenPOWER systems the only thing we currently actively communicate to<br>
the BMC is the IPMI FW progress sensor, which isn't especially fine<br>
grained, but it's what we have hooked up.<br>
<br>
We do print out more detailed progress information to the console<br>
though. What we print out to the console is roughly in two categories:<br>
a) ISTEPs (probably the closest thing we have to POST codes, in that<br>
   they're numbers), but these also have names because text is more<br>
   descriptive than numbers.<br>
b) log messages from OPAL (words, mostly around what we've probed/are<br>
initing)<br>
<br>
One thing to note about the istep numbers is that they can go<br>
*backwards* if our firmware needs to do a reconfigure loop (e.g. we're<br>
after a firmware update and needing to flash a seeprom inside the chip,<br>
or we've discovered a problem with one of the cores and we're going to<br>
disable it).<br>
<br>
On the more enterprise-y POWER systems, there's SRC codes, which<br>
are a set of incomprehensible hexadecimal numbers in a seemingly random<br>
order designed to a) fit on a tiny LCD screen on the front of the<br>
machine and b) not be strings that would have to be translated.<br>
(I *always* have to google them, and even then, I don't think it helps)<br>
<br>
If there's a problem during boot, we'd generally look at the console<br>
output.... unless boot failure is *really* *REALLY* early, in which case<br>
it's before we have any communications channel to the BMC open (and you<br>
have to go and poke at the chip through one of the debug<br>
interfaces... although we would like to improve this situation)<br>
<span class="gmail-"><br>
>> It just seems like the first thing anyone is going to do with these numbers is<br>
>> look them up and map them to something.  Wouldn’t it make sense to have<br>
>> done that mapping already at the API level so that every user and piece of<br>
>> code using this API doesn’t have to do it themselves?<br>
> That seems like a reasonable assumption, but practically isn't always<br>
> an option;  In general the POST code mappings are difficult to come<br>
> by, especially in initial system bringup, and that is when they are<br>
> most valuable.  If attempted, the ability to provide a mapping should<br>
> be made optional, which means the proposed interface still needs to<br>
> exist.<br>
<br>
</span>What if it was a "number and/or string" kind of interface? Would that work? On<br>
x86 if you only have the method of getting a number out, you could just<br>
have the numbers (unless you have a mapping somewhere), but on POWER we<br>
could hook this up to get a number and/or string from firmware.<br>
<span class="gmail-"><br>
>> I think what I’m hinting at here is that you could add a per-platform config file<br>
>> to your app that maps the codes to some enumerations in the DBus<br>
>> interface, and apply that mapping before you emit the signal. If you wanted<br>
>> to go back to numbers later you could just reverse the mapping using the<br>
>> same config file.  Please poke holes.<br>
><br>
> I would argue that this functionality is outside the scope of Patricks<br>
> patch.  We could very clearly do as you're suggesting, but it would be<br>
> error prone, and make per-platform configuration more difficult to<br>
> port, and would likely take a number of months to get correct for all<br>
> platforms.  As is, Patricks patch adds value outside of his direct<br>
> platform, as other teams would have an immediate use of it, and is<br>
> very clear and clean to implement.  Building the platform configurable<br>
> API you suggest would take a lot more time and effort, for only a<br>
> little incremental value.  This seems like a case of "Perfect is the<br>
> enemy of good".  As is, both the API and the daemon are things that I<br>
> would use today on my platforms.<br>
<br>
</span>Would a universal interface look something like this:<br>
<br>
- enum ProgressStages<br>
  (to support things like IPMI fw progress, i.e. generic and well<br>
  accepted what these mean)<br>
- int (descriptive integer, platform specific, 0=unknown)<br>
- string (descriptive, platform specific, can be null)<br>
<br>
with each platform implementing whatever parts of that they can.<br>
<br>
Looks like x86 post codes would go in the int, maybe a lookup table for<br>
the string (if available).<br>
<br>
For POWER, we'd poke the istep number into the int, and a description<br>
into the string (from the host, some unknown mechanism to do that).<br>
<br>
thoughts?<br></blockquote><div><br></div><div>I implemented port 80h POST codes for POWER9 hostboot a while back:</div><div><a href="https://github.com/open-power/hostboot/blob/c93bef31ae6ce781f9e0a11bb9224b6728ff120f/src/usr/initservice/istepdispatcher/istepdispatcher.C#L2312">https://github.com/open-power/hostboot/blob/c93bef31ae6ce781f9e0a11bb9224b6728ff120f/src/usr/initservice/istepdispatcher/istepdispatcher.C#L2312</a><br></div><div><br></div><div>On Zaius machines we are using that support with Patrick's snoop daemon and a separate daemon that receives the code via dbus and outputs it over the front 7seg debug display.</div><div>It has proven useful for getting early error/debug reports from technicians at scale e.g. "5 machines stopped at code 35h, 2 at 72h" provides a quick overview of what the problems are for me to debug further (since I have the decoder ring, and the istep names would be useless to them anyways).</div><div><br></div><div>-Rob</div></div></div></div>