[U-Boot] [PATCH v2] mtd: nand: allow to skip BBT scanning during NAND inititialization

Scott Wood scottwood at freescale.com
Mon Nov 3 22:47:47 CET 2014


On Mon, 2014-11-03 at 15:40 -0600, Scott Wood wrote:
> On Thu, 2014-10-23 at 21:25 +0900, Masahiro Yamada wrote:
> > Since commit ff94bc40af34 (mtd, ubi, ubifs: resync with Linux-3.14),
> > chip->scan_bbt() is called at the end of nand_scan_tail().
> > It means the first read access happens immediately after the generic
> > NAND initialization process.
> > 
> > It causes a problem to some SoCs of UniPhier platform because some of
> > their register values need to be fixed up after the general
> > initialization procedure has been finished.  Otherwise, read asccess
> > fails.  Such a fix-up is SoC-specific enough to be written in a board
> > file rather than in driver code.
> > 
> > One of possible and clean enough ways to work around this issue is
> > postpone the BBT scanning until necessary fix-up is done in
> > board_late_init() or somewhere else.
> > 
> > CONFIG_MTD_NAND_SKIP_BBTSCAN, if enabled, allows to skip the BBT
> > scanning at the end of nand_scan_tail().
> > 
> > Signed-off-by: Masahiro Yamada <yamada.m at jp.panasonic.com>
> > Cc: Scott Wood <scottwood at freescale.com>
> > ---
> 
> Rotislav Lisovy already posted a patch to fix the regression, but I
> don't think you should be relying on this for your problem.  Why don't
> you want to put SoC-specific knowledge in the driver?  At least make it
> a callback from the driver to an SoC file, rather than hoping the NAND
> won't be touched for a certain amount of time after the driver has told
> the subsystem "I'm here and ready to be used".

Also, if you did have a valid reason to set NAND_SKIP_BBTSCAN, why would
you want to set it from nand.c rather than from your driver's init
function?

-Scott




More information about the U-Boot mailing list