<div>Hello,</div><div> </div><div>I'm already works on this approach:</div><div> </div><div><a href="https://github.com/ya-mouse/meta-openbmc-yandex/blob/master/meta-yandex/meta-openrack/meta-shaosi/recipes-kernel/linux/linux-obmc/ipmi_i2c.c">https://github.com/ya-mouse/meta-openbmc-yandex/blob/master/meta-yandex/meta-openrack/meta-shaosi/recipes-kernel/linux/linux-obmc/ipmi_i2c.c</a></div><div> </div><div>This creates a OpenIPMI-compatible device for the requested i2c slave addr + master (you may use ipmitool/freeipmi after all). DTS example:</div><div> </div><div><a href="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">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</a></div><div> </div><div>In order to operate in multi-master env, you also need additional patche such as:</div><div><a href="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">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</a></div><div> </div><div>This driver still has some issues + not supported incoming requests (it only operates like a "client").</div><div> </div><div>12.04.2017, 22:51, "tomjose" <tomjose@linux.vnet.ibm.com>:</div><blockquote type="cite"><p>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:</p><blockquote> 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 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 /> </blockquote><p> </p></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>