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:test: Refactor mocked checkDumpStatus usage

When creating an instance of the SRC class in a testcase, it needs a
filled in mock of the checkDumpStatus() function. Instead of manually
doing that

PEL:test: Refactor mocked checkDumpStatus usage

When creating an instance of the SRC class in a testcase, it needs a
filled in mock of the checkDumpStatus() function. Instead of manually
doing that everywhere a PEL or SRC class is created, just do it in the
constructor of the mock DataInterface class.

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

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: Handle multiple inv paths per loc code

DataInterface::getInventoryFromLocCode() was only returning a single
inventory path from GetFRUsByExpandedLocationCode() even though multiple
paths may ha

PEL: Handle multiple inv paths per loc code

DataInterface::getInventoryFromLocCode() was only returning a single
inventory path from GetFRUsByExpandedLocationCode() even though multiple
paths may have been returned.

Mostly that was fine, except when a processor on a DCM was called out.
That would lead to only one processor on the DCM being set to not
functional by service_indicators.cpp, so on the web UI the actual CPU
called out may not have been marked as unhealthy (health status critical
in Redfish).

This commit changes getInventoryFromLocCode() to return all the paths
that GetFRUsByExpandedLocationCode() returns, and then makes the
corresponding changes in service_indicators.cpp to be able to handle
multiple inventory paths per location code when setting them to not
functional and creating a critical association.

The other code that was calling this function can just use the first
path returned, since in those cases it's just needed to get the VPD
information for the PEL, and all the paths would return the same info
anyway since they had the same location code.

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

show more ...

PEL: Add boot progress code to SRC hex data

Add the first 8 characters from the ASCII string field of the current
progress SRC, taken from the xyz.openbmc_project.State.Boot.Raw D-Bus
interface, to

PEL: Add boot progress code to SRC hex data

Add the first 8 characters from the ASCII string field of the current
progress SRC, taken from the xyz.openbmc_project.State.Boot.Raw D-Bus
interface, to SRC hex word 4 when creating a PEL.

This is how the field is defined in the PEL spec, and is to help with
debug so that one can know which part of the boot was occurring when
the PEL was created. Note that at this point most progress codes are
sent down from one of the host firmware subsystems and not created by
the BMC.

The field is only inserted into the SRC if those characters are present
and represent a valid 4 byte number, such as "C7004000". This is then
represented as 0xC7004000 in the SRC word. Otherwise, the word is left
at a value of zero.

For example:
...
"Valid Word Count": "0x09",
"Reference Code": "BD8D1001",
"Hex Word 2": "00080455",
"Hex Word 3": "2E2D0010",
"Hex Word 4": "C7004000", <---Progress code
"Hex Word 5": "00000000",
"Hex Word 6": "00000005",
"Hex Word 7": "00000000",
"Hex Word 8": "00000000",
"Hex Word 9": "00000000"
...

Signed-off-by: Vijay Lobo <vijaylobo@gmail.com>
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Iba41e88626c0e081e5759b994e3630ef8b12daf4

show more ...

PEL: Allow pretty symFRU/proc name in callout JSON

When callouts are passed in via JSON FFDC files, allow maintenance
procedures and symbolic FRUs to be the pretty names used in the
message registry

PEL: Allow pretty symFRU/proc name in callout JSON

When callouts are passed in via JSON FFDC files, allow maintenance
procedures and symbolic FRUs to be the pretty names used in the
message registry as well as the raw 7 character names.

Do this by attempting to look up the name as a key in the pretty name ->
raw name maps, and if found then use the raw name.

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

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: Pass in subsystem to use with additional data

There is a requirement to pass in the subsystem to use with
the additional data field. In the process update the user
header code and SRC with the

PEL: Pass in subsystem to use with additional data

There is a requirement to pass in the subsystem to use with
the additional data field. In the process update the user
header code and SRC with the passed-in subsystem value
instead from the message registry.

Signed-off-by: Sumit Kumar <sumit_kumar@in.ibm.com>
Change-Id: I08c8c3bab100fec581df9043f4bb27b28cb556e1

show more ...

PEL: pad hex words displayed in error message

In the message registry under "Documentation" and "Message", users can
include the hex words as part of the error message. This change pads

PEL: pad hex words displayed in error message

In the message registry under "Documentation" and "Message", users can
include the hex words as part of the error message. This change pads
the displayed hex words so that the full eight digit hex number is
displayed.

Signed-off-by: Zane Shelley <zshelle@us.ibm.com>
Change-Id: I32c4204a1643b585dc1309f67976f4abb44fb04c

show more ...

