[RFC] Add Fbterm support on Boston for Chinese VGA output

[klauskiwi]

Check commit(s) here - https://github.com/open-power/op-build/pull/3895/commits for the most up-to-date description

[klauskiwi]

So the issue about spawning on VGA instead of fb0, is that udev will process the rules in some order, and apparently the SUBSYSTEM==tty KERNEL=tty[0-9] devices will appear before the fb0 device is ready, so the test in the .profile file fails, but it succeeds once we recycle it (because fb0 would already be there).

I couldn't find how to fix that (with conditionals or waiting) on udev, so for now I'm removing tty1 and adding fb0: https://github.com/open-power/op-build/pull/3895/files#diff-daadf20349d8fe48b7e9c6a0035a4b24a3895d8772f99bb04ca783b43c8e1619R4

But it would be good to find an elegant solution that can work even on fb-less, or head-less servers.

Thoughts are welcome!

[klauskiwi]

Why do we need fbterm rather than a UTF-8 console and the rendering out the VGA port to be done BMC side?

Apparently some users are expecting Chinese characters to appear in the physical VGA port (which is the same output shown on the iKVM interface in the BMC). So despite SoL (or any serial) console working (because the decoding is done at the client terminal), the physical VGA output doesn't.

After some testing and research, this appears to be a limitation within the Linux (VGA) console itself (i.e. even on x64 architecture), and the only way to solve it is by using a terminal emulator. The one that is the most lightweight is fbterm.

[klauskiwi]

I submitted the wqy-zenhei package upstream, any reviews or justifications on why we need this would be appreciated: http://lists.busybox.net/pipermail/buildroot/2020-November/296243.html

[klauskiwi]

I submitted the wqy-zenhei package upstream, any reviews or justifications on why we need this would be appreciated: http://lists.busybox.net/pipermail/buildroot/2020-November/296243.html

FYI, the wqy-zenhei package addition was merged upstream.