General Overview

The chipflasher’s software pair uses the files chip2file.txt and file2chip.txt to store and read chip data. When invocing connect, you can pass alternative filenames, of course. Both files are processed on a line by line basis. Each line is embedded into a pair of STX/ETX characters which are stripped before the line is stored on disk or in the chip.

Reading chip data

In flash chips, data is stored byte by byte, in binary form. kick casts that data into a format which is then received by connect (the chipflasher’s host software) and stored on disk under the name chip2file.txt. Payloads of just 0xff may be filtered in order to accelerate data transfer. CR+LF is used as line ending. The one-line file header and footer may contain valuable information as well.
Writing data to chip

Transform your ROM file into a supported data format and save it as file2chip.txt. This file is used by connect for feeding data to kick. All commonly used line endings are supported, i.e. LF, CR and CR+LF.
Verification

It is always a good idea to read a chip twice and diff the outputs, in order to verify that the received data is not corrupted. Remember that chip2file.txt will be overwritten without notice, so back it up if you don't want to loose your data!

The <tt>srecord</tt> Program Collection

All of the chipflasher’s data formats intend to be compatible with srecord, the famous free software program collection by Peter Miller. Please install the srecord collection with:

your distribution’s installer
$ sudo apt-get install srecord — (i.e. Trisquel GNU/Linux)

Some first sources of information are:

http://srecord.sourceforge.net/
$ apropos srec_
$ man srec_examples
$ man srec_input
$ man srec_cat
$ man srec_motorola
$ man srec_binary

The srecord program collection supports a variety of data formats like binary, hexdump and the Motorola S-Record which is the default.

Supported Data Formats

The chipflasher menu offers the following format entries, which are accessible through “[t] toggle format”:

“Motorola-S”

Data is organized in lines of Motorola S-Record. The payload of each line is transmitted over the RS232 wire as binary data. This speeds up transmission. Each line contains a checksum which helps to check data integrity on the fly. This format is recommended.
“Hex-Dump”

Data is organized in lines of hexdata with an appended ASCII text representation of bytes, human readable. Note the output of srec_cat is understood by kick only if 0xffs are not stripped out.

Verification of initial Readouts

# create a backup of first readout
$ cp chip2file.txt backup.txt

# diff with second readout
$ diff backup.txt chip2file.txt

Create a Binary from the Chipflasher’s Readout

This is useful if you need to extract binary blobs in order to create a new boot.rom with coreboot.

“Motorola-S”

# Convert a Motorola S-Record into a complete map of your target chip.
# Use 0x800000 for 8MB chip sizes, 0x400000 for 4MB chip sizes, etc.
$ srec_cat chip2file.txt -fill 0xff 0x000000 0x800000 -o chip2file.bin -raw

“Hex-Dump”

# Convert a Hex-Dump into a complete map of your target chip.
# Use 0x800000 for 8MB chip sizes, 0x400000 for 4MB chip sizes, etc.
$ srec_cat chip2file.txt -hexd -fill 0xff 0x000000 0x800000 -o chip2file.bin -raw

Prepare for Flashing

“Motorola-S”

# convert a binary boot rom file into Motorola S-Record
$ srec_cat boot.rom -raw -o boot.srec -obs 0x40 -esa 0x00

# strip 0xff bytes, but allow a runlen of 16 bytes
$ srec_cat boot.srec -uf 0xff 0x10 -o file2chip.txt -obs 0x40 -esa 0x00

# check file integrity before flashing
$ srec_info file2chip.txt

“Hex-Dump”

# convert a binary boot rom file into Hex-Dump
$ srec_cat boot.rom -raw -o boot.hexdump -hexd

# check file integrity
$ srec_info boot.hexdump -hexd

# prepare for flashing
$ cp boot.hexdump file2chip.txt

Verification

“Motorola-S”

# strip all 0xff bytes from the boot file
$ srec_cat boot.srec -uf 0xff -o test0 -do

# convert the chip readout into same layout
$ srec_cat file2chip.txt -uf 0xff -o test1 -do

# diff the files, their data lines should match
$ diff test0 test1

“Hex-Dump”

# check file integrity
$ srec_info chip2file.txt -hexd

# convert the boot file into Hex-Dump for comparison
$ srec_cat boot.hexdump -hexd -uf 0xff -o test0 -hexd

# convert the chip readout into Hex-Dump
$ srec_cat chip2file.txt -hexd -uf 0xff -o test1 -hexd

# diff the files, they should match
$ diff test0 test1

Generating Data for Pages, Blocks and the whole Chip

If you need to fill memory areas with constant values, please use menu option “[I] flash file” with a prepared file2chip.txt file.

I.e., to fill page 3 of a paged 8MB SPI chip with 0xee, prepare your file2chip.txt like so:

$ srec_cat -gen 0x000300 0x0000400 0xee -o file2chip.txt

Please refer to

$ man srec_cat
$ man srec_input

to get to know more about srecord’s data generators.

Note: Some simple consumer SPI chips do not provide a chip erase command. Their memory may be cleaned to 0xff by this method!

Copyright: Copyright (C) 2016, 2017, 2018 Kai Mertens kmx@p.nosp@m.oste.nosp@m.o.net
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled: GNU Free Documentation License