talos-hostboot/src/usr/fapi2, branch 07-25-2019

Automatically include config.h

2019-12-06T16:28:47+00:00

Rather than having to remember to include config.h anywhere we reference a CONFIG variable (and usually forgetting), this adds it to the default compiler flags so that it gets included in every source file we build. Change-Id: I53622ab4d46c55d942e98cae6ec03049fd5b3d08 Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/87475 Tested-by: Jenkins Server Tested-by: Jenkins OP Build CI Tested-by: Jenkins OP HW Tested-by: FSP CI Jenkins Reviewed-by: Zachary Clark Reviewed-by: Roland Veloz Reviewed-by: Christian R Geddes Reviewed-by: Nicholas E Bofferding

Fix fapi spd testcases

2019-11-06T20:38:53+00:00

Fixed a few places where the Axone path was getting skipped incorrectly, then fixed the resulting latent errors. Change-Id: I917b9a0b6f4ff1491ff384dc924e29f688548873 Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/85688 Tested-by: Jenkins Server Tested-by: Jenkins OP Build CI Tested-by: Jenkins OP HW Reviewed-by: Zachary Clark Tested-by: FSP CI Jenkins Reviewed-by: Christian R Geddes Reviewed-by: William G Hoffa

Don't consider processor's OMI freq if it is 0 when freq restrictions

2019-10-25T20:31:19+00:00

We have been told that processors must run at the same OMI frequency. During bringup we saw that if the first boot was done with one of the processors guarded out, and that processor was later unguarded. We would fail the check that ensures these frequencies are the same, because the proc that was guarded/unguarded would still be 0 where the other would be set. This change will allow us to ignore processors with unset frequency so we can boot far enough to set it. Later on the rule will be enforced as well on subsequent boots. Change-Id: I23950371f6f65750aacb07b28317ba11a3a4e8ab Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/85832 Reviewed-by: Matt Derksen Reviewed-by: Roland Veloz Tested-by: Jenkins Server Reviewed-by: Nicholas E Bofferding

Dynamically generate ocmb cmd/rsp seq id

2019-10-16T13:28:42+00:00

The current procedure code is using the sequence id portion of the FW message to indicate the type of the command rather than the command number. This makes error handling very difficult because we can't detect which ocmb we are accessing when we detect a failure. Create a function backed ekb attribute to hold the sequence id so that every time we retrieve this attribute, we increment the valuwe on the next get. Change-Id: I93e0e7062d01ddf7ba6a69f89411a5b6bcf01471 RTC: 210371 Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/78767 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

Add OMI bus support to callouts

2019-10-10T13:07:00+00:00

Fill in a few spots where we need to handle OMI busses for proper error processing and display. Change-Id: Ibf236a7f6cb894d1516dbbe49b57e5be7dcceca2 Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/84952 Tested-by: Jenkins Server Tested-by: Jenkins OP Build CI Tested-by: Jenkins OP HW Tested-by: FSP CI Jenkins Reviewed-by: Corey V Swenson Reviewed-by: Matt Derksen Reviewed-by: Christian R Geddes Reviewed-by: William G Hoffa

Add support for DMI-MEMBUF bus failures to fapi

2019-10-07T21:04:12+00:00

I noticed this error message the other day - processEIBusCallouts - Bus between target types not known (0x00000027:0x00000004) The effect of this is that we don't end up with the bus error procedure getting added to the error log like it should be. Change-Id: Iecc5f6df2f9c6812d70c5ea66ad0f46dc9bb2694 Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/83671 Reviewed-by: Christian R Geddes Reviewed-by: Corey V Swenson 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

errl: Fix data reading from unaligned pointers

2019-10-03T17:32:06+00:00

Some architectures (like an ARM used in OpenBMC) do not support unaligned memory access. On these systems, reading an integral value from an unaligned pointer leads to undefined behavior. This patch doesn't change existing functionality, but forces the compiler to generate extra instructions to satisfy architectural alignment requirements. Resolves #185 Signed-off-by: Artem Senichev Change-Id: I6e75044b93c26cca76336d17bb3886fab403253a Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/84520 Reviewed-by: Matt Derksen Reviewed-by: Christian R Geddes 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

Fix ThreadPool Memory Corruption

2019-10-02T14:24:15+00:00

One of the functions that ends up being called by threads spun by ThreadPool has a potential memory corruption where a vector of data structures can be searched while it's being populated by two different threads. This commit changes the positions of mutex lock and ulock calls in the vicinity to protect the population and search of the vector. Change-Id: Ic1a5eb8928c1133ee2a99e2d9c04607be3c41b15 CQ: SW476649 Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/84561 Tested-by: Jenkins Server Tested-by: Jenkins OP Build CI Tested-by: Jenkins OP HW Tested-by: FSP CI Jenkins Reviewed-by: Christian R Geddes Reviewed-by: Nicholas E Bofferding Reviewed-by: Daniel M Crowell

Hostboot platform support for Explorer inband commands via i2c

2019-09-30T20:35:10+00:00

Inband SRAM can be accessed via scom i2c commands. To Explorer, a register address and an internal memory address are the same thing. That allows us to execute the inband command set even if the OMI link is not active. A new attribute determinds when this inband i2c is required so it can be an easy override for lab use. By default, this i2c path will not execute when OMI links are working. Change-Id: I3f18cf78d2e88e33935f1bd241ef4e2796d36d93 RTC: 208447 Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/83787 Tested-by: Jenkins Server Reviewed-by: Christian R Geddes Tested-by: Jenkins OP Build CI Tested-by: Jenkins OP HW Tested-by: FSP CI Jenkins Reviewed-by: Daniel M Crowell Reviewed-by: William G Hoffa

Skip hardware delays when running in Simics

2019-09-30T18:55:35+00:00

There are sometimes delays in HWPs due to hardware delays that need to be accounted for. When we're running in Simics there is no reason to wait because the hardware works instantly (in non- modeled time). Removing these extra delays can have a huge benefit on the total runtime because there is a multiplicative penalty between real time and simulated time. Change-Id: I4f581ad2c028f250ed3fea00cc924e028f3d22d3 Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/84439 Reviewed-by: Christian R Geddes Tested-by: Jenkins Server Tested-by: Jenkins OP Build CI Tested-by: FSP CI Jenkins Tested-by: Jenkins OP HW Reviewed-by: William G Hoffa