blackbird-hostboot/src/usr/sbeio/common, branch 07-25-2019

SMF: Port NVRAM Reading Logic From Skiboot

2018-11-08T02:36:51+00:00

As part of SMF secure memory distribution, we need to be able to read the size of secure memory from NVRAM PNOR partition (for OpenPOWER). The functionality to read (index into) NVRAM already exists in skiboot. This commits ports the bare minimum functionality required to read NVRAM from skiboot to hb. Change-Id: I17b9014ec3df590bcd8745ae70e0f96e36580117 RTC: 192411 Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/67414 Tested-by: Jenkins Server Tested-by: Jenkins OP Build CI Tested-by: Jenkins OP HW Tested-by: FSP CI Jenkins Reviewed-by: Dean Sanner Reviewed-by: Roland Veloz Reviewed-by: Nicholas E. Bofferding Reviewed-by: Daniel M. Crowell

Correctly handle psu FFDC on OpenPower Systems

2018-09-27T18:48:18+00:00

Prior to this change, there was a switch statement that was saying "if this RC is found in the psu FFDC, then do this recovery action" that is obviously not very easy to maintain because for every error we need to add the proper action. Instead of this, now we will just look if any GARD records were created as part of the error found in the FFDC. If a gard was found , Hostboot will stop trying to recover the SBE and instead enter a reconfig loop to try and IPL w/ the target garded out. Again this only applies to OP system, in the FSP world we will commit the error logs w/ the gard records and then TI telling HWSV they need to look at the SBE Change-Id: I04e03feebf2bbd1eae2d725bee31993062fe7c94 Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/66374 Reviewed-by: Matt Derksen Tested-by: Jenkins Server Tested-by: Jenkins OP Build CI Tested-by: Jenkins OP HW Tested-by: FSP CI Jenkins Reviewed-by: Roland Veloz Reviewed-by: Daniel M. Crowell

get FAPI_POS for all valid target types passed in SBE FIFO ffdc

2018-09-10T15:05:06+00:00

-In some cases the the SBE will return a proc target type as part of the SBE FFDC buffer, the current code only considers non-proc types when converting the FFDC buffer contents to a target. This commit will correctly convert all valid target types passed back in the FFDC buffer. Change-Id: If9f3542f18b72652d3353b6f167a264fcba21352 CQ:SW444855 Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/65832 Tested-by: Jenkins Server Reviewed-by: Christian R. Geddes Tested-by: HWSV CI Reviewed-by: Dean Sanner Tested-by: PPE CI Tested-by: Hostboot CI Reviewed-by: Jennifer A. Stofer Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/65835 Tested-by: Jenkins OP Build CI Tested-by: Jenkins OP HW Tested-by: FSP CI Jenkins

Only switch sides and perform hreset if SEEPROM side versions match

2018-07-19T20:35:30+00:00

In the event that the SBE fails hostboot will attempt to recover it. During runtime hostboot will attempt an HRESET if the SBE is in a failed state. When the SBE performs the HRESET it will save some important information that will persist through the reset. If one side is failing to recover the retry code will attempt to switch sides and do the hreset. If the SBE seeproms have different versions of the SBE code the data that was supposed to persist through the HRESET will be in incorrect places because the version mismatch. Because of this we cannot switch seeprom sides and perform a hreset if the seeproms have different level of the SBE code. CQ: SW438029 Change-Id: Ic7078a886088cc4d5355cc076e72d0fc36f85027 Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/61605 Reviewed-by: Matt Derksen Tested-by: Jenkins Server Tested-by: Jenkins OP Build CI Tested-by: FSP CI Jenkins Tested-by: Jenkins OP HW Reviewed-by: Daniel M. Crowell Reviewed-by: William G. Hoffa

Link PLID for failing SBE recovery in PRD path w/ other related logs

2018-06-14T01:22:12+00:00

When Hostboot fails to recover the SBE after PRD has alerted HB that the SBE needs recovery then HB will create an error log. Prior to this commit this log was not getting it's PLID linked with the other logs that get generated over the course of the sbe recovery attempts. This commit ensures that if any logs were created during the sbe recovery that they will be linked with the final log that tells us that the recovery was unsuccessful. Change-Id: I7af47cf437af0b68b954ab2b0e95aec660c11bab Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/59648 Tested-by: Jenkins Server Tested-by: Jenkins OP Build CI Tested-by: Jenkins OP HW Tested-by: FSP CI Jenkins Reviewed-by: Roland Veloz Reviewed-by: Prachi Gupta Reviewed-by: William G. Hoffa Reviewed-by: Daniel M. Crowell

