Hi Michal, It is not correct to say that SCMI already exists and so RPMI is not needed. If you read the RPMI specification you will find that the two differ significantly. I don't mean overlapping names, but how things are defined and implemented in the spec. Compare the transport, compare the defined messages.
RPMI defines many service groups that have no counterpart in SCMI like System MSI/System IRQ, TEE, RAS Agent, Management Mode, CPPC, Logging, Request Forward and others. Together they cover use cases ranging from typical systems to confidential computing and virtualization, all in one specification. There is also a difference in governance, which is visible from the licences of the two specifications. RPMI is under CC-BY 4 license which allows anyone to adapt it and share modified versions with attribution, and changes are developed in the open under RISC-V International. The development does not happen behind closed door but rather any indivudial/organization can also take part in the discussions. I think open source projects always give users/vendors freedom to use any protocol which suits their platform. It must not be dictated that everyone must stick to one interface. As Heinrich pointed out that U-Boot already supports alternatives for various things and Linux and OpenSBI already support RPMI. Adding RPMI support to U-Boot does not take anything away from SCMI. Platforms that use SCMI can continue to do so, and platforms built on RPMI get the support they need. So RPMI is not another interface that does the same thing. It is a broader specification, developed openly by the community that uses it in which you and anyone can also take part. Sorry for the big post. Regards, Rahul On Wed, Oct 14, 2026 at 12:41 PM Michal Simek <[email protected]> wrote: > > > > On 10/13/26 12:33, Heinrich Schuchardt wrote: > > On 10/13/26 08:49, Michal Simek wrote: > >> > >> > >> On 10/13/26 01:55, Charles Perry wrote: > >>> On Mon, Oct 12, 2026 at 11:47:51AM +0200, Michal Simek wrote: > >>>> Hi, +Paul > >>> > >>> Hello Michal, > >>> > >>>> > >>>> first of all do not use mailing list on denx.de. > >>> > >>> Ok, I sent this series at around the time U-Boot changed to > >>> [email protected]. Sorry for that. > >>> > >>>> > >>>> On 9/2/26 16:17, Charles Perry wrote: > >>>>> Hello, > >>>>> > >>>>> This series adds support for RISC-V Platform Management Interface > >>>>> (RPMI) to > >>>>> U-Boot. RPMI is an OS-agnostic protocol for communication between an > >>>>> Application Processor (AP) and a Platform Microcontroller (PuC) [1]. The > >>>>> goals and purpose of RPMI are similar to ARM's SCMI. > >>>> I have raised my concern at riscv minisummit at LPC and also talked to > >>>> Paul > >>>> (riscv kernel maintainer) that this is not the right way to go. We > >>>> already > >>>> have SCMI and there is no reason to introduce RPMI when it is said it is > >>>> serving the same purpose. > >>> > >>> Cool! Thanks for bringing this topic to LPC! > >>> > >>> That being said, I don't understand why we can't have both SCMI and RPMI. > >>> For sure its more code to maintain, but there are other things at play > >>> than > >>> just the functionnality. We discussed this in v2 [1], the points of > >>> contention were: > >>> > >>> * Anup said that the main blocker for him is that the SCMI spec is not > >>> community driven while RPMI is. > >> > >> Based on my information none really starts to talk to ARM about SCMI and > >> this > >> has been introduced serving the same purpose. None should introduce another > >> interface which does the same thing. That never was the right way to go. > >> > >> Thanks, > >> Michal > > > > Hello Michal, > > > > RPMI is already used in the Linux kernel since 2025. > > > > U-Boot has already lot of alternative interfaces implemented: > > > > * Xen and QEMU/KVM > > * half a dozen file systems > > * MBR and GPT > > * FIT images and UEFI > > > > I can't see anything special about RPMI. > > > > As nobody, including you, seems to be interested in driving a discussion > > with > > ARM which would set back RISC-V for months or years, we should proceed > > implementing what is needed. > When I found it I have raised this concern with ARM too. > > I have also sent one patch > https://lore.kernel.org/all/d7f7e8c9589d937b60e43168845ab4fda15037a3.1783603600.git.michal.si...@amd.com/ > > and based on my discussions at LPC/OSSE I will send another version. > > Thanks, > Michal
