* New repository request for platform specific Bridge IC code
@ 2022-01-04 7:56 Kumar Thangavel
2022-01-04 19:50 ` Ed Tanous
0 siblings, 1 reply; 5+ messages in thread
From: Kumar Thangavel @ 2022-01-04 7:56 UTC (permalink / raw)
To: OpenBMC Maillist; +Cc: velumanit, patrickw3, Amithash Prasad
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: New repository request for platform specific Bridge IC code 2022-01-04 7:56 New repository request for platform specific Bridge IC code Kumar Thangavel @ 2022-01-04 19:50 ` Ed Tanous 2022-01-05 14:23 ` Kumar Thangavel 0 siblings, 1 reply; 5+ messages in thread From: Ed Tanous @ 2022-01-04 19:50 UTC (permalink / raw) To: Kumar Thangavel; +Cc: OpenBMC Maillist, velumanit, patrickw3, Amithash Prasad 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: New repository request for platform specific Bridge IC code 2022-01-04 19:50 ` Ed Tanous @ 2022-01-05 14:23 ` Kumar Thangavel 2022-01-14 18:52 ` Patrick Williams 0 siblings, 1 reply; 5+ messages in thread From: Kumar Thangavel @ 2022-01-05 14:23 UTC (permalink / raw) To: Ed Tanous; +Cc: OpenBMC Maillist, velumanit, patrickw3, Amithash Prasad [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: New repository request for platform specific Bridge IC code 2022-01-05 14:23 ` Kumar Thangavel @ 2022-01-14 18:52 ` Patrick Williams 2022-01-15 5:45 ` Kumar Thangavel 0 siblings, 1 reply; 5+ messages in thread From: Patrick Williams @ 2022-01-14 18:52 UTC (permalink / raw) To: Kumar Thangavel Cc: OpenBMC Maillist, Ed Tanous, velumanit, patrickw3, Amithash Prasad [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: New repository request for platform specific Bridge IC code 2022-01-14 18:52 ` Patrick Williams @ 2022-01-15 5:45 ` Kumar Thangavel 0 siblings, 0 replies; 5+ messages in thread From: Kumar Thangavel @ 2022-01-15 5:45 UTC (permalink / raw) To: Patrick Williams Cc: OpenBMC Maillist, Ed Tanous, velumanit, patrickw3, Amithash Prasad [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-01-15 5:46 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-01-04 7:56 New repository request for platform specific Bridge IC code Kumar Thangavel 2022-01-04 19:50 ` Ed Tanous 2022-01-05 14:23 ` Kumar Thangavel 2022-01-14 18:52 ` Patrick Williams 2022-01-15 5:45 ` Kumar Thangavel
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.