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

[Anup Patel]

On Thu, Jul 9, 2026 at 10:27 PM Conor Dooley <conor at kernel.org> wrote:
>
> On Thu, Jul 09, 2026 at 05:20:31PM +0200, Michal Simek 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.
>
> I don't think it is a question to just Microchip, it's a question to be asked
> to all the various companies and projects using RISC-V. For example will
> upstream OpenSBI accept support for SCMI, or will they say "we have RPMI,
> use that"?

For upstream OpenSBI, the preference is RVI specifications and open
standards (such as UEFI, ACPI, Device Tree, etc).

Regards,
Anup