drivers/mtd: Remove bad block management in FTL when it is not needed

[jlaitine]

Summary

Bad block management and the logical->physical mapping is only needed with NAND based memories, so we can compile that in conditionally, saving ~600 bytes of flash on a 32-bit arm when NAND is not used.

Impact

This only removes dead code on a system which doesn't have CONFIG_MTD_NAND defined

Testing

Building for stm32l476vg-disco:nsh:

The original size:

LD: nuttx                          
Memory region         Used Size  Region Size  %age Used
           flash:      117168 B       512 KB     22.35%
            sram:        9488 B        96 KB      9.65%
           sram2:          0 GB        32 KB      0.00%

The size after change:

LD: nuttx                                            
Memory region         Used Size  Region Size  %age Used
           flash:      116552 B       512 KB     22.23%
            sram:        9488 B        96 KB      9.65%
           sram2:          0 GB        32 KB      0.00%

Diff being 616 bytes smaller.

Functionality has been tested with PX4 on Pixhawk4 hardware (stm32f7), which has px4 parameters on an MTD partition and no NAND.

[xiaoxiang781216]

but NOR flash need skip the bad block too.

[jlaitine]

but NOR flash need skip the bad block too.

Typically there are no bad blocks (or error detection / ecc) on NOR flash. I'll come back to this tomorrow, perhaps I missed something nuttx specifc... Is there some lower level driver which implements such in sw?

[xiaoxiang781216]

Suggested change

	default y if MTD_NAND
	default !DEFAULT_SMALL

[PetervdPerk-NXP]

@xiaoxiang781216 I don’t agree with enabling this by default for non‑DEFAULT_SMALL configurations. I have several chips that use FTL without bad block management, so it’s unclear why this should be applied universally to those devices. Bad block management is typically only required for NAND-based technologies.

[jlaitine]

I don't think DEFAULT_SMALL is the correct one here. All of the boards which I am working on are !DEFAULT_SMALL and bad block management is not needed. Only reasonable default that I can think of is really MTD_NAND, because BBM on the host controller side is commonly needed only for raw nand devices. If the motivation behind the suggestion is that there are other than MTD_NAND devices, where default y is wanted, please give an example of that... perhaps we can add some additiona "default y if ..."?

In addition, we could have a DEFAULT_SMALL board using raw nand, in which case the BBM would be needed.

So I'd rather find a reasonable default based on whether the functionality is required or not, and not couple it to DEFAULT_SMALL.

[xiaoxiang781216]

if so, please add assert if mtd support isbad or markbad, but FTL_BBM is false.

[jlaitine]

if so, please add assert if mtd support isbad or markbad, but FTL_BBM is false.

Sounds reasonable but where? In ftl_open perhaps? DEBUGASSERT?

What if user wants to intentionally disable the bad block management? Perhaps there is no reason to do so...

[michallenc]

No, I agree most of the drivers don't need it. But after this merge request you have to enable CONFIG_FTL_BBM if you use mtd_partition to create multiple partitions on your flash device. And that's not a theoretical bug, it's fairly common use case. If you don't enable CONFIG_FTL_BBM, you program runs into the debug assertion, even if your driver doesn't need bad block management. This should be solved by the diff above and we won't have to enable CONFIG_FTL_BBM for most of the NOR flash devices (perhaps for all of them...). I can create a merge request for the change if you want.

[jlaitine]

Ah sorry. Now I understand. The debugassert is definitely wrong! @xiaoxiang781216 I think we should remove that debugassert, and solve the potential misconfiguration you were worried about by other means.

Thanks @michallenc for you patience, sorry for me being so slow to understand what you were saying :)

[jlaitine]

Simplest fix would be to just remove the DEBUGASSERT. I can also check if something could be done to make proper compile time check for original purpose why it was suggested to be added.

[jlaitine]

Perhaps something in this direction: #19145 , do you think this would solve the issue @michallenc, @xiaoxiang781216 ?

[jlaitine]

Or then we can just pick the original patch that @michallenc provided and keep the debugassert?

[jlaitine]

re-based to master, hoping for the CI build errors to go away...

[lupyuen]

Hi: Could you Rebase your PR with the Master Branch? We fixed the Segger SystemView Error in the CI Build. Thanks :-)

• drivers/segger: Download systemview from NuttX Mirror Repo #19031

[lupyuen]

FYI: I restarted the CI Build to fix the Docker Image

• ci/docker: bump risc-v toolchain gcc14 #19035

[jlaitine]

For NAND devices the CONFIG_FTL_BBM is selected by default - these are the ones that typically would need it. If any other (non mtd nand) driver needs BBM, it can just select it in the respective Kconfig definition, to avoid misconfiguration. Part of the driver implementation is the config flag which enables it. Anyhow, compiling the image without CONFIG_FTL_BBM doesn't cause system crash, it will just cause the bad block management not being there in FTL layer (as this is what the flag does), that is, the framework just wouldn't call the markbad and isbad functions defined by the driver. I don't really see an issue here. Devices which need the BBM in the host software are not common, and those drivers which need it can just enable it by default.

…

On 6/15/26 14:11, Michal Lenc wrote: ***@***.**** commented on this pull request. ------------------------------------------------------------------------ In drivers/mtd/Kconfig <#19018 (comment)>: > @@ -50,6 +50,15 @@ config FTL_READAHEAD default n depends on DRVR_READAHEAD +config FTL_BBM + bool "Enable bad block management in the FTL layer" + default y if MTD_NAND I am talking about the opposite scenario. MTD driver sets |markbad| and |isbad|, but now you have to manually enable |CONFIG_FTL_BBM|, otherwise you end up with the assertion. The option should be set automatically if |CONFIG_MTD_PARTITION| is configured. — Reply to this email directly, view it on GitHub <#19018?email_source=notifications&email_token=AFSLTVU5JHDJ6J3O4ETDHY3477KVBA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTINBZGY4DANBQGU3KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#discussion_r3412984974>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFSLTVXGOWJ3Y67K2XMS6PT477KVBAVCNFSNUABFKJSXA33TNF2G64TZHMZDEOBRGAZTENZTHNEXG43VMU5TINJXGA2TIMBVGIZ2C5QC>. You are receiving this because you were mentioned.Message ID: ***@***.***>