title: srec_mif(5)

summary: Memory Initialization File (MIF) format

text:
# srec_mif(5)

## NAME
srec_mif - Memory Initialization File (MIF) format

## DESCRIPTION
This format was invented by Altera.

An ASCII text file (with the extension .mif) that specifies the initial content of a memory block (CAM, RAM, or ROM), that is, the initial values for each address. This file is used during project compilation and/or simulation. You can create a Memory Initialization File in the Memory Editor, the In‐System Memory Content Editor, or the Quartus II Text Editor.

A Memory Initialization File serves as an input file for memory initialization in the Compiler and Simulator. You can also use a Hexadecimal (Intel‐Format) File (.hex) to provide memory initialization data.

A Memory Initialization File contains the initial values for each address in the memory. A separate file is required for each memory block. In a Memory Initialization File, you must specify the memory depth and width values. In addition, you can specify data radixes as binary (BIN), hexadecimal (HEX), octal (OCT), signed decimal (DEC), or unsigned decimal (UNS) to display and interpret addresses and data values. Data values must match the specified data radix.

When creating a Memory Initialization File in the Quartus II Text Editor, you must start with the DEPTH, WIDTH, ADDRESS_RADIX and DATA_RADIX keywords. You can use Tab "" and Space " " characters as separators, and insert multiple lines of comments with the percent "%" character, or a single comment with double dash "--" characters. Address:data pairs represent data contained inside certain memory addresses and you must place them between the CONTENT BEGIN and END keywords, as shown in the following examples.

```
%  multiple‐line comment
multiple‐line comment  %
-- single‐line comment
DEPTH = 8;                    -- The size of data in bits
WIDTH = 32;                   -- The size of memory in words
ADDRESS_RADIX = HEX;          -- The radix for address values
DATA_RADIX = BIN;             -- The radix for data values
CONTENT                       -- start of (address : data pairs)
BEGIN
00 : 00000000;                -- memory address : data
01 : 00000001;
02 : 00000010;
03 : 00000011;
04 : 00000100;
05 : 00000101;
06 : 00000110;
07 : 00000111;
08 : 00001000;
09 : 00001001;
0A : 00001010;
0B : 00001011;
0C : 00001100;
END;
```

There are several ways to specify the address and data, as seen in the following table:

Notation

Interpretation

Example

A : D;

Addr[A] = D

2 : 4 Address: 01234567 Data: 00400000

[A0..A1] : D; (See note below.)

Addr[A0] to [A1] contain data D

[0..7] : 6 Address: 01234567 Data: 66666666

[A0..A1] : D0 D1; (See note below.)

Addr[A0] = D0, Addr[A0+1] = D1, Addr[A0+2] = D0, Addr[A0+3] = D1, until A0+n = A1

[0..7] : 5 6 Address: 01234567 Data: 56565656

A : D0 D1 D2;

Addr[A] = D0, Addr[A+1] = D1, Addr[A+2] = D2

2 : 4 5 6 Address: 01234567 Data: 00456000

Note: The address range forms are limited in SRecord, the range must be less than 255 bytes. SRecord will never write an address range.

Note: When reading MIF file, SRecord will round up the number of bits in the WIDTH to be a multiple of 8. Multi‐byte values will be laid down in memory as big‐endian.

An ASCII text file (with the extension .mif) that specifies the initial content of a memory block (CAM, RAM, or ROM), that is, the initial values for each address. This file is used during project compilation and/or simulation. A MIF contains the initial values for each address in the memory. In a MIF, you are also required to specify the memory depth and width values. In addition, you can specify the radixes used to display and interpret addresses and data values.

## SIZE MULTIPLIER
In general, binary data will expand in sized by approximately 3.29 times when 8‐bit data is represented with this format (16 bit = 2.75, 32 bit = 2.47, 64 bit = 2.34).

## EXAMPLE
Following is a sample MIF:

```
DEPTH = 32; % Memory depth and width are required %
% DEPTH is the number of addresses %
WIDTH = 14; % WIDTH is the number of bits of data per word %
% DEPTH and WIDTH should be entered as decimal numbers %
ADDRESS_RADIX = HEX; % Address and value radixes are required %
DATA_RADIX = HEX; % Enter BIN, DEC, HEX, OCT, or UNS; unless %

                  % otherwise specified, radixes = HEX %

 --Specify values for addresses, which can be single address or range
CONTENT
BEGIN
[0..F]: 3FFF;     % Range: Every address from 0 to F = 3FFF %
6     :    F;     % Single address: Address 6 = F %
8     :    F E 5; % Range starting from specific address %
--                % Addr[8] = F, Addr[9] = E, Addr[A] = 5 %
END;
```

## REFERENCE
The above information was gleaned from the following sources:

```
http://www.altera.com/support/software/nativelink/quartus2/glossary/def_mif.html
http://www.mil.ufl.edu/4712/docs/mif_help.pdf
```

## COPYRIGHT
srec_mif version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_mif program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_mif -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_mif -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


package: srecord

title: srec_mips_flash(5)

summary: MIPS\[hy]Flash file format

text:
# srec_mips_flash(5)

## NAME
srec_mips_flash - MIPS‐Flash file format

## DESCRIPTION
The MIPS SDE tool chain has a convert program that is able to output this format. I have no idea what reads it, some kind of flash programmer I suppose.

### Format
The file must start with '!R' to reset the state machine. White space appears to be ignored, except as it serves to separate tokens.

Data is presented as 32‐bit hexadecimal numbers, in the normal big‐endian text number format. To write them to memory, you have to know if the target is big‐endian or little‐endian. for little endian targets, reverse the order of the bytes in this number.

The eight bytes following a '>' are a sort of comment. The SDE code reads like they are displayed in the flash programmer as a kind of progress indicator.

The number following '@' is a new address for the following data.

Each segment must be erased before it can be written, this is done with the '!E' command. Each segment is assumed to be 128kB in size.

Special segments must unlocked (with the '!C' command) and locked again (with the '!S' command).

This file format contains no checksum mechanism.

### Command Line Options
This format is specified using one of the -Mips‐Flash‐Big_Endian or -Mips‐Flash‐Little_Endian options. The endian‐ness must be specified on the command line, because there is nothing in the file contents to indicate the endian‐ness of the data it contains.

### Size Multiplier
In general, binary data will expand in sized by approximately 2.3 times when represented with this format (worse if you use shorter lines).

## EXAMPLE
Here is an example MIPS‐Flash file. It contains the data “Hello, World” to be loaded at bytes address 0x0000 (but remember, the file contents are always multiples of four bytes).

```
!R
>00000xxx @00000000 !E
@00000000
>00000000
48656C6C 6F2C2057 6F726C64 210A0000
>#DL_DONE
>FINISHED
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au

branch: sisyphus


title: srec_mos_tech(5)

summary: MOS Technology file format

text:
# srec_mos_tech(5)

## NAME
srec_mos_tech - MOS Technology file format

## DESCRIPTION
The MOS Technology format allows binary files to be uploaded and downloaded between between a computer system (such as a PC, Macintosh, or workstation) and an emulator or evaluation board for microcontrollers and microprocessors.

### The Lines
Each line consists of 5 fields. These are the length field, address field, data field, and the checksum. The lines always start with a semicolon (;) character.

### The Fields
;

Length

Address

Data

Checksum

CRLF

Length

The record length field is a 2 character (1 byte) field that specifies the number of data bytes in the record. Typically this is 24 or less.

Address

This is a 2‐byte address that specifies where the data in the record is to be loaded into memory, big‐endian.

Data

The data field contains the executable code, memory‐loadable data or descriptive information to be transferred.

Checksum

The checksum is an 2‐byte field that represents the least significant two bytes of the the sum of the values represented by the pairs of characters making up the record's length, address, and data fields, big‐endian.

### End of File
The final line should have a data length of zero, and the data line count in the address field. The checksum is not the usual checksum, it is instead a repeat of the data line count.

### Size Multiplier
In general, binary data will expand in sized by approximately 2.54 times when represented with this format.

## EXAMPLE
Here is an example MOS Technology format file. It contains the data “Hello, World” to be loaded at address 0.

```
;0C000048656C6C6F2C20576F726C640454
;0000010001
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au

