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 <[email protected]> wrote:
On 11/25/25 1:00 AM, Heinrich Schuchardt wrote:
On 11/13/25 04:03, [email protected] wrote:
From: Dinesh Maniyam <[email protected]>
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
