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.si...@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.
Thanks,
Michal
