[PATCH] driver: nand: skip BBT scan during SPL to reduce size and complexity

[PATCH] driver: nand: skip BBT scan during SPL to reduce size and complexity

[dinesh.maniyam]

From: Dinesh Maniyam <dinesh.maniyam@altera.com>

Guard the Bad Block Table (BBT) scanning with `#ifndef CONFIG_SPL_BUILD`
to prevent running `chip->scan_bbt()` in SPL builds.

The SPL only requires basic NAND read functionality to load the next
stage and does not need full BBT management. Running the BBT scan in
SPL unnecessarily increases code size, memory usage, and boot time.

This change ensures the BBT is scanned only in U-Boot proper, where the
full NAND subsystem and dynamic memory are available.

Signed-off-by: Dinesh Maniyam <dinesh.maniyam@altera.com>
---
 drivers/mtd/nand/raw/nand_base.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 48e3685d995..4dc2a19b8f6 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -532,7 +532,9 @@ static int nand_block_checkbad(struct mtd_info *mtd, loff_t ofs, int allowbbt)
 	if (!(chip->options & NAND_SKIP_BBTSCAN) &&
 	    !(chip->options & NAND_BBT_SCANNED)) {
 		chip->options |= NAND_BBT_SCANNED;
+#ifndef CONFIG_XPL_BUILD
 		chip->scan_bbt(mtd);
+#endif
 	}
 
 	if (!chip->bbt)
-- 
2.43.7

Re: [PATCH] driver: nand: skip BBT scan during SPL to reduce size and complexity

[Heinrich Schuchardt]

On 11/13/25 04:03, dinesh.maniyam@altera.com wrote:
> From: Dinesh Maniyam <dinesh.maniyam@altera.com>
> 
> Guard the Bad Block Table (BBT) scanning with `#ifndef CONFIG_SPL_BUILD`

Thank you for looking into this issue.

In the patch you use CONFIG_XPL_BUILD not CONFIG_SPL_BUILD.

> to prevent running `chip->scan_bbt()` in SPL builds.
> 
> The SPL only requires basic NAND read functionality to load the next
> stage and does not need full BBT management. Running the BBT scan in
> SPL unnecessarily increases code size, memory usage, and boot time.
> 
> This change ensures the BBT is scanned only in U-Boot proper, where the
> full NAND subsystem and dynamic memory are available.
> 
> Signed-off-by: Dinesh Maniyam <dinesh.maniyam@altera.com>
> ---
>   drivers/mtd/nand/raw/nand_base.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> index 48e3685d995..4dc2a19b8f6 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -532,7 +532,9 @@ static int nand_block_checkbad(struct mtd_info *mtd, loff_t ofs, int allowbbt)
>   	if (!(chip->options & NAND_SKIP_BBTSCAN) &&
>   	    !(chip->options & NAND_BBT_SCANNED)) {
>   		chip->options |= NAND_BBT_SCANNED;
> +#ifndef CONFIG_XPL_BUILD

Running scripts/checkpatch.pl creates a warning because you use #ifdef 
instead of preferred

     if (IS_ENABLED(CONFIG_XPL_BUILD))

Best regards

Heinrich

>   		chip->scan_bbt(mtd);
> +#endif
>   	}
>   
>   	if (!chip->bbt)

Re: [PATCH] driver: nand: skip BBT scan during SPL to reduce size and complexity

[Maniyam, Dinesh]

Hi

