The board is part of the CI pipeline for the OS. The kernel is built in the normal CI pipeline, unit tested, etc. then platform-specific images are built.
Those are picked up by GitHub CI runners (could be anything but I'm using GH for now) that pull those image artifacts and send them over the internet to the board, which stores them on the microSD slot.
Then the board will boot the device-under-test (either by enabling a USB VBUS line, asserting PS_ON and pressing the power button, whatever the device needs) and will serve the image either a via USB mass device or by switching on access to the microSD card directly via a ribbon connector/custom microSD PCB and ribbon cable.
The kernel then communicates over serial back to the Link, which proxies that back up to the CI runner for evaluating test runs, etc.
Everything is configured using MQTT and mDNS. Using async Rust via Embassy for the firmware.
5-pin on the bottom left is for power - 5V 2A 'always on' supply (on the ATX24 adapters that's the 5vsb line), 5V 3A aux line (for VBUS, optional and not otherwise used to power the board itself), a sense line for the aux power (board will shut down and display an error on over-current of the main line if not sensed), active-low aux line enable signal (PS_ON for ATX24 sources), and ground.
This means that it's used to cut power on x86 machines, or to use a stock desktop PSU even for arm/riscv dev boards. In the future I want to make this all rack mounted and have a dedicated power supply for multiples of these.
alt Hacker News
The board is part of the CI pipeline for the OS. The kernel is built in the normal CI pipeline, unit tested, etc. then platform-specific images are built.
Those are picked up by GitHub CI runners (could be anything but I'm using GH for now) that pull those image artifacts and send them over the internet to the board, which stores them on the microSD slot.
Then the board will boot the device-under-test (either by enabling a USB VBUS line, asserting PS_ON and pressing the power button, whatever the device needs) and will serve the image either a via USB mass device or by switching on access to the microSD card directly via a ribbon connector/custom microSD PCB and ribbon cable.
The kernel then communicates over serial back to the Link, which proxies that back up to the CI runner for evaluating test runs, etc.
Everything is configured using MQTT and mDNS. Using async Rust via Embassy for the firmware.
5-pin on the bottom left is for power - 5V 2A 'always on' supply (on the ATX24 adapters that's the 5vsb line), 5V 3A aux line (for VBUS, optional and not otherwise used to power the board itself), a sense line for the aux power (board will shut down and display an error on over-current of the main line if not sensed), active-low aux line enable signal (PS_ON for ATX24 sources), and ground.
This means that it's used to cut power on x86 machines, or to use a stock desktop PSU even for arm/riscv dev boards. In the future I want to make this all rack mounted and have a dedicated power supply for multiples of these.