--- title: "Images and partition layout" --- # Images and partition layout What a .wic image, a uuu script or an ST flash layout writes, the image written to a board with uuu, STM32CubeProgrammer or bmaptool after a confirmation naming the device, and the partition layout and kickstart files with wic. ## 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](https://neuralinverse.com/docs/modules/embedded-linux/qemu/).