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

[Miquel Raynal <miquel.raynal@bootlin.com>]

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