* Plans for BMC i2c to host bridge via IPMI @ 2017-04-06 1:40 Peter Hanson 2017-04-12 19:51 ` tomjose 0 siblings, 1 reply; 7+ messages in thread From: Peter Hanson @ 2017-04-06 1:40 UTC (permalink / raw) To: OpenBMC, gBMC Ave! This email captures proposed actions from an exchange earlier today on the #openbmc IRC channel. Basic goal is to reach devices on a BMC I2C bus from IPMI commandline at host. I2C commands and responses to be carried as OEM extension messages, i.e., Network Function Codes 2Eh / 2Fh in the Intel specification. Those message forms require a three byte IANA Enterprise Number, and our original plan used Google's code. We would like to carry the feature in OpenBmc, so I wanted to confirm if this is acceptable, and/or what modifications would be needed. Decisions: 1. Ok to use OEM extensions. Patrick noted that OpenBmc already uses some, albeit under the IBM IANA Enterprise Number. 2. Switch to OpenBmc IANA Enterprise Number when available. 3. Patrick proposed to create a new phosphor-ipmi-oemproviders repo to hold the code, message documentation, etc. 4. All uses of the OpenBmc IANA shall be enumerated in place - almost certainly an include file in the new repo - so we don't end up with conflicting uses. Actions: A1. peterh: send this email to the mailing list. A2. stwcx: request IANA Enterprise Number. A3. stwcx: create new phosphor-ipmi-oemproviders repo. A4. peterh+brendanhiggins: propose detailed message designs. A5. peterh: {net-ipmid,host-ipmi} += support for these commands. A key point of this email is to reap your collective wisdom, so please if you have something to contribute, please do. In particular, Patrick, please correct anything I misunderstood or incorrectly extrapolated from the chat. -- peterh ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Plans for BMC i2c to host bridge via IPMI 2017-04-06 1:40 Plans for BMC i2c to host bridge via IPMI Peter Hanson @ 2017-04-12 19:51 ` tomjose 2017-04-13 0:54 ` Peter Hanson 2017-04-17 9:31 ` Anton D. Kachalov 0 siblings, 2 replies; 7+ messages in thread From: tomjose @ 2017-04-12 19:51 UTC (permalink / raw) To: Peter Hanson, OpenBMC Maillist Hello Peter, As i understand you would be leveraging the BT(Block Transfer) interface to route commands from host to BMC. From the IPMI specification it looks like this can be a generic one implementation instead of implementing OEM commands. Implementing the IPMB interface (Section 7) in the IPMI specification would probably suit your requirement. The following commands should help us achieve the goal: Master Write-Read command, Get Message command and Send message command. I am thinking that IPMB interface could be a dbus service which parses host IPMI commands and maps to an I2C read/write. Let me know your thoughts. Regards, Tom On Thursday 06 April 2017 07:10 AM, Peter Hanson wrote: > Ave! > > This email captures proposed actions from an exchange earlier today on > the #openbmc IRC channel. > > Basic goal is to reach devices on a BMC I2C bus from IPMI commandline at host. > > I2C commands and responses to be carried as OEM extension messages, > i.e., Network Function Codes 2Eh / 2Fh in the Intel specification. > Those message forms require a three byte IANA Enterprise Number, and > our original plan used Google's code. > > We would like to carry the feature in OpenBmc, so I wanted to confirm > if this is acceptable, and/or what modifications would be needed. > > Decisions: > > 1. Ok to use OEM extensions. Patrick noted that OpenBmc already uses > some, albeit under the IBM IANA Enterprise Number. > > 2. Switch to OpenBmc IANA Enterprise Number when available. > > 3. Patrick proposed to create a new phosphor-ipmi-oemproviders repo to > hold the code, message documentation, etc. > > 4. All uses of the OpenBmc IANA shall be enumerated in place - almost > certainly an include file in the new repo - so we don't end up with > conflicting uses. > > Actions: > > A1. peterh: send this email to the mailing list. > A2. stwcx: request IANA Enterprise Number. > A3. stwcx: create new phosphor-ipmi-oemproviders repo. > A4. peterh+brendanhiggins: propose detailed message designs. > A5. peterh: {net-ipmid,host-ipmi} += support for these commands. > > A key point of this email is to reap your collective wisdom, so please > if you have something to contribute, please do. In particular, > Patrick, please correct anything I misunderstood or incorrectly > extrapolated from the chat. > > -- peterh > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Plans for BMC i2c to host bridge via IPMI 2017-04-12 19:51 ` tomjose @ 2017-04-13 0:54 ` Peter Hanson 2017-04-17 9:31 ` Anton D. Kachalov 1 sibling, 0 replies; 7+ messages in thread From: Peter Hanson @ 2017-04-13 0:54 UTC (permalink / raw) To: tomjose; +Cc: OpenBMC Maillist On Wed, Apr 12, 2017 at 12:51 PM, tomjose <tomjose@linux.vnet.ibm.com> wrote: > Hello Peter, > > As i understand you would be leveraging the BT(Block Transfer) interface to > route commands from host to BMC. > > From the IPMI specification it looks like this can be a generic one > implementation instead of implementing > OEM commands. > > Implementing the IPMB interface (Section 7) in the IPMI specification would > probably suit your requirement. > The following commands should help us achieve the goal: Master Write-Read > command, Get Message command > and Send message command. > > I am thinking that IPMB interface could be a dbus service which parses host > IPMI commands and maps to an I2C read/write. Choosing the best interface is a very important early step, so I very much appreciate specific suggestions in that area - like this - and will be as specific as possible in my response, so that I can promptly correct holes in my thinking. So here goes: 1. IPMB plumbing alone is significantly heavier than this feature. The resulting Send Message and Get Message API seems awkward for our simple case. Someone with actual IPMB use cases should drive that work. 2. The key message the host would want to send - Master Write-Read Command - does not address the full problem at a modern BMC. My reading of Table 22- in section 22.11 puts the maximum number of private SMBuses at 8. We have 9 i2c _controllers_ on a typical system; some are further connected to multiplexers, further multiplying the number of logical buses. Our proposed OEM master write-read feature addresses both concerns. > Let me know your thoughts. > > Regards, > Tom ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Plans for BMC i2c to host bridge via IPMI 2017-04-12 19:51 ` tomjose 2017-04-13 0:54 ` Peter Hanson @ 2017-04-17 9:31 ` Anton D. Kachalov 2017-04-18 19:17 ` Chris Austen 1 sibling, 1 reply; 7+ messages in thread From: Anton D. Kachalov @ 2017-04-17 9:31 UTC (permalink / raw) To: tomjose, Peter Hanson, OpenBMC Maillist [-- Attachment #1: Type: text/html, Size: 4453 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Plans for BMC i2c to host bridge via IPMI 2017-04-17 9:31 ` Anton D. Kachalov @ 2017-04-18 19:17 ` Chris Austen 2017-04-19 10:58 ` Anton D. Kachalov 0 siblings, 1 reply; 7+ messages in thread From: Chris Austen @ 2017-04-18 19:17 UTC (permalink / raw) To: Anton D. Kachalov; +Cc: tomjose, Peter Hanson, OpenBMC Maillist [-- Attachment #1: Type: text/plain, Size: 4172 bytes --] Anton, you have it licensed as GPL. Tom will not be able to use your code as the base code for OpenBMC is Apache licensed. Chris Austen POWER Systems Enablement Manager "openbmc" <openbmc-bounces+austenc=us.ibm.com@lists.ozlabs.org> wrote on 04/17/2017 04:31:52 AM: > From: "Anton D. Kachalov" <mouse@yandex-team.ru> > To: tomjose <tomjose@linux.vnet.ibm.com>, Peter Hanson > <peterh@google.com>, OpenBMC Maillist <openbmc@lists.ozlabs.org> > Date: 04/17/2017 04:41 AM > Subject: Re: Plans for BMC i2c to host bridge via IPMI > Sent by: "openbmc" <openbmc-bounces+austenc=us.ibm.com@lists.ozlabs.org> > > Hello, > > I'm already works on this approach: > > https://github.com/ya-mouse/meta-openbmc-yandex/blob/master/meta- > yandex/meta-openrack/meta-shaosi/recipes-kernel/linux/linux-obmc/ipmi_i2c.c > > This creates a OpenIPMI-compatible device for the requested i2c > slave addr + master (you may use ipmitool/freeipmi after all). DTS example: > > https://github.com/ya-mouse/meta-openbmc-yandex/blob/master/meta- > yandex/meta-openrack/meta-shaosi/recipes-kernel/linux/linux-obmc/ > overlays/shaosi-CB.dts#L121-L125 > > In order to operate in multi-master env, you also need additional > patche such as: > https://github.com/ya-mouse/meta-openbmc-yandex/blob/master/meta- > yandex/meta-openrack/meta-shaosi/recipes-kernel/linux/linux-obmc/ > 086-ipmi-hacks.patch > > This driver still has some issues + not supported incoming requests > (it only operates like a "client"). > > 12.04.2017, 22:51, "tomjose" <tomjose@linux.vnet.ibm.com>: > Hello Peter, > > As i understand you would be leveraging the BT(Block Transfer) interface > to route commands from host to BMC. > > From the IPMI specification it looks like this can be a generic one > implementation instead of implementing > OEM commands. > > Implementing the IPMB interface (Section 7) in the IPMI specification > would probably suit your requirement. > The following commands should help us achieve the goal: Master > Write-Read command, Get Message command > and Send message command. > > I am thinking that IPMB interface could be a dbus service which parses > host IPMI commands and maps to an I2C read/write. > > Let me know your thoughts. > > Regards, > Tom > > > On Thursday 06 April 2017 07:10 AM, Peter Hanson wrote: > Ave! > > This email captures proposed actions from an exchange earlier today on > the #openbmc IRC channel. > > Basic goal is to reach devices on a BMC I2C bus from IPMI > commandline at host. > > I2C commands and responses to be carried as OEM extension messages, > i.e., Network Function Codes 2Eh / 2Fh in the Intel specification. > Those message forms require a three byte IANA Enterprise Number, and > our original plan used Google's code. > > We would like to carry the feature in OpenBmc, so I wanted to confirm > if this is acceptable, and/or what modifications would be needed. > > Decisions: > > 1. Ok to use OEM extensions. Patrick noted that OpenBmc already uses > some, albeit under the IBM IANA Enterprise Number. > > 2. Switch to OpenBmc IANA Enterprise Number when available. > > 3. Patrick proposed to create a new phosphor-ipmi-oemproviders repo to > hold the code, message documentation, etc. > > 4. All uses of the OpenBmc IANA shall be enumerated in place - almost > certainly an include file in the new repo - so we don't end up with > conflicting uses. > > Actions: > > A1. peterh: send this email to the mailing list. > A2. stwcx: request IANA Enterprise Number. > A3. stwcx: create new phosphor-ipmi-oemproviders repo. > A4. peterh+brendanhiggins: propose detailed message designs. > A5. peterh: {net-ipmid,host-ipmi} += support for these commands. > > A key point of this email is to reap your collective wisdom, so please > if you have something to contribute, please do. In particular, > Patrick, please correct anything I misunderstood or incorrectly > extrapolated from the chat. > > -- peterh > > > > > -- > Anton D. Kachalov > > ITO, Systems Architect > Tel: 7 (495) 739-70-00 ext.7613 > [-- Attachment #2: Type: text/html, Size: 6089 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Plans for BMC i2c to host bridge via IPMI 2017-04-18 19:17 ` Chris Austen @ 2017-04-19 10:58 ` Anton D. Kachalov 2017-04-19 19:32 ` Peter Hanson 0 siblings, 1 reply; 7+ messages in thread From: Anton D. Kachalov @ 2017-04-19 10:58 UTC (permalink / raw) To: Chris Austen; +Cc: tomjose, Peter Hanson, OpenBMC Maillist [-- Attachment #1: Type: text/html, Size: 6803 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Plans for BMC i2c to host bridge via IPMI 2017-04-19 10:58 ` Anton D. Kachalov @ 2017-04-19 19:32 ` Peter Hanson 0 siblings, 0 replies; 7+ messages in thread From: Peter Hanson @ 2017-04-19 19:32 UTC (permalink / raw) To: Anton D. Kachalov; +Cc: Chris Austen, tomjose, OpenBMC Maillist Anton, Thank you for the interesting contributions. As noted earlier, the Master send-receive message is inadequate to describe the private bus array in a modern Bmc. And has other senseless limitations. But using another message seems like a small difference. So I have been studying your design for its key ideas. I have some basic high-level questions and/or guesses. A higher level entity sends messages to one `adapter', which then sends them to i2c. More-or-less separately, a slave adapter receives replies and converts them back to messages to that entity. I now think ipmid can act as that entity. If so, it would be useful to understand completely how that works. I see what looks like usable slave I2C adapter code. Is it for multimaster I2C bus? Or do infernal messaging flows also use it? Thanks again, -- peterh ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-04-19 19:32 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-04-06 1:40 Plans for BMC i2c to host bridge via IPMI Peter Hanson 2017-04-12 19:51 ` tomjose 2017-04-13 0:54 ` Peter Hanson 2017-04-17 9:31 ` Anton D. Kachalov 2017-04-18 19:17 ` Chris Austen 2017-04-19 10:58 ` Anton D. Kachalov 2017-04-19 19:32 ` Peter Hanson
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.