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"?
signature.asc
Description: PGP signature