## KIM‐1 User Manual - Appendix F - Paper Tape Format
(The following information is reproduced from http://users.telenet.be/kim1‐6502/6502/usrman.html#F just in case it vanishes from the Web.)

The paper tape LOAD and DUMP routines store and retrieve data in a specific format designed to insure error free recovery. Each byte of data to be stored is converted to two half bytes. The half bytes (whose possible values are 0 to F HEX) are translated into their ASCII equivalents and written out onto paper tape in this form.

Each record outputted begins with a “;” character (ASCII 3B) to mark the start of a valid record. The next byte transmitted (18HEX) or (24 decimal) is the number of data bytes contained in the record. The record's starting address High (1 byte, 2 characters), starting address Lo (1 byte, 2 characters), and data (24 bytes, 48 characters) follow. Each record is terminated by the record's check‐sum (2 bytes, 4 characters), a carriage return (ASCII 0D), line feed (ASCII 0A), and six “NULL” characters (ASCII 00). (NULL characters cause a blank area on the paper tape.)

The last record transmitted has zero data bytes (indicated by ;00) The starting address field is replaced by a four digit Hex number representing the total number of data records contained in the transmission, followed by the records usual check‐sum digits. An “XOFF” character ends the transmission.

;180000FFEEDDCCBBAA0099887766554433221122334455667788990AFC

;0000010001

During a “LOAD” all incoming data is ignored until a “;” character is received. The receipt of non ASCII data or a mismatch between a records calculated check‐sum and the check‐sum read from tape will cause an error condition to be recognized by KIM. The check‐sum is calculated by adding all data in the record except the “;” character. The paper tape format described is compatible with all other MOS Technology, Inc. software support programs.


title: srec_motorola(5)

summary: Motorola S\[hy]Record hexadecimal file format

text:
# srec_motorola(5)

## NAME
srec_motorola - Motorola S‐Record hexadecimal file format

## DESCRIPTION
This format is also known as the Exorciser, Exormacs or Exormax format.

Motorola's S‐record format allows binary files to be uploaded and downloaded between two computer systems. This type of format is widely used when transferring programs and data between a computer system (such as a PC, Macintosh, or workstation) and an emulator or evaluation board for Motorola microcontrollers and microprocessors.

### The Lines
Most S‐Record file contain only S‐Record lines (see the next section), which always start with a capital S character. Some systems generate various “extensions[rq] which usually manifest as lines which start with something else. These “extension[rq] lines may or may not break other systems made by other vendors. Caveat emptor.

### The Fields
The S‐Record format consists of 5 fields. These are the type field, length field, address field, data field, and the checksum. The lines always start with a capital S character.

S

Type

Record Length

Address

Data

Checksum

Type

The type field is a 1 character field that specifies whether the record is an S0, S1, S2, S3, S5, S6, S7, S8 or S9 field.

Record Length

The record length field is a 2 character (1 byte) field that specifies the number of character pairs (bytes) in the record, excluding the type and record length fields.

Address

This is a 2‐, 3‐ or 4‐byte address that specifies where the data in the S‐Record is to be loaded into memory.

Data

The data field contains the executable code, memory‐loadable data or descriptive information to be transferred.

Checksum

The checksum is an 8‐bit field that represents the least significant byte of the one's complement of the sum of the values represented by the pairs of characters making up the record's length, address, and data fields.

### Record Types
S0

This type of record is the header record for each block of S‐Records. The data field may contain any descriptive information identifying the following block of S‐Records. (It is commonly “HDR[rq] on many systems.) The address field is normally zero.

S1

A record containing data and the 2‐byte address at which the data is to reside.

S2

A record containing data and the 3‐byte address at which the data is to reside.

S3

A record containing data and the 4‐byte address at which the data is to reside.

S5

An optional record containing the number of S1, S2 and S3 records transmitted in a particular block. The count appears in the two‐byte address field. There is no data field. This record is optional, you do not have to use it. Nobody knows if you can have more than one in a file; and if you do, nobody knows whether or not the line count resets after each one.

The srec_cat command will only ever use one, provided the number of lines fits in 16 bits, otherwise it will use S6.

S6

An optional record containing the number of S1, S2 and S3 records transmitted in a particular block. The count appears in the three‐byte address field. There is no data field. This record is optional, you do not have to use it. Nobody knows if you can have more than one in a file; and if you do, nobody knows whether or not the line count resets after each one.

Nobody knows what happens if you mix S5 and S6 records in a file.

The srec_cat command will only ever use one, provided the number of lines fits in 24 bits.

S7

A termination record for a block of S3 records. The address field may contain the 4‐byte address of the instruction to which control is passed. There is no data field.

S8

A termination record for a block of S2 records. The address field may optionally contain the 3‐byte address of the instruction to which control is passed. There is no data field.

S9

A termination record for a block of S1 records. The address field may optionally contain the 2‐byte address of the instruction to which control is passed. If not specified, the first entry point specification encountered in the object module input will be used. There is no data field.

### Size Multiplier
In general, binary data will expand in sized by approximately 2.4 times when represented with this format.

## EXAMPLE
Here is an example S‐Record file. It contains the data “Hello, World[rq] to be loaded at address 0.

```
S00600004844521B
S110000048656C6C6F2C20576F726C640A9D
S5030001FB
S9030000FC
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_msbin(5)

summary: Windows CE Binary Image Data Format

text:
# srec_msbin(5)

## NAME
srec_msbin - Windows CE Binary Image Data Format

## DESCRIPTION
This format is the output of the Microsoft WinCE Platform Builder. This is a binary (non‐text) file format. File names in this format typically (ambiguously) use the .bin suffix.

### File Format
Files in this format start with a header record.

Then comes the data itself, organized into records.

The file finishes with an execution start address record. This is mandatory.

### File Header Record
Data in this format start with an optional header containing the magic “B000FF\n”, followed by the image start (four bytes, little endian) address and the span of the image (highest address - lowest address + 1) (four bytes, little endian). The file header does not have a checksum; it is therefore possible that a corrupt file header will go undetected.

Magic “B000FF\n” (7 bytes)

Least Address (4 bytes)

Greatest Address (4 bytes)

There is no provision for a file comment of any kind.

### Data Record
Each record consists of a record start address (four bytes, little endian), a record length (four bytes, little endian), a record checksum (four bytes, little endian), followed by the record data. The data part of each record is raw byte values, no encoding.

Start address (4 bytes)

Length (4 bytes)

Checksum (4 bytes)

Data

The checksum is calculated by a simple sum of unsigned bytes into a 32‐bit accumulator.

The 12 record header bytes are not included in the record checksums; it is therefore possible that a corrupt record header will go undetected.

It is not possible to place data at address zero with this format. Address zero is reserved for use by the execution start address record.

There is effectively no limit on the length of a record (2^32-1). It is not uncommon for a MsBin file to contain records with sizes in the tens of megabytes.

### Execution Start Address Record
Last comes a special record with the record address set to zero and record length set to the image execution start address. According to specification the record describing the execution start address must be always present, and must always be the last record in the file.

Zero (4 bytes)

Start Address (4 bytes)

Checksum = 0 (4 bytes)

### Commentary
The MsBin files produced by SRecord are valid and can be successfully parsed by the command line utilities viewbin and cvrtbin (part of Windows CE platform).

For a MsBin file to be usable in Microsoft WinCE Platform Builder it has to contain a TOC meta‐structure. This is data embedded in the file by Microsoft WinCE Platform Builder itself.

The opposite conversion - from MsBin - comes in handy when analyzing a MsBin file (i.e. a WinCE image).

### Size Multiplier
In general, binary data will expand in sized by approximately 1.0 times (approaching asymptotically from above) when represented with this format, as the 15‐byte file header is averaged over the data content. Holes in the data will also increase the size.

## SOURCE
http://msdn.microsoft.com/en-us/library/ms924510.aspx

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_needham(5)

summary: Needham EMP\[hy]series programmer ASCII file format

text:
# srec_needham(5)

## NAME
srec_needham - Needham EMP‐series programmer ASCII file format

## DESCRIPTION
This format is understood by Needham Electronics' EMP‐series programmers. See www.needhams.com/winman.pdf for more information. (This format is very similar to the ASCII‐Hex format, but without the ^B and ^C guard characters.)

Each data byte is represented as 2 hexadecimal characters, and is separated by white space from all other data bytes.

The address for data bytes is set by using a sequence of $Annnn, characters, where nnnn is the 8‐character ascii representation of the address. The comma is required. There is no need for an address record unless there are gaps. Implicitly, the file starts a address 0 if no address is set before the first data byte.

### Size Multiplier
In general, binary data will expand in sized by approximately 3.0 times when represented with this format.

## EXAMPLE
Here is an example ascii‐hex file. It contains the data “Hello, World[rq] to be loaded at address 0x1000.

```
$A1000,
48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 0A
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_os65v(5)

summary: OS65V Loader file format

text:
# srec_os65v(5)

## NAME
srec_os65v - OS65V Loader file format

## DESCRIPTION
This format is used by Ohio Scientific OS65V‐compatible loaders. This family of machines includes the OSI C1P, Superboard II, C2, C4, C8, and Challenger III, as well as the UK101, and Elektor Junior.

The file startes with a period '.' (0x2E), to ensure address entry mode. then a 4‐digit hex address, followed by a slash '/' (0X2F) to enter the data entry mode. The initial address is always present. There is no need for an additional address record unless there are gaps.

Each data byte is represented as 2 hexadecimal characters, and is separated by a carriage return character (0x0D) (advance address). The final return character may be omitted.

The data is concluded with a period '.' (0x2E) to re‐enter address mode. If an address to start execution is specified, then the last 5 bytes are nnnnG where nnnn is the 4‐digit execution address, and G is the 'Go' command.

### Size Multiplier
In general, binary data will expand in sized by approximately 3.0 times when represented with this format.

## EXAMPLE
Here is an example ascii‐hex file. It contains the data “Hello, World[rq] to be loaded at address 0x1000, with execution at 0x1003. (On a 6502, this is the opcode for indirect jump to 0x2C6F.)

1000/48^M65^M6C^M6C^M6F^M2C^M20^M57^M6F^M72^M6C^M64^M0A^M.1010G

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_ppb(5)

summary: Stag Prom Programmer binary format

text:
# srec_ppb(5)

## NAME
srec_ppb - Stag Prom Programmer binary format

## DESCRIPTION
This is the native binary format of the Stag Prom Programmer.

### Format
The format is packet based. The packet is somposed of an 0x01 byte, the packet payload size (4 bytes, big‐endian), the packet address size (4 bytes, big‐endian), the packet data, and a one‐byte simple sum of the payload data.

If the packet payload is more than 1024 bytes, there is an intermediate checksum after each 1024th payload pyte.

The end of file is indicated by a packet with a zero‐length payload.

### Command Line Option
This format is specified using the -PPB command line option.

### Size Multiplier
In general, binary data will expand in sized by approximately 1.002 times when represented with this format (worse if there are many short data regions).

## SEE ALSO
http://www.stag.co.uk/

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_ppx(5)

summary: Stag Prom Programmer hexadecimal format

text:
# srec_ppx(5)

## NAME
srec_ppx - Stag Prom Programmer hexadecimal format

## DESCRIPTION
This is the native hexadecimal format of the Stag Prom Programmer.

### Format
The file must start with an asterisk '*' on a line by itself.

Each line has a 16‐bit address, followed by 8‐bit bytes.

The end is indicated by '$S' folloowed by a 16‐bit checksum of the data bytes as 4 hex digits.

### Command Line Option
This format is specified using the -PPX command line option.

### Size Multiplier
In general, binary data will expand in sized by approximately 3 times when represented with this format (worse if you use shorter lines).

## EXAMPLE
Here is an example PPX file. It contains the data “Hello, World” to be loaded at bytes address 0x0000 (but remember, the file contents are always multiples of four bytes).

```
*
0000 48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 21 0A $S0473
```

## SEE ALSO
http://matthieu.benoit.free.fr/pdf/pp39.pdf http://www.stag.co.uk/

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_signetics(5)

summary: Signetics file format

text:
# srec_signetics(5)

## NAME
srec_signetics - Signetics file format

## DESCRIPTION
The Signetics file format is not often used. The major disadvantage in modern applications is that the addressing range is limited to only 64kb.

### Records
All data lines are called records, and each record contains the following 5 fields:

:

aaaa

cc

as

dd

ss

The field are defined as follows:

:

Every record starts with this identifier.

aaaa

The address field. A four digit (2 byte) number representing the first address to be used by this record.

cc

The byte‐count. A two digit value (1 byte), counting the actual data bytes in the record.

as

Address checksum. Covers 2 address bytes and the byte count.

dd

The actual data of this record. There can be 1 to 255 data bytes per record (see cc)

ss

Data Checksum. Covers only all the data bytes of this record.

### Record Begin
Every record begins with a colon “:[rq] character. Records contain only ASCII characters. No spaces or tabs are allowed in a record. In fact, apart from the 1st colon, no other characters than 0..9 and A..F are allowed in a record. Interpretation of a record should be case less, it does not matter if you use a..f or A..F.

Unfortunately the colon was chosen for the Signetics file format, similar to the Intel format (see srec_intel(5) for more information). However, SRecord is able to automatically detect the dofference between the two format, when you use the -Guess format specifier.

### Address Field
This is the address where the first data byte of the record should be stored. After storing that data byte, the address is incremented by 1 to point to the address for the next data byte of the record. And so on, until all data bytes are stored. The address is represented by a 4 digit hex number (2 bytes), with the MSD first. The order of addresses in the records of a file is not important. The file may also contain address gaps, to skip a portion of unused memory.

### Byte Count
The byte count cc counts the actual data bytes in the current record. Usually records have 32 data bytes, but any number between 1 and 255 is possible.

A value of 0x00 for cc indicates the end of the file. In this case not even the address checksum will follow! The record (and file) are terminated immediately.

It is not recommended to send too many data bytes in a record for that may increase the transmission time in case of errors. Also avoid sending only a few data bytes per record, because the address overhead will be too heavy in comparison to the payload.

### Address Checksum
This is not really a checksum anymore, it looks more like a CRC. The checksum can not only detect errors in the values of the bytes, but also bytes out of order can be detected.

The checksum is calculated by this algorithm:

```
checksum = 0
for i = 1 to 3

  checksum = checkum XOR byte

  ROL checksum
next i
```

For the Address Checksum we only need 2 Address bytes and 1 Byte Count byte to be added. That's why we count to 3 in the loop. Every byte is XORed with the previous result. Then the intermediate result is rolled left (carry rolls back into b0). This results in a very reliable checksum, and that for only 3 bytes!

The last record of the file does not contain any checksums! So the file ends right after the Byte Count of 0.

### Data Field
The payload of the record is formed by the Data field. The number of data bytes expected is given by the Byte Count field. The last record of the file may not contain a Data field.

### Data Checksum
This checksum uses the same algorithm as used for the Address Checksum. This time we calculate the checksum with only the data bytes of this record.

```
checksum = 0
for i = 1 to cc

  checksum = checksum XOR byte

  ROL checksum
next i
```

Note that we count to the Byte Count cc this time.

### Size Multiplier
In general, binary data will expand in sized by approximately 2.4 times when represented with this format.

## EXAMPLE
Here is an example Signetics file

```
:B00010A5576F77212044696420796F75207265617B
:B01010E56C6C7920676F207468726F756768206136
:B02010256C6C20746861742074726F75626C652068
:B0300D5F746F207265616420746869733FD1
:B03D00
```

In the example above you can see a piece of code in Signetics format. The first 3 lines have 16 bytes of data each, which can be seen by the byte count. The 4th line has only 13 bytes, because the program is at it's end there. Notice that the last record of the file contains no data bytes, and not even an Address Checksum.

## SEE ALSO
http://sbprojects.fol.nl/knowledge/fileformats/signetics.htm

## AUTHOR
This man page was taken from the above Web page. It was written by San Bergmans <sanmail@bigfoot.com>


title: srec_spasm(5)

summary: SPASM file format

text:
# srec_spasm(5)

## NAME
srec_spasm - SPASM file format

## DESCRIPTION
This format is the output of the Paralax SPASM assembler (now defunct, I'm told). The file contains two columns of 16‐bit hexadecimal coded values. The first column is the word address, the second column is the word data.

By default, SRecord treats this is big‐endian data (the most significant byte first). If you want little endian order, use the -spasm‐le argument instead.

### Size Multiplier
In general, binary data will expand in sized by approximately 5.0 times when represented with this format (5.5 times in Windows).

## EXAMPLE
Here is an example SPASM file. It contains the data “Hello, World[rq] to be loaded at bytes address 0x0100 (but remember, the file contents are word addressed).

```
0080 6548
0081 6C6C
0082 2C6F
0083 5720
0084 726F
0085 646C
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_spectrum(5)

summary: Spectrum file format

text:
# srec_spectrum(5)

## NAME
srec_spectrum - Spectrum file format

## DESCRIPTION
In this format, bytes are recorded as ASCII code with binary digits represented by 1s and 0s. Each byte is preceded by a decimal address.

The file ends with a Control‐C character (0x03).

### Size Multiplier
In general, binary data will expand in sized by approximately 14 times when represented with this format (or 15 times on DOS or Windows).

## EXAMPLE
Here is an example Spectrum file. It contains the data “Hello, World[rq] to be loaded at address 0x0.

```
^B
0000 01001000
0001 01100101
0002 01101100
0003 01101100
0004 01101111
0005 00101100
0006 00100000
0007 01010111
0008 01101111
0009 01110010
0010 01101100
0011 01100100
0012 00100001
0013 00001010
^C
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_stewie(5)

summary: Stewie's binary file format

text:
# srec_stewie(5)

## NAME
srec_stewie - Stewie's binary file format

## DESCRIPTION
If you have a URL for documentation of this format, please let me know.

Any resemblance to the Motorola S‐Record is superficial, and extends only to the data records. The header records and termination records are completely different. None of the other Motorola S‐Records record type are available.

### The Records
All records start with an ASCII capital S character, value 0x53, followed by a type specifier byte. All records consist of binary bytes.

### The Header Record
Each file starts with a fixed four byte header record.

0x53

0x30

0x30

0x33

### The Data Records
Each data record consists of 5 fields. These are the type field, length field, address field, data field, and the checksum. The lines always start with a capital S character.

0x53

Type

Record Length

Address

Data

Checksum

Type

The type field is a one byte field that specifies whether the record has a two‐byte address field (0x31), a three‐byte address field (0x32) or a four‐byte address field (0x33). The address is big‐endian.

Record Length

The record length field is a one byte field that specifies the number of bytes in the record following this byte.

Address

This is a 2‐, 3‐ or 4‐byte address that specifies where the data in the record is to be loaded into memory.

Data

The data field contains the executable code, memory‐loadable data or descriptive information to be transferred.

Checksum

The checksum is a one byte field that represents the least significant byte of the one's complement of the sum of the values represented by the bytes making up the record's length, address, and data fields.

### The Termination Record
Each file ends with a fixed two byte termination record.

0x53

0x38

### Size Multiplier
In general, binary data will expand in sized by approximately 1.2 times when represented with this format.

## EXAMPLE
Here is an hex‐dump example file. It contains the data “Hello, World[rq] to be loaded at address 0.

```
0000: 53 30 30 33 53 31 10 00 00 48 65 6C 6C 6F 2C 20  S003S1...Hello,
0010: 57 6F 72 6C 64 0A 9D 53 38                       World..S8
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_tektronix(5)

summary: Tektronix hexadecimal file format

text:
# srec_tektronix(5)

## NAME
srec_tektronix - Tektronix hexadecimal file format

## DESCRIPTION
The Tektronix hexadecimal file format is no longer very common. It serves a similar purpose to the Motorola and Intel formats, usually used to transfer data into EPROM programmers.

### The Lines
Most Tektronix hex files contain only Tektronix hex lines (see the next section), which always start with a slash (“/[rq]) character. There are only two types of lines - data lines and a termination line.

### Data Lines
Data lines have five fields: address, length, checksum 1, data and checksum 2. The lines always start with a slash (“/[rq]) character.

/

Address

Length

Checksum1

Data

Checksum2

Address

This is a 4 character (2 byte) address that specifies where the data in the record is to be loaded into memory.

Data Length

The data length field is a 2 character (1 byte) field that specifies the number of character pairs (bytes) in the data field. This field never has a value of zero.

Checksum 1

The checksum 1 field is a 2 character (1 byte) field. Its value is the 8‐bit sum of the six 4‐bit values which make up the address and length fields.

Data

The data field contains character pairs (bytes); the number of character pairs (bytes) is indicated by the length field.

Checksum 2

The checksum 2 field is a 2 character (1 byte) field. Its value is the least significant byte of the sum of the all the 4‐bit values of the data field.

### Termination Line
Termination lines have three fields: address, zero and checksum. The lines always start with a slash (“/[rq]) character.

/

Address

Zero

Checksum

Address

This is a 4 character (2 byte) address that specifies where to begin execution.

Zero

The data length field is a 2 character (1 byte) field of value zero.

Checksum

The checksum 1 field is a 2 character (1 byte) field. Its value is the 8‐bit sum of the six 4‐bit values which make up the address and zero fields.

### Size Multiplier
In general, binary data will expand in sized by approximately 2.4 times when represented with this format.

## EXAMPLE
Here is an example Tektronix hex file. It contains the data “Hello, World[rq] to be loaded at address 0.

```
/00000D0D48656C6C6F2C20576F726C640A52
/00000000
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_tektronix_extended(5)

text:
# srec_tektronix_extended(5)

## NAME
srec_tektronix_extended - Tektronix Extended hexadecimal file format

## DESCRIPTION
This format allows binary files to be uploaded and downloaded between two computer systems, typically between a computer system (such as a PC, Macintosh, or workstation) and an emulator or evaluation board for microcontrollers and microprocessors.

### The Lines
Lines always start with a percent (%) character. Each line consists of 5 fields. These are the length field, the type field, the checksum, the address field (including address length), and the data field.

### The Fields
%

Length

Type

Checksum

Address

Data

Record Length

The record length field is a 2 character (1 byte) field that specifies the number of characters (not bytes) in the record, excluding the percent.

Type

The type field is a 1 character field that specifies whether the record is data (6) or termination (8).

Checksum

The checksum is an 2 character (1 byte) field that represents the sum of all the nibbles on the line, excluding the checksum.

Address

This is a 9 character field. The first character is the address size; it is always 8. The remaining 8 chgaracters are the 4‐byte address that specifies where the data is to be loaded into memory.

Data

The data field contains the executable code, memory‐loadable data or descriptive information to be transferred.

### Record Types
6

A record containing data. The data is placed at the address specified.

8

A termination record. The address field may optionally contain the address of the instruction to which control is passed. There is no data field.

### Size Multiplier
In general, binary data will expand in sized by approximately 2.5 times when represented with this format.

## EXAMPLE
Here is an example Tektronix extended file. It contains the data “Hello, World” to be loaded at address 0x006B.

```
%256D980000006B48656C6C6F2C20576F726C64210A
%09819800000000
```

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_ti_tagged(5)

text:
# srec_ti_tagged(5)

## NAME
srec_ti_tagged - Texas Instruments Tagged (SDSMAC) file format

## DESCRIPTION
This format is also known as the TI‐Tagged or TI‐SDSMAC format.

This format allows binary files to be uploaded and downloaded between two computer systems, typically between a computer system (such as a PC, Macintosh, or workstation) and an emulator or evaluation board for microcontrollers and microprocessors.

### The Lines
Unlike many other object formats, the lines themselves are not especially significant. The format consits of a number of tagged fields, and lines are composed of a series of these fields.

Tag

Description

*

Data byte.

:

End of file.

0

File header (optional).

7

Checksum.

8

Dummy checksum (ignored).

9

Address.

B

Data word.

F

End of data record.

K

Program identifier (optional).

### Data Byte
B

n

n

One byte of data. The nn is 8‐bit big‐endian hexadecimal.

### End of File
:

CRLF

The end of data is indicated by this tag. The end of line sequence (LF on Unix systems, CRLF on PCs) follows this tag.

### File Header
0

length

filename

The optional start‐of‐file record begins with a tag character ('0') and a 12‐character file header. The first four characters are the byte count of the file data. The remaining 8 characters are the name of the file and may be any ASCII characters, blank padded.

### Checksum
7

n

n

n

n

The checksum is the 2s complement sum of the 8‐bit ASCII values of characters, beginning with the first tag character and ending with the checksum tag character (7). The nnnn is 16‐bit big‐endian hexadecimal.

### Dummy Checksum
8

n

n

n

n

The checksum is the 2s complement sum of the 8‐bit ASCII values of characters, beginning with the first tag character and ending with the checksum tag character (8). The nnnn is 16‐bit big‐endian hexadecimal.

### Address
9

n

n

n

n

Addresses may be given for any data byte, but none is mandatory. The file begins at 0000 if no address is given before the first data field. The nnnn is 16‐bit big‐endian hexadecimal.

### Data Word
B

a

a

b

b

Two bytes of data. The aa and bb are each 8‐bit big‐endian hexadecimal.

### End of Record
F

CRLF

The end of line sequence (LF on Unix systems, CRLF on PCs) is escaped using this tag. The checksum is reset to zero at this point.

### Program Identifier
K

n

n

n

n

text

The program identifier can contain a brief description of the program, or can be empty (i.e. the text portion is optional). The nnnn length (hex) of the field includes the `K', the length and the text; it is at least 5.

### Size Multiplier
In general, binary data will expand in sized by approximately 2.9 times when represented with this format.

## EXAMPLE
Here is an example TI‐Tagged file. It contains the data “Hello, World[rq] to be loaded at address 0x0100.

```
K000590080B4865B6C6CB6F2CB2057B6F72B6C64*0A7F648F
:
```

and here is another example from the reference below

```
00050        7FDD4F
90000BFFFFBFFFFBFFFFBFFFFBFFFFBFFFFBFFFFBFFFF7F400F
90010BFFFFBFFFFBFFFFBFFFFBFFFFBFFFFBFFFFBFFFF7F3FFF
90020BFFFFBFFFFBFFFFBFFFFBFFFFBFFFFBFFFFBFFFF7F3FEF
90030BFFFFBFFFFBFFFFBFFFFBFFFFBFFFFBFFFFBFFFF7F3FDF
90040BFFFFBFFFFBFFFFBFFFFBFFFFBFFFFBFFFFBFFFF7F3FCF
:
```

## SEE ALSO
http://www.dataio.com/pdf/Manuals/Unifamily/981‐0014‐016.pdf (page 6‐33)

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_ti_tagged_16(5)

text:
# srec_ti_tagged_16(5)

## NAME
srec_ti_tagged_16 - Texas Instruments Tagged (SDSMAC 320) file format

## DESCRIPTION
This format is also known as the TI‐Tagged or Texas Instruments SDSMAC (320) format.

This format allows binary files to be uploaded and downloaded between two computer systems, typically between a computer system (such as a PC, Macintosh, or workstation) and an emulator or evaluation board for 16‐bit microcontrollers and microprocessors.

### The Lines
Unlike many other object formats, the lines themselves are not especially significant. The format consits of a number of tagged fields, and lines are composed of a series of these fields.

Tag

Description

*

Data byte.

:

End of file.

0

File header (optional).

7

Checksum.

8

Dummy checksum (ignored).

9

Word Address.

B

Data word.

F

End of data record.

K

Program identifier (optional).

### Data Byte
B

n

n

One byte of data. The nn is 8‐bit big‐endian hexadecimal.

### End of File
:

CRLF

The end of data is indicated by this tag. The end of line sequence (LF on Unix systems, CRLF on PCs) follows this tag.

### File Header
0

length

filename

The optional start‐of‐file record begins with a tag character ('0') and a 12‐character file header. The first four characters are the count (in hex) of the 16‐bit data word values (B) which follow, not including data byte values (*). The remaining file header characters are the name of the file and may be any ASCII characters, blank padded.

### Checksum
7

n

n

n

n

The checksum is the 2s complement sum of the 8‐bit ASCII values of characters, beginning with the first tag character and ending with the checksum tag character (7). The nnnn is 16‐bit big‐endian hexadecimal.

### Dummy Checksum
8

n

n

n

n

The checksum is the 2s complement sum of the 8‐bit ASCII values of characters, beginning with the first tag character and ending with the checksum tag character (8). The nnnn is 16‐bit big‐endian hexadecimal.

### Address
9

n

n

n

n

Addresses may be given for any data byte, but none is mandatory. The file begins at 0000 if no address is given before the first data field. The nnnn is 16‐bit big‐endian hexadecimal.

### Data Word
B

a

a

b

b

Two bytes of data. The aa and bb are each 8‐bit big‐endian hexadecimal.

### End of Record
F

CRLF

The end of line sequence (LF on Unix systems, CRLF on PCs) is escaped using this tag. The checksum is reset to zero at this point.

### Program Identifier
K

n

n

n

n

text

The program identifier can contain a brief description of the program, or can be empty (i.e. the text portion is optional). The nnnn length (hex) of the field includes the `K', the length and the text; it is at least 5.

### Size Multiplier
In general, binary data will expand in sized by approximately 2.9 times when represented with this format.

## EXAMPLE
Here is an example TI‐Tagged file. It contains the data “Hello, World[rq] to be loaded at address 0x0100.

```
K000590080B4865B6C6CB6F2CB2057B6F72B6C64*0A7F641F
:
```

Here is another example from the reference below

```
00028        7FDCFF
90000BFFFFBFFFFBFFFFBFFFFBFFFFBFFFFBFFFFBFFFF7F400F
90008BFFFFBFFFFBFFFFBFFFFBFFFFBFFFFBFFFFBFFFF7F3F8F
90010BFFFFBFFFFBFFFFBFFFFBFFFFBFFFFBFFFFBFFFF7F3FFF
90018BFFFFBFFFFBFFFFBFFFFBFFFFBFFFFBFFFFBFFFF7F3F7F
90020BFFFFBFFFFBFFFFBFFFFBFFFFBFFFFBFFFFBFFFF7F3FEF
:
```

## SEE ALSO
http://www.dataio.com/pdf/Manuals/Unifamily/981‐0014‐016.pdf (page 6‐7)

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_ti_txt(5)

summary: Texas Instruments ti\[hy]txt (MSP430) file format

text:
# srec_ti_txt(5)

## NAME
srec_ti_txt - Texas Instruments ti‐txt (MSP430) file format

## DESCRIPTION
The ti‐TXT format is used by the Texas Instruments MSP430 familty programming adapter.

The TI‐TXT hex format supports 16‐bit hexadecimal data. It consists of one or more sections, followed by the end‐of‐file indicator.

Each section consistes of an at (@) sign followed a execution start address (in hexadecimal), and newline, and then data bytes (in hexadecimal). The section address is followed by a newline. There are to be 16 data bytes per line, except for the last line in a section.

The end‐of‐file indicator is the letter q followed by a newline. The end‐of‐file indicator mandatory.

### Size Multiplier
In general, binary data will expand in sized by approximately 3.0 times when represented with this format.

## EXAMPLE
Here is an example ti‐txt file taken from the reference below:

```
@F000
31 40 00 03 B2 40 80 5A 20 01 D2 D3 22 00 D2 E3
21 00 3F 40 E8 FD 1F 83 FE 23 F9 3F
@FFFE
00 F0
q
```

## SEE ALSO
http://www.ti.com/lit/pdf/slau101, section A.2. Note: the portion which says addresses must be even, and the number of data bytes in a section must be even, is wrong.

## COPYRIGHT
srec_ti_txt version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_ti_txt program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_ti_txt -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_ti_txt -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_trs80(5)

summary: Radio Shack TRS\[hy]80 object file format specification

text:
# srec_trs80(5)

## NAME
srec_trs80 - Radio Shack TRS‐80 object file format specification

## DESCRIPTION
This document describes the binary object file format for the Z80‐based Radio Shack TRS‐80 microcomputers, such as the Model I, II, III, 4, 4D, and 4P. The binary format is generated by the disk‐based Assembler/Editor, and used for TRS‐DOS program files.

The object file is blocked into records, each of which contains the record type, length, and payload data. For Data and End of File records, the payload starts with two bytes of address in little‐endian format. There are four main types of records that are defined. The record types are:

•

Data Record

•

End of File Record with Execution Transfer

•

End of File Record without Execution Transfer

•

Comment

•

Start Linear Address Record (32‐bit format only)

### General Record Format
Record Type

Record Length

Load Address

Data

Record Type.

Each record begins with a single byte Record Type field which specifies the record type of this record. The Record Type field is used to interpret the remaining information within the record. This field is one byte, represented as two hexadecimal characters. The encoding for all the current record types are: 1

Data Record

2

End of File Record with Execution Transfer

3

End of File Record without Execution Transfer

5

Comment Record

Record Length

Each record has a single byte Record Length field which specifies the number of bytes of information or data which follows the Record Length field of the record. The maximum value of the Record Length field is hexadecimal “FF” or 255. In the case of Data Records only, Record Length byte values of zero to two are considered to be lengths of 256 to 258, respectively.

Address

Data and End records have a two‐byte Address field in little‐endian byte order. For Data records, this is the starting address at which to load the remaining payload of the record. In End records, this is the address for the start of execution of the file, or zero if not applicable.

Data

Each record has a variable length Data field, it consists of zero or more bytes. The interpretation of this field depends on the Record Type field.

## REFERENCE
This information comes from the "Program Files" section of TRSDOS‐II Reference Manual, Tandy Corporation, 1982.

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_vmem(5)

summary: vmem file format

text:
# srec_vmem(5)

## NAME
srec_vmem - vmem file format

## DESCRIPTION
This format is the Verilog VMEM format. This is a hex format suitable for loading into Verilog simulations using the $readmemh call.

The text file to be read shall contain only the following:

White space (spaces, new lines, tabs, and form‐feeds)

Comments (both types of C++ comment are allowed)

Hexadecimal numbers

White space and/or comments shall be used to separate the numbers.

In the following discussion, the term "address" refers to an index into the array that models the memory.

As the file is read, each number encountered is assigned to a successive word element of the memory. Addressing is controlled both by specifying start and/or finish addresses in the system task invocation and by specifying addresses in the data file.

When addresses appear in the data file, the format is an "at" character (@) followed by a hexadecimal number as follows:

```
@hh...h
```

Both uppercase and lowercase digits are allowed in the number. No white space is allowed between the @ and the number. As many address specifications as needed within the data file can be used. When the system task encounters an address specification, it loads subsequent data starting at that memory address.

### Commentary
There is no checksum in this format, which can generate false positives when guessing file formats on input.

There is no indication of the word size in the file, since it is dependent on the word type of the Verilog memory it is being read into. SRecord will guess the word size based on the number of digits it sees in the numbers, but this is only a guess.

SRecord will also assume that the numbers are to be loaded big‐endian; that is, most significant byte (first byte seen) into the lowest address covered by the word.

You can use the -byte‐swap filter to change the byte order; it takes an optional width of bytes to swap within.

### Size Multiplier
In general, binary data will expand in sized by approximately 2.9 times (32‐bit), 3.1 times (16‐bit) or 3.6 times (8‐bit) when represented with this format.

## EXAMPLE
Here is an example Verilog VMEM file. It contains the data “Hello, World[rq] to be loaded at address 0x1000.

```
@00000400 48656C6C 6F2C2057 6F726C64 0AFFFFFF
```

## REFERENCE
IEEE P1364‐2005/D2, Standard for Verilog Hardware Description Language (Draft), section 17.2.8 "Loading memory data from a file", p. 295.

Copyright © 2003 IEEE

http://www.boyd.com/1364/

http://www.boyd.com/1364/1364‐2005‐d2.pdf.gz

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srec_wilson(5)

summary: wilson file format

text:
# srec_wilson(5)

## NAME
srec_wilson - wilson file format

## DESCRIPTION
This is a mystery format, added to support a mysery EPROM loader used by Alan Wilson <dvdsales@dvdlibrary.co.uk>

If you know the true name of this format, please let me know! It bears a remarkable similarity to the Motorola S‐Record format, however I can find no reference to a "compressed" Motorola format.

### The Lines
Each line contains normal ASCII characters, and “high bit on[rq] characters, but the ASCII control characters are avoided (the high‐bit‐on con characters are not avoided). Normal line termination characters (CRLF or LF, depending on your system) are used.

The presence of high‐bit‐on characters makes this format unattractive to send via email, as it must be wrapped as a binary attachment, increasing its size.

In general, a single byte per byte is used to encode values, however some values use two bytes, according to the following table:

Byte Value

Encoding (1 or 2 chars)

0x00 .. 0x9F

0x40 .. 0xDF

0xA0 .. 0xAF

0x3A 0x30 .. 0x3A 0x3F

0xB0 .. 0xBF

0x3B 0x30 .. 0x3B 0x3F

0xC0 .. 0xCF

0x3C 0x30 .. 0x3C 0x3F

0xD0 .. 0xDF

0x3D 0x30 .. 0x3D 0x3F

oxE0 .. 0xFF

0xE0 .. 0xFF

The rest of this description, when refering to “bytes[rq] means byte values encoded using the above table.

### The Fields
Each line consists of 5 fields. These are the type field, length field, address field, data field, and the checksum.

Type

Record Length

Address

Data

Checksum

Type

The type field is a 1 character field that specifies whether the record is data (0x43), or termination (0x47).

Record Length

The record length field is a 1 byte field that specifies the number of bytes in the record, excluding the type and record length fields.

Address

This is a 4‐byte address that specifies where the data is to be loaded into memory.

Data

The data field contains the executable code, memory‐loadable data or descriptive information to be transferred.

Checksum

The checksum is an 1‐byte field that represents the least significant byte of the one's complement of the sum of the values represented by the bytes making up the length, address, and data fields.

### Record Types
0x43 (#)

A record containing data and the 4‐byte address at which the data is to reside.

0x47 (')

A termination record. The address field may contain the 4‐byte address of the instruction to which control is passed. There is no data field.

### Size Multiplier
In general, binary data will expand in sized by approximately 1.5 times when represented with this format.

## COPYRIGHT
srec_cat version 1.64

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Peter Miller

The srec_cat program comes with ABSOLUTELY NO WARRANTY; for details use the 'srec_cat -VERSion License' command. This is free software and you are welcome to redistribute it under certain conditions; for details use the 'srec_cat -VERSion License' command.

## MAINTAINER
Scott Finneran

E‐Mail:

scottfinneran@yahoo.com.au

Peter Miller

E‐Mail:

pmiller@opensource.org.au


title: srp_daemon.service(5)

text:
# srp_daemon.service(5)

## NAME
srp_daemon.service - srp_daemon systemd service that controls all ports

## SYNOPSIS
srp_daemon.service

## DESCRIPTION
The srp_daemon.service controls whether or not any srp_daemon processes are running. Although no srp_daemon processes are controlled directly by the srp_daemon.service, this service controls whether or not any srp_daemon_port@.service are allowed to be active. Each srp_daemon_port@.service controls one srp_daemon process.

## SEE ALSO
srp_daemon(1), srp_daemon_port@.service(5), systemctl(1)


title: srp_daemon_port@.service(5)

text:
# srp_daemon_port@.service(5)

## NAME
srp_daemon_port@.service - srp_daemon_port@ systemd service that controls a single port

## SYNOPSIS
srp_daemon_port@.service

## DESCRIPTION
The srp_daemon_port@.service controls whether or not an srp_daemon process is monitoring the RDMA port specified as template argument. The format for the RDMA port name is dev:port where dev is the name of an RDMA device and port is an port number starting from one. Starting an instance of this template will start an srp_daemon process. Stopping an instance of this template will stop the srp_daemon process for the specified port. It can be prevented that srp_daemon is started for a certain port by masking the corresponding systemd service, e.g. systemctl mask srp_daemon_port@mlx4_0:1.

A list of all RDMA device and port number pairs can be obtained e.g. as follows:

```
$ (cd /sys/class/infiniband >&/dev/null && for p in */ports/*; do

   [ -e "$p" ] && echo "${p/\/ports\//:}"; done)
mlx4_0:1
mlx4_0:2
mlx4_1:1
mlx4_1:2
```

```

```

## SEE ALSO
srp_daemon(1), srp_daemon.service(5), systemctl(1)


package: sssd

title: sss_rpcidmapd(5)

text:
# sss_rpcidmapd(5)

## NAME
sss_rpcidmapd - sss plugin configuration directives for rpc.idmapd

## CONFIGURATION FILE
rpc.idmapd configuration file is usually found at /etc/idmapd.conf. See idmapd.conf(5) for more information.

## SSS CONFIGURATION EXTENSION

### Enable SSS plugin
In section “[Translation]”, modify/set “Method” attribute to contain sss.

### [sss] config section
In order to change the default of one of the configuration attributes of the sss plugin listed below you will need to create a config section for it, named “[sss]”.

Configuration attributes

memcache (bool)

Indicates whether or not to use memcache optimisation technique. Default: True

## SSSD INTEGRATION
The sss plugin requires the NSS Responder to be enabled in sssd.

The attribute “use_fully_qualified_names” must be enabled on all domains (NFSv4 clients expect a fully qualified name to be sent on the wire).

## EXAMPLE
The following example shows a minimal idmapd.conf which makes use of the sss plugin.

```
[General]
Verbosity = 2
# domain must be synced between NFSv4 server and clients
# Solaris/Illumos/AIX use "localdomain" as default!
Domain = default
[Mapping]
Nobody-User = nfsnobody
Nobody-Group = nfsnobody
[Translation]
Method = sss
```

## SEE ALSO
sssd(8), idmapd.conf(5)

## AUTHORS
Noam Meltzer

Primary Data Inc.

Developer (2013-2014)

Noam Meltzer <tsnoam@gmail.com>

Developer (2014-)


sssd-session-recording

title: sssd-session-recording(5)

summary: Configuring session recording with SSSD

text:
# sssd-session-recording(5)

## NAME
sssd-session-recording - Configuring session recording with SSSD

## DESCRIPTION
This manual page describes how to configure sssd(8) to work with tlog-rec-session(8), a part of tlog package, to implement user session recording on text terminals. For a detailed configuration syntax reference, refer to the “FILE FORMAT” section of the sssd.conf(5) manual page.

SSSD can be set up to enable recording of everything specific users see or type during their sessions on text terminals. E.g. when users log in on the console, or via SSH. SSSD itself doesn't record anything, but makes sure tlog-rec-session is started upon user login, so it can record according to its configuration.

For users with session recording enabled, SSSD replaces the user shell with tlog-rec-session in NSS responses, and adds a variable specifying the original shell to the user environment, upon PAM session setup. This way tlog-rec-session can be started in place of the user shell, and know which actual shell to start, once it set up the recording.

## CONFIGURATION OPTIONS
These options can be used to configure the session recording.

scope (string)

One of the following strings specifying the scope of session recording: "none"

No users are recorded.

"some"

Users/groups specified by users and groups options are recorded.

"all"

All users are recorded.

Default: "none"

users (string)

A comma-separated list of users which should have session recording enabled. Matches user names as returned by NSS. I.e. after the possible space replacement, case changes, etc. Default: Empty. Matches no users.

groups (string)

A comma-separated list of groups, members of which should have session recording enabled. Matches group names as returned by NSS. I.e. after the possible space replacement, case changes, etc. NOTE: using this option (having it set to anything) has a considerable performance cost, because each uncached request for a user requires retrieving and matching the groups the user is member of.

Default: Empty. Matches no groups.

exclude_users (string)

A comma-separated list of users to be excluded from recording, only applicable with 'scope=all'. Default: Empty. No users excluded.

exclude_groups (string)

A comma-separated list of groups, members of which should be excluded from recording. Only applicable with 'scope=all'. NOTE: using this option (having it set to anything) has a considerable performance cost, because each uncached request for a user requires retrieving and matching the groups the user is member of.

Default: Empty. No groups excluded.

## EXAMPLE
The following snippet of sssd.conf enables session recording for users "contractor1" and "contractor2", and group "students".

```
[session_recording]
scope = some
users = contractor1, contractor2
groups = students
```

## SEE ALSO
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-idp(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(1), sss_ssh_knownhosts(1), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5)

## AUTHORS
The SSSD upstream - https://github.com/SSSD/sssd/


sssd-simple

title: sssd-simple(5)

summary: the configuration file for SSSD\*(Aqs \*(Aqsimple\*(Aq access\-control provider

text:
# sssd-simple(5)

## NAME
sssd-simple - the configuration file for SSSD's 'simple' access-control provider

## DESCRIPTION
This manual page describes the configuration of the simple access-control provider for sssd(8). For a detailed syntax reference, refer to the “FILE FORMAT” section of the sssd.conf(5) manual page.

The simple access provider grants or denies access based on an access or deny list of user or group names.

Groups from other domains configured in sssd.conf, even if the simple access provider is used there as well, and groups managed outside of SSSD are not evaluated.

The following rules apply:

•It is not recommended to leave an option empty, it might cause errors. If you want to allow all users, do not specify any `simple_allow_users` or `simple_allow_groups`.

•If any list is provided, the order of evaluation is: allow → deny. This means that any matching deny rule will supersede any matched allow rule.

•If either or both "allow" lists are provided, all users are denied unless they appear in at least one of these lists (OR condition).

•If either or both "deny" lists are provided, all users are granted access unless they appear in at least one of these lists (OR condition).

## CONFIGURATION OPTIONS
Refer to the section “DOMAIN SECTIONS” of the sssd.conf(5) manual page for details on the configuration of an SSSD domain.

simple_allow_users (string)

Comma-separated list of users who are allowed to log in. If this option is specified, all other users are denied unless they are members of groups listed in`simple_allow_groups`.

simple_deny_users (string)

Comma-separated list of users who are explicitly denied access. If this option is specified, these users will be denied regardless of whether they appear in `simple_allow_users` or `simple_allow_groups`. OR Logic Applies: A user will be denied access if they are listed in `simple_deny_users` or if they are a member of a group in `simple_deny_groups`.

simple_allow_groups (string)

Comma-separated list of groups that are allowed to log in. If this option is specified, all other users are denied unless they are explicitly listed in `simple_allow_users`. OR Logic Applies: A user can log in if they are listed in `simple_allow_users` or if they belong to a group in `simple_allow_groups`.

This applies only to groups within this SSSD domain. Local groups are not evaluated.

simple_deny_groups (string)

Comma-separated list of groups that are explicitly denied access. This applies only to groups within this SSSD domain. Local groups are not evaluated. OR Logic Applies: A user will be denied access if they are listed in `simple_deny_users` or if they are a member of any group in `simple_deny_groups`.

This applies only to groups within this SSSD domain. Local groups are not evaluated.

Specifying no values for any of the lists is equivalent to skipping it entirely. Beware of this while generating parameters for the simple provider using automated scripts.

## EXAMPLE
The following example assumes that SSSD is correctly configured and example.com is one of the domains in the [sssd] section. This example shows only the simple access provider-specific options.

```
[domain/example.com]
access_provider = simple
simple_allow_users = user1, user2
simple_deny_users = user3, user4
simple_allow_groups = allowed_group1
simple_deny_groups = denied_group1
```

## NOTES
The complete group membership hierarchy is resolved before the access check, thus even nested groups can be included in the access lists. Please be aware that the “ldap_group_nesting_level” option may impact the results and should be set to a sufficient value. (sssd-ldap(5)) option.

## SEE ALSO
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-idp(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(1), sss_ssh_knownhosts(1), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5)

## AUTHORS
The SSSD upstream - https://github.com/SSSD/sssd/


sssd-sudo

title: sssd-sudo(5)

summary: Configuring sudo with the SSSD back end

text:
# sssd-sudo(5)

## NAME
sssd-sudo - Configuring sudo with the SSSD back end

## DESCRIPTION
This manual page describes how to configure sudo(8) to work with sssd(8) and how SSSD caches sudo rules.

## CONFIGURING SUDO TO COOPERATE WITH SSSD
To enable SSSD as a source for sudo rules, add sss to the sudoers entry in nsswitch.conf(5).

For example, to configure sudo to first lookup rules in the standard sudoers(5) file (which should contain rules that apply to local users) and then in SSSD, the nsswitch.conf file should contain the following line:

```
sudoers: files sss
```

More information about configuring the sudoers search order from the nsswitch.conf file as well as information about the LDAP schema that is used to store sudo rules in the directory can be found in sudoers.ldap(5).

Note: in order to use netgroups or IPA hostgroups in sudo rules, you also need to correctly set nisdomainname(1) to your NIS domain name (which equals to IPA domain name when using hostgroups).

## CONFIGURING SSSD TO FETCH SUDO RULES
All configuration that is needed on SSSD side is to extend the list of services with "sudo" in [sssd] section of sssd.conf(5). To speed up the LDAP lookups, you can also set search base for sudo rules using ldap_sudo_search_base option.

The following example shows how to configure SSSD to download sudo rules from an LDAP server.

```
[sssd]
services = nss, pam, sudo
domains = EXAMPLE
[domain/EXAMPLE]
id_provider = ldap
sudo_provider = ldap
ldap_uri = ldap://example.com
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
```

It's important to note that on platforms where systemd is supported there's no need to add the "sudo" provider to the list of services, as it became optional. However, sssd-sudo.socket must be enabled instead.

When SSSD is configured to use IPA as the ID provider, the sudo provider is automatically enabled. The sudo search base is configured to use the IPA native LDAP tree (cn=sudo,$SUFFIX). If any other search base is defined in sssd.conf, this value will be used instead. The compat tree (ou=sudoers,$SUFFIX) is no longer required for IPA sudo functionality.

## THE SUDO RULE CACHING MECHANISM
The biggest challenge, when developing sudo support in SSSD, was to ensure that running sudo with SSSD as the data source provides the same user experience and is as fast as sudo but keeps providing the most current set of rules as possible. To satisfy these requirements, SSSD uses three kinds of updates. They are referred to as full refresh, smart refresh and rules refresh.

The smart refresh periodically downloads rules that are new or were modified after the last update. Its primary goal is to keep the database growing by fetching only small increments that do not generate large amounts of network traffic.

The full refresh simply deletes all sudo rules stored in the cache and replaces them with all rules that are stored on the server. This is used to keep the cache consistent by removing every rule which was deleted from the server. However, full refresh may produce a lot of traffic and thus it should be run only occasionally depending on the size and stability of the sudo rules.

The rules refresh ensures that we do not grant the user more permission than defined. It is triggered each time the user runs sudo. Rules refresh will find all rules that apply to this user, check their expiration time and redownload them if expired. In the case that any of these rules are missing on the server, the SSSD will do an out of band full refresh because more rules (that apply to other users) may have been deleted.

If enabled, SSSD will store only rules that can be applied to this machine. This means rules that contain one of the following values in sudoHost attribute:

•keyword ALL

•wildcard

•netgroup (in the form "+netgroup")

•hostname or fully qualified domain name of this machine

•one of the IP addresses of this machine

•one of the IP addresses of the network (in the form "address/mask")

There are many configuration options that can be used to adjust the behavior. Please refer to "ldap_sudo_*" in sssd-ldap(5) and "sudo_*" in sssd.conf(5).

## TUNING THE PERFORMANCE
SSSD uses different kinds of mechanisms with more or less complex LDAP filters to keep the cached sudo rules up to date. The default configuration is set to values that should satisfy most of our users, but the following paragraphs contain few tips on how to fine- tune the configuration to your requirements.

1. Index LDAP attributes. Make sure that following LDAP attributes are indexed: objectClass, cn, entryUSN or modifyTimestamp.

2. Set ldap_sudo_search_base. Set the search base to the container that holds the sudo rules to limit the scope of the lookup.

3. Set full and smart refresh interval. If your sudo rules do not change often and you do not require quick update of cached rules on your clients, you may consider increasing the ldap_sudo_full_refresh_interval and ldap_sudo_smart_refresh_interval. You may also consider disabling the smart refresh by setting ldap_sudo_smart_refresh_interval = 0.

4. If you have large number of clients, you may consider increasing the value of ldap_sudo_random_offset to distribute the load on the server better.

## SEE ALSO
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-idp(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(1), sss_ssh_knownhosts(1), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5)

## AUTHORS
The SSSD upstream - https://github.com/SSSD/sssd/