Date   

Re: [PATCH 1/1] Add README

atishp@...
 

On Thu, 2020-05-28 at 10:54 +0200, Schaefer, Daniel Helmut (DualStudy)
wrote:
Signed-off-by: Daniel Schaefer <daniel.schaefer@...>
---
README.adoc | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 README.adoc

diff --git a/README.adoc b/README.adoc
new file mode 100644
index 0000000..2c479eb
--- /dev/null
+++ b/README.adoc
@@ -0,0 +1,17 @@
+= RISC-V SBI specification
+
+SBI (Supervisor Binary Interface) is an interface between the
Supervisor
+Execution Environment (SEE) and the supervisor. It allows the
supervisor to
+execute some privileged operations by using the ecall instruction.
Examples of
+SEE and supervisor are: M-Mode and S-Mode on Unix-class platforms,
where SBI is
+the only interface between them, as well as the Hypervisor extended-
Supervisor
+(HS) and Virtualized Supervisor (VS).
+
+Discussion of SBI occurs on the
+https://lists.riscv.org/g/tech-unixplatformspec[RISC-V Unix Platform
Mailing
+list]. It is publicly readable but posting requires being a member
of the
+RISC-V Foundation. Any new SBI extension needs to be discussed and
approved
+there before being merged.
+
+https://github.com/riscv/opensbi[OpenSBI] is the reference
implementation,
+but other implementations exist; see section "SBI Implementation
IDs".
Looks good to me. Merged to master.

--
Regards,
Atish


Event: Unix platform working group meeting (06/09 8AM PST) @ Tue June 09, 2020 8am - 9am (PST) - Tuesday, 9 June 2020 #cal-invite

tech-unixplatformspec@lists.riscv.org Calendar <tech-unixplatformspec@...>
 

Unix platform working group meeting (06/09 8AM PST) @ Tue June 09, 2020 8am - 9am (PST)

When:
Tuesday, 9 June 2020
8:00am to 9:00am
(UTC-07:00) America/Los Angeles

Where:
webex

Description:

Hi,

The next unix platform specification working group meeting is scheduled on 9th June 8AM PST.

The agenda:
 - The system reset extension
    -- https://github.com/riscv/riscv-sbi-doc/pull/39
-  Discuss the changes that were merged after SBI v0.2 is tagged
-  How to deal with errors unspecified in the SBI specification
      - https://github.com/riscv/riscv-sbi-doc/pull/51
-  Future roadmap 

Looking forward to catching up with everyone.
 

Regards,

Atish

 

Options to Join this Meeting

From any computer or mobile deviceClick to Join WebEx.  

From any video conference unit, enter "54 161 501 6405" from remote or touch panel.

Meeting password: 7SEy784483545 (77397844 from phones)



Toll and Toll free numbers are billed at a higher per minute rate. Follow the below instructions for cost effective conferencing.
1. Click link above to join WebEx meeting.
2. Once you are in the meeting, click the Phone icon and select 'Call Me'.
3. Enter your full number, starting with country code followed by remaining digits. The system will then place a call to that number.

If you are unable to use WebEx 'Call Me' or 'Call Using Computer' features, use the following dial in numbers:

Join by phone
+1-408-717-7733 USA Toll
Meeting Number: 161 501 6405

Global call-in numbers

 


Unix platform working group future agenda (to be discussed in next meeting (06/09 8AM PST))

atishp@...
 

Hi All,
I would like to start a thread to discuss the topics that should go
into the unix platform specification apart from SBI & PLIC. SBI
specification is already tagged as v0.2 & PLIC specification will
follow.

Here is the current version if unix platform specification.


https://github.com/riscv/riscv-platform-specs/blob/master/riscv-unix.adoc

I think the spec definitely needs to have a lot more content than it
currently has :)

Here are some suggestions. This is just a small list that I can think
of right now. I am pretty sure we need to have more
sections/subsections with more details.

1. Register state requirement:
- S-mode CSR state before entering to S-mode
- GPR state before entering to S-mode (e.g a0 must contain
hartid, a1 must contain DT address)

2. Runtime firmware requirement:
- Platform runtime firmware must implement SBI v0.2
specification. We can avoid legacy implementations in future if we
make this mandatory now. But, I am open to other suggestions
as well.
- RISC-V ISA allows hardware not to implement misaligned
load/store. platform runtime firmware must implement it if it
is not implemented in hardware.
- TIME csr emulation support if not implemented in HW
- HTIMEDELTA csr emulation support (for platforms with hypervisor support)
- This section can link to the SBI specification.

3. Memory requirement
- DRAM start address
- memory model supported
- Boot address alignment requirement (2MB/4MB for 64bit/32bit)
- other requirement ?

4. Interrupt requirement
- What should be PLIC state upon entering S-mdoe
- Can link to the PLIC specifications
- local interrupt controller (CLIC/CLINT) ?

5. I/O devices ?

I am hoping this can initiate the discussion and we can continue that
during the working group meetings as well. The next platform
specification working group is scheduled on 9th June(06/09) 8AM PST.

FYI: The meeting webex link is available in calendar. Let me know if
you have any issues accessing that.


--
Regards,
Atish


Re: Unix platform working group future agenda (to be discussed in next meeting (06/09 8AM PST))

Greg Favor
 

One additional topic:  All the various architecture specs have little to lots of optional features or parameters that can be implementation-specific.  Some of these probably want to have minimum requirements specified in the Linux platform spec (similar to what the ARM SBSA does, for example).  For example:

A minimum reservation set size for LR/SC.

Minimum supported ASID size.

Minimum number and width of hardware performance counters.  Support for the small set of standard Linux perf mon events. 

