lg2: Add path to list of supported types in docs

Update the documentation on the lg2 API to include std::filesystem::path
in the list of supported types.

Also updated a README.md that was failing C

lg2: Add path to list of supported types in docs

Update the documentation on the lg2 API to include std::filesystem::path
in the list of supported types.

Also updated a README.md that was failing CI due to a line that was too
long for the formatting checks.

Change-Id: I61a3694d6ad994155829d433a62b2f4a05980e3d
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com>

show more ...

PEL: Adding a new BMC PEL for PDR Exchange Failure

This commit adds a new PEL when BMC fails to collect PDR from host.
GetPDR returns no response because of BMC PDR exchange failure as three
tries g

PEL: Adding a new BMC PEL for PDR Exchange Failure

This commit adds a new PEL when BMC fails to collect PDR from host.
GetPDR returns no response because of BMC PDR exchange failure as three
tries get exhausted and timeouts.

Change-Id: I6b928c53ca75f6b55dc124cc01eaba025ec9252a
Signed-off-by: Riya Dixit <riyadixitagra@gmail.com>

show more ...

PEL: Adding the support for Systems Key in message registry

The current implementation has the support for adding system specific
callouts with the help of 'System' key in message_registry.json.

Ad

PEL: Adding the support for Systems Key in message registry

The current implementation has the support for adding system specific
callouts with the help of 'System' key in message_registry.json.

Adding one more key named 'Systems' where it can have array of system
names in the form of strings. The 'Systems' key can be used to define
the shared callouts for a group of systems.

A unique callout to a specific system can be added using the existing
System key. If both 'System' and 'Systems' are not present or not
matching with the system name, then the default calloutList will be
taken if configured.

Tested:

The test setup has the following names for the compatible interface.

```
busctl -j get-property xyz.openbmc_project.EntityManager
/xyz/openbmc_project/inventory/system/chassis/Rainier_2U_Chassis
xyz.openbmc_project.Inventory.Decorator.Compatible Names
{
"type" : "as",
"data" : [
"com.ibm.Hardware.Chassis.Model.Rainier2U",
"com.ibm.Hardware.Chassis.Model.Rainier"
]
}
```
The callout section in the message_registry.json for TestError1 is
defined as below.
```
"Callouts": [
{
"Systems": ["com.ibm.Hardware.Chassis.Model.Rainier",
"com.ibm.Hardware.Chassis.Model.Blue_Ridge"],
"CalloutList": [
{"Priority": "medium", "SymbolicFRU": "service_docs"}
]
},
{
"System": "com.ibm.Hardware.Chassis.Model.Rainier",
"CalloutList": [
{"Priority": "high", "Procedure": "BMC0001"}
]
},
{
"CalloutList": [
{ "LocCode": "P0", "Priority": "high" },
{ "LocCode": "P0-C15","Priority": "low" }
]
}
]
```

Leads to PEL callouts section as below:
```
"Callout Section": {
"Callout Count": "2",
"Callouts": [{
"FRU Type": "Maintenance Procedure Required",
"Priority": "Mandatory, replace all with this type
as a unit",
"Procedure": "BMC0001"
}, {
"FRU Type": "Symbolic FRU",
"Priority": "Medium Priority",
"Part Number": "SVCDOCS"
}]
}
```

Signed-off-by: Arya K Padman <aryakpadman@gmail.com>
Change-Id: Iea65816dcb822bb07043897488a6251929548dc7

show more ...

PEL: Use raw procedure names in PEL msg reg

Start using the raw maintenance procedure names in the PEL message
registry, such as BMC0001, instead of the enum values, such as
'bmc_firmware'. This wa

PEL: Use raw procedure names in PEL msg reg

Start using the raw maintenance procedure names in the PEL message
registry, such as BMC0001, instead of the enum values, such as
'bmc_firmware'. This way, the script that generates documentation can
list the procedure in the section for that PEL. This was requested by
the support team.

