0xStubs – System Administration, Reconfigurable Computing and Other Random Topics

openSUSE Tumbleweed on the StarFive VisionFive 2

October 2, 2023 / By Michael / In System Administration / Leave Comment

In March, I wrote about my initial contact with the StarFive VisionFive 2 board. Since then, StarFive released a couple of new releases of their Debian-based operating system. However, these releases are still based on a Debian unstable snapshot from 2022 and a Linux 5.15.0 kernel that contains several severe vulnerabilities. Updating the image is not possible without breaking their custom fixes to mesa.

By now there are also dozens of distributions available for the board. Many of them rely on StarFive’s outdated kernel sources. Others merge those kernel sources with more recent upstream patches or selectively apply StarFive patches on up-to-date mainline kernel sources. However, looking at the current status of the upstreaming efforts for the JH7110 SoC, it shows that most parts of the SoC are supported in mainline Linux 6.6. The most important part missing is certainly the HDMI output.

As I am using the board purely headless, i.e., without any display, HDMI does not matter for me. With that, openSUSE Tumbleweed looked very interesting to me, currently coming with a stock Linux 6.6-rc3 kernel and stock u-boot 2023.10-rc4 and promising regular, rolling updates. However, it comes with several issues, namely:

It boots up with 8 GiB of memory visible to the kernel – no matter how much memory your board has. If you have less than 8 GiB, segmentation faults will bite you.
Lots of hardware that should work with the supplied kernel does not. For example, PCIe, USB, thermal sensors, SPI, etc…
It feels slow, in particular when I/O on the SD card is involved.
It does not properly shutdown. Instead, in most cases, the board freezes on shutdown and the file systems need a check on next boot.

By now I could fix most of these issues. If you are interested or affected yourself, read through the solutions / workarounds below.

Using the C++ bool type in HPC codes

August 3, 2023 / By Michael / In HPC, Programming / Leave Comment

When writing C++ code, you are probably inclined to use data types that are closest to what you are trying to express, expecting that this allows the compiler to provide the most efficient implementation possible. So, when processing boolean values, i.e., single-bit information distinguishing between true and false, you will likely want to use the bool type in C++. However, this bool type may behave in unexpected ways, in particular if you are working with codes that have to perform well and correctly in multi-threaded codes.

“touch -r $< $@” in Makefiles – Please don’t

May 15, 2023 / By Michael / In System Administration / Leave Comment

Recently I had a bad memory module in my main storage system which is also the backup target of many of my systems. To be on the safe side, I validated all backed up files against their origin via checksums. Interestingly, multiple systems showed differing checksums for all DejaVu font files, i.e. the files in the backup did not match those in the system. Clearly, this was not caused by the bad memory module. It looked very much like a systematic issue.

Tinkering with the StarFive VisionFive 2

March 30, 2023 / By Michael / In System Administration / Leave Comment

With RISC-V getting more and more attention, I was curious and got myself a StarFive VisionFive 2, a single board computer equipped with a SiFive JH7110 SoC which implements the RV64GC ISA. While the performance is not on par with ARM SBCs yet, the overall experience has been quite good so far. In this article, I share some of my experiences with it.

Stuck UART on the ZedBoard

March 25, 2023 / By Michael / In Reconfigurable Computing, System Administration / 1 Comment

Recently I grabbed my trusted old Avnet / Digilent ZedBoard to test how well the current Xilinx tools work with this now a decade old platform. However, I was facing a weird issue: The serial output by the Zynq PL was only received via USB on my computer when I was sending characters via UART from my computer to the PL as well. As soon as there was a pause in communication, any further serial output by the PL was silently dropped.

How not to use the HackRF One as a spectrum analyzer

November 2, 2022 / By Michael / In Ham Radio / Leave Comment

A while ago I wrote about how to use the HackRF One as a spectrum analyzer, and mentioned that apart from using its sweep functionality, it could also be used as a real-time 20 MHz spectrum analyzer using any SDR software. I now had to learn about its limitations and possible pitfalls when using it this way.

I wanted to look at the spectrum put out by an RF transmitter when transmitting a simple sine wave, i.e., an unmodulated carrier. In particular, I wanted to know about any nearby spurs, so looking at it with a high-bandwidth SDR seemed to be a good idea. So I connected the transmitter to the HackRF One, using appropriate attenuation. Looking at the spectrum put out by the transmitter gave me a bit of a shock:

libc’s random number generators and what to be aware of when seeding them

January 7, 2022 / By Michael / In Programming / Leave Comment

When you need pseudo-random numbers in C code, commonly used routines are random(), rand() and rand_r(unsigned int*). First and foremost, it is important to know that none of these routines produce high quality random numbers suitable for cryptographic use. But there are cases where you just need some random looking numbers. Let’s focus on these use-cases in this blog post.

For example, let’s assume you have a multi-threaded OpenMP program where you need to generate different pseudo-random numbers in each thread. A natural approach to this would be the following:

#pragma omp parallel
{
    unsigned seed = omp_get_thread_num();
    #pragma omp for
    for (...) {
        int rnd = rand_r(&seed);
        ...
    }
}

Each thread stores its own state of the random number generator and initializes (seeds) it with its thread number. Therefore, each thread should obtain different random numbers, although they will be idential on each run due to the deterministically chosen initial values. So, what’s wrong with this code? Let’s have a look at the very first random numbers generated for each thread on macOS 12:

Understanding USB Microphone Whine

August 8, 2021 / By Michael / In Miscellaneous / 4 Comments

I recently got my hands on a USB microphone, namely the Samson Meteor Mic, a large diaphragm electret condenser microphone that not only looks cute but also has overall good reviews online. However, when testing the microphone I was rather disappointed by the annoying background noise that is clearly audible when turning up the volume of the microphone. Have a listen:

Example of background noise

Same example as before but amplified

We hear two things here: One is relatively normal microphone hiss. The other is a high-pitched noise which you really do not want to have in your recordings. Let’s have a look at the spectrum of the recorded noise, using Audacity and its spectrum analysis (i.e., an FFT):

Making Touchpads with Builtin Windows Gestures Less Annoying on Raspberry Pi OS

December 11, 2020 / By Michael / In System Administration / Leave Comment

I use a Bluetooth keyboard with included touchpad to control a Raspberry Pi 4. To be specific, I use the Keysonic KSK-5220BT by RaidSonic. One thing that annoys me for some time now is: Whenever I touch the touchpad at the very edge, the LXDE menu will open and the cursor won’t move.

The reason is that the touchpad supports Windows swipe gestures. For whatever reason these gestures are (at least with this touchpad) not recognized in software but in hardware and are translated as follows:

Swipe from right edge > Windows + A
Swipe from bottom edge > Windows + B
Swipe from left edge > Windows + Tab
Swipe from top edge > Windows + Down

Raspberry Pi OS (formerly Raspbian) has a large set of key binding preconfigured in /etc/xdg/openbox/lxde-pi-rc.xml. In particular, every press of the Windows / Super key will open the application menu. So each of these swipe gestures will open the menu and issue an additional key press (A / B / Tab / Down).

A workaround is to edit that file and replace

<keybind key="Super_L">
  <action name="Execute">
    <command>lxpanelctl menu</command>
  </action>
</keybind>

<keybind key="W-a">
  <action name="Execute">
    <command>true</command>
  </action>
</keybind>
<keybind key="W-b">
  <action name="Execute">
    <command>true</command>
  </action>
</keybind>
<keybind key="W-Down">
  <action name="Execute">
    <command>true</command>
  </action>
</keybind>
<keybind key="W-Tab">
  <action name="Execute">
    <command>true</command>
  </action>
</keybind>

With this modification, the cursor still won’t move when touching the edge of the touchpad. But at least no action is triggered and no key press is issued. But be aware that an update of the raspberrypi-ui-mods package might overwrite these changes.

Update Mar 11, 2023:

In 2021 Raspberry Pi OS updated to Debian Bullseye as a foundation. Additionally, they changed the default window manager from Openbox to Mutter on all devices with more than 2 GiB of memory. For Mutter, the procedure for disabling the annoying key bindings is slightly different:

Disable Mutters key binding for the Windows / Super key:
gsettings set org.gnome.mutter.keybindings lxpanel-menu "[]"
Install xbindkeys:
apt install xbindkeys

Create a file called .xbindkeysrc in your home directory with the following content:

"true"
   Super_L a

"true"
   Super_L b

"true"
   Super_L Tab

"true"
   Super_L Down

Manually start xbindkeys or logout and login again.

Figuring out the used space_cache version of a btrfs file system

May 21, 2020 / By Michael / In System Administration / Leave Comment

Btrfs contains different implementations of a free space cache. The default currently is space_cache=v1. A newer tree-based cache can be activated by the mount option space_cache=v2. As soon as the new version has been used once, it will automatically be used for any future mount. But how do you figure out which version your file system is actually using?

There are multiple ways to determine the used space cache version. The easiest one is to just mount the file system and look into the kernel log. If the default space cache v1 is used, it will say something like

BTRFS info (device yourdevice): disk space caching is enabled

However, if it already has been configured to use the new space cache v2, it will say something like

BTRFS info (device yourdevice): using free space tree

One can also determine the used space cache version without mounting the file system by peeking into the superblock:

btrfs inspect-internal dump-super /dev/yourdev

If the file system already uses space_cache=v2, the compat_ro_flags will contain the flag FREE_SPACE_TREE.

For completeness: When playing with space_cache=v2, be aware of the risks (see the remarks on the space_cache mount option in btrfs(5)).