If the Hypervisor extension is supported:
   Minimum supported VMID size
   Full support for CSR's like htval and htinst

Past RV64GC, what other extensions should be required?  For example, the BitManip Zba/Zbb/Zbs extensions (and maybe Zbc) have value for general compiled code?  In the future the hypervisor and vector extensions probably want to become a requirement (but as say part of a future next "level" of platform spec).

Minimum and recommended mtime frequency.

Standard system watchdog timer?

Standard system UART for early boot communication.

The Debug spec (which provides facilities for self-hosted as well as external debug) has most features as optional.  At least for self-hosted debug purposes, should there be a minimum set of trigger module requirements for how many triggers and what trigger features are available?

Presenting on-chip peripherals as PCIe integrated endpoints?  (SBSA provides a lot of standardization along these lines.  But this may be a bridge too far at this early stage of platform standardization.)

Greg

On Tue, Jun 2, 2020 at 6:08 PM Atish Patra <atish.patra@...> wrote:
Hi All,
I would like to start a thread to discuss the topics that should go
into the unix platform specification apart from SBI & PLIC. SBI
specification is already tagged as v0.2 & PLIC specification will
follow.

Here is the current version if unix platform specification.


https://github.com/riscv/riscv-platform-specs/blob/master/riscv-unix.adoc

I think the spec definitely needs to have a lot more content than it
currently has  :)

Here are some suggestions. This is just a small list that I can think
of right now. I am pretty sure we need to have more
sections/subsections with more details.

1. Register state requirement:
        - S-mode CSR state before entering to S-mode
        - GPR state before entering to S-mode (e.g a0 must contain     
  hartid, a1 must contain DT address)

2. Runtime firmware requirement:
        - Platform runtime firmware must implement SBI v0.2             
specification. We can avoid legacy implementations in future      if we
make this mandatory now. But, I am open to other          suggestions
as well.
        - RISC-V ISA allows hardware not to implement misaligned       
  load/store. platform runtime firmware must implement it if it         
  is not implemented in hardware.
        - TIME csr emulation support if not implemented in HW
        - HTIMEDELTA csr emulation support (for platforms with           hypervisor support)
        - This section can link to the SBI specification.

3. Memory requirement
        - DRAM start address
        - memory model supported
        - Boot address alignment requirement (2MB/4MB for 64bit/32bit)
        - other requirement ?

4. Interrupt requirement
        - What should be PLIC state upon entering S-mdoe
        - Can link to the PLIC specifications
        - local interrupt controller (CLIC/CLINT) ?

5. I/O devices ?

I am hoping this can initiate the discussion and we can continue that
during the working group meetings as well. The next platform
specification working group is scheduled on 9th June(06/09) 8AM PST.

FYI: The meeting webex link is available in calendar. Let me know if
you have any issues accessing that.


--
Regards,
Atish




Re: Unix platform working group future agenda (to be discussed in next meeting (06/09 8AM PST))

Greg Favor
 

On Tue, Jun 2, 2020 at 6:08 PM Atish Patra <atish.patra@...> wrote:
3. Memory requirement
        - DRAM start address

Any requirement for some amount of DRAM below 4G, and located whether?

Should the first 4KB page (at system address 0x0) be covered by a fixed "empty" PMA region?  (This is also convenient for mapping the Debug Module at 0x0 when in Debug Mode for "execution-based" style implementations of the Debug spec.)
 
        - memory model supported
        - Boot address alignment requirement (2MB/4MB for 64bit/32bit)
        - other requirement ?

Should there be requirements around supporting the key components of a standard "Linux platform" boot flow?

Greg
 


Re: Unix platform working group future agenda (to be discussed in next meeting (06/09 8AM PST))

Andrew Waterman
 



On Tue, Jun 2, 2020 at 7:32 PM Greg Favor <gfavor@...> wrote:
One additional topic:  All the various architecture specs have little to lots of optional features or parameters that can be implementation-specific.  Some of these probably want to have minimum requirements specified in the Linux platform spec (similar to what the ARM SBSA does, for example).  For example:

A minimum reservation set size for LR/SC.

Minimum supported ASID size.

Minimum number and width of hardware performance counters.  Support for the small set of standard Linux perf mon events. 

If the Hypervisor extension is supported:
   Minimum supported VMID size
   Full support for CSR's like htval and htinst

Past RV64GC, what other extensions should be required?  For example, the BitManip Zba/Zbb/Zbs extensions (and maybe Zbc) have value for general compiled code?  In the future the hypervisor and vector extensions probably want to become a requirement (but as say part of a future next "level" of platform spec).

Since standard binary distributions don’t cope well with extensions being rolled out at a rapid clip, my thinking is that we should batch extensions together and roll them out periodically, say, every couple years. Hopefully this makes it easier for HW vendors to chart their roadmaps, too.

RV64GC is already a supported standard in this domain, and IMO, Zb* don’t offer quite great enough an improvement to justify their own new set of standard binaries. OTOH, RVV will hopefully be ratified this year, and that’s absolutely a big enough delta to justify recompilation and redistribution. So I figured we’d roll Zb* together with that.

(Obviously, the -march=native/Gentoo fans can take advantage of the latest and greatest whenever they want. I speak only to standard binary distributions.)


Minimum and recommended mtime frequency.

Standard system watchdog timer?

Standard system UART for early boot communication.

The Debug spec (which provides facilities for self-hosted as well as external debug) has most features as optional.  At least for self-hosted debug purposes, should there be a minimum set of trigger module requirements for how many triggers and what trigger features are available?

Presenting on-chip peripherals as PCIe integrated endpoints?  (SBSA provides a lot of standardization along these lines.  But this may be a bridge too far at this early stage of platform standardization.)

Greg

