New repository request for platform specific Bridge IC code

[Patrick Williams]

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 at tanous.net> wrote:
> 
> > On Mon, Jan 3, 2022 at 11:55 PM Kumar Thangavel
> > <kumarthangavel.hcl at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20220114/9c42bd3c/attachment.sig>