From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Wed, 27 Jan 2010 12:28:54 -0600
Subject: [U-Boot] bad block table stored in nand flash
In-Reply-To: <4B603A4E.3010707@local.elnec.sk>
References: <4B603A4E.3010707@local.elnec.sk>
Message-ID: <20100127182854.GA6755@loki.buserror.net>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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