<html><body><p><font size="2">Anton,</font><br><font size="2">you have it licensed as GPL. Tom will not be able to use your code as the base code for OpenBMC is Apache licensed. </font><br><font size="2"><br>Chris Austen<br>POWER Systems Enablement Manager <br></font><br><br><tt><font size="2">"openbmc" <openbmc-bounces+austenc=us.ibm.com@lists.ozlabs.org> wrote on 04/17/2017 04:31:52 AM:<br><br>> From: "Anton D. Kachalov" <mouse@yandex-team.ru></font></tt><br><tt><font size="2">> To: tomjose <tomjose@linux.vnet.ibm.com>, Peter Hanson <br>> <peterh@google.com>, OpenBMC Maillist <openbmc@lists.ozlabs.org></font></tt><br><tt><font size="2">> Date: 04/17/2017 04:41 AM</font></tt><br><tt><font size="2">> Subject: Re: Plans for BMC i2c to host bridge via IPMI</font></tt><br><tt><font size="2">> Sent by: "openbmc" <openbmc-bounces+austenc=us.ibm.com@lists.ozlabs.org></font></tt><br><tt><font size="2">> <br>> Hello,</font></tt><br><tt><font size="2">> </font></tt><br><tt><font size="2">> I'm already works on this approach:</font></tt><br><tt><font size="2">> </font></tt><br><tt><font size="2">> <a href="https://github.com/ya-mouse/meta-openbmc-yandex/blob/master/meta-">https://github.com/ya-mouse/meta-openbmc-yandex/blob/master/meta-</a><br>> yandex/meta-openrack/meta-shaosi/recipes-kernel/linux/linux-obmc/ipmi_i2c.c</font></tt><br><tt><font size="2">> </font></tt><br><tt><font size="2">> This creates a OpenIPMI-compatible device for the requested i2c <br>> slave addr + master (you may use ipmitool/freeipmi after all). DTS example:</font></tt><br><tt><font size="2">> </font></tt><br><tt><font size="2">> <a href="https://github.com/ya-mouse/meta-openbmc-yandex/blob/master/meta-">https://github.com/ya-mouse/meta-openbmc-yandex/blob/master/meta-</a><br>> yandex/meta-openrack/meta-shaosi/recipes-kernel/linux/linux-obmc/<br>> overlays/shaosi-CB.dts#L121-L125</font></tt><br><tt><font size="2">> </font></tt><br><tt><font size="2">> In order to operate in multi-master env, you also need additional <br>> patche such as:</font></tt><br><tt><font size="2">> <a href="https://github.com/ya-mouse/meta-openbmc-yandex/blob/master/meta-">https://github.com/ya-mouse/meta-openbmc-yandex/blob/master/meta-</a><br>> yandex/meta-openrack/meta-shaosi/recipes-kernel/linux/linux-obmc/<br>> 086-ipmi-hacks.patch</font></tt><br><tt><font size="2">> </font></tt><br><tt><font size="2">> This driver still has some issues + not supported incoming requests <br>> (it only operates like a "client").</font></tt><br><tt><font size="2">> </font></tt><br><tt><font size="2">> 12.04.2017, 22:51, "tomjose" <tomjose@linux.vnet.ibm.com>:</font></tt><br><tt><font size="2">> Hello Peter,<br>> <br>> As i understand you would be leveraging the BT(Block Transfer) interface<br>> to route commands from host to BMC.<br>> <br>> From the IPMI specification it looks like this can be a generic one<br>> implementation instead of implementing<br>> OEM commands.<br>> <br>> Implementing the IPMB interface (Section 7) in the IPMI specification<br>> would probably suit your requirement.<br>> The following commands should help us achieve the goal: Master<br>> Write-Read command, Get Message command<br>> and Send message command.<br>> <br>> I am thinking that IPMB interface could be a dbus service which parses<br>> host IPMI commands and maps to an I2C read/write.<br>> <br>> Let me know your thoughts.<br>> <br>> Regards,<br>> Tom<br>> <br>> <br>> On Thursday 06 April 2017 07:10 AM, Peter Hanson wrote:</font></tt><br><tt><font size="2">> Ave!<br>> <br>> This email captures proposed actions from an exchange earlier today on<br>> the #openbmc IRC channel.<br>> <br>> Basic goal is to reach devices on a BMC I2C bus from IPMI <br>> commandline at host.<br>> <br>> I2C commands and responses to be carried as OEM extension messages,<br>> i.e., Network Function Codes 2Eh / 2Fh in the Intel specification.<br>> Those message forms require a three byte IANA Enterprise Number, and<br>> our original plan used Google's code.<br>> <br>> We would like to carry the feature in OpenBmc, so I wanted to confirm<br>> if this is acceptable, and/or what modifications would be needed.<br>> <br>> Decisions:<br>> <br>> 1. Ok to use OEM extensions. Patrick noted that OpenBmc already uses<br>> some, albeit under the IBM IANA Enterprise Number.<br>> <br>> 2. Switch to OpenBmc IANA Enterprise Number when available.<br>> <br>> 3. Patrick proposed to create a new phosphor-ipmi-oemproviders repo to<br>> hold the code, message documentation, etc.<br>> <br>> 4. All uses of the OpenBmc IANA shall be enumerated in place - almost<br>> certainly an include file in the new repo - so we don't end up with<br>> conflicting uses.<br>> <br>> Actions:<br>> <br>> A1. peterh: send this email to the mailing list.<br>> A2. stwcx: request IANA Enterprise Number.<br>> A3. stwcx: create new phosphor-ipmi-oemproviders repo.<br>> A4. peterh+brendanhiggins: propose detailed message designs.<br>> A5. peterh: {net-ipmid,host-ipmi} += support for these commands.<br>> <br>> A key point of this email is to reap your collective wisdom, so please<br>> if you have something to contribute, please do. In particular,<br>> Patrick, please correct anything I misunderstood or incorrectly<br>> extrapolated from the chat.<br>> <br>> -- peterh<br>> </font></tt><br><tt><font size="2">> </font></tt><br><tt><font size="2">> </font></tt><br><tt><font size="2">> </font></tt><br><tt><font size="2">> -- <br>> Anton D. Kachalov<br>> <br>> ITO, Systems Architect<br>> Tel: 7 (495) 739-70-00 ext.7613</font></tt><br><tt><font size="2">> </font></tt><BR>
</body></html>