DM385: Bug somewhere in ubifs code

Never mind.  I now realize it was user error; I was not thinking carefully enough about the flashing process: when programming other partitions, the commands to u-boot look like this:

fatload mmc 0 0x82000000 dm38x-csk.dtb
nand erase 0x0DA40000 0x40000
nand write 0x82000000 0x0DA40000 0x40000

where the size of the erase and the size of the write are equal, since the file is sized to fit the partition exactly, up to PEB boundary.  However, when programming the filesystem partition, I need to take care to look at the size of the ubinized file in bytes (which is automatically rounded up to a multiple of PEB size) and while I should erase the entire partition, I should only write the actual file size, e.g.:

## We write ubifs_csk.bin to the 208 MiB file-system partition,
## first erasing the entire partition, then populating it.
fatload mmc 0 0x82000000 ubifs_csk.bin
nand erase 0x00A40000 0x0D000000

## Note: When we write, we need to calculate the size of ubifs_csk.bin,
## in bytes in hex; it will already be a multiple of the PEB size, so no need to round up.
nand write 0x82000000 0x00A40000 0x061C0000

I would have been nice if any of the TI documentation for the IPNC RDK explained the process in more detail, so that it could be revised to reflect changes in the resulting software.  I bothered to answer my own question here to help anyone else who might have this problem.

BTW, since it is not well-documented elsewhere:

• 0x82000000 refers to an used address in RAM for temporary storage, so fatload mmc 0 0x82000000 <filename> means we are reading the given file from the 0th MMC unit (i.e., SD card) into RAM at this address
• 0x00A40000 is the starting address of the NAND partition
• 0x0D000000 is the physical size of the partition
• 0x061C0000 is the actual size of the ubinized filesystem in bytes.  Note: This size is reported by the fatload command, so you just need to convert to hex.