From a Linux fault to a verified fix.

Follow a complete engineering workflow across the Linux shell, VS Code, GitHub and real hardware. KERNARY keeps the code change, validation results and release decision connected.

Tools connected by KERNARY

$

Linux shellGit, BitBake, systemd, can-utils and i2c-tools

⌁

VS CodeSource, tasks, diffs and the integrated terminal

GH

GitHubPull requests, Actions checks and review gates

◇

KERNARYOrchestration, validation and evidence interfaces

Interactive demos

Three jobs. One continuous evidence trail.

Select a scenario or let it play. Each stage updates the editor, Linux terminal and pull request together.

Guided walkthrough

Repair CAN bring-up on a custom i.MX93 carrier.

Inspect the real Linux source tree, patch device-tree pinmux in VS Code, build with BitBake, validate CAN on a physical fixture and open an evidence-backed pull request.

00:08 / 00:32
Trace the failing interface

Search the source tree and correlate the boot log with the board revision.

FileEditSelectionViewGoRunTerminalHelp
orbit-controller-demo — Visual Studio CodeSSH: build-cell-317
imx93-orbit-controller.dts ×kernary.yaml ×
meta-orbit › recipes-kernel › linux › files › imx93-orbit-controller.dts
118 &flexcan1 {
119 pinctrl-names = "default";
120- pinctrl-0 = <&pinctrl_flexcan1>;
122 };
123
124 &iomuxc {
TERMINALOUTPUTPROBLEMS 0bash · build-cell-317 +⌄

orbit@build-cell-317 ~/workspace/orbit-controller-demo

$git switch -c fix/can1-pinmux

$rg -n "flexcan1" arch/arm64/boot/dts/freescale

!can0: interface remains DOWN after boot

⑂ fix/can1-pinmux↻ 0 errorsUTF-8Linux / arm64Build cell: active
Type / to search+○◉
◇kernary-labs/orbit-controller-demoExample repository

Pull request #1842

Trace the failing interface

Draft fix/can1-pinmux into main

KE

kernary-engineer[bot]opened this change · human review required

0 of 5 checks complete

↻

Source policydiff + binding validation

Running
○

Yocto buildbuild #2387 · manifest

Waiting
○

QEMU smoke42 checks passed

Waiting
○

HIL / CAN loopbackboard rev B · 18/18

Waiting
○

Human release gateapproval required

Waiting

◇KERNARY evidence bundle18 / 18 HIL assertions passed · boot target 4.8s

build #2387test #9183source diff
⚿

Human release gateAgent cannot merge or sign this release

Linux and Git KERNARY workflow Evidence attached18 / 18 HIL assertions passed · boot target 4.8s

Engineering use cases

Built around engineering outcomes.

The demos connect the KERNARY product line to work an embedded team already recognises.

01Embedded Linux developer

Repair CAN bring-up on a custom i.MX93 carrier.

Inspect the real Linux source tree, patch device-tree pinmux in VS Code, build with BitBake, validate CAN on a physical fixture and open an evidence-backed pull request.

Outcome18 / 18 HIL assertions passed · boot target 4.8s
02BSP and driver engineer

Enable and verify a BME280 sensor on I²C.

Confirm the bus and address with standard Linux tools, add the device-tree node, load the upstream driver and preserve the observed measurement as evidence.

OutcomeDriver bound · temperature and pressure channels visible
03Platform reliability engineer

Reproduce a field boot regression and contain rollout risk.

Move from a fleet alert to a reproducible board-lab failure, use Git bisect and system logs to isolate the change, then send a guarded fix through CI.

OutcomeRegression isolated · canary rollout remains paused

Developer integrations

Start where engineers already work.

These examples use familiar VS Code tasks and GitHub Actions workflows alongside the KERNARY developer experience.

⌁

VS Code / task runner

Keep the real build one command away.

A workspace task launches the native Yocto command from the repository root. The editor is the control surface; Linux remains the execution environment.

.vscode/tasks.json
{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "KERNARY demo: Yocto build",
      "type": "shell",
      "command": "source oe-init-build-env build && bitbake kernary-image-production",
      "options": { "cwd": "${workspaceFolder}" },
      "problemMatcher": [],
      "group": { "kind": "build", "isDefault": true }
    }
  ]
}
GH

GitHub / pull request checks

Return proof to the change that produced it.

A self-hosted runner builds with native tooling. KERNARY then requests physical validation and associates evidence with the pull request.

.github/workflows/embedded-evidence.yml
name: Embedded evidence demo

on:
  pull_request:

jobs:
  build-and-test:
    runs-on: [self-hosted, linux, x64, yocto]
    steps:
      - uses: actions/checkout@v6
      - name: Build image
        shell: bash
        run: |
          source oe-init-build-env build
          bitbake kernary-image-production
      - name: Request physical validation
        run: |
          # KERNARY product preview; not publicly available.
          kernary test run --suite can-and-boot --evidence github

Plan your next release

Reduce integration risk before your product reaches the field.

KERNARY connects source changes, repeatable builds and real-hardware validation so teams can find issues earlier, make release decisions with evidence and avoid late-stage rework.