Skip to content
  • Sean Anderson's avatar
    nand: Add sandbox driver · bc8e8a4b
    Sean Anderson authored and Tom Rini's avatar Tom Rini committed
    
    
    Add a sandbox NAND flash driver to facilitate testing. This driver supports
    any number of devices, each using a single chip-select. The OOB data is
    stored in-band, with the separation enforced through the API.
    
    For now, create two devices to test with. The first is a very small device
    with basic ECC. The second is an 8G device (chosen to be larger than 32
    bits). It uses ONFI, with the values copied from the datasheet. It also
    doesn't need too strong ECC, which speeds things up.
    
    Although the nand subsystem determines the parameters of a chip based on
    the ID, the driver itself requires devicetree properties for each
    parameter. We do not derive parameters from the ID because parsing the ID
    is non-trivial. We do not just use the parameters that the nand subsystem
    has calculated since that is something we should be testing. An exception
    is made for the ECC layout, since that is difficult to encode in the device
    tree and is not a property of the device itself.
    
    Despite using file I/O to access the backing data, we do not support using
    external files. In my experience, these are unnecessary for testing since
    tests can generally be written to write their expected data beforehand.
    Additionally, we would need to store the "programmed" information somewhere
    (complicating the format and the programming process) or try to detect
    whether block are erased at runtime (degrading probe speeds).
    
    Information about whether each page has been programmed is stored in an
    in-memory buffer. To simplify the implementation, we only support a single
    program per erase. While this is accurate for many larger flashes, some
    smaller flashes (512 byte) support multiple programs and/or subpage
    programs. Support for this could be added later as I believe some
    filesystems expect this.
    
    To test ECC, we support error-injection. Surprisingly, only ECC bytes in
    the OOB area are protected, even though all bytes are equally susceptible
    to error. Because of this, we take care to only corrupt ECC bytes.
    Similarly, because ECC covers "steps" and not the whole page, we must take
    care to corrupt data in the same way.
    
    Signed-off-by: default avatarSean Anderson <seanga2@gmail.com>
    bc8e8a4b