PEL: Update bmc & platform dump status in SRC section

With every PEL creation, the status of bmc and platform dumps -
Hardware and Hypervisor would be checked and status bits in SRC

PEL: Update bmc & platform dump status in SRC section

With every PEL creation, the status of bmc and platform dumps -
Hardware and Hypervisor would be checked and status bits in SRC
section updated accordingly.

Change-Id: I3ec7626611cf330f2ce235a97ee3046c0d32b6ab
Signed-off-by: Sumit Kumar <sumit_kumar@in.ibm.com>

show more ...

PEL: Change BMCSP01 maint procedure to BMC0001

This name change allows 4 characters of uniqueness instead of just 2.

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

PEL: Change BMCSP01 maint procedure to BMC0001

This name change allows 4 characters of uniqueness instead of just 2.

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

show more ...

PEL: Remove 'no_vpd_for_fru' maintenance procedure

This procedure was being used in a callout when the location code could
not be found on an inventory item. The code was changed to jus

PEL: Remove 'no_vpd_for_fru' maintenance procedure

This procedure was being used in a callout when the location code could
not be found on an inventory item. The code was changed to just not add
a callout in this case.

This was done for the following reasons:
1) There's no expected reason that the inventory would be missing a
location code for a valid inventory path.
2) There wasn't a way to give a hint to the end user about what the
callout should be in that case. Usually maintenance procedures should
have steps one can take to still do the appropriate replacement.
3) Because of 1), this case indicates a bad inventory path passed in by
the caller. Theoretically there is a way to have a 'bmc_code'
callout, but that wouldn't be appropriate to add in this log since
the intent of this one is for another problem.
3a) There is no way to create a new error log from inside a PEL section,
and I don't think this one case warrants coming up with a way to do
so.
4) The inventory path in question is still being added into a UserData
section so that development can debug it.

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

show more ...

PEL: Handle location codes for connectors

There are cases where PELs need to callout physical system connectors,
such as a USB or other cable connector. This would be done by
specif

PEL: Handle location codes for connectors

There are cases where PELs need to callout physical system connectors,
such as a USB or other cable connector. This would be done by
specifying the connector's location code in either the message registry
JSON or device callout JSON. The problem is that the connector may not
be modeled by the inventory, and even if it was, there would need to be
a way to get the serial number, etc for the FRU that connector is on to
use in the callout

Instead of forcing all connectors to be modeled in the inventory along
with a copy of the SN/FN/CC from the parent FRU just to do a callout,
this commit will just pop off the connector segment of the location
code, a '-Tx', before trying to expand it or getting its related
inventory item. That way, it will be operating on the parent FRU which
would be in the inventory with its SN/FN/CC. In the case of the
location code expansion, the connector segment will then just be
re-appended afterwards.

This commit also makes a change to the device path callouts code to
expand the location code of the callout from the device path JSON
instead of trying to look it up later, which would have lost the
connector portion.

Note that when a cable itself wants to be called out, there usually
would need be a symbolic FRU specified saying which cable it is, along
with the connector location codes. In that case, the SN/FN/CC of the
parent FRU would not show up in the PEL.

Change-Id: I8e0eb58dfe630858f75e64b11ac13432bff4d2d1

show more ...

test: openpower-pels: Fix unscoped use of DoAll

This is in the global scope on old releases of googletest but is fixed
and inaccessible when tested against newer ones.

Change-Id

test: openpower-pels: Fix unscoped use of DoAll

This is in the global scope on old releases of googletest but is fixed
and inaccessible when tested against newer ones.

Change-Id: I139f2455bb804e1c711c5eec3159164d9ac138fa
Signed-off-by: William A. Kennington III <wak@google.com>

show more ...

PEL: Support creator supplied power fault flag

User can supply POWER_THERMAL_CRITICAL_FAULT=TRUE as part
of AdditionalData entry in the event log to set the power
fault bit in PEL

PEL: Support creator supplied power fault flag

User can supply POWER_THERMAL_CRITICAL_FAULT=TRUE as part
of AdditionalData entry in the event log to set the power
fault bit in PEL

Tested: I ran unit test using docker. Also tested manually
by setting D-bus event log

Change-Id: Ifa03f091a7d1efcc67f181c2be1cc0a6240891e1
Signed-off-by: Vijay Lobo <vijaylobo@gmail.com>

show more ...

peltool: Print the Words6To9 'Description' field

Include the 'Description' field from the Words6To9 registry entry when printing
SRC error details.

Changed from this:

"

peltool: Print the Words6To9 'Description' field

