Happy new year! Since I haven’t been posted in a while, here’s what I’ve been up to lately:

• adopted Wezterm as my terminal emulator, contributing a bunch of (mostly Wayland-related) patches in process
• figured out a minimal tool to make Xiaomi power strips work without the “cloud”
• saw a SIMD-accelerated tac line-reversing utility and immediately ported it to arm64 NEON/AdvSIMD
• helped out with firmware and EC (just testing with the latter) patches for the Thinkpad L430/L530
• developed a FreeBSD driver for the SPI keyboard/touchpad attachment in Apple MacBooks (currently only in my fork and only tested on the 2015 MBP, spibus-side prerequisites are in review)
  • related: got the Magic Trackpad 2 (which uses a compact packet format but similar surroundings to bcm5974) working too
• started learning PCB design with Horizon EDA
  • which has of course resulted in making some new tools for it
• found bugs in the mold linker and zlib-ng
• made new Wayfire plugins: wf-globalgestures, wf-dynspaces, wf-touchpad-gesture-drag (yeah, turns out 3-finger drag is easy with current libinput: it’s a hold-cancel-swipe sequence!)
• finally made a freebsd-embedded-hal Rust crate
• just now added dark mode to micro-panel where I’m writing this

Unusually, I do have a legit new year’s resolution this time: I should blog more! Want to publish some long-form things here.

Noticed the mgb driver for Microchip LAN7430 (/31) NIC in FreeBSD commit logs. Huh, interesting stuff: Microchip publishes so much documentation.. a “Programmer’s Guide” PDF with lots of driver pseudocode, and even evaluation board design files!

Ported the Firefox Profiler to FreeBSD in order to investigate why WebRender has some jank when scrolling some walls of text on my 4K/HiDPI setup.

The profiler code initially looked somewhat scary: some Google Breakpad code is used, a custom stack unwinder called LUL is used on Linux (which also partially derived from Breakpad code)…

Initially, I got it working with “pre-symbolication” (an option to build the goblin ELF parser into Firefox for this purpose) only, ifdef’ing any Breakpad code out.

Turns out:

• the only part of Breakpad used is extracting build IDs from shared objects (and in fact the “base profiler”, a copy (for now) of the Gecko profiler used for profiling during the early startup phase, just copied all the relevant code);
• devel/breakpad was there in FreeBSD Ports (but expires in like three days!), and its patches showed that it’s really trivial to get all it working.

So I got the main symbolication system working. Which, it turns out, runs WebAssembly-compiled goblin in a web worker! Fun stuff. Requires stripping libxul for now tho.

In the end, the patch turned out to be mostly just ifdef’s! The only meaningful parts are: thr_self/thr_kill2 instead of gettid/tgkill, supporting the different mcontext structs, and (for the pre-symbolication code path) ignoring symbol names returned by dladdr because they’re hilariously bad.

BTW, earlier in the dev-tools-on-FreeBSD space: heaptrack! I even used it to find a real memory leak in Wayfire.

Firefox content process sandboxing with Capsicum: it’s alive! Work in progress, but I have WebGL and audio working :)

“Why do programs I compile become all-zero files after rebooting?”

well, maybe that untested filesystem-related kernel patch you applied has something to do with it :D

But seriously, if anyone wants to make a very cursed unix system: apply this diff (note: old version by now) to FreeBSD from around now (say the beginning of 2020 — happy new year!), build programs using clang/lld 9.x and reboot.

I was wondering why I can’t watch Twitch streams in Firefox… turns out they serve a broken player if your User-Agent does not contain Linux/Windows/macOS. Fail.

It’s nice that Microsoft is pushing for all pen tablet (stylus) support in laptops to use the obvious generic set of HID reports. Quite probably, Microsoft is to thank for the Wacom touchscreen in my Pixelbook implementing that. I’ve seen the heaps of code in the Linux kernel to support Wacom’s custom protocols, that would’ve been very NOT fun to implement :)

Took like an hour max to get to working reports in console (dmesg), all that’s left is to evdev-ify it. Coming to iichid pull requests soon (but for now there’s no multiple device support in hidbus, so won’t be mergeable yet).

Looks like NetBSD is already working on the EC2 AArch64 instances! My attempt at running FreeBSD there failed: for mysterious reasons, the system reboots just after the last loader.efi message..

Trying to do anything system-level on EC2 is incredibly frustrating. There is STILL no read-write access to the serial console, because Bezos doesn’t believe in debugging or something >_<

Also, about the ARM instances themselves. I am happy to see a big player enter the ARM space. And with custom (Annapurna) chips, even. (Though they’d have much better performance if they just bought some Ampere eMAGs or Cavium ThunderX2s.)

But what’s up with that price? Did anyone at AWS ever look at Scaleway’s pricing page?! On-demand pricing for a single core EC2 ARM instance is almost 20 bucks per month! While Scaleway offers four ThunderX cores for three euros per month!! Sure sure Scaleway is not a big player and doesn’t have a huge ecosystem and is getting close to being out of stock on these ARM instances.. but still, 1/4 the cores for 5x the price.

(Spot pricing is better of course.)

what’s this? :)

Another weird LLVM mystery solved!

So, I was porting LDC to FreeBSD/aarch64, wondering why global constructors (you know, the before-main() code you can make in C using an __attribute__ thingy) aren’t running… but only when the executable is linked with LLD. Turns out:

• .init_array is the only supported way to do constructors on AArch64
• and everything in general is moving towards .init_array — but the default in LLVM is still to emit .ctors
• clang has code to enable .init_array when appropriate, ldc did not
• and the reason it all worked fine with bfd and gold is that these linkers SILENTLY convert .ctors to .init_array. For PERFORMANCE REASONS.

It’s almost 2019, so using a SATA SSD as the boot drive for your main development OS is not cool anymore… and I was running out of space on this 128gb one, so I bought an NVMe drive to replace it. Yay.

Because I don’t have anything with two or more M.2 slots and I was too lazy to find/make a bootable FreeBSD USB drive, moving the system involved inserting the new drive into another machine (server) and using ZFS replication to copy the data. (And forgetting to set bootfs on the pool, of course.)

But the fun part was that my 10G network card stopped working. Moving the card into the middle slot (from the bottom one) fixed it. Reported a FreeBSD bug.

The weirdest discovery of the day though was that MSI mainboards persist the “above 4G” PCIe setting across CMOS clears. What in the actual heck. This is the setting that breaks display output on most GPUs (funnily enough, mine did display non-EFI things such as the network card’s boot prompt and the glitchy way FreeBSD displays the console when booting on UEFI with the EFI framebuffer disabled). It’s a setting you very much need to clear.

yay, Firefox will use SHM_ANON on FreeBSD now

An SPI flash chip module arrived in the mail today. I ordered that for replicating this basically. To (network) boot the Orange Pi PC without microSD.

Naturally, instead of booting Linux to flash or (?) trying flash from U-Boot itself, time was spent on making flashrom work on FreeBSD :)

Scaleway’s ARM64 VPS has been successfully depenguinated! :) Now you can run FreeBSD on four ThunderX cores, 2GB RAM and 50GB SSD for 3€/month. Awesome!

Also, in the process, I finally discovered the cause of GPT partitions sometimes disappearing on reboot. It was the size of the partition table. It’s 128 by default, but sometimes it’s not — e.g. on the FreeBSD installer memstick image, it’s 2. Creating a third partition with gpart “succeeded”, but the partition disappeared on reboot.