|
Re: [PATCH] Add system reboot extension
Bin Meng
On Tue, Mar 31, 2020 at 12:13 PM Anup Patel <anup.patel@...> wrote:
One generic comment, pretty much similar to the SBI PMP extension I proposed, is that why is this necessary to introduce a new SBI extension to support reboot and shutdown? Do these functionalities have to be operated from M-mode? Regards, Bin
|
|
|
|
Re: [PATCH] Add system reboot extension
Jonathan Behrens <behrensj@...>
Could this just be one function that had cold reboot, warm reboot, and shutdown all as options? Also: "This is a synchronous call and is not expected to return if succeeds." -> "This is a synchronous call and does not return if it succeeds" Jonathan
On Tue, Mar 31, 2020 at 12:13 PM Anup Patel <anup.patel@...> wrote:
|
|
|
|
Re: [PATCH] Add system reboot extension
Bin Meng
On Tue, Mar 31, 2020 at 12:13 PM Anup Patel <anup.patel@...> wrote:
The words are misleading, as it could indicate that the above types only apply to RV32. +|===The shutdown request +|===Otherwise, looks good to me. Regards, Bin
|
|
|
|
[PATCH] Add system reboot extension
This patch adds SBI v0.2 compliant system reboot extension. It defines
two functions: 1. sbi_reboot - A system reboot call with reboot type as parameter 2. sbi_shutdown - A system shutdown/poweroff call The sbi_shutdown function defined here replaces SBI v0.1 shutdown function. Signed-off-by: Atish Patra <atish.patra@...> Signed-off-by: Anup Patel <anup.patel@...> --- riscv-sbi.adoc | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) diff --git a/riscv-sbi.adoc b/riscv-sbi.adoc index 8137686..a39e362 100644 --- a/riscv-sbi.adoc +++ b/riscv-sbi.adoc @@ -615,6 +615,70 @@ state of the hart at the time of return value verification. | sbi_hart_get_status | 2 | 0x48534D |=== +== System Reboot Extension, Extension ID: 0x53524254 (SRBT) + +The System Reboot Extension provides a set of functions that allow the +supervisor software to request system-level reboot or shutdown. + +[source, C] +---- +struct sbiret sbi_system_reboot(unsigned long reboot_type) +---- + +Reboot the system based on provided reboot type. This is a synchronous call +and is not expected to return if succeeds. + +The reboot_type parameter is 32 bit wide and has following possible values: + +[cols="<,>",options="header,compact"] +|=== +| Value | Description +| 0x00000000 | Cold reboot +| 0x00000001 | Warm reboot +| 0x00000002 - 0xEFFFFFFF | Reserved for future use +| 0xF0000000 - 0xFFFFFFFF | Vendor or platform specific reboot type +| 0x100000000 - 2^XELN-1 | Reserved for RV64/RV128 +|=== + +*Returns* one of the following possible SBI error codes through sbiret.error +upon failure. + +Cold reboot results in complete power cycle of the entire system while +warm reboot depends on SOC vendor design choices. + +[cols="<,>",options="header,compact"] +|=== +| Error code | Description +| SBI_ERR_INVALID_PARAM | `reboot_type` is not valid. +| SBI_ERR_FAILED | Reboot request failed for unknown reasons. +|=== + +[source, C] +---- +struct sbiret sbi_system_shutdown() +---- + +Shutdown the system. This is a synchronous call and is not expected to +return if succeeds. + +*Returns* one of the following possible SBI error codes through sbiret.error +upon failure. + +[cols="<,>",options="header,compact"] +|=== +| Error code | Description +| SBI_ERR_FAILED | The start request failed for unknown reasons. +|=== + +=== SRBT Function Listing + +[cols="<,,>",options="header,compact"] +|=== +| Function Name | Function ID | Extension ID +| sbi_system_reboot | 0 | 0x53524254 +| sbi_system_shutdown | 1 | 0x53524254 +|=== + == Experimental SBI Extension Space, Extension IDs 0x0800000 through 0x08FFFFFF No management. -- 2.17.1
|
|
|
|
Re: [PATCH 0/1] SBI: Introduce Physical Memory Protection Extension
atishp@...
On Tue, 2020-03-10 at 07:25 -0700, Bin Meng wrote:
S-mode software needs a way to know memory used by SBI firmware soLet'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 in S-mode software. Pros: No additional SBI extensions are required. Cons: U-Boot is responsible for copying the reserved-memory node from the DT passed by OpenSBI and set it to the final DT if it is a different one. OpenSBI also need to provide the DT where the previous stage (FSBL/U-Boot SPL) doesn't provide a DT. IMHO, this is not a very difficult problem to solve. The U-Boot implementation is available here (just ~40 lines of code). https://patchwork.ozlabs.org/patch/1254740/ 2. Trap-n-Emulate PMP CSR reads from S-mode. The details are available here. https://github.com/riscv/riscv-sbi-doc/pull/37#issuecomment-596944084 Pros: No SBI extension or prior DTB fixup required in U-Boot. Cons: As PMP extensions proposals are already in place, this may need to be extended. Privilege spec may need to be modified to explicitly say that M-mode can provide PMP csr emulation. Any thoughts ? -- Regards, Atish
|
|
|
|
[PATCH] Introduce Physical Memory Protection Extension
Bin Meng
S-mode software needs a way to know memory used by SBI firmware so
that it can correctly mark such memory as reserved. Related discussion: https://github.com/riscv/opensbi/issues/103 Signed-off-by: Bin Meng <bmeng.cn@...> --- riscv-sbi.adoc | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) diff --git a/riscv-sbi.adoc b/riscv-sbi.adoc index 37d0791..c9dba7c 100644 --- a/riscv-sbi.adoc +++ b/riscv-sbi.adoc @@ -592,6 +592,71 @@ state of the hart at the time of return value verification. | sbi_hart_get_status | 2 | 0x48534D |=== +== Physical Memory Protection Extension, Extension ID: 0x504D50 (PMP) +The Physical Memory Protection Extension introduces a set of functions that +allow the supervisor to request higher privilege mode to return information +of the memory regions protected by the SBI firmware via the PMP unit. + +Every memory region protected by the SBI firmware can be described by a C +structure (or descriptor) below: + +[source, C] +---- +struct pmp_fw_prot_desc { + unsigned long base; + unsigned long size; +}; +---- + +If there are mutiple memory regions protected, multiple descriptors should +be used with each one describing a single memory region. + +[source, C] +---- +struct sbiret sbi_get_fw_prot_desc_size() +---- +*Returns* the size of memory (in bytes) required to describe the protected +memory regions by the SBI firmware via PMP through sbiret.value, or one of +the following possible SBI error codes through sbiret.error. + +[cols="<,>",options="header,compact"] +|=== +| Error code | Description +| SBI_SUCCESS | The size of memory (in bytes) required to + + describe the protected memory regions by the SBI + + firmware via PMP is written to sbiret.value. + + The size should be multiple of one descriptor + + size, that is sizeof(struct pmp_fw_prot_desc). + + If no memory region is protected, zero is set + + to sbiret.value. +| SBI_ERR_NOT_SUPPORTED | PMP is not available on this platform. +|=== + +[source, C] +---- +struct sbiret sbi_get_fw_prot_desc(struct pmp_fw_prot_desc *desc) +---- +*Returns* one of the following possible SBI error codes through sbiret.error. + +[cols="<,>",options="header,compact"] +|=== +| Error code | Description +| SBI_SUCCESS | The physical address of RAM pointed by desc + + where memory region information is to be written + + are filled in by SBI firmware, one after another + + if multiple memory regions are protected. +| SBI_ERR_NOT_SUPPORTED | PMP is not available on this platform. +|=== + +=== PMP Function Listing + +[cols="<,,>",options="header,compact"] +|=== +| Function Name | Function ID | Extension ID +| sbi_get_fw_prot_desc_size | 0 | 0x504D50 +| sbi_get_fw_prot_desc | 1 | 0x504D50 +|=== + == Experimental SBI Extension Space, Extension IDs 0x0800000 through 0x08FFFFFF No management. -- 2.7.4
|
|
|
|
[PATCH 0/1] SBI: Introduce Physical Memory Protection Extension
Bin Meng
S-mode software needs a way to know memory used by SBI firmware so
that it can correctly mark such memory as reserved. This patch was already posted on github as a PR [1], and I was told to send this patch to this mailing list for broader discussion. For details on why and possible solutions to debate, please visit the github PR. Comments are welcome! [1] https://github.com/riscv/riscv-sbi-doc/pull/37 Bin Meng (1): Introduce Physical Memory Protection Extension riscv-sbi.adoc | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) -- 2.7.4
|
|
|
|
Unix platform working group meeting (02/05 8AM PST) @ Wed Feb 5, 2020 8am - 9am (PST) - Wed, 02/05/2020
#cal-notice
tech-unixplatformspec@lists.riscv.org Calendar <noreply@...>
Unix platform working group meeting (02/05 8AM PST) @ Wed Feb 5, 2020 8am - 9am (PST) When: Where: Description:
|
|
|
|
Upcoming Event: Unix platform working group meeting (02/05 8AM PST) @ Wed Feb 5, 2020 8am - 9am (PST) - Wed, 02/05/2020 8:00am-9:00am
#cal-reminder
tech-unixplatformspec@lists.riscv.org Calendar <tech-unixplatformspec@...>
Reminder: Unix platform working group meeting (02/05 8AM PST) @ Wed Feb 5, 2020 8am - 9am (PST) When: Wednesday, 5 February 2020, 8:00am to 9:00am, (GMT-08:00) America/Los Angeles Where:webex Description: Hi All,
|
|
|
|
Upcoming Event: Unix platform working group meeting (02/05 8AM PST) @ Wed Feb 5, 2020 8am - 9am (PST) - Wed, 02/05/2020 8:00am-9:00am
#cal-reminder
tech-unixplatformspec@lists.riscv.org Calendar <tech-unixplatformspec@...>
Reminder: Unix platform working group meeting (02/05 8AM PST) @ Wed Feb 5, 2020 8am - 9am (PST) When: Wednesday, 5 February 2020, 8:00am to 9:00am, (GMT-08:00) America/Los Angeles Where:webex Description: Hi All,
|
|
|