|
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.adocI 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
|
|
|
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
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
|
|
|
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
|
|
|
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
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
|
|
|
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
|
|
|
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
|
|
|
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.
|
|
|
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 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.
|
|
|
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 <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: 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
|
|
|
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
toggle quoted message
Show quoted text
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
|
|
|
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
|
|
|
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
|
|
|
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 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
|
|
|
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.
|
|
|
> 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
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.
|
|
|
> 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
|
|
|
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
|
|
|
