|
NAMEsrec_input - input file specificationsSYNOPSISsrec_* filename [ format ]DESCRIPTIONThis manual page describes the input file specifications for the srec_cat(1), srec_cmp(1) and srec_info(1) commands.Input files may be qualified in a number of ways: you may specify their format and you may specify filters to apply to them. An input file specification looks like this: filename [ format ][
-ignore‐checksums ][ filter ... ]
The filename may be specified as a file name, or the special name “-” which is understood to mean the standard input. Grouping with ParenthesesThere are some cases where operator precedence of the filters can be ambiguous. Input specifications may also be enclosed by ( parentheses ) to make grouping explicit. Remember that the parentheses must be separate words, i.e. surrounded by spaces, and they will need to be quoted to get them past the shell's interpretation of parentheses.Those Option Names Sure Are LongAll options may be abbreviated; the abbreviation is documented as the upper case letters, all lower case letters and underscores (_) are optional. You must use consecutive sequences of optional letters.All options are case insensitive, you may type them in upper case or lower case or a combination of both, case is not important. For example: the arguments “-help”, “-HEL” and “-h” are all interpreted to mean the -Help option. The argument “-hlp” will not be understood, because consecutive optional characters were not supplied. Options and other command line arguments may be mixed arbitrarily
on the command line.
The GNU long option names are understood. Since all option names for srec_input are long, this means ignoring the extra leading “-”. The “--option=value” convention is also understood. File FormatsThe format is specified by the argument after the file name. The format defaults to Motorola S‐Record if not specified. The format specifiers are:
This option says to use the Motorola S‐Record
format to read the file. (May be written -S‐Record as well.) See
srec_motorola(5) for a description of this file format.
The optional width argument describes the number of bytes which form each address multiple. For normal uses the default of one (1) byte is appropriate. Some systems with 16‐bit or 32‐bit targets mutilate the addresses in the file; this option will correct for that. Unlike most other parameters, this one cannot be guessed.
Ignore ChecksumsThe -IGnore‐Checksums option may be used to disable checksum validation of input files, for those formats which have checksums at all. Note that the checksum values are still read in and parsed (so it is still an error if they are missing) but their values are not checked. Used after an input file name, the option affects that file alone; used anywhere else on the command line, it applies to all following files.
Use this option to permit a file to contain redundant
values for some memory locations. The default is for this condition to be a
warning.
Use this option to permit a file to contain contradictory
values for some memory locations. The last value in the input(s) will be used.
The default is for this condition to be a fatal error.
GeneratorsIt is also possible to generate data, rather than read it from a file. You may use a generator anywhere you could use a file. An input generator specification looks like this:
The -data‐source may be one of the following:
This generator manufactures data with the given byte
value of the the given address range. It is an error if the byte‐value
is not in the range 0..255.
For example, to fill memory addresses 100..199 with newlines (0x0A), you could use a command like
This can, of course, be combined with data from files.
This generator manufactures data with the given byte
values repeating over the the given address range. It is an error if any of
the the byte‐values are not in the range 0..255.
For example, to create a data region with 0xDE in the even bytes and 0xAD in the odd bytes, use a generator like this:
The repeat boundaries are aligned with the base of the address range, modulo the number of bytes.
This generator is almost identical to -repeat‐data
except that the data to be repeated is the text of the given string.
For example, to fill the holes in an EPROM image eprom.srec with the text “Copyright (C) 1812 Tchaikovsky”, combine a generator and an -exclude filter, such as the command If you need to inject binary data into the string (e.g. a terminating NUL character), use the URL encoding that uses % followed by two hexadeimal characters. For example a backspace would be encoded as “%08”.
The thing to note is that we have two data sources: the eprom.srec file, and generated data over an address range which covers first megabyte of memory but excluding areas covered by the eprom.srec data.
This generator manufactures data with the given numeric
value, of a given byte width, in little‐endian byte order. It is an
error if the given value does not fit into the given byte width. It will
repeat over and over within the address range range.
For example, to insert a subversion commit number into 4 bytes at 0x0008..0x000B you would use a command like
This generator is a convenience wrapper around the -REPeat_Data generator. It can, of course, be combined with data from files.
As above, but using big‐endian byte
ordering.
Anything else will result in an error. Input FiltersYou may specify zero or more filters to be applied. Filters are applied in the order the user specifies.
This filter may be used to insert an
“Adler” 16‐bit checksum of the data into the data. Two
bytes, big‐endian order, are inserted at the address given. Holes in
the input data are ignored. Bytes are processed in ascending address order
(not in the order they appear in the input).
Note: If you have holes in your data, you will get a different Adler checksum than if there were no holes. This is important because the in‐memory EPROM image will not have holes. You almost always want to use the -fill filter before any of the Adler checksum filters. You will receive a warning if the data presented for Adler checksum has holes. You should also be aware that the lower and upper bounds of your data may not be the same as the lower and upper bounds of your EPROM. This is another reason to use the -fill filter, because it will establish the data across the full EPROM address range. http://en.wikipedia.org/wiki/Adler‐32
This filter may be used to insert an Adler 16‐bit
checksum of the data into the data. Two bytes, in little‐endian order,
are inserted at the address given. Holes in the input data are ignored. Bytes
are processed in ascending address order (not in the order they appear
in the input).
Note: If you have holes in your data, you will get a different Adler checksum than if there were no holes. This is important because the in‐memory EPROM image will not have holes. You almost always want to use the -fill filter before any of the Adler filters. You will receive a warning if the data presented for Adler checksum has holes. You should also be aware that the lower and upper bounds of your data may not be the same as the lower and upper bounds of your EPROM. This is another reason to use the -fill filter, because it will establish the data across the full EPROM address range. http://en.wikipedia.org/wiki/Adler‐32
This filter may be used to insert a Adler 32‐bit
checksum of the data into the data. Four bytes, big‐endian order, are
inserted at the address given. Holes in the input data are ignored. Bytes are
processed in ascending address order (not in the order they appear in
the input).
Note: If you have holes in your data, you will get a different Adler checksum than if there were no holes. This is important because the in‐memory EPROM image will not have holes. You almost always want to use the -fill filter before any of the Adler checksum filters. You will receive a warning if the data presented for Adler checksum has holes. You should also be aware that the lower and upper bounds of your data may not be the same as the lower and upper bounds of your EPROM. This is another reason to use the -fill filter, because it will establish the data across the full EPROM address range. http://en.wikipedia.org/wiki/Adler‐32
This filter may be used to insert a Adler 32‐bit
checksum of the data into the data. Four bytes, in little‐endian order,
are inserted at the address given. Holes in the input data are ignored. Bytes
are processed in ascending address order (not in the order they appear
in the input).
Note: If you have holes in your data, you will get a different Adler checksum than if there were no holes. This is important because the in‐memory EPROM image will not have holes. You almost always want to use the -fill filter before any of the Adler checksum filters. You will receive a warning if the data presented for Adler checksum has holes. You should also be aware that the lower and upper bounds of your data may not be the same as the lower and upper bounds of your EPROM. This is another reason to use the -fill filter, because it will establish the data across the full EPROM address range. http://en.wikipedia.org/wiki/Adler‐32
This filter may be used to insert an industry standard
16‐bit CRC checksum of the data into the data. Two bytes,
big‐endian order, are inserted at the address given. Holes in the input
data are ignored. Bytes are processed in ascending address order (not
in the order they appear in the input).
The following additional modifiers are understood:
This option may be used to set the CRC polynomial to be
used, by name. The known names include:
See http://en.wikipedia.org/wiki/Cyclic_redundancy_check for a table of names and values.
Note: If you have holes in your data, you will get a different CRC than if there were no holes. This is important because the in‐memory EPROM image will not have holes. You almost always want to use the -fill filter before any of the CRC filters. You will receive a warning if the data presented for CRC has holes. You should also be aware that the lower and upper bounds of your data may not be the same as the lower and upper bounds of your EPROM. This is another reason to use the -fill filter, because it will establish the data across the full EPROM address range. Note 2: there are a great many CRC16 implementations out there, see http://www.joegeluso.com/software/articles/ccitt.htm (now gone, reproduced at http://srecord.sourceforge.net/crc16-ccitt.html) and “A painless guide to CRC error detection algorithms” http://www.repairfaq.org/filipg/LINK/F_crc_v3.html for more information. If all else fails, SRecord is open source software: read the SRecord source code. The CRC16 source code (found in the srecord/crc16.cc file of the distribution tarball) has a great many explanatory comments. Please try all twelve combinations of the above options before reporting a bug in the CRC16 calculation.
This filter may be used to insert an industry standard
32‐bit CRC checksum of the data into the data. Four bytes,
big‐endian order, are inserted at the address given. Holes in the input
data are ignored. Bytes are processed in ascending address order (not
in the order they appear in the input). See also the note about holes, above.
The following additional modifiers are understood:
This filter may be used to insert an Fletcher
16‐bit checksum of the data into the data. Two bytes, big‐endian
order, are inserted at the address given. Holes in the input data are ignored.
Bytes are processed in ascending address order (not in the order they
appear in the input).
Note: If you have holes in your data, you will get a different Fletcher checksum than if there were no holes. This is important because the in‐memory EPROM image will not have holes. You almost always want to use the -fill filter before any of the Fletcher checksum filters. You will receive a warning if the data presented for Fletcher checksum has holes. You should also be aware that the lower and upper bounds of your data may not be the same as the lower and upper bounds of your EPROM. This is another reason to use the -fill filter, because it will establish the data across the full EPROM address range. http://en.wikipedia.org/wiki/Fletcher%27s_checksum It is possible to select seed values for sum1 and sum2 in the algorithm, by adding seed values on the command line. They each default to 0xFF if not explicitly stated. The default values (0) means that an empty EPROM (all 0x00 or all 0xFF) will sum to zero; by changing the seeds, an empty EPROM will always fail. The third optional argument is the desired sum, when the checksum itself is summed. A common value is 0x0000, placed in the last two bytes of an EPROM, so that the Fletcher 16 checksum of the EPROM is exactly 0x0000. No manipulation of the final value is performed if this value if not specified.
This filter may be used to insert an Fletcher
16‐bit checksum of the data into the data. Two bytes, in
little‐endian order, are inserted at the address given. Holes in the
input data are ignored. Bytes are processed in ascending address order
(not in the order they appear in the input).
Note: If you have holes in your data, you will get a different Fletcher checksum than if there were no holes. This is important because the in‐memory EPROM image will not have holes. You almost always want to use the -fill filter before any of the Fletcher filters. You will receive a warning if the data presented for Fletcher checksum has holes. You should also be aware that the lower and upper bounds of your data may not be the same as the lower and upper bounds of your EPROM. This is another reason to use the -fill filter, because it will establish the data across the full EPROM address range. http://en.wikipedia.org/wiki/Fletcher%27s_checksum
This filter may be used to insert a Fletcher
32‐bit checksum of the data into the data. Four bytes,
big‐endian order, are inserted at the address given. Holes in the input
data are ignored. Bytes are processed in ascending address order (not
in the order they appear in the input).
Note: If you have holes in your data, you will get a different Fletcher checksum than if there were no holes. This is important because the in‐memory EPROM image will not have holes. You almost always want to use the -fill filter before any of the Fletcher checksum filters. You will receive a warning if the data presented for Fletcher checksum has holes. You should also be aware that the lower and upper bounds of your data may not be the same as the lower and upper bounds of your EPROM. This is another reason to use the -fill filter, because it will establish the data across the full EPROM address range. http://en.wikipedia.org/wiki/Fletcher%27s_checksum
This filter may be used to insert a Fletcher
32‐bit checksum of the data into the data. Four bytes, in
little‐endian order, are inserted at the address given. Holes in the
input data are ignored. Bytes are processed in ascending address order
(not in the order they appear in the input).
Note: If you have holes in your data, you will get a different Fletcher checksum than if there were no holes. This is important because the in‐memory EPROM image will not have holes. You almost always want to use the -fill filter before any of the Fletcher checksum filters. You will receive a warning if the data presented for Fletcher checksum has holes. You should also be aware that the lower and upper bounds of your data may not be the same as the lower and upper bounds of your EPROM. This is another reason to use the -fill filter, because it will establish the data across the full EPROM address range. http://en.wikipedia.org/wiki/Fletcher%27s_checksum
This filter may be used to offset the addresses by the
given number of bytes. No data is lost, the addresses will wrap around in 32
bits, if necessary. You may use negative numbers for the offset, if you wish
to move data lower in memory.
Please note: the execution start address is a different concept than the first address in memory of your data. If you want to change where your monitor will start executing, use the -execution‐start‐address option (srec_cat(1) only).
These filters many be use to generate the CRC used by the
hardware CRC unit on the STM32 series of ARM MPUs. The algorithm used by the
STM32 hardware unit is just a CRC32 with a different polynomial and
word‐fed instead of byte‐fed.
The address is where to place the 4‐byte STM32 CRC. The CRC used is documented in “RM0041, STM32F100xx
reference manual”, page 46, chapter “CRC Calculation
Unit”, which can be found at
Address RangesThere are eight ways to specify an address range:
This says to use the specified input file as a mask. The
range includes all the places the specified input has data, and holes where it
has holes. The input specification need not be just a file name, it may be
anything any other input specification can be.
See also the -over option for a discussion on operator precedence.
This says to use the specified input file as a mask. The
range extends from the minimum to the maximum address used by the input,
without any holes, even if the input has holes. The input specification need
not be just a file name, it may be anything any other input specification can
be.
You may need to enclose input‐specification in parentheses to make sure it can't misinterpret which arguments go with which input specification. This is particularly important when a filter is to follow. For example filename -fill 0 -over filename2
-swap‐bytes
groups as
filename -fill 0 -over '(' filename2
-swap‐bytes ')'
when what you actually wanted was
'(' filename -fill 0 -over filename2 ')'
-swap‐bytes
The command line expression parsing tends to be “greedy” (or right
associative) rather than conservative (or left associative).
It is also possible to pad ranges to be whole aligned
multiples of the given number. For example
input‐file -fill 0xFF -within
input‐file -range‐pad 512
will fill the input‐file so that it consists of whole
512‐byte blocks, aligned on 512 byte boundaries. Any large holes in the
data will also be multiples of 512 bytes, though they may have been shrunk as
blocks before and after are padded.
This operator has the same precedence as the explicit union operator.
Calculated ValuesMost of the places above where a number is expected, you may supply one of the following:
The value of this expression is the negative of the
expression argument. Note the space between the minus sign and its
argument: this space is mandatory.
srec_cat in.srec -offset −
-minimum‐addr in.srec -o out.srec
This example shows how to move data to the base of
memory.
This inserts the minimum address of the specified input
file. The input specification need not be just a file name, it may be anything
any other input specification can be.
See also the -over option for a discussion on operator precedence.
This inserts the maximum address of the specified input
file, plus one. The input specification need not be just a file name, it may
be anything any other input specification can be.
See also the -over option for a discussion on operator precedence.
This inserts the length of the address range in the
specified input file, ignoring any holes. The input specification need not be
just a file name, it may be anything any other input specification can be.
See also the -over option for a discussion on operator precedence. For example, the -OVER input‐specification option can be thought of as short‐hand for '(' -min file -max file ')', except that it is much easier to type, and also more efficient. In addition, calculated values may optionally be rounded in one of three ways:
When using parentheses, they must each be a separate command line
argument, they can't be within the text of the preceding or following
option, and you will need to quote them to get them past the shell, as
'(' and ')'.
COPYRIGHTsrec_input version 1.64Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller The srec_input program comes with ABSOLUTELY NO WARRANTY;
for details use the 'srec_input -VERSion License' command. This is
free software and you are welcome to redistribute it under certain
conditions; for details use the 'srec_input -VERSion License'
command.
MAINTAINER
Visit the GSP FreeBSD Man Page Interface. |