All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] bad block table stored in nand flash
@ 2010-01-27 13:06 Ing. Jozef Goril
  2010-01-27 13:25 ` Ing. Jozef Goril
  2010-01-27 18:28 ` Scott Wood
  0 siblings, 2 replies; 3+ messages in thread
From: Ing. Jozef Goril @ 2010-01-27 13:06 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [U-Boot] bad block table stored in nand flash
  2010-01-27 13:06 [U-Boot] bad block table stored in nand flash Ing. Jozef Goril
@ 2010-01-27 13:25 ` Ing. Jozef Goril
  2010-01-27 18:28 ` Scott Wood
  1 sibling, 0 replies; 3+ messages in thread
From: Ing. Jozef Goril @ 2010-01-27 13:25 UTC (permalink / raw)
  To: u-boot

...sorry for confusing...

certainly, if reserved_block_code == 01b, then
rcode = 0x01;
msk[2] = ~rcode = ~0x01 = FE;

and I'm speaking about right side in parenthesis:
right side before negation: [FE,F8,E0,80]
right side after negation: [01,07,1F,7F]

But this doesn't change the fact that some blocks are irregularly set to invalid.

Thanks and best regards
Jozef


-------- Original Message --------
Subject: [U-Boot] bad block table stored in nand flash
From: Ing. Jozef Goril <jgoril@local.elnec.sk>
To: u-boot at lists.denx.de
Date: 27. 1. 2010 14:06

> 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 at 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
> 
> 
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [U-Boot] bad block table stored in nand flash
  2010-01-27 13:06 [U-Boot] bad block table stored in nand flash Ing. Jozef Goril
  2010-01-27 13:25 ` Ing. Jozef Goril
@ 2010-01-27 18:28 ` Scott Wood
  1 sibling, 0 replies; 3+ messages in thread
From: Scott Wood @ 2010-01-27 18:28 UTC (permalink / raw)
  To: u-boot

On Wed, Jan 27, 2010 at 02:06:22PM +0100, Ing. Jozef Goril wrote:
> 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 at 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?

This code came from Linux; I'd try asking on linux-mtd at lists.infradead.org.

-Scott

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-01-27 18:28 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-01-27 13:06 [U-Boot] bad block table stored in nand flash Ing. Jozef Goril
2010-01-27 13:25 ` Ing. Jozef Goril
2010-01-27 18:28 ` Scott Wood

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.