summaryrefslogtreecommitdiff
path: root/test/dm/nand.c
AgeCommit message (Collapse)Author
2024-08-26test: Update NAND test to avoid extra macrosSimon Glass
Write out the tests in full to allow the test to be found more easily when there is a failure. We could use a single test function with a for() loop but this would stop at the first failure, and some variations might while other pass. Signed-off-by: Simon Glass <sjg@chromium.org>
2024-08-26test: Rename unit-test flagsSimon Glass
The UT_TESTF_ macros read as 'unit test test flags' which is not right. Rename to UTF ('unit test flags'). This has the benefit of being shorter, which helps keep UNIT_TEST() declarations on a single line. Give the enum a name and reference it from the UNIT_TEST() macros while we are here. Signed-off-by: Simon Glass <sjg@chromium.org>
2023-11-16nand: Add sandbox driverSean Anderson
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: Sean Anderson <seanga2@gmail.com>