Update SBE In Istep7.5 In SMF Mode

A bug was discovered on OpenPOWER systems wherein if SMF
is enabled, we would checkstop in istep10.1 when trying
to XSCOM to the slave proc. The issue was that SBE at that
time didn't know we were booting in SMF mode and so didn't
set up the XSCOM BAR for the slave proc appropriately.
The solution is to force SBE update in istep7.5 if SMF is
enabled in the MRW (ATTR_SMF_CONFIG) but SBE doesn't yet
know about that (bit 16 in scratch reg6 is not set).

Change-Id: Ibaa2d1e5b441f378528443aa84e5cd61789792dd
Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/81950
Tested-by: Jenkins Server <pfd-jenkins+hostboot@us.ibm.com>
Tested-by: Jenkins OP Build CI <op-jenkins+hostboot@us.ibm.com>
Tested-by: FSP CI Jenkins <fsp-CI-jenkins+hostboot@us.ibm.com>
Tested-by: Jenkins OP HW <op-hw-jenkins+hostboot@us.ibm.com>
Reviewed-by: Nicholas E Bofferding <bofferdn@us.ibm.com>
Reviewed-by: Michael Baiocchi <mbaiocch@us.ibm.com>
Reviewed-by: Daniel M Crowell <dcrowell@us.ibm.com>

1 files changed, 31 insertions, 1 deletions

diff --git a/src/usr/isteps/istep07/call_mss_attr_update.C b/src/usr/isteps/istep07/call_mss_attr_update.C
index 4e015d7b8..3c1893273 100644
--- a/src/usr/isteps/istep07/call_mss_attr_update.C
+++ b/src/usr/isteps/istep07/call_mss_attr_update.C
@@ -5,7 +5,7 @@
 /*                                                                        */
 /* OpenPOWER HostBoot Project                                             */
 /*                                                                        */
-/* Contributors Listed Below - COPYRIGHT 2015,2018                        */
+/* Contributors Listed Below - COPYRIGHT 2015,2019                        */
 /* [+] International Business Machines Corp.                              */
 /*                                                                        */
 /*                                                                        */
@@ -72,6 +72,9 @@
 
 #include <isteps/mem_utils.H>
 
+#include <secureboot/smf_utils.H>
+#include <initservice/mboxRegs.H>
+
 namespace   ISTEP_07
 {
 
@@ -307,6 +310,33 @@ errlHndl_t check_proc0_memory_config(IStepError & io_istepErr)
               (l_procIds[i].proc)->getAttr<ATTR_FABRIC_CHIP_ID>());
     }
 
+    TARGETING::Target* l_sys = nullptr;
+    TARGETING::targetService().getTopLevelTarget(l_sys);
+    assert(l_sys != nullptr, "Top level target is nullptr!");
+
+    TARGETING::ATTR_MASTER_MBOX_SCRATCH_type l_scratchRegs;
+    assert(
+          l_sys->tryGetAttr<TARGETING::ATTR_MASTER_MBOX_SCRATCH>(l_scratchRegs),
+          "failed to get MASTER_MBOX_SCRATCH");
+    INITSERVICE::SPLESS::MboxScratch6_t l_scratch6 {
+        l_scratchRegs[INITSERVICE::SPLESS::SCRATCH_6]};
+
+    // If the smfConfig bit in scratch reg6 does not match the SMF_ENABLED
+    // setting on the system, then the SBE is in disagreement with the system on
+    // whether SMF mode should be enabled. We need to force SBE update here so
+    // that the XSCOM BAR on the slave proc is set correctly before
+    // we try to perform XSCOM operations in istep10.
+    if(l_scratch6.smfConfig != SECUREBOOT::SMF::isSmfEnabled())
+    {
+        TRACFCOMP(ISTEPS_TRACE::g_trac_isteps_trace,
+                  "SBE and SYS disagree on the SMF setting; SBE thinks it "
+                  "should be %s, but it should actually be %s;"
+                  "requesting SBE update.",
+                  l_scratch6.smfConfig ? "enabled" : "disabled",
+                  SECUREBOOT::SMF::isSmfEnabled() ? "enabled" : "disabled");
+        l_updateNeeded = true;
+    }
+
     if(l_updateNeeded)
     {
         do