Binary Image Files vs Formatted Firmware Files

Binary image files and formatted firmware files are two common file types used for storing and distributing firmware updates. The main difference is that binary image files contain the raw binary code of the firmware, while formatted firmware files have additional metadata and structure around the firmware binary.

What are Binary Image Files?

Binary image files, as the name suggests, contain the binary executable code of a firmware image in raw format. This includes the compiled machine code instructions and data that make up the firmware program. Binary image files go by many names like binary blobs, binary images and code dumps. They typically have the file extensions .bin, .img or .dump.

The key property of binary image files is that they contain just the firmware binary data without any appended metadata or structure. The data is organized exactly as the processor expects it – starting from the first instruction to execute through to the last byte of data. This allows the processor to easily load and run the binary file.

Binary image files are created by firmware developers after compiling the source code into machine executable format. The compiler and linker organize the instructions and data into the required segments like code, initialized data, stack, heap etc. The linker then outputs the binary containing these raw segments ready to be loaded onto the hardware memory.

On the developer side, binary files have the advantage of being compact files that are easy to generate from the build process. They contain the essential firmware code without any excess overhead. For distributing firmware upgrades, binary files are simple and widely compatible with devices as they do not require any special parsing logic.

Use Cases of Binary Image Files

Here are some common use cases of binary image firmware files:

• Distributing final release firmware – Binary image files are an efficient way to deliver production firmware builds to end users for applying updates.
• Low-level device programming – Manufacturers often use binary images to directly program firmware onto devices during production.
• Bootloaders – Simple bootloaders that execute upon startup can initialize hardware and directly load a binary image into memory.
• Recovery mode updating – Devices in recovery mode can sometimes accept binary images to replace corrupted firmware when higher level functions are unavailable.
• Debugging with JTAG/SWD – Debug probes upload binary images to emulate firmware during development. Easier than formatted files.
• Quick loading by developers – Developers working on firmware code can quickly load binary files to test on hardware without full build processing.

What are Formatted Firmware Files?

Formatted firmware files contain the same firmware binary code as image files, but they have additional metadata, integrity checks and structure wrapping the core firmware image. These files use well-defined specifications like Intel HEX, SREC or U-Boot UImage format.

The firmware binary is stored as the main payload data object. But it is augmented with header structures, checksums, load addresses, digital signatures and other metadata fields as defined by the particular file format. This metadata helps to validate, locate and load the binary safely.

Formatted firmware files provide robustness, adaptability and security compared to plain binary images. But they require firmware tools and bootloaders that understand the specific file format. The device needs to correctly parse the format to extract the firmware payload into memory.

Common Firmware File Formats

Here are some examples of common formatted firmware file types:

• Intel HEX – Used extensively with 8051, AVR, PIC and other microcontrollers. Includes extended linear address records and checksums.
• Motorola S-Record – Historic format with start address, ascii data records and end record. No compression or signing.
• TI-TXT – Texas Instruments format adds device identification and simple integrity checks for their MCUs.
• TEE – Trusted Execution Environment format wraps firmware securely using authentication and encryption.
• U-Boot UImage – UImage header defines entry point, load addr, timestamp and CRC for Linux systems.
• FIT – Flattened Image Tree encapsulates firmware images and configuration data into one file.
• UEFI Capsule – Standard firmware format for updating UEFI-based systems like modern PCs.

Advantages of Formatted Firmware Files

Here are some benefits provided by using a structured firmware file format:

• Metadata – Additional data like version, author, timestamp help identify and track firmware files.
• Validation – Checksums or signatures verify the integrity of the firmware binary code.
• Loading – Defines proper loading address, entry point and memory layout.
• Compression – Some formats allow compressing the firmware binary for smaller file sizes.
• Adaptability – Can contain multiple images or configurations for different devices in one file.
• Security – Encryption and authentication protect firmware from tampering.
• Robustness – Additional data provides redundancy and assists recovery from errors.

Use Cases of Formatted Firmware Files

Here are some examples of where formatted firmware files provide benefits over plain binary images:

• Booting Linux systems – Formats like U-Boot define entry point and memory mapping when booting Linux kernels.
• Secure firmware updates – Signed and encrypted firmware file formats prevent tampering of over-the-air (OTA) updates.
• Adaptive firmware – Defining configurations and images for different hardware variants in one firmware package file.
• Remote device deployment – Metadata assists tracking and inventory management of large device populations.
• Safety-critical devices – Checksums, signatures and encryption mitigate risk of firmware corruption.
• Automated handling – Tools can dissect metadata programmatically for tasks like version tracking and compatibility checking.

Firmware Development Process Overview

To better understand the difference between binary images and formatted firmware files, it helps to look at a typical embedded firmware development process:

1. Developers write firmware code in C/C++/Rust that implements the desired functionality.
2. The code is compiled into binary machine code for the target processor architecture.
3. The linker combines compiled object files and static libraries into an executable binary image.
4. The binary image can be directly loaded onto the hardware for testing.
5. For production firmware, the binary goes through post processing and formatting before release.
6. Post processing steps may include compression, encryption, validation, metadata insertion etc.
7. The final output is a formatted firmware file that encapsulates the binary with additional data and structure.
8. The formatted firmware file is then distributed or installed on devices.
9. Binary image – Primary output of the compile/link process.
10. Formatted firmware file – Enhanced version of the binary for production use.
11. Use binary images when you need a compact image for programming raw memory and don’t require metadata or validation.
12. Use formatted firmware if you need validation, security features, loading info or hardware configuration data.
13. Bootloaders should prefer a formatted firmware file that defines the memory layout and entry point.
14. For prototyping and testing during development, binary images load and execute code quickly.
15. For production releases and public distribution, use formatted firmware files with metadata and validation.
16. Recovery mode and failsafe mechanisms often rely on basic binary images without headers.
17. Simple single-function devices may only need a binary image, while complex devices require formatted firmware.
18. If distributing firmware publicly, use a formatted firmware file with signature to avoid tampering.