Mellanox ipmi daemon discussion

Mykola Kostenok c_mykolak at mellanox.com
Thu Sep 14 23:04:18 AEST 2017


Hi, Joel.

We add opportunity to compile our ipmi daemon with dbus headers and libs.
So it can be compiled --with-dbus.
Along with it I sent next version of mlx_ipmid recipe with dbus to gerrit:  
https://gerrit.openbmc-project.xyz/#/c/5694/5

Our ipmi daemon code located at:
	https://github.com/mellanoxbmc/ipmi
	branch openbmc

Best regards, Mykola Kostenok.


> -----Original Message-----
> From: openbmc [mailto:openbmc-
> bounces+c_mykolak=mellanox.com at lists.ozlabs.org] On Behalf Of Mykola
> Kostenok
> Sent: Wednesday, September 6, 2017 11:31 AM
> To: Joel Stanley <joel at jms.id.au>
> Cc: OpenBMC Maillist <openbmc at lists.ozlabs.org>; Ohad Oz
> <ohado at mellanox.com>; Vadim Pasternak <vadimp at mellanox.com>
> Subject: RE: Mellanox ipmi daemon discussion
> 
> Hi, Joel.
> Thanks for reply!
> 
> > -----Original Message-----
> > From: joel.stan at gmail.com [mailto:joel.stan at gmail.com] On Behalf Of
> > Joel Stanley
> > Sent: Wednesday, September 6, 2017 8:17 AM
> > To: Mykola Kostenok <c_mykolak at mellanox.com>
> > Cc: OpenBMC Maillist <openbmc at lists.ozlabs.org>
> > Subject: Re: Mellanox ipmi daemon discussion
> >
> > Hello Mykola,
> >
> > On Tue, Aug 29, 2017 at 12:57 AM, Mykola Kostenok
> > <c_mykolak at mellanox.com> wrote:
> > >
> > > We'd like to add Mellanox ipmi daemon recipe to mellanox msn platform.
> > It's based on openipmi project.
> > > Code review:
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fger
> > rit.openbmc-
> >
> project.xyz%2F%23%2Fc%2F5694%2F&data=02%7C01%7Cc_mykolak%40mell
> >
> anox.com%7Cdc12855ac5a7464852c308d4f4e68771%7Ca652971c7d2e4d9ba6a
> >
> 4d149256f461b%7C0%7C0%7C636402718335056189&sdata=Qfs2ITkG5TJgP5m
> > SVT0NHOzQqVkHDFNRpgVoc8YodrQ%3D&reserved=0.
> > >
> > > We added some hooks in openipmi code and also our specific module.
> > > We use it for SoL, SEL, serial console redirection, console
> > > switching
> > between the host and BMC, PET/PEF, LAN related commands, time
> > setting,, and also a lot of OEM commands for LED, FAN control, reset
> > signals, reset causes, BT connection with CPU, etc.
> >
> > The reuse of existing code is a good achievement. Well done.
> >
> > How did you find the use of OpenIPMI for your needs?
> >
> 
> It's good to us. It's already had many features from the box and It has
> infrastructure for adding vendor specific code. It has "simulator" and Marvell
> modules.
> And we added Mellanox.
> 
> When we started to use openbmc its ipmi demon has very limited features
> support.
> We had commitment to provide engineering sample to our potential
> customer two months after HW arriving. And we were very limited in
> resources.
> So we wanted to find some quick-and-dirty solution in order to be able to
> support SoL, serial redirection, SEL, SDR, LAN, PET/PEF and more.
> We built some wire-up model connecting one of our existing system to
> Aspeed EVB (with serial, I2C connections to FAN, PSU, LPC connections from
> host to BMC).
> On this model we were able to debug real system interface (LPC/BT),
> partially SDR, SEL, SOL.
> 
> When system is arrived we were able to come up from the first run.
> And all the above features worked more or less fine.
> Then we had to debug shared NIC/NC-SI, thermal algorithm, LED control,
> resets and other stuff.
> But basically we managed to provide engineering sample according to our
> commitment.
> 
> > > It doesn't use DBUS interface.
> >
> > This is a downside. The use of dbus as an inter-process communication
> > mechanism is something that defines OpenBMC at the moment.
> >
> > Could you add dbus IPC to the existing codebase?
> >
> 
> I'll add dbus IPC to the existing codebase, maybe I will need some guidelines
> on this matter.
> 
> > >
> > > We are planning transition to OpenBMC ipmi demon, after we are done
> > with all kernel related patches. Our plan is to start transition in
> > the following order SoL, SDR, SEL, LAN, LED and so on.
> >
> > What lead to this decision? What are the up and down sides of the
> > phosphor ipmi daemon compared to OpenIPMI?
> >
> 
> At the moment it's not so easy for me to compare the openipmi feature
> versus openbmc.
> I should learn more the current content of the last.
> 
> Actually we are OK with openipmi, but we wanted to be aligned with
> openbmc, since all the others systems are using it.
> Maybe after we'll add dbus IPC, it could be some compromise between
> these two processes.
> Maybe somebody else would like to extended our work in openipmi for
> using it.
> 
> Best regards, Mykola Kostenok.
> 
> > > At his moment we'd like to have functional image, which can be built
> > > from
> > OpenBMC with no any patches.
> > > We also have one customer and it's important for us to have a
> > > functional
> > image, which he can build by himself.
> >
> > Agreed. I've +1'd your patch, and would like to see it merged.
> >
> > Cheers,
> >
> > Joel


More information about the openbmc mailing list