>From: Stefan Roese [mailto:s...@denx.de] >>On 12.07.2014 15:30, Gupta, Pekon wrote: >>> From: Tom Rini [mailto:tom.r...@gmail.com] On Behalf Of Rini, Tom >>>> On Thu, Jul 10, 2014 at 07:28:00AM +0200, Stefan Roese wrote: >>>> Hi Pekon, >>>> >>>>> On 09.07.2014 20:22, Gupta, Pekon wrote: >>>>>> Commit a0a37183 (ARM: omap: merge GPMC initialization code for all >>>>>> platform) broke NAND on OMAP3 based platforms. I noticed this while >>>>>> testing the latest 2014.07-rc version on the TAO3530 board. NAND >>>>>> detection did not work with this error message: >>>>>> >>>>>> NAND: nand: error: Unable to find NAND settings in GPMC Configuration - >>>>>> quitting >>>>>> >>>>>> As OMAP3 configs don't set CONFIG_NAND but CONFIG_NAND_CMD. the GPMC >>>>>> was not initialized for NAND at all. This patch now fixes this issue. >>>>>> >>>>> Sorry couldn't understand this, why have users enabled CONFIG_NAND_CMD, >>>>> if CONFIG_NAND itself is not enabled ? >>>> >>>> CONFIG_NAND doesn't seem to be a mandatory define if NAND is used. >>> >>> Exactly. Adding in CONFIG_NAND is something that am335x started doing >>> because of the cases where we do, or do not, want to assume NAND exists. >>> >> That is bad. We shouldn't have added any CONFIG just for sake of making >> one platform work, that to with very generic nomenclature. Anyways, given >> the fact we have two similar configs, Let's kill one of them completely. >> I think killing CONFIG_NAND would be easier, as it's used only in few >> TI specific am33xx boards. Agree ? > >Yes. It would be great if you send an patch for this to be applied after >this release. And we should take my patch for this release to fix this >problem quickly. > Yes, absolutely, I don't want to stall your work. Acked-by: Pekon Gupta <pe...@ti.com>
with regards, pekon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
