Readme notes for genecc program
===============================

The genecc_<devicename>.exe program can be used to pre-generate the parity bits 
for an image or file to be flashed into the NAND attached to the EMIF2.5 interface
of various TI SoC devices.

The source code is included (look at the *.module files), as well as the makefile
used to generate the executable.

This executable requires the Microsoft .Net framework to be installed on Windows
(latest version at the time of this writing is 3.5).  It may also run under other
operating systems using the open source Mono framework.

The program requires an input binary file.  This file will be parsed into 512 byte
chunks, and then processed with the Reed Solomon encoder to get the parity symbols.  
These symbols are then formatted so that they look exactly the same as they would be
generated by the EMIF hardware of the device, as seen in the NAND4BITECCx registers.
There are 80 bits of parity generated by this program (and the EMIF hardware) for 
every 512 bytes.  Refer to the documentation of the NAND boot mode for the device in
question to know how to take these 80bits/10bytes and format them for placement within
the NAND pages (may depend on the device, device revision, the size of the pages/blocks, etc.).

The parity data is output to the standard output and also to a binary file.  Within
the binary output file, there are four 32-bit words for each 512 bytes of the input
file.  These four words correspond to the NAND4BITECC1-NAND4BITECC4 register values.
You can compare the binary file output to the console output to resolve any confusion.

Note that if the input file is not a multiple of 512 bytes, the file will be padded
with 0xFF, up to the next multiple of 512.  This can only affect the parity calculation
of the last portion of the input data.  Best practice is to pre-pad your input file to
a multiple of your NAND page size.

Also note that this parity data is only useful for prepping NAND images whose data will
be accessed with the EMIF 2.5 ECC hardware enabled and used by the software.  This will
likely apply to the ROM boot loader (so you should write a UBL with the parity data
generated by this program) and probably also the UBL (so you should write a u-boot image
with this parity data, since the u-boot is read by by the UBL).  Higher level software 
(like the NAND commands within u-boot or the NAND driver under Linux) may or may not use
or know anything about the hardware ECC capabilities.