New repository request for platform specific Bridge IC code

New repository request for platform specific Bridge IC code

[Kumar Thangavel]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

Hi All,

       In our system, Bridge IC will act as a bridge between host and BMC.
All the IPMI commands from the host are routed to Bridge IC and Bridge IC
will forward those commands to BMC.  Similarly, BMC will route IPMI
commands to Bridge IC and it's forward to host.

We wanted to put this platform specific Bridge IC related code and ipmb
commands handling code. So, we need a new repository to add these codes or
suggestions to add these codes in any other existing repository.

Could you please provide your suggestions on this.

Thanks,
Kumar.

[-- Attachment #2: Type: text/html, Size: 699 bytes --]

Re: New repository request for platform specific Bridge IC code

[Ed Tanous]

On Mon, Jan 3, 2022 at 11:55 PM Kumar Thangavel
<kumarthangavel.hcl@gmail.com> wrote:
>
> Hi All,
>
>        In our system, Bridge IC will act as a bridge between host and BMC. All the IPMI commands from the host are routed to Bridge IC and Bridge IC will forward those commands to BMC.  Similarly, BMC will route IPMI commands to Bridge IC and it's forward to host.
>
> We wanted to put this platform specific Bridge IC related code and ipmb commands handling code. So, we need a new repository to add these codes or suggestions to add these codes in any other existing repository.
>
> Could you please provide your suggestions on this.

There aren't a lot of details here, so it's kind of hard to make
concrete suggestions given how short the above description is.  Can
you please put some more details in, background, links, ect  Some
questions off the top of my head:

1. How does this differ from MCU sensor in the dbus-sensors repo,
which also manages a "bridge" IC?  IPMBSensor also implements IPMB,
how will code be reused in this new repository?
2. Who is going to be the maintainer of this repository?  Ideally it
would be someone that has been a maintainer before, or someone that
can mentor in how to be a maintainer.
3. How is this code going to be configured?
4. Where is the design doc for this new feature?  How is it going to
work, what features are going to be exposed?  What new interfaces will
be needed?

>
> Thanks,
> Kumar.

Re: New repository request for platform specific Bridge IC code

[Kumar Thangavel]

[-- Attachment #1: Type: text/plain, Size: 3127 bytes --]

On Wed, Jan 5, 2022 at 1:20 AM Ed Tanous <ed@tanous.net> wrote:

> On Mon, Jan 3, 2022 at 11:55 PM Kumar Thangavel
> <kumarthangavel.hcl@gmail.com> wrote:
> >
> > Hi All,
> >
> >        In our system, Bridge IC will act as a bridge between host and
> BMC. All the IPMI commands from the host are routed to Bridge IC and Bridge
> IC will forward those commands to BMC.  Similarly, BMC will route IPMI
> commands to Bridge IC and it's forward to host.
> >
> > We wanted to put this platform specific Bridge IC related code and ipmb
> commands handling code. So, we need a new repository to add these codes or
> suggestions to add these codes in any other existing repository.
> >
> > Could you please provide your suggestions on this.
>
> There aren't a lot of details here, so it's kind of hard to make
> concrete suggestions given how short the above description is.



> Can you please put some more details in, background, links, ect


Please find the link below for the yosemiteV2 Design specification.
https://www.opencompute.org/documents/facebook-multi-node-server-platform-yosemite-v2-design-specification

 Our platform is a Multi-node server platform that hosts four Open Compute
Platform (OCP) compliant One Socket (1S) server cards.
 Bridge IC is connected to the BMC on each 1S server through a dedicated I2
C bus as the management interface between a 1S server and the BMC.
 Those server cards are connected to BMC via bridgeIC. All the ipmb
commands from hosts are routed via bridge IC to BMC.
 This bridge IC controls the ipmb communication. This is handling all the
OEM commands and that are platform specific.

 We need to handle the ipmb commands for firmware update of bios/cpld and
bridge IC etc
 and for some other features related to bridge IC.

 Since this is a platform specific feature, we request a new repository to
have this code.
 Going forward, We have Yosemite V3 and other platforms as well. We may use
this new repository for our other platforms.


> Some questions off the top of my head:
>
> 1. How does this differ from MCU sensor in the dbus-sensors repo,
> which also manages a "bridge" IC?


    MCU sensors are different. bridge IC does not manage the MCU sensor.
  These are oem commands. This is not linked with BMC.


> IPMBSensor also implements IPMB, how will code be reused in this new
> repository?
>

 IPMB standard commands can be in IPMBSensor. Only oem commands are
handling in this
new repository.


> 2. Who is going to be the maintainer of this repository?  Ideally it
> would be someone that has been a maintainer before, or someone that
> can mentor in how to be a maintainer.
>

 Patrick Williams can be one of the maintainers.

3. How is this code going to be configured?

4. Where is the design doc for this new feature?  How is it going to
> work, what features are going to be exposed?  What new interfaces will
> be needed?
>

We need to decide to have a new repository for this feature or any other
suggestions/opinions from the community.
Will make the design document for this feature and explain all these
information in detail


>
> >
> > Thanks,
> > Kumar.
>

[-- Attachment #2: Type: text/html, Size: 5505 bytes --]

Re: New repository request for platform specific Bridge IC code

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]

On Wed, Jan 05, 2022 at 07:53:18PM +0530, Kumar Thangavel wrote:
> On Wed, Jan 5, 2022 at 1:20 AM Ed Tanous <ed@tanous.net> wrote:
> 
> > On Mon, Jan 3, 2022 at 11:55 PM Kumar Thangavel
> > <kumarthangavel.hcl@gmail.com> wrote:
<<clipped>>

We are initially supporting the non-open BIC implementation that we had on
Yosemite v1,2, and 3, but we have recently started a fully open source
implementation of the BIC side of this:

    https://github.com/facebook/OpenBIC

We'd certainly be interested in collaborating if anyone else is interested in
designing a system using a uC like this.  Basically the BIC acts as an IO
expander for the BMC so that we can manage multiple hosts and/or accelerator
cards.

At a high-level this is similar to the PLDM subsystem.  We have some IPMB events
that the BIC push to the BMC and we already have those handled in the IPMI
handlers, but there are other parts of the design where the BMC initiates
activity.

We could certainly spread the implementation out into various repositories,
like dbus-sensors and phosphor-bmc-code-mgmt, but I suspect there are going to
be challenges in a bug-free implementation in that regard.  There are cases
where asking the BIC to do one activity, such as update itself, takes offline
some other pieces of functionality, like sensors, and so there does need to be
some state-awareness.  It seems less error prone to put all the various DBus
objects related to the BIC into one daemon/repository in the same manner as
PLDM is doing.


Kumar, in order to get closure on this, I think you should open an issue to
technical-oversight-forum requesting a repository.  Repository oversight is
one of the primary functions of the TOF.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: New repository request for platform specific Bridge IC code

[Kumar Thangavel]

[-- Attachment #1: Type: text/plain, Size: 2004 bytes --]

Hi Patrick,

Thanks for the response. Sure. I will open an issue in TOF for requesting a
new repository.

Thanks,
Kumar.

On Sat, Jan 15, 2022 at 12:22 AM Patrick Williams <patrick@stwcx.xyz> wrote:

> On Wed, Jan 05, 2022 at 07:53:18PM +0530, Kumar Thangavel wrote:
> > On Wed, Jan 5, 2022 at 1:20 AM Ed Tanous <ed@tanous.net> wrote:
> >
> > > On Mon, Jan 3, 2022 at 11:55 PM Kumar Thangavel
> > > <kumarthangavel.hcl@gmail.com> wrote:
> <<clipped>>
>
> We are initially supporting the non-open BIC implementation that we had on
> Yosemite v1,2, and 3, but we have recently started a fully open source
> implementation of the BIC side of this:
>
>     https://github.com/facebook/OpenBIC
>
> We'd certainly be interested in collaborating if anyone else is interested
> in
> designing a system using a uC like this.  Basically the BIC acts as an IO
> expander for the BMC so that we can manage multiple hosts and/or
> accelerator
> cards.
>
> At a high-level this is similar to the PLDM subsystem.  We have some IPMB
> events
> that the BIC push to the BMC and we already have those handled in the IPMI
> handlers, but there are other parts of the design where the BMC initiates
> activity.
>
> We could certainly spread the implementation out into various repositories,
> like dbus-sensors and phosphor-bmc-code-mgmt, but I suspect there are
> going to
> be challenges in a bug-free implementation in that regard.  There are cases
> where asking the BIC to do one activity, such as update itself, takes
> offline
> some other pieces of functionality, like sensors, and so there does need
> to be
> some state-awareness.  It seems less error prone to put all the various
> DBus
> objects related to the BIC into one daemon/repository in the same manner as
> PLDM is doing.
>
>
> Kumar, in order to get closure on this, I think you should open an issue to
> technical-oversight-forum requesting a repository.  Repository oversight is
> one of the primary functions of the TOF.
>
> --
> Patrick Williams
>

[-- Attachment #2: Type: text/html, Size: 2714 bytes --]