| Message ID | 20240304102540.2789225-1-fei2.wu@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add RISC-V Server Platform Reference Board | expand |
On 04.03.24 11:25, Wu, Fei2 wrote: > The RISC-V Server Platform specification[1] defines a standardized set > of hardware and software capabilities, that portable system software, > such as OS and hypervisors can rely on being present in a RISC-V server > platform. This patchset provides a RISC-V Server Platform (RVSP) > reference implementation on qemu which is in compliance with the spec > as faithful as possible. > > The reference board can be running with tag edk2-stable202308 in > upstream edk2 repo[2]. > > The qemu command line used: > > $QEMU -nographic -m 4G -smp 2 \ > -machine rvsp-ref,pflash0=pflash0,pflash1=pflash1 \ > -blockdev node-name=pflash0,driver=file,read-only=on,filename=RISCV_VIRT_CODE.fd \ > -blockdev node-name=pflash1,driver=file,filename=RISCV_VIRT_VARS.fd \ > -bios fw_dynamic.bin \ > -drive file=$BRS_IMG,if=ide,format=raw > > Since there is no ACPI table generated in this new machine type, a > corresponding EDK-II platform (WIP) is needed to provide related ACPI > tables. The need for having a platform separate to virt for compliance testing was discussed in RISE in RVI meetings. Thanks for driving this. Will the EDK II platform also generate the SMBIOS table or shall this be handled in QEMU? Will further work in edk2-platforms be needed to provide full compliance with the the server platform specification? Best regards Heinrich > > For testing purposes only, we used a workaround to generate the ACPI > tables in Qemu with a dedicated downstream patch. > > [1] https://github.com/riscv-non-isa/riscv-server-platform > [2] https://github.com/tianocore/edk2.git > > Fei Wu (2): > hw/riscv: Add server platform reference machine > target/riscv: Add server platform reference cpu > > configs/devices/riscv64-softmmu/default.mak | 1 + > hw/riscv/Kconfig | 13 + > hw/riscv/meson.build | 1 + > hw/riscv/server_platform_ref.c | 1248 +++++++++++++++++++ > target/riscv/cpu-qom.h | 1 + > target/riscv/cpu.c | 62 + > 6 files changed, 1326 insertions(+) > create mode 100644 hw/riscv/server_platform_ref.c >
Yes. In short term, Smbios/ACPI still need to be handled by Qemu. We will have a reference board to upstream to edk2-platform compatible with server platform spec, which is still under review now. After that, Smbios/Acpi will be taken over by firmware directly. BR, Evan -----Original Message----- From: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Sent: Monday, March 4, 2024 7:02 PM To: Wu, Fei2 <fei2.wu@intel.com> Cc: pbonzini@redhat.com; palmer@dabbelt.com; alistair.francis@wdc.com; Meng, Bin <bin.meng@windriver.com>; liwei1518@gmail.com; dbarboza@ventanamicro.com; zhiwei_liu@linux.alibaba.com; qemu-devel@nongnu.org; qemu-riscv@nongnu.org; Warkentin, Andrei <andrei.warkentin@intel.com>; shaolin.xie@alibaba-inc.com; ved@rivosinc.com; sunilvl@ventanamicro.com; Xu, Haibo1 <haibo1.xu@intel.com>; Chai, Evan <evan.chai@intel.com>; Wang, Yin <yin.wang@intel.com>; tech-server-platform@lists.riscv.org; tech-server-soc@lists.riscv.org Subject: Re: [RISC-V][tech-server-platform] [RFC 0/2] Add RISC-V Server Platform Reference Board On 04.03.24 11:25, Wu, Fei2 wrote: > The RISC-V Server Platform specification[1] defines a standardized set > of hardware and software capabilities, that portable system software, > such as OS and hypervisors can rely on being present in a RISC-V > server platform. This patchset provides a RISC-V Server Platform > (RVSP) reference implementation on qemu which is in compliance with > the spec as faithful as possible. > > The reference board can be running with tag edk2-stable202308 in > upstream edk2 repo[2]. > > The qemu command line used: > > $QEMU -nographic -m 4G -smp 2 \ > -machine rvsp-ref,pflash0=pflash0,pflash1=pflash1 \ > -blockdev node-name=pflash0,driver=file,read-only=on,filename=RISCV_VIRT_CODE.fd \ > -blockdev node-name=pflash1,driver=file,filename=RISCV_VIRT_VARS.fd \ > -bios fw_dynamic.bin \ > -drive file=$BRS_IMG,if=ide,format=raw > > Since there is no ACPI table generated in this new machine type, a > corresponding EDK-II platform (WIP) is needed to provide related ACPI > tables. The need for having a platform separate to virt for compliance testing was discussed in RISE in RVI meetings. Thanks for driving this. Will the EDK II platform also generate the SMBIOS table or shall this be handled in QEMU? Will further work in edk2-platforms be needed to provide full compliance with the the server platform specification? Best regards Heinrich > > For testing purposes only, we used a workaround to generate the ACPI > tables in Qemu with a dedicated downstream patch. > > [1] https://github.com/riscv-non-isa/riscv-server-platform > [2] https://github.com/tianocore/edk2.git > > Fei Wu (2): > hw/riscv: Add server platform reference machine > target/riscv: Add server platform reference cpu > > configs/devices/riscv64-softmmu/default.mak | 1 + > hw/riscv/Kconfig | 13 + > hw/riscv/meson.build | 1 + > hw/riscv/server_platform_ref.c | 1248 +++++++++++++++++++ > target/riscv/cpu-qom.h | 1 + > target/riscv/cpu.c | 62 + > 6 files changed, 1326 insertions(+) > create mode 100644 hw/riscv/server_platform_ref.c >
W dniu 4.03.2024 o 11:25, Fei Wu pisze: > The RISC-V Server Platform specification[1] defines a standardized > set of hardware and software capabilities, that portable system > software, such as OS and hypervisors can rely on being present in a > RISC-V server platform. This patchset provides a RISC-V Server > Platform (RVSP) reference implementation on qemu which is in > compliance with the spec as faithful as possible. I am working on sbsa-ref which is AArch64 Standard Server Platform implementation. Will not go through details of rvsp-ref but give some potential hints from my work with our platform. 1. Consider versioning the platform. We have 'platform_version'.'major/minor' exported in DeviceTree-formatted data. This allows for firmware to know which of non-discoverable hardware features exists and which not. We use it to disable XHCI controller on older platform version. 2. If specification allows to have non-discoverable devices then add some. This will require you to handle them in firmware in some way. Sooner or later some physical hardware will be in same situation so they can use your firmware code as reference. We have AHCI and XHCI on system bus (hardcoded in firmware). 3. You are going to use EDK2 with ACPI. Hide DT from code there with some hardware information library. For sbsa-ref we created SbsaHardwareInfoLib in https://openfw.io/edk2-devel/20240306-no-dt-for-cpu-v6-0-acd8727a1b59@linaro.org/ patchset.
On 3/8/2024 6:15 AM, Marcin Juszkiewicz wrote: > W dniu 4.03.2024 o 11:25, Fei Wu pisze: > >> The RISC-V Server Platform specification[1] defines a standardized >> set of hardware and software capabilities, that portable system >> software, such as OS and hypervisors can rely on being present in a >> RISC-V server platform. This patchset provides a RISC-V Server >> Platform (RVSP) reference implementation on qemu which is in >> compliance with the spec as faithful as possible. > > I am working on sbsa-ref which is AArch64 Standard Server Platform > implementation. Will not go through details of rvsp-ref but give some > potential hints from my work with our platform. > Hi Marcin, Thank you for sharing this. > > 1. Consider versioning the platform. > > We have 'platform_version'.'major/minor' exported in > DeviceTree-formatted data. This allows for firmware to know which of > non-discoverable hardware features exists and which not. We use it to > disable XHCI controller on older platform version. > Looks good, I will add it. > > 2. If specification allows to have non-discoverable devices then add some. > > This will require you to handle them in firmware in some way. Sooner or > later some physical hardware will be in same situation so they can use > your firmware code as reference. We have AHCI and XHCI on system bus > (hardcoded in firmware). > This RFC currently adds the devices like AHCI as PCI devices. > > 3. You are going to use EDK2 with ACPI. Hide DT from code there with > some hardware information library. > > For sbsa-ref we created SbsaHardwareInfoLib in > https://openfw.io/edk2-devel/20240306-no-dt-for-cpu-v6-0-acd8727a1b59@linaro.org/ patchset. > Looks good, I will ask my colleague working on FW part to take a look. Thanks, Fei.
The RISC-V Server Platform specification[1] defines a standardized set of hardware and software capabilities, that portable system software, such as OS and hypervisors can rely on being present in a RISC-V server platform. This patchset provides a RISC-V Server Platform (RVSP) reference implementation on qemu which is in compliance with the spec as faithful as possible. The reference board can be running with tag edk2-stable202308 in upstream edk2 repo[2]. The qemu command line used: $QEMU -nographic -m 4G -smp 2 \ -machine rvsp-ref,pflash0=pflash0,pflash1=pflash1 \ -blockdev node-name=pflash0,driver=file,read-only=on,filename=RISCV_VIRT_CODE.fd \ -blockdev node-name=pflash1,driver=file,filename=RISCV_VIRT_VARS.fd \ -bios fw_dynamic.bin \ -drive file=$BRS_IMG,if=ide,format=raw Since there is no ACPI table generated in this new machine type, a corresponding EDK-II platform (WIP) is needed to provide related ACPI tables. For testing purposes only, we used a workaround to generate the ACPI tables in Qemu with a dedicated downstream patch. [1] https://github.com/riscv-non-isa/riscv-server-platform [2] https://github.com/tianocore/edk2.git Fei Wu (2): hw/riscv: Add server platform reference machine target/riscv: Add server platform reference cpu configs/devices/riscv64-softmmu/default.mak | 1 + hw/riscv/Kconfig | 13 + hw/riscv/meson.build | 1 + hw/riscv/server_platform_ref.c | 1248 +++++++++++++++++++ target/riscv/cpu-qom.h | 1 + target/riscv/cpu.c | 62 + 6 files changed, 1326 insertions(+) create mode 100644 hw/riscv/server_platform_ref.c