On Tue, Jun 2, 2020 at 6:08 PM Atish Patra <atish.patra@...> wrote:
Hi All,
I would like to start a thread to discuss the topics that should go
into the unix platform specification apart from SBI & PLIC. SBI
specification is already tagged as v0.2 & PLIC specification will
follow.

Here is the current version if unix platform specification.


https://github.com/riscv/riscv-platform-specs/blob/master/riscv-unix.adoc

I think the spec definitely needs to have a lot more content than it
currently has  :)

Here are some suggestions. This is just a small list that I can think
of right now. I am pretty sure we need to have more
sections/subsections with more details.

1. Register state requirement:
        - S-mode CSR state before entering to S-mode
        - GPR state before entering to S-mode (e.g a0 must contain     
  hartid, a1 must contain DT address)

2. Runtime firmware requirement:
        - Platform runtime firmware must implement SBI v0.2             
specification. We can avoid legacy implementations in future      if we
make this mandatory now. But, I am open to other          suggestions
as well.
        - RISC-V ISA allows hardware not to implement misaligned       
  load/store. platform runtime firmware must implement it if it         
  is not implemented in hardware.
        - TIME csr emulation support if not implemented in HW
        - HTIMEDELTA csr emulation support (for platforms with           hypervisor support)
        - This section can link to the SBI specification.

3. Memory requirement
        - DRAM start address
        - memory model supported
        - Boot address alignment requirement (2MB/4MB for 64bit/32bit)
        - other requirement ?

4. Interrupt requirement
        - What should be PLIC state upon entering S-mdoe
        - Can link to the PLIC specifications
        - local interrupt controller (CLIC/CLINT) ?

5. I/O devices ?

I am hoping this can initiate the discussion and we can continue that
during the working group meetings as well. The next platform
specification working group is scheduled on 9th June(06/09) 8AM PST.

FYI: The meeting webex link is available in calendar. Let me know if
you have any issues accessing that.


--
Regards,
Atish




Re: Unix platform working group future agenda (to be discussed in next meeting (06/09 8AM PST))

Greg Favor
 

On Tue, Jun 2, 2020 at 7:46 PM Andrew Waterman <andrew@...> wrote:
Since standard binary distributions don’t cope well with extensions being rolled out at a rapid clip, my thinking is that we should batch extensions together and roll them out periodically, say, every couple years. Hopefully this makes it easier for HW vendors to chart their roadmaps, too.

I completely agree.  So maybe the initial "level 1" platform spec is just RV64GC.  We would have liked to have the basic Zb* extensions included, but if the train has left the station for current standard binary Linux distros, then oh well (sadly).

Btw, are there really "standard" binary Linux distros for RISC-V currently available?

One last thought and observation:  Since this platform spec probably won't be finalized for a while (although I am all for sooner the better), it seems like Level 1 will be lagging the ecosystem and not until Level 2 will the platform spec provide leadership to the hardware and software ecosystem.

This is like what happened with ARM SBSA - where Level 0 reflected the state of early / legacy systems and then it wasn't until Level 1 that SBSA provided some leadership to where the hardware and software ecosystem should be heading towards.  Both levels were defined pretty much concurrently.

The point maybe is just that we should work to lay down a next level spec fairly soon behind establishment of the first level spec.
 
Greg


Re: Unix platform working group future agenda (to be discussed in next meeting (06/09 8AM PST))

David Abdurachmanov
 

On Wed, Jun 3, 2020 at 6:36 AM Greg Favor <gfavor@...> wrote:

On Tue, Jun 2, 2020 at 7:46 PM Andrew Waterman <andrew@...> wrote:

Since standard binary distributions don’t cope well with extensions being rolled out at a rapid clip, my thinking is that we should batch extensions together and roll them out periodically, say, every couple years. Hopefully this makes it easier for HW vendors to chart their roadmaps, too.

I completely agree. So maybe the initial "level 1" platform spec is just RV64GC. We would have liked to have the basic Zb* extensions included, but if the train has left the station for current standard binary Linux distros, then oh well (sadly).
/me puts Fedora/RISCV distro hat on

Just to clarify the base will continue to be RV64GC and any other
extension would be supported by optimized binaries (e.g. libraries
compiled with extra extensions flags) and by ifunc in GCC/glibc (or
other means). The actual base would stay as RV64GC. Simply put don't
expect Linux distribution to rebootstrap with a different base ISA.

I do recall that you can turn on a lot of newer ARMv8.X stuff and that
will work just fine on older silicon because it will be interpreted as
NOPs on older ARMv8.X silicon.

We need to avoid issues like we had with the SHAKTI project. Their 1st
silicon is RV64G and thus not capable of running Linux distribution
and they asked several times on how to rebuild the entire Fedora/RISCV
just for RV64GC to run on their stuff.

I personally would expect vector and hypervisor extensions to be quite
popular for *nix ecosystem.


Btw, are there really "standard" binary Linux distros for RISC-V currently available?
There are many distributions available for RV64GC (Fedora, Debian,
Ubuntu, OpenSUSE and some others). We have been bootstrapping &
building them for almost 4 years.
They run on QEMU, SiFive HiFive Unleashed, Andes stuff, FPGAs, etc.


One last thought and observation: Since this platform spec probably won't be finalized for a while (although I am all for sooner the better), it seems like Level 1 will be lagging the ecosystem and not until Level 2 will the platform spec provide leadership to the hardware and software ecosystem.
IIRC from Linaro/ARM the idea was to have something minimal ASAP. You
can expand later on as the ecosystem grows.

david


This is like what happened with ARM SBSA - where Level 0 reflected the state of early / legacy systems and then it wasn't until Level 1 that SBSA provided some leadership to where the hardware and software ecosystem should be heading towards. Both levels were defined pretty much concurrently.

