<div>Hello, Chris.</div><div> </div><div>It's not clear. I developed a kernel driver. It have to be licensed under the GPL.</div><div> </div><div>18.04.2017, 22:17, "Chris Austen" <austenc@us.ibm.com>:</div><blockquote type="cite"><div><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 /><br /><font size="2">Chris Austen<br />POWER Systems Enablement Manager </font><br /><br /><br /><font size="2">"openbmc" <<a href="mailto:openbmc-bounces+austenc=us.ibm.com@lists.ozlabs.org">openbmc-bounces+austenc=us.ibm.com@lists.ozlabs.org</a>> wrote on 04/17/2017 04:31:52 AM:<br /><br />> From: "Anton D. Kachalov" <<a href="mailto:mouse@yandex-team.ru">mouse@yandex-team.ru</a>></font><br /><font size="2">> To: tomjose <<a href="mailto:tomjose@linux.vnet.ibm.com">tomjose@linux.vnet.ibm.com</a>>, Peter Hanson<br />> <<a href="mailto:peterh@google.com">peterh@google.com</a>>, OpenBMC Maillist <<a href="mailto:openbmc@lists.ozlabs.org">openbmc@lists.ozlabs.org</a>></font><br /><font size="2">> Date: 04/17/2017 04:41 AM</font><br /><font size="2">> Subject: Re: Plans for BMC i2c to host bridge via IPMI</font><br /><font size="2">> Sent by: "openbmc" <<a href="mailto:openbmc-bounces+austenc=us.ibm.com@lists.ozlabs.org">openbmc-bounces+austenc=us.ibm.com@lists.ozlabs.org</a>></font><br /><font size="2">><br />> Hello,</font><br /><font size="2">>  </font><br /><font size="2">> I'm already works on this approach:</font><br /><font size="2">>  </font><br /><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><br /><font size="2">>  </font><br /><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><br /><font size="2">>  </font><br /><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><br /><font size="2">>  </font><br /><font size="2">> In order to operate in multi-master env, you also need additional<br />> patche such as:</font><br /><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><br /><font size="2">>  </font><br /><font size="2">> This driver still has some issues + not supported incoming requests<br />> (it only operates like a "client").</font><br /><font size="2">>  </font><br /><font size="2">> 12.04.2017, 22:51, "tomjose" <<a href="mailto:tomjose@linux.vnet.ibm.com">tomjose@linux.vnet.ibm.com</a>>:</font><br /><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><br /><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><br /><font size="2">>  </font><br /><font size="2">>  </font><br /><font size="2">>  </font><br /><font size="2">> -- <br />> Anton D. Kachalov<br />><br />> ITO, Systems Architect<br />> Tel: 7 (495) <span>739-70-00</span> ext.7613</font><br /><font size="2">>  </font></p></div></blockquote><div> </div><div> </div><div>-- <br />Anton D. Kachalov<br /><br />ITO, Systems Architect<br />Tel: 7 (495) 739-70-00 ext.7613</div><div> </div>