karstxI make things and then write about themZola2026-09-16T00:00:00+00:00https://karstx.net/atom.xmlHacking the NuPhy Air60 keyboard: part 32026-09-16T00:00:00+00:002026-09-16T00:00:00+00:00
Unknown
https://karstx.net/nuphy-air60-part-3/<p>It's been a long time coming... so this one's going to be a bigger one.</p>
<p>This is another update on the long-running project of putting my own firmware on a <a rel="external" href="https://nuphy.com/products/air60">NuPhy Air60</a>. If you're interested in the previous parts, they're here: <a href="/nuphy-air60">part 1</a> and <a href="/nuphy-air60-part-2">part 2</a>.</p>
<p>So what happened since? Quite a lot, honestly.</p>
<!-- toc -->
<figure>
<a href="https://karstx.net/nuphy-air60-part-3/assembled-keyboard.jpg">
<img src="https://karstx.net/processed_images/assembled-keyboard.0dd5870c6585009b.jpg" srcset="https://karstx.net/processed_images/assembled-keyboard.d686080528efa40f.jpg 2x" alt="a NuPhy Air60 on a wooden desk, with blue and white keycaps, a yellow spacebar and a red enter key, sitting on a black printed base" />
</a>
<figcaption class="center">my pimped out work-horse: NuPhy Air60 (v1)</figcaption>
</figure>
<h2 id="timeline-so-far">Timeline so far<a class="zola-anchor" href="#timeline-so-far" aria-label="Anchor link for: timeline-so-far">§</a>
</h2>
<ul>
<li><strong>April 2023</strong> - sinowealth-kb-tool gets its first release.</li>
<li><strong>December 2023</strong> - USB lands on top of the matrix scanning from October, so <a rel="external" href="https://github.com/karstx/smk">SMK</a> works as an actual USB keyboard for the first time.</li>
<li><strong>2024 into 2025</strong> - a steady stream of new devices gets added to sinowealth-kb-tool, and it hits 1.0.0 in May 2025. SMK picks up wireless (over the BK3632) and NKRO around the turn of the year.</li>
<li><strong>January 2026</strong> - reverse engineering the remaining bits of the SinoLink, enough to build sinodude, my own programmer around an Arduino Nano.</li>
<li><strong>June 2026</strong> - <a rel="external" href="https://github.com/karstx/hidra">hidra</a> gets written, the browser flasher at <a rel="external" href="https://smk.carlossless.io">smk.carlossless.io</a> quietly goes live, and I start designing a new base for the keyboard in FreeCAD.</li>
<li><strong>July 2026</strong> - everything gets wired together. sinowealth-kb-tool becomes <a rel="external" href="https://github.com/karstx/sinowisp">sinowisp</a> and drops hidapi for hidra.</li>
<li><strong>August 2026</strong> - the LED effect engine, sleep and settings land in SMK, along with the split between the platform layer and keyboard policy.</li>
<li><strong>September 2026</strong> - ports onto more keyboards and more MCUs (the SH68F881 and SH68F89, a Genesis Thor 300 and a CIY X77), and, thanks to the multiple backends, sinowisp gets to the point where it can talk to every documented ISP bootloader on Windows, macOS and Linux.</li>
</ul>
<p>Anyway, on to the actual stuff...</p>
<h2 id="smk-grew-up">SMK grew up<a class="zola-anchor" href="#smk-grew-up" aria-label="Anchor link for: smk-grew-up">§</a>
</h2>
<p>Part 2 of this series ended with a minimal firmware that booted, jumped back into the bootloader without bricking itself, and not a lot else. That scratchpad (it was called sh68f90a-experiments back then) is now <a rel="external" href="https://github.com/karstx/smk">SMK</a>, a working keyboard firmware, somewhat stable even. Stable enough that the Air60 running it is one of the two keyboards I use day to day.</p>
<p>It didn't all happen at once. Matrix scanning and USB came first, which is the point where it's a keyboard you can actually type on. A port to an E-YOOSO Z11 came next, and that was what forced the Air60-specific assumptions out of the way, taking the first steps into making this a more general keyboard firmware. Then media keys, NKRO, the LED effect engine, sleep, settings persistence, and fixing a pile of nasty timing bugs (USB-enumeration freezes, the LED scan and matrix scan fighting over the same pins), along with a bunch of cases where the stack would overflow or an interrupt would write into the wrong page. The 8051 isn't a forgiving architecture: the stack shares its 256 bytes of internal RAM with everything else, and nothing anywhere will fault on you, so mistakes like that don't crash, they just quietly corrupt something you notice a few keystrokes later.</p>
<p>Wireless was its own thing. The Air60 talks 2.4G and Bluetooth through a Beken BK3632, and the protocol between the MCU and that radio wasn't documented anywhere, so reproducing it in SMK meant reverse engineering the stock firmware and sitting a logic analyzer on the bus between the two to watch what they actually said to each other. That took a while to get right, but it works now, and it works well enough that I don't think about it anymore.</p>
<p>SMK isn't tied to the Air60 anymore either, which is what let it spread onto the Z11, a Genesis Thor 300 and a CIY X77, across a few different Sinowealth parts. Every one of those cheap <code>BYKxxx</code> and <code>BYxxxx</code> labelled boards is a potential target.</p>
<p>Testing all of that is the hard part, which is also why I've been holding off on accepting contributions so far. I don't own most of these keyboards, and with the amount of refactoring I've been doing, I'd have no way to tell whether a board I can't plug in still works afterwards. I have been experimenting with testing some of the more basic things in a modified build of <a rel="external" href="http://mazsola.iit.uni-miskolc.hu/ucsim/">ucsim</a>, so I think I might be able to start accepting contributions soon.</p>
<p>I should also mention that I started SMK as sort of a QMK clone for 8051, borrowing its keycodes and the general shape of things. But I never got much actual parity with QMK, and since then I've largely diverged from it anyway, so compatibility with QMK isn't the aim anymore.</p>
<h2 id="sinowealth-kb-tool-becomes-sinowisp">sinowealth-kb-tool becomes sinowisp<a class="zola-anchor" href="#sinowealth-kb-tool-becomes-sinowisp" aria-label="Anchor link for: sinowealth-kb-tool-becomes-sinowisp">§</a>
</h2>
<p>The little CLI from part 1 ended up carrying this whole project. Over time it picked up support for a lot more keyboards than I expected: somewhere around fifty of them now, plus a couple of mice.</p>
<p>Most of those entries didn't come from keyboards I own. Once the tool was out there, people started showing up with their own boards, filing device reports and dumps, and sometimes pull requests. I was surprised how common a platform this is for relatively inexpensive keyboards.</p>
<p>For a long time, it talked to keyboards through <a rel="external" href="https://github.com/libusb/hidapi">hidapi</a>, a C library. It works and it's on every platform, but having a C dependency in the mix got particularly annoying whenever I wanted to cross compile (might just be me). On top of that, I wanted something that could talk WebHID, and something that could give me several different backends on the same platform, so I could switch between them depending on what state the keyboard was in.</p>
<p>So I wrote my own cross-platform HID library in Rust.</p>
<p><a rel="external" href="https://github.com/karstx/hidra"><strong>hidra</strong></a> talks to the same platform APIs hidapi does: hidraw on Linux, hid.dll and SetupAPI on Windows, and IOKit's IOHIDManager on macOS. On top of those it adds <a rel="external" href="https://developer.mozilla.org/en-US/docs/Web/API/WebHID_API">WebHID</a>, so the same code runs in a browser, which is the whole reason the browser flasher later in this post exists at all. It's all one async API.</p>
<p>The part that ended up mattering most, though, is that it can carry several backends at once and switch between them at runtime. A keyboard shows up as a perfectly normal HID device, but the moment you send it into ISP mode its descriptors change, potentially into something the OS doesn't consider a valid HID device at all, so the native HID stack can't talk to it anymore. To get through you have to drop down to raw USB, which hidra does through <a rel="external" href="https://docs.rs/nusb">nusb</a> (a pure-Rust USB library, and the thing that made writing hidra feasible in the first place). So it carries both and picks: HID while the OS still sees a HID device, raw USB once ISP mode has left it undetectable as one.</p>
<p>That fixed some long-standing annoyances. Before, certain devices in ISP mode just couldn't be reached at all on some platforms, macOS especially.</p>
<p>The swap came with a restructure. The device-poking logic (read, write, erase, verify, all the bootloader quirks) now lives in a reusable <strong>library</strong>, with the CLI sitting on top as a thin shell. Pulling those apart, on top of hidra, is what lets the library build with no CLI dependencies at all, so it can be compiled for <a href="https://karstx.net/nuphy-air60-part-3/#smk-carlossless-io-flashing-from-a-browser">the web</a>.</p>
<p>At that point it wasn't really a kb-tool anymore, which was a good excuse to drop a working title I'd never liked: it's now <a rel="external" href="https://github.com/karstx/sinowisp"><strong>sinowisp</strong></a>.</p>
<h2 id="from-sinolink-to-sinodude">From SinoLink to sinodude<a class="zola-anchor" href="#from-sinolink-to-sinodude" aria-label="Anchor link for: from-sinolink-to-sinodude">§</a>
</h2>
<p>Time to talk about bricking again...</p>
<p>Part 2 covered how you brick one of these: flash firmware that can't jump back into the bootloader and the USB path is gone, leaving a programmer wired straight to the chip as the only way back in. When you're iterating on firmware, which involves writing a lot of broken firmware, you end up doing it more than you would expect.</p>
<p>That's why I bought the official option back in part 1: a Sinowealth <strong>SinoLink</strong> programmer, the probe the vendor's own ProWriter software drives. It works! But it's a proprietary black box with a Windows-only host tool, and I really don't like having one of those in the middle of an otherwise fully open project.</p>
<figure>
<a href="https://karstx.net/nuphy-air60-part-3/sinolink-connected-to-keyboard.jpg">
<img src="https://karstx.net/processed_images/sinolink-connected-to-keyboard.254abe7b3c45a292.jpg" srcset="https://karstx.net/processed_images/sinolink-connected-to-keyboard.2d087a65f981e870.jpg 2x" alt="a translucent blue SinoLink programmer on a cutting mat, wired through a small adapter board and a ribbon cable into the edge of the Air60" />
</a>
<figcaption class="center">the SinoLink, hooked up to the keyboard</figcaption>
</figure>
<p>So, naturally, I took it apart, and spent quite a while with its firmware in Ghidra.</p>
<p>The bit I actually cared about is how it programs the 8051 parts (Sinowealth makes ARM ones too). It does that over ICP, on the four JTAG lines. The annoying part is that these programming headers don't expose a reset line, so the only way into ICP is to switch the target's power off and back on, and start talking to it at the right moment. The read side of that was already mapped out by gashtaan in his <a rel="external" href="https://github.com/gashtaan/sinowealth-8051-dumper">sinowealth-8051-dumper</a>, so what I was after was the rest of it: page-write, mass-erase, the custom regions, and managing the security bits. And once I'd mapped that out, the obvious thought: if I understand the wire protocol, I don't need the dongle at all.</p>
<p>So I released <a rel="external" href="https://github.com/karstx/sinodude"><strong>sinodude</strong></a>: an open-source programmer that runs on a plain <strong>Arduino Nano</strong> (though it would take little to get it onto any compatible AVR) and can read and write most of the Sinowealth 8051 chips.</p>
<p>The Nano wasn't a random pick. The SinoLink is relatively expensive and, depending on where you are, hard to source, while a Nano is a couple of euros and you can get one anywhere, and anyone willing to crack open their keyboard has probably got one in a drawer already. gashtaan's dumper already runs on one too (it's the exact setup that I started with back in part 1), so there was a well-trodden path onto that hardware.</p>
<p>It also just made my life a lot better. I really disliked being stuck in the Windows-only ProWriter, and reverse-engineering how ProWriter itself talked to the SinoLink turned out to be harder than I expected. (I got a semi-working version of that going, and maybe I'll finish it off one day and add SinoLink support back into sinodude. We'll see.) Being able to run this programmer from a CLI, on Linux and macOS, was worth all of it.</p>
<p>The circuit is minimal: the four JTAG lines, ground, and one more pin driving a MOSFET that gates power to the target, so the programmer can time the power cycle these chips need itself. What it doesn't have is the circuitry the SinoLink puts around all this: a 3V3 supply alongside the 5V one, level translation between the probe and the target, and draining circuitry on the target's rails, without which the power cycle isn't always consistent on boards with more capacitance. But it's stable enough for me.</p>
<figure>
<div style="display: flex; flex-wrap: wrap; gap: 10px; max-width: 100%;">
<a href="https://karstx.net/nuphy-air60-part-3/sinodude-nano-connected-to-keyboard.jpg" style="flex: 1 1 200px; min-width: 0;">
<img src="https://karstx.net/processed_images/sinodude-nano-connected-to-keyboard.aa14cfbd046573b1.jpg" srcset="https://karstx.net/processed_images/sinodude-nano-connected-to-keyboard.a9d7713e008452c4.jpg 2x" alt="an Arduino Nano on a breadboard, wired through jumper wires and a ribbon cable to a NuPhy Air60 next to it" style="width: 100%;" />
</a>
<a href="https://karstx.net/nuphy-air60-part-3/sinodude-nano-connected-to-breakout.jpg" style="flex: 1 1 200px; min-width: 0;">
<img src="https://karstx.net/processed_images/sinodude-nano-connected-to-breakout.d090a3f179a61a90.jpg" srcset="https://karstx.net/processed_images/sinodude-nano-connected-to-breakout.b11d1fffac552a02.jpg 2x" alt="the same Nano on the breadboard, wired by jumper wires to a bare Sinowealth chip on a green breakout board" style="width: 100%;" />
</a>
<a href="https://karstx.net/nuphy-air60-part-3/connector-into-keyboard-pcb.jpg" style="flex: 1 1 200px; min-width: 0;">
<img src="https://karstx.net/processed_images/connector-into-keyboard-pcb.9fe9425f4c769fc9.jpg" srcset="https://karstx.net/processed_images/connector-into-keyboard-pcb.af17029d867cdea0.jpg 2x" alt="a ribbon cable plugged into a white connector on the Air60's blue PCB, between the switch sockets" style="width: 100%;" />
</a>
</div>
<figcaption class="center">sinodude (Arduino Nano) in action</figcaption>
</figure>
<p>On the host side it's the usual <code>read</code> / <code>write</code> / <code>erase</code> / <code>verify</code>, with a database of about 370 Sinowealth parts behind it, so it can read the JTAG ID off a target and suggest which parts match it, and with support for the EEPROM and all the custom regions these parts have (customer ID, option bytes, the security key, and so on).</p>
<figure>
<a href="https://karstx.net/nuphy-air60-part-3/sinowealth-chips-on-breakouts.jpg">
<img src="https://karstx.net/processed_images/sinowealth-chips-on-breakouts.32e90664ae3ebf41.jpg" srcset="https://karstx.net/processed_images/sinowealth-chips-on-breakouts.92287868c56d2d37.jpg 2x" alt="four green breakout boards on a wooden desk, each with a bare Sinowealth QFP chip soldered in the middle and jumper wires running off the pin headers" />
</a>
<figcaption class="center">bare Sinowealth parts on breakouts</figcaption>
</figure>
<p>One thing I haven't touched yet: the SinoLink can also do on-chip debugging (OCD) on these 8051 targets, not just flashing. That's something I'd like to reverse engineer some day. What I don't know yet is how hard it'd be to wire that up to something standard like <a rel="external" href="https://probe.rs/">probe-rs</a> or <a rel="external" href="https://openocd.org/">OpenOCD</a>, or whether these parts are too far off the beaten path for either to care. A problem for future me.</p>
<h2 id="smk-carlossless-io-flashing-from-a-browser">smk.carlossless.io: flashing from a browser<a class="zola-anchor" href="#smk-carlossless-io-flashing-from-a-browser" aria-label="Anchor link for: smk-carlossless-io-flashing-from-a-browser">§</a>
</h2>
<p>This was a fun detour.</p>
<p>Remember how I split the device logic into a sinowisp library, and wrote hidra so it could target WebHID? This is what that was all for. <a rel="external" href="https://smk.carlossless.io"><strong>smk.carlossless.io</strong></a> is a browser-based flasher for these keyboards. You plug in a HID device with one of these ISP bootloaders, click a button, and read or write its firmware straight from a web page. No CLI, no install, no cables beyond the USB one.</p>
<p>Under the hood it's exactly the pieces from above: sinowisp compiled to WebAssembly, talking to the keyboard over WebHID through hidra.</p>
<p>It works largely the same as sinowisp, but:</p>
<ul>
<li><strong>Chromium only.</strong> Firefox still doesn't ship WebHID, so it won't work there.</li>
<li><strong>It doesn't work on Linux.</strong> This one annoys me, given Linux is the platform I primarily use. The ISP bootloader's HID interface has no endpoints, so usbhid never binds it, and without a hidraw node there's nothing for WebHID to grab. The obvious fallback would be WebUSB, except Chrome refuses to hand over any interface that claims to be HID. So the device can't be reached over HID because the kernel won't treat it as one, and can't be reached over USB because Chrome insists that it is one.</li>
</ul>
<h2 id="a-new-base-for-the-keyboard-with-the-debug-bus-on-the-outside">A new base for the keyboard, with the debug bus on the outside<a class="zola-anchor" href="#a-new-base-for-the-keyboard-with-the-debug-bus-on-the-outside" aria-label="Anchor link for: a-new-base-for-the-keyboard-with-the-debug-bus-on-the-outside">§</a>
</h2>
<p>Which brings me back to the keyboard itself.</p>
<p>Getting this far meant JTAG leads soldered onto the Air60 (and a few other keyboards), and a whole logic-analyzer harness onto the bit-banged SPI bus to the BK3632. Doing that off flying leads on a half-open keyboard is as annoying as it sounds, especially when you want to be pressing buttons on the other side of it.</p>
<p>All that opening and closing had also wrecked the stock base, with a few of its standoffs disintegrating from being screwed and unscrewed so many times (it wasn't that many times...). So I fixed both at once.</p>
<p>First, a combined adapter PCB that lives inside the keyboard permanently, so all that access stays soldered down and I don't have to redo it every time.</p>
<p>Then a replacement base designed around it in FreeCAD, with the mounting, standoffs and cutouts worked out against the real PCB, and split into left and right halves so it fits on my printer.</p>
<p>The adapter breaks out:</p>
<ul>
<li><strong>the MCU's JTAG</strong> - TCK / TDI / TDO / TMS, plus +5V and GND</li>
<li><strong>the MCU-to-radio bus</strong> - the SPI lines MOSI / MISO / SCK / CS and the MOT and ACK handshake lines, plus +3V3 and GND</li>
</ul>
<p>All of it comes out to headers you can reach with the keyboard fully assembled and running.</p>
<figure>
<div style="display: flex; flex-wrap: wrap; gap: 10px; max-width: 100%;">
<a href="https://karstx.net/nuphy-air60-part-3/custom-base-inside-battery-and-adapter.jpg" style="flex: 1 1 200px; min-width: 0;">
<img src="https://karstx.net/processed_images/custom-base-inside-battery-and-adapter.d6fd94d9aca8587e.jpg" srcset="https://karstx.net/processed_images/custom-base-inside-battery-and-adapter.00960c82bda33b34.jpg 2x" alt="the printed base lying open on a cutting mat, with a silver LiPo battery and the purple adapter PCB mounted inside it" style="width: 100%;" />
</a>
<a href="https://karstx.net/nuphy-air60-part-3/custom-base-standoffs-and-connectors.jpg" style="flex: 1 1 200px; min-width: 0;">
<img src="https://karstx.net/processed_images/custom-base-standoffs-and-connectors.08be971a94cdad23.jpg" srcset="https://karstx.net/processed_images/custom-base-standoffs-and-connectors.405718905d01954b.jpg 2x" alt="close-up inside a corner of the base: printed standoffs, the two teal mode switches and the edge of the battery" style="width: 100%;" />
</a>
<a href="https://karstx.net/nuphy-air60-part-3/base-exposed-debug-access.jpg" style="flex: 1 1 200px; min-width: 0;">
<img src="https://karstx.net/processed_images/base-exposed-debug-access.6412989af0ca4372.jpg" srcset="https://karstx.net/processed_images/base-exposed-debug-access.83a527eda0881718.jpg 2x" alt="the back edge of the assembled base, with three square debug access ports below an orange flip-out foot and the two teal mode switches above" style="width: 100%;" />
</a>
<a href="https://karstx.net/nuphy-air60-part-3/assembled-keyboard-debug-ribbon.jpg" style="flex: 1 1 200px; min-width: 0;">
<img src="https://karstx.net/processed_images/assembled-keyboard-debug-ribbon.e84d769449f652fd.jpg" srcset="https://karstx.net/processed_images/assembled-keyboard-debug-ribbon.1c93c4c05577da7c.jpg 2x" alt="the fully assembled keyboard on a cutting mat, a ribbon cable running out of the side of its base to the SinoLink" style="width: 100%;" />
</a>
<a href="https://karstx.net/nuphy-air60-part-3/printed-base-split-halves.jpg" style="flex: 1 1 200px; min-width: 0;">
<img src="https://karstx.net/processed_images/printed-base-split-halves.8fb6bcad80c08281.jpg" srcset="https://karstx.net/processed_images/printed-base-split-halves.4aaf5648450a61a6.jpg 2x" alt="the underside of the printed base, showing the curved seam between the two printed halves, the two orange flip-out feet and the teal rubber strips" style="width: 100%;" />
</a>
<a href="https://karstx.net/nuphy-air60-part-3/custom-base-feet.jpg" style="flex: 1 1 200px; min-width: 0;">
<img src="https://karstx.net/processed_images/custom-base-feet.93081eedebd14ead.jpg" srcset="https://karstx.net/processed_images/custom-base-feet.a5f43cd6a96e8bed.jpg 2x" alt="the base standing on edge, showing the teal rubber strips and the three square debug access ports in its side" style="width: 100%;" />
</a>
</div>
<figcaption class="center">the new base, inside and out</figcaption>
</figure>
<p>Here's the base (drag to spin it):</p>
<div class="stl-1">
<script type="module">
import * as THREE from 'three';
import { STLLoader } from 'three/addons/loaders/STLLoader.js';
import { OrbitControls } from 'three/addons/controls/OrbitControls.js';
const scene = new THREE.Scene();
const camera = new THREE.PerspectiveCamera( 75, 1.25, 1, 1000);
const renderer = new THREE.WebGLRenderer({ alpha: true, antialias: true });
const controls = new OrbitControls(camera, renderer.domElement);
controls.enablePan = false;
controls.enableZoom = false;
// renderer.setSize(660, 528);
document.getElementsByClassName('stl-1')[0].appendChild(renderer.domElement);
const pointLight = new THREE.DirectionalLight(0xffffff, 3);
scene.add(pointLight);
let mesh
const loader = new STLLoader();
loader.load("nuphy-air60-base.stl", function (geometry) {
const material = new THREE.MeshLambertMaterial({color: 0xE752EE});
mesh = new THREE.Mesh(geometry, material);
mesh.geometry.center();
scene.add(mesh);
const offset = 1.7 / 1.35;
const boundingBox = new THREE.Box3();
boundingBox.setFromObject(mesh);
var middle = new THREE.Vector3();
var size = new THREE.Vector3();
boundingBox.getSize(size);
const fov = camera.fov * ( Math.PI / 180 );
const fovh = 2*Math.atan(Math.tan(fov/2) * camera.aspect);
let dx = size.z / 2 + Math.abs( size.x / 2 / Math.tan( fovh / 2 ) );
let dy = size.z / 2 + Math.abs( size.y / 2 / Math.tan( fov / 2 ) );
let cameraZ = Math.max(dx, dy);
// offset the camera, if desired (to avoid filling the whole canvas)
if( offset !== undefined && offset !== 0 ) cameraZ *= offset;
camera.position.set( 0, cameraZ/2, cameraZ );
// set the far plane of the camera so that it easily encompasses the whole object
const minZ = boundingBox.min.z;
const cameraToFarEdge = ( minZ < 0 ) ? -minZ + cameraZ : cameraZ - minZ;
camera.far = cameraToFarEdge * 3;
camera.updateProjectionMatrix();
});
function resizeCanvasToDisplaySize() {
const canvas = renderer.domElement.parentElement;
// look up the size the canvas is being displayed
const width = canvas.clientWidth;
// adjust displayBuffer size to match
if (canvas.width !== width) {
// you must pass false here or three.js sadly fights the browser
renderer.setSize(width, width/camera.aspect, false);
// camera.aspect = width / height;
camera.updateProjectionMatrix();
// update any render target sizes here
}
}
// camera.position.z = distance;
controls.autoRotate = true;
controls.update();
resizeCanvasToDisplaySize();
function animate() {
controls.update();
pointLight.position.copy(camera.position);
resizeCanvasToDisplaySize();
renderer.render( scene, camera );
}
renderer.setAnimationLoop( animate );
</script>
</div>
<h2 id="why-now-though">Why now, though?<a class="zola-anchor" href="#why-now-though" aria-label="Anchor link for: why-now-though">§</a>
</h2>
<p>A big reason I came back to this project at all is that LLM agents made the leftover parts finishable in the relatively little free time I have these days. What was left wasn't hard so much as tedious, and that's exactly the kind of work they're good at.</p>
<p>Reverse engineering is the obvious example, the SinoLink's firmware above as much as the keyboard's own stock firmware. A lot of it is just grinding: stepping through the disassembly, working out what a routine does, annotating it, and moving on to the next one. That's the part it's great at, and having it do that groundwork with me meant an hour in the evening was enough to get somewhere, instead of just enough to remember where I'd left off.</p>
<h2 id="what-s-next">What's next<a class="zola-anchor" href="#what-s-next" aria-label="Anchor link for: what-s-next">§</a>
</h2>
<p>"I don't like the stock software" turned into a bootloader flasher, a keyboard firmware, an in-circuit programmer for when that bootloader can't save you, a cross-platform HID library, the same flasher again in a browser, and a printed base that hands you the keyboard's own debug bus on a header. This is probably the deepest and most branching rabbit hole I've been down, and also one of the most rewarding.</p>
<p>There's still plenty I want to do:</p>
<ul>
<li><strong>An open-source ISP bootloader.</strong> The stock one is what bricks you, and it's the reason the browser flasher can't touch Linux. I'd like to replace it with one that presents itself as a proper HID device, which would kill the Linux limitation, and one that's actually recoverable: hold a key combination while plugging the keyboard in and you're in the bootloader, no programmer needed.</li>
<li><strong>An open-hardware replacement for the SinoLink.</strong> The Arduino Nano is the only programmer sinodude supports right now, and it's bare-bones. I want a proper little board around an RP2xxx, with the 5V / 3V3 muxing, level shifting and draining circuitry it's missing, and with a lot of the bit-banging living in the PIO instead of being timed by hand. And additionally, one day, hopefully, sinodude talking to a SinoLink directly as well.</li>
<li><strong>A lot more SMK.</strong> More refactoring, more boards, and (fingers crossed) more actual features.</li>
</ul>
<p>If you're interested in any of this, <a rel="external" href="https://github.com/karstx/smk">SMK is on GitHub</a> and there's a small community on <a rel="external" href="https://discord.gg/SZFBDBuxrK">Discord</a> if you want to come say hi.</p>
<p>Many thanks again to <a rel="external" href="https://github.com/gashtaan">@gashtaan</a> for releasing his <a rel="external" href="https://github.com/gashtaan/sinowealth-8051-dumper">dumper</a>, which enabled me to take the first steps in this project, and to <a rel="external" href="https://github.com/swiftgeek">@swiftgeek</a> for his <a rel="external" href="https://github.com/swiftgeek/hykker-re">reverse engineering work</a> around these chips!</p>
<p>See you in the next part!</p>
An Interesting Find: STM32 RDP1 "Decryptor"2026-03-01T00:00:00+00:002026-03-01T00:00:00+00:00
Unknown
https://karstx.net/stm32-rdp1-decryptor/<p>Recently while browsing <a rel="external" href="https://www.goofish.com/">Xianyu (闲鱼)</a> looking for BYK-series chips (Sinowealth 8051 MCUs) for another project I'm working on, I stumbled across something peculiar: a device claiming to bypass STM32 RDP1 (Read-Out Protection Level 1) on F0, F1, F2 and F4 series chips. As it turns out, there's a whole market for these if you search for <a rel="external" href="https://www.goofish.com/search?q=STM32%E8%A7%A3%E5%AF%86">"STM32解密"</a> (STM32 decryption).</p>
<figure>
<a href="https://karstx.net/stm32-rdp1-decryptor/./xianyu-listing.jpg">
<img src="https://karstx.net/processed_images/xianyu-listing.8f4b1f41ccf94f3c.jpg" srcset="https://karstx.net/processed_images/xianyu-listing.66c3cd2837f7cb0c.jpg 2x" alt="Xianyu listing photo showing the decryptor kit with USB dongle, multiple adapter PCBs and SWD pinout reference cards" />
</a>
<figcaption class="center">a picture from one of the many "STM32 decryptor" listings on Xianyu</figcaption>
</figure>
<p>At about 150 yuan, roughly 19 EUR plus shipping and forwarding on top, I decided to bite the bullet and just buy one to see if it actually works.</p>
<h2 id="what-arrived">What arrived<a class="zola-anchor" href="#what-arrived" aria-label="Anchor link for: what-arrived">§</a>
</h2>
<p>The package contained a blue USB dongle (the programmer), two green adapter PCBs, a row of double and a row of single 2.54mm pin headers and a couple of 10K resistors.</p>
<figure>
<a href="https://karstx.net/stm32-rdp1-decryptor/./kit-layout.jpg">
<img src="https://karstx.net/processed_images/kit-layout.9fed67d821d68bbc.jpg" srcset="https://karstx.net/processed_images/kit-layout.d88724bacd50e922.jpg 2x" alt="All components laid out on a cutting mat: USB dongle, two adapter PCBs, pin headers and connector" />
</a>
<figcaption class="center">everything that came in the package</figcaption>
</figure>
<p>The adapter boards have footprints for the various packages of F0, F1 and F2/F4 chips, along with pads for decoupling capacitors on the necessary VCAP pins and a resistor pulling BOOT1 down. I had to supply the 0.1uF caps for the VCAP pads myself.</p>
<figure>
<a href="https://karstx.net/stm32-rdp1-decryptor/./usb-dongle.jpg">
<img src="https://karstx.net/processed_images/usb-dongle.6a8c4af4c016f7b8.jpg" srcset="https://karstx.net/processed_images/usb-dongle.e97b294c23ed14f9.jpg 2x" alt="Close-up of the blue USB programmer dongle" />
</a>
</figure>
<h2 id="testing-with-an-stm32f205rbt6">Testing with an STM32F205RBT6<a class="zola-anchor" href="#testing-with-an-stm32f205rbt6" aria-label="Anchor link for: testing-with-an-stm32f205rbt6">§</a>
</h2>
<p>I had an STM32F205RBT6 lying around, so I desoldered it and placed it on the adapter board.</p>
<figure>
<a href="https://karstx.net/stm32-rdp1-decryptor/./adapter-board-connected.jpg">
<img src="https://karstx.net/processed_images/adapter-board-connected.b748169797e3f2da.jpg" srcset="https://karstx.net/processed_images/adapter-board-connected.59bd110bda35b172.jpg 2x" alt="STM32F205RBT6 soldered onto the adapter board and plugged into the USB dongle" />
</a>
<figcaption class="center">STM32F205RBT6 soldered onto the adapter board and plugged into the dongle</figcaption>
</figure>
<p>The device comes with a Windows utility. Before I could even get it running, I had to deal with a couple of hurdles. First, the software immediately triggers Windows Defender, probably for good reason. Since I was running this in a throwaway VM anyway, I just turned it off. Second, the application wouldn't launch until I changed the system encoding for non-Unicode programs to Chinese Simplified in the Windows 11 regional settings (<code>Settings > Time & language > Language & region > Language for non-Unicode programs > Chinese (Simplified, Mainland China)</code>).</p>
<p>The instructions that came with the device recommended using freeze spray on the chip during the read process. I was ready for that, but it turned out to be unnecessary in my case. It read just fine at room temperature.</p>
<figure>
<a href="https://karstx.net/stm32-rdp1-decryptor/./decryptor-utility.png">
<img src="https://karstx.net/processed_images/decryptor-utility.36913d8f3074c66f.png" alt="F0124 Series Decryptor V5.1 Windows utility showing a hex dump of flash contents read from an STM32F2/F4 chip" />
</a>
<figcaption class="center">the host Windows application showing a successful flash readout. The failed validation message at the bottom is probably related to the overshoot and can be ignored.</figcaption>
</figure>
<p>One quirk: the software would always overshoot when reading. A STM32F205RB has 128KB of flash, but the tool would happily read past that boundary, padding everything beyond it with <code>0xFF</code>. The actual flash contents within the valid 128KB region were correct though, so it's easy enough to just trim the output to the right size.</p>
<h2 id="conclusion">Conclusion<a class="zola-anchor" href="#conclusion" aria-label="Anchor link for: conclusion">§</a>
</h2>
<p>This thing actually works. It successfully dumped the full flash contents of an RDP1-protected STM32F205RBT6 without needing to introduce any external faults like cooling the chip down.</p>
<p>To be clear, this device is not the first to allow circumventing RDP1. There have already been documented ways for most of these devices: voltage glitching on <a rel="external" href="https://www.anvilsecure.com/blog/glitching-stm32-read-out-protection-with-voltage-fault-injection.html">STM32F4</a>, the <a rel="external" href="https://blog.zapb.de/stm32f1-exceptional-failure/">Exception(al) Failure</a> debug interface exploit on STM32F1, <a rel="external" href="https://www.aisec.fraunhofer.de/en/FirmwareProtection.html">Cold-Boot Stepping</a> on STM32F0, and <a rel="external" href="https://sec-consult.com/blog/detail/secglitcher-part-1-reproducible-voltage-glitching-on-stm32-microcontrollers/">reproducible glitching setups</a> with open-source tooling. But all of these require understanding the attack, building or buying a glitching rig, and tuning parameters. A turnkey product like this one just lets you solder the chip onto the adapter and click a button. It's both concerning and exciting.</p>
<p>Finally, other than glancing at the PCB, which has an SOP-16 IC with the label scraped off (presumably the microcontroller), I haven't tried analyzing how this device works yet. The Windows-only host app is not great either, but shouldn't be too hard to recreate it if someone wanted to. Might have to take a closer look at what's going on under the hood sometime. Or hopefully someone else will!</p>
racknex UM-SBC-209 + TI LP50122025-03-29T00:00:00+00:002025-03-29T00:00:00+00:00
Unknown
https://karstx.net/racknex-lp5012-leds/<p>As you might have seen from my <a href="/rpi-cluster-at-home/">previous post</a>, my RPi cluster is housed in a <a rel="external" href="https://racknex.com/raspberry-pi-rackmount-kit-4x-slot-19-inch-um-sbc-209/">racknex UM-SBC-209</a> case. It's a great case that I utilized to the max by setting up my RPis with poe+ hats, custom <a rel="external" href="https://github.com/karstx/qwiic-hat">hats</a> that I made to expose i2c via two <a rel="external" href="https://www.sparkfun.com/qwiic">qwiic</a> (jst sh) connectors and an additional 5v fan header that I use to connect to <a rel="external" href="https://noctua.at/de/products/fan/nf-a4x10-5v">Noctua NF-A4x10 5V</a> fans. I had made <a rel="external" href="https://github.com/karstx/keystone-oled">keystone holder</a> for a tiny OLED display and had it connected via the same Qwiic connectors. The only thing left untouched were the holes for the LEDs.</p>
<figure>
<a href="https://karstx.net/rpi-cluster-at-home/front.jpg">
<img src="https://karstx.net/processed_images/front.c50477fc5ba37bf5.jpg" srcset="https://karstx.net/processed_images/front.e7f75e0e7af4347e.jpg 2x" alt="racknex case with LED holes unpopulated" />
</a>
</figure>
<p>I wasn’t keen on wiring 3mm LEDs directly to individual GPIOs on the board. That's why my Qwiic hat was designed with two connectors instead of just one, though the second connector had been sitting idle for quite some time.</p>
<p>Finally, I decided it was time to put it to good use.</p>
<h2 id="electronics">Electronics<a class="zola-anchor" href="#electronics" aria-label="Anchor link for: electronics">§</a>
</h2>
<p>First off, I found a led controller. The <a rel="external" href="https://www.ti.com/lit/ds/symlink/lp5012.pdf">TI LP50xx</a> seemed like a great choice, since:</p>
<ul>
<li>it's driven through i2c</li>
<li>the LP5012 supports up to 4 RGB LEDs</li>
<li>the linux kernel has had a <a rel="external" href="https://github.com/torvalds/linux/blob/master/drivers/leds/leds-lp50xx.c">driver</a> for it for years now.</li>
</ul>
<p>I went ahead and designed a simple board for it, and there's not much to say about except that it's now <a rel="external" href="https://github.com/karstx/racknex-um-sbc-209-addons/tree/main/lp5012-leds/pcb">open source</a>.</p>
<p>When making a board this time around, instead of soldering components onto the board myself like I usually do, I took a gamble on the first revision and ordered it assembled by <a rel="external" href="https://jlcpcb.com/">JLCPCB</a> instead of assembling it myself.</p>
<p><figure>
<a href="https://karstx.net/racknex-lp5012-leds/./pcb-front.jpeg">
<img src="https://karstx.net/processed_images/pcb-front.57fc03c512679004.jpg" srcset="https://karstx.net/processed_images/pcb-front.92cdd7ee2bf8f225.jpg 2x" alt="PCB with LED side facing upward" />
</a>
</figure>
<figure>
<a href="https://karstx.net/racknex-lp5012-leds/pcb-back.jpeg">
<img src="https://karstx.net/processed_images/pcb-back.362bd546939a6c24.jpg" srcset="https://karstx.net/processed_images/pcb-back.c27520a2ea675bae.jpg 2x" alt="PCB with controller and connector facing upward" />
</a>
</figure>
</p>
<p>Surprisingly, everything worked on the first try!</p>
<p>A big shout-out to the maintainers of <a rel="external" href="https://web.git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/about/">i2c-tools</a>. This toolset was invaluable for quickly verifying that both the controller and LEDs were functioning correctly before proceeding to load the kernel driver via the device tree.</p>
<h2 id="bracket">Bracket<a class="zola-anchor" href="#bracket" aria-label="Anchor link for: bracket">§</a>
</h2>
<p>Even though this board works perfectly, it can't just float in mid-air. It needs to be securely positioned to align precisely with the LED holes. To solve this, I designed a custom bracket that fits snugly between the keystone frame, the Raspberry Pi and the bends of the front faceplate.</p>
<div class="stl-1">
<script type="module">
import * as THREE from 'three';
import { STLLoader } from 'three/addons/loaders/STLLoader.js';
import { OrbitControls } from 'three/addons/controls/OrbitControls.js';
const scene = new THREE.Scene();
const camera = new THREE.PerspectiveCamera( 75, 1.25, 1, 1000);
const renderer = new THREE.WebGLRenderer({ alpha: true, antialias: true });
const controls = new OrbitControls(camera, renderer.domElement);
controls.enablePan = false;
controls.enableZoom = false;
// renderer.setSize(660, 528);
document.getElementsByClassName('stl-1')[0].appendChild(renderer.domElement);
const pointLight = new THREE.DirectionalLight(0xffffff, 3);
scene.add(pointLight);
let mesh
const loader = new STLLoader();
loader.load("racknex-um-sbc-209-lp5012-bracket.stl", function (geometry) {
const material = new THREE.MeshLambertMaterial({color: 0xE752EE});
mesh = new THREE.Mesh(geometry, material);
mesh.geometry.center();
scene.add(mesh);
const offset = 1.7 / 1;
const boundingBox = new THREE.Box3();
boundingBox.setFromObject(mesh);
var middle = new THREE.Vector3();
var size = new THREE.Vector3();
boundingBox.getSize(size);
const fov = camera.fov * ( Math.PI / 180 );
const fovh = 2*Math.atan(Math.tan(fov/2) * camera.aspect);
let dx = size.z / 2 + Math.abs( size.x / 2 / Math.tan( fovh / 2 ) );
let dy = size.z / 2 + Math.abs( size.y / 2 / Math.tan( fov / 2 ) );
let cameraZ = Math.max(dx, dy);
// offset the camera, if desired (to avoid filling the whole canvas)
if( offset !== undefined && offset !== 0 ) cameraZ *= offset;
camera.position.set( 0, cameraZ/2, cameraZ );
// set the far plane of the camera so that it easily encompasses the whole object
const minZ = boundingBox.min.z;
const cameraToFarEdge = ( minZ < 0 ) ? -minZ + cameraZ : cameraZ - minZ;
camera.far = cameraToFarEdge * 3;
camera.updateProjectionMatrix();
});
function resizeCanvasToDisplaySize() {
const canvas = renderer.domElement.parentElement;
// look up the size the canvas is being displayed
const width = canvas.clientWidth;
// adjust displayBuffer size to match
if (canvas.width !== width) {
// you must pass false here or three.js sadly fights the browser
renderer.setSize(width, width/camera.aspect, false);
// camera.aspect = width / height;
camera.updateProjectionMatrix();
// update any render target sizes here
}
}
// camera.position.z = distance;
controls.autoRotate = true;
controls.update();
resizeCanvasToDisplaySize();
function animate() {
controls.update();
pointLight.position.copy(camera.position);
resizeCanvasToDisplaySize();
renderer.render( scene, camera );
}
renderer.setAnimationLoop( animate );
</script>
</div>
<p><figure>
<a href="https://karstx.net/racknex-lp5012-leds/bracket-front.jpeg">
<img src="https://karstx.net/processed_images/bracket-front.cf9b21c06b430ed1.jpg" srcset="https://karstx.net/processed_images/bracket-front.a502a6ef1aa5b88e.jpg 2x" alt="bracket with half-way inserted pcb from the front" />
</a>
</figure>
<figure>
<a href="https://karstx.net/racknex-lp5012-leds/bracket-back.jpeg">
<img src="https://karstx.net/processed_images/bracket-back.41b24583d9541366.jpg" srcset="https://karstx.net/processed_images/bracket-back.a54f3c28e4a719e4.jpg 2x" alt="bracket with fully inserted pcb from the back" />
</a>
</figure>
</p>
<p>I also needed some light pipes to transfer and diffuse the light better, fortunately it was easy to find some on <a rel="external" href="https://aliexpress.com/item/32969275348.html">aliexpress</a>.</p>
<figure>
<a href="https://karstx.net/racknex-lp5012-leds/bracked-light-pipe.jpeg">
<img src="https://karstx.net/processed_images/bracked-light-pipe.803a17708a326c4c.jpg" srcset="https://karstx.net/processed_images/bracked-light-pipe.6272f8db4bb4a5bc.jpg 2x" alt="bracket with light pipes inserted" />
</a>
<figcaption class="center">the front face of the case is about as thick as the light pipes poke out in the picture</figcaption>
</figure>
<h2 id="configuration">Configuration<a class="zola-anchor" href="#configuration" aria-label="Anchor link for: configuration">§</a>
</h2>
<p>Now that I had everything ready, assembled, and installed, the final step was to build a device-tree overlay that would enable the kernel to drive these LEDs and make them actually indicate something. Fortunately, this was easy to do, and I ended up with:</p>
<pre class="giallo" style="color: #D8DEE9; background-color: #2E3440;"><code data-lang="plain"><span class="giallo-l"><span>/dts-v1/;</span></span>
<span class="giallo-l"><span>/plugin/;</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span>#include <dt-bindings/leds/common.h></span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span>/ {</span></span>
<span class="giallo-l"><span> compatible = "brcm,bcm2711";</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span> fragment@0 {</span></span>
<span class="giallo-l"><span> target = <&i2c1>;</span></span>
<span class="giallo-l"><span> i2c_bus: __overlay__ {</span></span>
<span class="giallo-l"><span> led-controller@14 {</span></span>
<span class="giallo-l"><span> compatible = "ti,lp5012";</span></span>
<span class="giallo-l"><span> reg = <0x14>;</span></span>
<span class="giallo-l"><span> #address-cells = <1>;</span></span>
<span class="giallo-l"><span> #size-cells = <0>;</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span> multi-led@0 {</span></span>
<span class="giallo-l"><span> #address-cells = <1>;</span></span>
<span class="giallo-l"><span> #size-cells = <0>;</span></span>
<span class="giallo-l"><span> reg = <0>;</span></span>
<span class="giallo-l"><span> color = <LED_COLOR_ID_RGB>;</span></span>
<span class="giallo-l"><span> function = LED_FUNCTION_POWER;</span></span>
<span class="giallo-l"><span> default-state = "off";</span></span>
<span class="giallo-l"><span> linux,default-trigger = "default-on";</span></span>
<span class="giallo-l"><span> max-brightness = <127>;</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span> led@0 {</span></span>
<span class="giallo-l"><span> reg = <0>;</span></span>
<span class="giallo-l"><span> color = <LED_COLOR_ID_RED>;</span></span>
<span class="giallo-l"><span> };</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span> led@1 {</span></span>
<span class="giallo-l"><span> reg = <1>;</span></span>
<span class="giallo-l"><span> color = <LED_COLOR_ID_GREEN>;</span></span>
<span class="giallo-l"><span> };</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span> led@2 {</span></span>
<span class="giallo-l"><span> reg = <2>;</span></span>
<span class="giallo-l"><span> color = <LED_COLOR_ID_BLUE>;</span></span>
<span class="giallo-l"><span> };</span></span>
<span class="giallo-l"><span> };</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span> multi-led@1 {</span></span>
<span class="giallo-l"><span> ...</span></span>
<span class="giallo-l"><span> }</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span> ...</span></span>
<span class="giallo-l"><span> };</span></span>
<span class="giallo-l"><span> };</span></span>
<span class="giallo-l"><span> };</span></span>
<span class="giallo-l"><span>};</span></span></code></pre>
<p>Unfortunately there currently is no way to set the initial color intensity through the device tree, so I had to do that via a oneshot systemd service:</p>
<pre class="giallo" style="color: #D8DEE9; background-color: #2E3440;"><code data-lang="nix"><span class="giallo-l"><span style="color: #ECEFF4;">{}: {</span></span>
<span class="giallo-l"><span style="color: #8FBCBB;"> systemd</span><span>.</span><span style="color: #8FBCBB;">services</span><span>.</span><span style="color: #8FBCBB;">lp5012-intensity</span><span style="color: #81A1C1;"> =</span><span style="color: #ECEFF4;"> {</span></span>
<span class="giallo-l"><span style="color: #8FBCBB;"> enable</span><span style="color: #81A1C1;"> = true;</span></span>
<span class="giallo-l"><span style="color: #8FBCBB;"> wantedBy</span><span style="color: #81A1C1;"> =</span><span style="color: #ECEFF4;"> [ "</span><span style="color: #A3BE8C;">multi-user.target</span><span style="color: #ECEFF4;">" ]</span><span style="color: #81A1C1;">;</span></span>
<span class="giallo-l"><span style="color: #8FBCBB;"> serviceConfig</span><span style="color: #81A1C1;"> =</span><span style="color: #ECEFF4;"> {</span></span>
<span class="giallo-l"><span style="color: #8FBCBB;"> Type</span><span style="color: #81A1C1;"> =</span><span style="color: #ECEFF4;"> "</span><span style="color: #A3BE8C;">oneshot</span><span style="color: #ECEFF4;">"</span><span style="color: #81A1C1;">;</span></span>
<span class="giallo-l"><span style="color: #8FBCBB;"> User</span><span style="color: #81A1C1;"> =</span><span style="color: #ECEFF4;"> "</span><span style="color: #A3BE8C;">root</span><span style="color: #ECEFF4;">"</span><span style="color: #81A1C1;">;</span></span>
<span class="giallo-l"><span style="color: #8FBCBB;"> Group</span><span style="color: #81A1C1;"> =</span><span style="color: #ECEFF4;"> "</span><span style="color: #A3BE8C;">root</span><span style="color: #ECEFF4;">"</span><span style="color: #81A1C1;">;</span></span>
<span class="giallo-l"><span style="color: #8FBCBB;"> RemainAfterExit</span><span style="color: #81A1C1;"> = true;</span></span>
<span class="giallo-l"><span style="color: #ECEFF4;"> }</span><span style="color: #81A1C1;">;</span></span>
<span class="giallo-l"><span style="color: #8FBCBB;"> script</span><span style="color: #81A1C1;"> =</span><span style="color: #ECEFF4;"> ''</span></span>
<span class="giallo-l"><span style="color: #A3BE8C;"> if [ -d /sys/class/leds/rgb:power ]; then</span></span>
<span class="giallo-l"><span style="color: #A3BE8C;"> echo "0 255 0" > /sys/class/leds/rgb:power/multi_intensity</span></span>
<span class="giallo-l"><span style="color: #A3BE8C;"> fi</span></span>
<span class="giallo-l"><span style="color: #A3BE8C;"> ...</span></span>
<span class="giallo-l"><span style="color: #ECEFF4;"> ''</span><span style="color: #81A1C1;">;</span></span>
<span class="giallo-l"><span style="color: #ECEFF4;"> }</span><span style="color: #81A1C1;">;</span></span>
<span class="giallo-l"><span style="color: #ECEFF4;">}</span></span></code></pre>
<p>You can find the full nix module which includes the full device-tree overlay in this <a rel="external" href="https://gist.github.com/karstx/867fc12315b6f09e82c09430d6eeb63f">gist</a>.</p>
<h1 id="end">End<a class="zola-anchor" href="#end" aria-label="Anchor link for: end">§</a>
</h1>
<p><figure>
<a href="https://karstx.net/racknex-lp5012-leds/racknex-rpi-top.jpeg">
<img src="https://karstx.net/processed_images/racknex-rpi-top.02d903ceefd9d0f8.jpg" srcset="https://karstx.net/processed_images/racknex-rpi-top.28af69aaea0deb88.jpg 2x" alt="RPi with several hats in a racknex UM-SBC-209 case" />
</a>
</figure>
<figure>
<a href="https://karstx.net/racknex-lp5012-leds/racknex-front-leds.gif">
<img src="https://karstx.net/racknex-lp5012-leds/racknex-front-leds.gif" alt="indicators in action" />
</a>
</figure>
</p>
<p>And that's it, I finally feel this project is complete... for now...</p>
<p>You can find all the custom parts used in this project here:</p>
<ul>
<li><a rel="external" href="https://github.com/karstx/racknex-um-sbc-209-addons">racknex-um-sbc-209-addons</a></li>
<li><a rel="external" href="https://github.com/karstx/qwiic-hat">qwiic-hat</a></li>
<li><a rel="external" href="https://github.com/karstx/keystone-oled">keystone-oled</a></li>
</ul>
Hacking the NuPhy Air60 keyboard: part 22023-10-19T00:00:00+00:002023-10-19T00:00:00+00:00
Unknown
https://karstx.net/nuphy-air60-part-2/<p><em>This project continued in <a href="/nuphy-air60-part-3">part 3</a>.</em></p>
<p>It's time I wrote an update on this project again!</p>
<p>Since my <a href="/nuphy-air60">last update</a>, I've been working on bootstrapping a development toolchain and producing a minimal firmware where I could initialize and test the core features of the SH68F90A along side of booting back into the ISP bootloader (otherwise the keyboard will become unprogramable via USB).</p>
<p>I am happy to say that I managed to do that, and released everything I have done so far on <a rel="external" href="https://github.com/karstx/sh68f90a-experiments">github</a>.</p>
<h2 id="v2-has-already-been-released">V2 has already been released<a class="zola-anchor" href="#v2-has-already-been-released" aria-label="Anchor link for: v2-has-already-been-released">§</a>
</h2>
<p>Before I get into what I managed to do, I should note that NuPhy have recently released <a rel="external" href="https://nuphy.com/products/air60-v2">V2 of the Air60</a> and <a rel="external" href="https://nuphy.com/products/air75-v2">Air75</a> keyboards. These new versions are powered by ARM MCUs instead of the 8051-based SH68F90A and comes with <a rel="external" href="https://github.com/qmk/qmk_firmware">QMK</a> support out of the box.</p>
<p>I originally started this project, because I wanted to have QMK-like firmware on this keyboard, but since these news have come out, it has becomes purely a learning experience.</p>
<p>If you're interested in this project because of the possibility of running QMK on a Air60 or Air75 I really recommend you to just get the new version of these keyboards!</p>
<p>But anyway, on to the toolchain...</p>
<h2 id="embracing-open-source-tooling">Embracing Open-Source Tooling<a class="zola-anchor" href="#embracing-open-source-tooling" aria-label="Anchor link for: embracing-open-source-tooling">§</a>
</h2>
<p>A core principle of this project is to use all open source tooling to build the firmware. That's why I am using <a rel="external" href="https://sdcc.sourceforge.net/">SDCC</a> here, instead of the proprietary <a rel="external" href="https://developer.arm.com/Tools%20and%20Software/Keil%20PK51">Keil C51</a> which seems to be a standard for developing for 8051 MCUs.</p>
<p>I have SDCC configured with the smallest device size, so that all variables are put onto the IRAM, unless they are annotated differently (<code>__xdata</code>, <code>__code</code>, etc.).</p>
<p>The firmware size is 61440 leaving the remaining 4096 bytes untouched for the ISP bootloader.</p>
<p>When the ISP bootloader flashes the given firmware the finalisation routine looks for a <code>ljmp</code> instruction at <code>0xeffb</code> and if considers it valid, it will place it at <code>0x0000</code>, otherwise it will place a <code>ljmp</code> to <code>0xf000</code> (back to the bootloader itself). I gather that this is a mechanism to prevent corrupted firmware from being written to the device and then never being able to boot back into itself. Though, if you write non-corrupted, but non-working firmware, you won't be able to boot back into the ISP and you will need a programming device, like the sinolink. Be careful!. (Did I mention this is an incredibly brickable device?)</p>
<p>Anyway, because of this reason, I have added <a rel="external" href="https://github.com/karstx/sh68f90a-experiments/blob/main/src/preboot.asm">preboot.asm</a> which places this <code>ljmp</code> that points to the start of the user firmware at the previously mentioned place.</p>
<h1 id="diving-into-sh68f90a-s-capabilities">Diving into SH68F90A's Capabilities<a class="zola-anchor" href="#diving-into-sh68f90a-s-capabilities" aria-label="Anchor link for: diving-into-sh68f90a-s-capabilities">§</a>
</h1>
<p>The SH68F90A on the Air60 (and other Air models) come with the following <a rel="external" href="https://github.com/karstx/sh68f90a-experiments/blob/03552c6c6244f24ed6f9fd129a96ea96d5d76dd5/README.md#code-options">code-options</a> set. Since I would like to be able to load both the stock firmware and my own firmware through USB, I can't change these values to something else, but that also means that my firmware needs to do some specific initialization for the functionality these options require.</p>
<p>The first thing that needs to be setup is the 24MHz SYSCLK infrastructure, this involves initializing the PLL and then swiching SYSCLK to use the clock signal that's coming out of it, instead of the 128kHz OSC. <a rel="external" href="https://github.com/karstx/sh68f90a-experiments/blob/03552c6c6244f24ed6f9fd129a96ea96d5d76dd5/src/clock.c">link</a></p>
<p>Next, since we have the watchdog enabled, we need to configure the watchdog to use a comfortable overflow amount and then make sure that our firmware clears the watchdog timer before it overflows. (I wasn't able to test the WDT RESET flag, that would've helped in making this firmware a little bit less brickable). <a rel="external" href="https://github.com/karstx/sh68f90a-experiments/blob/03552c6c6244f24ed6f9fd129a96ea96d5d76dd5/src/watchdog.h">link</a></p>
<p>USB signaling also requires 3.3V, so we also need to initialize the internal voltage regulator. <a rel="external" href="https://github.com/karstx/sh68f90a-experiments/blob/03552c6c6244f24ed6f9fd129a96ea96d5d76dd5/src/ldo.c">link</a></p>
<p>Here we're already at a point where we have done enough initialization for the ISP bootloader program to work, so already, we could jump into it if we wanted <a rel="external" href="https://github.com/karstx/sh68f90a-experiments/blob/03552c6c6244f24ed6f9fd129a96ea96d5d76dd5/src/isp.c">link</a>.</p>
<p>GPIO setup is fairly straightforward, we setup the inputs and outputs, pull-ups according to the key matrix rows (input) and columns (output) and the RGB leds per row, per column. <a rel="external" href="https://github.com/karstx/sh68f90a-experiments/blob/03552c6c6244f24ed6f9fd129a96ea96d5d76dd5/src/gpio.c">link</a></p>
<p>Lastly, a pretty important tool for debugging (in absence of on-chip debugging via USB) is getting UART to work. This is fairly straightforward, and explained ok-ish in the datasheet, but the macros I added to calculate <code>SBRT</code> and <code>SFINE</code> values based on the desired baudrate should make it more easy to work with. Also, since the default (TXD, RXD) UART pins are harder to reach, I am setting the <code>MAPPING</code> register to <code>0x5a</code> to use the M_TXD and M_RXD pins instead, because they are also connected to the columns and the removable switch sockets, plugging in header cables for my USB<->SERIAL device, though it should be noted that PWM signals will interfere with the UART signals and you might get garbage in your serial output.</p>
<p><img src="https://karstx.net/nuphy-air60-part-2/uart.jpg" alt="uart connected through 5th and 6th key columns" loading="lazy" decoding="async" /></p>
<p align="center">
<img alt="hello world printed on screen" src="hello-world.png">
</p>
<h2 id="">On the horizon<a class="zola-anchor" href="#" aria-label="Anchor link for: ">§</a>
</h2>
<p>Moving forward I will be continuing work on <a rel="external" href="https://github.com/karstx/sh68f90a-experiments">sh68f90a-experiments</a> focusing on getting the following functionalities to work:</p>
<ol>
<li>Key Matrix</li>
<li>PWM + RGB LED Matrix</li>
<li>USB (it's a working keyboard!)</li>
<li>Wireless (stretch-goal)</li>
</ol>
<p>Stay tuned for more updates!</p>
Hacking the NuPhy Air60 keyboard: part 12023-04-19T00:00:00+00:002023-04-19T00:00:00+00:00
Unknown
https://karstx.net/nuphy-air60/<p><em>This project continued in <a href="/nuphy-air60-part-2">part 2</a> and <a href="/nuphy-air60-part-3">part 3</a>.</em></p>
<p>Not too long ago, I got a <a rel="external" href="https://nuphy.com/products/air60">NuPhy Air60</a> keyboard. I got it because I think it looks great! It has a mostly aluminum body, low profile switches along with low profile keycaps, switch sockets so that they can be removed without soldering, 2.4G wireless alongside Bluetooth, and RGB backlighting (yay?). Great right? I think so.</p>
<p><img src="https://karstx.net/nuphy-air60/keyboard.jpg" alt="keyboard" loading="lazy" decoding="async" /></p>
<p>What's not great about it is its software and its firmware. NuPhy has a Windows-only tool to configure the keyboard and from what I can tell it's very limited in what sort of key combinations it can support... For a long time, I've been using a <a rel="external" href="https://github.com/komar007/gh60">GH60</a> with <a rel="external" href="https://github.com/qmk/qmk_firmware">QMK</a> until it broke on me and since then I've been mostly using Apple keyboards.</p>
<p>So I opened up the keyboard and when I was greeted with an IC that was labeled only with a "BYK916" I knew that this won't be easy... There was barely any information about chips like this. Seemingly Chinese companies would use this sort of labeling to hide away hardware implementation details or make their own custom packages, but I can't tell for sure.</p>
<p><img src="https://karstx.net/nuphy-air60/mcu.jpg" alt="BYK916" loading="lazy" decoding="async" /></p>
<p>I tried looking for any info online and on my first try I found nothing... A little bit of time passed and I tried again - this time there was a <a rel="external" href="https://www.reddit.com/r/RedragonGaming/comments/nsdw7x/comment/hjwyu8q">reddit post</a> mentioning that a package like this was found in another keyboard and is actually a relabeled <a rel="external" href="https://www.sinowealth.com/detaile?pro_id=105">Sinowealth SH68F90</a>. Interesting! But it's still a dead end for me since I don't have any tools to program these chips. On my third try, I was lucky enough to find <a rel="external" href="https://github.com/gashtaan/sinowealth-8051-dumper">gashtaans sinowealth-8051-dumper</a> which supported my MCU. I didn't own any Arduinos by this point, so I set out to buy a Nano, and along the way I also learned about the existence of the ATmega328P clone LogicGreen LGT8F328P, but I digress...</p>
<p>I set up my Arduino with the dumper firmware and was able to <a rel="external" href="https://github.com/gashtaan/sinowealth-8051-dumper/issues/2#issuecomment-1440488904">semi-successfully read firmware</a>. Nice!</p>
<p><img src="https://karstx.net/nuphy-air60/flash-dump.jpg" alt="flash dumping setup" loading="lazy" decoding="async" /></p>
<p>After a bit of rummaging through datasheets, buying a Sinolink programmer off of Taobao, and consulting others interested in this hardware I eventually figured out that I could use the already built-in ISP mode to upload my own firmware via USB, with no additional hardware needed. After a bit of sniffing and analyzing NuPhy's firmware update utility, I started building my own tool and...</p>
<p>I present you the <a rel="external" href="https://github.com/karstx/sinowealth-kb-tool">sinowealth-kb-tool</a>!</p>
<p>The tool is not only capable of replacing the existing device firmware but also reading it completely verbatim. Also, while working on the tool I became familiar with different variations of this bootloader in other keyboards out there in the wild and I hope to add support for more of them in the future!</p>
<p>Many thanks to <a rel="external" href="https://github.com/gashtaan">@gashtaan</a> for the dumper and <a rel="external" href="https://github.com/swiftgeek">@swiftgeek</a> for his documentation efforts!</p>
<p>Now on to writing some firmware... See you in the <a href="/nuphy-air-60-part-2">next part</a>!</p>
Raspberry Pi PoE+ hat with nixos2022-08-07T00:00:00+00:002022-08-07T00:00:00+00:00
Unknown
https://karstx.net/nix-rpi-poe-plus-hat/<p>As previously mentioned in <a href="https://karstx.net/rpi-cluster-at-home/">my last post</a>, I've been using <a rel="external" href="https://nixos.org/">nixos</a> to run my raspberry-pi k3s cluster.</p>
<p>Things have been working great and managing these machines has never been this pleasant, <strong>except for one thing</strong> - the cooling fans which come with the <a rel="external" href="https://www.raspberrypi.com/products/poe-plus-hat/">PoE+ hats</a> refuse to work out of the box with nixos.</p>
<p>These fans are enabled without any extra configuration under <a rel="external" href="https://www.raspberrypi.com/software/">Raspberry Pi OS</a>, so I know that they <em>can</em> work, it just leaves me to figure out how to make them work...</p>
<h2 id="journey">Journey<a class="zola-anchor" href="#journey" aria-label="Anchor link for: journey">§</a>
</h2>
<p>After doing a bit of research I found that due to an incompatibility with the RPi bootloader and how nixos is designed to be used, the device tree cannot be passed down from the bootloader to the kernel, and thus a dtb must be "pre-baked" before some of the optional hardware, like these fans, can be used. This means that all overlays must be applied at compile time before the final dtb is produced. Nixos provides <code>hardware.deviceTree.overlays</code> to do just that.</p>
<p>Naturally, using <code>hardware.deviceTree.overlay</code> would be the way to go, and there's already <a rel="external" href="https://github.com/NixOS/nixos-hardware/blob/09ed30ff3bb67f5efe9c77e0d79aca01793526ca/raspberry-pi/4/poe-hat.nix#L18">examples of taking almost unchanged overlays from rpi/linux</a> and applying them through this mechanism.</p>
<p>Unfortunately, some of the overlays that are available in <a rel="external" href="https://github.com/raspberrypi/linux/tree/rpi-5.15.y/arch/arm/boot/dts/overlays">raspberrypi/linux</a> can not be successfully applied with the <code>fdtoverlay</code> tool used <a rel="external" href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/device-tree/default.nix#L24">here</a>. It just fails with barely any output other than a not-so-helpful <code>FDT_NOT_FOUND</code> error, and even running it in verbose mode with <code>fdtoverlay -v</code> does not provide any additional hints.</p>
<p>Digging into it more, I found that these overlays actually require RPiFs own <a rel="external" href="https://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/dtmerge/dtmerge.c">dtmerge</a> tool for successfully application.</p>
<p>After a bit of fiddling, I found that exchanging the implementation of applyOverlay with one that uses <code>dtmerge</code> instead of <code>fdtoverlay</code> was enough to successfully produce a valid dtb, and with it, kick my rpi fans into motion.</p>
<h2 id="result">Result<a class="zola-anchor" href="#result" aria-label="Anchor link for: result">§</a>
</h2>
<p>I have created <a rel="external" href="https://github.com/NixOS/nixos-hardware/pull/442">a pull-request in nixos-hardware</a> using the previously mentioned findings as a solution. <del>I'm not sure if this will ever be merged, but even if it won't be, it should serve as an example to anyone who would like to get their PoE+ hat fans working under nixos</del>.</p>
<p>UPDATE: It's been merged!</p>
Raspberry Pi Cluster @ Home2022-07-16T00:00:00+00:002022-07-16T00:00:00+00:00
Unknown
https://karstx.net/rpi-cluster-at-home/<p>I recently decided to move most of my meager server workloads from the cloud back to my own home.</p>
<p>If you're asking <strong>"why???"</strong> Then I would have to ask you to settle down and inform you that it's much more a <strong>"why not???"</strong> situation.</p>
<p>I wanted to try and learn <a rel="external" href="https://nixos.org/">nixos</a> and <a rel="external" href="https://kubernetes.io/">k8s</a> (through <a rel="external" href="https://k3s.io/">k3s</a>) and I like the idea of owning and having control over my hardware, that's pretty much the whole reason.</p>
<p>I'm not the first to do something like this and there are plenty of resources from people like <a rel="external" href="https://www.jeffgeerling.com/tags/k3s">Jeff Geerling</a> that are doing the same with similar setups.</p>
<h2 id="hardware">Hardware<a class="zola-anchor" href="#hardware" aria-label="Anchor link for: hardware">§</a>
</h2>
<p>I wanted to have a nice clean rack-mountable enclosure for this cluster, but that took me on a path to design and produce several accessories to get more utility out of it, like <a rel="external" href="https://github.com/karstx/keystone-oled">keystone-oled</a> and <a rel="external" href="https://github.com/karstx/qwiic-hat">qwiic-hat</a>. Here are a few images of the project in it's current state.</p>
<table><thead><tr><th>Enclosure</th><th>Front</th><th>Qwiic Hat</th><th>Mounted</th></tr></thead><tbody>
<tr><td><a href="https://karstx.net/rpi-cluster-at-home/enclosure.jpg"><img src="https://karstx.net/rpi-cluster-at-home/enclosure.jpg" alt="enclosure" loading="lazy" decoding="async" /></a></td><td><a href="https://karstx.net/rpi-cluster-at-home/front.jpg"><img src="https://karstx.net/rpi-cluster-at-home/front.jpg" alt="front" loading="lazy" decoding="async" /></a></td><td><a href="https://karstx.net/rpi-cluster-at-home/qwiic-hat.jpg"><img src="https://karstx.net/rpi-cluster-at-home/qwiic-hat.jpg" alt="i2c-hat" loading="lazy" decoding="async" /></a></td><td><a href="https://karstx.net/rpi-cluster-at-home/mounted.jpg"><img src="https://karstx.net/rpi-cluster-at-home/mounted.jpg" alt="mounted" loading="lazy" decoding="async" /></a></td></tr>
</tbody></table>
<h3 id="">BOM<a class="zola-anchor" href="#" aria-label="Anchor link for: ">§</a>
</h3>
<ul>
<li>1x <a rel="external" href="https://shop.racknex.com/19-inch-raspberry-pi-rackmount-kit-um-sbc-209/">racknex UM-SBC-209</a></li>
<li>4x <a rel="external" href="https://www.raspberrypi.com/products/raspberry-pi-4-model-b/">Raspberry Pi 4B</a></li>
<li>4x <a rel="external" href="https://www.raspberrypi.com/products/poe-plus-hat/">POE+ hat</a></li>
<li>16x M2.5 15mm standoffs</li>
<li>8x M2.5 5mm standoffs</li>
<li>16x M2.5 flathead philips screws</li>
<li>4x <a rel="external" href="https://www.reichelt.de/sg/de/buchsenleisten-2-54-mm-2x02-gerade-mpe-094-2-004-p119926.html?&trstct=pos_0&nbc=1">2x2 2.54mm socket</a> - for RPi POE pins</li>
<li>4x <a rel="external" href="https://www.reichelt.de/sg/de/raspberry-pi-gpio-header-40-polig-rm-2-54-farblich-kodiert-rpi-header-cg2-p266032.html">2x20 2.54mm socket with long pins</a> - for RPi GPIO pins</li>
<li>4x <a rel="external" href="https://github.com/karstx/keystone-oled">keystone-oled</a></li>
<li>4x <a rel="external" href="https://www.buydisplay.com/i2c-white-0-49-inch-oled-display-module-64x32-arduino-raspberry-pi">0.49 inch OLED SSD1306 32x64</a></li>
<li>4x <a rel="external" href="https://github.com/karstx/qwiic-hat">qwiic-hat</a></li>
</ul>
<h2 id="-1">Software<a class="zola-anchor" href="#-1" aria-label="Anchor link for: -1">§</a>
</h2>
<p>The software driving the OLED screens is a small custom rust app using the userspace i2cdev interface. It shows node IPs, CPU temps and supports animated transitions, but it's not really finished and I haven't released it, <em>yet</em>...</p>
<p>I have tried using the <a rel="external" href="https://github.com/torvalds/linux/blob/master/drivers/video/fbdev/ssd1307fb.c">ssd1307fb</a> driver to expose it as a linux framebuffer device, but I couldn't get it working perfectly and decided to drop it all together. I am looking it forward to trying <a rel="external" href="https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/solomon/ssd130x-i2c.c">the drm rewrite of the driver</a> though.</p>
<h2 id="-2">Future Improvements & Notes<a class="zola-anchor" href="#-2" aria-label="Anchor link for: -2">§</a>
</h2>
<p>LEDs: In the future I would also like to mount RGB LEDs in those currently vacant holes. I have yet to design a board for them, but that's why I have a second unused qwiic/I2C port.</p>
<p>fans: There are mounting holes on the UM-SBC-209 case for 40mm fans, but I don't yet have a way of powering them. I am considering expanding the qwiic-hat to include a 4-pin PWM fan connector to power and control the fan.</p>
APFS Volumes for your git projects2019-06-10T15:02:00+00:002019-06-10T15:02:00+00:00
Unknown
https://karstx.net/solving-that-pesky-file-rename-in-git-with-apfs-volumes/<p>I've been using this setup for over 2 years now and it saved me from a large number of small to medium headaches that used to haunt me every so often. Because of this, I think it's worth talking about in a blog post.</p>
<h1 id="so-what-am-i-talking-about">So what am I talking about?<a class="zola-anchor" href="#so-what-am-i-talking-about" aria-label="Anchor link for: so-what-am-i-talking-about">§</a>
</h1>
<p>Ever had to commit a file only to realize that you got the capitalization wrong? I've certainly been in that situation.</p>
<p>Well you'd think that you could just go back, edit the filename, <code>git commit --commit</code> and you're good, right? Wrong.</p>
<p><a rel="external" href="https://asciinema.org/a/AXQ3HyaE4vz6G4HUUeN2HJvg7"><img src="https://asciinema.org/a/AXQ3HyaE4vz6G4HUUeN2HJvg7.svg" alt="asciicast" loading="lazy" decoding="async" /></a></p>
<p>Well... Wrong for most users at least, because most of them will notice that the naming change wasn't picked up by git.</p>
<p>The reason why? It's probably because you're using a case-insensitive file system. It used to be the default option for HFS+, and it still is the default for APFS. Some applications rely on this to be the case, like the Adobe suite, so you don't want to change case-sensitivity for your whole system drive.</p>
<h1 id="">Volumes to the rescue!<a class="zola-anchor" href="#" aria-label="Anchor link for: ">§</a>
</h1>
<p>APFS redefines partitions with the introduction of <em>volumes</em>. Normal partitions and APFS volumes differ in many ways, but the two that we care about in this case are:</p>
<ul>
<li>Space sharing - volumes don't have predetermined sizes and will be able to "grow" until there's no space left in the container.</li>
<li>Independent configuration - different volumes can have different variants of APFS setup. In our case we can have a case-insensitive volume and a case-sensitive one.</li>
</ul>
<p>So, in my case I created a new volume APFS called <strong>Projects</strong> with case-sensitive filenames and put all of my code and repositories in it.</p>
<p><a href="https://karstx.net/solving-that-pesky-file-rename-in-git-with-apfs-volumes/hZ6ABYkF5ngLZ49NUt8qa10xspap.png"><img src="https://karstx.net/solving-that-pesky-file-rename-in-git-with-apfs-volumes/hZ6ABYkF5ngLZ49NUt8qa10xspap.png" alt="Screenshot 2019-06-10 at 15.53.17.png" loading="lazy" decoding="async" /></a></p>
<p>Et Voilà! All filename changes are now getting picked up by <code>git status</code>.</p>
<p><a rel="external" href="https://asciinema.org/a/j22jhjqBkIstyWy24LVT8blyg"><img src="https://asciinema.org/a/j22jhjqBkIstyWy24LVT8blyg.svg" alt="asciicast" loading="lazy" decoding="async" /></a></p>
Xcode 9 and Carthage - stripping out llvm instrument symbols2017-09-17T03:32:00+00:002017-09-17T03:32:00+00:00
Unknown
https://karstx.net/xcode-9-and-carthage-coverage-data/<p>Like any other year the new Xcode GM came out and everybody started rushing to submit their apps. This year, I was also one of these early adopters. Things were going relatively smoothly, except for a weird issue with <code>xattr</code> when trying to export archives. Regardless, I uploaded the build and was ready to see it processed... And then...</p>
<h1 id="the-problem">The Problem<a class="zola-anchor" href="#the-problem" aria-label="Anchor link for: the-problem">§</a>
</h1>
<p><a href="https://karstx.net/xcode-9-and-carthage-coverage-data/ic3junrykhonww.png"><img src="https://karstx.net/xcode-9-and-carthage-coverage-data/ic3junrykhonww.png" alt="Screen Shot 2017-09-14 at 12.42.56.png" loading="lazy" decoding="async" /></a></p>
<blockquote>
<p><strong>Invalid Bundle</strong> - Disallowed LLVM instrumentation. Do not submit apps with LLVM profiling instrumentation or coverage collection enabled. Turn off LLVM profiling or code coverage, rebuild your app and resubmit the app.</p>
</blockquote>
<p>LLVM instrumentation? What? I thought that gets striped out on Archive?</p>
<p>Well it turns out, that it does get stripped out, but only for the main application. I use <a rel="external" href="https://github.com/Carthage/Carthage">Carthage</a> for dependency management and Carthage doesn't build targets with the Archive action (<a rel="external" href="https://github.com/Carthage/Carthage/issues/169#issuecomment-68624884">or rather it can't</a>) and Xcode 9 enables code coverage by default:</p>
<p><a href="https://karstx.net/xcode-9-and-carthage-coverage-data/3sxvt5m7mcmzfq.png"><img src="https://karstx.net/xcode-9-and-carthage-coverage-data/3sxvt5m7mcmzfq.png" alt="Screen Shot 2017-09-14 at 19.03.43.png" loading="lazy" decoding="async" /></a></p>
<h1 id="">The Solution?<a class="zola-anchor" href="#" aria-label="Anchor link for: ">§</a>
</h1>
<p><code>xcodebuild</code> flags don't seem to affect this issue, meaning that every framework developer that makes their libraries available through Carthage will have to manually change this setting.</p>
<p>For the time being you'll have to checkout all of the dependencies and manually change <code>CLANG_ENABLE_CODE_COVERAGE</code> to <code>NO</code> for every dependency before building them with <code>carthage build</code>.</p>
<h1 id="-1">Survival through Tooling<a class="zola-anchor" href="#-1" aria-label="Anchor link for: -1">§</a>
</h1>
<p>I've made <a rel="external" href="https://gist.github.com/karstx/9492d8e20938cfd1ee8163d7cdbfab9b">a little script</a> that streamlines checking for LLVM instrument symbols. Change your working directory to the root of your project and you can pipe this script straight into bash (if you dare):</p>
<pre class="giallo" style="color: #D8DEE9; background-color: #2E3440;"><code data-lang="shellscript"><span class="giallo-l"><span style="color: #88C0D0;">curl</span><span style="color: #A3BE8C;"> -fsSL https://gist.githubusercontent.com/karstx/9492d8e20938cfd1ee8163d7cdbfab9b/raw</span><span style="color: #81A1C1;"> |</span><span style="color: #88C0D0;"> bash</span></span></code></pre>
<p>Hopefully we'll see improvements in later versions of Xcode and <code>xcodebuild</code>, but for now we'll have to live with this.</p>
<h5 id="-2">Resources<a class="zola-anchor" href="#-2" aria-label="Anchor link for: -2">§</a>
</h5>
<ul>
<li><a rel="external" href="https://developer.apple.com/library/content/qa/qa1964/_index.html#//apple_ref/doc/uid/DTS40017675-CH1-INSPECT">Apple Developer Docs - Technical Q&A QA1964: Resolving App Rejections for GCC and LLVM Instrumentation</a></li>
<li><a rel="external" href="https://github.com/Carthage/Carthage/issues/2056">GitHub Issues - Carthage - Targets built with coverage data in Xcode 9 #2056</a></li>
</ul>
Reverse Hackintosh Pro2017-06-17T15:08:00+00:002017-06-17T15:08:00+00:00
Unknown
https://karstx.net/reverse-hackintosh-pro/<p>Well it's been awhile, but I'm back to doing my own projects again.</p>
<h1 id="prelude">Prelude<a class="zola-anchor" href="#prelude" aria-label="Anchor link for: prelude">§</a>
</h1>
<p>So lately I've been feeling left out of the gaming world and thought to myself: "Hey why not build a sweet new gaming rig and jump right back into all of the fun?". Well, knowing myself I knew that after playing a couple of games, I would get bored and this rig won't see much use after that.</p>
<p>To counteract that I need to be able to do work on it. But I'm an iOS developer and practically there's only one platform that I can do my work on - macOS.</p>
<p>Alright, so it's a Hackintosh then!</p>
<p>Apple hasn't released significantly improved hardware for "pros" in years now, so this might actually be good timing to build one.</p>
<p>But let's not make things too simple. Remember those older Mac Pros? The cheese graters? Those cases look awesome and sleek, wouldn't it be awesome to build a pc in one of them? There's other people doing it also? SIGN ME UP!</p>
<p><a href="https://karstx.net/reverse-hackintosh-pro/vlfs0cslbsouw.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/vlfs0cslbsouw.jpg" alt="cheese-grater.JPG" loading="lazy" decoding="async" /></a></p>
<h1 id="">Table of Contents<a class="zola-anchor" href="#" aria-label="Anchor link for: ">§</a>
</h1>
<!-- toc -->
<h1 id="-1">Build<a class="zola-anchor" href="#-1" aria-label="Anchor link for: -1">§</a>
</h1>
<p>After doing some research I found a guy in Berlin who sold me his broken 2016 Mac Pro for 50€. After taking it home I immediately stripped most of the parts from it and started looking for suitable components.</p>
<h2 id="-2">BOM<a class="zola-anchor" href="#-2" aria-label="Anchor link for: -2">§</a>
</h2>
<p>I had simple requirements for the motherboard:</p>
<ol>
<li>It had to be Micro ATX form factor. So I wouldn't have to cut the case to make room for a full ATX motherboard.</li>
<li>It had to have Thunderbolt compatibility, preferably Thunderbolt 2, so I could use my Thunderbolt display with it.</li>
</ol>
<p>This is what I ended up with:</p>
<table><thead><tr><th>Part</th><th>Brand</th><th>Name</th><th>Quantity</th></tr></thead><tbody>
<tr><td>Motherboard</td><td>GIGABYTE</td><td>GA-Z170MX-Gaming 5</td><td>1</td></tr>
<tr><td>CPU</td><td>Intel</td><td>Core™ i7-6700K</td><td>1</td></tr>
<tr><td>GPU</td><td>EVGA</td><td>GeForce GTX 980 Ti HYBRID GAMING</td><td>1</td></tr>
<tr><td>RAM</td><td>Corsair</td><td>Vengeance® LPX 32GB (4 x 8GB) DDR4 DRAM 2400MHz</td><td>1</td></tr>
<tr><td>M2</td><td>Samsung</td><td>950 PRO M.2 256GB</td><td>1</td></tr>
<tr><td>SATA</td><td>Samsung</td><td>850-EVO 500GB</td><td>4</td></tr>
<tr><td>PCIE</td><td>AsRock</td><td>Thunderbolt™ 2 AIC</td><td>1</td></tr>
<tr><td>PCIE</td><td>Wdxxfu Studio Design</td><td>BCM943602CS (WIFI+BT)</td><td>1</td></tr>
<tr><td>PSU</td><td>EVGA</td><td>850 GQ Power Supply</td><td>1</td></tr>
<tr><td>CPU Cooler</td><td>Alpenföhn</td><td>Ben Nevis</td><td>1</td></tr>
<tr><td>Case Fan</td><td>Noctua</td><td>NF-S12B redux-700</td><td>1</td></tr>
<tr><td>Case Fan</td><td>Noctua</td><td>NF-S12B redux-1200</td><td>1</td></tr>
<tr><td>MISC</td><td>NewerTech</td><td>AdaptaDrive</td><td>4</td></tr>
</tbody></table>
<p><a href="https://karstx.net/reverse-hackintosh-pro/irj7mosz2bjiea.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/irj7mosz2bjiea.jpg" alt="bom.jpg" loading="lazy" decoding="async" /></a></p>
<h2 id="-3">Hardware<a class="zola-anchor" href="#-3" aria-label="Anchor link for: -3">§</a>
</h2>
<h3 id="-4">mATX Motherboard Tray<a class="zola-anchor" href="#-4" aria-label="Anchor link for: -4">§</a>
</h3>
<p>I went and got the mATX kit from <a rel="external" href="http://www.thelaserhive.com/product/mac-pro-matx-120-kit/">the laser hive</a> (plastic grill version). They provide pretty comprehensive instructions with the kit, so inserting and fastening the tray was a breeze. Cutting out and the back and attaching the back panel wasn't too hard either.</p>
<p><a href="https://karstx.net/reverse-hackintosh-pro/2ixet7kyer79a.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/2ixet7kyer79a.jpg" alt="empty-case.jpg" loading="lazy" decoding="async" /></a>
<a href="https://karstx.net/reverse-hackintosh-pro/yyrnypby6d6rq.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/yyrnypby6d6rq.jpg" alt="back-stripped.jpg" loading="lazy" decoding="async" /></a></p>
<h3 id="-5">Power Supply<a class="zola-anchor" href="#-5" aria-label="Anchor link for: -5">§</a>
</h3>
<p>The PSU was probably one of the components that I had to do the most work on in order to get it inside the case.</p>
<p>At first I thought I could stick in the internals of a standard power supply into the case of the original Mac Pro PSU. However, that didn't work out because the PSU would overheat after a few minutes under intense load. I had to scrap the original PSU I had bought and get another one.</p>
<p><a href="https://karstx.net/reverse-hackintosh-pro/m5qomtedsseow.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/m5qomtedsseow.jpg" alt="psu-oem.jpg" loading="lazy" decoding="async" /></a></p>
<h4 id="-6">Cable<a class="zola-anchor" href="#-6" aria-label="Anchor link for: -6">§</a>
</h4>
<p>I wanted to reuse the original AC port, so I had to make a little low profile adapter to solve the different placement of the cable port.</p>
<p><a href="https://karstx.net/reverse-hackintosh-pro/vjjlmpmygwoz1q.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/vjjlmpmygwoz1q.jpg" alt="psu-cable-front.jpg" loading="lazy" decoding="async" /></a>
<a href="https://karstx.net/reverse-hackintosh-pro/rdmcatkv3z6sq.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/rdmcatkv3z6sq.jpg" alt="psu-cable-back.jpg" loading="lazy" decoding="async" /></a>
<a href="https://karstx.net/reverse-hackintosh-pro/ickhzmms8il1q.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/ickhzmms8il1q.jpg" alt="psu-connection-closeup.jpg" loading="lazy" decoding="async" /></a></p>
<h4 id="-7">Case<a class="zola-anchor" href="#-7" aria-label="Anchor link for: -7">§</a>
</h4>
<p>I had to cut off one end of the original PSU case in order for it to house the new longer PSU. I also had to remove the PSU fan assembly from the case to fit the new PSU.</p>
<p><a href="https://karstx.net/reverse-hackintosh-pro/adzbhnvjyubsw.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/adzbhnvjyubsw.jpg" alt="psu-case.jpg" loading="lazy" decoding="async" /></a>
<a href="https://karstx.net/reverse-hackintosh-pro/lwiowvar0qzhyg.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/lwiowvar0qzhyg.jpg" alt="psu-tray-cutoff.jpg" loading="lazy" decoding="async" /></a>
<a href="https://karstx.net/reverse-hackintosh-pro/vgfjnnyyvabsba.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/vgfjnnyyvabsba.jpg" alt="psu-connection.jpg" loading="lazy" decoding="async" /></a>
<a href="https://karstx.net/reverse-hackintosh-pro/xtzoae7ocmcpgg.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/xtzoae7ocmcpgg.jpg" alt="psu-assembled.jpg" loading="lazy" decoding="async" /></a></p>
<h3 id="-8">Front Panel<a class="zola-anchor" href="#-8" aria-label="Anchor link for: -8">§</a>
</h3>
<p>I wanted to reuse the Mac Pros front panel interface. To do that neatly I had to make a couple PCBs.</p>
<p><a href="https://karstx.net/reverse-hackintosh-pro/3oikcvg9eybdq.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/3oikcvg9eybdq.jpg" alt="12pin-adapter-pcb.jpg" loading="lazy" decoding="async" /></a>
<a href="https://karstx.net/reverse-hackintosh-pro/gc2g1vzdp4uhva.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/gc2g1vzdp4uhva.jpg" alt="usb-adapter-pcb.jpg" loading="lazy" decoding="async" /></a></p>
<p>The designs for these PCBs are free and available on <a rel="external" href="https://github.com/karstx/mac-pro-conversion">GitHub</a>, you can use any PCB manufacturing service to make these, but I personally prefer <a rel="external" href="https://oshpark.com/">OSH Park</a> for prototypes.</p>
<p>Here are the adapters in action:</p>
<p><a href="https://karstx.net/reverse-hackintosh-pro/it9goyyx18yfq.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/it9goyyx18yfq.jpg" alt="usb-adapter-in-action.jpg" loading="lazy" decoding="async" /></a>
<a href="https://karstx.net/reverse-hackintosh-pro/9whphqhnbhaaw.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/9whphqhnbhaaw.jpg" alt="12pin-adapter-pcb-in-action.jpg" loading="lazy" decoding="async" /></a>
<a href="https://karstx.net/reverse-hackintosh-pro/oscndcpxp67yq.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/oscndcpxp67yq.jpg" alt="front-panel-pcb.jpg" loading="lazy" decoding="async" /></a></p>
<p><strong>One important note:</strong> the original 8 pin Micro-FIT cable that caries power for the panel from the original motherboard has it's pins mirrored on both ends. The pcb is designed for that cable, so you should be good if you use it. However, if you're making your own adapter, please check which pin on one end corresponds to what pin on the other end.</p>
<h3 id="-9">SATA<a class="zola-anchor" href="#-9" aria-label="Anchor link for: -9">§</a>
</h3>
<p>The SATA slots in the mac pro are pretty frigging cool, I wanted to make them functional with the new motherboard. Fortunately this was pretty easy (but pricey). I had to buy <a rel="external" href="http://www.maxupgrades.com/istore/index.cfm?fuseaction=product.display&product_ID=330&ParentCat=332">this adapter</a>. Making one doesn't make sense as the parts themselves cost almost as much as this fully build adapter.</p>
<p><a href="https://karstx.net/reverse-hackintosh-pro/ba9jkpmignshq.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/ba9jkpmignshq.jpg" alt="scsi-adapter.jpg" loading="lazy" decoding="async" /></a>
<a href="https://karstx.net/reverse-hackintosh-pro/orzkkspssxgzcw.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/orzkkspssxgzcw.jpg" alt="scsi-adapter-with-sata.jpg" loading="lazy" decoding="async" /></a>
<a href="https://karstx.net/reverse-hackintosh-pro/vofbqzldrzxw.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/vofbqzldrzxw.jpg" alt="scsi-adapter-in-action.jpg" loading="lazy" decoding="async" /></a></p>
<p>The drawers obviously also need SATA power, so I had to make a little adapter from the PSU to the custom apple connector. Sadly, I did not take a picture of it, and it's pretty deep in the case to remove it.</p>
<p>As there's not too many reasons to go with a mechanical hard drive and SATA SSDs only come in 2.5" I had to buy a few 3.5" to 2.5" adapters. There are plenty of these available to buy on Amazon.</p>
<h3 id="-10">Front Fan Assembly<a class="zola-anchor" href="#-10" aria-label="Anchor link for: -10">§</a>
</h3>
<p>Because of a very nice deal, I got an air-cooled, water-cooled hybrid GPU. One problem is that it comes with a gigantic radiator that needs to go somewhere in the case. Fortunately the original fan assembly was ideal for this. Just after a few modifications to (with a handy dremel) it I could easily hold the radiator and fan on top of it.</p>
<p><a href="https://karstx.net/reverse-hackintosh-pro/cworxxwnziszg.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/cworxxwnziszg.jpg" alt="fan-assembly-back.jpg" loading="lazy" decoding="async" /></a>
<a href="https://karstx.net/reverse-hackintosh-pro/arnyygt280haqg.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/arnyygt280haqg.jpg" alt="fan-assembly-front.jpg" loading="lazy" decoding="async" /></a>
<a href="https://karstx.net/reverse-hackintosh-pro/euisgplvzl6q.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/euisgplvzl6q.jpg" alt="gpu-fan-assembly.jpg" loading="lazy" decoding="async" /></a></p>
<h3 id="-11">Wifi<a class="zola-anchor" href="#-11" aria-label="Anchor link for: -11">§</a>
</h3>
<p>After some research, it became obvious that the best WIFI adapter for macOS is an original one. Fortunately for me, China if full of them. I got mine from <a rel="external" href="https://world.taobao.com/item/38195333521.htm?fromSite=main&spm=a230r.1.0.0.M8souu">TaoBao</a>. No additional steps needed to get WI-FI working. Although iMessage is another story...</p>
<p><a href="https://karstx.net/reverse-hackintosh-pro/sfcoeatsoebc2g.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/sfcoeatsoebc2g.jpg" alt="wifi.jpg" loading="lazy" decoding="async" /></a></p>
<h3 id="-12">Thunderbolt<a class="zola-anchor" href="#-12" aria-label="Anchor link for: -12">§</a>
</h3>
<p>I wanted to use my Apple Thunderbolt Display with this machine, so thunderbolt support was imperative.</p>
<p><a href="https://karstx.net/reverse-hackintosh-pro/h2msvivladnqlg.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/h2msvivladnqlg.jpg" alt="thunderbolt.jpg" loading="lazy" decoding="async" /></a></p>
<p>However macOS support for third party controllers is very... very... flaky. I had different levels of success, but nothing came close to being truly stable. Either the displays USB hub wouldn't work, or daisy chaining a hard drive wouldn't work, or the display wouldn't turn on in general. You can get it to work though and that's good enough for now.</p>
<p>The controller itself wouldn't ever get recognized by System Information, although it's children peripherals would show up as if they're hooked in directly in the system.</p>
<h3 id="-13">Back Fan<a class="zola-anchor" href="#-13" aria-label="Anchor link for: -13">§</a>
</h3>
<p>I had to cut off sides of the original backside fan grill in order to make it fit with the ATX motherboard backplate. But the amount of flat plastic surface left is enough to drill holes into the other side of the grill and attach the actual new fan to itself.</p>
<p><a href="https://karstx.net/reverse-hackintosh-pro/7ofbcld3rk4bsg.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/7ofbcld3rk4bsg.jpg" alt="back-fan-back.jpg" loading="lazy" decoding="async" /></a>
<a href="https://karstx.net/reverse-hackintosh-pro/bjgg7o3ampac2a.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/bjgg7o3ampac2a.jpg" alt="back-fan-front.jpg" loading="lazy" decoding="async" /></a></p>
<h3 id="-14">Other Pictures<a class="zola-anchor" href="#-14" aria-label="Anchor link for: -14">§</a>
</h3>
<p><a href="https://karstx.net/reverse-hackintosh-pro/pcrkonxob92j3g.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/pcrkonxob92j3g.jpg" alt="finished.jpg" loading="lazy" decoding="async" /></a>
<a href="https://karstx.net/reverse-hackintosh-pro/jhwqlc8pszpnq.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/jhwqlc8pszpnq.jpg" alt="drawer-out.jpg" loading="lazy" decoding="async" /></a>
<a href="https://karstx.net/reverse-hackintosh-pro/itibyi2498boew.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/itibyi2498boew.jpg" alt="case-backside.jpg" loading="lazy" decoding="async" /></a>
<a href="https://karstx.net/reverse-hackintosh-pro/qn5kitdqf2nxla.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/qn5kitdqf2nxla.jpg" alt="items.jpg" loading="lazy" decoding="async" /></a>
<a href="https://karstx.net/reverse-hackintosh-pro/fqffuoienz1yw.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/fqffuoienz1yw.jpg" alt="case-backside-front.jpg" loading="lazy" decoding="async" /></a></p>
<h2 id="-15">Software<a class="zola-anchor" href="#-15" aria-label="Anchor link for: -15">§</a>
</h2>
<h3 id="-16">BIOS Options<a class="zola-anchor" href="#-16" aria-label="Anchor link for: -16">§</a>
</h3>
<p>Before installing macOS it's important to change a few BIOS settings from their default values:</p>
<ul>
<li>Enable XHCI Handoff (important for USB to work)</li>
<li>Disable Serial IO</li>
<li>Enable Thunderbolt
<ul>
<li>Security: Legacy</li>
</ul>
</li>
</ul>
<h3 id="-17">Installation, Clover<a class="zola-anchor" href="#-17" aria-label="Anchor link for: -17">§</a>
</h3>
<p>I used <a rel="external" href="https://www.tonymacx86.com/resources/categories/tonymacx86-downloads.3/">UniBeast</a> to install macOS and <a rel="external" href="https://www.tonymacx86.com/resources/categories/tonymacx86-downloads.3/">MultiBeast</a> to configure all the options, injected kexts and etc. There are a number of guides on the web that cover this hardware, and some of the options depends on taste, so I won't cover them here.</p>
<p>It's generally a good idea to have the latest version of <a rel="external" href="https://sourceforge.net/projects/cloverefiboot/">Clover</a> installed. Multibeast usually comes with a version that's stable, but pretty outdated.</p>
<p>A very helpful tool if you don't want to deal with plists all the time when tweaking your Clover settings is the <a rel="external" href="http://mackie100projects.altervista.org/download-clover-configurator/">Clover Configurator</a>.</p>
<h3 id="-18">iMessage, iCloud, App Store<a class="zola-anchor" href="#-18" aria-label="Anchor link for: -18">§</a>
</h3>
<p>This is probably what gives people the most headaches in getting their hackintoshes fully working. I used a couple techniques to get this finally working.</p>
<p>I had success in following <a rel="external" href="http://www.fitzweekly.com/2016/02/hackintosh-imessage-tutorial.html">this guide</a>. But before I got everything working, I had my Apple ID account locked multiple times, so beware! It's no big deal of course, you just need to come up with a new password every time, but it's SEVERELY ANNOYING.</p>
<h3 id="-19">NVMe Storage<a class="zola-anchor" href="#-19" aria-label="Anchor link for: -19">§</a>
</h3>
<p>To get the NVMe storage drive to work (including installing macOS on that drive) I just used RehabMan's wonderful <a rel="external" href="https://github.com/RehabMan/patch-nvme">kext patches</a>. He has very comprehensive instructions on what needs to be done.</p>
<h3 id="-20">GPU<a class="zola-anchor" href="#-20" aria-label="Anchor link for: -20">§</a>
</h3>
<p>Getting the GPU to work is pretty straightforward. All I had to do is install the latest <a rel="external" href="https://www.tonymacx86.com/nvidia-drivers/">NVIDIA Web Drivers</a>. And making sure that the clover flag to use them is set "nvda_drv=1".</p>
<h1 id="-21">Other Stuff<a class="zola-anchor" href="#-21" aria-label="Anchor link for: -21">§</a>
</h1>
<p>Like any project, this one has it's share of notes and fails. Here's a few of them.</p>
<h2 id="-22">Original Build<a class="zola-anchor" href="#-22" aria-label="Anchor link for: -22">§</a>
</h2>
<p>This is what I had planned to use initially:</p>
<table><thead><tr><th>Part</th><th>Brand</th><th>Name</th></tr></thead><tbody>
<tr><td>Motherboard</td><td>AsRock</td><td>Fatal1ty X99M Killer/3.1</td></tr>
<tr><td>CPU</td><td>Intel</td><td>Core™ i7-6800K</td></tr>
<tr><td>GPU</td><td>EVGA</td><td>GeForce GTX 980 Ti HYBRID GAMING</td></tr>
<tr><td>RAM</td><td>Corsair</td><td>Vengeance® LPX 32GB (4 x 8GB) DDR4 DRAM 2400MHz</td></tr>
<tr><td>Drive</td><td>Samsung</td><td>950 PRO M.2 256GB</td></tr>
<tr><td>PCIE</td><td>AsRock</td><td>Thunderbolt™ 2 AIC</td></tr>
<tr><td>PSU</td><td>EVGA</td><td>850 GQ Power Supply</td></tr>
<tr><td>CPU Cooler</td><td>Alpenföhn</td><td>Ben Nevis</td></tr>
<tr><td>Case Fans</td><td>Noctua</td><td>2x NF-S12B redux-700 + 1x NF-S12B redux-1200</td></tr>
</tbody></table>
<h3 id="-23">Chipset & Thunderbolt<a class="zola-anchor" href="#-23" aria-label="Anchor link for: -23">§</a>
</h3>
<blockquote>
<p>Now I know what you're thinking. X99? That's going to be a pain to install macOS on, if possible at all. And, well you're right, but the reason I picked the Fatal1ty X99M Killer was because that was the only Micro ATX board with thunderbolt a capability and AsRock had it's AIC card for sale. In comparison Gigabyte had a Z170 Micro ATX motherboard with a Thunderbolt header, but Gigabytes AIC card wasn't being sold ANYWHERE. Only later did I find out that most of these thunderbolt cards are intercompatible between different brands...</p>
</blockquote>
<p>X99 support proved to be to difficult, and the interchangeability of the thunderbolt cards pushed me to use Z170 instead.</p>
<h3 id="-24">Standoffs<a class="zola-anchor" href="#-24" aria-label="Anchor link for: -24">§</a>
</h3>
<blockquote>
<p>In order to stuff some components in and connect others I had to make some modifications to the case. The first of these modifications was to remove the existing motherboard standoffs. This was fairly simple, you can remove the standoffs with pliers or a hammer. The next step was to to glue my own standoffs with epoxy, I did it by screwing in all of the standoffs to the motherboard and then covering their bottom ends with a small layer of epoxy, I put the motherboard into the case and aligned it, waited for some time and then undid the screws and took out the motherboard, I covered the base of the standoffs with more epoxy around them to secure them in place. You need to be careful when screwing your motherboard back in, because even though the epoxy has a pretty firm grip on the standoffs you can still break them off with enough force when screwing in the screws.</p>
</blockquote>
<p>After breaking a few of them, and ultimately needing the back facing IO ports more than I expected I got a ATX conversion kit from lazer hive.</p>
<h2 id="-25">The Perfect Build<a class="zola-anchor" href="#-25" aria-label="Anchor link for: -25">§</a>
</h2>
<p>Before doing this project I did some research on already existing builds. One build I found was absolutely amazing.</p>
<p>Skin008 - a Chinese electrical engineer and serial mac pro modder, made a one of a kind mac pro retrofit kit that reuses the same ports on the original 2008 and 2010 macs.</p>
<p><a href="https://karstx.net/reverse-hackintosh-pro/jjqpu8ly9azjow.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/jjqpu8ly9azjow.jpg" alt="skin008-board.jpg" loading="lazy" decoding="async" /></a>
<a href="https://karstx.net/reverse-hackintosh-pro/q0yltbzvuc0kw.jpg"><img src="https://karstx.net/reverse-hackintosh-pro/q0yltbzvuc0kw.jpg" alt="skin008-case.jpg" loading="lazy" decoding="async" /></a></p>
<p>I reached out to him, but found out that he only did 10 of these boards, sold them and was too busy with his personal stuff to make new ones this year. He did mention however that he may do another batch next year. I hope that’s true and I’ll try to keep in touch with him. You can find more pictures of his boards showcased <a rel="external" href="http://acidluna.tistory.com/295">here</a>.</p>
Convenient Dependency Injection in Swift2015-10-17T05:09:00+00:002015-10-17T05:09:00+00:00
Unknown
https://karstx.net/convenient-di-in-swift/<p>Ever since Swift 1.0 was released, I have been struggling with finding a way to introduce some proper dependency injection into my code. The previous methods that were popular in objective-C like Swizzling or property overloading no longer works or require far too many changes to your code to make them actually worth it.</p>
<p><a rel="external" href="https://twitter.com/natashatherobot">Natasha Murashev</a> posted some nice ideas about dependency injection through default property values in functions, you can read more about that <a rel="external" href="https://web.archive.org/web/20151113113136/http://natashatherobot.com/unit-testing-swift-dependency-injection/">here</a>.</p>
<p>But there's one problem with this solution, the default values require that the concrete implementation be dragged in and linked with your testing target, and that might be something that you don't want to do.</p>
<p>Today I bring you a way to solve these issues: by using default property values, (convenience) initilizers and type extensions to introduce some really convenient dependency injection.</p>
<h1 id="the-example">The Example<a class="zola-anchor" href="#the-example" aria-label="Anchor link for: the-example">§</a>
</h1>
<p>Let's start with the dependant type:</p>
<pre class="giallo" style="color: #D8DEE9; background-color: #2E3440;"><code data-lang="swift"><span class="giallo-l"><span style="color: #81A1C1;">public struct</span><span> Farm</span><span style="color: #ECEFF4;"> {</span></span>
<span class="giallo-l"><span> </span></span>
<span class="giallo-l"><span style="color: #81A1C1;"> private let</span><span> animals:</span><span style="color: #ECEFF4;"> [</span><span>Animal</span><span style="color: #ECEFF4;">]</span></span>
<span class="giallo-l"><span> </span></span>
<span class="giallo-l"><span style="color: #81A1C1;"> init</span><span style="color: #ECEFF4;">(</span><span style="color: #88C0D0;">animals</span><span>: </span><span style="color: #ECEFF4;">[</span><span>Animal</span><span style="color: #ECEFF4;">]) {</span></span>
<span class="giallo-l"><span style="color: #81A1C1;"> self</span><span>.animals</span><span style="color: #81A1C1;"> =</span><span> animals</span></span>
<span class="giallo-l"><span style="color: #ECEFF4;"> }</span></span>
<span class="giallo-l"><span> </span></span>
<span class="giallo-l"><span style="color: #81A1C1;"> public func</span><span style="color: #88C0D0;"> feedAnimals</span><span style="color: #ECEFF4;">()</span><span style="color: #81A1C1;"> -></span><span style="color: #ECEFF4;"> [</span><span style="color: #8FBCBB;">String</span><span style="color: #ECEFF4;">] {</span></span>
<span class="giallo-l"><span style="color: #81A1C1;"> return</span><span> animals.</span><span style="color: #88C0D0;">map</span><span style="color: #ECEFF4;"> {</span><span style="color: #81A1C1;"> $0</span><span>.</span><span style="color: #88C0D0;">feed</span><span style="color: #ECEFF4;">() }</span></span>
<span class="giallo-l"><span style="color: #ECEFF4;"> }</span></span>
<span class="giallo-l"><span> </span></span>
<span class="giallo-l"><span style="color: #ECEFF4;">}</span></span></code></pre>
<p>The Farm houses a bunch of generic animals, <code>Animal</code> is just a protocol for our dependencies - the actual farm animals. Here's the protocol itself:</p>
<pre class="giallo" style="color: #D8DEE9; background-color: #2E3440;"><code data-lang="swift"><span class="giallo-l"><span style="color: #81A1C1;">public protocol</span><span> Animal</span><span style="color: #ECEFF4;"> {</span></span>
<span class="giallo-l"><span> </span></span>
<span class="giallo-l"><span style="color: #81A1C1;"> func</span><span style="color: #88C0D0;"> feed</span><span style="color: #ECEFF4;">()</span><span style="color: #81A1C1;"> -></span><span style="color: #8FBCBB;"> String</span></span>
<span class="giallo-l"><span> </span></span>
<span class="giallo-l"><span style="color: #ECEFF4;">}</span></span></code></pre>
<p>Now let's add some concrete implementations of this protocol that we'll use in our production app:</p>
<pre class="giallo" style="color: #D8DEE9; background-color: #2E3440;"><code data-lang="swift"><span class="giallo-l"><span style="color: #81A1C1;">public struct</span><span> Cow</span><span style="color: #ECEFF4;">:</span><span style="color: #8FBCBB;font-weight: bold;"> Animal</span><span style="color: #ECEFF4;"> {</span></span>
<span class="giallo-l"><span> </span></span>
<span class="giallo-l"><span style="color: #81A1C1;"> public func</span><span style="color: #88C0D0;"> feed</span><span style="color: #ECEFF4;">()</span><span style="color: #81A1C1;"> -></span><span style="color: #8FBCBB;"> String</span><span style="color: #ECEFF4;"> {</span></span>
<span class="giallo-l"><span style="color: #81A1C1;"> return</span><span style="color: #ECEFF4;"> "</span><span style="color: #A3BE8C;">Moooo!</span><span style="color: #ECEFF4;">"</span></span>
<span class="giallo-l"><span style="color: #ECEFF4;"> }</span></span>
<span class="giallo-l"><span> </span></span>
<span class="giallo-l"><span style="color: #ECEFF4;">}</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span style="color: #81A1C1;">public class</span><span style="color: #8FBCBB;"> Duck</span><span style="color: #ECEFF4;">:</span><span style="color: #8FBCBB;font-weight: bold;"> Animal</span><span style="color: #ECEFF4;"> {</span></span>
<span class="giallo-l"><span> </span></span>
<span class="giallo-l"><span style="color: #81A1C1;"> public func</span><span style="color: #88C0D0;"> feed</span><span style="color: #ECEFF4;">()</span><span style="color: #81A1C1;"> -></span><span style="color: #8FBCBB;"> String</span><span style="color: #ECEFF4;"> {</span></span>
<span class="giallo-l"><span style="color: #81A1C1;"> return</span><span style="color: #ECEFF4;"> "</span><span style="color: #A3BE8C;">Quack!</span><span style="color: #ECEFF4;">"</span></span>
<span class="giallo-l"><span style="color: #ECEFF4;"> }</span></span>
<span class="giallo-l"><span> </span></span>
<span class="giallo-l"><span style="color: #ECEFF4;">}</span></span></code></pre>
<p>We ended up with a fully testable <code>Farm</code> type which we can use in our application by passing the right set of dependencies:</p>
<pre class="giallo" style="color: #D8DEE9; background-color: #2E3440;"><code data-lang="swift"><span class="giallo-l"><span style="color: #88C0D0;">Farm</span><span style="color: #ECEFF4;">(</span><span style="color: #88C0D0;">animals</span><span style="color: #ECEFF4;">:</span><span> [</span><span style="color: #88C0D0;">Cow</span><span style="color: #ECEFF4;">()</span><span>, </span><span style="color: #88C0D0;">Duck</span><span style="color: #ECEFF4;">()</span><span>]</span><span style="color: #ECEFF4;">)</span><span>)</span></span></code></pre>
<p>But <em>DI</em> isn't really <em>DI</em> unless you don't have to care about what you're passing to the constructor in your actual use case.</p>
<p>This is where class extensions come in. With Swift we can extend <em>classes</em> with convenience initializers and <em>structs</em> with just regular initializers wherever we like! So to do that create a separate swift file to house your DI initializers (you need to keep this in a different file to include it in your application and exclude it form your testing target, so you don't include the whole dependency tree for the type you're testing). In this file we would have:</p>
<pre class="giallo" style="color: #D8DEE9; background-color: #2E3440;"><code data-lang="swift"><span class="giallo-l"><span style="color: #81A1C1;">extension</span><span> Farm</span><span style="color: #ECEFF4;"> {</span></span>
<span class="giallo-l"><span> </span></span>
<span class="giallo-l"><span style="color: #81A1C1;"> init</span><span style="color: #ECEFF4;">() {</span></span>
<span class="giallo-l"><span style="color: #81A1C1;"> self</span><span>.</span><span style="color: #81A1C1;">init</span><span style="color: #ECEFF4;">(</span><span style="color: #88C0D0;">animals</span><span style="color: #ECEFF4;">:</span><span> [</span><span style="color: #88C0D0;">Cow</span><span style="color: #ECEFF4;">()</span><span>, </span><span style="color: #88C0D0;">Duck</span><span style="color: #ECEFF4;">()</span><span>]</span><span style="color: #ECEFF4;">)</span></span>
<span class="giallo-l"><span style="color: #ECEFF4;"> }</span></span>
<span class="giallo-l"><span> </span></span>
<span class="giallo-l"><span style="color: #ECEFF4;">}</span></span></code></pre>
<p>Since this is a swift extension, we can have whatever we want here, even returning a singleton instance of the interface you want to use. To put it simply: you're only limited by Swift itself when it comes to deciding how you want your dependencies executed and your dependency tree handled. For the sake of this example I chose to use the most simple case.</p>
<h1 id="on-to-the-tests">On to the Tests!<a class="zola-anchor" href="#on-to-the-tests" aria-label="Anchor link for: on-to-the-tests">§</a>
</h1>
<p>Now we want to unit test the Farm struct. We didn't import the source file that contains conveniences and the dependency tree, so we don't have to import types for <code>Cow</code> and <code>Duck</code>. Instead let's create a new mock type for our <code>Animal</code> protocol and execute the test with that:</p>
<pre class="giallo" style="color: #D8DEE9; background-color: #2E3440;"><code data-lang="swift"><span class="giallo-l"><span style="color: #81A1C1;">struct</span><span> TestAnimal</span><span style="color: #ECEFF4;">:</span><span style="color: #8FBCBB;font-weight: bold;"> Animal</span><span style="color: #ECEFF4;"> {</span></span>
<span class="giallo-l"><span> </span></span>
<span class="giallo-l"><span style="color: #81A1C1;"> func</span><span style="color: #88C0D0;"> feed</span><span style="color: #ECEFF4;">()</span><span style="color: #81A1C1;"> -></span><span style="color: #8FBCBB;"> String</span><span style="color: #ECEFF4;"> {</span></span>
<span class="giallo-l"><span style="color: #81A1C1;"> return</span><span style="color: #ECEFF4;"> "</span><span style="color: #A3BE8C;">This isn't an actual animal, it's just a test</span><span style="color: #ECEFF4;">"</span></span>
<span class="giallo-l"><span style="color: #ECEFF4;"> }</span></span>
<span class="giallo-l"><span> </span></span>
<span class="giallo-l"><span style="color: #ECEFF4;">}</span></span>
<span class="giallo-l"></span>
<span class="giallo-l"><span style="color: #81A1C1;">class</span><span style="color: #8FBCBB;"> InjectTests</span><span style="color: #ECEFF4;">:</span><span style="color: #8FBCBB;font-weight: bold;"> XCTestCase</span><span style="color: #ECEFF4;"> {</span></span>
<span class="giallo-l"><span> </span></span>
<span class="giallo-l"><span style="color: #81A1C1;"> func</span><span style="color: #88C0D0;"> testFeeding</span><span style="color: #ECEFF4;">() {</span></span>
<span class="giallo-l"><span style="color: #81A1C1;"> let</span><span> farm </span><span style="color: #81A1C1;">=</span><span style="color: #88C0D0;"> Farm</span><span style="color: #ECEFF4;">(</span><span style="color: #88C0D0;">animals</span><span style="color: #ECEFF4;">:</span><span> [</span><span style="color: #88C0D0;">TestAnimal</span><span style="color: #ECEFF4;">()</span><span>]</span><span style="color: #ECEFF4;">)</span></span>
<span class="giallo-l"><span style="color: #81A1C1;"> let</span><span> result </span><span style="color: #81A1C1;">=</span><span> farm.</span><span style="color: #88C0D0;">feedAnimals</span><span style="color: #ECEFF4;">()</span></span>
<span class="giallo-l"><span> </span></span>
<span class="giallo-l"><span style="color: #88C0D0;"> XCTAssertEqual</span><span style="color: #ECEFF4;">(</span><span>result, [</span><span style="color: #ECEFF4;">"</span><span style="color: #A3BE8C;">This is not an actual animal, it's just a test</span><span style="color: #ECEFF4;">"</span><span>]</span><span style="color: #ECEFF4;">)</span></span>
<span class="giallo-l"><span style="color: #ECEFF4;"> }</span></span>
<span class="giallo-l"><span> </span></span>
<span class="giallo-l"><span style="color: #ECEFF4;">}</span></span></code></pre>
<p>And here you go, a fully contained and convenient dependency injection method, that works without the need of any framework, objective-c code, var's (instead of lets) or dynamism (instead of static dispatch).</p>
<h1 id="project-source">Project Source<a class="zola-anchor" href="#project-source" aria-label="Anchor link for: project-source">§</a>
</h1>
<p><del>I've made a simple iOS project as a proof of concept for this: download</del> the project is out of date and no longer hosted</p>
Linking OpenSSL for the iOS Simulator (1.0.2a)2015-04-26T13:56:00+00:002015-04-26T13:56:00+00:00
Unknown
https://karstx.net/ios-openssl-support/<h1 id="intro">Intro<a class="zola-anchor" href="#intro" aria-label="Anchor link for: intro">§</a>
</h1>
<p>I've been doing some work with a fair amount of crypto for an my upcoming application. Now as you all probably know, the go-to for doing any crypto is with <a rel="external" href="https://www.openssl.org/">OpenSSL</a>. I'm not much of a hipster, so I immediately went with that.</p>
<h1 id="the-good">The Good<a class="zola-anchor" href="#the-good" aria-label="Anchor link for: the-good">§</a>
</h1>
<p><a rel="external" href="https://twitter.com/x2on">x2on</a>'s <a rel="external" href="https://github.com/x2on/OpenSSL-for-iPhone">OpenSSL-for-iPhone</a> is an excellent tool of convenience. It downloads the latest version of OpenSSL, builds both libssl and libcrypto for all available architectures and glues all slices into one universal library each. It even comes with a script to generate <code>openssl.framework</code> from the resulting libraries.</p>
<h1 id="the-bad">The Bad<a class="zola-anchor" href="#the-bad" aria-label="Anchor link for: the-bad">§</a>
</h1>
<p>The resulting framework runs great on any device, sadly, the linker just didn't want to link for the simulator. The linker spewing:</p>
<pre class="giallo" style="color: #D8DEE9; background-color: #2E3440;"><code data-lang="plain"><span class="giallo-l"><span>Undefined symbols for architecture x86_64:</span></span>
<span class="giallo-l"><span> "_OPENSSL_ia32cap_P", referenced from:</span></span>
<span class="giallo-l"><span> _AES_cbc_encrypt in openssl(aes-x86_64.o)</span></span>
<span class="giallo-l"><span>ld: symbol(s) not found for architecture x86_64</span></span>
<span class="giallo-l"><span>clang: error: linker command failed with exit code 1 (use -v to see invocation)</span></span></code></pre>
<p>I was at a complete loss, as I hadn't referenced anything of the like. In my code at least. But a bit more digging revealed the culprit.</p>
<h1 id="and-the-de-uglyfied">And the de-uglyfied<a class="zola-anchor" href="#and-the-de-uglyfied" aria-label="Anchor link for: and-the-de-uglyfied">§</a>
</h1>
<p>It turns out this is a bug in the generated code for x86_84. The linker doesn't know that the <a rel="external" href="https://github.com/openssl/openssl/blob/e0fc7961c4fbd27577fb519d9aea2dc788742715/crypto/aes/asm/aes-x86_64.pl#L1651">_OPENSSL_ia32cap_P</a> external symbol needs to be linked in from <a rel="external" href="https://github.com/openssl/openssl/blob/e0fc7961c4fbd27577fb519d9aea2dc788742715/crypto/x86_64cpuid.pl#L26">x86_64cpuid.o</a>.</p>
<p>We can force this by referencing another method that's in <code>x86_64cpuid.o</code>, like <code>OPENSSL_cleanse(void *, size_t)</code>. I did like so:</p>
<pre class="giallo" style="color: #D8DEE9; background-color: #2E3440;"><code data-lang="plain"><span class="giallo-l"><span>#if TARGET_IPHONE_SIMULATOR</span></span>
<span class="giallo-l"><span> // this is just so openssl links properly.</span></span>
<span class="giallo-l"><span> extern int OPENSSL_cleanse(void *ptr, size_t len);</span></span>
<span class="giallo-l"><span> OPENSSL_cleanse(nil, 0);</span></span>
<span class="giallo-l"><span>#endif</span></span></code></pre>
<p>Pasting the following anywhere in your code (that won't be discarded by compiler optimizations) should work.</p>
<h1 id="the-end">The End?<a class="zola-anchor" href="#the-end" aria-label="Anchor link for: the-end">§</a>
</h1>
<p>I'm hoping that this will get resolved in the future. If not as a mainline release, then at least as a publicly available patch. But until then, I guess we're stuck with this.</p>