The point maybe is just that we should work to lay down a next level spec fairly soon behind establishment of the first level spec.

Greg


Re: Unix platform working group future agenda (to be discussed in next meeting (06/09 8AM PST))

Andrew Waterman
 



On Tue, Jun 2, 2020 at 8:36 PM Greg Favor <gfavor@...> wrote:
On Tue, Jun 2, 2020 at 7:46 PM Andrew Waterman <andrew@...> wrote:
Since standard binary distributions don’t cope well with extensions being rolled out at a rapid clip, my thinking is that we should batch extensions together and roll them out periodically, say, every couple years. Hopefully this makes it easier for HW vendors to chart their roadmaps, too.

I completely agree.  So maybe the initial "level 1" platform spec is just RV64GC.  We would have liked to have the basic Zb* extensions included, but if the train has left the station for current standard binary Linux distros, then oh well (sadly).

It left the station a couple years ago, so don’t feel like you barely missed it.


Btw, are there really "standard" binary Linux distros for RISC-V currently available?

I’ve only personally used Debian, but that’s a “yes”.


One last thought and observation:  Since this platform spec probably won't be finalized for a while (although I am all for sooner the better), it seems like Level 1 will be lagging the ecosystem and not until Level 2 will the platform spec provide leadership to the hardware and software ecosystem.

I would separate ABI from platform here.  User-visible ISA features are a heavier lift, since they affect orders of magnitude more software. I imagine there’s more flexibility on the user-invisible stuff, as long as the changes can be masked with device drivers, SBI stuff, etc.


This is like what happened with ARM SBSA - where Level 0 reflected the state of early / legacy systems and then it wasn't until Level 1 that SBSA provided some leadership to where the hardware and software ecosystem should be heading towards.  Both levels were defined pretty much concurrently.

The point maybe is just that we should work to lay down a next level spec fairly soon behind establishment of the first level spec.

Yeah.

 
Greg


Re: Unix platform working group future agenda (to be discussed in next meeting (06/09 8AM PST))

Jonathan Behrens <behrensj@...>
 

Is a specification for bootloader behavior considered in scope for the platform spec?  Describing the initial register state and boot address alignment suggests that it is, but there's also more that goes into a modern bootloader than just that. Is the idea that what we're defining would be used to load GRUB or similar, and that bootloader would chainload the actual OS using a more sophisticated interface (like say Multiboot2)? Relatedly, where would UEFI fit into all of this?

Jonathan

On Wed, Jun 3, 2020 at 2:27 AM Andrew Waterman via lists.riscv.org <andrew=sifive.com@...> wrote:


On Tue, Jun 2, 2020 at 8:36 PM Greg Favor <gfavor@...> wrote:
On Tue, Jun 2, 2020 at 7:46 PM Andrew Waterman <andrew@...> wrote:
Since standard binary distributions don’t cope well with extensions being rolled out at a rapid clip, my thinking is that we should batch extensions together and roll them out periodically, say, every couple years. Hopefully this makes it easier for HW vendors to chart their roadmaps, too.

I completely agree.  So maybe the initial "level 1" platform spec is just RV64GC.  We would have liked to have the basic Zb* extensions included, but if the train has left the station for current standard binary Linux distros, then oh well (sadly).

It left the station a couple years ago, so don’t feel like you barely missed it.


Btw, are there really "standard" binary Linux distros for RISC-V currently available?

I’ve only personally used Debian, but that’s a “yes”.


One last thought and observation:  Since this platform spec probably won't be finalized for a while (although I am all for sooner the better), it seems like Level 1 will be lagging the ecosystem and not until Level 2 will the platform spec provide leadership to the hardware and software ecosystem.

I would separate ABI from platform here.  User-visible ISA features are a heavier lift, since they affect orders of magnitude more software. I imagine there’s more flexibility on the user-invisible stuff, as long as the changes can be masked with device drivers, SBI stuff, etc.


This is like what happened with ARM SBSA - where Level 0 reflected the state of early / legacy systems and then it wasn't until Level 1 that SBSA provided some leadership to where the hardware and software ecosystem should be heading towards.  Both levels were defined pretty much concurrently.

The point maybe is just that we should work to lay down a next level spec fairly soon behind establishment of the first level spec.

Yeah.

 
Greg


Re: Unix platform working group future agenda (to be discussed in next meeting (06/09 8AM PST))

atishp@...
 

On Wed, 2020-06-03 at 12:16 -0400, Jonathan Behrens wrote:
Is a specification for bootloader behavior considered in scope for
the platform spec? Describing the initial register state and boot
address alignment suggests that it is, but there's also more that
goes into a modern bootloader than just that. Is the idea that what
we're defining would be used to load GRUB or similar, and that
bootloader would chainload the actual OS using a more sophisticated
interface (like say Multiboot2)? Relatedly, where would UEFI fit into
all of this?
For boot loader behavior specification, the plan is to follow EBBR for
embedded devices. Currently, there are ongoing efforts to support UEFI
in Linux kernel and EDK2 for RISC-V. Once, all the changes are
available, RISC-V will be EBBR compliant.

We just need to modify EBBR to make generic embedded boot requirement
specification rather than an ARM specific one.

It is much more complicated for server class platforms and needs a lot
more attention.

Jonathan

On Wed, Jun 3, 2020 at 2:27 AM Andrew Waterman via lists.riscv.org <
andrew=sifive.com@...> wrote:

