talos-hostboot/src/usr/sbeio/common, branch master

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

Change sbe restart fail hwCallouts from GARDs to DECONFIG

2018-04-16T20:15:34+00:00

During the hreset and start_cbs hwps if we get an error (likely scom or cfam error) then we want to callout the processor. Previously we were GARDing out the processor if this occurred. It was pointed out this might be a little harsh so instead we are going to deconfigure the processor Change-Id: Id5bfe0af392a4863ef2d225777bc17f3c308340e Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/56960 Reviewed-by: Daniel M. Crowell 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: William G. Hoffa

Improve linking of PLIDs for sbe_retry_handler

2018-04-13T17:34:41+00:00

Previously if a PLID was passed to the ctor of the sbe_retry_handler we would link all errors logs created during the process of recovering the SBE with this PLID. But if no PLID was passed then we would not link the logs. This commit changes it so if no PLID is passed to the ctor then the first log created in the recovery process will become the PLID that all logs after will be set to. Change-Id: I93ef3a48b4cc1d7df3237d7ba3dfefba21d5fb6b Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/56885 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: Daniel M. Crowell

Revert "Clear perv scrach register prior to triggering HRESET"

2018-04-10T20:02:42+00:00

This reverts commit 4f32915aa1240d07bb2671010f95695ba5f306c3. Change-Id: Ie51fd274d018df63aef6f725bf57c7b1f7f59265 Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/57026 CI-Ready: Christian R. Geddes Reviewed-by: Christian R. Geddes Tested-by: Christian R. Geddes

Clear perv scrach register prior to triggering HRESET

2018-04-10T19:54:44+00:00

Before we initiate an HRESET we need to make sure that the perv scratch register that the SBE looks at during boot are all zeros. When these registers are zeros the SBE will ignore them and pull values from its own image. We need to do this because Hostboot will repurpose these registers after the SBE boots the first time so the data in the registers is no longer valid. It is okay for the SBE to pull the values from it's own image because during the IPL hostboot customized the SBE image with the correct values. Change-Id: I8b434d04cde3c384e35a3089a349a1d121b6b1dc RTC: 180242 Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/56959 Reviewed-by: Martin Gloff Tested-by: Jenkins Server Tested-by: Jenkins OP Build CI CI-Ready: Christian R. Geddes Tested-by: Jenkins OP HW Reviewed-by: Roland Veloz Reviewed-by: Daniel M. Crowell

Enable OpenPower SBE Vital Attention handler

2018-04-10T17:46:19+00:00

If PRD notices that a sbe vital attention is set (TP_LFIR 26) then it will call hostboot code to attempt to recover the SBE. If this occurs during IPL time then hostboot will not be able to recover the SBE and we will deconfigure the processor. If this occurs during runtime HBRT will attempt to run the retry_handler. This will result in us calling hreset on the SBE that failed. If we were able to recover the SBE then no error will be returned. If we are unable to recover the SBE then we will return an error with a deconfig record. Change-Id: I3da6ec932ef8e59f7b2a184621a47e88d465e0c5 RTC: 167191 Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/56821 CI-Ready: Daniel M. Crowell 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