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