Patchwork ARM: dts: dra7-evm: add parallel NOR flash support

login
register
mail settings
Submitter pekon gupta
Date July 23, 2014, 10:58 a.m.
Message ID <1406113130-23939-1-git-send-email-pekon@ti.com>
Download mbox | patch
Permalink /patch/372866/
State New
Headers show

Comments

pekon gupta - July 23, 2014, 10:58 a.m.
This patch adds support for parallel NOR device (S29GL512S10) present on J6-EVM.
The Flash device is connected to GPMC controller on chip-select[0] and accessed
as memory-mapped device. It has data-witdh=x16, capacity-64MBytes(512Mbits) and
is CFI compatible.
As multiple devices are share GPMC pins on this board, so following board
settings are required to detect NOR device:
     SW5.1 (NAND_BOOTn) = OFF (logic-1)
     SW5.2 (NOR_BOOTn)  = ON  (logic-0) /* Active-low */
     SW5.3 (eMMC_BOOTn) = OFF (logic-1)
     SW5.4 (QSPI_BOOTn) = OFF (logic-1)

Also to maintain NAND Boot functionality, following setting are kept as default
- NAND status="enabled"
- NOR status="disabled"

Signed-off-by: Pekon Gupta <pekon@ti.com>
---

/* Flash read/write access tested after enabling NOR sub-node in DT */
   linux#> flash_erase /dev/mtd9 0 0
   linux#> dd if=/dev/urandom of=/tmp/source.hex  bs=1c count=2048
   linux#> mtd_debug write /dev/mtd9 0x0 2048 /tmp/source.hex
   linux#> mtd_debug read  /dev/mtd9 0x0 2048 /tmp/destination.hex
   linux#> diff /tmp/source.hex  /tmp/destination.hex

 
 arch/arm/boot/dts/dra7-evm.dts | 141 ++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 140 insertions(+), 1 deletion(-)
Roger Quadros - July 29, 2014, 12:15 p.m.
Hi Pekon,

On 07/23/2014 01:58 PM, Pekon Gupta wrote:
> This patch adds support for parallel NOR device (S29GL512S10) present on J6-EVM.
> The Flash device is connected to GPMC controller on chip-select[0] and accessed
> as memory-mapped device. It has data-witdh=x16, capacity-64MBytes(512Mbits) and
> is CFI compatible.
> As multiple devices are share GPMC pins on this board, so following board
> settings are required to detect NOR device:
>      SW5.1 (NAND_BOOTn) = OFF (logic-1)
>      SW5.2 (NOR_BOOTn)  = ON  (logic-0) /* Active-low */
>      SW5.3 (eMMC_BOOTn) = OFF (logic-1)
>      SW5.4 (QSPI_BOOTn) = OFF (logic-1)

Why does NOR have any dependency on states of eMMC_BOOTn and QSPI_BOOTn?

> 
> Also to maintain NAND Boot functionality, following setting are kept as default
> - NAND status="enabled"
> - NOR status="disabled"

Too bad they designed the hardware so that either NOR or NAND can be used at a time.
Better to mention about this limitation by stating that CS0 is shared between NOR and NAND
and only one can be used at a time.

