tech-unixplatformspec@lists.riscv.org

Home Messages Hashtags Subgroups

Between

and

[PATCH v3] Add system reboot extension Anup Patel #21 This patch adds SBI v0.2 compliant system reboot extension. It defines the sbi_system_reboot function which does different things based on reboot_type parameter: 1. shutdown - Power-off the entire system 2. cold reboot - Power-cycle the entire system 3. warm reboot - Power-cycle only parts of system based on SOC vendor design choices The sbi_system_reboot function defined here is also a replacement of SBI v0.1 shutdown function. Signed-off-by: Atish Patra <atish.patra@...> Signed-off-by: Anup Patel <anup.patel@...> --- riscv-sbi.adoc \| 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) diff --git a/riscv-sbi.adoc b/riscv-sbi.adoc index 8137686..a55a996 100644 --- a/riscv-sbi.adoc +++ b/riscv-sbi.adoc @@ -615,6 +615,53 @@ 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 function 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 does not return if it succeeds. + +The reboot_type parameter is 32 bit wide and has following possible values: + +[cols="<,>",options="header,compact"] +\|=== +\| Value \| Description +\| 0x00000000 \| Shutdown +\| 0x00000001 \| Cold reboot +\| 0x00000002 \| Warm reboot +\| 0x00000003 - 0xEFFFFFFF \| Reserved for future use +\| 0xF0000000 - 0xFFFFFFFF \| Vendor or platform specific reboot type +\| 0x100000000 - 2^XELN-1 \| Reserved and unusable on RV32 +\|=== + +Cold reboot results in complete power cycle of the entire system while warm +reboot depends on SOC vendor design choices. + +Returns one of the following possible SBI error codes through sbiret.error +upon failure. + +[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. +\|=== + +=== SRBT Function Listing + +[cols="<,,>",options="header,compact"] +\|=== +\| Function Name \| Function ID \| Extension ID +\| sbi_system_reboot \| 0 \| 0x53524254 +\|=== + == Experimental SBI Extension Space, Extension IDs 0x0800000 through 0x08FFFFFF No management. -- 2.17.1
More All Messages By This Member
Re: [PATCH v3] Add system reboot extension Bin Meng #22 On Mon, Apr 6, 2020 at 11:27 AM Anup Patel <anup.patel@...> wrote: This patch adds SBI v0.2 compliant system reboot extension. It defines the sbi_system_reboot function which does different things based on reboot_type parameter: 1. shutdown - Power-off the entire system 2. cold reboot - Power-cycle the entire system 3. warm reboot - Power-cycle only parts of system based on SOC vendor design choices The sbi_system_reboot function defined here is also a replacement of SBI v0.1 shutdown function. Signed-off-by: Atish Patra <atish.patra@...> Signed-off-by: Anup Patel <anup.patel@...> --- riscv-sbi.adoc \| 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) A general comment: it would be good to put the reason why a new extension is introduced, to solve what issue. Reviewed-by: Bin Meng <bmeng.cn@...>
More All Messages By This Member
Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation Jonathan Behrens <behrensj@...> #23 I think tech-unixplatformspec@... might be the right list? To address the PR itself, I'd personally prefer to have this space allocated based on SBI implementation IDs analogously to how the vendor space is allocated. It also probably makes sense to pick a different address range so experimental extension space doesn't have to move. Jonathan toggle quoted message Show quoted text On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org <abner.chang=hpe.com@...> wrote: Seems opensbi ML is no longer exist? Use software@... insrtead. From: Chang, Abner (HPS SW/FW Technologist) Sent: Thursday, April 9, 2020 4:23 PM To: Atish Patra <Atish.Patra@...>; Anup Patel <anup.patel@...> Cc: opensbi@...; Schaefer, Daniel (DualStudy) <daniel.schaefer@...> Subject: Add SBI extension space for firmware code base implementation Hi Atish and Anup, We are working on some edk2-specific SBI extension which intends to be used by upper layer edk2 drivers. We originally consider to use Vendor Extension space however vendor may have its own proprietary SBI extension as well. In order to prevent from the conflicts of SBI extension space, we propose to have a range for firmware code base. The changes look like the PR below, https://github.com/riscv/riscv-sbi-doc/pull/43 How do you think? Thanks Abner
More All Messages By This Member
Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation Abner Chang <abner.chang@...> #24 Got it, Software ML removed. Johnathan, do you mean to define it as below? Firmware Base Extension, Extension ID: 0xxxxxxxxx (FWBE) , and the SBI functions definition is firmware code base implementation-specific. This also works for me and better than to reserve a range of IDs. Thanks Abner toggle quoted message Show quoted text From: software@... [mailto:software@...] On Behalf Of Jonathan Behrens Sent: Friday, April 10, 2020 12:39 AM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Atish Patra <Atish.Patra@...>; Anup Patel <anup.patel@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; software@...; tech-unixplatformspec@... Subject: Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation I think tech-unixplatformspec@... might be the right list? To address the PR itself, I'd personally prefer to have this space allocated based on SBI implementation IDs analogously to how the vendor space is allocated. It also probably makes sense to pick a different address range so experimental extension space doesn't have to move. Jonathan On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org <abner.chang=hpe.com@...> wrote: Seems opensbi ML is no longer exist? Use software@... insrtead. From: Chang, Abner (HPS SW/FW Technologist) Sent: Thursday, April 9, 2020 4:23 PM To: Atish Patra <Atish.Patra@...>; Anup Patel <anup.patel@...> Cc: opensbi@...; Schaefer, Daniel (DualStudy) <daniel.schaefer@...> Subject: Add SBI extension space for firmware code base implementation Hi Atish and Anup, We are working on some edk2-specific SBI extension which intends to be used by upper layer edk2 drivers. We originally consider to use Vendor Extension space however vendor may have its own proprietary SBI extension as well. In order to prevent from the conflicts of SBI extension space, we propose to have a range for firmware code base. The changes look like the PR below, https://github.com/riscv/riscv-sbi-doc/pull/43 How do you think? Thanks Abner
More All Messages By This Member
Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation atishp@... #25 On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW Technologist) wrote: Got it, Software ML removed. Johnathan, do you mean to define it as below? Firmware Base Extension, Extension ID: 0xxxxxxxxx (FWBE) , and the SBI functions definition is firmware code base implementation- specific. 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 SBI extension for firmwares, you should propose it to the Unix Platform working group. We can add it to the official spec. This also works for me and better than to reserve a range of IDs. Thanks Abner From: software@... [mailto:software@...] On Behalf Of Jonathan Behrens Sent: Friday, April 10, 2020 12:39 AM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Atish Patra <Atish.Patra@...>; Anup Patel <anup.patel@... ; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; software@...; tech-unixplatformspec@... Subject: Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation I think tech-unixplatformspec@... might be the right list? To address the PR itself, I'd personally prefer to have this space allocated based on SBI implementation IDs analogously to how the vendor space is allocated. It also probably makes sense to pick a different address range so experimental extension space doesn't have to move. Jonathan On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org < abner.chang=hpe.com@...> wrote: Seems opensbi ML is no longer exist? Use software@... insrtead. From: Chang, Abner (HPS SW/FW Technologist) Sent: Thursday, April 9, 2020 4:23 PM To: Atish Patra <Atish.Patra@...>; Anup Patel < anup.patel@...> Cc: opensbi@...; Schaefer, Daniel (DualStudy) < daniel.schaefer@...> Subject: Add SBI extension space for firmware code base implementation Hi Atish and Anup, We are working on some edk2-specific SBI extension which intends to be used by upper layer edk2 drivers. We originally consider to use Vendor Extension space however vendor may have its own proprietary SBI extension as well. In order to prevent from the conflicts of SBI extension space, we propose to have a range for firmware code base. The changes look like the PR below, https://github.com/riscv/riscv-sbi-doc/pull/43 How do you think? Thanks Abner -- Regards, Atish
More All Messages By This Member
Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation Abner Chang <abner.chang@...> #26 toggle quoted message Show quoted text -----Original Message----- From: tech-unixplatformspec@... [mailto:tech- unixplatformspec@...] On Behalf Of Atish Patra Sent: Friday, April 10, 2020 11:32 AM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; behrensj@... Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech- unixplatformspec@...; Anup Patel <Anup.Patel@...> Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW Technologist) wrote: Got it, Software ML removed. Johnathan, do you mean to define it as below? Firmware Base Extension, Extension ID: 0xxxxxxxxx (FWBE) , and the SBI functions definition is firmware code base implementation- specific. I prefer this one as well. But you should pick any value within experimental range. Not quite follow this, why pick up one from experimental range? The extension ID must be in the range of 0x0800000-0x08ffffff? I am not sure about the purpose of the extension but if it has the potential to be a generic SBI extension for firmwares, you should propose it to the Unix Platform working group. We can add it to the official spec. For those SBI extension which is generic to all firmware code bases, then we should just propose it to the official SBI spec and don’t not have to go with Firmware Base Extension. Firmware Base Extension is classified to those firmware code base specific SBI, for example to load an edk2 driver into M-mode managed memory and executed in M-mode which is behaved as secured system manage mode driver. So the detail Firmware Base Extension would be defined in the separate spec and not part of official sbi spec. Occupied an SBI extension ID is to avoid conflicts. This also works for me and better than to reserve a range of IDs. Thanks Abner From: software@... [mailto:software@...] On Behalf Of Jonathan Behrens Sent: Friday, April 10, 2020 12:39 AM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Atish Patra <Atish.Patra@...>; Anup Patel <anup.patel@... ; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; software@...; tech-unixplatformspec@... Subject: Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation I think tech-unixplatformspec@... might be the right list? To address the PR itself, I'd personally prefer to have this space allocated based on SBI implementation IDs analogously to how the vendor space is allocated. It also probably makes sense to pick a different address range so experimental extension space doesn't have to move. Jonathan On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org < abner.chang=hpe.com@...> wrote: Seems opensbi ML is no longer exist? Use software@... insrtead. From: Chang, Abner (HPS SW/FW Technologist) Sent: Thursday, April 9, 2020 4:23 PM To: Atish Patra <Atish.Patra@...>; Anup Patel < anup.patel@...> Cc: opensbi@...; Schaefer, Daniel (DualStudy) < daniel.schaefer@...> Subject: Add SBI extension space for firmware code base implementation Hi Atish and Anup, We are working on some edk2-specific SBI extension which intends to be used by upper layer edk2 drivers. We originally consider to use Vendor Extension space however vendor may have its own proprietary SBI extension as well. In order to prevent from the conflicts of SBI extension space, we propose to have a range for firmware code base. The changes look like the PR below, https://github.com/riscv/riscv-sbi-doc/pull/43 How do you think? Thanks Abner -- Regards, Atish
More All Messages By This Member
Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation Jonathan Behrens <behrensj@...> #27 What I was suggesting is something like: > Implementation specific SBI extension Space, Extension IDs 0x0A000000 through 0x0AFFFFFF. Low bits from SBI Implementation ID. In this scheme, each SBI implementation would have one extension reserved for it: BBL gets 0x0A000000, OpenSBI gets 0x0A000001, Xvisor gets 0x0A000002, KVM gets 0x0A000003, etc. That might not seem like a lot of space, but each extension can have up to 2^32 different functions (including ones for version number discovery, etc.) so it shouldn't actually be limiting. As a side note, I don't think edk2 has an SBI Implementation ID assigned yet. You should just be able to ask for one and get it. Jonathan toggle quoted message Show quoted text On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> wrote: > -----Original Message----- > From: tech-unixplatformspec@... [mailto:tech- > unixplatformspec@...] On Behalf Of Atish Patra > Sent: Friday, April 10, 2020 11:32 AM > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; > behrensj@... > Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech- > unixplatformspec@...; Anup Patel <Anup.Patel@...> > Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI > extension space for firmware code base implementation > > On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW > Technologist) wrote: > > Got it, Software ML removed. > > > > Johnathan, do you mean to define it as below? > > Firmware Base Extension, Extension ID: 0xxxxxxxxx (FWBE) , and the > > SBI functions definition is firmware code base implementation- > > specific. > > > > I prefer this one as well. But you should pick any value within experimental > range. Not quite follow this, why pick up one from experimental range? The extension ID must be in the range of 0x0800000-0x08ffffff? I am not sure about the purpose of the extension but if it has the > potential to be a generic SBI extension for firmwares, you should propose it > to the Unix Platform working group. We can add it to the official spec. For those SBI extension which is generic to all firmware code bases, then we should just propose it to the official SBI spec and don’t not have to go with Firmware Base Extension. Firmware Base Extension is classified to those firmware code base specific SBI, for example to load an edk2 driver into M-mode managed memory and executed in M-mode which is behaved as secured system manage mode driver. So the detail Firmware Base Extension would be defined in the separate spec and not part of official sbi spec. Occupied an SBI extension ID is to avoid conflicts. > > > This also works for me and better than to reserve a range of IDs. > > Thanks > > Abner > > > > From: software@... [mailto:software@...] On > > Behalf Of Jonathan Behrens > > Sent: Friday, April 10, 2020 12:39 AM > > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> > > Cc: Atish Patra <Atish.Patra@...>; Anup Patel > <anup.patel@... > > >; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; > > software@...; tech-unixplatformspec@... > > Subject: Re: [RISC-V] [software] Add SBI extension space for firmware > > code base implementation > > > > I think tech-unixplatformspec@... might be the right list? > > > > To address the PR itself, I'd personally prefer to have this space > > allocated based on SBI implementation IDs analogously to how the > > vendor space is allocated. It also probably makes sense to pick a > > different address range so experimental extension space doesn't have > > to move. > > > > Jonathan > > > > On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org < > > abner.chang=hpe.com@...> wrote: > > > Seems opensbi ML is no longer exist? Use software@... > > > insrtead. > > > > > > From: Chang, Abner (HPS SW/FW Technologist) > > > Sent: Thursday, April 9, 2020 4:23 PM > > > To: Atish Patra <Atish.Patra@...>; Anup Patel < > > > anup.patel@...> > > > Cc: opensbi@...; Schaefer, Daniel (DualStudy) < > > > daniel.schaefer@...> > > > Subject: Add SBI extension space for firmware code base > > > implementation > > > > > > Hi Atish and Anup, > > > We are working on some edk2-specific SBI extension which intends to > > > be used by upper layer edk2 drivers. We originally consider to use > > > Vendor Extension space however vendor may have its own proprietary > > > SBI extension as well. In order to prevent from the conflicts of SBI > > > extension space, we propose to have a range for firmware code base. > > > The changes look like the PR below, > > > > > > https://github.com/riscv/riscv-sbi-doc/pull/43 > > > > > > How do you think? > > > Thanks > > > Abner > > > > > > -- > Regards, > Atish > >
More All Messages By This Member
Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation Anup Patel #28 I agree with Jonathan's proposal. Let's have SBI FW extension ID depend on SBI implementation ID. We can target this for SBI v0.3 spec along with System Reboot extension. Regards, Anup Sent from Outlook Mobile toggle quoted message Show quoted text From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Jonathan Behrens <behrensj@...> Sent: Friday, April 10, 2020 7:14:45 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... <tech-unixplatformspec@...>; Anup Patel <Anup.Patel@...> Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation What I was suggesting is something like: > Implementation specific SBI extension Space, Extension IDs 0x0A000000 through 0x0AFFFFFF. Low bits from SBI Implementation ID. In this scheme, each SBI implementation would have one extension reserved for it: BBL gets 0x0A000000, OpenSBI gets 0x0A000001, Xvisor gets 0x0A000002, KVM gets 0x0A000003, etc. That might not seem like a lot of space, but each extension can have up to 2^32 different functions (including ones for version number discovery, etc.) so it shouldn't actually be limiting. As a side note, I don't think edk2 has an SBI Implementation ID assigned yet. You should just be able to ask for one and get it. Jonathan On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> wrote: > -----Original Message----- > From: tech-unixplatformspec@... [mailto:tech- > unixplatformspec@...] On Behalf Of Atish Patra > Sent: Friday, April 10, 2020 11:32 AM > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; > behrensj@... > Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech- > unixplatformspec@...; Anup Patel <Anup.Patel@...> > Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI > extension space for firmware code base implementation > > On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW > Technologist) wrote: > > Got it, Software ML removed. > > > > Johnathan, do you mean to define it as below? > > Firmware Base Extension, Extension ID: 0xxxxxxxxx (FWBE) , and the > > SBI functions definition is firmware code base implementation- > > specific. > > > > I prefer this one as well. But you should pick any value within experimental > range. Not quite follow this, why pick up one from experimental range? The extension ID must be in the range of 0x0800000-0x08ffffff? I am not sure about the purpose of the extension but if it has the > potential to be a generic SBI extension for firmwares, you should propose it > to the Unix Platform working group. We can add it to the official spec. For those SBI extension which is generic to all firmware code bases, then we should just propose it to the official SBI spec and don’t not have to go with Firmware Base Extension. Firmware Base Extension is classified to those firmware code base specific SBI, for example to load an edk2 driver into M-mode managed memory and executed in M-mode which is behaved as secured system manage mode driver. So the detail Firmware Base Extension would be defined in the separate spec and not part of official sbi spec. Occupied an SBI extension ID is to avoid conflicts. > > > This also works for me and better than to reserve a range of IDs. > > Thanks > > Abner > > > > From: software@... [mailto:software@...] On > > Behalf Of Jonathan Behrens > > Sent: Friday, April 10, 2020 12:39 AM > > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> > > Cc: Atish Patra <Atish.Patra@...>; Anup Patel > <anup.patel@... > > >; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; > > software@...; tech-unixplatformspec@... > > Subject: Re: [RISC-V] [software] Add SBI extension space for firmware > > code base implementation > > > > I think tech-unixplatformspec@... might be the right list? > > > > To address the PR itself, I'd personally prefer to have this space > > allocated based on SBI implementation IDs analogously to how the > > vendor space is allocated. It also probably makes sense to pick a > > different address range so experimental extension space doesn't have > > to move. > > > > Jonathan > > > > On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org < > > abner.chang=hpe.com@...> wrote: > > > Seems opensbi ML is no longer exist? Use software@... > > > insrtead. > > > > > > From: Chang, Abner (HPS SW/FW Technologist) > > > Sent: Thursday, April 9, 2020 4:23 PM > > > To: Atish Patra <Atish.Patra@...>; Anup Patel < > > > anup.patel@...> > > > Cc: opensbi@...; Schaefer, Daniel (DualStudy) < > > > daniel.schaefer@...> > > > Subject: Add SBI extension space for firmware code base > > > implementation > > > > > > Hi Atish and Anup, > > > We are working on some edk2-specific SBI extension which intends to > > > be used by upper layer edk2 drivers. We originally consider to use > > > Vendor Extension space however vendor may have its own proprietary > > > SBI extension as well. In order to prevent from the conflicts of SBI > > > extension space, we propose to have a range for firmware code base. > > > The changes look like the PR below, > > > > > > https://github.com/riscv/riscv-sbi-doc/pull/43 > > > > > > How do you think? > > > Thanks > > > Abner > > > > > > -- > Regards, > Atish > >
More All Messages By This Member
Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation Abner Chang <abner.chang@...> #29 Cool. This works for edk2. I will have another PR for this. For edk2, we will request a new SBI implementation ID (4) and register firmware code base extension SBI in edk2 SEC phase. toggle quoted message Show quoted text From: Anup Patel [mailto:Anup.Patel@...] Sent: Friday, April 10, 2020 11:14 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation I agree with Jonathan's proposal. Let's have SBI FW extension ID depend on SBI implementation ID. We can target this for SBI v0.3 spec along with System Reboot extension. Regards, Anup Sent from Outlook Mobile From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Jonathan Behrens <behrensj@...> Sent: Friday, April 10, 2020 7:14:45 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... <tech-unixplatformspec@...>; Anup Patel <Anup.Patel@...> Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation What I was suggesting is something like: > Implementation specific SBI extension Space, Extension IDs 0x0A000000 through 0x0AFFFFFF. Low bits from SBI Implementation ID. In this scheme, each SBI implementation would have one extension reserved for it: BBL gets 0x0A000000, OpenSBI gets 0x0A000001, Xvisor gets 0x0A000002, KVM gets 0x0A000003, etc. That might not seem like a lot of space, but each extension can have up to 2^32 different functions (including ones for version number discovery, etc.) so it shouldn't actually be limiting. As a side note, I don't think edk2 has an SBI Implementation ID assigned yet. You should just be able to ask for one and get it. Jonathan On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> wrote: > -----Original Message----- > From: tech-unixplatformspec@... [mailto:tech- > unixplatformspec@...] On Behalf Of Atish Patra > Sent: Friday, April 10, 2020 11:32 AM > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; > behrensj@... > Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech- > unixplatformspec@...; Anup Patel <Anup.Patel@...> > Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI > extension space for firmware code base implementation > > On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW > Technologist) wrote: > > Got it, Software ML removed. > > > > Johnathan, do you mean to define it as below? > > Firmware Base Extension, Extension ID: 0xxxxxxxxx (FWBE) , and the > > SBI functions definition is firmware code base implementation- > > specific. > > > > I prefer this one as well. But you should pick any value within experimental > range. Not quite follow this, why pick up one from experimental range? The extension ID must be in the range of 0x0800000-0x08ffffff? I am not sure about the purpose of the extension but if it has the > potential to be a generic SBI extension for firmwares, you should propose it > to the Unix Platform working group. We can add it to the official spec. For those SBI extension which is generic to all firmware code bases, then we should just propose it to the official SBI spec and don’t not have to go with Firmware Base Extension. Firmware Base Extension is classified to those firmware code base specific SBI, for example to load an edk2 driver into M-mode managed memory and executed in M-mode which is behaved as secured system manage mode driver. So the detail Firmware Base Extension would be defined in the separate spec and not part of official sbi spec. Occupied an SBI extension ID is to avoid conflicts. > > > This also works for me and better than to reserve a range of IDs. > > Thanks > > Abner > > > > From: software@... [mailto:software@...] On > > Behalf Of Jonathan Behrens > > Sent: Friday, April 10, 2020 12:39 AM > > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> > > Cc: Atish Patra <Atish.Patra@...>; Anup Patel > <anup.patel@... > > >; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; > > software@...; tech-unixplatformspec@... > > Subject: Re: [RISC-V] [software] Add SBI extension space for firmware > > code base implementation > > > > I think tech-unixplatformspec@... might be the right list? > > > > To address the PR itself, I'd personally prefer to have this space > > allocated based on SBI implementation IDs analogously to how the > > vendor space is allocated. It also probably makes sense to pick a > > different address range so experimental extension space doesn't have > > to move. > > > > Jonathan > > > > On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org < > > abner.chang=hpe.com@...> wrote: > > > Seems opensbi ML is no longer exist? Use software@... > > > insrtead. > > > > > > From: Chang, Abner (HPS SW/FW Technologist) > > > Sent: Thursday, April 9, 2020 4:23 PM > > > To: Atish Patra <Atish.Patra@...>; Anup Patel < > > > anup.patel@...> > > > Cc: opensbi@...; Schaefer, Daniel (DualStudy) < > > > daniel.schaefer@...> > > > Subject: Add SBI extension space for firmware code base > > > implementation > > > > > > Hi Atish and Anup, > > > We are working on some edk2-specific SBI extension which intends to > > > be used by upper layer edk2 drivers. We originally consider to use > > > Vendor Extension space however vendor may have its own proprietary > > > SBI extension as well. In order to prevent from the conflicts of SBI > > > extension space, we propose to have a range for firmware code base. > > > The changes look like the PR below, > > > > > > https://github.com/riscv/riscv-sbi-doc/pull/43 > > > > > > How do you think? > > > Thanks > > > Abner > > > > > > -- > Regards, > Atish > >
More All Messages By This Member
Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation atishp@... #30 On Fri, 2020-04-10 at 06:23 +0000, Abner Chang wrote: -----Original Message----- From: tech-unixplatformspec@... [mailto:tech- unixplatformspec@...] On Behalf Of Atish Patra Sent: Friday, April 10, 2020 11:32 AM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; behrensj@... Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech- unixplatformspec@...; Anup Patel <Anup.Patel@...> Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW Technologist) wrote: Got it, Software ML removed. Johnathan, do you mean to define it as below? Firmware Base Extension, Extension ID: 0xxxxxxxxx (FWBE) , and the SBI functions definition is firmware code base implementation- specific. I prefer this one as well. But you should pick any value within experimental range. Not quite follow this, why pick up one from experimental range? The extension ID must be in the range of 0x0800000-0x08ffffff? I am not sure about the purpose of the extension but if it has the potential to be a generic SBI extension for firmwares, you should propose it to the Unix Platform working group. We can add it to the official spec. For those SBI extension which is generic to all firmware code bases, then we should just propose it to the official SBI spec and don’t not have to go with Firmware Base Extension. Firmware Base Extension is classified to those firmware code base specific SBI, for example to load an edk2 driver into M-mode managed memory and executed in M-mode which is behaved as secured system manage mode driver. So the detail Firmware Base Extension would be defined in the separate spec and not part of official sbi spec. Occupied an SBI extension ID is to avoid conflicts. 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 SBI implementation ID. This also works for me and better than to reserve a range of IDs. Thanks Abner From: software@... [mailto:software@...] On Behalf Of Jonathan Behrens Sent: Friday, April 10, 2020 12:39 AM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Atish Patra <Atish.Patra@...>; Anup Patel <anup.patel@... ; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; software@...; tech-unixplatformspec@... Subject: Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation I think tech-unixplatformspec@... might be the right list? To address the PR itself, I'd personally prefer to have this space allocated based on SBI implementation IDs analogously to how the vendor space is allocated. It also probably makes sense to pick a different address range so experimental extension space doesn't have to move. Jonathan On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org < abner.chang=hpe.com@...> wrote: Seems opensbi ML is no longer exist? Use software@... insrtead. From: Chang, Abner (HPS SW/FW Technologist) Sent: Thursday, April 9, 2020 4:23 PM To: Atish Patra <Atish.Patra@...>; Anup Patel < anup.patel@...> Cc: opensbi@...; Schaefer, Daniel (DualStudy) < daniel.schaefer@...> Subject: Add SBI extension space for firmware code base implementation Hi Atish and Anup, We are working on some edk2-specific SBI extension which intends to be used by upper layer edk2 drivers. We originally consider to use Vendor Extension space however vendor may have its own proprietary SBI extension as well. In order to prevent from the conflicts of SBI extension space, we propose to have a range for firmware code base. The changes look like the PR below, https://github.com/riscv/riscv-sbi-doc/pull/43 How do you think? Thanks Abner -- Regards, Atish -- Regards, Atish
More All Messages By This Member
Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation Abner Chang <abner.chang@...> #31 This is the PR according to the discussion we had in mail thread. However you may see some confusions from this change. https://github.com/riscv/riscv-sbi-doc/pull/43/commits/e208f23c64f7a6a4be47d6d0ca852433107f6cf4 - EDK2 is a SBI implementation? Actually edk2 is not one of the SBI implementations, edk2 fully compliant with OpenSBI and additionally provides the firmware code base SBI extension. We can explain this in the external Firmware code base SBI extension spec (edk2 RISC-V OpenSBI spec), says edk2 SBI implementation actually goes alone with SBI OpenSBI implementation. - What is the SBI implementation version associated with EDK2 SBI implementation? This is another confusion because the major SBI implementation is OpenSBI. We also can explain this in the external Firmware code base SBI extension spec, says edk2 SBI implementation version is the version of SBI OpenSBI implementation. Apart from the above proposal, can we have more clear definitions for Firmware code base SBI extension in SBI spec instead of fixing those confusions in the extern spec? The below proposal makes more sense? - Define another table for firmware code base, e.g. SBI Firmware Code Base ID. In the table we can have edk2, uboot, Coreboot and etc.. - Create a new SBI Base function, sbi_get_firmware_code_base_id() which returns the SBI Firmware Code Base ID. - Create a new SBI Base function, sbi_get_firmware_code_base_version() for the version control of firmware code base SBI extension - Firmware code base SBI extension is from 0xA000000 to 0xAffffff with Firmware Code Base ID in low bits. I feel the later one makes more sense and clear, how do you think? Abner toggle quoted message Show quoted text From: tech-unixplatformspec@... [mailto:tech-unixplatformspec@...] On Behalf Of Abner Chang Sent: Saturday, April 11, 2020 12:08 AM To: Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Cool. This works for edk2. I will have another PR for this. For edk2, we will request a new SBI implementation ID (4) and register firmware code base extension SBI in edk2 SEC phase. From: Anup Patel [mailto:Anup.Patel@...] Sent: Friday, April 10, 2020 11:14 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation I agree with Jonathan's proposal. Let's have SBI FW extension ID depend on SBI implementation ID. We can target this for SBI v0.3 spec along with System Reboot extension. Regards, Anup Sent from Outlook Mobile From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Jonathan Behrens <behrensj@...> Sent: Friday, April 10, 2020 7:14:45 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... <tech-unixplatformspec@...>; Anup Patel <Anup.Patel@...> Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation What I was suggesting is something like: > Implementation specific SBI extension Space, Extension IDs 0x0A000000 through 0x0AFFFFFF. Low bits from SBI Implementation ID. In this scheme, each SBI implementation would have one extension reserved for it: BBL gets 0x0A000000, OpenSBI gets 0x0A000001, Xvisor gets 0x0A000002, KVM gets 0x0A000003, etc. That might not seem like a lot of space, but each extension can have up to 2^32 different functions (including ones for version number discovery, etc.) so it shouldn't actually be limiting. As a side note, I don't think edk2 has an SBI Implementation ID assigned yet. You should just be able to ask for one and get it. Jonathan On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> wrote: > -----Original Message----- > From: tech-unixplatformspec@... [mailto:tech- > unixplatformspec@...] On Behalf Of Atish Patra > Sent: Friday, April 10, 2020 11:32 AM > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; > behrensj@... > Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech- > unixplatformspec@...; Anup Patel <Anup.Patel@...> > Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI > extension space for firmware code base implementation > > On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW > Technologist) wrote: > > Got it, Software ML removed. > > > > Johnathan, do you mean to define it as below? > > Firmware Base Extension, Extension ID: 0xxxxxxxxx (FWBE) , and the > > SBI functions definition is firmware code base implementation- > > specific. > > > > I prefer this one as well. But you should pick any value within experimental > range. Not quite follow this, why pick up one from experimental range? The extension ID must be in the range of 0x0800000-0x08ffffff? I am not sure about the purpose of the extension but if it has the > potential to be a generic SBI extension for firmwares, you should propose it > to the Unix Platform working group. We can add it to the official spec. For those SBI extension which is generic to all firmware code bases, then we should just propose it to the official SBI spec and don’t not have to go with Firmware Base Extension. Firmware Base Extension is classified to those firmware code base specific SBI, for example to load an edk2 driver into M-mode managed memory and executed in M-mode which is behaved as secured system manage mode driver. So the detail Firmware Base Extension would be defined in the separate spec and not part of official sbi spec. Occupied an SBI extension ID is to avoid conflicts. > > > This also works for me and better than to reserve a range of IDs. > > Thanks > > Abner > > > > From: software@... [mailto:software@...] On > > Behalf Of Jonathan Behrens > > Sent: Friday, April 10, 2020 12:39 AM > > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> > > Cc: Atish Patra <Atish.Patra@...>; Anup Patel > <anup.patel@... > > >; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; > > software@...; tech-unixplatformspec@... > > Subject: Re: [RISC-V] [software] Add SBI extension space for firmware > > code base implementation > > > > I think tech-unixplatformspec@... might be the right list? > > > > To address the PR itself, I'd personally prefer to have this space > > allocated based on SBI implementation IDs analogously to how the > > vendor space is allocated. It also probably makes sense to pick a > > different address range so experimental extension space doesn't have > > to move. > > > > Jonathan > > > > On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org < > > abner.chang=hpe.com@...> wrote: > > > Seems opensbi ML is no longer exist? Use software@... > > > insrtead. > > > > > > From: Chang, Abner (HPS SW/FW Technologist) > > > Sent: Thursday, April 9, 2020 4:23 PM > > > To: Atish Patra <Atish.Patra@...>; Anup Patel < > > > anup.patel@...> > > > Cc: opensbi@...; Schaefer, Daniel (DualStudy) < > > > daniel.schaefer@...> > > > Subject: Add SBI extension space for firmware code base > > > implementation > > > > > > Hi Atish and Anup, > > > We are working on some edk2-specific SBI extension which intends to > > > be used by upper layer edk2 drivers. We originally consider to use > > > Vendor Extension space however vendor may have its own proprietary > > > SBI extension as well. In order to prevent from the conflicts of SBI > > > extension space, we propose to have a range for firmware code base. > > > The changes look like the PR below, > > > > > > https://github.com/riscv/riscv-sbi-doc/pull/43 > > > > > > How do you think? > > > Thanks > > > Abner > > > > > > -- > Regards, > Atish > >
More All Messages By This Member
Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation Anup Patel #32 Hi Abner, We have two options here: EDK2 can use 0xA000000 + <opensbi_imp_id> as SBI Extension OpenSBI provides a way to EDK2 for overriding SBI implementation ID (preferably using some API) If we go with Option1 above then we don’t need separate SBI implementation ID for EDK2. Let us know what you guys think in this context. Regards, Anup toggle quoted message Show quoted text From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Sent: 12 April 2020 14:50 To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation This is the PR according to the discussion we had in mail thread. However you may see some confusions from this change. https://github.com/riscv/riscv-sbi-doc/pull/43/commits/e208f23c64f7a6a4be47d6d0ca852433107f6cf4 EDK2 is a SBI implementation? Actually edk2 is not one of the SBI implementations, edk2 fully compliant with OpenSBI and additionally provides the firmware code base SBI extension. We can explain this in the external Firmware code base SBI extension spec (edk2 RISC-V OpenSBI spec), says edk2 SBI implementation actually goes alone with SBI OpenSBI implementation. What is the SBI implementation version associated with EDK2 SBI implementation? This is another confusion because the major SBI implementation is OpenSBI. We also can explain this in the external Firmware code base SBI extension spec, says edk2 SBI implementation version is the version of SBI OpenSBI implementation. Apart from the above proposal, can we have more clear definitions for Firmware code base SBI extension in SBI spec instead of fixing those confusions in the extern spec? The below proposal makes more sense? Define another table for firmware code base, e.g. SBI Firmware Code Base ID. In the table we can have edk2, uboot, Coreboot and etc.. Create a new SBI Base function, sbi_get_firmware_code_base_id() which returns the SBI Firmware Code Base ID. Create a new SBI Base function, sbi_get_firmware_code_base_version() for the version control of firmware code base SBI extension Firmware code base SBI extension is from 0xA000000 to 0xAffffff with Firmware Code Base ID in low bits. I feel the later one makes more sense and clear, how do you think? Abner From: tech-unixplatformspec@... [mailto:tech-unixplatformspec@...] On Behalf Of Abner Chang Sent: Saturday, April 11, 2020 12:08 AM To: Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Cool. This works for edk2. I will have another PR for this. For edk2, we will request a new SBI implementation ID (4) and register firmware code base extension SBI in edk2 SEC phase. From: Anup Patel [mailto:Anup.Patel@...] Sent: Friday, April 10, 2020 11:14 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation I agree with Jonathan's proposal. Let's have SBI FW extension ID depend on SBI implementation ID. We can target this for SBI v0.3 spec along with System Reboot extension. Regards, Anup Sent from Outlook Mobile From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Jonathan Behrens <behrensj@...> Sent: Friday, April 10, 2020 7:14:45 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... <tech-unixplatformspec@...>; Anup Patel <Anup.Patel@...> Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation What I was suggesting is something like: > Implementation specific SBI extension Space, Extension IDs 0x0A000000 through 0x0AFFFFFF. Low bits from SBI Implementation ID. In this scheme, each SBI implementation would have one extension reserved for it: BBL gets 0x0A000000, OpenSBI gets 0x0A000001, Xvisor gets 0x0A000002, KVM gets 0x0A000003, etc. That might not seem like a lot of space, but each extension can have up to 2^32 different functions (including ones for version number discovery, etc.) so it shouldn't actually be limiting. As a side note, I don't think edk2 has an SBI Implementation ID assigned yet. You should just be able to ask for one and get it. Jonathan On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> wrote: > -----Original Message----- > From: tech-unixplatformspec@... [mailto:tech- > unixplatformspec@...] On Behalf Of Atish Patra > Sent: Friday, April 10, 2020 11:32 AM > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; > behrensj@... > Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech- > unixplatformspec@...; Anup Patel <Anup.Patel@...> > Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI > extension space for firmware code base implementation > > On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW > Technologist) wrote: > > Got it, Software ML removed. > > > > Johnathan, do you mean to define it as below? > > Firmware Base Extension, Extension ID: 0xxxxxxxxx (FWBE) , and the > > SBI functions definition is firmware code base implementation- > > specific. > > > > I prefer this one as well. But you should pick any value within experimental > range. Not quite follow this, why pick up one from experimental range? The extension ID must be in the range of 0x0800000-0x08ffffff? I am not sure about the purpose of the extension but if it has the > potential to be a generic SBI extension for firmwares, you should propose it > to the Unix Platform working group. We can add it to the official spec. For those SBI extension which is generic to all firmware code bases, then we should just propose it to the official SBI spec and don’t not have to go with Firmware Base Extension. Firmware Base Extension is classified to those firmware code base specific SBI, for example to load an edk2 driver into M-mode managed memory and executed in M-mode which is behaved as secured system manage mode driver. So the detail Firmware Base Extension would be defined in the separate spec and not part of official sbi spec. Occupied an SBI extension ID is to avoid conflicts. > > > This also works for me and better than to reserve a range of IDs. > > Thanks > > Abner > > > > From: software@... [mailto:software@...] On > > Behalf Of Jonathan Behrens > > Sent: Friday, April 10, 2020 12:39 AM > > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> > > Cc: Atish Patra <Atish.Patra@...>; Anup Patel > <anup.patel@... > > >; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; > > software@...; tech-unixplatformspec@... > > Subject: Re: [RISC-V] [software] Add SBI extension space for firmware > > code base implementation > > > > I think tech-unixplatformspec@... might be the right list? > > > > To address the PR itself, I'd personally prefer to have this space > > allocated based on SBI implementation IDs analogously to how the > > vendor space is allocated. It also probably makes sense to pick a > > different address range so experimental extension space doesn't have > > to move. > > > > Jonathan > > > > On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org < > > abner.chang=hpe.com@...> wrote: > > > Seems opensbi ML is no longer exist? Use software@... > > > insrtead. > > > > > > From: Chang, Abner (HPS SW/FW Technologist) > > > Sent: Thursday, April 9, 2020 4:23 PM > > > To: Atish Patra <Atish.Patra@...>; Anup Patel < > > > anup.patel@...> > > > Cc: opensbi@...; Schaefer, Daniel (DualStudy) < > > > daniel.schaefer@...> > > > Subject: Add SBI extension space for firmware code base > > > implementation > > > > > > Hi Atish and Anup, > > > We are working on some edk2-specific SBI extension which intends to > > > be used by upper layer edk2 drivers. We originally consider to use > > > Vendor Extension space however vendor may have its own proprietary > > > SBI extension as well. In order to prevent from the conflicts of SBI > > > extension space, we propose to have a range for firmware code base. > > > The changes look like the PR below, > > > > > > https://github.com/riscv/riscv-sbi-doc/pull/43 > > > > > > How do you think? > > > Thanks > > > Abner > > > > > > -- > Regards, > Atish > >
More All Messages By This Member
Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation Jonathan Behrens <behrensj@...> #33 Is the code for the extension you want to add going to live in the OpenSBI repository or in the EDK2 repository? If I understand correctly, it would live in the EDK2 repository, meaning that your implementation would actually be downstream from OpenSBI and should have its own implementation ID. If you did this then it seems like everything else would fall out nicely: you could decide on version numbers independently of OpenSBI, there'd be no need for a separate set of firmware IDs, and you'd have full control over all the details of your extension. Jonathan toggle quoted message Show quoted text On Sun, Apr 12, 2020 at 8:18 AM Anup Patel <Anup.Patel@...> wrote: Hi Abner, We have two options here: EDK2 can use 0xA000000 + <opensbi_imp_id> as SBI Extension OpenSBI provides a way to EDK2 for overriding SBI implementation ID (preferably using some API) If we go with Option1 above then we don’t need separate SBI implementation ID for EDK2. Let us know what you guys think in this context. Regards, Anup From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Sent: 12 April 2020 14:50 To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation This is the PR according to the discussion we had in mail thread. However you may see some confusions from this change. https://github.com/riscv/riscv-sbi-doc/pull/43/commits/e208f23c64f7a6a4be47d6d0ca852433107f6cf4 EDK2 is a SBI implementation? Actually edk2 is not one of the SBI implementations, edk2 fully compliant with OpenSBI and additionally provides the firmware code base SBI extension. We can explain this in the external Firmware code base SBI extension spec (edk2 RISC-V OpenSBI spec), says edk2 SBI implementation actually goes alone with SBI OpenSBI implementation. What is the SBI implementation version associated with EDK2 SBI implementation? This is another confusion because the major SBI implementation is OpenSBI. We also can explain this in the external Firmware code base SBI extension spec, says edk2 SBI implementation version is the version of SBI OpenSBI implementation. Apart from the above proposal, can we have more clear definitions for Firmware code base SBI extension in SBI spec instead of fixing those confusions in the extern spec? The below proposal makes more sense? Define another table for firmware code base, e.g. SBI Firmware Code Base ID. In the table we can have edk2, uboot, Coreboot and etc.. Create a new SBI Base function, sbi_get_firmware_code_base_id() which returns the SBI Firmware Code Base ID. Create a new SBI Base function, sbi_get_firmware_code_base_version() for the version control of firmware code base SBI extension Firmware code base SBI extension is from 0xA000000 to 0xAffffff with Firmware Code Base ID in low bits. I feel the later one makes more sense and clear, how do you think? Abner From: tech-unixplatformspec@... [mailto:tech-unixplatformspec@...] On Behalf Of Abner Chang Sent: Saturday, April 11, 2020 12:08 AM To: Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Cool. This works for edk2. I will have another PR for this. For edk2, we will request a new SBI implementation ID (4) and register firmware code base extension SBI in edk2 SEC phase. From: Anup Patel [mailto:Anup.Patel@...] Sent: Friday, April 10, 2020 11:14 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation I agree with Jonathan's proposal. Let's have SBI FW extension ID depend on SBI implementation ID. We can target this for SBI v0.3 spec along with System Reboot extension. Regards, Anup Sent from Outlook Mobile From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Jonathan Behrens <behrensj@...> Sent: Friday, April 10, 2020 7:14:45 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... <tech-unixplatformspec@...>; Anup Patel <Anup.Patel@...> Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation What I was suggesting is something like: > Implementation specific SBI extension Space, Extension IDs 0x0A000000 through 0x0AFFFFFF. Low bits from SBI Implementation ID. In this scheme, each SBI implementation would have one extension reserved for it: BBL gets 0x0A000000, OpenSBI gets 0x0A000001, Xvisor gets 0x0A000002, KVM gets 0x0A000003, etc. That might not seem like a lot of space, but each extension can have up to 2^32 different functions (including ones for version number discovery, etc.) so it shouldn't actually be limiting. As a side note, I don't think edk2 has an SBI Implementation ID assigned yet. You should just be able to ask for one and get it. Jonathan On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> wrote: > -----Original Message----- > From: tech-unixplatformspec@... [mailto:tech- > unixplatformspec@...] On Behalf Of Atish Patra > Sent: Friday, April 10, 2020 11:32 AM > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; > behrensj@... > Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech- > unixplatformspec@...; Anup Patel <Anup.Patel@...> > Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI > extension space for firmware code base implementation > > On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW > Technologist) wrote: > > Got it, Software ML removed. > > > > Johnathan, do you mean to define it as below? > > Firmware Base Extension, Extension ID: 0xxxxxxxxx (FWBE) , and the > > SBI functions definition is firmware code base implementation- > > specific. > > > > I prefer this one as well. But you should pick any value within experimental > range. Not quite follow this, why pick up one from experimental range? The extension ID must be in the range of 0x0800000-0x08ffffff? I am not sure about the purpose of the extension but if it has the > potential to be a generic SBI extension for firmwares, you should propose it > to the Unix Platform working group. We can add it to the official spec. For those SBI extension which is generic to all firmware code bases, then we should just propose it to the official SBI spec and don’t not have to go with Firmware Base Extension. Firmware Base Extension is classified to those firmware code base specific SBI, for example to load an edk2 driver into M-mode managed memory and executed in M-mode which is behaved as secured system manage mode driver. So the detail Firmware Base Extension would be defined in the separate spec and not part of official sbi spec. Occupied an SBI extension ID is to avoid conflicts. > > > This also works for me and better than to reserve a range of IDs. > > Thanks > > Abner > > > > From: software@... [mailto:software@...] On > > Behalf Of Jonathan Behrens > > Sent: Friday, April 10, 2020 12:39 AM > > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> > > Cc: Atish Patra <Atish.Patra@...>; Anup Patel > <anup.patel@... > > >; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; > > software@...; tech-unixplatformspec@... > > Subject: Re: [RISC-V] [software] Add SBI extension space for firmware > > code base implementation > > > > I think tech-unixplatformspec@... might be the right list? > > > > To address the PR itself, I'd personally prefer to have this space > > allocated based on SBI implementation IDs analogously to how the > > vendor space is allocated. It also probably makes sense to pick a > > different address range so experimental extension space doesn't have > > to move. > > > > Jonathan > > > > On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org < > > abner.chang=hpe.com@...> wrote: > > > Seems opensbi ML is no longer exist? Use software@... > > > insrtead. > > > > > > From: Chang, Abner (HPS SW/FW Technologist) > > > Sent: Thursday, April 9, 2020 4:23 PM > > > To: Atish Patra <Atish.Patra@...>; Anup Patel < > > > anup.patel@...> > > > Cc: opensbi@...; Schaefer, Daniel (DualStudy) < > > > daniel.schaefer@...> > > > Subject: Add SBI extension space for firmware code base > > > implementation > > > > > > Hi Atish and Anup, > > > We are working on some edk2-specific SBI extension which intends to > > > be used by upper layer edk2 drivers. We originally consider to use > > > Vendor Extension space however vendor may have its own proprietary > > > SBI extension as well. In order to prevent from the conflicts of SBI > > > extension space, we propose to have a range for firmware code base. > > > The changes look like the PR below, > > > > > > https://github.com/riscv/riscv-sbi-doc/pull/43 > > > > > > How do you think? > > > Thanks > > > Abner > > > > > > -- > Regards, > Atish > >
More All Messages By This Member
Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation Abner Chang <abner.chang@...> #34 Basically OpenSBI is a git submodule of edk2 and we don’t make any modification on it, we just build OpenSBI on edk2 build environment. Yes, edk2 will have its own control of extensions for those firmware code base specific functions. One think we concern about is the conflict of extension ID with vendor extension. Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now. We don’t have to add edk2 as one of SBI implementation and this can also prevent from extension ID conflict with vendor’s ones. We can just take #1 opinion. Any other comments? Will let you know if we miss something later. Thanks to all for supporting ekd2. Abner toggle quoted message Show quoted text From: Jonathan Behrens [mailto:behrensj@...] Sent: Sunday, April 12, 2020 10:19 PM To: Anup Patel <Anup.Patel@...> Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Is the code for the extension you want to add going to live in the OpenSBI repository or in the EDK2 repository? If I understand correctly, it would live in the EDK2 repository, meaning that your implementation would actually be downstream from OpenSBI and should have its own implementation ID. If you did this then it seems like everything else would fall out nicely: you could decide on version numbers independently of OpenSBI, there'd be no need for a separate set of firmware IDs, and you'd have full control over all the details of your extension. Jonathan On Sun, Apr 12, 2020 at 8:18 AM Anup Patel <Anup.Patel@...> wrote: Hi Abner, We have two options here: EDK2 can use 0xA000000 + <opensbi_imp_id> as SBI Extension OpenSBI provides a way to EDK2 for overriding SBI implementation ID (preferably using some API) If we go with Option1 above then we don’t need separate SBI implementation ID for EDK2. Let us know what you guys think in this context. Regards, Anup From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Sent: 12 April 2020 14:50 To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation This is the PR according to the discussion we had in mail thread. However you may see some confusions from this change. https://github.com/riscv/riscv-sbi-doc/pull/43/commits/e208f23c64f7a6a4be47d6d0ca852433107f6cf4 EDK2 is a SBI implementation? Actually edk2 is not one of the SBI implementations, edk2 fully compliant with OpenSBI and additionally provides the firmware code base SBI extension. We can explain this in the external Firmware code base SBI extension spec (edk2 RISC-V OpenSBI spec), says edk2 SBI implementation actually goes alone with SBI OpenSBI implementation. What is the SBI implementation version associated with EDK2 SBI implementation? This is another confusion because the major SBI implementation is OpenSBI. We also can explain this in the external Firmware code base SBI extension spec, says edk2 SBI implementation version is the version of SBI OpenSBI implementation. Apart from the above proposal, can we have more clear definitions for Firmware code base SBI extension in SBI spec instead of fixing those confusions in the extern spec? The below proposal makes more sense? Define another table for firmware code base, e.g. SBI Firmware Code Base ID. In the table we can have edk2, uboot, Coreboot and etc.. Create a new SBI Base function, sbi_get_firmware_code_base_id() which returns the SBI Firmware Code Base ID. Create a new SBI Base function, sbi_get_firmware_code_base_version() for the version control of firmware code base SBI extension Firmware code base SBI extension is from 0xA000000 to 0xAffffff with Firmware Code Base ID in low bits. I feel the later one makes more sense and clear, how do you think? Abner From: tech-unixplatformspec@... [mailto:tech-unixplatformspec@...] On Behalf Of Abner Chang Sent: Saturday, April 11, 2020 12:08 AM To: Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Cool. This works for edk2. I will have another PR for this. For edk2, we will request a new SBI implementation ID (4) and register firmware code base extension SBI in edk2 SEC phase. From: Anup Patel [mailto:Anup.Patel@...] Sent: Friday, April 10, 2020 11:14 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation I agree with Jonathan's proposal. Let's have SBI FW extension ID depend on SBI implementation ID. We can target this for SBI v0.3 spec along with System Reboot extension. Regards, Anup Sent from Outlook Mobile From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Jonathan Behrens <behrensj@...> Sent: Friday, April 10, 2020 7:14:45 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... <tech-unixplatformspec@...>; Anup Patel <Anup.Patel@...> Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation What I was suggesting is something like: > Implementation specific SBI extension Space, Extension IDs 0x0A000000 through 0x0AFFFFFF. Low bits from SBI Implementation ID. In this scheme, each SBI implementation would have one extension reserved for it: BBL gets 0x0A000000, OpenSBI gets 0x0A000001, Xvisor gets 0x0A000002, KVM gets 0x0A000003, etc. That might not seem like a lot of space, but each extension can have up to 2^32 different functions (including ones for version number discovery, etc.) so it shouldn't actually be limiting. As a side note, I don't think edk2 has an SBI Implementation ID assigned yet. You should just be able to ask for one and get it. Jonathan On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> wrote: > -----Original Message----- > From: tech-unixplatformspec@... [mailto:tech- > unixplatformspec@...] On Behalf Of Atish Patra > Sent: Friday, April 10, 2020 11:32 AM > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; > behrensj@... > Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech- > unixplatformspec@...; Anup Patel <Anup.Patel@...> > Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI > extension space for firmware code base implementation > > On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW > Technologist) wrote: > > Got it, Software ML removed. > > > > Johnathan, do you mean to define it as below? > > Firmware Base Extension, Extension ID: 0xxxxxxxxx (FWBE) , and the > > SBI functions definition is firmware code base implementation- > > specific. > > > > I prefer this one as well. But you should pick any value within experimental > range. Not quite follow this, why pick up one from experimental range? The extension ID must be in the range of 0x0800000-0x08ffffff? I am not sure about the purpose of the extension but if it has the > potential to be a generic SBI extension for firmwares, you should propose it > to the Unix Platform working group. We can add it to the official spec. For those SBI extension which is generic to all firmware code bases, then we should just propose it to the official SBI spec and don’t not have to go with Firmware Base Extension. Firmware Base Extension is classified to those firmware code base specific SBI, for example to load an edk2 driver into M-mode managed memory and executed in M-mode which is behaved as secured system manage mode driver. So the detail Firmware Base Extension would be defined in the separate spec and not part of official sbi spec. Occupied an SBI extension ID is to avoid conflicts. > > > This also works for me and better than to reserve a range of IDs. > > Thanks > > Abner > > > > From: software@... [mailto:software@...] On > > Behalf Of Jonathan Behrens > > Sent: Friday, April 10, 2020 12:39 AM > > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> > > Cc: Atish Patra <Atish.Patra@...>; Anup Patel > <anup.patel@... > > >; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; > > software@...; tech-unixplatformspec@... > > Subject: Re: [RISC-V] [software] Add SBI extension space for firmware > > code base implementation > > > > I think tech-unixplatformspec@... might be the right list? > > > > To address the PR itself, I'd personally prefer to have this space > > allocated based on SBI implementation IDs analogously to how the > > vendor space is allocated. It also probably makes sense to pick a > > different address range so experimental extension space doesn't have > > to move. > > > > Jonathan > > > > On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org < > > abner.chang=hpe.com@...> wrote: > > > Seems opensbi ML is no longer exist? Use software@... > > > insrtead. > > > > > > From: Chang, Abner (HPS SW/FW Technologist) > > > Sent: Thursday, April 9, 2020 4:23 PM > > > To: Atish Patra <Atish.Patra@...>; Anup Patel < > > > anup.patel@...> > > > Cc: opensbi@...; Schaefer, Daniel (DualStudy) < > > > daniel.schaefer@...> > > > Subject: Add SBI extension space for firmware code base > > > implementation > > > > > > Hi Atish and Anup, > > > We are working on some edk2-specific SBI extension which intends to > > > be used by upper layer edk2 drivers. We originally consider to use > > > Vendor Extension space however vendor may have its own proprietary > > > SBI extension as well. In order to prevent from the conflicts of SBI > > > extension space, we propose to have a range for firmware code base. > > > The changes look like the PR below, > > > > > > https://github.com/riscv/riscv-sbi-doc/pull/43 > > > > > > How do you think? > > > Thanks > > > Abner > > > > > > -- > Regards, > Atish > >
More All Messages By This Member
Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation Jonathan Behrens <behrensj@...> #35 Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now. That is fine, just realize that if you are using OpenSBI's implementation ID then you need to get approval from them before defining the extension. Jonathan On Sun, Apr 12, 2020 at 8:57 PM Abner Chang via lists.riscv.org <abner.chang=hpe.com@...> wrote: Basically OpenSBI is a git submodule of edk2 and we don’t make any modification on it, we just build OpenSBI on edk2 build environment. Yes, edk2 will have its own control of extensions for those firmware code base specific functions. One think we concern about is the conflict of extension ID with vendor extension. Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now. We don’t have to add edk2 as one of SBI implementation and this can also prevent from extension ID conflict with vendor’s ones. We can just take #1 opinion. Any other comments? Will let you know if we miss something later. Thanks to all for supporting ekd2. Abner From: Jonathan Behrens [mailto:behrensj@...] Sent: Sunday, April 12, 2020 10:19 PM To: Anup Patel <Anup.Patel@...> Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Is the code for the extension you want to add going to live in the OpenSBI repository or in the EDK2 repository? If I understand correctly, it would live in the EDK2 repository, meaning that your implementation would actually be downstream from OpenSBI and should have its own implementation ID. If you did this then it seems like everything else would fall out nicely: you could decide on version numbers independently of OpenSBI, there'd be no need for a separate set of firmware IDs, and you'd have full control over all the details of your extension. Jonathan On Sun, Apr 12, 2020 at 8:18 AM Anup Patel <Anup.Patel@...> wrote: Hi Abner, We have two options here: EDK2 can use 0xA000000 + <opensbi_imp_id> as SBI Extension OpenSBI provides a way to EDK2 for overriding SBI implementation ID (preferably using some API) If we go with Option1 above then we don’t need separate SBI implementation ID for EDK2. Let us know what you guys think in this context. Regards, Anup From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Sent: 12 April 2020 14:50 To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation This is the PR according to the discussion we had in mail thread. However you may see some confusions from this change. https://github.com/riscv/riscv-sbi-doc/pull/43/commits/e208f23c64f7a6a4be47d6d0ca852433107f6cf4 EDK2 is a SBI implementation? Actually edk2 is not one of the SBI implementations, edk2 fully compliant with OpenSBI and additionally provides the firmware code base SBI extension. We can explain this in the external Firmware code base SBI extension spec (edk2 RISC-V OpenSBI spec), says edk2 SBI implementation actually goes alone with SBI OpenSBI implementation. What is the SBI implementation version associated with EDK2 SBI implementation? This is another confusion because the major SBI implementation is OpenSBI. We also can explain this in the external Firmware code base SBI extension spec, says edk2 SBI implementation version is the version of SBI OpenSBI implementation. Apart from the above proposal, can we have more clear definitions for Firmware code base SBI extension in SBI spec instead of fixing those confusions in the extern spec? The below proposal makes more sense? Define another table for firmware code base, e.g. SBI Firmware Code Base ID. In the table we can have edk2, uboot, Coreboot and etc.. Create a new SBI Base function, sbi_get_firmware_code_base_id() which returns the SBI Firmware Code Base ID. Create a new SBI Base function, sbi_get_firmware_code_base_version() for the version control of firmware code base SBI extension Firmware code base SBI extension is from 0xA000000 to 0xAffffff with Firmware Code Base ID in low bits. I feel the later one makes more sense and clear, how do you think? Abner From: tech-unixplatformspec@... [mailto:tech-unixplatformspec@...] On Behalf Of Abner Chang Sent: Saturday, April 11, 2020 12:08 AM To: Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Cool. This works for edk2. I will have another PR for this. For edk2, we will request a new SBI implementation ID (4) and register firmware code base extension SBI in edk2 SEC phase. From: Anup Patel [mailto:Anup.Patel@...] Sent: Friday, April 10, 2020 11:14 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation I agree with Jonathan's proposal. Let's have SBI FW extension ID depend on SBI implementation ID. We can target this for SBI v0.3 spec along with System Reboot extension. Regards, Anup Sent from Outlook Mobile From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Jonathan Behrens <behrensj@...> Sent: Friday, April 10, 2020 7:14:45 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... <tech-unixplatformspec@...>; Anup Patel <Anup.Patel@...> Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation What I was suggesting is something like: > Implementation specific SBI extension Space, Extension IDs 0x0A000000 through 0x0AFFFFFF. Low bits from SBI Implementation ID. In this scheme, each SBI implementation would have one extension reserved for it: BBL gets 0x0A000000, OpenSBI gets 0x0A000001, Xvisor gets 0x0A000002, KVM gets 0x0A000003, etc. That might not seem like a lot of space, but each extension can have up to 2^32 different functions (including ones for version number discovery, etc.) so it shouldn't actually be limiting. As a side note, I don't think edk2 has an SBI Implementation ID assigned yet. You should just be able to ask for one and get it. Jonathan On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> wrote: > -----Original Message----- > From: tech-unixplatformspec@... [mailto:tech- > unixplatformspec@...] On Behalf Of Atish Patra > Sent: Friday, April 10, 2020 11:32 AM > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; > behrensj@... > Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech- > unixplatformspec@...; Anup Patel <Anup.Patel@...> > Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI > extension space for firmware code base implementation > > On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW > Technologist) wrote: > > Got it, Software ML removed. > > > > Johnathan, do you mean to define it as below? > > Firmware Base Extension, Extension ID: 0xxxxxxxxx (FWBE) , and the > > SBI functions definition is firmware code base implementation- > > specific. > > > > I prefer this one as well. But you should pick any value within experimental > range. Not quite follow this, why pick up one from experimental range? The extension ID must be in the range of 0x0800000-0x08ffffff? I am not sure about the purpose of the extension but if it has the > potential to be a generic SBI extension for firmwares, you should propose it > to the Unix Platform working group. We can add it to the official spec. For those SBI extension which is generic to all firmware code bases, then we should just propose it to the official SBI spec and don’t not have to go with Firmware Base Extension. Firmware Base Extension is classified to those firmware code base specific SBI, for example to load an edk2 driver into M-mode managed memory and executed in M-mode which is behaved as secured system manage mode driver. So the detail Firmware Base Extension would be defined in the separate spec and not part of official sbi spec. Occupied an SBI extension ID is to avoid conflicts. > > > This also works for me and better than to reserve a range of IDs. > > Thanks > > Abner > > > > From: software@... [mailto:software@...] On > > Behalf Of Jonathan Behrens > > Sent: Friday, April 10, 2020 12:39 AM > > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> > > Cc: Atish Patra <Atish.Patra@...>; Anup Patel > <anup.patel@... > > >; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; > > software@...; tech-unixplatformspec@... > > Subject: Re: [RISC-V] [software] Add SBI extension space for firmware > > code base implementation > > > > I think tech-unixplatformspec@... might be the right list? > > > > To address the PR itself, I'd personally prefer to have this space > > allocated based on SBI implementation IDs analogously to how the > > vendor space is allocated. It also probably makes sense to pick a > > different address range so experimental extension space doesn't have > > to move. > > > > Jonathan > > > > On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org < > > abner.chang=hpe.com@...> wrote: > > > Seems opensbi ML is no longer exist? Use software@... > > > insrtead. > > > > > > From: Chang, Abner (HPS SW/FW Technologist) > > > Sent: Thursday, April 9, 2020 4:23 PM > > > To: Atish Patra <Atish.Patra@...>; Anup Patel < > > > anup.patel@...> > > > Cc: opensbi@...; Schaefer, Daniel (DualStudy) < > > > daniel.schaefer@...> > > > Subject: Add SBI extension space for firmware code base > > > implementation > > > > > > Hi Atish and Anup, > > > We are working on some edk2-specific SBI extension which intends to > > > be used by upper layer edk2 drivers. We originally consider to use > > > Vendor Extension space however vendor may have its own proprietary > > > SBI extension as well. In order to prevent from the conflicts of SBI > > > extension space, we propose to have a range for firmware code base. > > > The changes look like the PR below, > > > > > > https://github.com/riscv/riscv-sbi-doc/pull/43 > > > > > > How do you think? > > > Thanks > > > Abner > > > > > > -- > Regards, > Atish > >
More All Messages By This Member
Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation Abner Chang <abner.chang@...> #36 toggle quoted message Show quoted text From: Jonathan Behrens [mailto:behrensj@...] Sent: Monday, April 13, 2020 10:49 AM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Anup Patel <Anup.Patel@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now. That is fine, just realize that if you are using OpenSBI's implementation ID then you need to get approval from them before defining the extension. [Abner] I suppose the intention of reserving 0xa000000 is to let firmware defines its own SBI functions. SBI spec won’t touch or specify anything in this range as it doesn’t touch vendor extension. To have 0xa000000 + opensbi_imp_id means the firmware code base extension is defined base on OpenSBI SBI implementation. *Anup, is my understanding correct?* *Abner* Jonathan On Sun, Apr 12, 2020 at 8:57 PM Abner Chang via lists.riscv.org <abner.chang=hpe.com@...> wrote: Basically OpenSBI is a git submodule of edk2 and we don’t make any modification on it, we just build OpenSBI on edk2 build environment. Yes, edk2 will have its own control of extensions for those firmware code base specific functions. One think we concern about is the conflict of extension ID with vendor extension. Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now. We don’t have to add edk2 as one of SBI implementation and this can also prevent from extension ID conflict with vendor’s ones. We can just take #1 opinion. Any other comments? Will let you know if we miss something later. Thanks to all for supporting ekd2. Abner From: Jonathan Behrens [mailto:behrensj@...] Sent: Sunday, April 12, 2020 10:19 PM To: Anup Patel <Anup.Patel@...> Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Is the code for the extension you want to add going to live in the OpenSBI repository or in the EDK2 repository? If I understand correctly, it would live in the EDK2 repository, meaning that your implementation would actually be downstream from OpenSBI and should have its own implementation ID. If you did this then it seems like everything else would fall out nicely: you could decide on version numbers independently of OpenSBI, there'd be no need for a separate set of firmware IDs, and you'd have full control over all the details of your extension. Jonathan On Sun, Apr 12, 2020 at 8:18 AM Anup Patel <Anup.Patel@...> wrote: Hi Abner, We have two options here: EDK2 can use 0xA000000 + <opensbi_imp_id> as SBI Extension OpenSBI provides a way to EDK2 for overriding SBI implementation ID (preferably using some API) If we go with Option1 above then we don’t need separate SBI implementation ID for EDK2. Let us know what you guys think in this context. Regards, Anup From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Sent: 12 April 2020 14:50 To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation This is the PR according to the discussion we had in mail thread. However you may see some confusions from this change. https://github.com/riscv/riscv-sbi-doc/pull/43/commits/e208f23c64f7a6a4be47d6d0ca852433107f6cf4 EDK2 is a SBI implementation? Actually edk2 is not one of the SBI implementations, edk2 fully compliant with OpenSBI and additionally provides the firmware code base SBI extension. We can explain this in the external Firmware code base SBI extension spec (edk2 RISC-V OpenSBI spec), says edk2 SBI implementation actually goes alone with SBI OpenSBI implementation. What is the SBI implementation version associated with EDK2 SBI implementation? This is another confusion because the major SBI implementation is OpenSBI. We also can explain this in the external Firmware code base SBI extension spec, says edk2 SBI implementation version is the version of SBI OpenSBI implementation. Apart from the above proposal, can we have more clear definitions for Firmware code base SBI extension in SBI spec instead of fixing those confusions in the extern spec? The below proposal makes more sense? Define another table for firmware code base, e.g. SBI Firmware Code Base ID. In the table we can have edk2, uboot, Coreboot and etc.. Create a new SBI Base function, sbi_get_firmware_code_base_id() which returns the SBI Firmware Code Base ID. Create a new SBI Base function, sbi_get_firmware_code_base_version() for the version control of firmware code base SBI extension Firmware code base SBI extension is from 0xA000000 to 0xAffffff with Firmware Code Base ID in low bits. I feel the later one makes more sense and clear, how do you think? Abner From: tech-unixplatformspec@... [mailto:tech-unixplatformspec@...] On Behalf Of Abner Chang Sent: Saturday, April 11, 2020 12:08 AM To: Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Cool. This works for edk2. I will have another PR for this. For edk2, we will request a new SBI implementation ID (4) and register firmware code base extension SBI in edk2 SEC phase. From: Anup Patel [mailto:Anup.Patel@...] Sent: Friday, April 10, 2020 11:14 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation I agree with Jonathan's proposal. Let's have SBI FW extension ID depend on SBI implementation ID. We can target this for SBI v0.3 spec along with System Reboot extension. Regards, Anup Sent from Outlook Mobile From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Jonathan Behrens <behrensj@...> Sent: Friday, April 10, 2020 7:14:45 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... <tech-unixplatformspec@...>; Anup Patel <Anup.Patel@...> Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation What I was suggesting is something like: > Implementation specific SBI extension Space, Extension IDs 0x0A000000 through 0x0AFFFFFF. Low bits from SBI Implementation ID. In this scheme, each SBI implementation would have one extension reserved for it: BBL gets 0x0A000000, OpenSBI gets 0x0A000001, Xvisor gets 0x0A000002, KVM gets 0x0A000003, etc. That might not seem like a lot of space, but each extension can have up to 2^32 different functions (including ones for version number discovery, etc.) so it shouldn't actually be limiting. As a side note, I don't think edk2 has an SBI Implementation ID assigned yet. You should just be able to ask for one and get it. Jonathan On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> wrote: > -----Original Message----- > From: tech-unixplatformspec@... [mailto:tech- > unixplatformspec@...] On Behalf Of Atish Patra > Sent: Friday, April 10, 2020 11:32 AM > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; > behrensj@... > Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech- > unixplatformspec@...; Anup Patel <Anup.Patel@...> > Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI > extension space for firmware code base implementation > > On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW > Technologist) wrote: > > Got it, Software ML removed. > > > > Johnathan, do you mean to define it as below? > > Firmware Base Extension, Extension ID: 0xxxxxxxxx (FWBE) , and the > > SBI functions definition is firmware code base implementation- > > specific. > > > > I prefer this one as well. But you should pick any value within experimental > range. Not quite follow this, why pick up one from experimental range? The extension ID must be in the range of 0x0800000-0x08ffffff? I am not sure about the purpose of the extension but if it has the > potential to be a generic SBI extension for firmwares, you should propose it > to the Unix Platform working group. We can add it to the official spec. For those SBI extension which is generic to all firmware code bases, then we should just propose it to the official SBI spec and don’t not have to go with Firmware Base Extension. Firmware Base Extension is classified to those firmware code base specific SBI, for example to load an edk2 driver into M-mode managed memory and executed in M-mode which is behaved as secured system manage mode driver. So the detail Firmware Base Extension would be defined in the separate spec and not part of official sbi spec. Occupied an SBI extension ID is to avoid conflicts. > > > This also works for me and better than to reserve a range of IDs. > > Thanks > > Abner > > > > From: software@... [mailto:software@...] On > > Behalf Of Jonathan Behrens > > Sent: Friday, April 10, 2020 12:39 AM > > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> > > Cc: Atish Patra <Atish.Patra@...>; Anup Patel > <anup.patel@... > > >; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; > > software@...; tech-unixplatformspec@... > > Subject: Re: [RISC-V] [software] Add SBI extension space for firmware > > code base implementation > > > > I think tech-unixplatformspec@... might be the right list? > > > > To address the PR itself, I'd personally prefer to have this space > > allocated based on SBI implementation IDs analogously to how the > > vendor space is allocated. It also probably makes sense to pick a > > different address range so experimental extension space doesn't have > > to move. > > > > Jonathan > > > > On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org < > > abner.chang=hpe.com@...> wrote: > > > Seems opensbi ML is no longer exist? Use software@... > > > insrtead. > > > > > > From: Chang, Abner (HPS SW/FW Technologist) > > > Sent: Thursday, April 9, 2020 4:23 PM > > > To: Atish Patra <Atish.Patra@...>; Anup Patel < > > > anup.patel@...> > > > Cc: opensbi@...; Schaefer, Daniel (DualStudy) < > > > daniel.schaefer@...> > > > Subject: Add SBI extension space for firmware code base > > > implementation > > > > > > Hi Atish and Anup, > > > We are working on some edk2-specific SBI extension which intends to > > > be used by upper layer edk2 drivers. We originally consider to use > > > Vendor Extension space however vendor may have its own proprietary > > > SBI extension as well. In order to prevent from the conflicts of SBI > > > extension space, we propose to have a range for firmware code base. > > > The changes look like the PR below, > > > > > > https://github.com/riscv/riscv-sbi-doc/pull/43 > > > > > > How do you think? > > > Thanks > > > Abner > > > > > > -- > Regards, > Atish > >
More All Messages By This Member
Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation Anup Patel #37 Hi Abner, Yes, your understanding is correct. The 0xA000000 + opensbi_imp_id is the SBI Firmware code base extension meant to be used by OpenSBI. Now EDK2 uses unmodified OpenSBI as library/submodule so underlying SBI implementation in-case of EDK2 is indeed OpenSBI itself. From OpenSBI perspective, we don’t see any OpenSBI specific SBI calls being implemented in-future because previous and next booting stages are totally black-box for OpenSBI. This means SBI Firmware code base extension will be never used by OpenSBI hence EDK2 can certainly register custom SBI extension for ext_id = 0xA000000 + opensbi_imp_id (Note: EDK2 can use sbi_ecall_register_extension() API for this from platform final_init() callback). Apart from above, I do see SBI firmware code base extension useful to some of the hypervisors (such as Xvisor, Xen, etc) but this is in totally different context. Regards, Anup toggle quoted message Show quoted text From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Abner Chang Sent: 13 April 2020 08:45 To: Jonathan Behrens <behrensj@...> Cc: Anup Patel <Anup.Patel@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation From: Jonathan Behrens [mailto:behrensj@...] Sent: Monday, April 13, 2020 10:49 AM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Anup Patel <Anup.Patel@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now. That is fine, just realize that if you are using OpenSBI's implementation ID then you need to get approval from them before defining the extension. [Abner] I suppose the intention of reserving 0xa000000 is to let firmware defines its own SBI functions. SBI spec won’t touch or specify anything in this range as it doesn’t touch vendor extension. To have 0xa000000 + opensbi_imp_id means the firmware code base extension is defined base on OpenSBI SBI implementation. *Anup, is my understanding correct?* *Abner* Jonathan On Sun, Apr 12, 2020 at 8:57 PM Abner Chang via lists.riscv.org <abner.chang=hpe.com@...> wrote: Basically OpenSBI is a git submodule of edk2 and we don’t make any modification on it, we just build OpenSBI on edk2 build environment. Yes, edk2 will have its own control of extensions for those firmware code base specific functions. One think we concern about is the conflict of extension ID with vendor extension. Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now. We don’t have to add edk2 as one of SBI implementation and this can also prevent from extension ID conflict with vendor’s ones. We can just take #1 opinion. Any other comments? Will let you know if we miss something later. Thanks to all for supporting ekd2. Abner From: Jonathan Behrens [mailto:behrensj@...] Sent: Sunday, April 12, 2020 10:19 PM To: Anup Patel <Anup.Patel@...> Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Is the code for the extension you want to add going to live in the OpenSBI repository or in the EDK2 repository? If I understand correctly, it would live in the EDK2 repository, meaning that your implementation would actually be downstream from OpenSBI and should have its own implementation ID. If you did this then it seems like everything else would fall out nicely: you could decide on version numbers independently of OpenSBI, there'd be no need for a separate set of firmware IDs, and you'd have full control over all the details of your extension. Jonathan On Sun, Apr 12, 2020 at 8:18 AM Anup Patel <Anup.Patel@...> wrote: Hi Abner, We have two options here: EDK2 can use 0xA000000 + <opensbi_imp_id> as SBI Extension OpenSBI provides a way to EDK2 for overriding SBI implementation ID (preferably using some API) If we go with Option1 above then we don’t need separate SBI implementation ID for EDK2. Let us know what you guys think in this context. Regards, Anup From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Sent: 12 April 2020 14:50 To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation This is the PR according to the discussion we had in mail thread. However you may see some confusions from this change. https://github.com/riscv/riscv-sbi-doc/pull/43/commits/e208f23c64f7a6a4be47d6d0ca852433107f6cf4 EDK2 is a SBI implementation? Actually edk2 is not one of the SBI implementations, edk2 fully compliant with OpenSBI and additionally provides the firmware code base SBI extension. We can explain this in the external Firmware code base SBI extension spec (edk2 RISC-V OpenSBI spec), says edk2 SBI implementation actually goes alone with SBI OpenSBI implementation. What is the SBI implementation version associated with EDK2 SBI implementation? This is another confusion because the major SBI implementation is OpenSBI. We also can explain this in the external Firmware code base SBI extension spec, says edk2 SBI implementation version is the version of SBI OpenSBI implementation. Apart from the above proposal, can we have more clear definitions for Firmware code base SBI extension in SBI spec instead of fixing those confusions in the extern spec? The below proposal makes more sense? Define another table for firmware code base, e.g. SBI Firmware Code Base ID. In the table we can have edk2, uboot, Coreboot and etc.. Create a new SBI Base function, sbi_get_firmware_code_base_id() which returns the SBI Firmware Code Base ID. Create a new SBI Base function, sbi_get_firmware_code_base_version() for the version control of firmware code base SBI extension Firmware code base SBI extension is from 0xA000000 to 0xAffffff with Firmware Code Base ID in low bits. I feel the later one makes more sense and clear, how do you think? Abner From: tech-unixplatformspec@... [mailto:tech-unixplatformspec@...] On Behalf Of Abner Chang Sent: Saturday, April 11, 2020 12:08 AM To: Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Cool. This works for edk2. I will have another PR for this. For edk2, we will request a new SBI implementation ID (4) and register firmware code base extension SBI in edk2 SEC phase. From: Anup Patel [mailto:Anup.Patel@...] Sent: Friday, April 10, 2020 11:14 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation I agree with Jonathan's proposal. Let's have SBI FW extension ID depend on SBI implementation ID. We can target this for SBI v0.3 spec along with System Reboot extension. Regards, Anup Sent from Outlook Mobile From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Jonathan Behrens <behrensj@...> Sent: Friday, April 10, 2020 7:14:45 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... <tech-unixplatformspec@...>; Anup Patel <Anup.Patel@...> Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation What I was suggesting is something like: > Implementation specific SBI extension Space, Extension IDs 0x0A000000 through 0x0AFFFFFF. Low bits from SBI Implementation ID. In this scheme, each SBI implementation would have one extension reserved for it: BBL gets 0x0A000000, OpenSBI gets 0x0A000001, Xvisor gets 0x0A000002, KVM gets 0x0A000003, etc. That might not seem like a lot of space, but each extension can have up to 2^32 different functions (including ones for version number discovery, etc.) so it shouldn't actually be limiting. As a side note, I don't think edk2 has an SBI Implementation ID assigned yet. You should just be able to ask for one and get it. Jonathan On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> wrote: > -----Original Message----- > From: tech-unixplatformspec@... [mailto:tech- > unixplatformspec@...] On Behalf Of Atish Patra > Sent: Friday, April 10, 2020 11:32 AM > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; > behrensj@... > Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech- > unixplatformspec@...; Anup Patel <Anup.Patel@...> > Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI > extension space for firmware code base implementation > > On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW > Technologist) wrote: > > Got it, Software ML removed. > > > > Johnathan, do you mean to define it as below? > > Firmware Base Extension, Extension ID: 0xxxxxxxxx (FWBE) , and the > > SBI functions definition is firmware code base implementation- > > specific. > > > > I prefer this one as well. But you should pick any value within experimental > range. Not quite follow this, why pick up one from experimental range? The extension ID must be in the range of 0x0800000-0x08ffffff? I am not sure about the purpose of the extension but if it has the > potential to be a generic SBI extension for firmwares, you should propose it > to the Unix Platform working group. We can add it to the official spec. For those SBI extension which is generic to all firmware code bases, then we should just propose it to the official SBI spec and don’t not have to go with Firmware Base Extension. Firmware Base Extension is classified to those firmware code base specific SBI, for example to load an edk2 driver into M-mode managed memory and executed in M-mode which is behaved as secured system manage mode driver. So the detail Firmware Base Extension would be defined in the separate spec and not part of official sbi spec. Occupied an SBI extension ID is to avoid conflicts. > > > This also works for me and better than to reserve a range of IDs. > > Thanks > > Abner > > > > From: software@... [mailto:software@...] On > > Behalf Of Jonathan Behrens > > Sent: Friday, April 10, 2020 12:39 AM > > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> > > Cc: Atish Patra <Atish.Patra@...>; Anup Patel > <anup.patel@... > > >; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; > > software@...; tech-unixplatformspec@... > > Subject: Re: [RISC-V] [software] Add SBI extension space for firmware > > code base implementation > > > > I think tech-unixplatformspec@... might be the right list? > > > > To address the PR itself, I'd personally prefer to have this space > > allocated based on SBI implementation IDs analogously to how the > > vendor space is allocated. It also probably makes sense to pick a > > different address range so experimental extension space doesn't have > > to move. > > > > Jonathan > > > > On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org < > > abner.chang=hpe.com@...> wrote: > > > Seems opensbi ML is no longer exist? Use software@... > > > insrtead. > > > > > > From: Chang, Abner (HPS SW/FW Technologist) > > > Sent: Thursday, April 9, 2020 4:23 PM > > > To: Atish Patra <Atish.Patra@...>; Anup Patel < > > > anup.patel@...> > > > Cc: opensbi@...; Schaefer, Daniel (DualStudy) < > > > daniel.schaefer@...> > > > Subject: Add SBI extension space for firmware code base > > > implementation > > > > > > Hi Atish and Anup, > > > We are working on some edk2-specific SBI extension which intends to > > > be used by upper layer edk2 drivers. We originally consider to use > > > Vendor Extension space however vendor may have its own proprietary > > > SBI extension as well. In order to prevent from the conflicts of SBI > > > extension space, we propose to have a range for firmware code base. > > > The changes look like the PR below, > > > > > > https://github.com/riscv/riscv-sbi-doc/pull/43 > > > > > > How do you think? > > > Thanks > > > Abner > > > > > > -- > Regards, > Atish > >
More All Messages By This Member
Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation Abner Chang <abner.chang@...> #38 Hi Anup, Thanks for the clarification. I have updated PR according to this. edk2 is removed from SBI implementation ID. Thanks Anup and Jonathan. Abner toggle quoted message Show quoted text From: Anup Patel [mailto:Anup.Patel@...] Sent: Monday, April 13, 2020 2:26 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Hi Abner, Yes, your understanding is correct. The 0xA000000 + opensbi_imp_id is the SBI Firmware code base extension meant to be used by OpenSBI. Now EDK2 uses unmodified OpenSBI as library/submodule so underlying SBI implementation in-case of EDK2 is indeed OpenSBI itself. From OpenSBI perspective, we don’t see any OpenSBI specific SBI calls being implemented in-future because previous and next booting stages are totally black-box for OpenSBI. This means SBI Firmware code base extension will be never used by OpenSBI hence EDK2 can certainly register custom SBI extension for ext_id = 0xA000000 + opensbi_imp_id (Note: EDK2 can use sbi_ecall_register_extension() API for this from platform final_init() callback). Apart from above, I do see SBI firmware code base extension useful to some of the hypervisors (such as Xvisor, Xen, etc) but this is in totally different context. Regards, Anup From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Abner Chang Sent: 13 April 2020 08:45 To: Jonathan Behrens <behrensj@...> Cc: Anup Patel <Anup.Patel@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation From: Jonathan Behrens [mailto:behrensj@...] Sent: Monday, April 13, 2020 10:49 AM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Anup Patel <Anup.Patel@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now. That is fine, just realize that if you are using OpenSBI's implementation ID then you need to get approval from them before defining the extension. [Abner] I suppose the intention of reserving 0xa000000 is to let firmware defines its own SBI functions. SBI spec won’t touch or specify anything in this range as it doesn’t touch vendor extension. To have 0xa000000 + opensbi_imp_id means the firmware code base extension is defined base on OpenSBI SBI implementation. *Anup, is my understanding correct?* *Abner* Jonathan On Sun, Apr 12, 2020 at 8:57 PM Abner Chang via lists.riscv.org <abner.chang=hpe.com@...> wrote: Basically OpenSBI is a git submodule of edk2 and we don’t make any modification on it, we just build OpenSBI on edk2 build environment. Yes, edk2 will have its own control of extensions for those firmware code base specific functions. One think we concern about is the conflict of extension ID with vendor extension. Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now. We don’t have to add edk2 as one of SBI implementation and this can also prevent from extension ID conflict with vendor’s ones. We can just take #1 opinion. Any other comments? Will let you know if we miss something later. Thanks to all for supporting ekd2. Abner From: Jonathan Behrens [mailto:behrensj@...] Sent: Sunday, April 12, 2020 10:19 PM To: Anup Patel <Anup.Patel@...> Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Is the code for the extension you want to add going to live in the OpenSBI repository or in the EDK2 repository? If I understand correctly, it would live in the EDK2 repository, meaning that your implementation would actually be downstream from OpenSBI and should have its own implementation ID. If you did this then it seems like everything else would fall out nicely: you could decide on version numbers independently of OpenSBI, there'd be no need for a separate set of firmware IDs, and you'd have full control over all the details of your extension. Jonathan On Sun, Apr 12, 2020 at 8:18 AM Anup Patel <Anup.Patel@...> wrote: Hi Abner, We have two options here: EDK2 can use 0xA000000 + <opensbi_imp_id> as SBI Extension OpenSBI provides a way to EDK2 for overriding SBI implementation ID (preferably using some API) If we go with Option1 above then we don’t need separate SBI implementation ID for EDK2. Let us know what you guys think in this context. Regards, Anup From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Sent: 12 April 2020 14:50 To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation This is the PR according to the discussion we had in mail thread. However you may see some confusions from this change. https://github.com/riscv/riscv-sbi-doc/pull/43/commits/e208f23c64f7a6a4be47d6d0ca852433107f6cf4 EDK2 is a SBI implementation? Actually edk2 is not one of the SBI implementations, edk2 fully compliant with OpenSBI and additionally provides the firmware code base SBI extension. We can explain this in the external Firmware code base SBI extension spec (edk2 RISC-V OpenSBI spec), says edk2 SBI implementation actually goes alone with SBI OpenSBI implementation. What is the SBI implementation version associated with EDK2 SBI implementation? This is another confusion because the major SBI implementation is OpenSBI. We also can explain this in the external Firmware code base SBI extension spec, says edk2 SBI implementation version is the version of SBI OpenSBI implementation. Apart from the above proposal, can we have more clear definitions for Firmware code base SBI extension in SBI spec instead of fixing those confusions in the extern spec? The below proposal makes more sense? Define another table for firmware code base, e.g. SBI Firmware Code Base ID. In the table we can have edk2, uboot, Coreboot and etc.. Create a new SBI Base function, sbi_get_firmware_code_base_id() which returns the SBI Firmware Code Base ID. Create a new SBI Base function, sbi_get_firmware_code_base_version() for the version control of firmware code base SBI extension Firmware code base SBI extension is from 0xA000000 to 0xAffffff with Firmware Code Base ID in low bits. I feel the later one makes more sense and clear, how do you think? Abner From: tech-unixplatformspec@... [mailto:tech-unixplatformspec@...] On Behalf Of Abner Chang Sent: Saturday, April 11, 2020 12:08 AM To: Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Cool. This works for edk2. I will have another PR for this. For edk2, we will request a new SBI implementation ID (4) and register firmware code base extension SBI in edk2 SEC phase. From: Anup Patel [mailto:Anup.Patel@...] Sent: Friday, April 10, 2020 11:14 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation I agree with Jonathan's proposal. Let's have SBI FW extension ID depend on SBI implementation ID. We can target this for SBI v0.3 spec along with System Reboot extension. Regards, Anup Sent from Outlook Mobile From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Jonathan Behrens <behrensj@...> Sent: Friday, April 10, 2020 7:14:45 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... <tech-unixplatformspec@...>; Anup Patel <Anup.Patel@...> Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation What I was suggesting is something like: > Implementation specific SBI extension Space, Extension IDs 0x0A000000 through 0x0AFFFFFF. Low bits from SBI Implementation ID. In this scheme, each SBI implementation would have one extension reserved for it: BBL gets 0x0A000000, OpenSBI gets 0x0A000001, Xvisor gets 0x0A000002, KVM gets 0x0A000003, etc. That might not seem like a lot of space, but each extension can have up to 2^32 different functions (including ones for version number discovery, etc.) so it shouldn't actually be limiting. As a side note, I don't think edk2 has an SBI Implementation ID assigned yet. You should just be able to ask for one and get it. Jonathan On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> wrote: > -----Original Message----- > From: tech-unixplatformspec@... [mailto:tech- > unixplatformspec@...] On Behalf Of Atish Patra > Sent: Friday, April 10, 2020 11:32 AM > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; > behrensj@... > Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech- > unixplatformspec@...; Anup Patel <Anup.Patel@...> > Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI > extension space for firmware code base implementation > > On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW > Technologist) wrote: > > Got it, Software ML removed. > > > > Johnathan, do you mean to define it as below? > > Firmware Base Extension, Extension ID: 0xxxxxxxxx (FWBE) , and the > > SBI functions definition is firmware code base implementation- > > specific. > > > > I prefer this one as well. But you should pick any value within experimental > range. Not quite follow this, why pick up one from experimental range? The extension ID must be in the range of 0x0800000-0x08ffffff? I am not sure about the purpose of the extension but if it has the > potential to be a generic SBI extension for firmwares, you should propose it > to the Unix Platform working group. We can add it to the official spec. For those SBI extension which is generic to all firmware code bases, then we should just propose it to the official SBI spec and don’t not have to go with Firmware Base Extension. Firmware Base Extension is classified to those firmware code base specific SBI, for example to load an edk2 driver into M-mode managed memory and executed in M-mode which is behaved as secured system manage mode driver. So the detail Firmware Base Extension would be defined in the separate spec and not part of official sbi spec. Occupied an SBI extension ID is to avoid conflicts. > > > This also works for me and better than to reserve a range of IDs. > > Thanks > > Abner > > > > From: software@... [mailto:software@...] On > > Behalf Of Jonathan Behrens > > Sent: Friday, April 10, 2020 12:39 AM > > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> > > Cc: Atish Patra <Atish.Patra@...>; Anup Patel > <anup.patel@... > > >; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; > > software@...; tech-unixplatformspec@... > > Subject: Re: [RISC-V] [software] Add SBI extension space for firmware > > code base implementation > > > > I think tech-unixplatformspec@... might be the right list? > > > > To address the PR itself, I'd personally prefer to have this space > > allocated based on SBI implementation IDs analogously to how the > > vendor space is allocated. It also probably makes sense to pick a > > different address range so experimental extension space doesn't have > > to move. > > > > Jonathan > > > > On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org < > > abner.chang=hpe.com@...> wrote: > > > Seems opensbi ML is no longer exist? Use software@... > > > insrtead. > > > > > > From: Chang, Abner (HPS SW/FW Technologist) > > > Sent: Thursday, April 9, 2020 4:23 PM > > > To: Atish Patra <Atish.Patra@...>; Anup Patel < > > > anup.patel@...> > > > Cc: opensbi@...; Schaefer, Daniel (DualStudy) < > > > daniel.schaefer@...> > > > Subject: Add SBI extension space for firmware code base > > > implementation > > > > > > Hi Atish and Anup, > > > We are working on some edk2-specific SBI extension which intends to > > > be used by upper layer edk2 drivers. We originally consider to use > > > Vendor Extension space however vendor may have its own proprietary > > > SBI extension as well. In order to prevent from the conflicts of SBI > > > extension space, we propose to have a range for firmware code base. > > > The changes look like the PR below, > > > > > > https://github.com/riscv/riscv-sbi-doc/pull/43 > > > > > > How do you think? > > > Thanks > > > Abner > > > > > > -- > Regards, > Atish > >
More All Messages By This Member
Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation Jonathan Behrens <behrensj@...> #39 Anup, are you saying that EDK2's extension would be the only use of ext_id = 0xA000000 + opensbi_imp_id or that any firmware that uses OpenSBI is free to make a (potentially incompatible) extension using that ID? Jonathan toggle quoted message Show quoted text On Mon, Apr 13, 2020 at 2:26 AM Anup Patel <Anup.Patel@...> wrote: Hi Abner, Yes, your understanding is correct. The 0xA000000 + opensbi_imp_id is the SBI Firmware code base extension meant to be used by OpenSBI. Now EDK2 uses unmodified OpenSBI as library/submodule so underlying SBI implementation in-case of EDK2 is indeed OpenSBI itself. From OpenSBI perspective, we don’t see any OpenSBI specific SBI calls being implemented in-future because previous and next booting stages are totally black-box for OpenSBI. This means SBI Firmware code base extension will be never used by OpenSBI hence EDK2 can certainly register custom SBI extension for ext_id = 0xA000000 + opensbi_imp_id (Note: EDK2 can use sbi_ecall_register_extension() API for this from platform final_init() callback). Apart from above, I do see SBI firmware code base extension useful to some of the hypervisors (such as Xvisor, Xen, etc) but this is in totally different context. Regards, Anup From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Abner Chang Sent: 13 April 2020 08:45 To: Jonathan Behrens <behrensj@...> Cc: Anup Patel <Anup.Patel@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation From: Jonathan Behrens [mailto:behrensj@...] Sent: Monday, April 13, 2020 10:49 AM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Anup Patel <Anup.Patel@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now. That is fine, just realize that if you are using OpenSBI's implementation ID then you need to get approval from them before defining the extension. [Abner] I suppose the intention of reserving 0xa000000 is to let firmware defines its own SBI functions. SBI spec won’t touch or specify anything in this range as it doesn’t touch vendor extension. To have 0xa000000 + opensbi_imp_id means the firmware code base extension is defined base on OpenSBI SBI implementation. *Anup, is my understanding correct?* *Abner* Jonathan On Sun, Apr 12, 2020 at 8:57 PM Abner Chang via lists.riscv.org <abner.chang=hpe.com@...> wrote: Basically OpenSBI is a git submodule of edk2 and we don’t make any modification on it, we just build OpenSBI on edk2 build environment. Yes, edk2 will have its own control of extensions for those firmware code base specific functions. One think we concern about is the conflict of extension ID with vendor extension. Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now. We don’t have to add edk2 as one of SBI implementation and this can also prevent from extension ID conflict with vendor’s ones. We can just take #1 opinion. Any other comments? Will let you know if we miss something later. Thanks to all for supporting ekd2. Abner From: Jonathan Behrens [mailto:behrensj@...] Sent: Sunday, April 12, 2020 10:19 PM To: Anup Patel <Anup.Patel@...> Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Is the code for the extension you want to add going to live in the OpenSBI repository or in the EDK2 repository? If I understand correctly, it would live in the EDK2 repository, meaning that your implementation would actually be downstream from OpenSBI and should have its own implementation ID. If you did this then it seems like everything else would fall out nicely: you could decide on version numbers independently of OpenSBI, there'd be no need for a separate set of firmware IDs, and you'd have full control over all the details of your extension. Jonathan On Sun, Apr 12, 2020 at 8:18 AM Anup Patel <Anup.Patel@...> wrote: Hi Abner, We have two options here: EDK2 can use 0xA000000 + <opensbi_imp_id> as SBI Extension OpenSBI provides a way to EDK2 for overriding SBI implementation ID (preferably using some API) If we go with Option1 above then we don’t need separate SBI implementation ID for EDK2. Let us know what you guys think in this context. Regards, Anup From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Sent: 12 April 2020 14:50 To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation This is the PR according to the discussion we had in mail thread. However you may see some confusions from this change. https://github.com/riscv/riscv-sbi-doc/pull/43/commits/e208f23c64f7a6a4be47d6d0ca852433107f6cf4 EDK2 is a SBI implementation? Actually edk2 is not one of the SBI implementations, edk2 fully compliant with OpenSBI and additionally provides the firmware code base SBI extension. We can explain this in the external Firmware code base SBI extension spec (edk2 RISC-V OpenSBI spec), says edk2 SBI implementation actually goes alone with SBI OpenSBI implementation. What is the SBI implementation version associated with EDK2 SBI implementation? This is another confusion because the major SBI implementation is OpenSBI. We also can explain this in the external Firmware code base SBI extension spec, says edk2 SBI implementation version is the version of SBI OpenSBI implementation. Apart from the above proposal, can we have more clear definitions for Firmware code base SBI extension in SBI spec instead of fixing those confusions in the extern spec? The below proposal makes more sense? Define another table for firmware code base, e.g. SBI Firmware Code Base ID. In the table we can have edk2, uboot, Coreboot and etc.. Create a new SBI Base function, sbi_get_firmware_code_base_id() which returns the SBI Firmware Code Base ID. Create a new SBI Base function, sbi_get_firmware_code_base_version() for the version control of firmware code base SBI extension Firmware code base SBI extension is from 0xA000000 to 0xAffffff with Firmware Code Base ID in low bits. I feel the later one makes more sense and clear, how do you think? Abner From: tech-unixplatformspec@... [mailto:tech-unixplatformspec@...] On Behalf Of Abner Chang Sent: Saturday, April 11, 2020 12:08 AM To: Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Cool. This works for edk2. I will have another PR for this. For edk2, we will request a new SBI implementation ID (4) and register firmware code base extension SBI in edk2 SEC phase. From: Anup Patel [mailto:Anup.Patel@...] Sent: Friday, April 10, 2020 11:14 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation I agree with Jonathan's proposal. Let's have SBI FW extension ID depend on SBI implementation ID. We can target this for SBI v0.3 spec along with System Reboot extension. Regards, Anup Sent from Outlook Mobile From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Jonathan Behrens <behrensj@...> Sent: Friday, April 10, 2020 7:14:45 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... <tech-unixplatformspec@...>; Anup Patel <Anup.Patel@...> Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation What I was suggesting is something like: > Implementation specific SBI extension Space, Extension IDs 0x0A000000 through 0x0AFFFFFF. Low bits from SBI Implementation ID. In this scheme, each SBI implementation would have one extension reserved for it: BBL gets 0x0A000000, OpenSBI gets 0x0A000001, Xvisor gets 0x0A000002, KVM gets 0x0A000003, etc. That might not seem like a lot of space, but each extension can have up to 2^32 different functions (including ones for version number discovery, etc.) so it shouldn't actually be limiting. As a side note, I don't think edk2 has an SBI Implementation ID assigned yet. You should just be able to ask for one and get it. Jonathan On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> wrote: > -----Original Message----- > From: tech-unixplatformspec@... [mailto:tech- > unixplatformspec@...] On Behalf Of Atish Patra > Sent: Friday, April 10, 2020 11:32 AM > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; > behrensj@... > Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech- > unixplatformspec@...; Anup Patel <Anup.Patel@...> > Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI > extension space for firmware code base implementation > > On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW > Technologist) wrote: > > Got it, Software ML removed. > > > > Johnathan, do you mean to define it as below? > > Firmware Base Extension, Extension ID: 0xxxxxxxxx (FWBE) , and the > > SBI functions definition is firmware code base implementation- > > specific. > > > > I prefer this one as well. But you should pick any value within experimental > range. Not quite follow this, why pick up one from experimental range? The extension ID must be in the range of 0x0800000-0x08ffffff? I am not sure about the purpose of the extension but if it has the > potential to be a generic SBI extension for firmwares, you should propose it > to the Unix Platform working group. We can add it to the official spec. For those SBI extension which is generic to all firmware code bases, then we should just propose it to the official SBI spec and don’t not have to go with Firmware Base Extension. Firmware Base Extension is classified to those firmware code base specific SBI, for example to load an edk2 driver into M-mode managed memory and executed in M-mode which is behaved as secured system manage mode driver. So the detail Firmware Base Extension would be defined in the separate spec and not part of official sbi spec. Occupied an SBI extension ID is to avoid conflicts. > > > This also works for me and better than to reserve a range of IDs. > > Thanks > > Abner > > > > From: software@... [mailto:software@...] On > > Behalf Of Jonathan Behrens > > Sent: Friday, April 10, 2020 12:39 AM > > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> > > Cc: Atish Patra <Atish.Patra@...>; Anup Patel > <anup.patel@... > > >; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; > > software@...; tech-unixplatformspec@... > > Subject: Re: [RISC-V] [software] Add SBI extension space for firmware > > code base implementation > > > > I think tech-unixplatformspec@... might be the right list? > > > > To address the PR itself, I'd personally prefer to have this space > > allocated based on SBI implementation IDs analogously to how the > > vendor space is allocated. It also probably makes sense to pick a > > different address range so experimental extension space doesn't have > > to move. > > > > Jonathan > > > > On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org < > > abner.chang=hpe.com@...> wrote: > > > Seems opensbi ML is no longer exist? Use software@... > > > insrtead. > > > > > > From: Chang, Abner (HPS SW/FW Technologist) > > > Sent: Thursday, April 9, 2020 4:23 PM > > > To: Atish Patra <Atish.Patra@...>; Anup Patel < > > > anup.patel@...> > > > Cc: opensbi@...; Schaefer, Daniel (DualStudy) < > > > daniel.schaefer@...> > > > Subject: Add SBI extension space for firmware code base > > > implementation > > > > > > Hi Atish and Anup, > > > We are working on some edk2-specific SBI extension which intends to > > > be used by upper layer edk2 drivers. We originally consider to use > > > Vendor Extension space however vendor may have its own proprietary > > > SBI extension as well. In order to prevent from the conflicts of SBI > > > extension space, we propose to have a range for firmware code base. > > > The changes look like the PR below, > > > > > > https://github.com/riscv/riscv-sbi-doc/pull/43 > > > > > > How do you think? > > > Thanks > > > Abner > > > > > > -- > Regards, > Atish > >
More All Messages By This Member
Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation Anup Patel #40 Jonathan, With EDK2 + OpenSBI running in background, the S-mode software will see SBI implementation ID of OpenSBI because EDK2 uses unmodified OpenSBI as library. This means from S-mode perspective the underlying SBI implementation is still OpenSBI. The OpenSBI itself does not need the SBI firmware code base extension hence I suggested that EDK2 can use ext_id = 0xA000000 + opensbi_imp_id. Most of the other bootloaders (U-Boot and Coreboot) use OpenSBI FW_DYNAMIC firmware. For such bootloaders, the SBI firmware code extension won’t be available because OpenSBI firmwares will not implement it. Apart from bootloaders, the SBI firmware code base extension space can be used hypervisors to provide hypervisor specific SBI calls. Regards, Anup toggle quoted message Show quoted text From: Jonathan Behrens <behrensj@...> Sent: 14 April 2020 08:42 To: Anup Patel <Anup.Patel@...> Cc: Abner Chang <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Anup, are you saying that EDK2's extension would be the only use of ext_id = 0xA000000 + opensbi_imp_id or that any firmware that uses OpenSBI is free to make a (potentially incompatible) extension using that ID? Jonathan On Mon, Apr 13, 2020 at 2:26 AM Anup Patel <Anup.Patel@...> wrote: Hi Abner, Yes, your understanding is correct. The 0xA000000 + opensbi_imp_id is the SBI Firmware code base extension meant to be used by OpenSBI. Now EDK2 uses unmodified OpenSBI as library/submodule so underlying SBI implementation in-case of EDK2 is indeed OpenSBI itself. From OpenSBI perspective, we don’t see any OpenSBI specific SBI calls being implemented in-future because previous and next booting stages are totally black-box for OpenSBI. This means SBI Firmware code base extension will be never used by OpenSBI hence EDK2 can certainly register custom SBI extension for ext_id = 0xA000000 + opensbi_imp_id (Note: EDK2 can use sbi_ecall_register_extension() API for this from platform final_init() callback). Apart from above, I do see SBI firmware code base extension useful to some of the hypervisors (such as Xvisor, Xen, etc) but this is in totally different context. Regards, Anup From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Abner Chang Sent: 13 April 2020 08:45 To: Jonathan Behrens <behrensj@...> Cc: Anup Patel <Anup.Patel@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation From: Jonathan Behrens [mailto:behrensj@...] Sent: Monday, April 13, 2020 10:49 AM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Anup Patel <Anup.Patel@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now. That is fine, just realize that if you are using OpenSBI's implementation ID then you need to get approval from them before defining the extension. [Abner] I suppose the intention of reserving 0xa000000 is to let firmware defines its own SBI functions. SBI spec won’t touch or specify anything in this range as it doesn’t touch vendor extension. To have 0xa000000 + opensbi_imp_id means the firmware code base extension is defined base on OpenSBI SBI implementation. *Anup, is my understanding correct?* *Abner* Jonathan On Sun, Apr 12, 2020 at 8:57 PM Abner Chang via lists.riscv.org <abner.chang=hpe.com@...> wrote: Basically OpenSBI is a git submodule of edk2 and we don’t make any modification on it, we just build OpenSBI on edk2 build environment. Yes, edk2 will have its own control of extensions for those firmware code base specific functions. One think we concern about is the conflict of extension ID with vendor extension. Also respond to Anup’s reply, 0xA000000+opensbi_imp_id is the best and simple solution for now. We don’t have to add edk2 as one of SBI implementation and this can also prevent from extension ID conflict with vendor’s ones. We can just take #1 opinion. Any other comments? Will let you know if we miss something later. Thanks to all for supporting ekd2. Abner From: Jonathan Behrens [mailto:behrensj@...] Sent: Sunday, April 12, 2020 10:19 PM To: Anup Patel <Anup.Patel@...> Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Is the code for the extension you want to add going to live in the OpenSBI repository or in the EDK2 repository? If I understand correctly, it would live in the EDK2 repository, meaning that your implementation would actually be downstream from OpenSBI and should have its own implementation ID. If you did this then it seems like everything else would fall out nicely: you could decide on version numbers independently of OpenSBI, there'd be no need for a separate set of firmware IDs, and you'd have full control over all the details of your extension. Jonathan On Sun, Apr 12, 2020 at 8:18 AM Anup Patel <Anup.Patel@...> wrote: Hi Abner, We have two options here: EDK2 can use 0xA000000 + <opensbi_imp_id> as SBI Extension OpenSBI provides a way to EDK2 for overriding SBI implementation ID (preferably using some API) If we go with Option1 above then we don’t need separate SBI implementation ID for EDK2. Let us know what you guys think in this context. Regards, Anup From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Sent: 12 April 2020 14:50 To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: RE: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation This is the PR according to the discussion we had in mail thread. However you may see some confusions from this change. https://github.com/riscv/riscv-sbi-doc/pull/43/commits/e208f23c64f7a6a4be47d6d0ca852433107f6cf4 EDK2 is a SBI implementation? Actually edk2 is not one of the SBI implementations, edk2 fully compliant with OpenSBI and additionally provides the firmware code base SBI extension. We can explain this in the external Firmware code base SBI extension spec (edk2 RISC-V OpenSBI spec), says edk2 SBI implementation actually goes alone with SBI OpenSBI implementation. What is the SBI implementation version associated with EDK2 SBI implementation? This is another confusion because the major SBI implementation is OpenSBI. We also can explain this in the external Firmware code base SBI extension spec, says edk2 SBI implementation version is the version of SBI OpenSBI implementation. Apart from the above proposal, can we have more clear definitions for Firmware code base SBI extension in SBI spec instead of fixing those confusions in the extern spec? The below proposal makes more sense? Define another table for firmware code base, e.g. SBI Firmware Code Base ID. In the table we can have edk2, uboot, Coreboot and etc.. Create a new SBI Base function, sbi_get_firmware_code_base_id() which returns the SBI Firmware Code Base ID. Create a new SBI Base function, sbi_get_firmware_code_base_version() for the version control of firmware code base SBI extension Firmware code base SBI extension is from 0xA000000 to 0xAffffff with Firmware Code Base ID in low bits. I feel the later one makes more sense and clear, how do you think? Abner From: tech-unixplatformspec@... [mailto:tech-unixplatformspec@...] On Behalf Of Abner Chang Sent: Saturday, April 11, 2020 12:08 AM To: Anup Patel <Anup.Patel@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation Cool. This works for edk2. I will have another PR for this. For edk2, we will request a new SBI implementation ID (4) and register firmware code base extension SBI in edk2 SEC phase. From: Anup Patel [mailto:Anup.Patel@...] Sent: Friday, April 10, 2020 11:14 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Jonathan Behrens <behrensj@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation I agree with Jonathan's proposal. Let's have SBI FW extension ID depend on SBI implementation ID. We can target this for SBI v0.3 spec along with System Reboot extension. Regards, Anup Sent from Outlook Mobile From: tech-unixplatformspec@... <tech-unixplatformspec@...> on behalf of Jonathan Behrens <behrensj@...> Sent: Friday, April 10, 2020 7:14:45 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> Cc: Atish Patra <Atish.Patra@...>; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech-unixplatformspec@... <tech-unixplatformspec@...>; Anup Patel <Anup.Patel@...> Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI extension space for firmware code base implementation What I was suggesting is something like: > Implementation specific SBI extension Space, Extension IDs 0x0A000000 through 0x0AFFFFFF. Low bits from SBI Implementation ID. In this scheme, each SBI implementation would have one extension reserved for it: BBL gets 0x0A000000, OpenSBI gets 0x0A000001, Xvisor gets 0x0A000002, KVM gets 0x0A000003, etc. That might not seem like a lot of space, but each extension can have up to 2^32 different functions (including ones for version number discovery, etc.) so it shouldn't actually be limiting. As a side note, I don't think edk2 has an SBI Implementation ID assigned yet. You should just be able to ask for one and get it. Jonathan On Fri, Apr 10, 2020 at 2:23 AM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> wrote: > -----Original Message----- > From: tech-unixplatformspec@... [mailto:tech- > unixplatformspec@...] On Behalf Of Atish Patra > Sent: Friday, April 10, 2020 11:32 AM > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; > behrensj@... > Cc: Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; tech- > unixplatformspec@...; Anup Patel <Anup.Patel@...> > Subject: Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [software] Add SBI > extension space for firmware code base implementation > > On Fri, 2020-04-10 at 01:08 +0000, Chang, Abner (HPS SW/FW > Technologist) wrote: > > Got it, Software ML removed. > > > > Johnathan, do you mean to define it as below? > > Firmware Base Extension, Extension ID: 0xxxxxxxxx (FWBE) , and the > > SBI functions definition is firmware code base implementation- > > specific. > > > > I prefer this one as well. But you should pick any value within experimental > range. Not quite follow this, why pick up one from experimental range? The extension ID must be in the range of 0x0800000-0x08ffffff? I am not sure about the purpose of the extension but if it has the > potential to be a generic SBI extension for firmwares, you should propose it > to the Unix Platform working group. We can add it to the official spec. For those SBI extension which is generic to all firmware code bases, then we should just propose it to the official SBI spec and don’t not have to go with Firmware Base Extension. Firmware Base Extension is classified to those firmware code base specific SBI, for example to load an edk2 driver into M-mode managed memory and executed in M-mode which is behaved as secured system manage mode driver. So the detail Firmware Base Extension would be defined in the separate spec and not part of official sbi spec. Occupied an SBI extension ID is to avoid conflicts. > > > This also works for me and better than to reserve a range of IDs. > > Thanks > > Abner > > > > From: software@... [mailto:software@...] On > > Behalf Of Jonathan Behrens > > Sent: Friday, April 10, 2020 12:39 AM > > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> > > Cc: Atish Patra <Atish.Patra@...>; Anup Patel > <anup.patel@... > > >; Schaefer, Daniel (DualStudy) <daniel.schaefer@...>; > > software@...; tech-unixplatformspec@... > > Subject: Re: [RISC-V] [software] Add SBI extension space for firmware > > code base implementation > > > > I think tech-unixplatformspec@... might be the right list? > > > > To address the PR itself, I'd personally prefer to have this space > > allocated based on SBI implementation IDs analogously to how the > > vendor space is allocated. It also probably makes sense to pick a > > different address range so experimental extension space doesn't have > > to move. > > > > Jonathan > > > > On Thu, Apr 9, 2020 at 4:39 AM Abner Chang via lists.riscv.org < > > abner.chang=hpe.com@...> wrote: > > > Seems opensbi ML is no longer exist? Use software@... > > > insrtead. > > > > > > From: Chang, Abner (HPS SW/FW Technologist) > > > Sent: Thursday, April 9, 2020 4:23 PM > > > To: Atish Patra <Atish.Patra@...>; Anup Patel < > > > anup.patel@...> > > > Cc: opensbi@...; Schaefer, Daniel (DualStudy) < > > > daniel.schaefer@...> > > > Subject: Add SBI extension space for firmware code base > > > implementation > > > > > > Hi Atish and Anup, > > > We are working on some edk2-specific SBI extension which intends to > > > be used by upper layer edk2 drivers. We originally consider to use > > > Vendor Extension space however vendor may have its own proprietary > > > SBI extension as well. In order to prevent from the conflicts of SBI > > > extension space, we propose to have a range for firmware code base. > > > The changes look like the PR below, > > > > > > https://github.com/riscv/riscv-sbi-doc/pull/43 > > > > > > How do you think? > > > Thanks > > > Abner > > > > > > -- > Regards, > Atish > >
More All Messages By This Member

21 - 40 of 1857

Home Hashtags Subgroups Terms