[U-Boot] [PATCH 1/3] ARM: omap: Fix GPMC init for OMAP3 platforms

Gupta, Pekon pekon at ti.com
Mon Jul 14 03:35:01 CEST 2014


>From: Stefan Roese [mailto:sr at denx.de]
>>On 12.07.2014 15:30, Gupta, Pekon wrote:
>>> From: Tom Rini [mailto:tom.rini at 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 <pekon at ti.com>

with regards, pekon




More information about the U-Boot mailing list