[console] Add Console Switch HLD

[Blueve]

This is high level design document for SONiC Console Switch

Please see: https://github.com/Azure/SONiC/blob/126a4f7af8cadd8451b22bd80227c07c11452a63/doc/console/SONiC-Console-Switch-High-Level-Design.md

[KarthikGengan]

In a hypothetic hardware design, consider when the CPU UART is connected via FPGA / MUX then how to configure those intermediate devices.

Connection details:-

CPU_UART -> FPGA/MUX -> USB B/RJ45 (Console)

Based on FPGA/MUX control setting will be accessed to either USB-B/RJ45.

[Blueve]

In a hypothetic hardware design, consider when the CPU UART is connected via FPGA / MUX then how to configure those intermediate devices.

Connection details:-

CPU_UART -> FPGA/MUX -> USB B/RJ45 (Console)

Based on FPGA/MUX control setting will be accessed to either USB-B/RJ45.

What is the intermediate device for? Seems like they can be a part of console device.
The connection can be simplify to below diagram in current HLD:

Console Device <---usb/rj45(console)---> SONiC Device(has mgmt ip)

I suppose that all devices behind SONiC Device are considered as plug-able part which need a specified implementation which can consume [line number, flow control, baud rate].

[KarthikGengan]

In a hypothetic hardware design, consider when the CPU UART is connected via FPGA / MUX then how to configure those intermediate devices.

Connection details:-

CPU_UART -> FPGA/MUX -> USB B/RJ45 (Console)
Based on FPGA/MUX control setting will be accessed to either USB-B/RJ45.

What is the intermediate device for? Seems like they can be a part of console device.
The connection can be simplify to below diagram in current HLD:

Console Device <---usb/rj45(console)---> SONiC Device(has mgmt ip)

I suppose that all devices behind SONiC Device are considered as plug-able part which need a specified implementation which can consume [line number, flow control, baud rate].

[Blueve]

In a hypothetic hardware design, consider when the CPU UART is connected via FPGA / MUX then how to configure those intermediate devices.

Connection details:-

CPU_UART -> FPGA/MUX -> USB B/RJ45 (Console)
Based on FPGA/MUX control setting will be accessed to either USB-B/RJ45.

What is the intermediate device for? Seems like they can be a part of console device.
The connection can be simplify to below diagram in current HLD:

Console Device <---usb/rj45(console)---> SONiC Device(has mgmt ip)

I suppose that all devices behind SONiC Device are considered as plug-able part which need a specified implementation which can consume [line number, flow control, baud rate].

I think we are not going to design a hardware or involve a specific hardware here to support add-on console device. As an OS, we want to enable SONiC to adapt any other add-on hardware without depends on a specific inner hardware structure.

If we want to support add-on console device by using USB or RJ45, then we need to write a adapter to enable SONiC user to control them by a unified way. Imagine some day, we may want support plug in a console device by using Bluetooth or RF... Just like a mouse, you can use it with USB line and you can use it with a USB Bluetooth adapter and you can use it with laptop built-in Bluetooth... and the only thing you need to do is installing a driver to your OS.

Let me know if there are any misunderstanding : D

• @lguohan for commenting on this, any thoughts?

[KarthikGengan]

In a hypothetic hardware design, consider when the CPU UART is connected via FPGA / MUX then how to configure those intermediate devices.

Connection details:-

CPU_UART -> FPGA/MUX -> USB B/RJ45 (Console)
Based on FPGA/MUX control setting will be accessed to either USB-B/RJ45.

What is the intermediate device for? Seems like they can be a part of console device.
The connection can be simplify to below diagram in current HLD:

Console Device <---usb/rj45(console)---> SONiC Device(has mgmt ip)

I suppose that all devices behind SONiC Device are considered as plug-able part which need a specified implementation which can consume [line number, flow control, baud rate].

I think we are not going to design a hardware or involve a specific hardware here to support add-on console device. As an OS, we want to enable SONiC to adapt any other add-on hardware without depends on a specific inner hardware structure.

If we want to support add-on console device by using USB or RJ45, then we need to write a adapter to enable SONiC user to control them by a unified way. Imagine some day, we may want support plug in a console device by using Bluetooth or RF... Just like a mouse, you can use it with USB line and you can use it with a USB Bluetooth adapter and you can use it with laptop built-in Bluetooth... and the only thing you need to do is installing a driver to your OS.

Let me know if there are any misunderstanding : D

• @lguohan for commenting on this, any thoughts?

Thanks for the update ...

[Staphylo]

The HLD mostly focuses on a design where the console controllers are connected as a USB device or some other kind of external device.
I just want to confirm that the case where the console controller are directly integrated on the switch and managed by kernel drivers in SONiC OS is supported.

You could think of a switch that has a mix of Ethernet and Console front panel ports and manage them all within the same system without any external device and exposing all these consoles as tty in SONiC OS. Would that work as well ?

