It is completely feasible and is in fact the essence of pre-GUI Unix'es, circa 1970, that this was the only modus operandi available to connect a console terminal to a Unix computer. The legacy of this convention is still with us (and it is not anachronistic though perhaps obscure and subliminal in today's micro-computer systems) and available, especially with embedded systems that lack consoles with builtin keyboards and monitors like the actual devices at this website
(Marvel's U-Boot is the host computer's Linux OS derivative).
There are two issues that need to be addressed.
The physical connection is only part of the answer as already discussed.
A CLI
(command line interpreter) or other console
terminal interface running on the host is also required.
Details:
step 1. The physical connection can be tested (and hardware settings controlled such as port
selected, baud rate
, parity
, etc.) with utilities like: moserial
, gtkterm
, minicom
, putty
, ... with elementary data and file transfer capabilities.
(Somewhat obtusely, the next step, 2, is not needed if ls >dir-list.txt
is done on one machine and then a utility (like moserial) is used to send the directory listing file to the other.)
step 2. To actually use the connection to control the host from the client requires a command interface on the host using utilities like: getty
, screen
, ... . Here are basic descriptions of using getty
or the screen
Ubuntu lucid manpages to do it. The client can often use just a "simple" serial port communication utility as in step 1. Programs such as screen
or kermit
are usually run on both host and client machines. If using gkermit
on the host though, a console communication session must already be established, such as with getty
.