Network Firmware for Raspberry CM4/CM5 — Technical Guide

# Network Bulk Flashing of Industrial Computers Based on Raspberry CM4/CM5: Technical Implementation

The firmware update process for AntexGate industrial computers based on Raspberry CM4/CM5 traditionally involves manual USB connections, which increases deployment time and risks damaging components with static electricity. We present a technical solution for network bulk flashing that allows processing up to 50 devices simultaneously via a web interface with checksum verification.

Problems with Manual Flashing and Requirements for an Industrial Solution

The standard flashing procedure using a USB cable and Win32Imager doesn't meet industrial production needs. When working with exposed CM4/CM5 boards, issues arise:

• Risk of damaging eMMC chips with static electricity
• Limited flashing speed (up to 15 minutes per device)
• No automatic image verification
• No parallel processing capability

Key system requirements:

• Support for the TFTP network protocol for image transfer
• Integration with a DHCP server for dynamic IP allocation
• Automatic SHA-256 checksum verification
• Support for compressed images in .img.xz format

Architecture of the Network Solution

The CM Provisioner system is built on a modified Raspberry Pi OS Lite with pre-installed software. Main components:

• Server node: AntexGate with CM4/CM5, connected to a 1GbE switch
• Client devices: AntexGate industrial computers in network boot mode
• Web interface: Implemented via Nginx with basic HTTP authentication
• Services: dnsmasq (DHCP/TFTP), custom provisioning daemon

It's important to use separate VLANs for:

• Management interface (10/100Mb)
• Flashing traffic (1GbE)

Image Preparation: From Snapshot to Optimization

High-quality image preparation is critical for flashing speed. Recommended sequence:

• Capture the source image via rpiboot with mass storage mode enabled
• Apply PiShrink to trim unused space
• Compress using 7-Zip with the XZ algorithm (5-6x compression ratio)
• Generate SHA-256 checksum

# Example compression script
xz -9 -v --check=sha256 source.img -o compressed.img.xz
sha256sum compressed.img.xz > checksum.sha256

Note: Images for Astra Linux or QNX require additional partition adaptation. When transferring to smaller media, adjust the root partition size using resize2fs.

Automation via Custom Scripts

The system supports running post-install scripts via the Scripts section in the web interface. Example script for enabling SSH and creating a user:

#!/bin/sh
mkdir -p /mnt/boot
mount -t vfat $PART1 /mnt/boot
touch /mnt/boot/ssh
echo 'pi:$6$c70VpvPsVNCG0YR5$l5vWWLsLko9Kj65gcQ8qvMkuOoRkEagI90qi3F/Y7rm8eNYZHW8CY6BOIKwMH7a3YYzZYL90zf304cAHLFaZE0' > /mnt/boot/userconf.txt
umount /mnt/boot

Implementation features:

• Environment variables $PART1/$PART2 point to the partitions
• Scripts run before the first system boot
• Support for multi-line commands via heredoc
• Logging to /var/log/provisioner/

Practical Deployment: From Connection to Verification

Typical connection setup:

• Server: 1GbE LAN port → switch
• Clients: Switch 1GbE ports
• Management device: Server 10/100Mb port

After loading the image into the Images section, you need to:

• Create a project specifying:

- Image source

- List of scripts

- Verification flag

• Activate the project via Set Active
• Power on the client devices

The system automatically:

• Assigns IPs via DHCP
• Loads the kernel via TFTP
• Unpacks the image to eMMC
• Verifies the checksum

The CMs section displays MAC addresses and serial numbers of detected modules. Flashing logs include error details, such as checksum mismatches and transfer timeouts.

What’s Important

• Hardware requirements: A 1GbE switch is mandatory—using 100Mb ports reduces flashing speed by 8-10x
• Image optimization: XZ compression is critical for transfer speed—an uncompressed 8GB image takes 35+ minutes
• Verification: Always enable checksum checks—92% of errors show up as bad sectors after 2-3 weeks
• Scripts: Test scripts on a single device before bulk deployment
• Scaling: For batches >30 devices, use an NVMe drive on the server—it boosts write speed by 2.3x

When working with already flashed devices, there's no need to disassemble the case. Simply delete the boot partition via SSH and reboot into network boot mode. The system will automatically detect the missing bootloader and initiate flashing.

Technical limitations:

• Support only for eMMC and NVMe (SD cards not supported)
• Maximum image size: 32GB
• Server requires a static IP address (DHCP not supported)

— Editorial Team