+-------------------------+       +------------------------+
|  Switch                 |       |  Device 1              |
|  +-------------------+  |       |  +--------+ +--------+ |
|  |SONiC OS           |  |   +------>Console | |Ethernet| |
|  |                   |  |   |   |  +--------+ +--------+ |
|  +-------------------+  |   |   |                        |
|                         |   |   +------------------------+
|  +--------+ +--------+  |   |
|  |Ethernet| |Console1+------+   +------------------------+
|  +--------+ +--------+  |       |  Device 2              |
|  +--------+ +--------+  |       |  +--------+ +--------+ |
|  |Console | |Console2+------------->Console | |Ethernet| |
|  +--------+ +--------+  |       |  +--------+ +--------+ |
|                         |       |                        |
+-------------------------+       +------------------------+

[Blueve]

This is a good question!

This HLD is focus on support external serial hub.
In my view, the top consideration is extensibility: not all serial hub can install a OS but we can still using them.

In other hand, we can also support embedded console ports by exposing them to tty with some adapter, then we can use same flow to control remote devices, what's more, if we don't want to expose tty, we can improve the consult in future to use SAI to manage embedded console ports.

@yxieca could you comments on this? Do we have plan to support embedded console without exposing tty?

[Staphylo]

I don't necessary see the relevance of the serial hub being USB in the design.
A known USB hub will be automatically detected by the kernel and its driver will allocate a tty for each serial port available.
The same applies to serial ports seated directly on the switch and managed by SONiC OS.
A kernel driver will expose them through /dev/tty%s%d

I see in your design that the CONSOLE_PORT_TABLE table of CONFIG_DB seems to support that usecase.
Are the fields in the port table meant to be used this way "/dev/tty%s%d" % (driver, row_name) ?

I would suggest adding a field id since this model would not work if there were different drivers in use.
Each driver gets its own set of ids which means that it's possible to have similar values.
For example /dev/ttyACM0 and /dev/ttyUSB0.
The key could alternatively be "USB1" instead of just "1". Or even "USB|1".

The reason I highlight this is that it would prevent a switch having internal tty ports from having usb tty ports.
You would have to make a choice to avoid key conflict in CONSOLE_PORT_TABLE.

Let me know what you think.

[Blueve]

Yes, actually, the USB topo is just a sample.

Your concern is make sense, that's why we introduce the field "Driver" in CONFIG_DB.

We hoping we can identify a console tty by using port number which means we can't simply use the original device name here, otherwise the conflict might happens just like you mentioned.

In current design, the port number is the unique id, we will aliasing the original tty device name to a specified format to avoid device name conflict or port shifting. Here is another HLD regarding this: https://github.com/Azure/SONiC/pull/654/files

The driver field will help us to build the mapping between the physical port and device name alias.

[Blueve]

Does the design supports command line tools to change baud rate in local devices?Is the design support automatic flow control match to local to remote switches?

I will introduce cli for supporting change baud rate in sonic os in next version HLD.
For flow control, you need to indicate if you want to enable it in config db.

Is the design support friendly sonic CLI in addition to cfg utility?

I will draft this cli design in next version HLD.

How does the design handle console port conflicts with different drivers using the same name? driver + device + line should be part of the port object?

We will create alias device under /dev and the driver should be transparent for us.
For example, you have two drivers USB and ACM, then we will have below devices under /dev:

/dev/ttyACM0
/dev/ttyUSB0

If we have following configuration:

"CONSOLE_PORT:0" { driver: "USB" },
"CONSOLE_PORT:1" { driver: "ACM" }

We hoping we can mapping them to following devices:

/dev/ttySONiC0  (alias of /dev/ttyUSB0)
/dev/ttySONiC1  (alias of /dev/ttyACM0}

There is another HLD for the device name aliasing: https://github.com/Azure/SONiC/pull/654/files
We hoping we can take advantage of the udev rule for the inner device mapping too.

In other hand, no matter which way we will take when implementing, store a "driver" in config db looks good enough. For example, we can group all console port config object by it driver type and then we can finding the origin device by a simple rule, for example we have following configuration objects:

"CONSOLE_PORT:0" { driver: "USB" },
"CONSOLE_PORT:1" { driver: "ACM" },
"CONSOLE_PORT:2" { driver: "USB" },

First step we can grouping them:

# driver = "USB"
[0] CONSOLE_PORT:0
[1] CONSOLE_PORT:2

#driver = "ACM"
[0] CONSOLE_PORT:1

With above indexing, we can find the target device under /dev.

Above are my initial idea, I think they are belong to detail design so I will not put them in this HLD.

[Blueve]

I am going to complete this PR now.
Following comments will be address in next version(0.2):

1. config cli
2. show cli
3. Take advantage of state DB
4. More design detail on the relationship between underlying tty device and console port

I will link new PR here once published for reference.

[Blueve]

#673