Arm: GPU Build Team

Overview

In summer 2026 I joined the GPU Build team at Arm. The team works on Ragnarök, a project with the goal to move Arm’s GPU software away from its legacy build infrastructure and onto more scalable tooling, namely Bazel for builds and GitLab for source control and CI.

Why Bazel: Hermeticity

Bazel is a build system with a strong focus on hermeticity. A hermetic build is sealed off from the machine it runs on: it only uses inputs it has explicitly declared, such as pinned source code, tools and compilers, and never whatever happens to be installed on the host. The same inputs always produce the same outputs, on a laptop or a CI runner.

That makes builds reproducible and safe to cache. Bazel can reuse results across machines and only rebuild what actually changed, which matters at the scale of a GPU software stack. In practice, it means every tool a build needs is provided through a Bazel toolchain rather than assumed to be on the system.

What I Built

I owned three open-source Bazel rulesets, published under the MIT licence on Arm’s GitLab, that together cover the steps of building an operating-system image:

1. 01 rules_mkfs Files → filesystem image (ext4)
2. 02 rules_uboot Kernel or ramdisk → U-Boot image
3. 03 rules_disk Partitions → GPT disk image

rules_mkfs

Rules for creating filesystem images. mkfs_file turns a tarball of files into a labelled ext4 image, with the filesystem tools provided through Bazel toolchains. I wrote most of the ruleset: I added support for Bazel 9’s dependency resolution, set up GitLab CI, and wrote end-to-end tests that inspect the generated images with e2fsprogs tools such as debugfs, dumpe2fs and e2label.

rules_disk

Rules for assembling partitions into GPT disk images with partition_info and gpt_disk_image. I built the sgdisk toolchain: a host fallback for development, and a hermetic option that downloads a pinned, checksum-verified static binary. I also wrote an end-to-end test suite in Go that extracts each partition from the generated disk and verifies its contents, covering named, mixed, multi-partition and raw-payload layouts, and I removed redundant tool usage from the image-building step.

rules_uboot

Rules for creating U-Boot images with mkimage, the format bootloaders use to load kernels and ramdisks. I created the repository and its foundations, including the project layout, licensing, pre-commit hooks and CI. My colleague Jonathan Watson then made mkimage fully hermetic by building it from pinned U-Boot sources.

Shared Foundations

• Consistent setup: all three repositories share the same project layout, MIT licensing, CODEOWNERS and pre-commit hooks, so they are easy to maintain together.
• CI on GitLab: every change is built and tested through Arm’s shared Bazel CI component, which I kept up to date as it evolved.
• Keeping tests hermetic: tests that still depend on host tools are kept out of wildcard runs, so the default test suite stays hermetic.
• Release registry: pre-release versions are published to GitLab releases, so other teams can depend on them before they reach the Bazel Central Registry.