Images and partition layout

Write the image to a board

State: modelled: bmaptool 3.8.0 wrote a real wic image with its .bmap to a loop device, equal byte for byte, and refused a busy and a too-small device; uuu 1.5.233 built from source ran -dry on a gateway script, -lsusb was read and a wait for a board was cancelled; a lab host over a real sshd (tools found, lsblk read, system and mounted disks refused, a device changed after confirmation stopped the write); MBR and GPT read from real wic output checked against sfdisk; ST's own FlashLayout samples. No board has been written over USB serial download or DFU, and STM32CubeProgrammer has never run. Not run on Windows (tool discovery), or for TI and AMD boot media. A verification kit for hardware teams runs the same command lines without the IDE.

See what an image writes

Open Image for Writing lists the deploy folder's .wic and .wic.zst images (with their .bmap), .uuu scripts and ST FlashLayout .tsv files, and shows what each writes before anything runs:

• for a disk image: the partitions and raw bootloader areas from its MBR or GPT, with the data each holds;
• for a uuu script: each command, what it does on the board and the files it sends (scripts with fuse commands are refused);
• for a flash layout: its rows, with checks for duplicate ids, missing binaries and overlaps.

Write it

1. Install the writing tools where the board is attached: uuu (NXP), STM32_Programmer_CLI (STM32CubeProgrammer) or bmaptool. Find Writing Tools finds them on PATH and in the vendors' Windows install folders, or set neuralInverse.embeddedLinux.paths.uuu, neuralInverse.embeddedLinux.paths.stm32Programmer or neuralInverse.embeddedLinux.paths.bmaptool.
2. Write from this computer, or from a lab host declared in neuralInverse.embeddedLinux.labHosts (name, host, user, port, identityFile, folder, notes) and reached over SSH like the build host.
3. Run Write Image to Board... and pick the image, the station and the method (for example uuu emmc_all with the bootloader).
4. The image is copied from the build host with its SHA-256 checked (to neuralInverse.embeddedLinux.imageWriting.localFolder on this computer, or the lab host's folder).
5. The confirmation names the device (model, size, serial) or the board's USB path, the image and its SHA-256. System, mounted and read-only disks are refused, and the device is checked again before writing; a device changed after confirmation stops the write. uuu runs -dry first.
6. Progress shows in a terminal and a cancellable notification. Each write is recorded in the editor's Writes of this image; a cancelled write says the storage may be partly written.

Agent tools: six read-only, and writing an image always asks first.

Partition layout with wic

State: modelled with poky scarthgap's own wic (create, ls, cp, rm and its kickstart parser) on poky's .wks files and meta-freescale's imx-imx-boot-bootpart.wks.in, real bitbake -e (BitBake 2.8.1), RAUC system.conf slots, and the running app over a local sshd. Image contents were stand-ins (no real i.MX image build); SWUpdate slots were checked in unit tests only. Not run on Windows, against a real build server, on a board or on Wind River Linux.

Kickstart files

.wks and .wks.in files have syntax colouring, an outline, hovers on part, bootloader and include options, and go to an include. Open Kickstart File of Image (WKS_FILE) opens the file WKS_FILE or WKS_FILES names for an image recipe, from bitbake -e. Check Kickstart File with wic runs wic's own kickstart parser on the build host; its errors and the module's own land in Problems (for example a comment after a statement, which wic reads as arguments).

The Partition Layout view

Open Partition Layout shows a built image's partition table to scale, wic ls of the image and of each partition, each built partition compared with its .wks line (alignment, size, type, bootable flag, file system), and the RAUC and SWUpdate slot devices checked against the layout, with a warning when a slot points at a partition the image does not have. Reload reads it again.

Change a copy, never the deployed image

wic cp, wic rm and wic create work only on copies in build/wic-dev, never on deploy/images, each after a confirmation with the exact command, and the result is checked with wic ls:

• Make Working Copy of Image..., then Copy File into Working Copy (wic cp)... and Remove from Working Copy (wic rm)...;
• Create Developer Image with wic... lays an image out with a .wks you pick;
• Discard Working Copy or Developer Image... removes one.

Agent tools: three read-only, four that ask first.

Next: QEMU.