AnsweredAssumed Answered

How DBBT at absolute page is handled in u-boot

Question asked by Gnanachandran Dhanapal on Jul 3, 2014
Latest reply on Jul 9, 2014 by alejandrolozano

I have issues handling DBBT at absolute page in u-boot. The requirement is U-boot  should use DBBT written by kobs-ng to check  block good or bad before performing the operation(read/write/erase) on it

instead of scanning all blocks and creating its own table.



Using kobs-ng tool, We can write  redundant copy of FCB, DBBT and firmware at first partition of NAND. I can also see DBBT having some entries for bad block that was found scanning  NAND in my platform.



Following are kobs-ng  code snap shot that write FCB, DBBT and DBBT Entries for Bad block.






Using  above code FCBs are written in block 0, 1, 2  and 3. DBBTs are written in block 4,5,6 and 7  of  NAND chip.



In u-boot, I configured  nand option as follow





init board_nand_init(struct nand_chip *nand)











static struct nand_bbt_descr bbt_main_no_bbt_descr = {

        .options = NAND_BBT_ABSPAGE | NAND_BBT_WRITE

                | NAND_BBT_4BIT

                | NAND_BBT_NO_OOB,

        .len = 4,

        .veroffs = 8,

        .maxblocks = 4,

        .pattern = bbt_pattern,

        .pages[0]=512, /* Block 4 in Page */






Now I expect DBBT is read from page 512 (block 4) and should match pattern “bbt_pattern” and should have version number at Offset of 8 as shown below.



When U-boot is booting up, DBBT at page 512 is read in function read_abs_bbts(…) in nand_bbt.c  and read buffer is sent to read_bbt(…).

In read_bbt(…) function, I don’t see the code to match finger print, read version number and read DBBT entries for bad block.



Instead In read_bbt(…) , All blocks are scanned again for bad block mark again.



I want to understand how DBBT at absolute page is handled and used in u-boot.