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 <yamad...@jp.panasonic.com> > > Cc: Scott Wood <scottw...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot