Let's continue the discussion here as it has a wider audience than github PR. I have also cc'd all the possible stakeholders. The other alternatives propsed so far 1. Just parse the deveice tree node

Technologist) wrote: I prefer this one as well. But you should pick any value within experimental range. I am not sure about the purpose of the extension but if it has the potential to be a generic SB

Ahh I see. This is very EDK2 specific. I was asking if this extension is required by other Bootloader/firmware. I guess the answer is no. I agree with John's proposal of an extension ID reserved per S

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

wrote: Yeah. That would be useful. Patches are welcome!! As discussed in the OpenSBI mailing list, this might not be possible always. Supervisor software should decide whether it wants to hang the sys

wrote: Looks good to me. Merged to master.

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

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

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

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 :-):-).

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

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

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 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.

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

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

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

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

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.

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