> 
> Signed-off-by: Pekon Gupta <pekon@ti.com>
> ---
> 
> /* Flash read/write access tested after enabling NOR sub-node in DT */
>    linux#> flash_erase /dev/mtd9 0 0
>    linux#> dd if=/dev/urandom of=/tmp/source.hex  bs=1c count=2048
>    linux#> mtd_debug write /dev/mtd9 0x0 2048 /tmp/source.hex
>    linux#> mtd_debug read  /dev/mtd9 0x0 2048 /tmp/destination.hex
>    linux#> diff /tmp/source.hex  /tmp/destination.hex
> 
>  
>  arch/arm/boot/dts/dra7-evm.dts | 141 ++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 140 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
> index 4adc280..1ee9727 100644
> --- a/arch/arm/boot/dts/dra7-evm.dts
> +++ b/arch/arm/boot/dts/dra7-evm.dts
> @@ -151,6 +151,66 @@
>  			0xd0	(PIN_OUTPUT | MUX_MODE0)	/* gpmc_be0n_cle */
>  		>;
>  	};
> +
> +	nor_flash_x16: nor_flash_x16 {
> +		/* On DRA7 EVM, NOR_BOOTn comes from DIP switch
> +		 * So NOR flash requires following switch settings:
> +		 * SW5.1 (NAND_BOOTn) = OFF (logic-1)
> +		 * SW5.2 (NOR_BOOTn)  = ON  (logic-0) Active-low
> +		 * SW5.3 (eMMC_BOOTn) = OFF (logic-1)
> +		 * SW5.4 (QSPI_BOOTn) = OFF (logic-1)
> +		 */

The only requirement for NOR_BOOTn is SW5.2 = ON and SW5.1 (NAND_BOOTn) = OFF.

> +		pinctrl-single,pins = <
> +			0x00	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad0  */
> +			0x04	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad1  */
> +			0x08	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad2  */
> +			0x0c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad3  */
> +			0x10	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad4  */
> +			0x14	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad5  */
> +			0x18	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad6  */
> +			0x1c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad7  */
> +			0x20	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad8  */
> +			0x24	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad9  */
> +			0x28	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad10 */
> +			0x2c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad11 */
> +			0x30	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad12 */
> +			0x34	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad13 */
> +			0x38	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad14 */
> +			0x3c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad15 */
> +			0x40	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a0   */
> +			0x44	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a1   */
> +			0x48	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a2   */
> +			0x4c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a3   */
> +			0x50	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a4   */
> +			0x54	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a5   */
> +			0x58	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a6   */
> +			0x5c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a7   */
> +			0x60	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a8   */
> +			0x64	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a9   */
> +			0x68	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a10  */
> +			0x6c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a11  */
> +			0x70	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a12  */
> +			0x74	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a13  */
> +			0x78	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a14  */
> +			0x7c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a15  */
> +			0x80	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a16  */
> +			0x84	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a17  */
> +			0x88	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a18  */
> +			0x8c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a19  */
> +			0x90	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a20  */
> +			0x94	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a21  */
> +			0x98	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a22  */
> +			0x9c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a23  */
> +			0xa0	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a24  */
> +			0xa4	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a25  */
> +			0xd8	(PIN_INPUT  | MUX_MODE0)	/* gpmc_wait0    */
> +			0xcc	(PIN_OUTPUT | MUX_MODE0)	/* gpmc_wen      */
> +			0xb4	(PIN_OUTPUT | MUX_MODE0)	/* gpmc_csn0     */
> +			0xc4	(PIN_OUTPUT | MUX_MODE0)	/* gpmc_advn_ale */
> +			0xc8	(PIN_OUTPUT | MUX_MODE0)	/* gpmc_oen_ren	 */
> +			0xd0	(PIN_OUTPUT | MUX_MODE0)	/* gpmc_be0n_cle */
> +		>;
> +	};
>  };
>  
>  &i2c1 {
> @@ -417,8 +477,9 @@
>  	status = "okay";
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&nand_flash_x16>;
> -	ranges = <0 0 0 0x01000000>;	/* minimum GPMC partition = 16MB */
> +	ranges = <0 0 0x08000000 0x04000000>;	/* address offset=128MB, range=512Mb=64MB */
>  	nand@0,0 {
> +		status = "okay";

Not needed. If it is not explicitly disabled it is always enabled by default.

>  		reg = <0 0 4>;		/* device IO registers */
>  		ti,nand-ecc-opt = "bch8";
>  		ti,elm-id = <&elm>;
> @@ -494,4 +555,82 @@
>  			reg = <0x00a00000 0x0f600000>;
>  		};
>  	};
> +
> +	nor@0,0 {
> +		status = "disabled";
> +		compatible = "cfi-flash";
> +		reg = <0 0 0x04000000>;		/* device memory map = 64MB (actual capacity) */
> +		/* generic bindings */
> +		linux,mtd-name = "Spansion,S29GL512";
> +		bank-width = <2>;
> +		/* vendor specific bindings */
> +		gpmc,device-width = <2>;
> +		gpmc,sync-clk-ps = <0>;
> +		gpmc,cs-on-ns = <0>;
> +		gpmc,cs-rd-off-ns = <100>;
> +		gpmc,cs-wr-off-ns = <100>;
> +		gpmc,adv-on-ns = <10>;
> +		gpmc,adv-rd-off-ns = <100>;
> +		gpmc,adv-wr-off-ns = <100>;
> +		gpmc,we-on-ns = <10>;
> +		gpmc,we-off-ns = <100>;
> +		gpmc,oe-on-ns = <10>;
> +		gpmc,oe-off-ns = <100>;
> +		gpmc,access-ns = <75>;
> +		gpmc,rd-cycle-ns = <100>;
> +		gpmc,wr-cycle-ns = <100>;
> +		gpmc,page-burst-access-ns = <10>;
> +		gpmc,cycle2cycle-samecsen;
> +		gpmc,bus-turnaround-ns = <10>;
> +		gpmc,cycle2cycle-delay-ns = <20>;
> +		/* gpmc,clk-activation-ns = <0>; */
> +		gpmc,wait-monitoring-ns = <0>;
> +		gpmc,wr-access-ns = <75>;
> +		gpmc,wr-data-mux-bus-ns = <100>;
> +		/* MTD partition table */
> +		/* All SPL-* partitions are sized to minimal length
> +		 * which can be independently programmable */
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		partition@0x00000000 {
> +			label = "NOR.SPL";
> +			reg = <0x00000000 0x00040000>;
> +		};
> +		partition@0x00040000 {
> +			label = "NOR.SPL.backup1";
> +			reg = <0x00040000 0x00040000>;
> +		};
> +		partition@0x00080000 {
> +			label = "NOR.SPL.backup2";
> +			reg = <0x00080000 0x00040000>;
> +		};
> +		partition@0x000c0000 {
> +			label = "NOR.SPL.backup3";
> +			reg = <0x000c0000 0x00040000>;
> +		};
> +		partition@0x00100000 {
> +			label = "NOR.u-boot-spl-os";
> +			reg = <0x00100000 0x00080000>;
> +		};
> +		partition@0x00180000 {
> +			label = "NOR.u-boot";
> +			reg = <0x00180000 0x00100000>;
> +		};
> +		partition@0x00280000 {
> +			label = "NOR.u-boot-env";
> +			reg = <0x00280000 0x00040000>;
> +		};
> +		partition@0x002c0000 {
> +			label = "NOR.u-boot-env.backup1";
> +			reg = <0x002c0000 0x00040000>;
> +		};
> +		partition@0x00300000 {
> +			label = "NOR.kernel";
> +			reg = <0x00300000 0x00700000>;
> +		};
> +		partition@0x00a00000 {
> +			label = "NOR.file-system";
> +			reg = <0x00a00000 0x00600000>;
> +		};
> +	};
>  };
> 

cheers,
-roger
Pekon Gupta - July 30, 2014, 7:40 p.m.
Hi Roger,

On Tue, Jul 29, 2014 at 5:45 PM, Roger Quadros <rogerq@ti.com> wrote:
> On 07/23/2014 01:58 PM, Pekon Gupta wrote:
> > This patch adds support for parallel NOR device (S29GL512S10) present on J6-EVM.
> > The Flash device is connected to GPMC controller on chip-select[0] and accessed
> > as memory-mapped device. It has data-witdh=x16, capacity-64MBytes(512Mbits) and
> > is CFI compatible.
> > As multiple devices are share GPMC pins on this board, so following board
> > settings are required to detect NOR device:
> >      SW5.1 (NAND_BOOTn) = OFF (logic-1)
> >      SW5.2 (NOR_BOOTn)  = ON  (logic-0) /* Active-low */
> >      SW5.3 (eMMC_BOOTn) = OFF (logic-1)
> >      SW5.4 (QSPI_BOOTn) = OFF (logic-1)
>
> Why does NOR have any dependency on states of eMMC_BOOTn and QSPI_BOOTn?
>
If you see the schematics of J6-EVM, GPMC data and control lines are shared
between NAND, NOR, eMMC (and probably QSPI also).
I don't have access to TI's hardaware or board schematics anymore, so
please double check.

