summaryrefslogtreecommitdiffstats
path: root/src/include/usr/xscom/xscomif.H
Commit message (Collapse)AuthorAgeFilesLines
* Save HRMOR in mbox scratch reg for IPC messagingPrachi Gupta2018-06-261-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to know where the IPC message of a given node is, we save off the HRMOR of every node in a hw register. Originally, we were saving this information in the core scratch register. Since, the core scratch registers are wiped off when the cores go into the winkle state, therefore, we were writing to the register after we come out of winkle. But, at that point, we ran into race conditions because other nodes could be ahead and try to access the register on a node that is not exactly out of winkle yet. This fixes the problems by using the mbox scratch register rather than the core scratch register because they are saved off even when the cores go into winkle state. Because the registers are preseved, we can set the value prior to cores coming out of winkle, so, we don't run into the race condition where one node is trying to read a value prior to the other one writing the value. Change-Id: I822bfc8defe09cbb418edc5f36a99b7cd41eec88 CQ:SW435271 Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/61093 Tested-by: Jenkins Server <pfd-jenkins+hostboot@us.ibm.com> Tested-by: Jenkins OP Build CI <op-jenkins+hostboot@us.ibm.com> Tested-by: Jenkins OP HW <op-hw-jenkins+hostboot@us.ibm.com> Tested-by: FSP CI Jenkins <fsp-CI-jenkins+hostboot@us.ibm.com> Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
* Fixes to node IPC messaging to handle non-zero base addressesBrian Bakke2018-06-071-1/+10
| | | | | | | | | | | | | | | | | | | | Current code has each Node calculate each Remote Node's IPC area remote address by performing a fixed format calculation. This change has each Node calculating its IPC area Remote address and posting this value to a local SCOM register. A Node reads a Remote Node's SCOM register to acquire the Remote IPC area address. Change-Id: I25260ce180e0d07e5e81990d4c1f99e249912491 RTC:191463 Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/59177 Tested-by: Jenkins Server <pfd-jenkins+hostboot@us.ibm.com> Reviewed-by: William G. Hoffa <wghoffa@us.ibm.com> Tested-by: Jenkins OP Build CI <op-jenkins+hostboot@us.ibm.com> Tested-by: Jenkins OP HW <op-hw-jenkins+hostboot@us.ibm.com> Tested-by: FSP CI Jenkins <fsp-CI-jenkins+hostboot@us.ibm.com> Reviewed-by: Prachi Gupta <pragupta@us.ibm.com> Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
* Force checkstops for unhandled machine checksDan Crowell2018-03-291-1/+10
| | | | | | | | | | | | | | | | | | | Default MSR[ME]=0 during initial boot for bootloader and hostboot kernel Once the xscom address range has been mapped in, enable the machine check handler to force a checkstop and set MSR[ME]=1 to allow regular machine check handling CQ: SW401402 Change-Id: I104e39465e61b3b19d5c073e71271102711ae54f Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/47179 Reviewed-by: Christian R. Geddes <crgeddes@us.ibm.com> Tested-by: Jenkins Server <pfd-jenkins+hostboot@us.ibm.com> Tested-by: Jenkins OP Build CI <op-jenkins+hostboot@us.ibm.com> Tested-by: Jenkins OP HW <op-hw-jenkins+hostboot@us.ibm.com> Tested-by: FSP CI Jenkins <fsp-CI-jenkins+hostboot@us.ibm.com> Reviewed-by: William G. Hoffa <wghoffa@us.ibm.com> Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
* Use XSCOM BAR from Bootloader instead of hardcoded valueDan Crowell2017-06-071-0/+40
The memory map can be modified by the SBE such that the XSCOM BAR is not in the default location. The BAR value is passed up through the bootloader into hostboot. Change-Id: I469b7534d384bce4bb8c72f7cd78d0075ac04632 RTC: 173519 Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/41140 Reviewed-by: Martin Gloff <mgloff@us.ibm.com> Tested-by: Jenkins Server <pfd-jenkins+hostboot@us.ibm.com> Tested-by: FSP CI Jenkins <fsp-CI-jenkins+hostboot@us.ibm.com> Tested-by: Jenkins OP Build CI <op-jenkins+hostboot@us.ibm.com> Reviewed-by: Christian R. Geddes <crgeddes@us.ibm.com> Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
OpenPOWER on IntegriCloud