Note that there is still one user of the enums - the checkstop analysis
code uses them when it creates callouts by passing in them via JSON user
data files.

There are pointers added to the README and schema to find the available
procedures and their descriptions.

Tested:
- The unit tests still work which verify the callout contents when PEL
callouts are created via the message registry.
- Also manually verified PEL procedure callouts look correct when
created from the message registry.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I3e8416956120d4dae1ff40592fd0df4f0285d072

show more ...

PEL: Support for CheckstopFlag msg reg field

Similiar to the DeconfigFlag field that was recently added, this one
indicates the PEL is for a hardware checkstop and results in a bit in
SRC hex word 5

PEL: Support for CheckstopFlag msg reg field

Similiar to the DeconfigFlag field that was recently added, this one
indicates the PEL is for a hardware checkstop and results in a bit in
SRC hex word 5 being set.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ib05de7471ad3e32f48e7f20a5c611abc119fe82a

show more ...

PEL: Support new DeconfigFlag msg reg field

Add a new field to the PEL message registry to indicate that some
hardware associated with a callout was deconfigured.

"DeconfigFlag": true

This results

PEL: Support new DeconfigFlag msg reg field

Add a new field to the PEL message registry to indicate that some
hardware associated with a callout was deconfigured.

"DeconfigFlag": true

This results in bit 6 in the SRC's hex word 5 being set. It is looked
at by the code that creates the periodic PELs when there is a system
running with deconfigured hardware.

Note: For something to be considered deconfigured, it doesn't
necessarily mean that firmware chose to not configure it. It could also
mean that it is broken or missing, at least in the case of power
supplies or fans.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I3e657cb52416fc50000e299bf2d583db7b67caf8

show more ...

PEL: Usability fixes to msg registry validator

This commit makes some usability improvements to the script that
validates the PEL message registry.

1) Renames the script from process_registry.py to

PEL: Usability fixes to msg registry validator

This commit makes some usability improvements to the script that
validates the PEL message registry.

1) Renames the script from process_registry.py to validate_registry.py
to more accurately reflect what it does.
2) Removes the '-v' option that was required to make it do any
validation and just run it by default. (At one point in the past it
was going to do more than just validation.)

An internal improvement was made to just use argparse's ability to
check for required parameters instead of checking manually.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I30c4ba5c693388048095b385d5cae1993e906975

show more ...

PEL: Define JSON schema to capture the journal

This chain of commits is adding the functionality to be able to capture
portions of the journal into PEL UserData sections by defining it in the
messag

PEL: Define JSON schema to capture the journal

This chain of commits is adding the functionality to be able to capture
portions of the journal into PEL UserData sections by defining it in the
message registry entry for an error.

This commit updates the JSON schema for it, and the README.

From the README, examples are:

"JournalCapture": {
"NumLines": 30
}

"JournalCapture":
{
"Sections": [
{
"SyslogID": "phosphor-bmc-state-manager",
"NumLines": 20
},
{
"SyslogID": "phosphor-log-manager",
"NumLines": 15
}
]
}

The first example will capture the previous 30 lines from the journal
into a single UserData section.

The second example will create two UserData sections, the first with the
most recent 20 lines from phosphor-bmc-state-manager, and the second
with 15 lines from phosphor-log-manager.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I005a84547b43887a5f746832c68f4b40b6334404

show more ...

PEL: Fix markdownlint errors in reg/README.md

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ia1d51f87ec4e032accc15e8f659fdb00f7961e0d

prettier: re-format

Prettier is enabled in openbmc-build-scripts on Markdown, JSON, and YAML
files to have consistent formatting for these file types. Re-run the
formatter on the whole repository.

prettier: re-format

Prettier is enabled in openbmc-build-scripts on Markdown, JSON, and YAML
files to have consistent formatting for these file types. Re-run the
formatter on the whole repository.

Change-Id: I6e8d56540a30898369d7f232d900fd74de2e7bd1
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

