<feed xmlns='http://www.w3.org/2005/Atom'>
<title>talos-hostboot/src/include/usr/ipmi, branch 07-25-2019</title>
<subtitle>Talos™ II hostboot sources</subtitle>
<id>https://git.raptorcs.com/git/talos-hostboot/atom?h=07-25-2019</id>
<link rel='self' href='https://git.raptorcs.com/git/talos-hostboot/atom?h=07-25-2019'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-hostboot/'/>
<updated>2019-07-23T18:54:41+00:00</updated>
<entry>
<title>ipmidcmi: Get DCMI capabilities info to check PM support</title>
<updated>2019-07-23T18:54:41+00:00</updated>
<author>
<name>Maxim Polyakov</name>
<email>max.senia.poliak@gmail.com</email>
</author>
<published>2019-05-13T13:51:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-hostboot/commit/?id=e8665007c850aea68f494b34705276585ce13086'/>
<id>urn:sha1:e8665007c850aea68f494b34705276585ce13086</id>
<content type='text'>
According to section 6.6 Power management of DCMI spec, the DCMI
Get Power Limit command isn`t supported if Get DCMI Capabilities
Info command indicates no Power Management support.  Commit adds
code to get DCMI capabilities information from BMC to check this
Tested on the Vesnin P8 server

Change-Id: I3c4216e2ee4f5fa98ffbcfa95c4af6771f81b43c
RTC: 123256
Resolves #176
Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/80681
Tested-by: Jenkins Server &lt;pfd-jenkins+hostboot@us.ibm.com&gt;
Tested-by: Jenkins OP Build CI &lt;op-jenkins+hostboot@us.ibm.com&gt;
Tested-by: Jenkins OP HW &lt;op-hw-jenkins+hostboot@us.ibm.com&gt;
Tested-by: FSP CI Jenkins &lt;fsp-CI-jenkins+hostboot@us.ibm.com&gt;
Reviewed-by: Martha Broyles &lt;mbroyles@us.ibm.com&gt;
Reviewed-by: Daniel M Crowell &lt;dcrowell@us.ibm.com&gt;
</content>
</entry>
<entry>
<title>Reduce ipmi trace spam for pnor hiomap messages</title>
<updated>2018-11-27T22:28:17+00:00</updated>
<author>
<name>Dan Crowell</name>
<email>dcrowell@us.ibm.com</email>
</author>
<published>2018-11-09T18:04:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-hostboot/commit/?id=8e5dda92903e105c62f52390b35d3e335d55f532'/>
<id>urn:sha1:8e5dda92903e105c62f52390b35d3e335d55f532</id>
<content type='text'>
With the PNOR accesses now going over IPMI, the IPMI traces are
now completely overwhelmed by those messages.  This change will
skip tracing out the messages if they are the hiomap requests.

Example of trace spam:
  3.34945|IPMI|rp: queuing sync e8:5a
  3.34946|IPMI|rp: W&gt;Got message (0xe8:0x5a): l_is_pnor: 1
  3.34952|IPMI|dd: I&gt;write ok e8:5a seq 26 len 6
  3.35837|IPMI|dd: I&gt;read b2h ok ec:5a seq 26 len 8 cc 0
  3.35947|IPMI|rp: queuing sync e8:5a
  3.35948|IPMI|rp: W&gt;Got message (0xe8:0x5a): l_is_pnor: 1
  3.35953|IPMI|dd: I&gt;write ok e8:5a seq 27 len 6
  3.36837|IPMI|dd: I&gt;read b2h ok ec:5a seq 27 len 8 cc 0
  3.36947|IPMI|rp: queuing sync e8:5a
  3.36948|IPMI|rp: W&gt;Got message (0xe8:0x5a): l_is_pnor: 1
  3.36953|IPMI|dd: I&gt;write ok e8:5a seq 28 len 6
  3.43855|IPMI|dd: I&gt;read b2h ok ec:5a seq 28 len 8 cc 0
  3.43926|IPMI|rp: queuing sync e8:5a
  3.43927|IPMI|rp: W&gt;Got message (0xe8:0x5a): l_is_pnor: 1
  3.43933|IPMI|dd: I&gt;write ok e8:5a seq 29 len 6
  3.50860|IPMI|dd: I&gt;read b2h ok ec:5a seq 29 len 8 cc 0
  3.50902|IPMI|rp: queuing sync e8:5a
  3.50902|IPMI|rp: W&gt;Got message (0xe8:0x5a): l_is_pnor: 1
In a single boot on a system there were close to 4000 of these
traces.

Change-Id: Ia8944ca7f281986ec0bca7328fa56a7c0d521339
Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/68605
Tested-by: Jenkins Server &lt;pfd-jenkins+hostboot@us.ibm.com&gt;
Tested-by: Jenkins OP Build CI &lt;op-jenkins+hostboot@us.ibm.com&gt;
Tested-by: Jenkins OP HW &lt;op-hw-jenkins+hostboot@us.ibm.com&gt;
Tested-by: FSP CI Jenkins &lt;fsp-CI-jenkins+hostboot@us.ibm.com&gt;
Reviewed-by: Christian R. Geddes &lt;crgeddes@us.ibm.com&gt;
Reviewed-by: William G. Hoffa &lt;wghoffa@us.ibm.com&gt;
Reviewed-by: Daniel M. Crowell &lt;dcrowell@us.ibm.com&gt;
</content>
</entry>
<entry>
<title>Enable IPMI errl after targeting is initialized</title>
<updated>2018-11-05T17:51:47+00:00</updated>
<author>
<name>Corey Swenson</name>
<email>cswenson@us.ibm.com</email>
</author>
<published>2018-11-01T15:12:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-hostboot/commit/?id=83335d59ac593a543bcbe8c9c2f030798c02a2dc'/>
<id>urn:sha1:83335d59ac593a543bcbe8c9c2f030798c02a2dc</id>
<content type='text'>
A recent change split IPMI into base and extended.
Move the enable of IPMI errl from base to extended
to avoid targeting errors.

Change-Id: Ia833dd8178ff407dff1fa514b32468c5fc70e945
CQ:SW450286
Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/68265
Tested-by: Jenkins Server &lt;pfd-jenkins+hostboot@us.ibm.com&gt;
Tested-by: Jenkins OP Build CI &lt;op-jenkins+hostboot@us.ibm.com&gt;
Tested-by: Jenkins OP HW &lt;op-hw-jenkins+hostboot@us.ibm.com&gt;
Tested-by: FSP CI Jenkins &lt;fsp-CI-jenkins+hostboot@us.ibm.com&gt;
Reviewed-by: ANDREW R. JEFFERY &lt;andrewrj@au1.ibm.com&gt;
Reviewed-by: Michael Baiocchi &lt;mbaiocch@us.ibm.com&gt;
Reviewed-by: Daniel M. Crowell &lt;dcrowell@us.ibm.com&gt;
</content>
</entry>
<entry>
<title>pnor: Introduce an IPMI-based PNOR driver implementation</title>
<updated>2018-10-10T18:45:29+00:00</updated>
<author>
<name>Andrew Jeffery</name>
<email>andrewrj@au1.ibm.com</email>
</author>
<published>2018-09-17T07:53:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-hostboot/commit/?id=c829113199d6ee1f1788ff336a09b55b98bc3609'/>
<id>urn:sha1:c829113199d6ee1f1788ff336a09b55b98bc3609</id>
<content type='text'>
Similar to the AST MBOX implementation, the IPMI PNOR implementation
negotiates the layout of the LPC FW space with the BMC, but using IPMI
rather than the AST mailbox as a protocol transport. The same protocol
is still used and has simply been adapted to the new interface.

Note that currently the change of transport has had a 2-3x impact on
boot performance. Optimisation is an ongoing effort.

Change-Id: I7f838f5b5e88ac877a725386a33df58ee5e7213c
Signed-off-by: Andrew Jeffery &lt;andrewrj@au1.ibm.com&gt;
Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/65942
Tested-by: Jenkins Server &lt;pfd-jenkins+hostboot@us.ibm.com&gt;
Tested-by: Jenkins OP HW &lt;op-hw-jenkins+hostboot@us.ibm.com&gt;
Tested-by: FSP CI Jenkins &lt;fsp-CI-jenkins+hostboot@us.ibm.com&gt;
Reviewed-by: Daniel M. Crowell &lt;dcrowell@us.ibm.com&gt;
</content>
</entry>
<entry>
<title>ipmi: Terminate SEL task via shutdown event</title>
<updated>2018-10-09T15:07:42+00:00</updated>
<author>
<name>Andrew Jeffery</name>
<email>andrewrj@au1.ibm.com</email>
</author>
<published>2018-10-04T05:33:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-hostboot/commit/?id=d6741cb3db68795586a21fc812806836135341ec'/>
<id>urn:sha1:d6741cb3db68795586a21fc812806836135341ec</id>
<content type='text'>
The IpmiSEL task will become part of the extended image once the IPMI
module is split in two. Once split, if we need to handle an early shutdown
we cannot be referencing code from HBI in HBB. To that end, ensure we
don't instantiate an IpmiSEL via Singleton in an attempt to shutdown its
event loop when it hasn't been loaded, let alone started. Instead, have
IpmiSEL register itself in the shutdown handler, and shut down the SEL
task before IpmiRP.

Change-Id: I358f6cb1f5528a4ad72c93477ad883cad19e2bf6
Signed-off-by: Andrew Jeffery &lt;andrewrj@au1.ibm.com&gt;
Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/67076
Tested-by: Jenkins Server &lt;pfd-jenkins+hostboot@us.ibm.com&gt;
Tested-by: Jenkins OP Build CI &lt;op-jenkins+hostboot@us.ibm.com&gt;
Tested-by: Jenkins OP HW &lt;op-hw-jenkins+hostboot@us.ibm.com&gt;
Tested-by: FSP CI Jenkins &lt;fsp-CI-jenkins+hostboot@us.ibm.com&gt;
Reviewed-by: Corey V. Swenson &lt;cswenson@us.ibm.com&gt;
Reviewed-by: Daniel M. Crowell &lt;dcrowell@us.ibm.com&gt;
</content>
</entry>
<entry>
<title>ipmi: Introduce register_for_event() interface</title>
<updated>2018-10-08T20:29:30+00:00</updated>
<author>
<name>Andrew Jeffery</name>
<email>andrewrj@au1.ibm.com</email>
</author>
<published>2018-09-17T07:53:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-hostboot/commit/?id=988eda165254887e231a61d7031e5baf636c8c85'/>
<id>urn:sha1:988eda165254887e231a61d7031e5baf636c8c85</id>
<content type='text'>
register_for_event() allows the IPMI PNOR implementation to indicate
interest in SELs from the hiomap protocol used for managing the LPC FW
space.

Change-Id: I3bf6cb7f860d41a0c46755e23fd54276ae2258ff
Signed-off-by: Andrew Jeffery &lt;andrewrj@au1.ibm.com&gt;
Reviewed-on: http://rchgit01.rchland.ibm.com/gerrit1/65938
Tested-by: Jenkins Server &lt;pfd-jenkins+hostboot@us.ibm.com&gt;
Tested-by: Jenkins OP Build CI &lt;op-jenkins+hostboot@us.ibm.com&gt;
Tested-by: Jenkins OP HW &lt;op-hw-jenkins+hostboot@us.ibm.com&gt;
Tested-by: FSP CI Jenkins &lt;fsp-CI-jenkins+hostboot@us.ibm.com&gt;
Reviewed-by: Daniel M. Crowell &lt;dcrowell@us.ibm.com&gt;
</content>
</entry>
<entry>
<title>Send errors from previous boots as callhome type eSELs</title>
<updated>2018-07-17T21:18:04+00:00</updated>
<author>
<name>Nick Bofferding</name>
<email>bofferdn@us.ibm.com</email>
</author>
<published>2018-07-09T22:56:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-hostboot/commit/?id=928ef690c0862878a457a965984ab90efaba3a00'/>
<id>urn:sha1:928ef690c0862878a457a965984ab90efaba3a00</id>
<content type='text'>
During early boot, Hostboot attempts to resend unacknowledged error
logs from prior boots as eSELS, without correponding SELs.  BMCs typically
require both in order to expose a given error log to a customer.  This change
morphs errors from prior boots into callhome type logs, so that a simple eSEL
will be enough to get the error propagated.

Change-Id: If499defe8a39b9254f08392b264d72047b7e5f7c
CQ: SW426731
RTC: 193265
Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/62079
Tested-by: Jenkins Server &lt;pfd-jenkins+hostboot@us.ibm.com&gt;
Tested-by: Jenkins OP Build CI &lt;op-jenkins+hostboot@us.ibm.com&gt;
Tested-by: Jenkins OP HW &lt;op-hw-jenkins+hostboot@us.ibm.com&gt;
Tested-by: FSP CI Jenkins &lt;fsp-CI-jenkins+hostboot@us.ibm.com&gt;
Reviewed-by: William G. Hoffa &lt;wghoffa@us.ibm.com&gt;
</content>
</entry>
<entry>
<title>Increase default watchdog timeout to 10 minutes</title>
<updated>2018-05-29T14:33:43+00:00</updated>
<author>
<name>Dan Crowell</name>
<email>dcrowell@us.ibm.com</email>
</author>
<published>2018-05-23T14:54:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-hostboot/commit/?id=4bfa55da9a90424359d3ae5175ddd2863cb75235'/>
<id>urn:sha1:4bfa55da9a90424359d3ae5175ddd2863cb75235</id>
<content type='text'>
We have discovered some error cases within the memory diagnostics
step where a single hardware operation can take up to 6 minutes
to complete.  The code sends a watchdog ping before issuing any
command, but the current timeout (2 minutes) is insufficient to
handle these long commands.

Resolves boston-openpower/#1240

Change-Id: I4e27a45c927c014b5fcc28d4510c5996a7009953
Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/59254
Tested-by: Jenkins Server &lt;pfd-jenkins+hostboot@us.ibm.com&gt;
Tested-by: Jenkins OP Build CI &lt;op-jenkins+hostboot@us.ibm.com&gt;
Tested-by: Jenkins OP HW &lt;op-hw-jenkins+hostboot@us.ibm.com&gt;
Tested-by: FSP CI Jenkins &lt;fsp-CI-jenkins+hostboot@us.ibm.com&gt;
Reviewed-by: William G. Hoffa &lt;wghoffa@us.ibm.com&gt;
Reviewed-by: Daniel M. Crowell &lt;dcrowell@us.ibm.com&gt;
</content>
</entry>
<entry>
<title>Get SN from BMC and update into PVPD EEPROM</title>
<updated>2018-05-19T21:09:16+00:00</updated>
<author>
<name>Meng Li</name>
<email>shlimeng@cn.ibm.com</email>
</author>
<published>2018-04-24T13:21:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-hostboot/commit/?id=fd23ae8d50f307a1aca530d5a204d67261b58fea'/>
<id>urn:sha1:fd23ae8d50f307a1aca530d5a204d67261b58fea</id>
<content type='text'>
Resolves #135

Change-Id: I46b5c2208ed28822c6001a955f4056d976e79339
Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/58010
Tested-by: Jenkins Server &lt;pfd-jenkins+hostboot@us.ibm.com&gt;
Tested-by: Jenkins OP Build CI &lt;op-jenkins+hostboot@us.ibm.com&gt;
Tested-by: Jenkins OP HW &lt;op-hw-jenkins+hostboot@us.ibm.com&gt;
Tested-by: FSP CI Jenkins &lt;fsp-CI-jenkins+hostboot@us.ibm.com&gt;
Reviewed-by: Daniel M. Crowell &lt;dcrowell@us.ibm.com&gt;
</content>
</entry>
<entry>
<title>Enable super-long watchdog timer when console traces are enabled</title>
<updated>2018-05-02T17:53:54+00:00</updated>
<author>
<name>Dan Crowell</name>
<email>dcrowell@us.ibm.com</email>
</author>
<published>2018-04-20T20:05:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-hostboot/commit/?id=2c84fc6ab09e3641957290eb8fbfd5b4ced64213'/>
<id>urn:sha1:2c84fc6ab09e3641957290eb8fbfd5b4ced64213</id>
<content type='text'>
When console traces are enabled, the boot takes significantly
longer than usual.  Our standard watchdog timeout of 2 minutes
is not sufficient.

Made the following changes:
- Tied the enablement of the long timeout to the CONFIG flags for
  console traces
- Increased the timeout to 1 hour (from 40 minutes) since this is
  lab only and false positives are the worst...
- Added a couple clarifying traces to make future watchdog debug
  simpler

Change-Id: I92bb0b07cb77a13cb390450999b285f2ad74168d
CQ: SW425407
Reviewed-on: http://ralgit01.raleigh.ibm.com/gerrit1/57580
Reviewed-by: Martin Gloff &lt;mgloff@us.ibm.com&gt;
Reviewed-by: Richard J. Knight &lt;rjknight@us.ibm.com&gt;
Tested-by: Jenkins Server &lt;pfd-jenkins+hostboot@us.ibm.com&gt;
Tested-by: Jenkins OP Build CI &lt;op-jenkins+hostboot@us.ibm.com&gt;
Tested-by: FSP CI Jenkins &lt;fsp-CI-jenkins+hostboot@us.ibm.com&gt;
Reviewed-by: Christian R. Geddes &lt;crgeddes@us.ibm.com&gt;
Tested-by: Jenkins OP HW &lt;op-hw-jenkins+hostboot@us.ibm.com&gt;
Reviewed-by: William G. Hoffa &lt;wghoffa@us.ibm.com&gt;
</content>
</entry>
</feed>
