Building a samus image with `build_image --enable_serial=ttyS0` doesn't yield a login shell on the servo UART (ttyS0), though it *does* produce kernel log output. The problem is twofold, it seems:

(a) /dev/ttyS0 yields EIO errors when read/written to
(b) we never specify TTY_CONSOLE=ttyS0 in the samus overlay ($TTY_CONSOLE generates the upstart jobs which launch consoles)

---
Note that (b) is actually true of many/most Intel overlays. e.g., I see these in cyan's make.defaults:

# Un-comment these lines to enable the serial port.
# TTY_CONSOLE="ttyS0"
# USE="pcserial"
---

Anyway, we can't reasonably resolve (b) without resolving (a), or else we'll see the console jobs keep failing/respawning.

FWIW, copying some email conversations from a few months back:

--- From dlaurie ---
I definitely noticed the same thing during samus development, and I believe I ended up with the same conclusion that getty wasn't working because /dev/ttyS0 returned errors, but did not dig into why that was the case.

I seem to recall that this does work on other platforms that use this EC, but we do have a known bug in the TI LM4 chip that we had to work around in firmware: https://chromium-review.googlesource.com/#/c/184421/

It is possible something changed in the kernel (a long time ago now because samus is 3.14) that is now tripping over the same issue.  Or I could be mis-remembering the behavior on other platforms with that EC and it has been broken for longer than I thought...
---
---Reply from briannorris ---
FWIW, I see the same behavior on both our official 3.14 kernel and our (WIP, experimental) v4.4 kernel. I mostly noticed because it's been a pain while working on the rebase and testing on samus. But it's not insurmountable. At least I can still get the kernel log on ttyS0, which saves me from buggy kernels!
---