On Tue, Jun 2, 2020 at 8:36 PM Greg Favor <gfavor@...>
wrote:
On Tue, Jun 2, 2020 at 7:46 PM Andrew Waterman <andrew@...
wrote:
Since standard binary distributions don’t cope well with
extensions being rolled out at a rapid clip, my thinking is
that we should batch extensions together and roll them out
periodically, say, every couple years. Hopefully this makes it
easier for HW vendors to chart their roadmaps, too.
I completely agree. So maybe the initial "level 1" platform spec
is just RV64GC. We would have liked to have the basic Zb*
extensions included, but if the train has left the station for
current standard binary Linux distros, then oh well (sadly).
It left the station a couple years ago, so don’t feel like you
barely missed it.

Btw, are there really "standard" binary Linux distros for RISC-V
currently available?
I’ve only personally used Debian, but that’s a “yes”.

One last thought and observation: Since this platform spec
probably won't be finalized for a while (although I am all for
sooner the better), it seems like Level 1 will be lagging the
ecosystem and not until Level 2 will the platform spec provide
leadership to the hardware and software ecosystem.
I would separate ABI from platform here. User-visible ISA features
are a heavier lift, since they affect orders of magnitude more
software. I imagine there’s more flexibility on the user-invisible
stuff, as long as the changes can be masked with device drivers,
SBI stuff, etc.

This is like what happened with ARM SBSA - where Level 0
reflected the state of early / legacy systems and then it wasn't
until Level 1 that SBSA provided some leadership to where the
hardware and software ecosystem should be heading towards. Both
levels were defined pretty much concurrently.

The point maybe is just that we should work to lay down a next
level spec fairly soon behind establishment of the first level
spec.
Yeah.


Greg
--
Regards,
Atish


Re: Unix platform working group future agenda (to be discussed in next meeting (06/09 8AM PST))

Tommy Thorn <tommy.thorn@...>
 

The Unix spec has so far (AFAIUI) not required anything about DRAM starting address as long as it's stated in the DT.
Esperanto Tech's Maxion cannot have DRAM below 4 GB as that memory space is reserved.
We don't seem to have run into assumptions in the Linux kernel nor openSBI.

The only issue I can think of is some legacy devices that cannot DMA to a 64-bit address.
We don't except supporting those, but we do have a limited ability for bounce buffering.

Tommy



On Tue, Jun 2, 2020 at 7:42 PM Greg Favor <gfavor@...> wrote:
On Tue, Jun 2, 2020 at 6:08 PM Atish Patra <atish.patra@...> wrote:
3. Memory requirement
        - DRAM start address

Any requirement for some amount of DRAM below 4G, and located whether?

Should the first 4KB page (at system address 0x0) be covered by a fixed "empty" PMA region?  (This is also convenient for mapping the Debug Module at 0x0 when in Debug Mode for "execution-based" style implementations of the Debug spec.)
 
        - memory model supported
        - Boot address alignment requirement (2MB/4MB for 64bit/32bit)
        - other requirement ?

Should there be requirements around supporting the key components of a standard "Linux platform" boot flow?

Greg
 


Re: Unix platform working group future agenda (to be discussed in next meeting (06/09 8AM PST))

David Abdurachmanov
 

Atish,

Could I circulate WebEx meeting information to people outside RISC-V
Foundation? In particular I would like to see if we could get
engineers from Red Hat, SUSE and Canonical to join. Red Hat is a
member of foundation so that's probably an easy answer.

david

On Wed, Jun 3, 2020 at 4:08 AM Atish Patra <atish.patra@...> wrote:

Hi All,
I would like to start a thread to discuss the topics that should go
into the unix platform specification apart from SBI & PLIC. SBI
specification is already tagged as v0.2 & PLIC specification will
follow.

Here is the current version if unix platform specification.


https://github.com/riscv/riscv-platform-specs/blob/master/riscv-unix.adoc

I think the spec definitely needs to have a lot more content than it
currently has :)

Here are some suggestions. This is just a small list that I can think
of right now. I am pretty sure we need to have more
sections/subsections with more details.

1. Register state requirement:
- S-mode CSR state before entering to S-mode
- GPR state before entering to S-mode (e.g a0 must contain
hartid, a1 must contain DT address)

2. Runtime firmware requirement:
- Platform runtime firmware must implement SBI v0.2
specification. We can avoid legacy implementations in future if we
make this mandatory now. But, I am open to other suggestions
as well.
- RISC-V ISA allows hardware not to implement misaligned
load/store. platform runtime firmware must implement it if it
is not implemented in hardware.
- TIME csr emulation support if not implemented in HW
- HTIMEDELTA csr emulation support (for platforms with hypervisor support)
- This section can link to the SBI specification.

3. Memory requirement
- DRAM start address
- memory model supported
- Boot address alignment requirement (2MB/4MB for 64bit/32bit)
- other requirement ?

4. Interrupt requirement
- What should be PLIC state upon entering S-mdoe
- Can link to the PLIC specifications
- local interrupt controller (CLIC/CLINT) ?

5. I/O devices ?

I am hoping this can initiate the discussion and we can continue that
during the working group meetings as well. The next platform
specification working group is scheduled on 9th June(06/09) 8AM PST.

FYI: The meeting webex link is available in calendar. Let me know if
you have any issues accessing that.


--
Regards,
Atish



Re: Unix platform working group future agenda (to be discussed in next meeting (06/09 8AM PST))

atishp@...
 

On Thu, 2020-06-04 at 15:34 +0300, David Abdurachmanov wrote:
Atish,

Could I circulate WebEx meeting information to people outside RISC-V
Foundation? In particular I would like to see if we could get
engineers from Red Hat, SUSE and Canonical to join. Red Hat is a
member of foundation so that's probably an easy answer.
Yeah. I would love to allow anybody (RISC-V foundation member or not)
to jump into the discussions. However, foundation has strict rules on
who can participate in the working group meetings. That's why I
couldn't send the meeting invite to the public mailing list.

