Hi All, We don't have a dedicated RISC-V PMU extension but we do have HW performance counters such as CYCLE CSR, INSTRET CSR, and HPMCOUNTER CSRs. A RISC-V CPU can allow monitoring HW events using

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

From that link it looks like the OS already has access to the kernel command line and the EFI system table before it starts looking at the DT / ACPI tables? In that case, the bootloader has already

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

But how will the booting OS know whether to look at ACPI tables or the device tree? Wouldn't you need some register to indicate which one is being used? Jonathan

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. -- Regards, Atish

The register value would also signal the other elements of this platform spec are being followed. Notably including that a1 actually points to a valid device tree. If we could count on a 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

Thanks for that clarification! It is good to know that SBI v0.1 implementations are consistent about returning negative values for functions they don't recognize like sbi_get_spec_version. This

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

Hi everyone, To start off discussion about requirements that should go into the platform spec, I propose a simple change to current software: When entering S-mode for the first time, the a2 register

Hello, This email message is a notification to let you know that the following files have been uploaded to the Files area of the tech-unixplatformspec@... group. /Unix Platform specification working

Note that it can generally be useful to have 4K page 0x0 be no man's land (e.g. catch a bad PA pointer dereference), and that a number of implementations of the RISC-V Debug spec have the Debug Module

Since we don't have the chance to discuss the topics on the agenda in the meeting, please allow me to post two comments from Andes here: > DRAM start address Is there any good reason to standardize

Reminder: Unix platform working group meeting (06/09 8AM PST) @ Tue June 09, 2020 8am - 9am (PST) When: Tuesday, 9 June 2020, 8:00am to 9:00am, (GMT-07:00) America/Los

Yes, I imagine so. Eventually this would be desirable as a very basic form of RAS, i.e when the system is hung or in livelock, this would bring control back to system firmware (to log, recover,

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

Reminder: Unix platform working group meeting (06/09 8AM PST) @ Tue June 09, 2020 8am - 9am (PST) When: Tuesday, 9 June 2020, 8:00am to 9:00am, (GMT-07:00) America/Los

Yes absolutely. I wrote an RV32 MCU question to the unix platform spec group which is my bad. Best Regards Nagendra

I just want to say unequivocally that trying to emulate the Cortex-M memory map in the Unix platform is a short-sighted idea that will only cause extra trouble. These platforms aren’t compatible