...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 <jgo...@local.elnec.sk> To: u-boot@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@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot