libmctp / libpldm / pldmtool

[Andrew Jeffery]

Hi Rajesh,

On Mon, 2024-09-16 at 15:13 +0000, Ananth, Rajesh wrote:
> Andrew,
> 
> Thank you so much. For people like us who are totally new to this development environment, the "siloed" aspect of information availability has been very difficult to navigate through.
> 
> The objective of ours is to use the PLDM and SPDM software tools with the MCTP support in the OpenBMC environment. We are totally new to this development, and hence based on our own research we went with Portwell's PCOMC660 board (for a charge) that came up with their own BB layer added to the OpenBMC source. This source is not in the OpenBMC github but in their own private tree that is forked downstream by them. Our thought was to have somebody who could help us directly, instead of going to a big forum like yours.
> 

Working with open source projects almost always goes best if you engage
with them socially as well as technically :) If the "big forum" part of
OpenBMC felt intimidating then it's important we know about that too,
so we can work to make it more inclusive.

The discord instance[1] is hopefully a more casual way to get in touch
with the community.

[1]: https://discord.gg/69Km47zH98

> We had so many new things to navigate through.

For the OpenBMC-specific bits, it might be good to get your thoughts on
this post from yesterday:

https://lore.kernel.org/all/0a691364b0d01644c9ca6dfee4b76e69106650d2.camel@codeconstruct.com.au/

> 
> We make CXL controller cards, and for them PLDM Type-5 based Firmware update is very critical for our customers. Also, our customers need SPDM support for device authenticity. We want to have a development environment to validate what we build. Without a ready to run stack of MCTP, PLDM (libpldm, pldmtool, pldmresponder), and SPDM, for people like ours to put them all together  is becoming a huge project on its own.
> 
> In the downstream Portwell source we have:
> 1. xys.openbmc_project.mcptd.service is there, but is not discovering any endpoints. We tried over smbus as well as Pcie, as their board as well as our CXL firmware supports MCTP over both the interfaces.
> 2. Utilities such as  mctp-ast,  mctp-astpcie-test etc., are present.  No PLDM tools are present.

These all sound like pieces of a puzzle that doesn't reflect upstream
OpenBMC. I suspect you've got Intel's mctpd, and ASPEED's mctp tools.

Upstream OpenBMC uses Linux's AF_MCTP sockets and the mctp tools from
the same people that did the upstream kernel work:

https://github.com/CodeConstruct/mctp

I'm not sure how easy they will be to integrate in your context, but
I'd certainly recommend trying given that it's the community supported
approach.

> 
> We have been asking the Portwell team to provide them. But we thought, we could do on our own with the delay that was really frustrating.
> The documentation for OpenBMC support for PLDM, MCTP and SPDM, all refer to the full stack that is based on Linux  (the one you explained in your earlier email) and we went with integrating them in our source. That was a disaster as we just couldn't bake the recipe files properly (running in circle reference).
> 

Best to talk to the community before things become disasters :) Usually
you can find the person that did the work and talk with them directly
about what you're trying to do. That said if you're using a mix of
tools and support from Aspeed and Intel's OpenBMC fork, then it might
be a little more difficult.

>  The AF_MCTP reference that you mentioned was something we didn't know that existed at all.

Please do ask questions if you think the AF_MCTP approach will help
your efforts!

Andrew