213 lines · plain
1==========================================2Reed-Solomon Library Programming Interface3==========================================4 5:Author: Thomas Gleixner6 7Introduction8============9 10The generic Reed-Solomon Library provides encoding, decoding and error11correction functions.12 13Reed-Solomon codes are used in communication and storage applications to14ensure data integrity.15 16This documentation is provided for developers who want to utilize the17functions provided by the library.18 19Known Bugs And Assumptions20==========================21 22None.23 24Usage25=====26 27This chapter provides examples of how to use the library.28 29Initializing30------------31 32The init function init_rs returns a pointer to an rs decoder structure,33which holds the necessary information for encoding, decoding and error34correction with the given polynomial. It either uses an existing35matching decoder or creates a new one. On creation all the lookup tables36for fast en/decoding are created. The function may take a while, so make37sure not to call it in critical code paths.38 39::40 41 /* the Reed Solomon control structure */42 static struct rs_control *rs_decoder;43 44 /* Symbolsize is 10 (bits)45 * Primitive polynomial is x^10+x^3+146 * first consecutive root is 047 * primitive element to generate roots = 148 * generator polynomial degree (number of roots) = 649 */50 rs_decoder = init_rs (10, 0x409, 0, 1, 6);51 52 53Encoding54--------55 56The encoder calculates the Reed-Solomon code over the given data length57and stores the result in the parity buffer. Note that the parity buffer58must be initialized before calling the encoder.59 60The expanded data can be inverted on the fly by providing a non-zero61inversion mask. The expanded data is XOR'ed with the mask. This is used62e.g. for FLASH ECC, where the all 0xFF is inverted to an all 0x00. The63Reed-Solomon code for all 0x00 is all 0x00. The code is inverted before64storing to FLASH so it is 0xFF too. This prevents that reading from an65erased FLASH results in ECC errors.66 67The databytes are expanded to the given symbol size on the fly. There is68no support for encoding continuous bitstreams with a symbol size != 8 at69the moment. If it is necessary it should be not a big deal to implement70such functionality.71 72::73 74 /* Parity buffer. Size = number of roots */75 uint16_t par[6];76 /* Initialize the parity buffer */77 memset(par, 0, sizeof(par));78 /* Encode 512 byte in data8. Store parity in buffer par */79 encode_rs8 (rs_decoder, data8, 512, par, 0);80 81 82Decoding83--------84 85The decoder calculates the syndrome over the given data length and the86received parity symbols and corrects errors in the data.87 88If a syndrome is available from a hardware decoder then the syndrome89calculation is skipped.90 91The correction of the data buffer can be suppressed by providing a92correction pattern buffer and an error location buffer to the decoder.93The decoder stores the calculated error location and the correction94bitmask in the given buffers. This is useful for hardware decoders which95use a weird bit ordering scheme.96 97The databytes are expanded to the given symbol size on the fly. There is98no support for decoding continuous bitstreams with a symbolsize != 8 at99the moment. If it is necessary it should be not a big deal to implement100such functionality.101 102Decoding with syndrome calculation, direct data correction103~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~104 105::106 107 /* Parity buffer. Size = number of roots */108 uint16_t par[6];109 uint8_t data[512];110 int numerr;111 /* Receive data */112 .....113 /* Receive parity */114 .....115 /* Decode 512 byte in data8.*/116 numerr = decode_rs8 (rs_decoder, data8, par, 512, NULL, 0, NULL, 0, NULL);117 118 119Decoding with syndrome given by hardware decoder, direct data correction120~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~121 122::123 124 /* Parity buffer. Size = number of roots */125 uint16_t par[6], syn[6];126 uint8_t data[512];127 int numerr;128 /* Receive data */129 .....130 /* Receive parity */131 .....132 /* Get syndrome from hardware decoder */133 .....134 /* Decode 512 byte in data8.*/135 numerr = decode_rs8 (rs_decoder, data8, par, 512, syn, 0, NULL, 0, NULL);136 137 138Decoding with syndrome given by hardware decoder, no direct data correction.139~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~140 141Note: It's not necessary to give data and received parity to the142decoder.143 144::145 146 /* Parity buffer. Size = number of roots */147 uint16_t par[6], syn[6], corr[8];148 uint8_t data[512];149 int numerr, errpos[8];150 /* Receive data */151 .....152 /* Receive parity */153 .....154 /* Get syndrome from hardware decoder */155 .....156 /* Decode 512 byte in data8.*/157 numerr = decode_rs8 (rs_decoder, NULL, NULL, 512, syn, 0, errpos, 0, corr);158 for (i = 0; i < numerr; i++) {159 do_error_correction_in_your_buffer(errpos[i], corr[i]);160 }161 162 163Cleanup164-------165 166The function free_rs frees the allocated resources, if the caller is167the last user of the decoder.168 169::170 171 /* Release resources */172 free_rs(rs_decoder);173 174 175Structures176==========177 178This chapter contains the autogenerated documentation of the structures179which are used in the Reed-Solomon Library and are relevant for a180developer.181 182.. kernel-doc:: include/linux/rslib.h183 :internal:184 185Public Functions Provided186=========================187 188This chapter contains the autogenerated documentation of the189Reed-Solomon functions which are exported.190 191.. kernel-doc:: lib/reed_solomon/reed_solomon.c192 :export:193 194Credits195=======196 197The library code for encoding and decoding was written by Phil Karn.198 199::200 201 Copyright 2002, Phil Karn, KA9Q202 May be used under the terms of the GNU General Public License (GPL)203 204 205The wrapper functions and interfaces are written by Thomas Gleixner.206 207Many users have provided bugfixes, improvements and helping hands for208testing. Thanks a lot.209 210The following people have contributed to this document:211 212Thomas Gleixner\ tglx@linutronix.de213