> >
> > Also to maintain NAND Boot functionality, following setting are kept as default
> > - NAND status="enabled"
> > - NOR status="disabled"
>
> Too bad they designed the hardware so that either NOR or NAND can be used at a time.
> Better to mention about this limitation by stating that CS0 is shared between NOR and NAND
> and only one can be used at a time.
>
NAND/NOR/eMMC/QSPI effectively all are storage devices, so users may
not use all of
them at once, so may be to optimize usage of pins they added multiple
devices on CS0.
Sorry, I may not be able to re-spin this patch anytime soon, as I have
no access to TI
resources so request you to please re-send it with appropriate commit
log change as you wish.

> >
> > Signed-off-by: Pekon Gupta <pekon@ti.com>
> > ---
> >
> > /* Flash read/write access tested after enabling NOR sub-node in DT */
> >    linux#> flash_erase /dev/mtd9 0 0
> >    linux#> dd if=/dev/urandom of=/tmp/source.hex  bs=1c count=2048
> >    linux#> mtd_debug write /dev/mtd9 0x0 2048 /tmp/source.hex
> >    linux#> mtd_debug read  /dev/mtd9 0x0 2048 /tmp/destination.hex
> >    linux#> diff /tmp/source.hex  /tmp/destination.hex
> >
> >
> >  arch/arm/boot/dts/dra7-evm.dts | 141 ++++++++++++++++++++++++++++++++++++++++-
> >  1 file changed, 140 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
> > index 4adc280..1ee9727 100644
> > --- a/arch/arm/boot/dts/dra7-evm.dts
> > +++ b/arch/arm/boot/dts/dra7-evm.dts
> > @@ -151,6 +151,66 @@
> >                       0xd0    (PIN_OUTPUT | MUX_MODE0)        /* gpmc_be0n_cle */
> >               >;
> >       };
> > +
> > +     nor_flash_x16: nor_flash_x16 {
> > +             /* On DRA7 EVM, NOR_BOOTn comes from DIP switch
> > +              * So NOR flash requires following switch settings:
> > +              * SW5.1 (NAND_BOOTn) = OFF (logic-1)
> > +              * SW5.2 (NOR_BOOTn)  = ON  (logic-0) Active-low
> > +              * SW5.3 (eMMC_BOOTn) = OFF (logic-1)
> > +              * SW5.4 (QSPI_BOOTn) = OFF (logic-1)
> > +              */
>
> The only requirement for NOR_BOOTn is SW5.2 = ON and SW5.1 (NAND_BOOTn) = OFF.
>
As mentioned above, please check board schematics
IIRC, GPMC lines pass through various levels of on-board
bi-directional multiplexers,
And 'select' lines of these multiplexers are controlled indirectly via
these xxx_BOOTn switches.

[...]

> >  &i2c1 {
> > @@ -417,8 +477,9 @@
> >       status = "okay";
> >       pinctrl-names = "default";
> >       pinctrl-0 = <&nand_flash_x16>;
> > -     ranges = <0 0 0 0x01000000>;    /* minimum GPMC partition = 16MB */
> > +     ranges = <0 0 0x08000000 0x04000000>;   /* address offset=128MB, range=512Mb=64MB */
> >       nand@0,0 {
> > +             status = "okay";
>
> Not needed. If it is not explicitly disabled it is always enabled by default.
>
Yes, but good to have clarity in DTS, as most users will just copy-paste TI-EVM
DTS and then tweak it for their own custom board DTS. So better to have this
mentioned explicitely.


with regards, pekon
Roger Quadros - July 31, 2014, 11:43 a.m.
+Sourav for QSPI and Balaji for mmc

On 07/30/2014 10:40 PM, Pekon Gupta wrote:
> Hi Roger,
> 
> On Tue, Jul 29, 2014 at 5:45 PM, Roger Quadros <rogerq@ti.com> wrote:
>> On 07/23/2014 01:58 PM, Pekon Gupta wrote:
>>> This patch adds support for parallel NOR device (S29GL512S10) present on J6-EVM.
>>> The Flash device is connected to GPMC controller on chip-select[0] and accessed
>>> as memory-mapped device. It has data-witdh=x16, capacity-64MBytes(512Mbits) and
>>> is CFI compatible.
>>> As multiple devices are share GPMC pins on this board, so following board
>>> settings are required to detect NOR device:
>>>      SW5.1 (NAND_BOOTn) = OFF (logic-1)
>>>      SW5.2 (NOR_BOOTn)  = ON  (logic-0) /* Active-low */
>>>      SW5.3 (eMMC_BOOTn) = OFF (logic-1)
>>>      SW5.4 (QSPI_BOOTn) = OFF (logic-1)
>>
>> Why does NOR have any dependency on states of eMMC_BOOTn and QSPI_BOOTn?
>>
> If you see the schematics of J6-EVM, GPMC data and control lines are shared
> between NAND, NOR, eMMC (and probably QSPI also).
> I don't have access to TI's hardaware or board schematics anymore, so
> please double check.

I just took a deeper look in the schematics.
It has nothing to do with GPMC Data and control lines but with the address lines.
The GPMC address lines are muxed on the same pins of the SoC as QSPI and MMC2.
i.e. A13-A18,CS2 for QSPI and A19-A27,CS1 for MMC2

NAND can probably work simultaneously with QSPI and MMC2 but for NOR case, QSPI and MMC2
need to be disabled.

This is starting to look ugly where apart from changing the DIP switch the DTS has to be
hand modified to support a certain case.

Lets leave the most usable configuration for default case i.e. NAND, QSPI and MMC2 enabled and keep NOR information in the dts but keep it disabled with a note that if NOR is enabled then NAND, QSPI, and MMC2 nodes need to be disabled.

I will resend this patch with the relevant changes.

cheers,
-roger

> 
>>>
>>> Also to maintain NAND Boot functionality, following setting are kept as default
>>> - NAND status="enabled"
>>> - NOR status="disabled"
>>
>> Too bad they designed the hardware so that either NOR or NAND can be used at a time.
>> Better to mention about this limitation by stating that CS0 is shared between NOR and NAND
>> and only one can be used at a time.
>>
> NAND/NOR/eMMC/QSPI effectively all are storage devices, so users may
> not use all of
> them at once, so may be to optimize usage of pins they added multiple
> devices on CS0.
> Sorry, I may not be able to re-spin this patch anytime soon, as I have
> no access to TI
> resources so request you to please re-send it with appropriate commit
> log change as you wish.
> 
>>>
>>> Signed-off-by: Pekon Gupta <pekon@ti.com>
>>> ---
>>>
>>> /* Flash read/write access tested after enabling NOR sub-node in DT */
>>>    linux#> flash_erase /dev/mtd9 0 0
>>>    linux#> dd if=/dev/urandom of=/tmp/source.hex  bs=1c count=2048
>>>    linux#> mtd_debug write /dev/mtd9 0x0 2048 /tmp/source.hex
>>>    linux#> mtd_debug read  /dev/mtd9 0x0 2048 /tmp/destination.hex
>>>    linux#> diff /tmp/source.hex  /tmp/destination.hex
>>>
>>>
>>>  arch/arm/boot/dts/dra7-evm.dts | 141 ++++++++++++++++++++++++++++++++++++++++-
>>>  1 file changed, 140 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
>>> index 4adc280..1ee9727 100644
>>> --- a/arch/arm/boot/dts/dra7-evm.dts
>>> +++ b/arch/arm/boot/dts/dra7-evm.dts
>>> @@ -151,6 +151,66 @@
>>>                       0xd0    (PIN_OUTPUT | MUX_MODE0)        /* gpmc_be0n_cle */
>>>               >;
>>>       };
>>> +
>>> +     nor_flash_x16: nor_flash_x16 {
>>> +             /* On DRA7 EVM, NOR_BOOTn comes from DIP switch
>>> +              * So NOR flash requires following switch settings:
>>> +              * SW5.1 (NAND_BOOTn) = OFF (logic-1)
>>> +              * SW5.2 (NOR_BOOTn)  = ON  (logic-0) Active-low
>>> +              * SW5.3 (eMMC_BOOTn) = OFF (logic-1)
>>> +              * SW5.4 (QSPI_BOOTn) = OFF (logic-1)
>>> +              */
>>
>> The only requirement for NOR_BOOTn is SW5.2 = ON and SW5.1 (NAND_BOOTn) = OFF.
>>
> As mentioned above, please check board schematics
> IIRC, GPMC lines pass through various levels of on-board
> bi-directional multiplexers,
> And 'select' lines of these multiplexers are controlled indirectly via
> these xxx_BOOTn switches.
> 
> [...]
> 
>>>  &i2c1 {
>>> @@ -417,8 +477,9 @@
>>>       status = "okay";
>>>       pinctrl-names = "default";
>>>       pinctrl-0 = <&nand_flash_x16>;
>>> -     ranges = <0 0 0 0x01000000>;    /* minimum GPMC partition = 16MB */
>>> +     ranges = <0 0 0x08000000 0x04000000>;   /* address offset=128MB, range=512Mb=64MB */
>>>       nand@0,0 {
>>> +             status = "okay";
>>
>> Not needed. If it is not explicitly disabled it is always enabled by default.
>>
> Yes, but good to have clarity in DTS, as most users will just copy-paste TI-EVM
> DTS and then tweak it for their own custom board DTS. So better to have this
> mentioned explicitely.
> 
> 
> with regards, pekon
>
Tony Lindgren - Aug. 1, 2014, 6:38 a.m.
* Roger Quadros <rogerq@ti.com> [140731 04:46]:
> +Sourav for QSPI and Balaji for mmc
> 
> On 07/30/2014 10:40 PM, Pekon Gupta wrote:
> > Hi Roger,
> > 
> > On Tue, Jul 29, 2014 at 5:45 PM, Roger Quadros <rogerq@ti.com> wrote:
> >> On 07/23/2014 01:58 PM, Pekon Gupta wrote:
> >>> This patch adds support for parallel NOR device (S29GL512S10) present on J6-EVM.
> >>> The Flash device is connected to GPMC controller on chip-select[0] and accessed
> >>> as memory-mapped device. It has data-witdh=x16, capacity-64MBytes(512Mbits) and
> >>> is CFI compatible.
> >>> As multiple devices are share GPMC pins on this board, so following board
> >>> settings are required to detect NOR device:
> >>>      SW5.1 (NAND_BOOTn) = OFF (logic-1)
> >>>      SW5.2 (NOR_BOOTn)  = ON  (logic-0) /* Active-low */
> >>>      SW5.3 (eMMC_BOOTn) = OFF (logic-1)
> >>>      SW5.4 (QSPI_BOOTn) = OFF (logic-1)
> >>
> >> Why does NOR have any dependency on states of eMMC_BOOTn and QSPI_BOOTn?
> >>
> > If you see the schematics of J6-EVM, GPMC data and control lines are shared
> > between NAND, NOR, eMMC (and probably QSPI also).
> > I don't have access to TI's hardaware or board schematics anymore, so
> > please double check.
> 
> I just took a deeper look in the schematics.
> It has nothing to do with GPMC Data and control lines but with the address lines.
> The GPMC address lines are muxed on the same pins of the SoC as QSPI and MMC2.
> i.e. A13-A18,CS2 for QSPI and A19-A27,CS1 for MMC2
> 
> NAND can probably work simultaneously with QSPI and MMC2 but for NOR case, QSPI and MMC2
> need to be disabled.
> 
> This is starting to look ugly where apart from changing the DIP switch the DTS has to be
> hand modified to support a certain case.
> 
> Lets leave the most usable configuration for default case i.e. NAND, QSPI and MMC2 enabled and keep NOR information in the dts but keep it disabled with a note that if NOR is enabled then NAND, QSPI, and MMC2 nodes need to be disabled.
> 
> I will resend this patch with the relevant changes.

It might make sense for the gpmc driver to manage the pins in some
cases. That would allow dynamic muxing of the pins depending which
driver is loaded, or even during runtime if needed.

Regards,

Tony
Roger Quadros - Aug. 1, 2014, 7:46 a.m.
On 08/01/2014 09:38 AM, Tony Lindgren wrote:
> * Roger Quadros <rogerq@ti.com> [140731 04:46]:
>> +Sourav for QSPI and Balaji for mmc
>>
>> On 07/30/2014 10:40 PM, Pekon Gupta wrote:
>>> Hi Roger,
>>>
>>> On Tue, Jul 29, 2014 at 5:45 PM, Roger Quadros <rogerq@ti.com> wrote:
>>>> On 07/23/2014 01:58 PM, Pekon Gupta wrote:
>>>>> This patch adds support for parallel NOR device (S29GL512S10) present on J6-EVM.
>>>>> The Flash device is connected to GPMC controller on chip-select[0] and accessed
>>>>> as memory-mapped device. It has data-witdh=x16, capacity-64MBytes(512Mbits) and
>>>>> is CFI compatible.
>>>>> As multiple devices are share GPMC pins on this board, so following board
>>>>> settings are required to detect NOR device:
>>>>>      SW5.1 (NAND_BOOTn) = OFF (logic-1)
>>>>>      SW5.2 (NOR_BOOTn)  = ON  (logic-0) /* Active-low */
>>>>>      SW5.3 (eMMC_BOOTn) = OFF (logic-1)
>>>>>      SW5.4 (QSPI_BOOTn) = OFF (logic-1)
>>>>
>>>> Why does NOR have any dependency on states of eMMC_BOOTn and QSPI_BOOTn?
>>>>
>>> If you see the schematics of J6-EVM, GPMC data and control lines are shared
>>> between NAND, NOR, eMMC (and probably QSPI also).
>>> I don't have access to TI's hardaware or board schematics anymore, so
>>> please double check.
>>
>> I just took a deeper look in the schematics.
>> It has nothing to do with GPMC Data and control lines but with the address lines.
>> The GPMC address lines are muxed on the same pins of the SoC as QSPI and MMC2.
>> i.e. A13-A18,CS2 for QSPI and A19-A27,CS1 for MMC2
>>
>> NAND can probably work simultaneously with QSPI and MMC2 but for NOR case, QSPI and MMC2
>> need to be disabled.
>>
>> This is starting to look ugly where apart from changing the DIP switch the DTS has to be
>> hand modified to support a certain case.
>>
>> Lets leave the most usable configuration for default case i.e. NAND, QSPI and MMC2 enabled and keep NOR information in the dts but keep it disabled with a note that if NOR is enabled then NAND, QSPI, and MMC2 nodes need to be disabled.
>>
>> I will resend this patch with the relevant changes.
> 
> It might make sense for the gpmc driver to manage the pins in some
> cases. That would allow dynamic muxing of the pins depending which
> driver is loaded, or even during runtime if needed.

It is more like a board configuration so something more generic than the gpmc driver has to manage.
Also, QSPI and MMC don't fall under GPMC scope.

There are 2 things that need to change to update the hardware configuration.
1) The pinmux via the enabling/disabling (or plugging in/out) of relevant nodes in the DT.
2) The I2C GPIOs which reconfigure the DIP Switch lines in order to reconfigure external Muxes.

cheers,
-roger
Tony Lindgren - Aug. 1, 2014, 7:54 a.m.
* Roger Quadros <rogerq@ti.com> [140801 00:49]:
> On 08/01/2014 09:38 AM, Tony Lindgren wrote:
> > * Roger Quadros <rogerq@ti.com> [140731 04:46]:
> >> +Sourav for QSPI and Balaji for mmc
> >>
> >> On 07/30/2014 10:40 PM, Pekon Gupta wrote:
> >>> Hi Roger,
> >>>
> >>> On Tue, Jul 29, 2014 at 5:45 PM, Roger Quadros <rogerq@ti.com> wrote:
> >>>> On 07/23/2014 01:58 PM, Pekon Gupta wrote:
> >>>>> This patch adds support for parallel NOR device (S29GL512S10) present on J6-EVM.
> >>>>> The Flash device is connected to GPMC controller on chip-select[0] and accessed
> >>>>> as memory-mapped device. It has data-witdh=x16, capacity-64MBytes(512Mbits) and
> >>>>> is CFI compatible.
> >>>>> As multiple devices are share GPMC pins on this board, so following board
> >>>>> settings are required to detect NOR device:
> >>>>>      SW5.1 (NAND_BOOTn) = OFF (logic-1)
> >>>>>      SW5.2 (NOR_BOOTn)  = ON  (logic-0) /* Active-low */
> >>>>>      SW5.3 (eMMC_BOOTn) = OFF (logic-1)
> >>>>>      SW5.4 (QSPI_BOOTn) = OFF (logic-1)
> >>>>
> >>>> Why does NOR have any dependency on states of eMMC_BOOTn and QSPI_BOOTn?
> >>>>
> >>> If you see the schematics of J6-EVM, GPMC data and control lines are shared
> >>> between NAND, NOR, eMMC (and probably QSPI also).
> >>> I don't have access to TI's hardaware or board schematics anymore, so
> >>> please double check.
> >>
> >> I just took a deeper look in the schematics.
> >> It has nothing to do with GPMC Data and control lines but with the address lines.
> >> The GPMC address lines are muxed on the same pins of the SoC as QSPI and MMC2.
> >> i.e. A13-A18,CS2 for QSPI and A19-A27,CS1 for MMC2
> >>
> >> NAND can probably work simultaneously with QSPI and MMC2 but for NOR case, QSPI and MMC2
> >> need to be disabled.
> >>
> >> This is starting to look ugly where apart from changing the DIP switch the DTS has to be
> >> hand modified to support a certain case.
> >>
> >> Lets leave the most usable configuration for default case i.e. NAND, QSPI and MMC2 enabled and keep NOR information in the dts but keep it disabled with a note that if NOR is enabled then NAND, QSPI, and MMC2 nodes need to be disabled.
> >>
> >> I will resend this patch with the relevant changes.
> > 
> > It might make sense for the gpmc driver to manage the pins in some
> > cases. That would allow dynamic muxing of the pins depending which
> > driver is loaded, or even during runtime if needed.
> 
> It is more like a board configuration so something more generic than the gpmc driver has to manage.
> Also, QSPI and MMC don't fall under GPMC scope.
> 
> There are 2 things that need to change to update the hardware configuration.
> 1) The pinmux via the enabling/disabling (or plugging in/out) of relevant nodes in the DT.
> 2) The I2C GPIOs which reconfigure the DIP Switch lines in order to reconfigure external Muxes.

Oh OK, yeah gpmc should only manage gpmc pins, this would need
a separate driver for coordinating things.

Regards,

Tony
Pekon Gupta - Aug. 1, 2014, 8:22 a.m.
On Fri, Aug 1, 2014 at 1:24 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Roger Quadros <rogerq@ti.com> [140801 00:49]:
>> On 08/01/2014 09:38 AM, Tony Lindgren wrote:
>> > * Roger Quadros <rogerq@ti.com> [140731 04:46]:
>> >> +Sourav for QSPI and Balaji for mmc
>> >>
>> >> On 07/30/2014 10:40 PM, Pekon Gupta wrote:
>> >>> Hi Roger,
>> >>>
>> >>> On Tue, Jul 29, 2014 at 5:45 PM, Roger Quadros <rogerq@ti.com> wrote:
>> >>>> On 07/23/2014 01:58 PM, Pekon Gupta wrote:
>> >>>>> This patch adds support for parallel NOR device (S29GL512S10) present on J6-EVM.
>> >>>>> The Flash device is connected to GPMC controller on chip-select[0] and accessed
>> >>>>> as memory-mapped device. It has data-witdh=x16, capacity-64MBytes(512Mbits) and
>> >>>>> is CFI compatible.
>> >>>>> As multiple devices are share GPMC pins on this board, so following board
>> >>>>> settings are required to detect NOR device:
>> >>>>>      SW5.1 (NAND_BOOTn) = OFF (logic-1)
>> >>>>>      SW5.2 (NOR_BOOTn)  = ON  (logic-0) /* Active-low */
>> >>>>>      SW5.3 (eMMC_BOOTn) = OFF (logic-1)
>> >>>>>      SW5.4 (QSPI_BOOTn) = OFF (logic-1)
>> >>>>
>> >>>> Why does NOR have any dependency on states of eMMC_BOOTn and QSPI_BOOTn?
>> >>>>
>> >>> If you see the schematics of J6-EVM, GPMC data and control lines are shared
>> >>> between NAND, NOR, eMMC (and probably QSPI also).
>> >>> I don't have access to TI's hardaware or board schematics anymore, so
>> >>> please double check.
>> >>
>> >> I just took a deeper look in the schematics.
>> >> It has nothing to do with GPMC Data and control lines but with the address lines.
>> >> The GPMC address lines are muxed on the same pins of the SoC as QSPI and MMC2.
>> >> i.e. A13-A18,CS2 for QSPI and A19-A27,CS1 for MMC2
>> >>
>> >> NAND can probably work simultaneously with QSPI and MMC2 but for NOR case, QSPI and MMC2
>> >> need to be disabled.
>> >>
>> >> This is starting to look ugly where apart from changing the DIP switch the DTS has to be
>> >> hand modified to support a certain case.
>> >>
>> >> Lets leave the most usable configuration for default case i.e. NAND, QSPI and MMC2 enabled and keep NOR information in the dts but keep it disabled with a note that if NOR is enabled then NAND, QSPI, and MMC2 nodes need to be disabled.
>> >>
>> >> I will resend this patch with the relevant changes.
>> >
>> > It might make sense for the gpmc driver to manage the pins in some
>> > cases. That would allow dynamic muxing of the pins depending which
>> > driver is loaded, or even during runtime if needed.
>>
>> It is more like a board configuration so something more generic than the gpmc driver has to manage.
>> Also, QSPI and MMC don't fall under GPMC scope.
>>
>> There are 2 things that need to change to update the hardware configuration.
>> 1) The pinmux via the enabling/disabling (or plugging in/out) of relevant nodes in the DT.
>> 2) The I2C GPIOs which reconfigure the DIP Switch lines in order to reconfigure external Muxes.
>
> Oh OK, yeah gpmc should only manage gpmc pins, this would need
> a separate driver for coordinating things.
>
You need to also consider the case where multiple devices of different types
are connected to different chip-selects like;
- NAND on chip-select[0]
- NOR on chip-select[1]
And with acceptance of 'Rostislav Lisovy''s patch [1] this
multi-device configuration
is possible on custom boards.

It would have been appropriate if pinctrl-probe was called from protocol drivers
(OMAP-NAND and NOR in this case). But I don't know if that's feasible even.
Also how drivers would handle probe conflicts arising with common pins.
Example: gpmc_ad[7:0] will be common to pin-mux of both NAND and NOR devices.

Does pinctrl framework gives freedom to _ignore_ conflicts on already configured
pins, and continues with configuring remaining non-conflicting pins ?
If yes, then
moving pinctrl-probe to OMAP-NAND | NOR protocol driver should be more
appropriate.


with regards, pekon

[1] https://patchwork.kernel.org/patch/4514561/
Roger Quadros - Aug. 1, 2014, 9:24 a.m.
On 08/01/2014 11:22 AM, Pekon Gupta wrote:
> On Fri, Aug 1, 2014 at 1:24 PM, Tony Lindgren <tony@atomide.com> wrote:
>> * Roger Quadros <rogerq@ti.com> [140801 00:49]:
>>> On 08/01/2014 09:38 AM, Tony Lindgren wrote:
>>>> * Roger Quadros <rogerq@ti.com> [140731 04:46]:
>>>>> +Sourav for QSPI and Balaji for mmc
>>>>>
>>>>> On 07/30/2014 10:40 PM, Pekon Gupta wrote:
>>>>>> Hi Roger,
>>>>>>
>>>>>> On Tue, Jul 29, 2014 at 5:45 PM, Roger Quadros <rogerq@ti.com> wrote:
>>>>>>> On 07/23/2014 01:58 PM, Pekon Gupta wrote:
>>>>>>>> This patch adds support for parallel NOR device (S29GL512S10) present on J6-EVM.
>>>>>>>> The Flash device is connected to GPMC controller on chip-select[0] and accessed
>>>>>>>> as memory-mapped device. It has data-witdh=x16, capacity-64MBytes(512Mbits) and
>>>>>>>> is CFI compatible.
>>>>>>>> As multiple devices are share GPMC pins on this board, so following board
>>>>>>>> settings are required to detect NOR device:
>>>>>>>>      SW5.1 (NAND_BOOTn) = OFF (logic-1)
>>>>>>>>      SW5.2 (NOR_BOOTn)  = ON  (logic-0) /* Active-low */
>>>>>>>>      SW5.3 (eMMC_BOOTn) = OFF (logic-1)
>>>>>>>>      SW5.4 (QSPI_BOOTn) = OFF (logic-1)
>>>>>>>
>>>>>>> Why does NOR have any dependency on states of eMMC_BOOTn and QSPI_BOOTn?
>>>>>>>
>>>>>> If you see the schematics of J6-EVM, GPMC data and control lines are shared
>>>>>> between NAND, NOR, eMMC (and probably QSPI also).
>>>>>> I don't have access to TI's hardaware or board schematics anymore, so
>>>>>> please double check.
>>>>>
>>>>> I just took a deeper look in the schematics.
>>>>> It has nothing to do with GPMC Data and control lines but with the address lines.
>>>>> The GPMC address lines are muxed on the same pins of the SoC as QSPI and MMC2.
>>>>> i.e. A13-A18,CS2 for QSPI and A19-A27,CS1 for MMC2
>>>>>
>>>>> NAND can probably work simultaneously with QSPI and MMC2 but for NOR case, QSPI and MMC2
>>>>> need to be disabled.
>>>>>
>>>>> This is starting to look ugly where apart from changing the DIP switch the DTS has to be
>>>>> hand modified to support a certain case.
>>>>>
>>>>> Lets leave the most usable configuration for default case i.e. NAND, QSPI and MMC2 enabled and keep NOR information in the dts but keep it disabled with a note that if NOR is enabled then NAND, QSPI, and MMC2 nodes need to be disabled.
>>>>>
>>>>> I will resend this patch with the relevant changes.
>>>>
>>>> It might make sense for the gpmc driver to manage the pins in some
>>>> cases. That would allow dynamic muxing of the pins depending which
>>>> driver is loaded, or even during runtime if needed.
>>>
>>> It is more like a board configuration so something more generic than the gpmc driver has to manage.
>>> Also, QSPI and MMC don't fall under GPMC scope.
>>>
>>> There are 2 things that need to change to update the hardware configuration.
>>> 1) The pinmux via the enabling/disabling (or plugging in/out) of relevant nodes in the DT.
>>> 2) The I2C GPIOs which reconfigure the DIP Switch lines in order to reconfigure external Muxes.
>>
>> Oh OK, yeah gpmc should only manage gpmc pins, this would need
>> a separate driver for coordinating things.
>>
> You need to also consider the case where multiple devices of different types
> are connected to different chip-selects like;
> - NAND on chip-select[0]
> - NOR on chip-select[1]