On 25/11/2025 8:00 am, Heinrich Schuchardt wrote:
> [CAUTION: This email is from outside your organization. Unless you 
> trust the sender, do not click on links or open attachments as it may 
> be a fraudulent email attempting to steal your information and/or 
> compromise your computer.]
>
> On 11/13/25 04:03, dinesh.maniyam@altera.com wrote:
>> From: Dinesh Maniyam <dinesh.maniyam@altera.com>
>>
>> Guard the Bad Block Table (BBT) scanning with `#ifndef CONFIG_SPL_BUILD`
>
> Thank you for looking into this issue.
>
> In the patch you use CONFIG_XPL_BUILD not CONFIG_SPL_BUILD.
>
> Overlooked. I will make changes to the commit message.
>
>> to prevent running `chip->scan_bbt()` in SPL builds.
>>
>> The SPL only requires basic NAND read functionality to load the next
>> stage and does not need full BBT management. Running the BBT scan in
>> SPL unnecessarily increases code size, memory usage, and boot time.
>>
>> This change ensures the BBT is scanned only in U-Boot proper, where the
>> full NAND subsystem and dynamic memory are available.
>>
>> Signed-off-by: Dinesh Maniyam <dinesh.maniyam@altera.com>
>> ---
>>   drivers/mtd/nand/raw/nand_base.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/mtd/nand/raw/nand_base.c 
>> b/drivers/mtd/nand/raw/nand_base.c
>> index 48e3685d995..4dc2a19b8f6 100644
>> --- a/drivers/mtd/nand/raw/nand_base.c
>> +++ b/drivers/mtd/nand/raw/nand_base.c
>> @@ -532,7 +532,9 @@ static int nand_block_checkbad(struct mtd_info 
>> *mtd, loff_t ofs, int allowbbt)
>>       if (!(chip->options & NAND_SKIP_BBTSCAN) &&
>>           !(chip->options & NAND_BBT_SCANNED)) {
>>               chip->options |= NAND_BBT_SCANNED;
>> +#ifndef CONFIG_XPL_BUILD
>
> Running scripts/checkpatch.pl creates a warning because you use #ifdef
> instead of preferred
>
>     if (IS_ENABLED(CONFIG_XPL_BUILD))
>
> Best regards
>
> Heinrich
>
> I will use the preferred. 
>
> Thanks
> Dinesh
>
>>               chip->scan_bbt(mtd);
>> +#endif
>>       }
>>
>>       if (!chip->bbt)
>

Re: [PATCH] driver: nand: skip BBT scan during SPL to reduce size and complexity

[Marek Vasut]

On 11/25/25 1:00 AM, Heinrich Schuchardt wrote:
> On 11/13/25 04:03, dinesh.maniyam@altera.com wrote:
>> From: Dinesh Maniyam <dinesh.maniyam@altera.com>
>>
>> Guard the Bad Block Table (BBT) scanning with `#ifndef CONFIG_SPL_BUILD`
> 
> Thank you for looking into this issue.
> 
> In the patch you use CONFIG_XPL_BUILD not CONFIG_SPL_BUILD.
> 
>> to prevent running `chip->scan_bbt()` in SPL builds.
>>
>> The SPL only requires basic NAND read functionality to load the next
>> stage and does not need full BBT management. Running the BBT scan in
>> SPL unnecessarily increases code size, memory usage, and boot time.
>>
>> This change ensures the BBT is scanned only in U-Boot proper, where the
>> full NAND subsystem and dynamic memory are available.
How do you guarantee that the content that you read from the NAND is not 
corrupted, or read from already spent cells, or is even aligned with 
what U-Boot would read after scanning the BBT ? NAND suffers from 
considerable bitflips and short cell erase cycle count, the bad block 
table scanning is very likely mandatory. Disabling it because it 
increases code complexity and size is not a good reason for disabling it.

Re: [PATCH] driver: nand: skip BBT scan during SPL to reduce size and complexity

[Michael Nazzareno Trimarchi]

Hi Dinesh

