Question regarding mtd/nand/bbt.c with recent corner case fix

dinggao.pan dinggao.pan at horizon.ai
Mon Dec 13 03:44:27 PST 2021


Hi, 

Recently I encountered a case where while erasing the SPI-NAND flash, both 0x1d40000 and 0x1d60000 are properly reported as badblocks, but writing data to the flash, improper attempt of write is issued to address 0x1d75800 which is an actual broken NAND array causing write failure. This is fixed by a recently merged patch: [v2,1/2] Fix corner case in bad block table handling (Please check the attachment for details). I want to do a bit more research on the bbt cache management mechanism. I had a hard time locating the mailing series discussing the implementation.

During research, I am confused by how bbt.cache keep track of all the status of the erase blocks on a flash. Take aarch64, and a NAND flash with 128KiB erase block, 2048B page size and a total 128MB capacity as an example. We currently have 3 bits/entry in bbt, so, for all 1024 erase blocks, we'll need 3*1024 = 3072 bits to keep track of all bad block status. On aarch64, unsigned long will have 64 bits., which means we will have kind of a 48-way association for bbt.cache which is similar to actual CPU cache line associations?

My questions are the below ones:
1.	Is there such line association? If so, how did we map each entry with the actual erase block?
2.	Is there any documentation on the design logic of this bbt.cache?

Any insights are much appreciated, thanks!

Dinggao Pan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v2-1-2-Fix-corner-case-in-bad-block-table-handling..patch
Type: application/octet-stream
Size: 7113 bytes
Desc: v2-1-2-Fix-corner-case-in-bad-block-table-handling..patch
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20211213/560aed3c/attachment.obj>


More information about the linux-mtd mailing list