<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Home on Ryjelsum</title>
    <link>//localhost:1313/</link>
    <description>Recent content in Home on Ryjelsum</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 21 Jun 2026 09:32:54 -0700</lastBuildDate>
    <atom:link href="//localhost:1313/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Disable the modem on a MSM8916 device and reclaim reserved memory</title>
      <link>//localhost:1313/homelab/msm8916-modem-disable/</link>
      <pubDate>Sun, 21 Jun 2026 09:32:54 -0700</pubDate>
      <guid>//localhost:1313/homelab/msm8916-modem-disable/</guid>
      <description>&lt;p&gt;Another article about the MSM8916 dongles. I have many of them, and they use an incredibly small amount of power, so they are somewhat useful if I basically just need a Linux computer and the specs don&amp;rsquo;t matter. Some of them even have nominally working Bluetooth, so I am experimenting with making these into, essentially, a smart speaker node.&lt;/p&gt;&#xA;&lt;p&gt;On MSM8916 devices and I imagine many other Qualcomm platforms, some of the overall memory is reserved for exclusive use by the modem. I don&amp;rsquo;t need cellular communications, and a couple of the devices that I have don&amp;rsquo;t even have US cellular bands anyway, so the modem is just sitting there, parking its ass on ~80MB out of ~512mb, which is a significant chunk. That&amp;rsquo;s basically as much memory as an OpenRC console install of PostmarketOS uses on its own. Ideally, I&amp;rsquo;d like that chunk of memory back. PostmarketOS used to support disabling the modem in a user accessible way - or more accurately, the bootloader used for many older Qualcomm devices, lk2nd, used to. At one point, though, lk2nd underwent a significant or complete rewrite, and in the process of that, this remote processor selection was dropped. You can see the source code that handled this in the old version of lk2nd &lt;a href=&#34;https://github.com/msm8916-mainline/lk2nd/blob/0.16.0/lk2nd/lk2nd-rproc.c&#34;&gt;here&lt;/a&gt;, and this is ultimately derived from that. They do the device tree changes at runtime before passing it off to Linux, I am doing it at device tree compile-time.&lt;/p&gt;</description>
    </item>
    <item>
      <title>MH-M18 (and other Jieli Bluetooth audio SoC based boards) can be a USB sound card</title>
      <link>//localhost:1313/homelab/mh-m18-usb-audio/</link>
      <pubDate>Mon, 27 Apr 2026 21:09:20 -0700</pubDate>
      <guid>//localhost:1313/homelab/mh-m18-usb-audio/</guid>
      <description>&lt;p&gt;This one&amp;rsquo;s a short one.&lt;/p&gt;&#xA;&lt;p&gt;I&amp;rsquo;ve become somewhat fascinated with these ubiquitous but somewhat anonymous Jieli bluetooth audio chips. They pack a surprising amount of extra functionality behind what is nominally just supposed to be a Bluetooth audio SoC series. The tooling behind it is seemingly very mysterious and obscure, though that&amp;rsquo;s for another time.&lt;/p&gt;&#xA;&lt;p&gt;This is about a specific board that is available as a bluetooth reciever module for quite cheap, &amp;ldquo;MH-M18&amp;rdquo;, usually sold alongside other boards with connectors attached in listings labeled MH-MX8. The M18 is a simple reciever board, the M28 is a similar board but with a 3.5mm audio and USB power connector onboard, and the M38 is a full-featured bluetooth speaker board with 2 5W amplifier chips on-board - and USB audio functionality, meaning you can plug it into a computer to both power it and output audio, which is what turned me onto this functionality.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Continuing my Qualcomm garbage addiction: QM215 KaiOS flip phones (and a bit of tearing into TCL vendor repair utility files)</title>
      <link>//localhost:1313/homelab/qm215-kaios-flips/</link>
      <pubDate>Fri, 03 Apr 2026 07:56:37 -0700</pubDate>
      <guid>//localhost:1313/homelab/qm215-kaios-flips/</guid>
      <description>&lt;p&gt;I hate the modern smartphone form factor, because of issues that I have with my hands. Touch gestures and touchscreen typing are incredibly frustrating for me, so I try to avoid them. In looking at modern flip phones out of curiosity, I discovered that many modern flip phones use a rebadged variant of a decade old 64-bit Qualcomm SoC, one that is decently well supported by mainline Linux (though not this particular variant). I fell down a bit of a rabbit hole and came out the other side with information that people might find useful.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Notes to flash lk2nd/lk1st firmware and PostmarketOS on UZ801 v3 MSM8916 dongles</title>
      <link>//localhost:1313/homelab/uz801-v3.2-postmarketos/</link>
      <pubDate>Sat, 30 Aug 2025 14:52:09 -0700</pubDate>
      <guid>//localhost:1313/homelab/uz801-v3.2-postmarketos/</guid>
      <description>&lt;p&gt;Found these $5 USB dongles that are actually entire computers using an old budget smartphone SoC. Smart reuse, it works just fine for the purpose. I like it. Let&amp;rsquo;s make it more useful and trustworthy.&lt;/p&gt;&#xA;&lt;p&gt;PostmarketOS has &lt;a href=&#34;https://wiki.postmarketos.org/wiki/Zhihe_series_LTE_dongles_(generic-zhihe)&#34;&gt;a fairly comprehensive wiki page on these&lt;/a&gt;, but it does not have a clear ordered set of steps anywhere, partly because it is trying to cover a wide range of devices. I ordered two in mid-late 2025 and I got two identical &amp;lsquo;UZ801 v3.2&amp;rsquo; boards, so I am assuming that is most common at this time. To see what board you have, take it apart, it is fairly easy, nondestructive, and should be silkscreened on.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Magic Q35/OVMF Intel iGPU Passthrough Incantation (Proxmox 8.2)</title>
      <link>//localhost:1313/homelab/magic-igpu-passthrough-incantation/</link>
      <pubDate>Thu, 25 Apr 2024 14:49:11 -0700</pubDate>
      <guid>//localhost:1313/homelab/magic-igpu-passthrough-incantation/</guid>
      <description>&lt;p&gt;Finding information on potential pitfalls and problems with this sort of setup is kind of difficult and contradictory, since it heavily depends on your hardware and OS platform. I&amp;rsquo;ve got it working, so I&amp;rsquo;m documenting my exact setup. I&amp;rsquo;ve tried around a half dozen times to get this to work, and this is the first time I&amp;rsquo;ve succeeded. Just to clarify, this is not the GVT-g mediated device stuff, this is full GPU passthrough to a single virtual machine.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Setting up greetd/tuigreet in NixOS with session detection and choosing (0.8.0 and 0.9.0)</title>
      <link>//localhost:1313/homelab/greetd-session-choose/</link>
      <pubDate>Tue, 19 Mar 2024 12:21:23 -0700</pubDate>
      <guid>//localhost:1313/homelab/greetd-session-choose/</guid>
      <description>&lt;p&gt;Posting this for posterity, since I haven&amp;rsquo;t seen anyone put all these bits together in one place quite yet.&lt;/p&gt;&#xA;&lt;p&gt;Greetd is packaged for NixOS, but not really &lt;em&gt;well&lt;/em&gt;. The package works if you&amp;rsquo;re not setting it up to allow for a choice of multiple sessions, by using it the way most people use tuigreet - with the &lt;code&gt;--cmd&lt;/code&gt; option to specify the default command to execute after login. This works 100% fine if you only use one particular WM/DE session. However, I wanted greetd to detect both my sway session and my XFCE+i3 custom session.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Cheap Riverbed/Silicom Intel i350 based bypass network cards - how to use normally, other misc information</title>
      <link>//localhost:1313/homelab/sicom-bypass-cards/</link>
      <pubDate>Thu, 18 Jan 2024 13:43:31 -0800</pubDate>
      <guid>//localhost:1313/homelab/sicom-bypass-cards/</guid>
      <description>&lt;p&gt;Recently I came across these Riverbed-labeled quad-port i350 &amp;lsquo;bypass&amp;rsquo; NICs up on eBay. They are unusually cheap, but seem to be at the edge of their manufacturer support lifetime and are somewhat confusing to actually utilize as a standard NIC. I will explain these to the best of my understanding, as well as how to both configure the card as a bog-standard i350 NIC or use the bypass capability for (very basic) failover purposes without configuring any additional software on the host.&lt;/p&gt;</description>
    </item>
    <item>
      <title>XPT2046 / ILI9341 SPI LCD (Raspberry Pi style) on Orange Pi Zero (Allwinner H3), Armbian OS</title>
      <link>//localhost:1313/homelab/xpt2046-ili9341-opi-zero/</link>
      <pubDate>Mon, 20 Nov 2023 20:32:06 -0800</pubDate>
      <guid>//localhost:1313/homelab/xpt2046-ili9341-opi-zero/</guid>
      <description>&lt;p&gt;I have a touchscreen SPI LCD that I got for a Raspberry Pi but don&amp;rsquo;t use for much. I got it working on an Orange Pi Zero (Allwinner H3) SBC. Yay!&lt;/p&gt;&#xA;&lt;p&gt;This is on the mainline kernel version, &lt;code&gt;6.1.53.&lt;/code&gt; Most complete guides that I find out there for getting these SPI LCDs working on Armbian will use older mechanisms that don&amp;rsquo;t work with more current kernel versions, AFAIK.&lt;/p&gt;&#xA;&lt;p&gt;This was adapted from &lt;a href=&#34;https://hackaday.io/project/190371-g-edm/log/217902-first-success-with-armbian-nanopi-and-ili9341-touch&#34;&gt;this&lt;/a&gt; person&amp;rsquo;s device tree for a NanoPi SBC. The pinouts are significantly different, and the SPI0 bus is not exposed, so many changes were necessary, but the basic structure is the same.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Intel MSR turbo twiddle - Increased all-core performance on power-limited Intel CPUs (dubious utility?)</title>
      <link>//localhost:1313/homelab/msr-turbo-twiddle/</link>
      <pubDate>Thu, 02 Nov 2023 20:59:37 -0700</pubDate>
      <guid>//localhost:1313/homelab/msr-turbo-twiddle/</guid>
      <description>&lt;p&gt;I was recently screwing around with Intel XTU on Windows on my PC, since it is purportedly able to overclock my strange engineering sample laptop CPU that was converted to a desktop CPU with non-Z motherboards. That is half true. I was able to get a slight bump on my all-core turbo frequency, but within reasonable limits, and up to the Aliexpress vendor&amp;rsquo;s advertised 3.3ghz per core from the ~2.9 I was getting before. This inspired me to go back and start playing with turbo-related Intel CPU model specific registers again, as I had researched it in the past enough to find which registers to twiddle.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Initial research on the Google Nest Wifi Router (model H2D, board name mistral), putting Linux on it</title>
      <link>//localhost:1313/homelab/hardware-notes/nest-router-h2d/</link>
      <pubDate>Fri, 06 Oct 2023 13:20:46 -0700</pubDate>
      <guid>//localhost:1313/homelab/hardware-notes/nest-router-h2d/</guid>
      <description>&lt;p&gt;This seems to be a ChromeOS based device that boots using depthcharge much like the Google Onhub or Google Wifi (AC-1304) puck. Qualcomm based, like all the other Google routers, with an uncommon SoC (QCS404), the 4gb of flash that is typical in Google routers, and 1gb of RAM. It has an internal debug button and an internal hidden USB-C port that likely serves a similar function to those on the Google Wifi. I don&amp;rsquo;t know if it can be powered from this port, though. I&amp;rsquo;m guessing not.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Running Fractorium on NixOS with OpenCL/CUDA acceleration</title>
      <link>//localhost:1313/homelab/fractorium-nixos/</link>
      <pubDate>Mon, 18 Sep 2023 15:22:53 -0700</pubDate>
      <guid>//localhost:1313/homelab/fractorium-nixos/</guid>
      <description>&lt;p&gt;Fractorium is a piece of software that allows you to edit fractal &amp;lsquo;flames&amp;rsquo;, based on flam3. I&amp;rsquo;m not going to go into it too much as I&amp;rsquo;m going to assume that you&amp;rsquo;ve somehow found this website off of a deep search or something and get straight to the point. I&amp;rsquo;m also assuming you already have CUDA/OpenCL working (see your distro&amp;rsquo;s guides, the Arch Linux &amp;ldquo;GPGPU&amp;rdquo; article is enlightening for all distros as usual as well).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Wyse 5020 (Dx0Q), 7010, (Zx0D) 7020 (Zx0Q)</title>
      <link>//localhost:1313/homelab/hardware-notes/wyse-5020-7020/</link>
      <pubDate>Mon, 14 Aug 2023 11:20:02 -0700</pubDate>
      <guid>//localhost:1313/homelab/hardware-notes/wyse-5020-7020/</guid>
      <description>&lt;p&gt;These models of Wyse thin client have an extra SATA port, a 1.25mm spacing header with 5V, a 2.0mm spacing header with 12V, a 9 pin USB 2.0 internal header, and (most interestingly) a 40 pin ZIF FPC header that is a nonstandard PCI-E 2.0 x4.&lt;/p&gt;&#xA;&lt;p&gt;I have wanted to make a breakout PCB that adapts the 40pin FPC to a M.2 M-key slot, intended to be used with an M.2 to PCI-E riser. Unsure if there is anything I&amp;rsquo;m not thinking about.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Optiplex 7440 Family (Optiplex 3240, 5250, 7440, 7450)</title>
      <link>//localhost:1313/homelab/hardware-notes/optiplex-7440-fam/</link>
      <pubDate>Mon, 14 Aug 2023 11:09:23 -0700</pubDate>
      <guid>//localhost:1313/homelab/hardware-notes/optiplex-7440-fam/</guid>
      <description>&lt;p&gt;As far as I can tell, all of the models listed above are interchangable as far as the motherboard is concerned, for the most part. The one exception seems to be those models of the Optiplex 7440/7450 which include a 2K/4K display, which use an embedded displayport header that is unpopulated or not even present on motherboards that don&amp;rsquo;t use it, in favor of an LVDS connector.&lt;/p&gt;&#xA;&lt;p&gt;I have swapped an Optiplex 7450 motherboard (with the R7 M465x dedicated GPU) into an Optiplex 5250, and it has been working perfectly fine. I did this because the 7440/7450 motherboards have an HDMI input, so I can use it as a monitor. This has worked perfectly fine. You would likely need to swap out the power supply for the 200W model though - this is relatively expensive, but I&amp;rsquo;m using an i5-6500T, which offsets ~30W of the power draw, in my mind. I haven&amp;rsquo;t experienced any errors or instability that I could trace back to having the improper PSU.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Google OnHub Hacking</title>
      <link>//localhost:1313/onarouter/onhub-hacking/</link>
      <pubDate>Mon, 31 Jul 2023 12:42:44 -0700</pubDate>
      <guid>//localhost:1313/onarouter/onhub-hacking/</guid>
      <description>&lt;p&gt;I found these routers quite by accident, after I got a collection of Google Wifi pucks for very cheap and decided to look into their other Wi-fi products to see if they were able to be hacking and worth it to do so. And oh boy, did I find a doozy in the Onhub, which is branded as both TP-Link (TGR1900) and ASUS (SRT-AC1900) and made for Google Home. This article was written using TP-Link units, but it&amp;rsquo;s my understanding that the Asus model is very similar.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How I got Wi-fi working in Proxmox</title>
      <link>//localhost:1313/homelab/proxmox-wifi/</link>
      <pubDate>Mon, 31 Jul 2023 12:38:39 -0700</pubDate>
      <guid>//localhost:1313/homelab/proxmox-wifi/</guid>
      <description>&lt;p&gt;Pictures may be added later if there is any ambiguity - if you would like me to add pictures for clarity feel free to contact me, and I&amp;rsquo;ll clarify and add pictures.&lt;/p&gt;&#xA;&lt;h2 id=&#34;tldr&#34;&gt;tl;dr:&lt;/h2&gt;&#xA;&lt;p&gt;PCI-E passthrough to an OpenWRT virtual machine. Create a second vmbr to act as the output. Connect both vmbrs to the virtual machine in order to install drivers and configure. Alternatively, build an image with the drivers inside of it.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Openwrt Hardware Choice</title>
      <link>//localhost:1313/onarouter/openwrt-hardware-choice/</link>
      <pubDate>Mon, 31 Jul 2023 12:29:25 -0700</pubDate>
      <guid>//localhost:1313/onarouter/openwrt-hardware-choice/</guid>
      <description>&lt;p&gt;Short version: For a dual purpose of a small server host alongside a wireless router, Mediatek and Atheros chipsets are probably best. Many more recent Atheros based devices are nice because their chipsets are multi-core ARM processors. Try to get something with a good amount of flash and RAM (128/256mb respectively, as a bare minimum) if you plan on using it as a multi-purpose &amp;lsquo;server&amp;rsquo; device, though it is possible to get around flash restrictions with some contortions.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
