Why should only S-mode and not HS-mode be allowed? I think the modes that are allowed to access this extension should be enumerated more clearly. How are systems treated that only have M-mode and U-mo

The TCG2 protocol is only a UEFI extension (see UEFI spec 2.9, p.68) and not required to claim UEFI compatibility. If you put a protocol into the UEFI specification, you can be sure that EDK II will i

Am 19. November 2021 01:09:34 MEZ schrieb atishp@...: It seems irrelevant if a library call is made or the syscall is invoked directly. A libc library may be used by some programs but will be

Am 19. November 2021 01:09:33 MEZ schrieb atishp@...: Please, remove one 'only'. Best regards Heinrich

Am 19. November 2021 01:09:32 MEZ schrieb atishp@...: %s/Thue/The/ Best regards Heinrich

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

The phrase "Platforms are allowed to operate only in little-endian mode" literally means that * some platforms may be little-endian only and * others may provide and *use* further modes which contradi

Content-wise I am happy. I would just change the wording and a bit: The M-mode runtime must implement SBI specification version 0.3 or higher. %s/includes/include/ %s/responsibilities/features/ ? %s/o

%s/for OS-A/for the OS-A/ Do you want to allow harts with further ACLINT MTIMER devices? Or is the requirement that each hart must have exactly one ACLINT MTIMER device? An example would help: If the

Just a few typos %s/If H-extension/If the H-extension/ %s/with/with the/ %s/pyscial/physical/ ditto Best regards Heinrich

The way that UEFI reports local time zones is unsatisfactory: There is an offset to UTC and a daylight savings flag but this does not allow to derive on which day daylight saving switches (you could b

a %s/a SBI/an SBI/ (as you will pronounce SBI as as-bee-aye) Can we do away with all the placeholders? How about: "SBI extensions as whole are optional but they shall not be partially implemented: If

%s/secion/section/ %s/managment/management/ %s/implemenation/implementation/ %s/requestd/requested/ %s/hierarchial/hierarchical/ %s/inititated/initiated/ %s/recieves/receives/ %s/rententive/retentive/

"deprecated" implies is required but will be removed in next version. Use instead: "MBR support is not required." Please, remove this sentence because we do not require to implement this. Best regards

Currently EDK II provides OpenSBI as part of its SEC (Security) code in edk2-platforms/Silicon/RISC-V/ProcessorPkg/Library/RiscVOpensbiLib/opensbi. When the hypervisor provides the SEC code we will ne

Am 16. Mai 2021 19:13:47 MESZ schrieb Anup Patel <anup.patel@...>: At least U-Boot relies on OpemSBI for unaligned memory access and may use it for sytem reset. Where will ecalls and exceptions be

Nits only: Please, stick to 80 characters per line. %s/requried/required/ %s/incorportate/incorporate/ %s/locol/local %s/plementation-specific/implementation specific/ Best regards Heinrich

Both has nothing to do with the PI spec. Up to now we have not required that EDK II must be the firmware used. Why would you disallow other firmware? Why should we care about the storage format of the

Up to now this spec does not require EDK II but the provision of APIs. We should keep it this way. EDK II can live on either SPI or on MMC or on an SD card. For developement it is preferable to have i

Dear Abner, https://lists.riscv.org/g/tech-unixplatformspec/message/831?p=,,,20,0,0,0::Created,,efi_load_file2_protocol,20,2,0,82475933 mentioned use cases for the EFI_LOAD_FILE2_PROTOCOL. Shouldn't w