On Sun, Apr 11, 2021 at 11:46 AM Heinrich Schuchardt via lists.riscv.org <xypron.glpk=gmx.de@...> 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 restrictions?
(We should not disallow open hardware.)

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

Isn't it enough to to have any UART that at least supports 115200,8N1?

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

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

Jonathan