Anybody who
is a member can join. If their organization is already a member, they
just need to sign up using the org's email address or they can sign up
as an individual member (I think it's free to be an individual member
now).

david

On Wed, Jun 3, 2020 at 4:08 AM Atish Patra <atish.patra@...>
wrote:
Hi All,
I would like to start a thread to discuss the topics that should go
into the unix platform specification apart from SBI & PLIC. SBI
specification is already tagged as v0.2 & PLIC specification will
follow.

Here is the current version if unix platform specification.


https://github.com/riscv/riscv-platform-specs/blob/master/riscv-unix.adoc

I think the spec definitely needs to have a lot more content than
it
currently has :)

Here are some suggestions. This is just a small list that I can
think
of right now. I am pretty sure we need to have more
sections/subsections with more details.

1. Register state requirement:
- S-mode CSR state before entering to S-mode
- GPR state before entering to S-mode (e.g a0 must contain
hartid, a1 must contain DT address)

2. Runtime firmware requirement:
- Platform runtime firmware must implement SBI v0.2
specification. We can avoid legacy implementations in
future if we
make this mandatory now. But, I am open to
other suggestions
as well.
- RISC-V ISA allows hardware not to implement misaligned
load/store. platform runtime firmware must implement it if it
is not implemented in hardware.
- TIME csr emulation support if not implemented in HW
- HTIMEDELTA csr emulation support (for platforms
with hypervisor support)
- This section can link to the SBI specification.

3. Memory requirement
- DRAM start address
- memory model supported
- Boot address alignment requirement (2MB/4MB for
64bit/32bit)
- other requirement ?

4. Interrupt requirement
- What should be PLIC state upon entering S-mdoe
- Can link to the PLIC specifications
- local interrupt controller (CLIC/CLINT) ?

5. I/O devices ?

I am hoping this can initiate the discussion and we can continue
that
during the working group meetings as well. The next platform
specification working group is scheduled on 9th June(06/09) 8AM
PST.

FYI: The meeting webex link is available in calendar. Let me know
if
you have any issues accessing that.


--
Regards,
Atish


--
Regards,
Atish


Re: Unix platform working group future agenda (to be discussed in next meeting (06/09 8AM PST))

atishp@...
 

On Tue, 2020-06-02 at 19:32 -0700, Greg Favor wrote:
One additional topic: All the various architecture specs have little
to lots of optional features or parameters that can be
implementation-specific. Some of these probably want to have minimum
requirements specified in the Linux platform spec (similar to what
the ARM SBSA does, for example). For example:

A minimum reservation set size for LR/SC.

Minimum supported ASID size.

Minimum number and width of hardware performance counters. Support
for the small set of standard Linux perf mon events.

If the Hypervisor extension is supported:
Minimum supported VMID size
Full support for CSR's like htval and htinst

Past RV64GC, what other extensions should be required? For example,
the BitManip Zba/Zbb/Zbs extensions (and maybe Zbc) have value for
general compiled code? In the future the hypervisor and vector
extensions probably want to become a requirement (but as say part of
a future next "level" of platform spec).
As discussed, RV64GC should be the minimum required extensions to boot
Linux.

Minimum and recommended mtime frequency.
Sure. I think most of the above should be specified in the
specification. I am hoping somebody will send a PR now :-):-).

Standard system watchdog timer?
AFAIK, we don't have any system watchdog timer in any of the current
RISC-V hardware. May be we can defer this ?

Standard system UART for early boot communication.
Do we have to say which standard UART ?
An uart must be available but the implementation details doesn't need
go into the platform spec.

The Debug spec (which provides facilities for self-hosted as well as
external debug) has most features as optional. At least for self-
hosted debug purposes, should there be a minimum set of trigger
module requirements for how many triggers and what trigger features
are available?
Is it a common practice to mandate a subset of debug spec in a platform
specification?

Presenting on-chip peripherals as PCIe integrated endpoints? (SBSA
provides a lot of standardization along these lines. But this may be
a bridge too far at this early stage of platform standardization.)
I guess so.

Greg

On Tue, Jun 2, 2020 at 6:08 PM Atish Patra <atish.patra@...>
wrote:
Hi All,
I would like to start a thread to discuss the topics that should go
into the unix platform specification apart from SBI & PLIC. SBI
specification is already tagged as v0.2 & PLIC specification will
follow.

Here is the current version if unix platform specification.


https://github.com/riscv/riscv-platform-specs/blob/master/riscv-unix.adoc

I think the spec definitely needs to have a lot more content than
it
currently has :)

Here are some suggestions. This is just a small list that I can
think
of right now. I am pretty sure we need to have more
sections/subsections with more details.

1. Register state requirement:
- S-mode CSR state before entering to S-mode
- GPR state before entering to S-mode (e.g a0 must contain

hartid, a1 must contain DT address)

2. Runtime firmware requirement:
- Platform runtime firmware must implement SBI v0.2

specification. We can avoid legacy implementations in future
if we
make this mandatory now. But, I am open to other
suggestions
as well.
- RISC-V ISA allows hardware not to implement misaligned

load/store. platform runtime firmware must implement it if it

is not implemented in hardware.
- TIME csr emulation support if not implemented in HW
- HTIMEDELTA csr emulation support (for platforms with
hypervisor support)
- This section can link to the SBI specification.

3. Memory requirement
- DRAM start address
- memory model supported
- Boot address alignment requirement (2MB/4MB for
64bit/32bit)
- other requirement ?

4. Interrupt requirement
- What should be PLIC state upon entering S-mdoe
- Can link to the PLIC specifications
- local interrupt controller (CLIC/CLINT) ?

5. I/O devices ?

