On Thu, Jul 9, 2026 at 10:27 PM Conor Dooley <[email protected]> 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.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. > > 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
