Module for libmctp

[teburd]

Origin

libmctp hosted by the openbmc project at https://github.com/openbmc/libmctp

Purpose

Implements a transport protocol, MCTP, which is useful for multiplexing and packetizing data across a wire transport, e.g. UART, I2C, I3C, etc.

Mode of integration

Integrated as a module

Maintainership

• @teburd
• @inteljiangwe1

Pull Request

#75743

Description

Management Component Transport Protocol (MCTP) is a well defined protocol that enables multiplexed streams of packetized data across chip to chip interfaces such as i2c, espi, i3c, uart, and others. Built on this protocol are device management and informational protocols such as PLDM which allow for tooling to monitor, control, and update connected devices.

The MCTP and PLDM protocols are very lightweight and commonly only require memcpy of predefined C structures, with modest costs to provide protocol headers including packet numbers, check sums, and channel identifiers.

Protocol definition is maintained by DMTF https://www.dmtf.org/documents/pmci/management-component-transport-protocol-mctp-base-specification-131

Revision

Latest revision with some patches that I'm hopeful to have upstreamed
teburd/libmctp@692ee7c

License

Apache-2.0 OR GPL-2.0-or-later

[henrikbrixandersen]

Will this require any integration code within the Zephyr repository? Or will there be any consumers of this within the Zephyr repository? I am trying to understand the motivation for adding this as an upstream module, if downstream users can just pull it in via their custom manifests.

[teburd]

Will this require any integration code within the Zephyr repository? Or will there be any consumers of this within the Zephyr repository? I am trying to understand the motivation for adding this as an upstream module, if downstream users can just pull it in via their custom manifests.

Yes, libmctp has this idea of bus bindings, I'm looking at adding native bus bindings for Zephyr (uart, etc) and have updated the PR in draft to start showing some of that.

[henrikbrixandersen]

Yes, libmctp has this idea of bus bindings, I'm looking at adding native bus bindings for Zephyr (uart, etc) and have updated the PR in draft to start showing some of that.

I have looked over the PR again. I must admit I am still a bit confused as to what this integration is bringing to Zephyr.

[beriberikix]

Interesting! FWIW I see a lot of requests and custom solutions for inter-MCU communications. Often it's for FOTA but also things like RPC.

Can't speak to the question of upstream needs but this is certainly something I think would be useful for the community.

Looking forward to seeing how the bindings work!

[teburd]

Yes, libmctp has this idea of bus bindings, I'm looking at adding native bus bindings for Zephyr (uart, etc) and have updated the PR in draft to start showing some of that.

I have looked over the PR again. I must admit I am still a bit confused as to what this integration is bringing to Zephyr.

MCTP is a packet protocol, akin to IP or COBS. It needs to be layered on a physical transport (uart/i2c/etc), libmctp provides a binding API to connect the protocol to the physical transport. Having that in Zephyr saves the hassle of having to recreate your own bindings in each application. Not sure whats confusing about that.

I get the PR is confusing, that's due to taking a out of tree sample with a ton of hacks and reworking it into a proper PR. It's still in draft so perhaps I need to get more of it together to paint a better picture for you.

If the problem is that all modules get pulled all the time by west... I mean that's a different problem, a west problem. Other similar tools (cargo, poetry, etc) don't seem to run into this because you can have optional dependencies toggled with feature flags.

[dkalowsk]

I'd really like to see this module be added. Ampere use a version of libmctp ported to Zephyr to run an i2c bus binding. I'll see if we can add that to your PR which in my view would make it easier to explain the value of MCTP. Thanks for doing this work!

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.