PEL: Add CalloutsWhenNoADMatch msg reg support

There is a new use case where we need to do one callout in the message
registry based on the value of an AdditionalData field value, and
another callou

PEL: Add CalloutsWhenNoADMatch msg reg support

There is a new use case where we need to do one callout in the message
registry based on the value of an AdditionalData field value, and
another callout in all other cases.

To support this, this commit is adding a new 'CalloutsWhenNoADMatch'
field in the PEL message registry that allows one to add callouts when
there is no match on the 'ADValue' field. This behaves like an 'else'
leg to the 'if AdValue == X' structure in the message registry.

Example:
{
"ADName": "PROC_NUM",
"CalloutsWithTheirADValues":
[
{
"ADValue": "0",
"Callouts":
[
// callouts when PROC_NUM == 0
]
},
{
"ADValue": "1",
"Callouts":
[
// callouts when PROC_NUM == 1
]
}
],
"CalloutsWhenNoADMatch": [
{
// callouts when PROC_NUM != 0 or 1
}
]
}

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ib8e208ff950a643302e856c7dd2b7474fec61b26

show more ...

PEL: Convert component ID list to JSON

With a machine readable list of BMC PEL component IDs, the PEL parsers
will be able to use it to look up component names for display.

The component ID names a

PEL: Convert component ID list to JSON

With a machine readable list of BMC PEL component IDs, the PEL parsers
will be able to use it to look up component names for display.

The component ID names all have 'bmc' in them to avoid confusion with
similar components in other subsystems, like hostboot. This was added
at the request of hostboot.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ia08dee13695a55f34885940348cb44bce9cb7bb5

show more ...

PEL: Remove PowerFault from message entries, registries, and code

The PowerFault flag is deprecated and should be removed in both the
registry and code references. Its functionality is superseded by

PEL: Remove PowerFault from message entries, registries, and code

The PowerFault flag is deprecated and should be removed in both the
registry and code references. Its functionality is superseded by the
critical_system severity level.

Signed-off-by: Mike Capps <mikepcapps@gmail.com>
Change-Id: I1bc1898d9589e0678b5a37b87289c6588859f2ee

show more ...

PEL: Support 'PossibleSubsystems' in msg registry

Add a 'PossibleSubsystems' field to the message registry schema where
someone can list which subsystems they might pass into the PEL_SUBSYSTEM
Addit

PEL: Support 'PossibleSubsystems' in msg registry

Add a 'PossibleSubsystems' field to the message registry schema where
someone can list which subsystems they might pass into the PEL_SUBSYSTEM
AdditionalData property field when creating a PEL.

The PossibleSubsystems value will be used by a off-BMC script that
generates field documentation for SRCs, so it knows what all SRC ASCII
string values are possible for that entry since the subsystem is part of
them. For example, if that field was ['processor', 'memory'], then that
means the possible SRCs are BD10AAAA and BD20AAAA for reason code
'AAAA'.

The Subsystem and PossibleSubsystems fields are mutually exclusive in
the message registry, so code changes had to be made to support the
subsystem field now being optional.

There is now a chance that even though the subsystem is supposed to be
passed in using PEL_SUBSYSTEM, it isn't. In that case, the 'Other'
subsystem will be used, since it seems fairly generic.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ic8087fc46b2a192459b7287186f8972610e84730

show more ...

PEL: Dynamic location code for registry callout

The PEL callout type 'symbolic FRU with trusted location code'
previously had both the symoblic FRU name and the location code
specified in the PEL me

PEL: Dynamic location code for registry callout

The PEL callout type 'symbolic FRU with trusted location code'
previously had both the symoblic FRU name and the location code
specified in the PEL message registry. However, there are cases where
the location code is not known until runtime so it cannot be specified
in the registry.

