For #2, I think device tree/ACPI would be a better choice. It's already well defined for ARM. Obviously, it needs to be adopted for RISC-V. https://elixir.bootlin.com/linux/v5.9-rc7/source/Documentati

+Stephano Wednesday 8AM PST may not work as tech-chairs meetings are scheduled on that slot. I was recently made aware of that while setting up hypervisor syncup call. They are on a different calendar

I updated the subject to include the time (8AM PST). I also updated the calendar invite. So everybody's calendar should be updated with the google meet link instead of Zoom. FYI: The calendar in group

I agree. Let's keep UEFI out of this discussion as UEFI support can't be mandatory on all platforms. Moreover, UEFI runtime services are implemented between same privilege levels. Thus, UEFI reset wou

+ Paul/Palmer Any other comments/suggestions ? It would be great if we conclude either way and have some standard reset mechanism sooner than later.

SBI RESET extension is optional. So S-mode software can always fallback on CONFIG_SYSREST to reset the system.

yes. When the group was proposed (almost 18 months back), the idea was to first come up with subset of specifications (SBI, PLIC) under unix platform specification. We have SBI v0.2 specification and

Kindly send the proposal to the mailing list. We have enough topics now so that we can setup a meeting to discuss and finalize things.

I was suggesting to have fixed ranges for both event types. But I agree that it gets tricky with non-standard implementation specific counters. My concern is that it may increase the booting time. For

That's what my understanding as well. Assigning continous counter_idx may put a restriction on M-mode implementation. How about assigning some ranges for software vs hardware counters. May be split th

Yes. ACPI is only usable via UEFI boot. Thus, EFI system table is already available with kernel. Even though kernel looks at DT, before looking at EFI system table, it removes all the memory mappings

I am not sure how it will be implemented in RISC-V when we have ACPI. However, this is process followed in ARM64[1] ACPI tables are passed via UEFI system configuration table while DT address will be

For ACPI tables, a similar property can be added in the ACPI table. We anyways have to add other run time properties to ACPI table as we do currently for the device tree.

Yes. That’s a possibility. If I understand you correctly, you want some identifier that let supervisor know that the M-mode firmware is an SBI based one. If that’s the only case, how about a DT proper

For SBI version, supervisor systems should use "sbi_get_spec_version" API to identify what is the SBI version of the SBI implementation. For v0.1, the above call will return a -ve value indicating tha

I have gathered all the requirements discussed till now and created a google doc. https://docs.google.com/document/d/1sLYZJrK38R_QWj5KjogxU2vjJSTIq0bJjZu57djuGoA/edit?usp=sharing The plan is to regula

As discussed, RV64GC should be the minimum required extensions to boot Linux. Sure. I think most of the above should be specified in the specification. I am hoping somebody will send a PR now :-):-).

Yeah. I would love to allow anybody (RISC-V foundation member or not) to jump into the discussions. However, foundation has strict rules on who can participate in the working group meetings. That's wh

For boot loader behavior specification, the plan is to follow EBBR for embedded devices. Currently, there are ongoing efforts to support UEFI in Linux kernel and EDK2 for RISC-V. Once, all the changes

Hi All, I would like to start a thread to discuss the topics that should go into the unix platform specification apart from SBI & PLIC. SBI specification is already tagged as v0.2 & PLIC specification