Re: [PATCH v1 2/2] Section 3.1.4 System Peripherals.

Alistair Francis

On Sun, 2021-04-11 at 12:22 -0400, Jonathan Behrens wrote:

On Sun, Apr 11, 2021 at 11:46 AM Heinrich Schuchardt via <> wrote:
On 4/11/21 5:02 PM, Mayuresh Chitale wrote:
This patch is an initial draft for the section
3.1.4 - System Peripherals.

Signed-off-by: Mayuresh Chitale <mchitale@...>
   riscv-platform-spec.adoc | 31 +++++++++++++++++++++++++++----
   1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 003181c..f164545 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -52,10 +52,33 @@ include::profiles.adoc[]
   * Interrupt Assignments

   ==== System Peripherals
-* UART/Serial Console
-* Clocks
-* Timers
-* Watchdog Timers
+* *UART/Serial Console* +
+In order to facilitate the bringup and debug of the low level
initial platform
+software(firmware, bootloaders, kernel etc), the platform shall
implement a UART
+port compatible with PC16550D.
Is software compatibility with PC16550D free of copyright
(We should not disallow open hardware.)

Strict PC16550D compatibility would for instance preclude usage of
voltages. Is this really needed?

Isn't it enough to to have any UART that at least supports

For software, it very much matters that the register layout and
behavior match some standard. Otherwise you would need to ship
drivers for essentially every uart ever made (which might be
acceptable to Linux because it already has them, but would be wasted
effort for anyone else). 
Isn't this the Linux and other Rich OS spec though?


That said, this spec shouldn’t be specifying the physical
implementation of the uart. It should be allowed to use a
real PC16550D, a lower voltage one, a uart tunneled over Ethernet, or
even an entirely emulated uart (say for  a VM).


Join to automatically receive all group messages.