Reference and testing

Capabilities and their evidence

Each capability is described, with its commands and steps, on its task page (see the Overview). This table gathers the evidence in one place.

Everything below was run on Linux only. "Stand-in" means a local SSH server, a chroot or a QEMU arm64 machine playing the build host or the board. Nothing has run on Windows, against a real build server, against Wind River Linux, or on a real board.

Settings

All keys are under neuralInverse.embeddedLinux.. Credentials are never settings.

Confirmations and records

• Writes to a board ask first, naming the board and every path: saves, new files, deletes, renames and pastes in a board's folder; Copy to Target; Reboot and Power Off; deploy-target; installing an update package (with the board, the package, its SHA-256 and the slots or devices written); writing an image (a device changed after confirmation is refused, and system and mounted disks are refused).
• Writes to the build ask first: a BitBake build started by an agent, devtool finish (with its dry run), a CVE_STATUS line (with the file and line), INCOMPATIBLE_LICENSE lines, FIT signing (with the key and the exact command; a PKCS#11 PIN comes from MKIMAGE_SIGN_PIN in the build account's environment, never from the Editor).
• Agent tools: listing and reading are read-only; every command, build, devtool action, board write, signing and update is always confirmed.
• Records: each BitBake build writes a record to <build directory>/.neuralinverse/builds/ with MACHINE and layer revisions; the licence record exports with each required source archive's SHA-256; the Embedded Linux output channel logs sessions, commands and project reads, never credentials.

With Neural Inverse Govern, builds started as tasks and changes to Neural Inverse settings are decided by the in-app policy check. See Govern.

Testing it and reporting back

The hardware team's checks need a Windows 10 or 11 laptop without administrator rights, your Linux build server with a Wind River Linux, NXP i.MX, TI, AMD or ST build directory, and a board's debug UART.

1. Check that ssh.exe works from a Windows terminal: ssh <you>@<build server> true (with your ProxyJump in %USERPROFILE%\.ssh\config).
2. Add the settings from Set up the build host and trust the workspace.
3. Check that Trust Build Host Key shows the same SHA256 fingerprint as ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub on the server.
4. Compare the Build Directory view with bitbake-layers show-layers and bitbake -e | grep -E '^(MACHINE|DISTRO)=' on the server.
5. Run Select Build Target..., build with Ctrl+Shift+B, cancel during a build, and check with ps -u $USER | grep bitbake on the server that nothing is left.
6. For the serial console: Open Serial Monitor at 115200 baud on the board's debug UART; check the U-Boot prompt, the full kernel log, the login prompt, and on Windows that the COM port opens without administrator rights.

Send back the operating system and version, ssh -V, the build server's distribution, the product (Wind River Linux LTS or BSP release), the BitBake version, the results and the Embedded Linux output log.

Troubleshooting

Next: What's next.