Taming The Serial Console
Embedded Linux boards usually can be controlled through a serial port driven directly by a UART block of the SoC (System-On-Chip) at the heart of the board. Without hardware flow control, this interface uses only 2 pins (RX and TX) and the clock itself (baud rate) is generated independantly at both ends. Where such a port was usually exposed through a D-sub connector on older boards, modern boards use a USB-to-serial converter and expose the port on a regular USB micro plug. It is still a serial port, so this post applies to it equally well.
Once the boot-up sequence successfully reaches Linux shell, problems sometimes occur when the command line is very long and the terminal emulator window is larger or smaller than the standard 80 columns by 24 lines. In such situations, the display gets messed up and it is basically impossible to tell what command will be executed on pressing enter. Using ssh to login to a remote board, all of these problems will not even show up - so if you can use ssh you will circumvent the problems described in this post.
On a desktop Linux one usually fixes the problem of a mismatch between the internal representation of the terminal window size and the actual size like this:
dzu@krikkit:~$ eval `resize`
dzu@krikkit:~$
Unfortunatly, the resize program belongs to the xterm package and is thus usually not available on ressource limited embedded boards.
I pushed a small Python tool to codeberg.org which fixes the problem when you have Python3 available on the board.
Read more… (1 min remaining to read)
Too Many SSH Keys
Working with development boards in my local network, ssh started to act up on me when I try to log into one of them:
dzu@krikkit:~$ ssh user@ls1012afrwy
Received disconnect from 192.168.44.102 port 22:2: Too many authentication failures
Disconnected from 192.168.44.102 port 22
dzu@krikkit:~$
This blog post explains why this is caused by seemingly unrelated actions and how to fix it. Before going into the details I will examine the context leading up to this problem.
Read more… (3 min remaining to read)
Fixing Zephyr SDK in Debian Bullseye
On micro-controllers not capable to run a real Linux kernel, there is still the need for a comparable community effort to abstract away the different platforms. One project I find very promising is the Zephyr project which is a Linux Foundation project. Currently I am especially interested in the support for the NXP i.MXRT cross over micro-controllers.
The project delivers cross compilation tool chains for all of the supported architectures (aarch64, arc, arm, mips, nios2, riscv64, sparc, x86_64, xtensa) which are easy to install and use. Since v0.11.3 of ths SDK there is a hidden dependency in the cross-debugger which require python. Those binaries are linked explicitly against python3.8 but Debian Bullseye only offers python3.7 or python3.9. The problem can be seen in this example trying to debug an example Zephyr application in Debian Bullseye:
dzu@krikkit:/opt/src/git/zephyrproject/zephyr (master)$ west debug -d build/lvgl -r pyocd -- west debug: rebuilding [0/1] cd /opt/src/git/zephyrproject/zephyr/build/lvgl/zephyr/cmake/flash && /usr/bin/cmake -E echo -- west debug: using runner pyocd -- runners.pyocd: pyOCD GDB server running on port 3333 /opt/zephyr-sdk-0.12.2/arm-zephyr-eabi/bin/arm-zephyr-eabi-gdb: error while loading shared libraries: libpython3.8.so.1.0: cannot open shared object file: No such file or directory FATAL ERROR: command exited with status 127: /opt/zephyr-sdk-0.12.2/arm-zephyr-eabi/bin/arm-zephyr-eabi-gdb build/lvgl/zephyr/zephyr.elf -ex 'target remote :3333' -ex 'monitor halt' -ex 'monitor reset' -ex load dzu@krikkit:/opt/src/git/zephyrproject/zephyr (master)$
Read more… (4 min remaining to read)
Nikola Blog Posts with Emacs
Starting out my blog a few years ago first required picking one of the available platforms. I can still remember looking around for setups and finding that there were so many to choose from. My only real requirements for the blog were easy to list:
-
Static site generator
-
Easy to interface with git and Emacs
This blog post is about the setup I picked, how I use it and why I think it has been a good idea.
Read more… (2 min remaining to read)
Emacs, Evince and SyncTeX Magic - Look Ma no Code!
In my previous post I showed how it is possible to better integrate the LaTeX editing in Emacs and viewing the result in the GNOME Evince PDF viewer. With the help of SyncTeX it is easy to control click inside the PDF and let Emacs find the corresponding source for it ("inverse search") or to notify Evince out of Emacs to focus on the currently edited area ("forward search").
Some ELisp code recklessly stolen from StackExchange was required to do some plumping but I already noticed that it should be possible to integrate things in a much nicer way. And sure enough, Tassilo Horn commented on Mastodon that the Emacs package AUCTeX already includes all of this (and much more).
Read more… (1 min remaining to read)
GNOME Recent Files
Switching from the GNOME desktop to a shell session, I sometimes wish I could use the recent file list of the desktop system. For example having downloaded a file from Firefox, I want to continue handling this file from within my shell session.
For example I start thinking about the further handling of a download only when the download already started. So in a shell I want to be able to do something like this:
dzu@krikkit:~$ gnome-recent
/home/dzu/Downloads/zephyr-toolchain-arm-0.12.2-x86_64-linux-setup.run
dzu@krikkit:~$ chmod a+x `gnome-recent`
dzu@krikkit:~$ sudo `gnome-recent`
Read more… (1 min remaining to read)
ifconfig, ip, json and jq
Reading articles on Linux Weekly News (LWN) I usually also read the comments as it is not uncommon for people to comment who are actually involved in the topic of discussion. So it is not at all uncommon that the comments significantly contribute to my understanding of the content.
In this vein the discussion on LWN picked my interest as it meandered into why still so many people cling to the ifconfig tool rather than switch to the ip tool meant to replace it for a long time. I was surprised that the first one seems to be obsolete now for over two decades. It appears to me that my attempts to switch to the new tool started only a few years ago, but hey, time flies. Of course such a discussion is quickly dominated by different personal preferences, but one thing struck me and coincides with a lot of my recent thinking - the fact that ip can be told to produce its output in JSON format.
dzu@elementary-vm:~$ ip -4 -j address
[{
"ifindex": 1,
"ifname": "lo",
"flags": ["LOOPBACK","UP","LOWER_UP"],
"mtu": 65536,
"qdisc": "noqueue",
"operstate": "UNKNOWN",
"group": "default",
"txqlen": 1000,
"addr_info": [{
"family": "inet",
"local": "127.0.0.1",
"prefixlen": 8,
"scope": "host",
"label": "lo",
"valid_life_time": 4294967295,
"preferred_life_time": 4294967295
}]
},{
"ifindex": 2,
"ifname": "ens3",
"flags": ["BROADCAST","MULTICAST","UP","LOWER_UP"],
"mtu": 1500,
"qdisc": "fq_codel",
"operstate": "UP",
"group": "default",
"txqlen": 1000,
"addr_info": [{
"family": "inet",
"local": "192.168.122.53",
"prefixlen": 24,
"broadcast": "192.168.122.255",
"scope": "global",
"dynamic": true,
"noprefixroute": true,
"label": "ens3",
"valid_life_time": 3570,
"preferred_life_time": 3570
}]
}
]
dzu@elementary-vm:~$
Read more… (4 min remaining to read)
Emacs, Evince and SyncTeX Magic
The Nokia 7.2 phone I recently bought for my wife required downloading more than a gigabyte of updates after switching it on for the first time. It may seem strange in such quick paced times to use software older than a few years and so I was astonished to find that two important pieces of my digital tool set are more than 30 years old. Both the GNU Emacs editor and the typesetting system LaTeX started life already 36 years ago.
Emacs is usually the first application I launch after a fresh boot and it is rare for me to "M-x kill-emacs" before shutting down the system again some weeks later for a kernel update. Of course the system is suspended to save power when it is not in use.
Having mastered the LaTeX learning curve already back in University it is still my go to system for presentations using the beamer class. Using plain text for presentations allows using git, the version control system of my choice, to track changes in a natural way.
Even though there is this nifty preview latex package for Emacs to embed LaTeX previews right into the editing environment, I haven’t used it for ages. I rather have the GNOME PDF viewer Evince display the generated PDF file on another monitor. Evince watches the PDF for changes, and automatically refreshes the output after another LaTeX run. So usually I do not switch a lot between Emacs and Evince and so this "waterfall" workflow with Evince at the bottom served me well for a long time.
Only by chance I stumbled upon SyncTeX and became interested if my setup was extensible in a way to close the loop more tightly by enabling jumps from the PDF to the source.
Read more… (3 min remaining to read)
Debugging GNOME GThumb
I have been using the GNOME image viewer GThumb on my Debian system for a long time. But only now I started looking into it some more because of a bug that has become more annoying with the pictures taken by our newest smart phones.
As nobody reacted to the bug report so far I thought I might take a look myself. Cloning the gitlab repository is a no-brainer and after installing the required dependencies, latest head of tree also builds nicely. Because of the plug-in architecture, the binary is not easily started from the build directory and so I installed it to /usr/local/bin just like README.md says.
Starting it under gdb I can start looking into why comments get populated all by themselves. Unfortunately, the GLib data structures are not properly decoded by gdb as can be seen in this short transcript:
(gdb) p *settings
$2 = {parent_instance = {g_type_instance = {Python Exception <class 'gdb.error'> No type named TypeNode.:
g_class = }, ref_count = 1, qdata = 0x7fffdc0019f0},
priv = 0x555555f16d40}
(gdb)
Solving this on Debian Buster was not hard, but as I tend to forget the details I decided to turn my notes into this short blog post.
Read more… (4 min remaining to read)
acme - Power of Simplicity
Coming from an MS-DOS background, I immediately fell in love with the Unix Programming Environment when I first encountered it. The idea of treating the "user" not as a "consumer" of large isolated and monolithic "applications" but rather provide a toolbox allowing to quickly assemble non-trivial ad-hoc programs in the form of pipelines utterly changed my take on how to use computers.
In a way, the Unix shell and the Unix tools are an "Integrated Development Environment" (IDE for short) although nowadays people believe that behemoths like Eclipse or Microsoft Visual Studio are IDEs.
However the original Unix toolkit lacked an integrated editor and so the full potential of the Unix Philosophy in One Lesson remained untapped for some time. (In case you are unfamiliar with the Art of Unix Programming I suggest reading all of it just in case.)
Enter Plan 9 from Bell Labs.
Read more… (4 min remaining to read)