Take a photo of a computer. Get back a fully custom Linux system — hardware identified, every device mapped, a complete validated build, and a desktop that already knows what it's running on the moment you log in. No board notes, no digging through datasheets, no hand-assembling BitBake layers. With img2linux, its easy as shoot n boot.
How it works:
• See it: A photo runs through a component-detection pipeline that locates the SoC, RAM, connectors, M.2 slots, and add-on cards, then OCRs the actual part numbers and board names printed on the silkscreen. That's the real identification signal — visual shape alone isn't trustworthy for chips that look alike — so every guess gets confirmed against a hardware database and, once the board boots, against what the board itself reports.
• Map it: Once the base board is known, img2linux pulls the real device tree source for it - the same file the kernel uses to understand its own buses, addresses, and pins - and folds every other piece of detected hardware into that map as an overlay. An Axelera Metis card, a camera, an NVMe drive: all of it becomes one structured picture of the whole machine, rendered as an interactive block diagram.
• Cook it: With the hardware side settled, img2linux searches the Yocto/OpenEmbedded ecosystem — plus Axelera's own meta-axelera layer and BSP releases - for the board support package and machine definition that fits, folds in the kernel version and OS features requested, and assembles the full BitBake build.
• Prove it: Before it spends an hour on a real build, img2linux parse-checks the recipe, runs static compatibility checks over the whole device map, and boot-tests it in a virtual machine. If anything fails, it redesigns the recipe and tries again - automatically - until the virtual boot passes clean.
• Build it: Once it passes, img2linux kicks off the real build and hands over a finished image, ready to flash.
• Show it: Every image it builds ships with one more thing: a desktop that renders the exact block diagram it built for that machine, with every device as a live tile - temperature, clock speed, memory, utilization - updating itself the instant something changes, no polling. Where the hardware allows it, settings can be edited right from the desktop, safely, because the same compatibility rules that built the recipe are the ones gating what's allowed to change.
With img2linux, you photograph a computer, get a bespoke, working Linux distribution back, complete with a desktop that already understands its own hardware - needs zero technical explanation to land. Non-experts get it instantly. And underneath the "wow," every stage is real, deterministic engineering: known device trees, indexed BSPs, a database that won't let the model guess its way into an incompatible build, and a validation loop that only ships what's provably going to work.
It's also a genuinely live, on-Metis demo in two places, not just a batch job: the photo-to-hardware-ID stage is a real vision pipeline running on the Metis card, and the desktop dashboard reads live telemetry: clocks, temperature, utilization - straight off the Metis card through its own device APIs while it's running.
What we're not claiming:
img2linux doesn't invent board support for hardware nobody's ever built a BSP for - bootloader and DDR bring-up for genuinely new silicon isn't something that can be responsibly automated from a datasheet. If a photographed board has no indexed BSP, img2linux says so plainly instead of guessing. It's a generator built on real, existing embedded-Linux infrastructure - not a silicon bring-up wizard.
*img2linux will only use free and publicly available software.
＄ＴＨＥ ＰＲＯＭＰＴ＄
Ok Wingman, ive got a *special* objective today and i need YOUR help. Lets build a system that takes a photo (or description) of a piece of hardware and produces a validated, ready-to-boot custom Linux image for it, and even includes a live desktop canvas that displays and lets you edit the hardware it's running on. Build it in these stages:
1. Hardware ID (vision). Take a photo or video showing all components of a target system. Run a component-detection pipeline (a fine-tuned YOLO-family model) over the image to locate the SoC package, RAM, connectors, M.2 slots, PMICs, camera modules, and any add-ons. Run OCR over each detected region to read board names, revisions, and IC part numbers off the silkscreen and package markings - and treat this as the real identification signal, since visual appearance alone is unreliable for SoC packages that might look alike. Look up the OCR identifiers and compare against a hardware knowledge database, falling back to web/datasheet lookup for anything not already indexed. Surface the result as a candidate identification for me to confirm, and once the board is actually running, cross-check it against live probing (lspci, device tree, /proc/cpuinfo)
2. Device tree resolution. Once the base board is identified, pull its authoritative device tree source (DTS) from its BSP rather than inferring one from photos or datasheets - the DTS is the real machine map: buses, peripheral base addresses, interrupts, clocks, pinmux. Parse it into a graph model of the base machine.
3. Full-system composition. Add every other piece of hardware detected in the photo - including an Axelera Metis card, cameras, storage, or other accessories - into that graph as device tree overlays, so the graph represents the complete system as built, not just the base board.
4. Block diagram. Render the completed machine graph as an interactive block diagram of the whole system: every device, its connections, and where it sits in the machine. This will serve as the absolute identity from which all the following steps build upon.
5. BSP and recipe resolution. Search the OpenEmbedded Layer Index plus Axelera-specific sources (meta-axelera, Metis Compute Board BSP release notes, supported kernel versions, Voyager SDK runtime dependencies) for the BSP and MACHINE definition matching the identified hardware, preferring Yocto layers wherever one exists. Only generate a configuration for hardware with a known, indexed BSP layer — if nothing matches, tell me clearly rather than attempting to invent bootloader or DDR-init support from datasheets alone.
6. Kernel and distro assembly. Using the user-specified kernel version and desired distro features, resolve the full set of recipes and companion layers needed, confirming every layer's compatible Yocto release agrees with the others as a deterministic database check, not a guess. Assemble the complete BitBake configuration — machine, distro, layers including meta-axelera, and the DISTRO_FEATURES/IMAGE_INSTALL lines - as a kas YAML.
7. Virtualized validation loop. Before any real build, validate the whole recipe virtually: parse-check the generated config (bitbake -p / bitbake -n), run static checks over the device tree graph for bus conflicts, address overlaps, pinmux collisions, and power budget, and boot-test the result in QEMU where a machine model exists. If anything fails, revise the recipe and re-test until the virtual path passes clean. Tell me plainly that Metis-specific and other vendor peripherals still need hardware-in-the-loop confirmation once the board is in hand — don't claim the virtual pass covers that.
8. Build. Once validated, run the real build and hand me the finished artifact — a bootable image or ISO for the target device.
9. A living desktop. Every image you produce should include one more recipe: a desktop canvas that renders the block diagram from step 4, with each device as a live widget. Build this as a small event-driven system service that owns the machine graph and subscribes to the hardware's own event sources - udev/netlink hotplug events, sysfs attribute changes, D-Bus signals already broadcast by things like UPower and NetworkManager - instead of polling, with a lazy-refresh fallback only for the few attributes that don't emit change events. Widgets should be pure clients of that service's D-Bus API, with zero direct hardware access. Where a device supports it - including the Metis card, through its axdevice and tracer interfaces for clocks, temperature, memory, and MVM utilization - let the widget edit the setting directly, but gate every write behind the same compatibility checks used to build the recipe, so nothing lets me set a value the hardware doesn't actually support, and journal changes so the service can tell desired state from actual state after a reboot. Render it as one full-canvas application rather than separate floating widgets, so it works consistently across desktop environments and on the target board's own display output.
Walk me through each stage as you build it, and ask me directly if anything about the target hardware or desired features is ambiguous before generating the recipe.
