Hempstick Breakthrough

Haven't posted in over 2 months... I was pulling my hair out in the last two months... and finally achieved two breakthroughs. I will not talk about the first breakthrough, suffice to say it's a software breakthrough.

The other breakthrough I will talk about now is I now have a Linux Hempstick distro. for RPi Zero 2W. Yes, you read it right, it's a whole Linux distro. I build myself.

It contains the followings.

  1. The newest Linux Kernel 6.16.0 (only about 3 weeks old).
  2. It has the newly mainlined Real Time module turned on.
  3. It has a minimal Linux distribution (as much as I care to install), built into a .img file just like the Raspberry Pi OS.
Why in the hell do I bother with this difficult route???!!!

Well... originally, it started with an idea of using a Linux on RPi Zero 2W or Pi5, etc... for controlling all the panels in the "pit." One Linux per panel... or whatever. Then... there are a bunch of stuff I want to write and install on each of the instance of OS, possibly all different. So, I am faced to two basic choices. Because, this is way too much a technical ask for your regular simmers. No offense, what would you think if I told you that you must at step 2 download and install my custom compiled Linux kernel and update your initramfs, and then modify your boot up comdline.txt and config.txt boot up parameters? Ya... right. Not practical for an Anesthesiologist, or an Electrician, now is it?

a.) I could install everything on a stock Raspberry Pi OS, and do all the customization on it... and once I am happy about it, dump the SD card to a .img and have you download and install it.
b.) I could build my own distro, which generates a .img with everything installed and configured.

#a is workable, but it's not repeatable... and it's not exactly customizable. I want eventually to have a system which you can go and customize all kinds of things, like select how many inputs you want, your VID/PID, your manufacturer string and stuff, and it will generate a .img just for you. #a is not an option. Plus, if I do this... aren't you going to get my WiFi SSID and my WiFi password? Ok... maybe I will wipe them out... but... that means, you will have to put them in. Meaning, you will have to mount the file systems, and then edit them... Gah...

#b is incredibly difficult. Well... it's not rocket science, nor Ph.D. worthy, but it's just incredibly time consuming. And you have to deal with a lot of OpenSource software glued together with snot. You have no idea what I had to deal with to get here. For instance, I spend the last two weeks of my spare time pulling my hair out dealing with a '+' character. Fucking snot! Most of the distros... don't give you their secret sausage making machines! Except Yocto. Yocto... is very difficult to deal with. It deals with all kinds of snot.... with more snot. grr...

But I found a work-in-progress, experimental software that kind of works... and just released not long ago.. well, this year. So, I tried it out, build one .img!

That's the "packaging" reason.

Now, for #1...

Why in the hell do I need Linux Kernel 6.16.0, the newest? Ok. ok.... by the time I finished pulling my hair in the last two weeks... Linux Kernel has 6.17.0 version. Well... there is a feature of 6.16.0 that was just mainlined and merged into the master branch. This is related to adjusting the USB report rate.... I definitely will not want the default 40ms! Unfortunately, Debian 13, code name Trixie, after two+ years of development, was just released... well... Aug. 9, 2025, this month. Now, Raspberry Pi OS is a Debian-derivative... and it's usually a year behind Debian. Well, at least a few months. So, even Debian 13 came with Linux kernel 6.12.... so even if Raspberry Pi OS catches up with Debian 13, it's still too old for me... and not even the Debian backport repository has it, i.e. you want anything newer than 6.12, you have to compile it yourself. There is just no way out of it.

#2

Also, I definitely want the Real Time kernel ... feature... which used to be called the Linux Real Time patch, because it was maintained out of the mainline as a patch. So, you wanted it, you had to download the patch, patched it yourself, and then compiled it into the kernel yourself.... Now, after 20+ years (?) of out of mainline as a patch... it is finally mainlined!!! No more patch! But, you do have to enabled it and compile it yourself, it's by default turned off, and most main distros turn it off. I have no luck in any of those linux-image-x.y.z-rpt-rpi-v8-rt kernels I could run "apt install"... from various Debian repositories. They simply don't boot! I think I know which snot is causing the problem.

Wait... you didn't explain why you want the Real Time kernel, you said. I know... I previously published a test report, a couple of years ago, on interrupt latency of various RPi devices, unfortunately on ViperPit. I found that the Linux Real Time patch do improve the latency tremendously for RPi. The worst was RPi Zero W (no v2 at that time). I found its worst case interrupt latency was around 250µs, i.e. 0.25ms, 1/4 of what I require. But without the Real Time kernel, it went up to almost 1ms, too close for comfort.

#3

I want quite a few things to be installed in the OS, and quite a lot of things I don't want in it. One of the thing is that the boot up params have to be customized.... this is best not left to noobs... again... sorry no offense. Hardware developers' worst nightmare is designing a circuit, particularly one with complex OS on it... you boot up... and nothing, absolutely nothing, no light, no led, no beep... just utter silence. So, what's wrong. You don't know! Now, dealing with Raspberry Pi is not as bad as this. But... you mess up the boot up params.... you at least know the hardware is good, but RPi will just give you 7x blinks for the power LED, if it doesn't find a kernel to boot, or if it finds a kernel to boot... nothing. I need to load a few kernel modules for it to work, and I need to tell it to run in a special USB mode. Then, I need to install quite a few things on it, arrange them to auto start using systemd init mechanism. I possibly want to statically compile some of the stuff into the kernel if I could to avoid having to dynamically load them to avoid potential problems. After all, this is a one purpose Linux distro, not a generic OS. All these are complicated tasks... so I want them as automated as possible.


Automation

I currently have a Jenkins job that builds the kernel for me... at some selection of drop down boxes, and a click... it will compile a Linux kernel Debian package for me with the features I want turned on/off.

Then I have another Jenkins job that will build a program for me (will let you know what it is when I release it).

Then, I have yet another Jenkins job that will take a specified artifacts from the kernel job, and a specified artifact from the 2nd job, and build a minimal Linux distro image for me.

I take the hempstick-developer.img and burn it onto a microSD card, and boot it up with a RPi Zero 2 W.

I am still quite far from releasing it. For instance, I still need to write the code to read sensors, and feeder program to send the reports to the DCS Windows box (I won't tell you how yet), and I still need an artifactory or Nexus repo server setup (I have one... but they are a PITA to deal with), and I also need DRM modules written, and customization automation written etc.

Oh... DRM? Yes... Digital Right Management. It will be free software as in beer, but not as in freedom. That's what you get when your OpenSourced stuff get stolen, and in turns, be accused by the thieves that you steal from LMCO. No... you will not get the source code, but you will won't have to pay me money either. I reserve the rights to turn off, or degrade your service. But rest assure, if you are not in one of the CRINKS countries... I won't not turn that on you, even if you live in Denmark.

Ya... I know... 4 cores at 1GHz is definitely overkill as a panel controller! I agree whole heartily... But at USD $15? Well... that's the same price as a Raspberry Pi Pico 2 W, which is not capable of running Linux! But... RPi Zero 2 W does not have ADCs... But I think I can turn an RPi Pico into a quad ADC sensor stick, if you really want to read analog signals. Me? I am going all digital Hall Effect. brrr.... 


Comments

Popular posts from this blog

F-16 blk 50 Central Pedestal

F-16 ICP Mechanical Design Fully Prototyped!

F-16 (and other modern jets) Two-stage Trigger