nought Networked Orchestrated Unit for Generic Hardware Testing early access · in development

The most expensive bug is the one your customer finds.

Nought runs your firmware tests automatically on real hardware before release. Failures surface on the bench—not in the field—and the workflow no longer depends on the one person who knows how to run it.

A clean bench every run. Less manual verification. Fewer field failures.

clean state, every run first green in days, not months no framework · no kubernetes works with your existing CI
The problem, documented in public U-Boot CI ↗ GitHub runners ↗ Linaro LAVA ↗
01 Why it matters

Release with confidence—not a hope that the bench was right.

A green check matters only when it supports a release decision. Nought starts each run from a known state, so your team can reproduce failures and release with confidence—not guesswork.

Field failure

Catch defects before customers do

A test you cannot trust becomes a field failure. Real-hardware tests find it before release, where it is cheaper to fix.

ref ↗ The Milbank Quarterly · FDA data
Key-person risk

Your bench should not depend on one person

Replace one person’s setup and know-how with a workflow the whole team can run the same way.

Trustworthy result

A green check you can trust

A passing result reflects your firmware and tests—not whatever state the bench was in that day.

The origin

Built because we needed it.

After 20+ years in software and embedded development, I kept seeing the same gap: software is automated; real-hardware tests remain bespoke and manual.

At ADNT, Crispy made that gap concrete. We needed every change tested on real hardware, on a bench our CI could reserve, start clean and reset automatically.

So we built Nought.

Today, it runs in ADNT’s development process. Next, we are standardising it for other teams with the same problem.

02 Why it works

Reliable hardware CI, without another platform to maintain.

Persistent runners accumulate old workspaces, leftover files and cached credentials. GitHub recommends replacing them after each job.

ref ↗ docs.github.com

It affects mature labs too: U-Boot CI recently hit a flaky bench and a stale build artefact. Neither was a source-code bug.

ref ↗ concept.u-boot.org · MR 967

Existing lab frameworks provide hardware access, not a clean host—and often take weeks to deploy.

ref ↗ docs.lavasoftware.org

Real hardware. A known state. Reproducible results.

Nought is a complete hardware-in-the-loop (HIL) test bench. It orchestrates diskless test machines wired to your embedded system. Your CI reserves one through a simple API; each run power-cycles the target and starts from a clean environment. Engineers connect over SSH and keep using their usual tools.

nought nought nought nought 01 CI 02 CONTROLLER 03 BENCH + DUT 04 RESULTS
[ 0.000000] nought: lease acquired by ci runner #4812 [ 0.418311] booting from ram — no disk attached [ 2.771540] dut: power cycle — rail A off → on, cold start [ 2.933012] dut: usb-serial ttyUSB0 @ 115200 · link up [ 3.099862] provision: reference image written, readback verified state: CLEAN — bench ready

Diskless boot.

No disk means no accumulated state. Every reboot starts clean.

Full power cycle.

Every run cold-starts the target, clearing RAM and peripheral state.

Verified reference image.

Nought verifies the image before the run, so you test the firmware you expect.

03 How you use it

Keep your tools. Let the bench run itself.

NOUGHT BENCH LEASE API SSH POWER-CYCLE POWER USB·SERIAL SWD your CI github · gitlab · jenkins controller lease · netboot · power nought machine diskless · runs in ram your embedded system dut

Run Nought in your lab or let us host your connected hardware. Your developers get the same reproducible environment either way.

LEASE POWER-CYCLE boots clean · ram COLD START SSH · TESTS VERDICT ERASE · SWD POWER OFF state dissolves your CI controller nought machine your embedded system
  1. 01Your pipeline requests a bench
  2. 02The controller power-cycles a diskless machine, which boots clean from the network and cold-starts your embedded system
  3. 03Your tests run over SSH, signals and consoles captured
  4. 04The result returns; the target is erased over SWD and the machine resets for the next job

Already have a CI?

Use GitHub, GitLab, Jenkins or your own tooling to reserve a bench, run tests and collect results. Your pipeline stays in charge.

Haven't automated your tests yet?

Start with the scripts you already use, then automate step by step. No CI transformation required.

See what your firmware does on the wire

An optional analysis head decodes UART, I²C and SPI, checks GPIO timing, and reports pass or fail to your pipeline.

USB USB USB·SERIAL SIGNALS SWD nought machine raspberry pi digital probe uart · i²c · spi · gpio swd probe flash · erase · debug your embedded system dut
in service

