rtyler

Honeycomb LX2 Resources

2026-08-17T00:00:00+00:00

An ARM64 (aarch64) machine which sat idle on the workbench amidst other inert items has finally returned to service. Many years ago I purchased a HoneyComb LX2 ARM workstation with the hopes that it would become the desktop counterpart to the Pinebook Pro which also graced my junk heap. The earlier days of Linux/aarch64 were quite unpleasant with a hodgepodge of driver support and other problems. A lot of hardware support improvements have landed upstream in the Linux kernel since I first purchased this machine and I was able to install a stock Debian image without too much difficulty.

Not too much.

It still was not terribly simple but at least I now have something functioning in the rack servicing aarch64 builds!

Linux honeycomb 6.12.101+deb13-arm64 #1 SMP Debian 6.12.101-1 (2026-08-05) aarch64 GNU/Linux

There are a number of useful hobbyist resources I relied on, which I wanted to link for posterity here:

LX2K_Guide from @Wooty-B

I found this repository to be incredibly helpful as a confirmation of some install procedures and hardware support. This Honeycomb repository popped in my searching as well, while not as thorough as Wooty’s it has some useful UEFI shell invocations that helped me muddle through using the shell.

SolidRun has this quickstart guide which didn’t exist when I bought this board originally. It was a handy reference for some basics.

Installing Ubuntu on SolidRun HoneyComb LX2

This was a very helpful blog post to refer back to because the original author included screenshots of some of the UEFI bios settings! This was really helpful to confirm what was correct versus incorrect as I got started.

openSUSE wiki page on HoneyComb LX2K

I found this useful mostly to confirm that the system should be generally well supported these days. When it was originally released there were all kinds of kernel and driver hacks that were needed to bring the machine online.

First experiences with Honeycomb LX2k

Not terribly useful or detailed, but another confirmation “from the field” of some things I had in mind. This reminded me about the jumpers for the boot sequencing:

Make sure the firmware source jumpers are set off-ON-ON-ON-ON-off (or otherwise as indicated by silkscreen on board).

Mr. Sas, here to save the day.

2024-07-09T00:00:00+00:00

I have always been a technology scavenger, picking up cheap or disused computers for parts or tinkering. Last year when I picked up a full-height server cabinet, a new world of rack-mountable junk finally became possible! One lucky Craigslist find ended up being an older 2U IBM xSeries server with 8 drive sleds that was described as “sorta working” by the owner, who was shedding some extra stuff for his move across the country. I accepted the challenge, forked over a few Jacksons, and brought the machine home.

The thing about “server grade hardware” is that it never really is. The consumer grade stuff is junk, the small-medium business grade stuff is junk. It’s all junk. Servers tend to have more redundancies to compensate, but at the end of the day: junk.

Anyways, the seller had trouble getting the server to recognize more than one stick of RAM. I carefully unseated and reseated the RAM… and it just worked!

Onto the next challenge, sometimes the machine wouldn’t reboot. Somehow a cold boot, versus a “reboot” didn’t work properly. I found a critical problem in the IMM which could have resulted in me bricking the board and upgraded the out-of-date firmware, dreading any potential triggering of the bug.

I then fought against the RAID card, which really means I fought against the Serial-Attached-SCSI disks. Did you know that Serial-Attached-SCSI has a cable that’s functionally compatible with SATA? Did you also know that SAS disks are obscenely expensive, while SATA SSDs are plentiful? The difference it turns out is largely in software and many SAS supporting devices also support SATA!

I wanted to boot directly into FreeBSD via ZFS, with a nice array of SATA SSDs , but try as I might I could not get FreeBSD to boot consistently. Inevitiably mfi(4) errors would appear and the system would become unusable. There were so many goblins in this machine, I continued searching forums, StackOverflow, and random mailing list posts. Until I finally met Mr. Sas.

From the mrsas(4) man page:

Using /boot/device.hints (as mentioned below), the user can provide a preference for the mrsas driver to detect a MR-Fusion card instead of the mfi(4) driver.

The mfi(4) driver and my hardware simply would not cooperate, so I updated /boot/loader.conf with:

hw.mfi.mrsas_enable="1"

I crossed my fingers, blew the petals off a dandelion, clutched a lucky charm and rebooted the machine..

…

As the machine POSTed and booted into FreeBSD I quietly waited for something else to go wrong.

But it didn’t.

…

How about that? It just worked.

Mr. Sas saved the day!

I have probably spent $1000 on upgrades for the machine, which was retired from some guy’s garage for $100. In turn I’ve gotten far more benefit from this goofy steel slap resting at the bottom of the rack.

The machine has since had its disk capacity maxed out, it’s been upgraded to 136GB of RAM. It has become the central workhorse of my homelab: storing backups, hosting a dozen jails, and even a few VMs!

None of which would have been possible without the friendly help of mrsas(4).

Loving the PinePower

2021-01-31T00:00:00+00:00

My current available working space is at an all time low which has made the dimensions of everything around me much more important. While I can never become one of those extreme minimalists that works with only their laptop on a park bench, next to their camper van (or whatever), I have been pushing myself to become more space-efficient with my electronics. This includes how they all are powered, so when I learned about the PinePower device, I ordered it immediately.

The PinePower is sold by Pine64, the same folks who manufactured my PineBook Pro. The device is basically a “power all the USB from one place” desktop power supply. One 120V plug provides five USB ports (four USB-A, one USB-C) along with a charging pad, although I own nothing that can utilize wireless charging.

Currently this little brick is powering:

Dell XPS via USB-C
PineBook Pro
A work phone
My personal phone, using the USB-A port with Quick Charging capability.

Consolidating four “wall warts” into a single 120V plug is more than enough of a reason to purchase the device when it becomes available again.

The PinePower also offers a little display above each port which tells you the voltage and current amperage of each port. I love this feature as it gives me a good understanding of the power draw of all of these devices, when charging has completed, or when CPU intensive tasks have caused power consumption to spike. At a glance I can see that my PineBook Pro is charging, pulling 2.2A, while the XPS is fluctuating power modes between 0.4, 0.7, and 1.2A as I write this blog post. Power utilization and efficiency are important to me, and to that end the PinePower has been more informative than I anticipated it would be.

From an excitement-to-complexity ratio, the device scores very highly for me. It’s so simple, yet I find myself glancing over at the display multiple times a day to get a sense of my current power requirements.

To learn more about it, I recommend reading this article on the PinePower, and of course keep an eye on the website to see when it comes back in stock!