I am hoping this can initiate the discussion and we can continue
that
during the working group meetings as well. The next platform
specification working group is scheduled on 9th June(06/09) 8AM
PST.

FYI: The meeting webex link is available in calendar. Let me know
if
you have any issues accessing that.

--
Regards,
Atish


Re: Unix platform working group future agenda (to be discussed in next meeting (06/09 8AM PST))

David Kruckemyer
 

Hi all,

I would add a few more (somewhat related) topics:

- Minimum set of "standard" PMA combinations, e.g. "Normal" and "Device" types in ARM or "WB" and "UC" types in x86
- Maybe a standard PMA architecture, or support for a PMA API/driver? (Perhaps this is a lower-level software thing....)
- Zam requirements?
- Support or non-support for LR/SCs and AMOs in I/O regions, i.e. just a clear statement whether they are required or not
- Channel 1+ I/O ordering requirements?

Thanks!

Cheers,
David


On Thu, Jun 4, 2020 at 11:45 PM Atish Patra <atish.patra@...> wrote:
On Tue, 2020-06-02 at 19:32 -0700, Greg Favor wrote:
> One additional topic:  All the various architecture specs have little
> to lots of optional features or parameters that can be
> implementation-specific.  Some of these probably want to have minimum
> requirements specified in the Linux platform spec (similar to what
> the ARM SBSA does, for example).  For example:
>
> A minimum reservation set size for LR/SC.
>
> Minimum supported ASID size.
>
> Minimum number and width of hardware performance counters.  Support
> for the small set of standard Linux perf mon events.
>
> If the Hypervisor extension is supported:
>    Minimum supported VMID size
>    Full support for CSR's like htval and htinst
>
> Past RV64GC, what other extensions should be required?  For example,
> the BitManip Zba/Zbb/Zbs extensions (and maybe Zbc) have value for
> general compiled code?  In the future the hypervisor and vector
> extensions probably want to become a requirement (but as say part of
> a future next "level" of platform spec).
>

As discussed, RV64GC should be the minimum required extensions to boot
Linux.

> Minimum and recommended mtime frequency.
>

Sure. I think most of the above should be specified in the
specification. I am hoping somebody will send a PR now :-):-).

> Standard system watchdog timer?
>

AFAIK, we don't have any system watchdog timer in any of the current
RISC-V hardware. May be we can defer this ?

> Standard system UART for early boot communication.
>

Do we have to say which standard UART ?
An uart must be available but the implementation details doesn't need
go into the platform spec.

> The Debug spec (which provides facilities for self-hosted as well as
> external debug) has most features as optional.  At least for self-
> hosted debug purposes, should there be a minimum set of trigger
> module requirements for how many triggers and what trigger features
> are available?
>

Is it a common practice to mandate a subset of debug spec in a platform
specification?

> Presenting on-chip peripherals as PCIe integrated endpoints?  (SBSA
> provides a lot of standardization along these lines.  But this may be
> a bridge too far at this early stage of platform standardization.)
>

I guess so.

> Greg
>
> On Tue, Jun 2, 2020 at 6:08 PM Atish Patra <atish.patra@...>
> wrote:
> > Hi All,
> > I would like to start a thread to discuss the topics that should go
> > into the unix platform specification apart from SBI & PLIC. SBI
> > specification is already tagged as v0.2 & PLIC specification will
> > follow.
> >
> > Here is the current version if unix platform specification.
> >
> >
> > https://github.com/riscv/riscv-platform-specs/blob/master/riscv-unix.adoc
> >
> > I think the spec definitely needs to have a lot more content than
> > it
> > currently has  :)
> >
> > Here are some suggestions. This is just a small list that I can
> > think
> > of right now. I am pretty sure we need to have more
> > sections/subsections with more details.
> >
> > 1. Register state requirement:
> >         - S-mode CSR state before entering to S-mode
> >         - GPR state before entering to S-mode (e.g a0 must contain
> >     
> >   hartid, a1 must contain DT address)
> >
> > 2. Runtime firmware requirement:
> >         - Platform runtime firmware must implement SBI v0.2       
> >       
> > specification. We can avoid legacy implementations in future     
> > if we
> > make this mandatory now. But, I am open to other         
> > suggestions
> > as well.
> >         - RISC-V ISA allows hardware not to implement misaligned   
> >     
> >   load/store. platform runtime firmware must implement it if it   
> >     
> >   is not implemented in hardware.
> >         - TIME csr emulation support if not implemented in HW
> >         - HTIMEDELTA csr emulation support (for platforms with     
> >      hypervisor support)
> >         - This section can link to the SBI specification.
> >
> > 3. Memory requirement
> >         - DRAM start address
> >         - memory model supported
> >         - Boot address alignment requirement (2MB/4MB for
> > 64bit/32bit)
> >         - other requirement ?
> >
> > 4. Interrupt requirement
> >         - What should be PLIC state upon entering S-mdoe
> >         - Can link to the PLIC specifications
> >         - local interrupt controller (CLIC/CLINT) ?
> >
> > 5. I/O devices ?
> >
> > I am hoping this can initiate the discussion and we can continue
> > that
> > during the working group meetings as well. The next platform
> > specification working group is scheduled on 9th June(06/09) 8AM
> > PST.
> >
> > FYI: The meeting webex link is available in calendar. Let me know
> > if
> > you have any issues accessing that.
> >
> >

--
Regards,
Atish




Platform memory map

Nagendra Gulur
 

I joined the group recently and not sure that I have all the context yet for what the group's charter and current scope are.
However, I was exchanging email with Andrew Waterman about RV32 cores and system integration standardization.

Specifically, I was wondering where the mtime and mtimecmp registers were memory-mapped per the privileged spec.
And the answer is that this is a platform-level decision and not in the scope of the privileged spec.

