Writing text to a graphical console device

I want to write text to the LCD screen, e.g.
echo "text" > /dev/tty0

During kernel boot-up I see the message:
Console: switching to colour frame buffer device 100x37
So presumably with a frambuffer device configured for a particular font it should be possible to display text to the LCD.
However, I don't know where my LCD text-device is mapped in the /dev folder. I have a frambuffer device at /dev/fb0, but it doesn't display text directly if I echo to it. I can just display images to it using the fbv program.
I've tried most of the nodes in /dev/, e.g. tty0-6, ttyO0-6 (0 is my serial console), vcs, vcsa...
I was told to check for an fbcon device. There's no node called fbcon, but I found it here:

bash-4.2# ls /sys/class/graphics/ fb0 fbcon bash-4.2# ls /sys/class/graphics/fbcon cursor_blink power rotate rotate_all subsystem uevent

I set cursor_blink to 1, to see if I'd get a cursor displayed, but there's none visible. I've built U-Boot with splash screen support and it's able to display console messages to the LCD, so I know it works and should be possible. However, I can't figure out how.
I also had a look at the virtual console devices:

bash-4.2# ls /sys/class/vtconsole/vtcon0/ bind name power subsystem uevent bash-4.2# cat /sys/class/vtconsole/vtcon0/name (S) dummy device bash-4.2# bash-4.2# cat /sys/class/vtconsole/vtcon1/name (M) frame buffer device

but that's not given me anymore clues... and I'm not sure that doing bind/unbind is going to give me somewhere to write text to.

Could anyone suggest next steps please?

It's generally best not to guess when dealing with the Linux kernel. It's something like 15 million lines of code. See the documentation here:

http://lxr.free-electrons.com/source...on/devices.txt

It says /dev/tty is your current tty device.

cat foo >/dev/tty 
Hello, world!

One of the issues with a booting system is that there is no terminal (/dev/tty) necessarily assigned to the process. There IS a /dev/log socket that is used by init - but that has to be passed to the process as stderr/stdout or it doesn't work. If you are systemd based, stderr should be put into the log.

My terminal console is via the serial port at /dev/ttyO0. It's an AM335x CPU and the board is pretty similar to their General Purpose EVM.
I've seen people assigning the console=/dev/fb0 in bootargs, I don't want the console to be on the LCD screen, I just want to write to the LCD screen separately from the console.

I've been looking into using fbcon=map:0 in the bootargs, but it seems to be getting ignored because the frame buffer is not the primary console (check enabled with CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY kernel option).

The problem is partly that the console terminals are not initialized.

Normally they are addressed as /dev/tty1 through /dev/tty12 (could be more, usually 1 is used for boot messages, but that is up to what the kernel considers the console), These are kernel terminal emulations that should be capable of display; at least it works for me (echo "testing" >/dev/tty1 as root). They are supposed to be equivalent to a vt100, but there are escape sequences not supported. The actual terminal type is "linux", which is a bit different from a vt100.

There are times it won't work (as in "shouldn't") because they are not logged in, but MIGHT have getty/mgetty attached for initialization and login. This is specially true for reading from the keyboard. One symptom of an unitialized terminal is when a newline ('\n') character doesn't get translated into "\r\n". Once the terminal is initialized it should work normally.

Selection of which virtual terminal to view is selected by alt-f<n> where <n> is the virtual terminal (1-12 usually) to display. In your situation, I would guess that only /dev/tty1 is accessible unless you have a keyboard also attached.

(sorry, keep forgetting things) The number of virtual terminals supported is a kernel option. If the kernel doesn't have virtual terminals configured, then terminal like output to the frame buffer will not work. You will have to have a custom application to draw to the framebuffer. Note, I have never done that since the libvga disappeared from support. Similar capability is possible - you can look at the plymouth splash screens to see how that may be done.

Turned out that a systemd process was starting the xserver, which is then in control of the /dev/fb0 colour frame buffer, and therefore the other mappings to it from /dev/tty<n> don't work. I commented out the process:

#ExecStart=/usr/bin/Xfbdev -nolisten tcp -noreset -nocursor -screen 800x600x16 -dpi 95 -fb /dev/fb0 -mouse tslib

When I disabled that process, I was able to type to the LCD console using /dev/tty0 and /dev/tty1. However, since the touchscreen was being controlled by Xfbdev, then the screen backlight times out.
I wasn't able to turn on the screen through /sys:

echo "1" > /sys/class/graphics/fb0/blank

I just decided not to bother with the touchscreen and have enabled the display permanently with:
setterm -blank 0 > /dev/tty0 < /dev/tty0

fbdef is put on a different virtual terminal that /dev/tty1 (though which one depends on your distribution, but I think it uses the first uninitialized virtual terminal).

And rather than commenting it out (which will cause an error in your logs, as well as get replaced by updates), select a different final target. Since it is still a basic server, use "multi-user.target", which will not start the GUI (which is done by graphical.target; make the switch with the command "systemctl set-default multi-user.target").

It's an embedded system (that's why I posted in this forum), so there is no updates on it. The xinit.service was written by us for starting the touch-screen and LCD, but for testing purposes we don't need that, should be ok to remove that file, or comment out it's processes. There's nothing else starting in systemd that depends on it.

not sure if it works the same with embeded systems, but if I recall correctly /dev/fb0 is a framebuffer device, which is used for graphics such as graphically rendering the text graphially, but doesn't directly take text as an input.

what you need is to find the TTY for the device (/dev/ttyO0) or maybe it's a /dev/pts/X and send text to that, since a framebuffer device isn't a text interface it's a graphical interface that functions similarly to an X server, and the vrtual TTY simply runs on top of that.