| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <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: Zachary Clark <zach@ibm.com>
Reviewed-by: Roland Veloz <rveloz@us.ibm.com>
Reviewed-by: Christian R Geddes <crgeddes@us.ibm.com>
Reviewed-by: Nicholas E Bofferding <bofferdn@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some of the unit tests we must load in .so modules that were
unloaded during the boot. Modules must get loaded and unloaded during
the boot, especially before we expand from cache containment to over
come size limitations. We were seeing issues were test case A and
B both relied on a module and attempted to load it when the test
case was instantiated then tried to unload the module when the test
case was completed. This was causing issues if two tests were using
the same loaded module and one test finished early and unloaded it.
Test cases are run on simics after memory is expanded so there is
no reason unload the extra modules we load in so we will leave them
loaded.
Change-Id: Ia41d38da11400f54ee2e59e497b9610ac24f1629
Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/82099
Reviewed-by: Matt Derksen <mderkse1@us.ibm.com>
Reviewed-by: Glenn Miles <milesg@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: Daniel M Crowell <dcrowell@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use IB_RSP_ADDR memory spot to run some valid
mmio operations. Also make sure a user's
invalid input does not switch the scom
switch to i2c operations.
Change-Id: I68da42b2fc817f7bf4b99bb9c53cdf862136c7aa
RTC:201738
Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/79195
Tested-by: Jenkins Server <pfd-jenkins+hostboot@us.ibm.com>
Reviewed-by: Christian R. Geddes <crgeddes@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: Roland Veloz <rveloz@us.ibm.com>
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Disabling a few testcases temporarily until Axone gets off
the ground.
Cleaned up some bad traces, etc in existing code.
Add CI support for AXONE config
Change-Id: I7a2140366e225971c91a50cec1f7e822e4847078
Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/72186
Tested-by: Jenkins Server <pfd-jenkins+hostboot@us.ibm.com>
Reviewed-by: Matt Derksen <mderkse1@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>
Tested-by: Jenkins OP HW <op-hw-jenkins+hostboot@us.ibm.com>
Reviewed-by: Christian R. Geddes <crgeddes@us.ibm.com>
|
|
There will be a new set of interfaces in fapi2 to perform mmio
(aka inband) operations directly. This is needed for OCMB access
in the memory HWPs, specifically as part of the command/response
protocol.
Change-Id: If473e8e53fa6f76a05ad897e150b58075c769902
RTC:191344
Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/66045
Reviewed-by: Richard Ward <rward15@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: FSP CI Jenkins <fsp-CI-jenkins+hostboot@us.ibm.com>
Tested-by: Jenkins OP HW <op-hw-jenkins+hostboot@us.ibm.com>
Reviewed-by: Christian R. Geddes <crgeddes@us.ibm.com>
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
|