Mellanox ipmi daemon discussion

[Mykola Kostenok]

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