75XX XNAND
The XNAND is our layer of software and an FPGA core which is designed to vastly increase the reliability of NAND access. This board includes a 512MB flash chip, but the XNAND algorithm will limit this to a usable 256MB from redundancy. The software layer to access the XNAND is implemented in userspace in conjunction with NBD (network block device). You may want to refer to the nandctl page which will show more advanced usage, but by default the linuxrc script will mount the sd card with the following layout:
/dev/nbd0 - whole disk device of XNAND drive /dev/nbd1 - 1st partition (kernel partition) /dev/nbd2 - 2nd partition (EXT2 initrd) /dev/nbd3 - 3rd partition (~252MByte mini Debian EXT3 filesystem) /dev/nbd4 - 4th partition (unused)
| Note: | NBD devices report their size as SIZE_MAX for more flexibility when using them with nandctl. If you are formatting a partition or using dd you will need to specify the size of the block device or partition. |
XNAND2
XNAND2 is an innovation built upon its XNAND predecessor. This engineering effort was predicated by the NAND industry's falling quality standards and Technologic Systems' dedication to continued superior quality, long lifespan products. XNAND2 introduces a more robust system of redundant, error-corrected data storage, and a whole-device wear leveling system that ensures the longest possible lifespan for NAND media.
Please see our whitepaper on the subject for more detail and information.
To facilitate this new paradigm, a new 'nandctl' binary has been introduced. The features and output of this new utility are detailed in this section.
The command line options for the XNAND2 nandctl are very similar to the original:
# nandctl --help Usage: nandctl [OPTION] ... Technologic Systems NAND flash manipulation. General options: -R, --read=N Read N blocks of flash to stdout -W, --write=N Write N blocks to flash -x, --writeset=BYTE Write BYTE as value (default 0) -i, --writeimg=FILE Use FILE as file to write to NAND -t, --writetest Run write speed test -r, --readtest Run read speed test -n, --random=SEED Do random seeks for tests -z, --blocksize=SZ Use SZ bytes each read/write call -k, --seek=SECTOR Seek to 512b sector number SECTOR -d, --nbdserver=NBDSPEC Run NBD userspace block driver server -I, --bind=IPADDR Bind NBD server to IPADDR -Q, --stats Print NBD server stats -m, --dmesg Print log of NAND activity -f, --foreground Run NBD server in foreground -X, --xnand Use XNAND RAID layer -I, --xnandinit Initialize flash chip for XNAND -L, --listbb List all factory bad blocks -v, --verbose Be verbose (-vv for maximum) -P, --printmbr Print MBR and partition table -M, --setmbr Write MBR from environment variables -h, --help This help When running a NBD server, NBDSPEC is a comma separated list of devices and partitions for the NBD servers starting at port 7525. e.g. "lun0:part1,lun1:disc" corresponds to 2 NBD servers, one at port 7525 serving the first partition of chip #0, and the other at TCP port 7526 serving the whole disc device of chip #1.
The --dmesg command will show a running event log since boot. This is useful for troubleshooting if a failure is suspected.
The --stats command will show a mixture of long-term and short-term statistical data about the NAND chip and the XNAND2 layer over it:
# nandctl --stats nbdpid=146 nbd_readreqs=0 nbd_read_blks=0 nbd_writereqs=0 nbd_write_blks=0 nbd_seek_past_eof_errs=0 xnand2_most_worn=5936 xnand2_spares_used=6 xnand2_spares_remaining=1014 xnand2_total_erases=24156537 xnand2_ecc_fixups=0 xnand2_parity_recovers=0 read_seeks=0 write_seeks=0
This --stats output is helpful for systems where monitoring long-term health is useful.
Stats output definitions:
nbdpid: This is the process id of the nandctl process.
nbd_readreqs: This is the number of read requests received by nandctl since boot.
nbd_read_blks: This is the number of blocks read by the nbd client since boot.
nbd_writereqs: This is the number of write requests received by nandctl since boot.
nbd_write_blks: This is the number of blocks written by the nbd client since boot.
nbd_seek_past_eof_errs: This statistic should always read zero. It's the number of times the OS has asked nandctl to seek past the end of the media.
xnand2_most_worn: This is the number of writes that have been made to the most worn block on the NAND chip over the lifetime of the XNAND2 media.
xnand2_spares_used: This is the number of bad blocks marked by XNAND2 over the lifetime of the XNAND2 media.
xnand2_spares_remaining: This is the number of blocks not currently in active use by the disk block device or the RAID5 like redundant data backup. They are available to participate in wear-leveling activities (along with the blocks used by the disk block device and redundant data).
xnand2_total_erases: This is the number of erases over the lifetime of the XNAND2 media since boot.
xnand2_ecc_fixups: This is the total number of ecc correctable errors XNAND2 has corrected since boot.
xnand2_parity_recovers: This is the total number of blocks XNAND2 has had to recover from parity data.
read_seeks: This is the number of read seeks done since boot.
write_seeks: This is the number of write seeks done since boot.
Upgrading to XNAND2
Replacing XNAND with XNAND2 in a dd image for use in production programing
The updated nandctl binary with XNAND2 support can be found here.
An XNAND2 formatted NAND device will work on supported products with any bootrom date, whether or not the bootrom supports XNAND2. However, devices can only be booted from the XNAND technology that their bootrom supports. An XNAND2 formatted NAND cannot be booted from a bootrom that only supports XNAND1 and vice versa. This allows for application support of XNAND2, regardless of bootrom support, but only if NAND is not the boot media. Because of this, it is important to update all programming and production processes to support XNAND2. For other production preparation processes that do not re-image the entire device, it is still important to confirm the production process is using the XNAND2 nandctl binary dated October 2016 or later. The following section provides the necessary information to update an existing XNAND1 image with the new XNAND2 nandctl software.
The latest nandctl binary is compatible with both XNAND1 and XNAND2; however it will assume that disk initialization will be targeted at XNAND2 support and it is not possible to force XNAND1 formatting. Because of this, the bootrom should be updated to be compatible with XNAND2 before using '--xnandinit' against a NAND device using the latest nandctl binary. TS-BOOTROMs with a date after October 2016 are compatible with and able to boot XNAND2 devices.
This update will walk through the steps of updating the nandctl binary contained in a customized production image. These steps are not necessary when using our stock image, only if your production process is using an SD or NAND image that has been based on any of our previous shipping images. Note that both SD and NAND images should be updated to properly support XNAND2 in all situations.
To prepare this update, a workstation running linux is necessary, either in a virtual machine or native install. From the workstation, open a terminal window and copy your original production image file to a local working directory (this is done to limit working on production used images). This file will be referenced as diskimg.dd in the following instructions. The latest XNAND2 compatible nandctl binary (link to download is at the top of this section) should also be downloaded in the same working directory.
Next, run the following command:
sudo fdisk -l diskimg.dd
This will produce output like the following:
Disk diskimg.dd: 268 MB, 268435456 bytes
255 heads, 63 sectors/track, 32 cylinders, total 524288 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
diskimg.dd1 1 5119 2559+ da Non-FS data
diskimg.dd2 5120 10239 2560 da Non-FS data
diskimg.dd3 10240 524287 257024 83 Linux
The above is the partition table of an XNAND disk. An image for an SD card will have 4 partitions rather than 3, but the same basic layout. The necessary information is the start sector of the second partition with the Id of "da," and the "Sector size" listed above the partition table. In this case it is partition 2 in which the start block is 5120 and the Sector size is 512. Multiply the two numbers to obtain the necessary offset: 5120 * 512 = 2621440.
Next, the initrd partition from the disk image file is mounted to a folder created in the working directory:
mkdir mnt
sudo mount -orw,loop,offset=$((5120*512)) diskimg.dd mnt/
The new XNAND2 nandctl binary is copied to the mounted folder structure
cp nandctl mnt/sbin/nandctl
sync
The disk image can be unmounted and renamed as needed:
sudo umount mnt
mv diskimg.dd diskimg-xnand2.dd