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

["Maniyam, Dinesh" <dinesh.maniyam@altera.com>]

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
>