Next, I took a brief look at the documentations from SiFive and ETH/Pulp for RV32-based SoCs.
Their SoC-level memory maps are completely different. Neither is compatible with ARM CxM either.

These differences start to matter if we want to establish more standard ways to assemble SoCs, use standard debug/link tools (such as IAR or Lauterbach for example), or to develop consistent boot loader modules and so on. 

It would be quite useful to bring some attention to this problem of SoC-level fragmentation.
At a high level, on the memory mapping topic, one might provide a broad specification of where on-chip memories go, where flash/nvm goes, and peripheral spaces, etc. 

My apologies if this is a repetition of what has already been discussed before. 

Best Regards
Nagendra


Re: Platform memory map

Andrew Waterman
 

I just want to say unequivocally that trying to emulate the Cortex-M memory map in the Unix platform is a short-sighted idea that will only cause extra trouble.

These platforms aren’t compatible anyway. You can’t run Linux on a Cortex-M. Cortex-A memory maps don’t look like Cortex-M memory maps, for good reason.

On Fri, Jun 5, 2020 at 3:45 PM Nagendra Gulur <nagendra.gd@...> wrote:
I joined the group recently and not sure that I have all the context yet for what the group's charter and current scope are.
However, I was exchanging email with Andrew Waterman about RV32 cores and system integration standardization.

Specifically, I was wondering where the mtime and mtimecmp registers were memory-mapped per the privileged spec.
And the answer is that this is a platform-level decision and not in the scope of the privileged spec.

Next, I took a brief look at the documentations from SiFive and ETH/Pulp for RV32-based SoCs.
Their SoC-level memory maps are completely different. Neither is compatible with ARM CxM either.

These differences start to matter if we want to establish more standard ways to assemble SoCs, use standard debug/link tools (such as IAR or Lauterbach for example), or to develop consistent boot loader modules and so on. 

It would be quite useful to bring some attention to this problem of SoC-level fragmentation.
At a high level, on the memory mapping topic, one might provide a broad specification of where on-chip memories go, where flash/nvm goes, and peripheral spaces, etc. 

My apologies if this is a repetition of what has already been discussed before. 

Best Regards
Nagendra


Re: Platform memory map

Nagendra Gulur
 

Yes absolutely. I wrote an RV32 MCU question to the unix platform spec group which is my bad.

Best Regards
Nagendra


On Sat, Jun 6, 2020 at 8:58 AM Andrew Waterman <andrew@...> wrote:
I just want to say unequivocally that trying to emulate the Cortex-M memory map in the Unix platform is a short-sighted idea that will only cause extra trouble.

These platforms aren’t compatible anyway. You can’t run Linux on a Cortex-M. Cortex-A memory maps don’t look like Cortex-M memory maps, for good reason.

On Fri, Jun 5, 2020 at 3:45 PM Nagendra Gulur <nagendra.gd@...> wrote:
I joined the group recently and not sure that I have all the context yet for what the group's charter and current scope are.
However, I was exchanging email with Andrew Waterman about RV32 cores and system integration standardization.

Specifically, I was wondering where the mtime and mtimecmp registers were memory-mapped per the privileged spec.
And the answer is that this is a platform-level decision and not in the scope of the privileged spec.

Next, I took a brief look at the documentations from SiFive and ETH/Pulp for RV32-based SoCs.
Their SoC-level memory maps are completely different. Neither is compatible with ARM CxM either.

These differences start to matter if we want to establish more standard ways to assemble SoCs, use standard debug/link tools (such as IAR or Lauterbach for example), or to develop consistent boot loader modules and so on. 

It would be quite useful to bring some attention to this problem of SoC-level fragmentation.
At a high level, on the memory mapping topic, one might provide a broad specification of where on-chip memories go, where flash/nvm goes, and peripheral spaces, etc. 

My apologies if this is a repetition of what has already been discussed before. 

Best Regards
Nagendra


Upcoming Event: Unix platform working group meeting (06/09 8AM PST) @ Tue June 09, 2020 8am - 9am (PST) - Tue, 06/09/2020 8:00am-9:00am #cal-reminder

tech-unixplatformspec@lists.riscv.org Calendar <tech-unixplatformspec@...>
 

Reminder: Unix platform working group meeting (06/09 8AM PST) @ Tue June 09, 2020 8am - 9am (PST)

When: Tuesday, 9 June 2020, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles

Where:webex

View Event

Description: Hi,

The next unix platform specification working group meeting is scheduled on 9th June 8AM PST.

The agenda:
 - The system reset extension
    -- https://github.com/riscv/riscv-sbi-doc/pull/39
-  Discuss the changes that were merged after SBI v0.2 is tagged
-  How to deal with errors unspecified in the SBI specification
      - https://github.com/riscv/riscv-sbi-doc/pull/51
-  Future roadmap 

Looking forward to catching up with everyone.
 

Regards,

Atish

 

Options to Join this Meeting

From any computer or mobile deviceClick to Join WebEx.  

From any video conference unit, enter "54 161 501 6405" from remote or touch panel.

Meeting password: 7SEy784483545 (77397844 from phones)



Toll and Toll free numbers are billed at a higher per minute rate. Follow the below instructions for cost effective conferencing.
1. Click link above to join WebEx meeting.
2. Once you are in the meeting, click the Phone icon and select 'Call Me'.
3. Enter your full number, starting with country code followed by remaining digits. The system will then place a call to that number.

If you are unable to use WebEx 'Call Me' or 'Call Using Computer' features, use the following dial in numbers:

Join by phone
+1-408-717-7733 USA Toll
Meeting Number: 161 501 6405

Global call-in numbers

 

61 - 80 of 1847