NOR and NAND are both on CS0 because GMPC boot only happens on CS0. So they cannot be used simultaneously on DRA7-EVM.

> And with acceptance of 'Rostislav Lisovy''s patch [1] this
> multi-device configuration
> is possible on custom boards.

Yep, as song as the devices are on different CS.
> 
> It would have been appropriate if pinctrl-probe was called from protocol drivers
> (OMAP-NAND and NOR in this case). But I don't know if that's feasible even.
> Also how drivers would handle probe conflicts arising with common pins.
> Example: gpmc_ad[7:0] will be common to pin-mux of both NAND and NOR devices.

GPMC devices always share Address, data and control lines. The Chip select line defines which chip is selected for GPMC access at any given moment. So there should be no conflict for multiple GPMC devices. And the pinmux conflict issue doesn't arise for them.

> 
> Does pinctrl framework gives freedom to _ignore_ conflicts on already configured
> pins, and continues with configuring remaining non-conflicting pins ?

I'm not sure. I think it just overrides the configuration if a new device uses the same pin configured by an earlier device.

> If yes, then
> moving pinctrl-probe to OMAP-NAND | NOR protocol driver should be more
> appropriate.

I don't think this is applicable now. 

cheers,
-roger

Patch

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 4adc280..1ee9727 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -151,6 +151,66 @@ 
 			0xd0	(PIN_OUTPUT | MUX_MODE0)	/* gpmc_be0n_cle */
 		>;
 	};
