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.
CLI (command line interpreter) or other
console terminal interface running on the host is also required.
step 1. The physical connection can be tested (and hardware settings controlled such as
parity, etc.) with utilities like:
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:
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
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