Topics

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


Atish Patra
 

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


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




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
 


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




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


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


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


Jonathan Behrens
 

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


Atish Patra
 

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


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
 


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



Atish Patra
 

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


Atish Patra
 

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


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




Atish Patra
 

I have gathered all the requirements discussed till now and created a google doc.

https://docs.google.com/document/d/1sLYZJrK38R_QWj5KjogxU2vjJSTIq0bJjZu57djuGoA/edit?usp=sharing

The plan is to regularly update this document so that we keep a tab of all the requirements that should go into the platform specification.

It will also help to identify which sections should be mandatory and added now.

If anybody is interested to expand a particular area, you can edit the document or send a patch directly.

 

 


Greg Favor
 

On Thu, Jun 4, 2020 at 11:45 PM Atish Patra <atish.patra@...> wrote:
> 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 ?

Yes, I imagine so.  Eventually this would be desirable as a very basic form of RAS, i.e when the system is hung or in livelock, this would bring control back to system firmware (to log, recover, reboot, etc.).


> Standard system UART for early boot communication.
>

Do we have to say which standard UART ?

This is desirable for the sake of early boot software (before it's convenient to be loading in platform-specific drivers).  (As a side-note, when ARM SBSA first mandated this, it painfully blew it by not standardizing a little detail like the clock frequency for the UART.)

In any case, this and surrounding comments are about standardizing basics of the platform that provide no differentiation value and just complicate life when one wants to get to a world where one can take a compliant platform, install standard binaries, and have it all work out of the box.  Not an issue for embedded systems, but certainly important if and when RISC-V is going to get into parts of the server or edge compute space.
 
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?

In embedded systems, probably.  But, as noted above, desirable on standardized server-class systems (even if going into high-end embedded "infrastructure" type systems - which are increasingly looking more like Linux servers platforms and less like classic embedded Linux systems).
 

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

Hopefully this suggestion makes more sense given my comments above.  Not necessary for embedded systems, but very desirable for high-end embedded and server-class systems (as ARM took a long time to realize).

Greg


alankao
 
Edited

Since we don't have the chance to discuss the topics on the agenda in the meeting, please allow me to post two comments from Andes here:

DRAM start address
Is there any good reason to standardize it?
I also notice that both BBL and OpenSBI have default start address at 0x80000000, but is there any reason why 0x0 is not a good configuration?

> Minimum number and width of hardware performance counters.  Support for the small set of standard Linux perf mon events
We have made a proposal in privileged task group, https://lists.riscv.org/g/tech-privileged-archive/message/488?p=,,,20,0,0,0::Created,,Proposal,20,2,40,32306071
For those who don't access to privileged task group, please check https://github.com/riscv/riscv-isa-manual/issues/402
This can provide the minimum functionality for perf to work. Any comments are welcome.


Greg Favor
 

DRAM start address
Is there any good reason to standardize it?
I also notice that both BBL and OpenSBI have default start address at 0x80000000, but is there any reason why 0x0 is not a good configuration?

Note that it can generally be useful to have 4K page 0x0 be no man's land (e.g. catch a bad PA pointer dereference), and that a number of implementations of the RISC-V Debug spec have the Debug Module and the Debug-Mode code located specifically in page 0x0 (so as to avoid the need for freeing up a GPR to serve as a D-mode base register).  (In the latter case, that debug stuff in page 0x0 might only be accessible while in D-mode.)

Greg

 


Josh Scheid
 


On Wed, Jun 3, 2020 at 4:46 PM Tommy Thorn <tommy.thorn@...> wrote:
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.

It was a deal in the last decade.  There was concern for support for boot devices like non-64-bit addressing capable USB, 32-bit BARs in PCI and possibly other such older protocols.  Without requiring IOMMUs to be able to redirect those devices, or platform-specific PA-PCI address fixed offset functionality, things get difficult.  A solution is to enable allocating both some system memory and some IO (e.g., PCI space) in the low 4 GiB. 

This isn't a problem for systems that control all attached devices, but for systems that want to have robust support for plug-in stuff (USB, PCI, SATA?), it's a consideration.

The platform spec can not address this, but the group should do so consciously.

-Josh