summaryrefslogtreecommitdiffstats
path: root/skiboot.lds.S
diff options
context:
space:
mode:
authorMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>2017-12-08 16:19:42 +0530
committerStewart Smith <stewart@linux.vnet.ibm.com>2017-12-11 19:30:46 -0600
commit10f0a09239ddfd4faf47d792f04d3124fb347f88 (patch)
treebbf6652baf6b769dc33498810c7c2f60e8537c1d /skiboot.lds.S
parent363f328fbc597a5996fc3b28e509c09f2869888f (diff)
downloadtalos-skiboot-10f0a09239ddfd4faf47d792f04d3124fb347f88.tar.gz
talos-skiboot-10f0a09239ddfd4faf47d792f04d3124fb347f88.zip
opal/xscom: Add recovery for lost core wakeup scom failures.
Due to a hardware issue where core responding to scom was delayed due to thread reconfiguration, leaves the SCOM logic in a state where the subsequent scom to that core can get errors. This is affected for Core PC scom registers in the range of 20010A80-20010ABF The solution is if a xscom timeout occurs to one of Core PC scom registers in the range of 20010A80-20010ABF, a clearing scom write is done to 0x20010800 with data of '0x00000000' which will also get a timeout but clears the scom logic errors. After the clearing write is done the original scom operation can be retried. The scom timeout is reported as status 0x4 (Invalid address) in HMER[21-23]. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Diffstat (limited to 'skiboot.lds.S')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud