The draft says "Platform must support a default ACLINT MTIME counter resolution of 10ns" which I interpret to mean that 100,000 always corresponds to 1ms. The point of different frequencies just means

I hope I am reading the right current draft. The current draft states: "The ACLINT MTIME update frequency (i.e. hardware clock) must be between 10 MHz and 100 MHz, and updates must be strictly

Adding more configuration options increases complexity. Under the current draft, if software wants an interrupt 1ms in the future it can set mtimecmp to the value of mtime plus 100,000. If we make the

Yes. A spec update to allow higher update frequencies is in the works (along with the other changes that have been recently discussed and decided). Greg

So do we agree that the platform specification must not treat a implementation that has MTIME update frequency higher than 100 MHz as non-compliant. Removing this upper bound does not of course force

The required UART is not for exclusive use by firmwares so the OS can certainly use the UART but it is not mandatory for the OS to support the UART. Regards, Anup

Could you say a bit more about the OS aspect? Is the idea that an OS must be provided access to a UART, but has the option to ignore it in favor of other I/O methods? I don't think we should allow

Darius, The Platforms HSC writing the specs is a left-over (committees only provide governance) that is expected to be restructured in the future (once the initial set of specifications are through

Philipp, The Common Software Interface concept seems like it could be a promising idea, but at this point, that appears to be all it is: an idea. Whether that idea is fully realized into something

+ platforms mailing list Regards Kumar

Hi All, During our Platform HSC meeting today, one of the topics that came up for discussion was whether we should mandate the 16550 UART for all OS-A platforms and keep this requirement within the

But why mandate that it cannot be finer resolytion than 10ns. I can see a requirement to say minimum of 10ns but whats the rationalet to say must not be better than 10ns? regards ved

I can understand definining a minimum resolution but I do not understand why it needs to be capped to 10ns. I do not think the specification should define a maximum resolution. Which specter version

100 MHz is way more than sufficient for carrying out a Spectre attack. Web browsers limit clock resolutions to 1 kHz or even 500 Hz to disrupt those sorts of attacks (and apply other mitigations as

The intent of the wording is that the resolution is 10ns (as implied by the max update frequency of 100 MHz). But I agree that the current wording should change to just directly state a 10ns

The resolution of the mtime register is defined as 10 ns. The 100 MHz value is irrelevant and should be deleted from the spec. (You could check if an mtime increment is needed at a 10 GHz rate.

I have a question about this requirement: "The ACLINT MTIME update frequency (i.e. hardware clock) must be between 10 MHz and 100 MHz, and updates must be strictly monotonic." I do understand

Hi All, The next platform HSC meeting is scheduled on Mon Nov 15th 2021 at 8AM PST. Here are the details: Agenda and minutes kept on the github

Sure. I will update the patch. I was talking about the CMO (cache management operations) CSRs. Here are the

Agree that adding a clarification that these are "required" only if supporting SW interrupts or other interrupts to M-mode is supported. Else the specification reads as if these are always