To solve this, create a boolean 'UseInventoryLocCode` key that can be
used in the registry callout entry to specify that the location code to
use for the callout should come from the FRU passed in using the
CALLOUT_INVENTORY_PATH entry in the AdditionalData event log property.
In this case, that FRU will not be added as a normal FRU callout as it
would normally be otherwise. The registry that uses this must be the
first one in the callout list.

For example:
{
"Priority": "high",
"SymbolicFRUTrusted": "air_mover",
"UseInventoryLocCode": true
},

along with CALLOUT_INVENTORY_PATH=<processor 0 path>

would result in a symbolic FRU callout with the trusted location code
being the processor 0 location code.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Iaf65c523803662313f2ad5e197262b9f4e722332

show more ...

PEL: Point action flags documention to its rules

Add a link from where the PEL action flags are described to the rules on
how the code sets them.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Ch

PEL: Point action flags documention to its rules

Add a link from where the PEL action flags are described to the rules on
how the code sets them.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I5d562ff447913f0fd8dd784ea809873917aa696b

show more ...

PEL: Add registry testing steps to readme

Give an overview of how to modify and test new entries in the PEL
message registry.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ib039b18b70

PEL: Add registry testing steps to readme

Give an overview of how to modify and test new entries in the PEL
message registry.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ib039b18b702251c85d8662a0143f44899cbba789

show more ...

PEL: Document support for sys based severities

Update the PEL message registry JSON schema and readme to support PEL
severity values that can depend on the system type.

For example:
"Severity"

PEL: Document support for sys based severities

Update the PEL message registry JSON schema and readme to support PEL
severity values that can depend on the system type.

For example:
"Severity":
[
{
"System": "systemA",
"SevValue": "predictive"
},
{
"System": "systemB",
"SevValue": "recovered"
},
{
"SevValue": "unrecoverable"
}
]

On system systemA, the severity is predictive.
On system systemB, it is recovered.
On any other system it is unrecoverable.

The original method is still valid, like:
"Severity": "recovered"

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ie1abae8f7a1dc55daec86ee86b4c1c4f7b83b19b

show more ...

PEL: Explain PEL callouts

Update the READMEs to describe how callouts can be added to PELs.

At a high level, they can be added by specifying them completely in
AdditionalData fields like CALLOUT_IN

PEL: Explain PEL callouts

Update the READMEs to describe how callouts can be added to PELs.

At a high level, they can be added by specifying them completely in
AdditionalData fields like CALLOUT_INVENTORY_PATH, by specifying them
completely in the PEL message registry JSON, or by a combination of the
2.

A future commit will add the new JSON schema.

Note, there is still a use case that maybe isn't covered here, and that
is when an application like openpower-hw-diags gets its full callout
list, including priorities, from its own data. This should cover
everything else though.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ia42286b8d1bf1e13d1be9f742c532ab48f6e7ff9

show more ...

PEL: Registry: Make "Action Flags" optional

The Action Flags bits in the PEL need to be in agreement with other PEL
fields, such as if the severity is informational then the 'report' flag
cannot be

PEL: Registry: Make "Action Flags" optional

The Action Flags bits in the PEL need to be in agreement with other PEL
fields, such as if the severity is informational then the 'report' flag
cannot be on. In fact, for most logs all of these flags can be deduced
from the other PEL fields.

So, to avoid the case of the action flags in the registry not matching
the other PEL fields, make them optional and the BMC code will set them
appropriately. And when they are specified, the BMC code will still run
through the same code to ensure everything is in agreement.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I5bea83d01846d7a2d3307666e6d0758a99229e3f

show more ...

PEL: Add message registry README

This README describes the message registry in an easier to read way than
what is buried in the JSON schema.

The commit also provides a file to document which compon

PEL: Add message registry README

This README describes the message registry in an easier to read way than
what is buried in the JSON schema.

The commit also provides a file to document which component IDs are
used by which repositories/applications.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ibf1109e0a1fb6fff872cfa91d79c007ecf5527b0

show more ...