On 10/30/25 12:23 PM, Chao Liu wrote:
On 10/30/2025 9:33 PM, Daniel Henrique Barboza wrote:
On 10/30/25 8:48 AM, Chao Liu wrote:
On Wed, May 28, 2025 at 05:01:29PM -0300, Daniel Henrique Barboza wrote:
Hi,
This is my attempt to ressurect the Server SoC Platform reference work
that has been buried for an year. The last posting was made an year ago
[1].
Most of the changes were made due to upstream differences from one year
ago. Patch 1 is an example of that.
In patch 2 (former 1), the main difference is the new CPU is rva23s64
compliant. This wasn't possible in May 2024 because we didn't have this
support back then.
Patch 3 consists mostly of code base changes rather than functional
changes. There was a discussion about whether we should supply fdts in
this machine back in the v2 review [2]. The answer is yes: machine mode
requires fdt to work, and we want to be flexible enough to generate our
own fdt instead of relying on EDK2 to supply them. Note that we can also
supply an EDK2-generated fdt via command line, bypassing the fdt created
by QEMU, if desired.
Patch 4 adds a riscv-iommu-sys device to the board. This wasn't possible
back then because we didn't have the required upstream support for it.
Hi, Daniel.
Do we have any plans to support virt-io on the rvsp-ref machine in the future?
Hmmm good question. In theory we're interested only in implementing the rvsp-ref
spec but adding virt-io support doesn't hurt the spec implementation in any
way ... I think. Drew, any comments?
Recently, I have been using the RISC-V reference platform built on this set of
patches to support running the OpenEuler RISC-V operating system.
I will actively feed back any test results to the upstream.
This series has been stale because, as you might've read in the thread, it turns
out we're missing a mandatory extension (sdext).
I have a basic version of the sdext extension ready. I’ll improve it later and
share it with the upstream community to discuss.
That's awesome! Guess we'll be able to upstream a 100% compliant server platform
emulation sooner than I've expected.
Thanks,
Daniel
Thank,
Chao
I get emails from time to time from people asking about the status of this work
so I'm considering pushing the patches as is, without sdext, and add
documentation
saying that this isn't a 100% rsvp-ref compliant board. The absence of sdext
seems tolerable for the current uses ppl have for the board ATM, so upstreaming
it as is can be beneficial for everyone. We can add sdext support later and
then update the docs claiming 100% compliance.
At very least I'll have to send a v4 now that you pointed out a wrong memory
address in the memmap, so I'll start with that.
Thanks,
Daniel
Thanks,
Chao
