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