Include the 'Description' field from the Words6To9 registry entry when printing
SRC error details.

Changed from this:

"Error Details": {
"Message": "There was a failure when reading a sensor device",
"CALLOUT_ERRNO": "0x5"
}

to this:

"Error Details": {
"Message": "There was a failure when reading a sensor device",
"CALLOUT_ERRNO": [
"0x5",
"errno of the failure"
]
}

Signed-off-by: Harisuddin Mohamed Isa <harisuddin@gmail.com>
Change-Id: Icc107b0516062eb891f14f3ff3f3cffd316c6d77

show more ...

Specify PEL callout priority and sort callouts.

Allow the priority to be passed in at creation time by calling the
CALLOUT_PRIORITY keyword. When creating a PEL, callouts will always

Specify PEL callout priority and sort callouts.

Allow the priority to be passed in at creation time by calling the
CALLOUT_PRIORITY keyword. When creating a PEL, callouts will always
be sorted by priority instead of creation time, the order is as follows:
H,M,A,B,C,L.

Signed-off-by: Miguel Gomez <mgomez@mx1.ibm.com>
Change-Id: I84345aaf3fad7b2e4958b698ab761966f499986b

show more ...

PEL: Use the real system names property

There is now a 'Names' property on the new
xyz.openbmc_project.Configuration.IBMCompatibleSystem interface that the
DataInterface::getSystemNa

PEL: Use the real system names property

There is now a 'Names' property on the new
xyz.openbmc_project.Configuration.IBMCompatibleSystem interface that the
DataInterface::getSystemNames function will read. The existing code was
mostly a placeholder until the actual interface showed up on D-Bus.

Since the path that holds the interface is system specific, and the PEL
code should only rarely need this, the code was changed to read it on
demand instead of at caching it startup.

Since getSystemNames() no longer returns a cached value, the signature
was changed slightly to remove the reference from the returned
std::vector<std::string> value.

The UserHeader constructor used to make a call to getSystemNames every
time, and that was changed to only call it when actually necessary,
which is when there is a severity value defined in the message registry
that depends on the system name.

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

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
specifi

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: Look for JSON Guard & Deconfig fields

There are optional 'Guarded' and 'Deconfigured' fields in the callout
JSON. If these are set, there are some bits in the SRC that should be

PEL: Look for JSON Guard & Deconfig fields

There are optional 'Guarded' and 'Deconfigured' fields in the callout
JSON. If these are set, there are some bits in the SRC that should be
set.

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

show more ...

PEL: Extract MRUs from callout JSON

The callout JSON can also contain MRU (Manufacturing Replaceable Unit)
IDs and priorities that should be added to a callout along with the FRU.

PEL: Extract MRUs from callout JSON

The callout JSON can also contain MRU (Manufacturing Replaceable Unit)
IDs and priorities that should be added to a callout along with the FRU.

Extract them from the JSON and add them to the callout if they are
there.

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

show more ...

PEL: Parse and add JSON callouts

In the SRC class, create callout objects for the callouts that were
contained in the incoming JSON array. These can be procedure, symbolic
FRU, or n

PEL: Parse and add JSON callouts

In the SRC class, create callout objects for the callouts that were
contained in the incoming JSON array. These can be procedure, symbolic
FRU, or normal hardware FRU callouts.

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

show more ...

PEL: Update getInventoryFromLocCode

Add an argument to this function that says if the location code passed
in is already expanded (has the fcs and mts placeholders filled in with
VPD

PEL: Update getInventoryFromLocCode

Add an argument to this function that says if the location code passed
in is already expanded (has the fcs and mts placeholders filled in with
VPD data).

This will be used in an upcoming commit that pulls location codes out of
PEL callouts.

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

show more ...

PEL: Add device path callouts in SRC section

When the SRC section is created and it has either CALLOUT_DEVICE_PATH or
(CALLOUT_IIC_BUS, CALLOUT_IIC_ADDR) in the AdditionalData property,

PEL: Add device path callouts in SRC section

When the SRC section is created and it has either CALLOUT_DEVICE_PATH or
(CALLOUT_IIC_BUS, CALLOUT_IIC_ADDR) in the AdditionalData property, look
up the device callouts to add to the section using
device_callouts::getCallouts().

CALLOUT_IIC_BUS can either be the plain bus number, like "5", or a /dev
path like "/dev/i2c-5". CALLOUT_IIC_ADDR is a 7 bit I2C address and can
either be in decimal, like "16", or in hex like "0x10".

For now, it just stores any MRUs that come back in the section debug
data that will be added to a UserData section.

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

show more ...