+
+	nor_flash_x16: nor_flash_x16 {
+		/* On DRA7 EVM, NOR_BOOTn comes from DIP switch
+		 * So NOR flash requires following switch settings:
+		 * SW5.1 (NAND_BOOTn) = OFF (logic-1)
+		 * SW5.2 (NOR_BOOTn)  = ON  (logic-0) Active-low
+		 * SW5.3 (eMMC_BOOTn) = OFF (logic-1)
+		 * SW5.4 (QSPI_BOOTn) = OFF (logic-1)
+		 */
+		pinctrl-single,pins = <
+			0x00	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad0  */
+			0x04	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad1  */
+			0x08	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad2  */
+			0x0c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad3  */
+			0x10	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad4  */
+			0x14	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad5  */
+			0x18	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad6  */
+			0x1c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad7  */
+			0x20	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad8  */
+			0x24	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad9  */
+			0x28	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad10 */
+			0x2c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad11 */
+			0x30	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad12 */
+			0x34	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad13 */
+			0x38	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad14 */
+			0x3c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad15 */
+			0x40	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a0   */
+			0x44	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a1   */
+			0x48	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a2   */
+			0x4c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a3   */
+			0x50	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a4   */
+			0x54	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a5   */
+			0x58	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a6   */
+			0x5c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a7   */
+			0x60	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a8   */
+			0x64	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a9   */
+			0x68	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a10  */
+			0x6c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a11  */
+			0x70	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a12  */
+			0x74	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a13  */
+			0x78	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a14  */
+			0x7c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a15  */
+			0x80	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a16  */
+			0x84	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a17  */
+			0x88	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a18  */
+			0x8c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a19  */
+			0x90	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a20  */
+			0x94	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a21  */
+			0x98	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a22  */
+			0x9c	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a23  */
+			0xa0	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a24  */
+			0xa4	(PIN_INPUT  | MUX_MODE0)	/* gpmc_a25  */
+			0xd8	(PIN_INPUT  | MUX_MODE0)	/* gpmc_wait0    */
+			0xcc	(PIN_OUTPUT | MUX_MODE0)	/* gpmc_wen      */
+			0xb4	(PIN_OUTPUT | MUX_MODE0)	/* gpmc_csn0     */
+			0xc4	(PIN_OUTPUT | MUX_MODE0)	/* gpmc_advn_ale */
+			0xc8	(PIN_OUTPUT | MUX_MODE0)	/* gpmc_oen_ren	 */
+			0xd0	(PIN_OUTPUT | MUX_MODE0)	/* gpmc_be0n_cle */
+		>;
+	};
 };
 
 &i2c1 {
@@ -417,8 +477,9 @@ 
 	status = "okay";
 	pinctrl-names = "default";
 	pinctrl-0 = <&nand_flash_x16>;
-	ranges = <0 0 0 0x01000000>;	/* minimum GPMC partition = 16MB */
+	ranges = <0 0 0x08000000 0x04000000>;	/* address offset=128MB, range=512Mb=64MB */
 	nand@0,0 {
+		status = "okay";
 		reg = <0 0 4>;		/* device IO registers */
 		ti,nand-ecc-opt = "bch8";
 		ti,elm-id = <&elm>;
@@ -494,4 +555,82 @@ 
 			reg = <0x00a00000 0x0f600000>;
 		};
 	};
+
+	nor@0,0 {
+		status = "disabled";
+		compatible = "cfi-flash";
+		reg = <0 0 0x04000000>;		/* device memory map = 64MB (actual capacity) */
+		/* generic bindings */
+		linux,mtd-name = "Spansion,S29GL512";
+		bank-width = <2>;
+		/* vendor specific bindings */
+		gpmc,device-width = <2>;
+		gpmc,sync-clk-ps = <0>;
+		gpmc,cs-on-ns = <0>;
+		gpmc,cs-rd-off-ns = <100>;
+		gpmc,cs-wr-off-ns = <100>;
+		gpmc,adv-on-ns = <10>;
+		gpmc,adv-rd-off-ns = <100>;
+		gpmc,adv-wr-off-ns = <100>;
+		gpmc,we-on-ns = <10>;
+		gpmc,we-off-ns = <100>;
+		gpmc,oe-on-ns = <10>;
+		gpmc,oe-off-ns = <100>;
+		gpmc,access-ns = <75>;
+		gpmc,rd-cycle-ns = <100>;
+		gpmc,wr-cycle-ns = <100>;
+		gpmc,page-burst-access-ns = <10>;
+		gpmc,cycle2cycle-samecsen;
+		gpmc,bus-turnaround-ns = <10>;
+		gpmc,cycle2cycle-delay-ns = <20>;
+		/* gpmc,clk-activation-ns = <0>; */
+		gpmc,wait-monitoring-ns = <0>;
+		gpmc,wr-access-ns = <75>;
+		gpmc,wr-data-mux-bus-ns = <100>;
+		/* MTD partition table */
+		/* All SPL-* partitions are sized to minimal length
+		 * which can be independently programmable */
+		#address-cells = <1>;
+		#size-cells = <1>;
+		partition@0x00000000 {
+			label = "NOR.SPL";
+			reg = <0x00000000 0x00040000>;
+		};
+		partition@0x00040000 {
+			label = "NOR.SPL.backup1";
+			reg = <0x00040000 0x00040000>;
+		};
+		partition@0x00080000 {
+			label = "NOR.SPL.backup2";
+			reg = <0x00080000 0x00040000>;
+		};
+		partition@0x000c0000 {
+			label = "NOR.SPL.backup3";
+			reg = <0x000c0000 0x00040000>;
+		};
+		partition@0x00100000 {
+			label = "NOR.u-boot-spl-os";
+			reg = <0x00100000 0x00080000>;
+		};
+		partition@0x00180000 {
+			label = "NOR.u-boot";
+			reg = <0x00180000 0x00100000>;
+		};
+		partition@0x00280000 {
+			label = "NOR.u-boot-env";
+			reg = <0x00280000 0x00040000>;
+		};
+		partition@0x002c0000 {
+			label = "NOR.u-boot-env.backup1";
+			reg = <0x002c0000 0x00040000>;
+		};
+		partition@0x00300000 {
+			label = "NOR.kernel";
+			reg = <0x00300000 0x00700000>;
+		};
+		partition@0x00a00000 {
+			label = "NOR.file-system";
+			reg = <0x00a00000 0x00600000>;
+		};
+	};
 };