From: Ing. Jozef Goril <jgoril@local.elnec.sk>
To: u-boot@lists.denx.de
Subject: [U-Boot] bad block table stored in nand flash
Date: Wed, 27 Jan 2010 14:06:22 +0100 [thread overview]
Message-ID: <4B603A4E.3010707@local.elnec.sk> (raw)
Hi.
I'm new in U-Boot and need some help to understand how does BBT in nand flash work.
I don't understand, how reserved blocks (those used for BBT storage) are marked
in BBT in flash. The file in concern is drivers/mtd/nand_bbt.c, of actual
release version (2009.11.1).
At file beginning, there is some note:
* The table uses 2 bits per block
* 11b: block is good
* 00b: block is factory marked bad
* 01b, 10b: block is marked bad due to wear
*
* The memory bad block table uses the following scheme:
* 00b: block is good
* 01b: block is marked bad due to wear
* 10b: block is reserved (to protect the bbt area)
* 11b: block is factory marked bad
Later, in function write_bbt, there is a code that converts RAM-based BBT to
flash-based one at lines 720-730.
For line
buf[offs + (i >> sft)] &= ~(msk[dat & 0x03] << sftcnt);
I cannot understand the case, if (dat&0x03) == 10b (reserved block).
In that case, msk[2] value should be used.
The value of msk[2] is set few lines above (line 649): msk[2] = ~rcode;
The value of rcode is set@time of declaration:
rcode = td->reserved_block_code;
Now, in case of reserved_block_code == 01b:
rcode = 0x02;
msk[2] = ~rcode = ~0x02 = FD;
Regarding to line
buf[offs + (i >> sft)] &= ~(msk[dat & 0x03] << sftcnt);
it should be shifted left by sftcnt bits (sftcnt can be [0,2,4,6]).
I.e. that the value in the parenthesis on the left side can be of
[FD,F4,D0,40]. After negation: [02,0B,2F,BF].
These are values, that original byte in buffer can be ANDed with. Since there
are zeros on higher bits position (over mask 11b), this ANDing will destroy the
block status information of some blocks using the same byte. 00b in flash means
invalid block...
Am I missing something important or is there a bug?
I understand the reserved_block_code can be:
- zero : reserved blocks are not marked in flash-based BBT, the mechanism
rewrites rcode from 0x00 to 0xFF, later msk[2] = 0x00 and all works fine.
- non zero : reserved blocks are marked in flash-based BBT. But the only
avoilable value is 01b (00b stands for invalid block, 11b for good block and 10b
will come from RAM-based 01b due to a procedure mentioned above).
But I cannot find how does reserved_block_code of 01b work...
Can you, please, make me clear?
Thanks a lot.
Jozef Goril
next reply other threads:[~2010-01-27 13:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-27 13:06 Ing. Jozef Goril [this message]
2010-01-27 13:25 ` [U-Boot] bad block table stored in nand flash Ing. Jozef Goril
2010-01-27 18:28 ` Scott Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B603A4E.3010707@local.elnec.sk \
--to=jgoril@local.elnec.sk \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox