AVAILABLE FOR DEVICE-ENABLEMENT, BSP & KERNEL WORK — WORLDWIDE
Device enablement, BSP & kernel porting — done by someone who’s bricked a few and recovered them all.
I’m a freelance low-level Linux developer. If you have hardware — a phone, a tablet, an SBC, a niche embedded board, an old console — and you need Linux (or a modern Linux userland) running on it properly, that’s my job. I do the layer that makes everything above it possible: kernel bring-up and device trees, board-support packages, Halium/libhybris Android-HAL enablement, graphics/compositor plumbing, and the boot chain. I work in the open, contribute upstream where it’s the right call, and I’d rather tell you a problem is hard than hand you a demo that falls over the moment a real user touches it.
01
What I do
Seven things, end to end — the unglamorous layer below the login screen.
01
Kernel bring-up & device trees
Get a board booting Linux: vendor/downstream kernel bring-up, device tree authoring and fixing (display, touch, USB, power, boot delays), backporting features onto frozen vendor kernels, defconfig and GKI/clang builds, UART/serial recovery.
02
Board-support packages (BSP)
A maintainable BSP around your SoC and board — kernel, firmware, bootloader integration, packaging (Fedora RPM/COPR or Debian/APT), and a reproducible image/build pipeline.
03
Ubuntu Touch / Halium device ports
Full UBports/Ubuntu Touch ports on Halium + libhybris for Android phones and tablets (MediaTek & Qualcomm), including the awkward cases — foldables, tablets, multi-display, sensors and RIL.
04
Graphics & compositor work
Mir / MirAL / Lomiri and Wayland-stack porting and debugging, libhybris EGL/GLES integration, nested-compositor and GPU-sharing problems, hardware video decode/encode (VAAPI, NVDEC).
05
Power & thermal tuning
DVFS / cpufreq power-save and battery-saver work, charge limiting, per-device power profiles benchmarked with stress-ng — making a device actually last a day.
06
Rescue & second opinions
The “it doesn’t boot / it bricks / it’s all-black and nobody knows why” jobs. I’ll diagnose which layer is actually at fault (HAL vs kernel vs shell) before anyone touches the wrong code.
07
AMD ROCm / LLM inference enablement
Standing up and tuning local LLM inference on AMD hardware — llama.cpp and vLLM on Strix Halo (Ryzen AI Max+ 395, ~124 GB unified VRAM) and Radeon 7900 XTX nodes via ROCm/HIP, including multi-node Ray and pipeline-parallel setups.
02
Who I work with
If you recognise yourself here, we’ll probably get on.
Hardware makers shipping a niche Linux or Ubuntu Touch device who need real bring-up, not a slideshow
Companies stuck on a frozen vendor kernel who need features backported safely
Projects that want their device port done upstream-clean and maintainable, not a one-off fork
Communities / OEMs wanting a console, SBC or phone re-enabled for a modern Linux userland
Hardware vendors needing mainline/BSP support for a board or phone
Mobile-Linux projects (Ubuntu Touch / postmarketOS / Halium)
AI/ML teams running AMD ROCm inference clusters
03
How an engagement runs
Open, honest about risk, and shaped to fit the work.
01
Scope
We figure out what “done” means and where the real risk is. I’ll tell you up front if something is genuinely hard.
02
Bring-up
Kernel, device tree, BSP, the boot chain — built in the open, with progress you can actually follow.
03
Harden
Make it correct, not just demo-able: real failure modes chased down, power and stability tuned.
04
Hand off
Upstream-clean and maintainable where it makes sense — a fork you can live with, not one you inherit and fear.
The entity
Azkali Limited
Hong Kong incorporated low-level engineering company — the continuation of the freelance practice I ran in France.
Engagement terms
Fixed-scope projects, retainers, and longer engagements, worldwide. Invoicing in USD or EUR.
OPEN TO NEW PROJECTS
Have hardware that won’t boot the OS you need?
Tell me the device, the SoC, and what “working” looks like to you. I’ll tell you honestly whether it’s a weekend or a quarter — and where the bodies are buried.