On Thu, Nov 13, 2025 at 4:04 AM <dinesh.maniyam@altera.com> wrote:
>
> From: Dinesh Maniyam <dinesh.maniyam@altera.com>
>
> Guard the Bad Block Table (BBT) scanning with `#ifndef CONFIG_SPL_BUILD`
> to prevent running `chip->scan_bbt()` in SPL builds.
>
> The SPL only requires basic NAND read functionality to load the next
> stage and does not need full BBT management. Running the BBT scan in
> SPL unnecessarily increases code size, memory usage, and boot time.
>
> This change ensures the BBT is scanned only in U-Boot proper, where the
> full NAND subsystem and dynamic memory are available.
>
> Signed-off-by: Dinesh Maniyam <dinesh.maniyam@altera.com>
> ---
>  drivers/mtd/nand/raw/nand_base.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> index 48e3685d995..4dc2a19b8f6 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -532,7 +532,9 @@ static int nand_block_checkbad(struct mtd_info *mtd, loff_t ofs, int allowbbt)
>         if (!(chip->options & NAND_SKIP_BBTSCAN) &&
>             !(chip->options & NAND_BBT_SCANNED)) {
>                 chip->options |= NAND_BBT_SCANNED;
> +#ifndef CONFIG_XPL_BUILD
>                 chip->scan_bbt(mtd);
> +#endif
>         }
>

Look at the file there are other points where this ifdef is used for
exactly the same reason and please check this commit

commit fa87360b3ae28639f72e1c665b0631436693f60f
Author: Roger Quadros <rogerq@kernel.org>
Date:   Tue Dec 20 12:21:57 2022 +0200

    mtd: rawnand: nand_base: Allow base driver to be used in SPL
without nand_bbt

    nand_bbt.c is not being built with the nand_base driver during SPL
    build. This results in build failures if we try to access any nand_bbt
    related functions.

    Don't use any nand_bbt functions for SPL build.

    Signed-off-by: Roger Quadros <rogerq@kernel.org>
    Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
    Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
    Link: https://lore.kernel.org/all/20221220102203.52398-3-rogerq@kernel.org

Michael

>         if (!chip->bbt)
> --
> 2.43.7
>


--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael@amarulasolutions.com
__________________________________

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info@amarulasolutions.com
www.amarulasolutions.com

Re: [PATCH] driver: nand: skip BBT scan during SPL to reduce size and complexity

[Miquel Raynal]

On 25/11/2025 at 12:55:30 +01, Marek Vasut <marek.vasut@mailbox.org> wrote:

> On 11/25/25 1:00 AM, Heinrich Schuchardt wrote:
>> On 11/13/25 04:03, dinesh.maniyam@altera.com wrote:
>>> From: Dinesh Maniyam <dinesh.maniyam@altera.com>
>>>
>>> Guard the Bad Block Table (BBT) scanning with `#ifndef CONFIG_SPL_BUILD`
>> Thank you for looking into this issue.
>> In the patch you use CONFIG_XPL_BUILD not CONFIG_SPL_BUILD.
>> 
>>> to prevent running `chip->scan_bbt()` in SPL builds.
>>>
>>> The SPL only requires basic NAND read functionality to load the next
>>> stage and does not need full BBT management.

You do not need full BBT management, but you probably need some of it,
at least the part that finds it and interprets it, for sure.

>>> Running the BBT scan in
>>> SPL unnecessarily increases code size, memory usage, and boot time.

"unnecessarily" :-)

>>>
>>> This change ensures the BBT is scanned only in U-Boot proper, where the
>>> full NAND subsystem and dynamic memory are available.
> How do you guarantee that the content that you read from the NAND is not
> corrupted, or read from already spent cells, or is even aligned with
> what U-Boot would read after scanning the BBT ? NAND suffers from
> considerable bitflips and short cell erase cycle count, the bad block
> table scanning is very likely mandatory. Disabling it because it
> increases code complexity and size is not a good reason for disabling
> it.

I agree with Marek, you cannot simply close your eyes on the BBT. You
*really* need to know what you're doing here.

In some cases (which must be clearly identified by the system owner) you can
leverage the BBM only, but:
- this requires a bit of logic anyway (finding the BBM location +
  reading and remembering the block state)
- some drivers set NAND_BBT_NO_OOB_BBM which prevent the OOB to be used
  for writing the BBM, in which case you don't have any other choice
  than searching for a BBT.