Deconfig record can't get added to vitalAttn elog on FSP

2018-05-14T15:31:57+00:00

On FSP system we should never try to call vitalAttnHandler because the fir bits that trigger this code should be masked. However we have seen issues where for whatever reason the firs get unmasked. If we happen to fall into this code on a FSP system we want to make sure that no deconfigure records get added to the error logs that get generated. If deconfig records get added it can collide with the flow that hwsv is doing to attempt to recover the SBE. Also in this commit we removed the TODO for disabling the OCC if the SBE dies. We have decided that it is no longer necessary to disable the OCC if the SBE dies. See story for more information. Change-Id: Ib75dc34a122a37853047af67ec8858dbca11e4a2 CQ: SW427127 RTC: 180244 Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/58226 Reviewed-by: Martin Gloff Reviewed-by: Brian E. Bakke Tested-by: Jenkins Server Tested-by: Jenkins OP Build CI Tested-by: FSP CI Jenkins Reviewed-by: Roland Veloz Reviewed-by: Daniel M. Crowell Tested-by: Jenkins OP HW

Add error log for sbe poweron fails and clean up errlog commits

2018-05-07T20:13:03+00:00

This commit introduces a new error log that will get displayed when a slave SBE fails to reach runtime after the intial start_cbs. Before adding this there was no notification letting the user know that Hostboot failed to boot the slave sbe and that it gave control to the FSP so hwsv can figure out what to do next. In addition to this new error log this commit also updates other errlCommit func calls in the sbe_retry_handler to ensure we are using SBEIO as the component id for these error logs. Change-Id: I73854f753a6186958d55909e8e37a605c1ad57c9 Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/58049 Tested-by: Jenkins Server Tested-by: Jenkins OP Build CI Tested-by: Jenkins OP HW Tested-by: FSP CI Jenkins Reviewed-by: Martin Gloff Reviewed-by: Brian E. Bakke Reviewed-by: Roland Veloz Reviewed-by: Daniel M. Crowell

Change all FAPI_INVOKE calls to be FAPI_EXEC in sbe_retry_handler

2018-04-24T00:47:33+00:00

There are instances where we will call the sbe_retry_handler in the middle of a HWP. This happens when we attempt to use the FIFO path to scom during a HWP and the SBE is dead. This results in the sbe_retry_handler being called which itself will try to run HWPs. If the sbe_retry_handler attempts to call a HWP with FAPI_INVOKE while handling a fail inside a HWP the INVOKE call will get stuck waiting for the fapi mutex to get unlocked which it never will. To get around this we are making all FAPI_INVOKE calls into FAPI_EXEC calls and we are handling the returnCode from FAPI_EXEC locally. Change-Id: I87e54be4ca738c3c327e6519093fb4b6848a542b Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/57401 Reviewed-by: Martin Gloff Tested-by: Jenkins Server Tested-by: Jenkins OP Build CI Tested-by: Jenkins OP HW Tested-by: FSP CI Jenkins Reviewed-by: Roland Veloz Reviewed-by: Daniel M. Crowell

Add recovery summary traces for sbeAttemptRecovery for FSP runtime

2018-04-18T21:22:33+00:00

Previously you had to look at other traces, or decipher to binary trace to determine if the sbe was recovered or not, this commit adds clear traces after the recover effort is done to tell whether it was successful or not. Change-Id: I17ce4de2f7e1168409758ca0ef1a5eaa044d6728 Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/57146 CI-Ready: Christian R. Geddes Reviewed-by: Martin Gloff Tested-by: Jenkins Server Tested-by: Jenkins OP Build CI Tested-by: Jenkins OP HW Tested-by: FSP CI Jenkins Reviewed-by: Roland Veloz Reviewed-by: Daniel M. Crowell

Ensure that we only attempt to recover from vital attn on BMC systems

2018-04-18T15:55:58+00:00

On an FSP system PRD should never get triggered on an SBE vital attn. However if for any reason PRD attempts to handle a vital attn on an FSP system HB should not actually perform any recovery and we should just return an error back to PRD signaling that we could not recover. PRD should stop mask off the error after the handler returns with an error saying we could not recover. Change-Id: If1666bd028da9a94bed34d79da34f6264beb0fbf Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/57176 CI-Ready: Christian R. Geddes Reviewed-by: Martin Gloff Tested-by: Jenkins Server Tested-by: Jenkins OP Build CI Tested-by: Jenkins OP HW Tested-by: FSP CI Jenkins Reviewed-by: Roland Veloz Reviewed-by: William G. Hoffa