"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
>