flash: spi_nand: support bad block management#104685
flash: spi_nand: support bad block management#104685MaureenHelm merged 3 commits intozephyrproject-rtos:mainfrom
Conversation
3bc14f4 to
68955ff
Compare
|
I validated this also with the flash translation layer from #100858. All disk tests pass: I will contribute the tests once either this or #100858 is merged. |
| page_address = addr >> config->addr_page_shift; | ||
|
|
||
| /* Copy data from main storage to cache (ignore ECC errors) */ | ||
| ret = spi_nand_page_read_to_cache(dev, page_address); |
There was a problem hiding this comment.
Am I wrong that the intended usage flow for this would be something like:
if (is_bad_block(dev, block)) {
return -EINVAL;
}
flash_read(dev, block, mem, len);
If so, the current implementation will read from main memory to cache twice for every block read.
There was a problem hiding this comment.
Bad blocks don't really matter for reads. E.g. if a block goes bad, i.e. one of its pages is no longer programmable, it is still possible to read the other pages stored in the block and migrate these to another block.
Bad blocks are relevant for writes/erases. Datasheets of NAND flashes usually state something like:
System software should initially check the first spare area location for non-FFH data on the first page of each block prior to performing any program or erase operations on the NAND Flash device.
Nevertheless, performance could be improved by doing a bad block scan on init and storing a bad block table in memory.
| return ret; | ||
| } | ||
|
|
||
| /* Copy bad block marker to cache (all other bytes stay reset at 0xff) */ |
There was a problem hiding this comment.
How do we know the cache bytes are 0xFF?
There was a problem hiding this comment.
That is the difference between PROGRAM LOAD (0x02) instruction and PROGRAM LOAD RANDOM (0x84) instruction. PROGRAM LOAD first resets the cache to the unprogrammed state (0xff) and then data transmitted over SPI is stored in the cache. PROGRAM LOAD RANDOM skips the resets and just overwrites the data in the cache. Context here is that to set the bad blocker mark a partial write of only that byte is performed. This is fine as it also is not protected by ECC.
|
Rebased and resolved conflicts. No other changes. |
Add support for bad block management in SPI NAND flash devices. This includes functions to check if a block is bad and to mark a block as bad. The bad block marker is stored in the OOB area of the first page of each block. Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
|
Rebase only, no other changes |
Add a test for the FTL disk driver using the spi_nand flash driver. This test utilizes the frdm_mcxn947 board with the MikroE Flash 5 Click shield. Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
…lash Add a test for the FTL disk driver using the spi_nand flash driver. This test utilizes the frdm_mcxn947 board with the MikroE Flash 5 Click shield. Signed-off-by: Tim Pambor <tim.pambor@codewrights.de>
|
|
I have added test coverage by adding FTL disk tests on top of the spi_nand driver. disk_access test: disk_performance: |
|
@de-nordic please take a look |
|
@de-nordic PTAL |



This PR adds support for bad block management in SPI NAND flash devices. This includes functions to mark a block as bad and to check if a block is bad, either marked as bad in factory or by software. The bad block marker is stored in the first byte of the OOB area of the first page of each block.
Demo: