jlaitine commented on code in PR #19018:
URL: https://github.com/apache/nuttx/pull/19018#discussion_r3346224777
##########
drivers/mtd/ftl.c:
##########
@@ -80,10 +80,12 @@ struct ftl_struct_s
FAR uint8_t *eblock; /* One, in-memory erase block */
int oflags;
+#ifdef CONFIG_MTD_NAND
Review Comment:
I studied the issue you mentioned a bit forward. I was only aware of w25n
devices, which don't need the BBM in FTL layer, since they implement it by a
LUT in the chip's controller itself (which is the "sane" way to do it). I
assumed that this is the way all of those "controller based" nand devices would
work.
However, I found out that there is also the gd5f device in the tree, which
DO need the external bad block management; it only has ECC and error detection
but no integrated LUT for the BBM (at least acc. to the specs I managed to
find). This is weird, but proves that you are correct architecturally, such
devices do exist! (This commit doesn't actually break that device though,
because it doesn't even implement the bad block detection currently,
"mtd->isbad" and "mtd->markbad" are unimplemented).
I still think that it is wrong to enable the BBM for all the devices
unconditionally in FTL layer, since there are very few configurations which
would really need that. Consider all "disk" type devices, all MMC / SD devices,
all NOR flash based devices - they don't use it, so it is just dead weight.
I am starting to think that the more proper way to do this is to add a
specialiced flag to enable the block mapping code in FTL, something like this:
```
config FTL_BBM
bool "Enable bad block management in FTL"
default y if MTD_NAND
depends on MTD && FTL
```
Then, *if* you have some oddball device (nand or something else) which can
do bad block detection but doesn't have a bad block management LUT, you can
select it also separately?
What do you think @xiaoxiang781216 ?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
