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

[Conor Dooley]

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"?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260709/09b4bc1b/attachment.sig>