Table of Contents
Oregon Trail Device Board
I saw on Liliputing that they were selling one of those single game systems that had Oregon Trail instead of Frogger or whatever. I thought it might hold local interest a little longer than arcade games that only few of us remember. And then once done, I could do something terrible to it.
Also, I was wondering if they were doing something interesting in the hardware. Alas…
Those are some biggish COB blobs. I instantly thought NES-on-a-chip1) but they look a bit bigger than the standard dual NoaC and ROM splurts onto the substrate.
I should probe around a bit, because of the LCD panel. It looks like a standard panel, and I could probably fit one of the ILI9341 or so panels from ebay in it with few changes.
Also, if it *is* a NoaC, it might have composite video somewhere on the board. That could be interesting.
LVM2 Fixes for Arch Linux
Alright, so I run Xen on Arch Linux, and I use LVM to manage virtual disks, because snapshots take the pain out of life. There's been a longstanding problem in the hand off from initrd to systemd where not every logical volume is activated at boot, and lvmetad2) will end up running twice with both hanging– in an aggravating but also amusing lock race– when there's a large number of logical volumes.
There was a bug on it, but the bug report suggested that fixes had been implemented and I felt like I was on my own. From there I decided that I wouldn't include root in the LVM, and older systems would just have need intervention on boot. Which is fine– the two affected systems are on my desk or in a datacenter, so inadvertent reboots are rare.
Well, today I decided to patch for Intel-horror, and I really looked at the bug report to fix it once and for all.
It turned out to be absurdly simple.
Digigram VX222e Isn't Seen in Arch Linux
A radio station I'm working on has a machine with a Digigram VX222e connected to it.
According to the Digigram site, and ALSA, the sound card is supported by ALSA. Unfortunately, it doesn't appear to be detected as a sound card. Reading online, it requires some firmware, but it appears that my system has the proper firmware installed.
The VX222e is a PCIe card, but it appears to be PCI on the card with a PCIe to PCI bridge. According to Digigram's support site, they made a hardware change in March of 2017, and I suspect that this might be the problem.
Linux, Serial, C, and Intel vs. ARM
I'm working on some mcu stuff and I kept running into the same problems when writing code to talk to it on Linux. I've been writing code on my desktop, moving it to either my Chromebook or an RPi.
So I'm writing it down sos I remember. I thought it might be because of the ch341 UART adaptor I had on my shitty arduino clone, but I'm running into it elsewhere.
- In c_iflag, IRCNL is set on be default on ARM, converting CR's into NL's. Annoying when you write stuff designed to be understood by humans and machines.
- cfsetispeed and cfsetospeed don't seem to work. cfsetspeed does.
- O_NONBLOCK never seems to work right. Leave it alone and use c_cc[VMIN || VTIME] instead, because that's smarter anyway.
There will probably be more here.
Get Out Of Infinality Part 1
This is what I do to my systems to get them up to date with freetype 2.7, which invalidates3) the infinality patches. This assumes you have multilib installed. Remove references to lib32- packages if you don't.
Step 0: Update system and get rid of orphans to make sure things are clean. Make sure you have an alternative wm like windowmaker installed so freetype2 problems aren't deadly.