diff options
| author | Stephen Glancy <sglancy@us.ibm.com> | 2017-09-21 10:14:04 -0500 |
|---|---|---|
| committer | Daniel M. Crowell <dcrowell@us.ibm.com> | 2017-10-02 23:45:51 -0400 |
| commit | 3890040afa1dc93d58476d68df35cb44d49c57b2 (patch) | |
| tree | 1c1538e4b8bb40a8a9d65bc8e900a84bb2caa586 /src/import/chips/p9/procedures/hwp/memory/lib/ccs/ccs.C | |
| parent | f21a18e501c28d932ee24f11a7a3ffaa93228735 (diff) | |
| download | talos-hostboot-3890040afa1dc93d58476d68df35cb44d49c57b2.tar.gz talos-hostboot-3890040afa1dc93d58476d68df35cb44d49c57b2.zip | |
Updates error paths for PRD FIR checking
FIR's could cause errors within hardware procedures. PRD has
the capability to retrigger a procedure if it sees an error.
We might be able to avoid IPL issues with this, so if a FIR
has been hit during hardware enabled code (CCS or calibration),
then log the error and let PRD find the "new" FIR that could have
caused the hardware engine to have an issue. If there is some other
problem, the retriggered HWP will find it.
Change-Id: I81599d1d0c4b4c256b79820b4a7e2eafc09e206b
Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/46571
Tested-by: FSP CI Jenkins <fsp-CI-jenkins+hostboot@us.ibm.com>
Reviewed-by: JACOB L. HARVEY <jlharvey@us.ibm.com>
Reviewed-by: Louis Stermole <stermole@us.ibm.com>
Tested-by: Jenkins Server <pfd-jenkins+hostboot@us.ibm.com>
Tested-by: HWSV CI <hwsv-ci+hostboot@us.ibm.com>
Reviewed-by: ANDRE A. MARIN <aamarin@us.ibm.com>
Tested-by: Hostboot CI <hostboot-ci+hostboot@us.ibm.com>
Reviewed-by: Jennifer A. Stofer <stofer@us.ibm.com>
Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/46584
Tested-by: Jenkins OP Build CI <op-jenkins+hostboot@us.ibm.com>
Tested-by: Jenkins OP HW <op-hw-jenkins+hostboot@us.ibm.com>
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Diffstat (limited to 'src/import/chips/p9/procedures/hwp/memory/lib/ccs/ccs.C')
| -rw-r--r-- | src/import/chips/p9/procedures/hwp/memory/lib/ccs/ccs.C | 7 |
1 files changed, 6 insertions, 1 deletions
diff --git a/src/import/chips/p9/procedures/hwp/memory/lib/ccs/ccs.C b/src/import/chips/p9/procedures/hwp/memory/lib/ccs/ccs.C index b82951221..669048513 100644 --- a/src/import/chips/p9/procedures/hwp/memory/lib/ccs/ccs.C +++ b/src/import/chips/p9/procedures/hwp/memory/lib/ccs/ccs.C @@ -37,6 +37,7 @@ #include <mss.H> #include <lib/ccs/ccs.H> +#include <lib/fir/check.H> using fapi2::TARGET_TYPE_MCBIST; using fapi2::TARGET_TYPE_MCA; @@ -83,6 +84,7 @@ fapi2::ReturnCode fail_type( const fapi2::Target<TARGET_TYPE_MCBIST>& i_target, const uint64_t& i_type, const fapi2::Target<TARGET_TYPE_MCA>& i_mca ) { + fapi2::ReturnCode l_failing_rc(fapi2::FAPI2_RC_SUCCESS); // Including the MCA_TARGET here and below at CAL_TIMEOUT since these problems likely lie at the MCA level // So we disable the PORT and hopefully that's it // If the problem lies with the MCBIST, it'll just have to loop @@ -112,7 +114,10 @@ fapi2::ReturnCode fail_type( const fapi2::Target<TARGET_TYPE_MCBIST>& i_target, fapi2::MSS_CCS_HUNG().set_MCBIST_TARGET(i_target), "%s CCS appears hung", mss::c_str(i_target)); fapi_try_exit: - return fapi2::current_err; + // Due to the PRD update, we need to check for FIR's + // If any FIR's have lit up, this CCS fail could have been caused by the FIR + // So, let PRD retrigger this step to see if we can resolve the issue + return mss::check::fir_or_pll_fail(i_target, fapi2::current_err); } /// |