In service on Crispy.

Two benches run the hardware CI of Crispy, our open-source A/B bootloader: boards, pipeline and control portal.

The first test bench: a Raspberry Pi with its PoE hat on a black mount, next to a plate holding the RP2040 target and its SWD debug probe
The first bench: a Nought machine on its PoE mount, the RP2040 target and its SWD probe on the plate.
A green CI run on the bench: the pipeline leases a bench, builds the firmware, flashes it over SWD, runs protocol tests on the target and releases the lease
From lease to release in one pipeline: firmware built, flashed over SWD, protocol tests on the target, then the bench frees itself for the next job.
The control portal: one bench ready with SSH up and its boot trace, one bench free, and an SSH console opened with the boot's ephemeral key
Every bench at a glance: state, boot trace, and a console opened with the key generated at each boot.
On the roadmap: every run will bind what matters (firmware hash, device serial, test-suite version, result), evidence you can hand to an audit (CRA, IEC 62304) instead of a screenshot.
design partners

We built it for our bench. Now we want to test it against yours.

Nought already runs our hardware CI. Before we finalise it, we want to validate it with teams using different boards and workflows.

Show us your target and constraints. Help build the Nought you would deploy.

Design-partner access is free and selective. We read every application and reply personally.

Florian Mahon
Who's behind Nought Florian Mahon — Founder · 20+ years across IT, software & firmware engineering.

Software engineer (HES) with 20+ years of experience. I started in IT (managing client fleets and servers), then specialised in desktop and firmware development for real-time environments (FPGA, EtherCAT, and more), before leading an 8-person software R&D department.

Nought is the test bench I kept wishing I had, all those years.

Email ↗ LinkedIn ↗
commitment

Early access

The bench already runs our own hardware CI. What we're defining now is the public product: this phase collects the concerns and needs of embedded teams, then we'll publish a roadmap listing the features that will be implemented. Early-access users help shape it.

timeline — from your needs to the roadmap
launch roadmap published development starts first batch Sep 2026 Nov 2026 Jan 2027 for early-access users sign-ups gathering · 2 months consolidation early-access influence development
one-time paymentlimited batch

CHF 1 000

Early access · deducted from your first bench
✓ 100% refundable

Your email first, so we can reach you about your access and any refund. Payment follows on SumUp.

Payment secured by SumUp.

Fully refunded if we don't ship. No questions asked.

  • Be first on the hardware batch.
  • Your CHF 1 000 are deducted from the price of your first bench.
  • Get a direct line into the roadmap.
  • No budget risk: the deposit is fully refunded if Nought never ships.
questions

FAQ

Why not Jumpstarter or labgrid?+

They solve remote access to hardware, and they do it well. What they don't do is make the test host itself disposable. Nought does. Think of it as an extension of your CI, not a replacement for your tools.

How is it different from Lager or BenchCI?+

They wrap your bench and ship your tests to it. Nought does one thing: it makes the test host itself ephemeral, so reproducibility comes from the machine, not from how carefully someone wrote the teardown script. Run it next to them, or on its own.

How long until my first green pipeline?+

If your test scripts already exist: a few days. Wire your target, point your CI at the lease API, run. No lab to build, no Kubernetes, no IT project. Framework-based labs quote weeks to months per embedded system.

Does it need Kubernetes?+

No.

What hardware does it run on?+

Standard Raspberry Pi plus off-the-shelf probes. No proprietary boards.

How much will a bench cost?+

The final price isn't announced yet. Early-access users pay a CHF 1 000 deposit, deducted from the price of their first bench and fully refunded if Nought never ships.

What stage is the product at?+

The bench is in service: it runs our own hardware CI on Crispy. What we're defining now is the public product. This phase is about collecting the concerns and needs of embedded teams; we'll then publish a roadmap listing the features that will be implemented. Design partners and early-access users shape it directly.

When does it ship?+

It's in development. Early-access users get the first batch and set the priorities.

What if it never ships?+

Full refund, no questions asked.

Results your team can trust.

Choose the level of involvement that fits your team: help validate the product, reserve a place in the first batch, or simply follow its progress.

  • Design partner : I have this problem and want to help define the product.
  • Early access, CHF 1 000 : reserve a place in the first batch; your refundable deposit is deducted from your first bench.
  • Waitlist : interested, keep me posted.