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 plugcomputer dot org as described in the article
slash plugwiki slash index dot php slash Setting_up_Serial_Console_Under_Linux
(Sorry, new users can only post a maximum of two hyperlinks)
(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.