This patch adds all the required content to make RISC-V EBBR compatible. The additional content is not a lot given that we just need to update the architecture specific sections for RISC-V. Rest of th

DT or ACPI are the only hw discovery method that platform spec allows. All the rich operating systems have very mature support for FDT/ACPI. There is no reason to support yet another hw discovery meth

Reviewed-by: Atish Patra <atish.patra@...>

Reviewed-by: Atish Patra <atish.patra@...>

You are correct. If the platform spec defines the dt binding in details for the timebase frequency, all other OS may simply just implement it. Here are my concerns with this approach. 1. If the platfo

Yes. But specifying an approach that is very specific to Linux may not work with other OS. In this case, "timebase-frequency" DT property is specific to Linux. Other OS may or may not adopt the same n

The minimum ISA required is specified by RVA22 profile. I think platform spec should only specify any ISA requirements if any required ISA extensions are not specified by the profile. Pasting the rele

In order to allow the existing hardware to comply with the Linux2022 spec, we should add additional clarification. It is recommended that platforms shall implement the time CSR. In absence of time CSR

Probably some of them are. At least I know OpenPiton guys are interested because they can just run upstream software stack without worrying too much. As per my understanding, Linux2022 base is the min

Yes. Additional clarification for everybody: EBBR is meant for embedded systems as in embedded Linux. The embedded 2022 in RISC-V platform spec is aimed towards the bare metal/micro-controller platfor

As the base specification also targets the dev boards, academia FPGAs at least for Linux 2022, do we need to mandate a watchdog timer. May be put it as strongly recommended and mandate it in Linux 202

This statement is bit ambiguous given that individual SBI section says legacy ones must not be implemented. Should we reword something like this, Any platform seeking compliance with the base specific

I think the confusion is valid because of the current naming scheme which is just a place holder. Just to clarify the embedded2022 is meant for microcontroller type of hardware where some RTOS or bare

Agreed. There are lot of moving pieces with LinuxBoot for RISC-V at this moment. I would suggest to have the Linux-2022 version with UEFI. We can include LinuxBoot in the future version as an alternat

From: Anup Patel <anup.patel@...> This patch adds SBI performance monitoring unit (PMU) extension which allows S-mode (or VS-mode) software to configure hardware/software performance counters with

Overall looks good to me. Merging it via github PR.

LGTM. Reviewed-by: Atish Patra <atish.patra@...>

Adding EDK-II support for platforms usually takes more effort than U- Boot. I think we should keep U-Boot/EDK-II for the base and may choose only EDK-II for server extension. That is still the intenti

Hi, The next platform meeting is scheduled on 8th march 7AM PST. Here are the details: Agenda and minutes kept on the github wiki: https://github.com/riscv/riscv-platform-specs/wiki Here are the slide

Reviewed-by: Atish Patra <atish.patra@...>