Separate out platform sections from original document

The very first draft of the spec contained three sections: User Level
Platform, Supervisor Level Platform and Machine Level Platform.  This
change moves those to individual files; note that there was no content
for machine level, so there was no need for an additional file.

This is a structural change only.  All content remains the same.

It is unclear where the content in these files will eventually end up.
The outline of the spec is certain to change and how the content here
gets used is still to be determined.

Signed-off-by: Al Stone <[email protected]>

Makefile

@@ -5,7 +5,8 @@
 ASCIIDOCTOR = asciidoctor
 PLATFORM_SPEC = riscv-platform-spec
 PANDOC = pandoc
-PARTS = changelog.adoc contributors.adoc introduction.adoc licensing.adoc
+PARTS = changelog.adoc contributors.adoc introduction.adoc licensing.adoc \
+	supervisor-level.adoc user-level.adoc
 
 # Build the platform spec in several formats
 all: $(PLATFORM_SPEC).md $(PLATFORM_SPEC).pdf $(PLATFORM_SPEC).html

riscv-platform-spec.adoc

@@ -26,41 +26,13 @@ include::changelog.adoc[]
 // Introduction: describe the intent and purpose of the document
 include::introduction.adoc[]
 
-## User-Level Platform
+// User-Level Platform (NB: content from very first version)
+include::user-level.adoc[]
 
-* User-mode environments must implement at least version 2.2 of the RISC-V User
-  ISA specification, which can be found at
-  https://github.com/riscv/riscv-isa-manual/blob/master/release/riscv-spec-v2.2.pdf.  
-* User-mode programs may not execute the `fence.i` instruction.
-* User-mode environments may provide additional ISA extensions, but if those
-  extensions add user-visible state they must be initially disabled.
-* Within main-memory regions, aligned instruction fetch must be atomic, up to
-  the smaller of ILEN and XLEN bits.  In particular, if an aligned 4-byte word
-  is stored with the `sw` instruction, then any processor attempts to execute
-  that word, the processor either fetches the newly stored word, or some previous
-  value stored to that location.  (That is, the fetched instruction is not an
-  unpredictable value, nor is it a hybrid of the bytes of the old and new
-  values.)
-
-## Supervisor-Level Platform
-
-* Supervisor-mode environments must implement at least version 0.2.0 of the
-  RISC-V SBI specification, which can be found at
-  https://github.com/riscv/riscv-sbi-doc/blob/v0.2.0/riscv-sbi.adoc
-* Supervisor-mode environments must implement the Sv39 page-based
-  virtual-memory scheme.   Systems that support Sv48 must support Sv39, systems
-  that support Sv57 must support Sv48, and so forth.
-* Unless otherwise specified by a given I/O device, I/O regions are at least
-  point-to-point strongly ordered.  All devices attached to a given PCIe root
-  complex are on the same ordered channel (numbered 2 or above), though
-  different root complexes might not be on the same ordering channel.
-* On RV64I-based Unix-class systems the negative virtual addresses are reserved
-  for the kernel.
-* External devices (DMA engines, the debug unit, non RISC-V cores, etc) that
-  are visible to RISC-V harts must appear as coherent agents, just like any
-  RISC-V hart would.  If additional ordering constraints are necessary for a
-  device to function, those will be provide by a device-specific mechanism.
+// Supervisor-Level Platform (NB: content from very first version)
+include::supervisor-level.adoc[]
 
+// Machine-Level Platform (NB: content from very first version)
 ## Machine-Level Platform
 
 ## Profiles

supervisor-level.adoc

@@ -0,0 +1,26 @@
+// SPDX-License-Indentifer: CC-BY-4.0
+//
+// supervisor-level.adoc: original Supervisor Level Platform content
+//
+// This is material from the very first draft of the spec.
+//
+
+## Supervisor-Level Platform
+
+* Supervisor-mode environments must implement at least version 0.2.0 of the
+  RISC-V SBI specification, which can be found at
+  https://github.com/riscv/riscv-sbi-doc/blob/v0.2.0/riscv-sbi.adoc
+* Supervisor-mode environments must implement the Sv39 page-based
+  virtual-memory scheme.   Systems that support Sv48 must support Sv39, systems
+  that support Sv57 must support Sv48, and so forth.
+* Unless otherwise specified by a given I/O device, I/O regions are at least
+  point-to-point strongly ordered.  All devices attached to a given PCIe root
+  complex are on the same ordered channel (numbered 2 or above), though
+  different root complexes might not be on the same ordering channel.
+* On RV64I-based Unix-class systems the negative virtual addresses are reserved
+  for the kernel.
+* External devices (DMA engines, the debug unit, non RISC-V cores, etc) that
+  are visible to RISC-V harts must appear as coherent agents, just like any
+  RISC-V hart would.  If additional ordering constraints are necessary for a
+  device to function, those will be provide by a device-specific mechanism.
+

user-level.adoc

@@ -0,0 +1,23 @@
+// SPDX-License-Indentifer: CC-BY-4.0
+//
+// user-level.adoc: original User Level Platform content
+//
+// This is material from the very first draft of the spec.
+//
+
+## User-Level Platform
+
+* User-mode environments must implement at least version 2.2 of the RISC-V User
+  ISA specification, which can be found at
+  https://github.com/riscv/riscv-isa-manual/blob/master/release/riscv-spec-v2.2.pdf.  
+* User-mode programs may not execute the `fence.i` instruction.
+* User-mode environments may provide additional ISA extensions, but if those
+  extensions add user-visible state they must be initially disabled.
+* Within main-memory regions, aligned instruction fetch must be atomic, up to
+  the smaller of ILEN and XLEN bits.  In particular, if an aligned 4-byte word
+  is stored with the `sw` instruction, then any processor attempts to execute
+  that word, the processor either fetches the newly stored word, or some previous
+  value stored to that location.  (That is, the fetched instruction is not an
+  unpredictable value, nor is it a hybrid of the bytes of the old and new
+  values.)
+