All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Hanson <peterh@google.com>
To: tomjose <tomjose@linux.vnet.ibm.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: Plans for BMC i2c to host bridge via IPMI
Date: Wed, 12 Apr 2017 17:54:23 -0700	[thread overview]
Message-ID: <CAPozSNrrtUcmsw=wbhwY3dttzbKLJUraS1LPyDnPU4mgzjEs5Q@mail.gmail.com> (raw)
In-Reply-To: <58EE852E.8010005@linux.vnet.ibm.com>

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

  reply	other threads:[~2017-04-13  0:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPozSNrrtUcmsw=wbhwY3dttzbKLJUraS1LPyDnPU4mgzjEs5Q@mail.gmail.com' \
    --to=peterh@google.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=tomjose@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.