[PATCH v2 0/5] Add support for RPMI to U-Boot

[Anup Patel]

On Thu, Jul 9, 2026 at 8:50 PM Michal Simek <michal.simek at amd.com> wrote:
>
>
>
> On 7/9/26 16:54, Charles Perry wrote:
> > On Thu, Jul 09, 2026 at 03:02:11PM +0200, Michal Simek wrote:
> >>
> >>
> >> On 7/8/26 23:51, 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.
> >>
> >>  From the first look it looks like SCMI. Why do you introducing something
> >> what can be replaced by SCMI?
> >> And SCMI has only specific ARM transport layer but the rest is arch independent.
> >
> > Yes, there are alot of similarities between RPMI and SCMI. I found some
> > justification for this in some Linux Plumbers slide deck on RISC-V power
> > management by Paul Walmsley [1]:
> >
> >   * The hardware is more sophisticated
> >   * The software is more sophisticated
> >   * Some stakeholders haven’t had input in the past
> >   * RISC-V “big tent” philosophy
> >
> > I think this is referring to the SBI spec of RISC-V vs arm's PSCI but the
> > same arguments may as well apply to RPMI vs SCMI.
> >
> > Some other arguments:
> >
> >   * The microcontroller side is made easier with RPMI because of librpmi [2].
> >     SCMI has SCP-firmware [3] which is a quite complex project compared to
> >     librpmi. Also SCP-firmware doesn't accept contribution anymore.
> >   * RPMI is already in Linux.
> >
> > For what I'm doing, RPMI is what gave me the first results (controlling
> > clocks) the quickest because all the pieces were present in Linux, OpenSBI
> > and librpmi. There are however lots of missing service drivers in Linux and
> > some other important OS like u-boot don't have support for RPMI at all. So
> > even though I gave you a bunch of reason for saying yes to RPMI, I do have
> > some doubt about how long it will take to bring RPMI on par with SCMI,
> > making the SCMI-for-RISCV transport that you suggest more appealing.
> >
> > [1]: https://lpc.events/event/2/contributions/197/attachments/133/165/RISC-V_Platform_Power_Management.pdf (slide 22)
> > [2]: https://github.com/riscv-software-src/librpmi
> > [3]: https://gitlab.arm.com/firmware/SCP-firmware
> >
> >>
> >> In our case where we have Microblaze V in programmable logic I can't see any
> >> reason to use RPMI for talking to the same server if I need to do it from
> >> ARM side too via SCMI.
> >>
> >> I pretty much think that there should be communication with ARM and instead
> >> of creating another firmware interface talk to each other and have only one
> >> which can be used across multiple architectures.
>
> I have sent RFC patch to eliminate ARM from SCMI here
>
> https://lore.kernel.org/all/d7f7e8c9589d937b60e43168845ab4fda15037a3.1783603600.git.michal.simek@amd.com/
>
> and feedback is quite positive. I think it is more or less question to Microchip
> if you want to take responsibility on another firmware interface (I understand
> that it is approved, etc) or just use what it is around for longer time.
>

Simply renaming the Linux sources does not make the SCMI specification
to be open and community driven. The real problem is SCMI specification
development is not open and community driven with appropriate permissive
license.

Some of the note worthy highlights of RPMI ecosystem as compared to
SCMI are:

1) RPMI specification is an open an community driven specification licensed
under "Creative Commons Attribution 4.0".

2) The scope of RPMI specification is much bigger than SCMI specification where
RPMI is trying to consolidate all required messaging protocols under one RPMI
specification. RPMI defines some unique service groups in-addition to
the service
groups providing SCMI-style functionality such as:
   2.1) Collaborative Processor Performance Control (CPPC)
   Allows application processor to abstract out CPPC support to a
   microcontroller. It also has fast-channels for hot-path CPPC registers
   such as desired performance and current performance level along
   with RISC-V specific fast-mechanism to access delivered and
   reference counter.
   2.2) System MSI
   Allows system-level events to be sent to application processors as MSIs.
   This is used for graceful shutdown/reboot request, hotplug events, etc
   2.3) Request Forward
   Enables one domain / world to receive messages forwarded from
   another domain.
   2.4) Managment Mode (MM)
   Allows UFEI / EDK2 firmware running on application processors to talk
   to managment mode (other domain / world / microcontroller) for secure
   variable updates and other MM services
   2.5) RAS Agent
   Allows UEFI / EDK2 firmware to discover error sources handled by
   firmware and generate RAS related ACPI tables at boot-time
   2.6) Truested Execution Environment (TEE) (Work-in-progress)
   Provides a rich and extensible TEE communication interface between
   non-secure world (Linux) and trusted world (OP-TEE and others).
   2.7) ... and more to come ...

3) The LibRPMI project which a open-source reference implementation of
RPMI is permissively licensed under BSD-2-clause which allows platform
vendors use any RTOS / baremetal-app as their microcontroller firmware.
This library is also shipped as a shared library allowing QEMU to use
LibRPMI for emulating RPMI services for TCG and KVM guests.

4) The following Linux RPMI drivers are already available in upstream:
MPXY mailbox controller, RPMI clock, and RPMI system MSI whereas
the CPPC, LPI and system suspend drivers already work as-is for RISC-V.
The upstreaming of RPMI performance driver is in-progress and should
be merged soon. The OpenSBI (M-mode firmware) already supports
almost all service groups defined by the RPMI v1.0 specification.

Based on the above facts, I would suggest AMD to consider using
RPMI over SCMI.

Regards,
Anup