A third option might be tempting, but is IMHO unreliable, it is to rely
on the ECC results. For instance, many chips still use Hamming ECC
schemes, which will generate invalid reports above 2 bitflips. So on a
badly damaged block you will end up with misses. Also hoping for the ECC feedback to
tell you a block is bad would require to read the entire block, because
any single page in a block may lead to a block being assumed bad. It's not
like you can just read X pages and tell "I have no error, so it's
fine". Because if the block was declared bad by the OS because of page >
X, you won't detect it and you'd read stale data.

Thanks,
Miquèl

Re: [PATCH] driver: nand: skip BBT scan during SPL to reduce size and complexity

[Maniyam, Dinesh]

On 25/11/2025 10:54 pm, Miquel Raynal wrote:
> [CAUTION: This email is from outside your organization. Unless you trust the sender, do not click on links or open attachments as it may be a fraudulent email attempting to steal your information and/or compromise your computer.]
>
> On 25/11/2025 at 12:55:30 +01, Marek Vasut <marek.vasut@mailbox.org> wrote:
>
>> On 11/25/25 1:00 AM, Heinrich Schuchardt wrote:
>>> On 11/13/25 04:03, dinesh.maniyam@altera.com wrote:
>>>> From: Dinesh Maniyam <dinesh.maniyam@altera.com>
>>>>
>>>> Guard the Bad Block Table (BBT) scanning with `#ifndef CONFIG_SPL_BUILD`
>>> Thank you for looking into this issue.
>>> In the patch you use CONFIG_XPL_BUILD not CONFIG_SPL_BUILD.
>>>
>>>> to prevent running `chip->scan_bbt()` in SPL builds.
>>>>
>>>> The SPL only requires basic NAND read functionality to load the next
>>>> stage and does not need full BBT management.
> You do not need full BBT management, but you probably need some of it,
> at least the part that finds it and interprets it, for sure.
>
>>>> Running the BBT scan in
>>>> SPL unnecessarily increases code size, memory usage, and boot time.
> "unnecessarily" :-)
>
>>>> This change ensures the BBT is scanned only in U-Boot proper, where the
>>>> full NAND subsystem and dynamic memory are available.
>> How do you guarantee that the content that you read from the NAND is not
>> corrupted, or read from already spent cells, or is even aligned with
>> what U-Boot would read after scanning the BBT ? NAND suffers from
>> considerable bitflips and short cell erase cycle count, the bad block
>> table scanning is very likely mandatory. Disabling it because it
>> increases code complexity and size is not a good reason for disabling
>> it.
> I agree with Marek, you cannot simply close your eyes on the BBT. You
> *really* need to know what you're doing here.
>
> In some cases (which must be clearly identified by the system owner) you can
> leverage the BBM only, but:
> - this requires a bit of logic anyway (finding the BBM location +
>    reading and remembering the block state)
> - some drivers set NAND_BBT_NO_OOB_BBM which prevent the OOB to be used
>    for writing the BBM, in which case you don't have any other choice
>    than searching for a BBT.
>
> A third option might be tempting, but is IMHO unreliable, it is to rely
> on the ECC results. For instance, many chips still use Hamming ECC
> schemes, which will generate invalid reports above 2 bitflips. So on a
> badly damaged block you will end up with misses. Also hoping for the ECC feedback to
> tell you a block is bad would require to read the entire block, because
> any single page in a block may lead to a block being assumed bad. It's not
> like you can just read X pages and tell "I have no error, so it's
> fine". Because if the block was declared bad by the OS because of page >
> X, you won't detect it and you'd read stale data.
>
> Thanks,
> Miquèl
>
> Hi Marek, Miquel
>
> Thank you, this clarifies it well. I completely agree — the BBT must not be bypassed, and ECC alone cannot guarantee valid data. Your points about BBM and the limitations of ECC are spot on.
>
> Thanks
> Dinesh
>