Mellanox ipmi daemon discussion

Mellanox ipmi daemon discussion

[Mykola Kostenok]

Hi,

We'd like to add Mellanox ipmi daemon recipe to mellanox msn platform. It's based on openipmi project.
Code review: https://gerrit.openbmc-project.xyz/#/c/5694/.

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.
It doesn't use DBUS interface.

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

Reviewers welcome.

Best regards. Mykola Kostenok.

Re: Mellanox ipmi daemon discussion

[Joel Stanley]

Hello Mykola,

On Tue, Aug 29, 2017 at 12:57 AM, Mykola Kostenok
<c_mykolak@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://gerrit.openbmc-project.xyz/#/c/5694/.
>
> 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 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?

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

RE: Mellanox ipmi daemon discussion

[Mykola Kostenok]

Hi, Joel.
Thanks for reply!

> -----Original Message-----
> From: joel.stan@gmail.com [mailto:joel.stan@gmail.com] On Behalf Of Joel
> Stanley
> Sent: Wednesday, September 6, 2017 8:17 AM
> To: Mykola Kostenok <c_mykolak@mellanox.com>
> Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
> Subject: Re: Mellanox ipmi daemon discussion
> 
> Hello Mykola,
> 
> On Tue, Aug 29, 2017 at 12:57 AM, Mykola Kostenok
> <c_mykolak@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

RE: Mellanox ipmi daemon discussion

[Mykola Kostenok]

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@lists.ozlabs.org] On Behalf Of Mykola
> Kostenok
> Sent: Wednesday, September 6, 2017 11:31 AM
> To: Joel Stanley <joel@jms.id.au>
> Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>; Ohad Oz
> <ohado@mellanox.com>; Vadim Pasternak <vadimp@mellanox.com>
> Subject: RE: Mellanox ipmi daemon discussion
> 
> Hi, Joel.
> Thanks for reply!
> 
> > -----Original Message-----
> > From: joel.stan@gmail.com [mailto:joel.stan@gmail.com] On Behalf Of
> > Joel Stanley
> > Sent: Wednesday, September 6, 2017 8:17 AM
> > To: Mykola Kostenok <c_mykolak@mellanox.com>
> > Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
> > Subject: Re: Mellanox ipmi daemon discussion
> >
> > Hello Mykola,
> >
> > On Tue, Aug 29, 2017 at 12:57 AM, Mykola Kostenok
> > <c_mykolak@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