<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
>> I don't think this needs to be solved immediately but "which processor</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
>> type is installed in a socket" is not necessarily fixed. For example,</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
>> AMD socket SP5[1] supports both "Genoa" and "Bergamo" processor variants,</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
>> which could require different post code handling. There is little</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
>> reason why a system with an SP5 socket couldn't have a BMC that should</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
>> be able to handle both Genoa and Bergamo chips.</div>
<div class="elementToProof" id="Signature">
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Agree with the general direction. We would need to accomplish a couple things before we get here.</div>
<ol style="margin-top: 0px; margin-bottom: 0px;" data-editing-info="{"applyListStyleFromLevel":false,"orderedStyleType":4}" start="1">
<li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); list-style-type: "(1) ";">
<div role="presentation" class="elementToProof">We would need EM or other runtime detection of CPU types.</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); list-style-type: "(2) ";">
<div role="presentation" class="elementToProof">Also to extend your example, I would not be surprised if Genoa and Bergamo are more similar than different. So, having different handler JSONs would mean they might be more alike than different. But, we can do
that optimization when we cross that bridge.</div>
</li><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); list-style-type: "(3) ";">
<div role="presentation" class="elementToProof">I believe there are post codes defined by system software (BIOS) vendors in addition to CPU vendors. I would not be surprised if there are additional codes which are then OEM defined. This might need platform
layer extensions because I would be surprised if there are universally consistent.</div>
</li></ol>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
At the moment, I think we can go with machine owners packaging the configuration in their meta-layer while the nuances are developed for CPU type detection along with handling of SW/OEM bits.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
>> Please add a name and/or description field.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
>> I don't think we should do conversion to decimal just to make it JSON-native; optimize for humans and (especially) reviewers.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Ah yes, this will make it easy to review and the configuration more human readable. I will go ahead and push updates to change this (Add name, description fields and convert the primary/secondary to hex strings).</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
>> I'd like to see a jsonschema validation of whatever the config ends up being</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Yes. This will really help catch a lot of things at compile time. </div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
>> You should also consider how multi-host systems, like yosemite4, might be handled here.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
+1. I was thinking of extending the code to use magic fields in the configuration for the service to insert the "host" index.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Is there a general common approach taken for this by other services? I see EM uses $ to indicate variables.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Example:</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
```</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
"arguments": {</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
"POWER_RAIL": "/path/to/host$HOST",</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
```</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
>> Why do we need to be able to trigger custom systemd services?</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
I was considering cases certain platforms could do some platform specific debug collection when they receive certain post-code.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div class="elementToProof" id="divtagdefaultwrapper">
<p style="direction: ltr; margin-top: 0px; margin-bottom: 0px;" class="elementToProof">
<span style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Thanks,</span></p>
<p style="direction: ltr; margin-top: 0px; margin-bottom: 0px;" class="elementToProof">
<span style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Amithash</span></p>
</div>
</div>
<div id="appendonsend"></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style="display: inline-block; width: 98%;">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b>From:</b> Patrick Williams<br>
<b>Sent:</b> Friday, May 30, 2025 6:17 AM<br>
<b>To:</b> Amithash Prasad<br>
<b>Cc:</b> LF/OpenBMC Mailing List; wangkuiying.wky@alibaba-inc.com; zhikui.ren@intel.com<br>
<b>Subject:</b> Re: [RFC] Special handlers for post-codes </div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-size: 11pt;" class="elementToProof">On Fri, May 30, 2025 at 02:02:20AM +0000, Amithash Prasad wrote:<br>
> Hello,<br>
><br>
> There are many occasions when a post code from a server actually means something is wrong — especially crucial if a boot failure occurs before the part of the system firmware capable of sending a SEL to the BMC is loaded. To support this, I am proposing enhancing
phosphor-post-code-mfg to support configurable special handling of post codes.<br>
<br>
Thanks, this looks like interesting work. I know some processors that<br>
have magic postcodes that mean things like memory training has failed.<br>
<br>
How do you anticipate these configurations are managed? I see 3<br>
options:<br>
<br>
1. People add them to their meta-layer for a particular machine<br>
and/or processor.<br>
<br>
2. The configuration files are part of phosphor-post-code-manager<br>
(and enabled via CompatibleHardware matching from entity-manager?).<br>
<br>
3. The configuration is part of the entity-manager config instead.<br>
<br>
My initial impression is that we have two different kinds of configs:<br>
<br>
- Configuration that is entirely processor dependent; any system<br>
using a particular processor version will have the same postcode<br>
handling.<br>
<br>
- Configuration that is vendor / BIOS / machine specific.<br>
<br>
For configuration that is processor dependent, install option (1) does<br>
not seem like a good direction, since it means we're going to be<br>
duplicating this work. I would lean towards option (2) here, but you<br>
probably need a method to load multiple configs: "processor.json" and<br>
"system.json".<br>
<br>
I don't think this needs to be solved immediately but "which processor<br>
type is installed in a socket" is not necessarily fixed. For example,<br>
AMD socket SP5[1] supports both "Genoa" and "Bergamo" processor variants,<br>
which could require different post code handling. There is little<br>
reason why a system with an SP5 socket couldn't have a BMC that should<br>
be able to handle both Genoa and Bergamo chips.<br>
<br>
><br>
> Example configuration:<br>
> [<br>
> {<br>
<br>
Please add a name and/or description field.<br>
<br>
> "primary": [123],<br>
> "secondary": [234, 123],<br>
<br>
This is a bit awkward to me; you should probably look at what<br>
entity-manager does. People tend to think of postcodes as hex and not<br>
decimal. I don't think we should do conversion to decimal just to make<br>
it JSON-native; optimize for humans and (especially) reviewers.<br>
<br>
> "targets": ["my_special.service"]<br>
<br>
Why do we need to be able to trigger custom systemd services? This<br>
isn't clear. To me, this starts to cause the configs to be system<br>
specific, which is far less ideal.<br>
<br>
I'd rather see some well-defined "actions" like "catastrophic failure<br>
that requires a server reboot".<br>
<br>
You should also consider how multi-host systems, like yosemite4, might<br>
be handled here. We will have multiple instances of phosphor-post-code-manager<br>
running, one for each host. If you do have systemd targets, they have<br>
to be templated.<br>
<br>
> },<br>
> {<br>
> "primary": [999],<br>
> "targets": ["power_failure.service"],<br>
> "event": {<br>
> "name": "xyz.openbmc_project.State.Power.PowerRailFault",<br>
> "arguments": {<br>
> "POWER_RAIL": "MyDevice",<br>
> "FAILURE_DATA": ""<br>
> }<br>
> }<br>
> }<br>
> ]<br>
><br>
<br>
I'd like to see a jsonschema validation of whatever the config ends up<br>
being. We do that in at least entity-manager and sdbusplus if you need<br>
examples (EM uses JSON for the schema, sdbusplus uses YAML).<br>
<br>
> I would love to get feedback before I continue down this path.<br>
><br>
><br>
> Thanks,<br>
><br>
> Amithash<br>
<br>
[1]: <a data-auth="NotApplicable" rel="noopener noreferrer" class="OWAAutoLink" id="OWA224d2cb8-e1db-8314-2637-4dae9fbc0986" target="_blank" href="https://en.wikipedia.org/wiki/Socket_SP5">
https://en.wikipedia.org/wiki/Socket_SP5</a><br>
<br>
--<br>
Patrick Williams<br>
</div>
</body>
</html>