[PATCH v7 0/4] add parallel NAND support for TI's new OMAPx and AMxx platforms (Part-2)

[PATCH v7 0/4] add parallel NAND support for TI's new OMAPx and AMxx platforms (Part-2)

[Pekon Gupta]

*changes v6 -> v7*
fixed 'reg = <cs offset 'size'> property for NAND nodes


*changes v5 -> v6*
- removed explicit disabling of GPMC and ELM in am335x-bone-memorycape.dts
  as both modules are already disabled by default in am33xx.dtsi
- fixed comments for <range> and <reg> properties. keeping it consistent
  across platforms.
- fixed <reg size> property. Using 'exact' register space as in hardware.
- fixed DT properties for wait-pin monitoring. Added gpmc,wait-pin = <>
- using lower-case letter for hex digits
Rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap :omap-for-v3.16/dt


*changes v4 -> v5*
use lower-case hexadecimal numbers
add comments for using different memory sizes in <range> and <reg> properties
fix 'reg size' property for GPMC and ELM nodes in dra7.dtsi


*changes v3 -> v4*
fixed <reg> and <range> property for all GPMC DT nodes
added fix for am335x-evm and am437x-epos-evm
rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap +omap-for-v3.16/dt


*changes v2 -> v3*
rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap :master
merged leftover patches (dra7-evm and am43x-epos-evm fix) from Part-1 series


*changes v1 -> v2*
[PATCH v2 1/2] created new DTS for memory-capes based on following feedbacks
  http://www.spinics.net/lists/linux-omap/msg104348.html from 'Nishanth Menon <nm@ti.com>'
  http://www.spinics.net/lists/linux-omap/msg104447.html from 'Tony Lindgren <tony@atomide.com>'
[PATCH v2 2/2] <same as [PATCH v1 1/3]>


*original v1*
This patch-set adds parallel NAND support on following TI platforms
 - AM335x (am335x-bone LT, am335x-boneblack): <disabled by default>
 - AM43xx (am437x-gp-evm)


Minal Shah (1):
  ARM: dts: dra7: add support for parallel NAND flash

Pekon Gupta (3):
  ARM: dts: am335x-bone: add support for beaglebone NAND cape
  ARM: dts: am437x-gp-evm: add support for parallel NAND flash
  ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition

 arch/arm/boot/dts/am335x-bone-memory-cape.dts | 123 ++++++++++++++++++++++++++
 arch/arm/boot/dts/am335x-bone.dts             |   1 +
 arch/arm/boot/dts/am335x-boneblack.dts        |   1 +
 arch/arm/boot/dts/am437x-gp-evm.dts           | 108 ++++++++++++++++++++++
 arch/arm/boot/dts/am43x-epos-evm.dts          |   2 +-
 arch/arm/boot/dts/dra7-evm.dts                | 118 ++++++++++++++++++++++++
 arch/arm/boot/dts/dra7.dtsi                   |  20 +++++
 7 files changed, 372 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts

-- 
1.8.5.1.163.gd7aced9

[PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Pekon Gupta]

Beaglebone Board can be connected to expansion boards to add devices to them.
These expansion boards are called 'capes'. This patch adds support for
following versions of Beaglebone(AM335x) NAND capes
(a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64
(b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224
Further information and datasheets can be found at [1] and [2]

* How to boot from NAND using Memory Expander + NAND Cape ? *
 - Important: As BOOTSEL values are sampled only at POR, so after changing any
   setting on SW2 (DIP switch), disconnect and reconnect all board power supply
   (including mini-USB console port) to POR the beaglebone.

 - Selection of ECC scheme
  for NAND cape(a), ROM code expects BCH8_HW ecc-scheme
  for NAND cape(b), ROM code expects BCH16_HW ecc-scheme

 - Selection of boot modes can be controlled via  DIP switch(SW2) present on
   Memory Expander cape, so first boot via MMC or other sources to flash NAND
   device and then switch to SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
   SW2[SWITCH_BOOT] == OFF  follow default boot order  MMC-> SPI -> UART -> USB
   SW2[SWITCH_BOOT] == ON   boot mode selected via DIP switch(SW2)

 - For NAND boot following switch settings need to be followed
   SW2[ 0] = ON   (SYSBOOT[ 0]==0: NAND boot mode selected )
   SW2[ 1] = ON   (SYSBOOT[ 1]==0:       -- do --          )
   SW2[ 2] = OFF  (SYSBOOT[ 2]==1:       -- do --          )
   SW2[ 3] = OFF  (SYSBOOT[ 3]==1:       -- do --          )
   SW2[ 4] = ON   (SYSBOOT[ 4]==0:       -- do --          )
   SW2[ 8] = OFF  (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
   SW2[ 9] = ON   (SYSBOOT[ 9]==0: ECC done by ROM  )
   SW2[10] = ON   (SYSBOOT[10]==0: Non Muxed device )
   SW2[11] = ON   (SYSBOOT[11]==0:    -- do --      )

[1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion
[2] http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module

Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
---
 arch/arm/boot/dts/am335x-bone-memory-cape.dts | 123 ++++++++++++++++++++++++++
 arch/arm/boot/dts/am335x-bone.dts             |   1 +
 arch/arm/boot/dts/am335x-boneblack.dts        |   1 +
 3 files changed, 125 insertions(+)
 create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts

diff --git a/arch/arm/boot/dts/am335x-bone-memory-cape.dts b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
new file mode 100644
index 0000000..ce3f87d
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
@@ -0,0 +1,123 @@
+/*
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This DTS adds supports for capes using GPMC interface to connect external
+ * memory like NAND, NOR Flash to Beaglebone-LT (white) and Beaglebone-Black.
+ */
+
+
+&am33xx_pinmux {
+	nand_flash_x16: nand_flash_x16 {
+		pinctrl-single,pins = <
+			0x00 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad0.gpmc_ad0 */
+			0x04 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad1.gpmc_ad1 */
+			0x08 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad2.gpmc_ad2 */
+			0x0c (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad3.gpmc_ad3 */
+			0x10 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad4.gpmc_ad4 */
+			0x14 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad5.gpmc_ad5 */
+			0x18 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad6.gpmc_ad6 */
+			0x1c (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad7.gpmc_ad7 */
+			0x20 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad8.gpmc_ad8 */
+			0x24 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad9.gpmc_ad9 */
+			0x28 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad10.gpmc_ad10 */
+			0x2c (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad11.gpmc_ad11 */
+			0x30 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad12.gpmc_ad12 */
+			0x34 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad13.gpmc_ad13 */
+			0x38 (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad14.gpmc_ad14 */
+			0x3c (MUX_MODE0 | PIN_INPUT)	/* gpmc_ad15.gpmc_ad15 */
+			0x70 (MUX_MODE0 | PIN_INPUT_PULLUP )	/* gpmc_wait0.gpmc_wait0 */
+			0x74 (MUX_MODE7 | PIN_OUTPUT_PULLUP)	/* gpmc_wpn.gpio0_30 */
+			0x7c (MUX_MODE0 | PIN_OUTPUT_PULLUP)	/* gpmc_csn0.gpmc_csn0  */
+			0x90 (MUX_MODE0 | PIN_OUTPUT)		/* gpmc_advn_ale.gpmc_advn_ale */
+			0x94 (MUX_MODE0 | PIN_OUTPUT)		/* gpmc_oen_ren.gpmc_oen_ren */
+			0x98 (MUX_MODE0 | PIN_OUTPUT)		/* gpmc_wen.gpmc_wen */
+			0x9c (MUX_MODE0 | PIN_OUTPUT)		/* gpmc_be0n_cle.gpmc_be0n_cle */
+		>;
+	};
+};
+
+&gpmc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&nand_flash_x16>;
+	ranges = <0 0 0 0x01000000>;	/* minimum GPMC partition = 16MB */
+	nand@0,0 {
+		reg = <0 0 4>;		/* device IO registers */
+		ti,nand-ecc-opt = "bch8";
+		ti,elm-id = <&elm>;
+		nand-bus-width = <16>;
+		gpmc,device-width = <2>;
+		gpmc,sync-clk-ps = <0>;
+		gpmc,cs-on-ns = <0>;
+		gpmc,cs-rd-off-ns = <80>;
+		gpmc,cs-wr-off-ns = <80>;
+		gpmc,adv-on-ns = <0>;
+		gpmc,adv-rd-off-ns = <80>;
+		gpmc,adv-wr-off-ns = <80>;
+		gpmc,we-on-ns = <20>;
+		gpmc,we-off-ns = <60>;
+		gpmc,oe-on-ns = <20>;
+		gpmc,oe-off-ns = <60>;
+		gpmc,access-ns = <40>;
+		gpmc,rd-cycle-ns = <80>;
+		gpmc,wr-cycle-ns = <80>;
+		gpmc,wait-pin = <0>;
+		gpmc,wait-on-read;
+		gpmc,wait-on-write;
+		gpmc,bus-turnaround-ns = <0>;
+		gpmc,cycle2cycle-delay-ns = <0>;
+		gpmc,clk-activation-ns = <0>;
+		gpmc,wait-monitoring-ns = <0>;
+		gpmc,wr-access-ns = <40>;
+		gpmc,wr-data-mux-bus-ns = <0>;
+		/* MTD partition table */
+		/* All SPL-* partitions are sized to minimal length
+		 * which can be independently programmable. For
+		 * NAND flash this is equal to size of erase-block */
+		#address-cells = <1>;
+		#size-cells = <1>;
+		partition@0 {
+			label = "NAND.SPL";
+			reg = <0x00000000 0x00040000>;
+		};
+		partition@1 {
+			label = "NAND.SPL.backup1";
+			reg = <0x00040000 0x00040000>;
+		};
+		partition@2 {
+			label = "NAND.SPL.backup2";
+			reg = <0x00080000 0x00040000>;
+		};
+		partition@3 {
+			label = "NAND.SPL.backup3";
+			reg = <0x000c0000 0x00040000>;
+		};
+		partition@4 {
+			label = "NAND.u-boot-spl-os";
+			reg = <0x00100000 0x00080000>;
+		};
+		partition@5 {
+			label = "NAND.u-boot";
+			reg = <0x00180000 0x00100000>;
+		};
+		partition@6 {
+			label = "NAND.u-boot-env";
+			reg = <0x00280000 0x00040000>;
+		};
+		partition@7 {
+			label = "NAND.u-boot-env.backup1";
+			reg = <0x002c0000 0x00040000>;
+		};
+		partition@8 {
+			label = "NAND.kernel";
+			reg = <0x00300000 0x00700000>;
+		};
+		partition@9 {
+			label = "NAND.file-system";
+			reg = <0x00a00000 0x1f600000>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index 94ee427..f16bfcf 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -9,6 +9,7 @@
 
 #include "am33xx.dtsi"
 #include "am335x-bone-common.dtsi"
+#include "am335x-bone-memory-cape.dts"
 
 &ldo3_reg {
 	regulator-min-microvolt = <1800000>;
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts
index 6b71ad9..c030b24 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -9,6 +9,7 @@
 
 #include "am33xx.dtsi"
 #include "am335x-bone-common.dtsi"
+#include "am335x-bone-memory-cape.dts"
 
 &ldo3_reg {
 	regulator-min-microvolt = <1800000>;
-- 
1.8.5.1.163.gd7aced9

[PATCH v7 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash

[Pekon Gupta]

Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
am437x-gp-evm board.
(1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
    eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled:
    (a) By dynamically driving following GPIO pin from software
        SPI2_CS0(GPIO) == 0 NAND is selected (default)
        SPI2_CS0(GPIO) == 1 eMMC is selected
    (b) By statically using Jumper (J89) on the board

(2) As NAND device connnected to this board has page-size=4K and oob-size=224,
    So ROM code expects boot-loaders to be flashed in BCH16 ECC scheme for
    NAND boot.

Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 108 ++++++++++++++++++++++++++++++++++++
 1 file changed, 108 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
index 30ace1b..f432685 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -150,6 +150,27 @@
 			0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
 		>;
 	};
+
+	nand_flash_x8: nand_flash_x8 {
+		pinctrl-single,pins = <
+			0x26c(PIN_OUTPUT_PULLDOWN | MUX_MODE7)	/* spi2_cs0.gpio/eMMCorNANDsel */
+			0x0  (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad0.gpmc_ad0 */
+			0x4  (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad1.gpmc_ad1 */
+			0x8  (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad2.gpmc_ad2 */
+			0xc  (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad3.gpmc_ad3 */
+			0x10 (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad4.gpmc_ad4 */
+			0x14 (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad5.gpmc_ad5 */
+			0x18 (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad6.gpmc_ad6 */
+			0x1c (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad7.gpmc_ad7 */
+			0x70 (PIN_INPUT_PULLUP | MUX_MODE0)	/* gpmc_wait0.gpmc_wait0 */
+			0x74 (PIN_OUTPUT_PULLUP | MUX_MODE7)	/* gpmc_wpn.gpmc_wpn */
+			0x7c (PIN_OUTPUT | MUX_MODE0)		/* gpmc_csn0.gpmc_csn0  */
+			0x90 (PIN_OUTPUT | MUX_MODE0)		/* gpmc_advn_ale.gpmc_advn_ale */
+			0x94 (PIN_OUTPUT | MUX_MODE0)		/* gpmc_oen_ren.gpmc_oen_ren */
+			0x98 (PIN_OUTPUT | MUX_MODE0)		/* gpmc_wen.gpmc_wen */
+			0x9c (PIN_OUTPUT | MUX_MODE0)		/* gpmc_be0n_cle.gpmc_be0n_cle */
+		>;
+	};
 };
 
 &i2c0 {
@@ -246,3 +267,90 @@
 	phy_id = <&davinci_mdio>, <0>;
 	phy-mode = "rgmii";
 };
+
+&elm {
+	status = "okay";
+};
+
+&gpmc {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&nand_flash_x8>;
+	ranges = <0 0 0 0x01000000>;	/* minimum GPMC partition = 16MB */
+	nand@0,0 {
+		reg = <0 0 4>;		/* device IO registers */
+		ti,nand-ecc-opt = "bch8";
+		ti,elm-id = <&elm>;
+		nand-bus-width = <8>;
+		gpmc,device-width = <1>;
+		gpmc,sync-clk-ps = <0>;
+		gpmc,cs-on-ns = <0>;
+		gpmc,cs-rd-off-ns = <40>;
+		gpmc,cs-wr-off-ns = <40>;
+		gpmc,adv-on-ns = <0>;
+		gpmc,adv-rd-off-ns = <25>;
+		gpmc,adv-wr-off-ns = <25>;
+		gpmc,we-on-ns = <0>;
+		gpmc,we-off-ns = <20>;
+		gpmc,oe-on-ns = <3>;
+		gpmc,oe-off-ns = <30>;
+		gpmc,access-ns = <30>;
+		gpmc,rd-cycle-ns = <40>;
+		gpmc,wr-cycle-ns = <40>;
+		gpmc,wait-pin = <0>;
+		gpmc,wait-on-read;
+		gpmc,wait-on-write;
+		gpmc,bus-turnaround-ns = <0>;
+		gpmc,cycle2cycle-delay-ns = <0>;
+		gpmc,clk-activation-ns = <0>;
+		gpmc,wait-monitoring-ns = <0>;
+		gpmc,wr-access-ns = <40>;
+		gpmc,wr-data-mux-bus-ns = <0>;
+		/* MTD partition table */
+		/* All SPL-* partitions are sized to minimal length
+		 * which can be independently programmable. For
+		 * NAND flash this is equal to size of erase-block */
+		#address-cells = <1>;
+		#size-cells = <1>;
+		partition@0 {
+			label = "NAND.SPL";
+			reg = <0x00000000 0x00040000>;
+		};
+		partition@1 {
+			label = "NAND.SPL.backup1";
+			reg = <0x00040000 0x00040000>;
+		};
+		partition@2 {
+			label = "NAND.SPL.backup2";
+			reg = <0x00080000 0x00040000>;
+		};
+		partition@3 {
+			label = "NAND.SPL.backup3";
+			reg = <0x000c0000 0x00040000>;
+		};
+		partition@4 {
+			label = "NAND.u-boot-spl-os";
+			reg = <0x00100000 0x00080000>;
+		};
+		partition@5 {
+			label = "NAND.u-boot";
+			reg = <0x00180000 0x00100000>;
+		};
+		partition@6 {
+			label = "NAND.u-boot-env";
+			reg = <0x00280000 0x00040000>;
+		};
+		partition@7 {
+			label = "NAND.u-boot-env.backup1";
+			reg = <0x002c0000 0x00040000>;
+		};
+		partition@8 {
+			label = "NAND.kernel";
+			reg = <0x00300000 0x00700000>;
+		};
+		partition@9 {
+			label = "NAND.file-system";
+			reg = <0x00a00000 0x1f600000>;
+		};
+	};
+};
-- 
1.8.5.1.163.gd7aced9

[PATCH v7 3/4] ARM: dts: dra7: add support for parallel NAND flash

[Pekon Gupta]

From: Minal Shah <minalkshah@gmail.com>

DRA7xx platform has in-build GPMC and ELM h/w engines which can be used
for accessing externel NAND flash device. This patch:
- adds generic DT binding in dra7.dtsi for enabling GPMC and ELM h/w engines
- adds DT binding for Micron NAND Flash (MT29F2G16AADWP) present on dra7-evm
*Important*
	On DRA7 EVM, GPMC_WPN and NAND_BOOTn are controlled by DIP switch
	So following board settings are required for NAND device detection:
	SW5.9 (GPMC_WPN) = LOW
	SW5.1 (NAND_BOOTn) = HIGH

Signed-off-by: Minal Shah <minalkshah@gmail.com>
Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
---
 arch/arm/boot/dts/dra7-evm.dts | 118 +++++++++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/dra7.dtsi    |  20 +++++++
 2 files changed, 138 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index ec77907..4adc280 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -120,6 +120,37 @@
 			0x284 (PIN_INPUT_SLEW | MUX_MODE0) /* usb2_drvvbus */
                 >;
         };
+
+	nand_flash_x16: nand_flash_x16 {
+		/* On DRA7 EVM, GPMC_WPN and NAND_BOOTn comes from DIP switch
+		 * So NAND flash requires following switch settings:
+		 * SW5.9 (GPMC_WPN) = LOW
+		 * SW5.1 (NAND_BOOTn) = HIGH */
+		pinctrl-single,pins = <
+			0x0 	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad0	*/
+			0x4 	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad1	*/
+			0x8 	(PIN_INPUT  | MUX_MODE0)	/* gpmc_ad2	*/
+			0xc 	(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	*/
+			0xd8	(PIN_INPUT_PULLUP  | MUX_MODE0)	/* gpmc_wait0	*/
+			0xcc	(PIN_OUTPUT | MUX_MODE0)	/* gpmc_wen	*/
+			0xb4	(PIN_OUTPUT_PULLUP | 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 {
@@ -377,3 +408,90 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&usb2_pins>;
 };
+
+&elm {
+	status = "okay";
+};
+
+&gpmc {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&nand_flash_x16>;
+	ranges = <0 0 0 0x01000000>;	/* minimum GPMC partition = 16MB */
+	nand@0,0 {
+		reg = <0 0 4>;		/* device IO registers */
+		ti,nand-ecc-opt = "bch8";
+		ti,elm-id = <&elm>;
+		nand-bus-width = <16>;
+		gpmc,device-width = <2>;
+		gpmc,sync-clk-ps = <0>;
+		gpmc,cs-on-ns = <0>;
+		gpmc,cs-rd-off-ns = <40>;
+		gpmc,cs-wr-off-ns = <40>;
+		gpmc,adv-on-ns = <0>;
+		gpmc,adv-rd-off-ns = <30>;
+		gpmc,adv-wr-off-ns = <30>;
+		gpmc,we-on-ns = <5>;
+		gpmc,we-off-ns = <25>;
+		gpmc,oe-on-ns = <2>;
+		gpmc,oe-off-ns = <20>;
+		gpmc,access-ns = <20>;
+		gpmc,wr-access-ns = <40>;
+		gpmc,rd-cycle-ns = <40>;
+		gpmc,wr-cycle-ns = <40>;
+		gpmc,wait-pin = <0>;
+		gpmc,wait-on-read;
+		gpmc,wait-on-write;
+		gpmc,bus-turnaround-ns = <0>;
+		gpmc,cycle2cycle-delay-ns = <0>;
+		gpmc,clk-activation-ns = <0>;
+		gpmc,wait-monitoring-ns = <0>;
+		gpmc,wr-data-mux-bus-ns = <0>;
+		/* MTD partition table */
+		/* All SPL-* partitions are sized to minimal length
+		 * which can be independently programmable. For
+		 * NAND flash this is equal to size of erase-block */
+		#address-cells = <1>;
+		#size-cells = <1>;
+		partition@0 {
+			label = "NAND.SPL";
+			reg = <0x00000000 0x000020000>;
+		};
+		partition@1 {
+			label = "NAND.SPL.backup1";
+			reg = <0x00020000 0x00020000>;
+		};
+		partition@2 {
+			label = "NAND.SPL.backup2";
+			reg = <0x00040000 0x00020000>;
+		};
+		partition@3 {
+			label = "NAND.SPL.backup3";
+			reg = <0x00060000 0x00020000>;
+		};
+		partition@4 {
+			label = "NAND.u-boot-spl-os";
+			reg = <0x00080000 0x00040000>;
+		};
+		partition@5 {
+			label = "NAND.u-boot";
+			reg = <0x000c0000 0x00100000>;
+		};
+		partition@6 {
+			label = "NAND.u-boot-env";
+			reg = <0x001c0000 0x00020000>;
+		};
+		partition@7 {
+			label = "NAND.u-boot-env";
+			reg = <0x001e0000 0x00020000>;
+		};
+		partition@8 {
+			label = "NAND.kernel";
+			reg = <0x00200000 0x00800000>;
+		};
+		partition@9 {
+			label = "NAND.file-system";
+			reg = <0x00a00000 0x0f600000>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 6af8b08..a8a0cee 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -964,6 +964,26 @@
 				dr_mode = "otg";
 			};
 		};
+
+		elm: elm@48078000 {
+			compatible = "ti,am3352-elm";
+			reg = <0x48078000 0xfc0>;      /* device IO registers */
+			interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+			ti,hwmods = "elm";
+			status = "disabled";
+		};
+
+		gpmc: gpmc@50000000 {
+			compatible = "ti,am3352-gpmc";
+			ti,hwmods = "gpmc";
+			reg = <0x50000000 0x37c>;      /* device IO registers */
+			interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+			gpmc,num-cs = <8>;
+			gpmc,num-waitpins = <2>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+			status = "disabled";
+		};
 	};
 };
 
-- 
1.8.5.1.163.gd7aced9

[PATCH v7 4/4] ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition

[Pekon Gupta]

MTD NAND partition for file-system should start at offset=0xA00000

Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
---
 arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
index 2a0fbbb..ad362c5 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -366,7 +366,7 @@
 		};
 		partition@9 {
 			label = "NAND.file-system";
-			reg = <0x00800000 0x1F600000>;
+			reg = <0x00a00000 0x1f600000>;
 		};
 	};
 };
-- 
1.8.5.1.163.gd7aced9

Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Tony Lindgren]

* Pekon Gupta <pekon@ti.com> [140519 02:16]:
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -9,6 +9,7 @@
>  
>  #include "am33xx.dtsi"
>  #include "am335x-bone-common.dtsi"
> +#include "am335x-bone-memory-cape.dts"
>  
>  &ldo3_reg {
>  	regulator-min-microvolt = <1800000>;
> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> @@ -9,6 +9,7 @@
>  
>  #include "am33xx.dtsi"
>  #include "am335x-bone-common.dtsi"
> +#include "am335x-bone-memory-cape.dts"
>  
>  &ldo3_reg {
>  	regulator-min-microvolt = <1800000>;

Based on the recent discussions on the capes, it seems that nobody
wants to implement toggling of the capes in u-boot. And as there
can be other capes using GPMC bus, we can't merge this. And because
the capes are stackable, we can't really have .dts files for all
the combinations. And no, we're not merging any unconnected .dts
files either, sorry.

Regards,

Tony

RE: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Gupta, Pekon]

Hi Tony,

>From: Tony Lindgren [mailto:tony@atomide.com]
>
>* Pekon Gupta <pekon@ti.com> [140519 02:16]:
>> --- a/arch/arm/boot/dts/am335x-bone.dts
>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>> @@ -9,6 +9,7 @@
>>
>>  #include "am33xx.dtsi"
>>  #include "am335x-bone-common.dtsi"
>> +#include "am335x-bone-memory-cape.dts"
>>
>>  &ldo3_reg {
>>  	regulator-min-microvolt = <1800000>;
>> --- a/arch/arm/boot/dts/am335x-boneblack.dts
>> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
>> @@ -9,6 +9,7 @@
>>
>>  #include "am33xx.dtsi"
>>  #include "am335x-bone-common.dtsi"
>> +#include "am335x-bone-memory-cape.dts"
>>
>>  &ldo3_reg {
>>  	regulator-min-microvolt = <1800000>;
>
>Based on the recent discussions on the capes, it seems that nobody
>wants to implement toggling of the capes in u-boot. And as there
>can be other capes using GPMC bus, we can't merge this. And because
>the capes are stackable, we can't really have .dts files for all
>the combinations. And no, we're not merging any unconnected .dts
>files either, sorry.
>
Yes, I fully understand. This is like death for most of the capes from point
of view of mainline support. But I have submitted this patch just for sake
of completion. And to provide reference if someone wants to locally work
on beaglebone NAND cape.
You may ignore this patch, and take the remaining ones if they are suitable.

with regards, pekon

Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Ezequiel Garcia]

On 19 May 05:52 PM, Gupta, Pekon wrote:
> Hi Tony,
> 
> >From: Tony Lindgren [mailto:tony@atomide.com]
> >
> >* Pekon Gupta <pekon@ti.com> [140519 02:16]:
> >> --- a/arch/arm/boot/dts/am335x-bone.dts
> >> +++ b/arch/arm/boot/dts/am335x-bone.dts
> >> @@ -9,6 +9,7 @@
> >>
> >>  #include "am33xx.dtsi"
> >>  #include "am335x-bone-common.dtsi"
> >> +#include "am335x-bone-memory-cape.dts"
> >>
> >>  &ldo3_reg {
> >>  	regulator-min-microvolt = <1800000>;
> >> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> >> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> >> @@ -9,6 +9,7 @@
> >>
> >>  #include "am33xx.dtsi"
> >>  #include "am335x-bone-common.dtsi"
> >> +#include "am335x-bone-memory-cape.dts"
> >>
> >>  &ldo3_reg {
> >>  	regulator-min-microvolt = <1800000>;
> >
> >Based on the recent discussions on the capes, it seems that nobody
> >wants to implement toggling of the capes in u-boot. And as there
> >can be other capes using GPMC bus, we can't merge this. And because
> >the capes are stackable, we can't really have .dts files for all
> >the combinations. And no, we're not merging any unconnected .dts
> >files either, sorry.
> >
> Yes, I fully understand. This is like death for most of the capes from point
> of view of mainline support. But I have submitted this patch just for sake
> of completion. And to provide reference if someone wants to locally work
> on beaglebone NAND cape.

While I fully agree with Tony on this, I think the reference is much
appreciated. Do you think you can push the NAND cape DT example somewhere?

Maybe some TI wiki page?
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Gupta, Pekon]

From: Ezequiel Garcia [mailto:ezequiel.garcia@free-electrons.com]
>On 19 May 05:52 PM, Gupta, Pekon wrote:
>> >From: Tony Lindgren [mailto:tony@atomide.com]
>> >Based on the recent discussions on the capes, it seems that nobody
>> >wants to implement toggling of the capes in u-boot. And as there
>> >can be other capes using GPMC bus, we can't merge this. And because
>> >the capes are stackable, we can't really have .dts files for all
>> >the combinations. And no, we're not merging any unconnected .dts
>> >files either, sorry.
>> >
>> Yes, I fully understand. This is like death for most of the capes from point
>> of view of mainline support. But I have submitted this patch just for sake
>> of completion. And to provide reference if someone wants to locally work
>> on beaglebone NAND cape.
>
>While I fully agree with Tony on this, I think the reference is much
>appreciated. Do you think you can push the NAND cape DT example somewhere?
>
>Maybe some TI wiki page?

Yes, that's my intent. I usually keep updating following TI wiki pages [1] and [2]
which I think are helpful for NAND users on OMAP platforms.

[1]  https://processors.wiki.ti.com/index.php/Linux_Core_NAND_User%27s_Guide#Board_specific_configurations
[2] https://processors.wiki.ti.com/index.php/Linux_Core_NAND_User%27s_Guide

with regards, pekon

Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Robert Nelson]

On Mon, May 19, 2014 at 1:16 PM, Ezequiel Garcia
<ezequiel.garcia@free-electrons.com> wrote:
> On 19 May 05:52 PM, Gupta, Pekon wrote:
>> Hi Tony,
>>
>> >From: Tony Lindgren [mailto:tony@atomide.com]
>> >
>> >* Pekon Gupta <pekon@ti.com> [140519 02:16]:
>> >> --- a/arch/arm/boot/dts/am335x-bone.dts
>> >> +++ b/arch/arm/boot/dts/am335x-bone.dts
>> >> @@ -9,6 +9,7 @@
>> >>
>> >>  #include "am33xx.dtsi"
>> >>  #include "am335x-bone-common.dtsi"
>> >> +#include "am335x-bone-memory-cape.dts"
>> >>
>> >>  &ldo3_reg {
>> >>    regulator-min-microvolt = <1800000>;
>> >> --- a/arch/arm/boot/dts/am335x-boneblack.dts
>> >> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
>> >> @@ -9,6 +9,7 @@
>> >>
>> >>  #include "am33xx.dtsi"
>> >>  #include "am335x-bone-common.dtsi"
>> >> +#include "am335x-bone-memory-cape.dts"
>> >>
>> >>  &ldo3_reg {
>> >>    regulator-min-microvolt = <1800000>;
>> >
>> >Based on the recent discussions on the capes, it seems that nobody
>> >wants to implement toggling of the capes in u-boot. And as there
>> >can be other capes using GPMC bus, we can't merge this. And because
>> >the capes are stackable, we can't really have .dts files for all
>> >the combinations. And no, we're not merging any unconnected .dts
>> >files either, sorry.
>> >
>> Yes, I fully understand. This is like death for most of the capes from point
>> of view of mainline support. But I have submitted this patch just for sake
>> of completion. And to provide reference if someone wants to locally work
>> on beaglebone NAND cape.
>
> While I fully agree with Tony on this, I think the reference is much
> appreciated. Do you think you can push the NAND cape DT example somewhere?
>
> Maybe some TI wiki page?

(resent in text mode for linux-omap list archive)

Since the capes are always some way tied with bb.org hardware, why
don't we put them up on https://github.com/beagleboard/ ?

am335x-capes.git ?

I envision, we should just mirror the base ./arch/arm/boot/dts/
directory (as someday the dts will be external anyways). In that repo,
we will keep these synced with mainline

am335x-bone-common.dtsi
am335x-bone.dts
am335x-boneblack.dts

and add the capes as:

<baseboard>-<cape>.dts

as a staging ground till a mainline overlay/etc system appears?

Thoughs?

-- 
Robert Nelson
http://www.rcn-ee.com/

RE: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Gupta, Pekon]

>From: Robert Nelson [mailto:robertcnelson@gmail.com]
[...]
>Since the capes are always some way tied with bb.org hardware, why
>don't we put them up on https://github.com/beagleboard/ ?
>
>am335x-capes.git ?
>
>I envision, we should just mirror the base ./arch/arm/boot/dts/
>directory (as someday the dts will be external anyways). In that repo,
>we will keep these synced with mainline
>
>am335x-bone-common.dtsi
>am335x-bone.dts
>am335x-boneblack.dts
>
>and add the capes as:
>
><baseboard>-<cape>.dts
>
>as a staging ground till a mainline overlay/etc system appears?
>
>Thoughs?
>

If you know and can convince 'Gerald Coley' then plz try. I failed :-)


with regards, pekon

Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Robert Nelson]

On Mon, May 19, 2014 at 1:51 PM, Gupta, Pekon <pekon@ti.com> wrote:
>>From: Robert Nelson [mailto:robertcnelson@gmail.com]
> [...]
>>Since the capes are always some way tied with bb.org hardware, why
>>don't we put them up on https://github.com/beagleboard/ ?
>>
>>am335x-capes.git ?
>>
>>I envision, we should just mirror the base ./arch/arm/boot/dts/
>>directory (as someday the dts will be external anyways). In that repo,
>>we will keep these synced with mainline
>>
>>am335x-bone-common.dtsi
>>am335x-bone.dts
>>am335x-boneblack.dts
>>
>>and add the capes as:
>>
>><baseboard>-<cape>.dts
>>
>>as a staging ground till a mainline overlay/etc system appears?
>>
>>Thoughs?
>>
>
> If you know and can convince 'Gerald Coley' then plz try. I failed :-)

Oh, I'll do it... ;)

I just need Jason to create the intial "repo" for me on
github.com/beagleboard and enable my permission for it.

Then i'll just pull in the capes in that repo and push it to my
"--beta-kernel" option for users running the new debian image who
would like run mainline over the old v3.8.x

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Robert Nelson]

On Mon, May 19, 2014 at 2:11 PM, Kridner, Jason <jdk@ti.com> wrote:
>
>
> On May 19, 2014, at 11:58 AM, "Robert Nelson" <robertcnelson@gmail.com>
> wrote:
>
> On Mon, May 19, 2014 at 1:51 PM, Gupta, Pekon <pekon@ti.com> wrote:
>
> From: Robert Nelson [mailto:robertcnelson@gmail.com]
>
> [...]
>
> Since the capes are always some way tied with bb.org hardware, why
>
> don't we put them up on https://github.com/beagleboard/ ?
>
>
> am335x-capes.git ?
>
>
> I envision, we should just mirror the base ./arch/arm/boot/dts/
>
> directory (as someday the dts will be external anyways). In that repo,
>
> we will keep these synced with mainline
>
>
> am335x-bone-common.dtsi
>
> am335x-bone.dts
>
> am335x-boneblack.dts
>
>
> and add the capes as:
>
>
> <baseboard>-<cape>.dts
>
>
> as a staging ground till a mainline overlay/etc system appears?
>
>
> Thoughs?
>
>
>
> If you know and can convince 'Gerald Coley' then plz try. I failed :-)
>
>
> Oh, I'll do it... ;)
>
> I just need Jason to create the intial "repo" for me on
> github.com/beagleboard and enable my permission for it.
>
>
> I believe this is the same reason I created
> https://github.com/beagleboard/cape-firmware.  Is something else needed?

Hi Jason,

Same exact idea. But instead of the "overlay" dts's that get installed
in /lib/firmware/ this will be for the main kernel dtb files, that'll
be dumped in /boot/dtbs/*.dtb or /boot/*.dtb.  In theory we should be
able to build these outside kernel.org, so down the road we can add a
package for all the other distro's.

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Kridner, Jason]

> On May 19, 2014, at 12:22 PM, "Robert Nelson" <robertcnelson@gmail.com> wrote:
> 
>> On Mon, May 19, 2014 at 2:11 PM, Kridner, Jason <jdk@ti.com> wrote:
>> 
>> 
>> On May 19, 2014, at 11:58 AM, "Robert Nelson" <robertcnelson@gmail.com>
>> wrote:
>> 
>> On Mon, May 19, 2014 at 1:51 PM, Gupta, Pekon <pekon@ti.com> wrote:
>> 
>> From: Robert Nelson [mailto:robertcnelson@gmail.com]
>> 
>> [...]
>> 
>> Since the capes are always some way tied with bb.org hardware, why
>> 
>> don't we put them up on https://github.com/beagleboard/ ?
>> 
>> 
>> am335x-capes.git ?
>> 
>> 
>> I envision, we should just mirror the base ./arch/arm/boot/dts/
>> 
>> directory (as someday the dts will be external anyways). In that repo,
>> 
>> we will keep these synced with mainline
>> 
>> 
>> am335x-bone-common.dtsi
>> 
>> am335x-bone.dts
>> 
>> am335x-boneblack.dts
>> 
>> 
>> and add the capes as:
>> 
>> 
>> <baseboard>-<cape>.dts
>> 
>> 
>> as a staging ground till a mainline overlay/etc system appears?
>> 
>> 
>> Thoughs?
>> 
>> 
>> 
>> If you know and can convince 'Gerald Coley' then plz try. I failed :-)
>> 
>> 
>> Oh, I'll do it... ;)
>> 
>> I just need Jason to create the intial "repo" for me on
>> github.com/beagleboard and enable my permission for it.
>> 
>> 
>> I believe this is the same reason I created
>> https://github.com/beagleboard/cape-firmware.  Is something else needed?
> 
> Hi Jason,
> 
> Same exact idea. But instead of the "overlay" dts's that get installed
> in /lib/firmware/ this will be for the main kernel dtb files, that'll
> be dumped in /boot/dtbs/*.dtb or /boot/*.dtb.  In theory we should be
> able to build these outside kernel.org, so down the road we can add a
> package for all the other distro's.

Why not reuse the same repo since the capes would be in there too? Does it need renaming?

> 
> Regards,
> 
> -- 
> Robert Nelson
> http://www.rcn-ee.com/

Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Robert Nelson]

>>>
>>> I believe this is the same reason I created
>>> https://github.com/beagleboard/cape-firmware.  Is something else needed?
>>
>> Hi Jason,
>>
>> Same exact idea. But instead of the "overlay" dts's that get installed
>> in /lib/firmware/ this will be for the main kernel dtb files, that'll
>> be dumped in /boot/dtbs/*.dtb or /boot/*.dtb.  In theory we should be
>> able to build these outside kernel.org, so down the road we can add a
>> package for all the other distro's.
>
> Why not reuse the same repo since the capes would be in there too? Does it need renaming?

Okay, i'll work with that repo and get something for v3.15.x/v3.16.x cleaned up.

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

Re: [PATCH v7 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash

[Tony Lindgren]

* Pekon Gupta <pekon@ti.com> [140519 02:16]:
> Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
> am437x-gp-evm board.
> (1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
>     eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled:
>     (a) By dynamically driving following GPIO pin from software
>         SPI2_CS0(GPIO) == 0 NAND is selected (default)
>         SPI2_CS0(GPIO) == 1 eMMC is selected
>     (b) By statically using Jumper (J89) on the board

So which MMC controller has eMMC then? How do we select which one we
have enabled in the am437x-gp-evm.dts by default?

Regards,

Tony
 
> (2) As NAND device connnected to this board has page-size=4K and oob-size=224,
>     So ROM code expects boot-loaders to be flashed in BCH16 ECC scheme for
>     NAND boot.
> 
> Signed-off-by: Pekon Gupta <pekon@ti.com>
> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
> ---
>  arch/arm/boot/dts/am437x-gp-evm.dts | 108 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 108 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
> index 30ace1b..f432685 100644
> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
> @@ -150,6 +150,27 @@
>  			0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
>  		>;
>  	};
> +
> +	nand_flash_x8: nand_flash_x8 {
> +		pinctrl-single,pins = <
> +			0x26c(PIN_OUTPUT_PULLDOWN | MUX_MODE7)	/* spi2_cs0.gpio/eMMCorNANDsel */
> +			0x0  (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad0.gpmc_ad0 */
> +			0x4  (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad1.gpmc_ad1 */
> +			0x8  (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad2.gpmc_ad2 */
> +			0xc  (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad3.gpmc_ad3 */
> +			0x10 (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad4.gpmc_ad4 */
> +			0x14 (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad5.gpmc_ad5 */
> +			0x18 (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad6.gpmc_ad6 */
> +			0x1c (PIN_INPUT  | MUX_MODE0)	/* gpmc_ad7.gpmc_ad7 */
> +			0x70 (PIN_INPUT_PULLUP | MUX_MODE0)	/* gpmc_wait0.gpmc_wait0 */
> +			0x74 (PIN_OUTPUT_PULLUP | MUX_MODE7)	/* gpmc_wpn.gpmc_wpn */
> +			0x7c (PIN_OUTPUT | MUX_MODE0)		/* gpmc_csn0.gpmc_csn0  */
> +			0x90 (PIN_OUTPUT | MUX_MODE0)		/* gpmc_advn_ale.gpmc_advn_ale */
> +			0x94 (PIN_OUTPUT | MUX_MODE0)		/* gpmc_oen_ren.gpmc_oen_ren */
> +			0x98 (PIN_OUTPUT | MUX_MODE0)		/* gpmc_wen.gpmc_wen */
> +			0x9c (PIN_OUTPUT | MUX_MODE0)		/* gpmc_be0n_cle.gpmc_be0n_cle */
> +		>;
> +	};
>  };
>  
>  &i2c0 {
> @@ -246,3 +267,90 @@
>  	phy_id = <&davinci_mdio>, <0>;
>  	phy-mode = "rgmii";
>  };
> +
> +&elm {
> +	status = "okay";
> +};
> +
> +&gpmc {
> +	status = "okay";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&nand_flash_x8>;
> +	ranges = <0 0 0 0x01000000>;	/* minimum GPMC partition = 16MB */
> +	nand@0,0 {
> +		reg = <0 0 4>;		/* device IO registers */
> +		ti,nand-ecc-opt = "bch8";
> +		ti,elm-id = <&elm>;
> +		nand-bus-width = <8>;
> +		gpmc,device-width = <1>;
> +		gpmc,sync-clk-ps = <0>;
> +		gpmc,cs-on-ns = <0>;
> +		gpmc,cs-rd-off-ns = <40>;
> +		gpmc,cs-wr-off-ns = <40>;
> +		gpmc,adv-on-ns = <0>;
> +		gpmc,adv-rd-off-ns = <25>;
> +		gpmc,adv-wr-off-ns = <25>;
> +		gpmc,we-on-ns = <0>;
> +		gpmc,we-off-ns = <20>;
> +		gpmc,oe-on-ns = <3>;
> +		gpmc,oe-off-ns = <30>;
> +		gpmc,access-ns = <30>;
> +		gpmc,rd-cycle-ns = <40>;
> +		gpmc,wr-cycle-ns = <40>;
> +		gpmc,wait-pin = <0>;
> +		gpmc,wait-on-read;
> +		gpmc,wait-on-write;
> +		gpmc,bus-turnaround-ns = <0>;
> +		gpmc,cycle2cycle-delay-ns = <0>;
> +		gpmc,clk-activation-ns = <0>;
> +		gpmc,wait-monitoring-ns = <0>;
> +		gpmc,wr-access-ns = <40>;
> +		gpmc,wr-data-mux-bus-ns = <0>;
> +		/* MTD partition table */
> +		/* All SPL-* partitions are sized to minimal length
> +		 * which can be independently programmable. For
> +		 * NAND flash this is equal to size of erase-block */
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		partition@0 {
> +			label = "NAND.SPL";
> +			reg = <0x00000000 0x00040000>;
> +		};
> +		partition@1 {
> +			label = "NAND.SPL.backup1";
> +			reg = <0x00040000 0x00040000>;
> +		};
> +		partition@2 {
> +			label = "NAND.SPL.backup2";
> +			reg = <0x00080000 0x00040000>;
> +		};
> +		partition@3 {
> +			label = "NAND.SPL.backup3";
> +			reg = <0x000c0000 0x00040000>;
> +		};
> +		partition@4 {
> +			label = "NAND.u-boot-spl-os";
> +			reg = <0x00100000 0x00080000>;
> +		};
> +		partition@5 {
> +			label = "NAND.u-boot";
> +			reg = <0x00180000 0x00100000>;
> +		};
> +		partition@6 {
> +			label = "NAND.u-boot-env";
> +			reg = <0x00280000 0x00040000>;
> +		};
> +		partition@7 {
> +			label = "NAND.u-boot-env.backup1";
> +			reg = <0x002c0000 0x00040000>;
> +		};
> +		partition@8 {
> +			label = "NAND.kernel";
> +			reg = <0x00300000 0x00700000>;
> +		};
> +		partition@9 {
> +			label = "NAND.file-system";
> +			reg = <0x00a00000 0x1f600000>;
> +		};
> +	};
> +};
> -- 
> 1.8.5.1.163.gd7aced9
> 

Re: [PATCH v7 3/4] ARM: dts: dra7: add support for parallel NAND flash

[Tony Lindgren]

* Pekon Gupta <pekon@ti.com> [140519 02:16]:
> From: Minal Shah <minalkshah@gmail.com>
> 
> DRA7xx platform has in-build GPMC and ELM h/w engines which can be used
> for accessing externel NAND flash device. This patch:
> - adds generic DT binding in dra7.dtsi for enabling GPMC and ELM h/w engines
> - adds DT binding for Micron NAND Flash (MT29F2G16AADWP) present on dra7-evm
> *Important*
> 	On DRA7 EVM, GPMC_WPN and NAND_BOOTn are controlled by DIP switch
> 	So following board settings are required for NAND device detection:
> 	SW5.9 (GPMC_WPN) = LOW
> 	SW5.1 (NAND_BOOTn) = HIGH
> 
> Signed-off-by: Minal Shah <minalkshah@gmail.com>
> Signed-off-by: Pekon Gupta <pekon@ti.com>
> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>

Thanks applying this into omap-for-v3.16/dt.

Tony

Re: [PATCH v7 4/4] ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition

[Tony Lindgren]

* Pekon Gupta <pekon@ti.com> [140519 02:16]:
> MTD NAND partition for file-system should start at offset=0xA00000
> 
> Signed-off-by: Pekon Gupta <pekon@ti.com>
> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>

Applying this too into omap-for-v3.16/dt.

Tony

> ---
>  arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
> index 2a0fbbb..ad362c5 100644
> --- a/arch/arm/boot/dts/am43x-epos-evm.dts
> +++ b/arch/arm/boot/dts/am43x-epos-evm.dts
> @@ -366,7 +366,7 @@
>  		};
>  		partition@9 {
>  			label = "NAND.file-system";
> -			reg = <0x00800000 0x1F600000>;
> +			reg = <0x00a00000 0x1f600000>;
>  		};
>  	};
>  };
> -- 
> 1.8.5.1.163.gd7aced9
> 

RE: [PATCH v7 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash

[Gupta, Pekon]

From: Tony Lindgren [mailto:tony@atomide.com]
>* Pekon Gupta <pekon@ti.com> [140519 02:16]:
>> Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
>> am437x-gp-evm board.
>> (1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
>>     eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled:
>>     (a) By dynamically driving following GPIO pin from software
>>         SPI2_CS0(GPIO) == 0 NAND is selected (default)
>>         SPI2_CS0(GPIO) == 1 eMMC is selected
>>     (b) By statically using Jumper (J89) on the board
>
>So which MMC controller has eMMC then? How do we select which one we
>have enabled in the am437x-gp-evm.dts by default?
>
If there is no Jumper on the board, then driving SPI2_CS0 before device
probe decides the selection between NAND and eMMC. Therefore NAND
pin-mux also includes SPI2_CS0 and enables PULLDOWN on it to select NAND.

+ 0x26c(PIN_OUTPUT_PULLDOWN | MUX_MODE7)	/* spi2_cs0.gpio/eMMCorNANDsel */

>Regards,
>
>Tony
>
>> (2) As NAND device connnected to this board has page-size=4K and oob-size=224,
>>     So ROM code expects boot-loaders to be flashed in BCH16 ECC scheme for
>>     NAND boot.
>>
>> Signed-off-by: Pekon Gupta <pekon@ti.com>
>> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
>> ---
>>  arch/arm/boot/dts/am437x-gp-evm.dts | 108 ++++++++++++++++++++++++++++++++++++
>>  1 file changed, 108 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
>> index 30ace1b..f432685 100644
>> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
>> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
>> @@ -150,6 +150,27 @@
>>  			0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
>>  		>;
>>  	};
>> +
>> +	nand_flash_x8: nand_flash_x8 {
>> +		pinctrl-single,pins = <
>> +			0x26c(PIN_OUTPUT_PULLDOWN | MUX_MODE7)	/*  <------
>spi2_cs0.gpio/eMMCorNANDsel */


with regards, pekon

Re: [PATCH v7 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash

[Tony Lindgren]

* Gupta, Pekon <pekon@ti.com> [140519 21:07]:
> From: Tony Lindgren [mailto:tony@atomide.com]
> >* Pekon Gupta <pekon@ti.com> [140519 02:16]:
> >> Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
> >> am437x-gp-evm board.
> >> (1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
> >>     eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled:
> >>     (a) By dynamically driving following GPIO pin from software
> >>         SPI2_CS0(GPIO) == 0 NAND is selected (default)
> >>         SPI2_CS0(GPIO) == 1 eMMC is selected
> >>     (b) By statically using Jumper (J89) on the board
> >
> >So which MMC controller has eMMC then? How do we select which one we
> >have enabled in the am437x-gp-evm.dts by default?
> >
> If there is no Jumper on the board, then driving SPI2_CS0 before device
> probe decides the selection between NAND and eMMC. Therefore NAND
> pin-mux also includes SPI2_CS0 and enables PULLDOWN on it to select NAND.

So do they share lines outside omap, not inside omap?

The reason I'm asking is I'm worried about the conflicting
pinctrl settings if we try to use both. And I guess that's
not an issue if the muxing of lines is done outside the
omap?

Regards,

Tony 

RE: [PATCH v7 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash

[Gupta, Pekon]

From: Tony Lindgren [mailto:tony@atomide.com]
>* Gupta, Pekon <pekon@ti.com> [140519 21:07]:
>> From: Tony Lindgren [mailto:tony@atomide.com]
>> >* Pekon Gupta <pekon@ti.com> [140519 02:16]:
>> >> Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
>> >> am437x-gp-evm board.
>> >> (1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
>> >>     eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled:
>> >>     (a) By dynamically driving following GPIO pin from software
>> >>         SPI2_CS0(GPIO) == 0 NAND is selected (default)
>> >>         SPI2_CS0(GPIO) == 1 eMMC is selected
>> >>     (b) By statically using Jumper (J89) on the board
>> >
>> >So which MMC controller has eMMC then? How do we select which one we
>> >have enabled in the am437x-gp-evm.dts by default?
>> >
>> If there is no Jumper on the board, then driving SPI2_CS0 before device
>> probe decides the selection between NAND and eMMC. Therefore NAND
>> pin-mux also includes SPI2_CS0 and enables PULLDOWN on it to select NAND.
>
>So do they share lines outside omap, not inside omap?
>
>The reason I'm asking is I'm worried about the conflicting
>pinctrl settings if we try to use both. And I guess that's
>not an issue if the muxing of lines is done outside the
>omap?
>
Yes, the muxing is outside OMAP SoC, so if SPI2_CS0 is correctly
driven it will not allow contention on GPMC line (as per board design).

On am437x-gp-evm board, SPI2_CS0 is used to:
- route GPMC signals to selected device {eMMC | NAND}.
- keep the de-selected device {eMMC | NAND} in reset.

with regards, pekon

Re: [PATCH v7 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash

[Tony Lindgren]

* Gupta, Pekon <pekon@ti.com> [140519 23:10]:
> From: Tony Lindgren [mailto:tony@atomide.com]
> >* Gupta, Pekon <pekon@ti.com> [140519 21:07]:
> >> From: Tony Lindgren [mailto:tony@atomide.com]
> >> >* Pekon Gupta <pekon@ti.com> [140519 02:16]:
> >> >> Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
> >> >> am437x-gp-evm board.
> >> >> (1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
> >> >>     eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled:
> >> >>     (a) By dynamically driving following GPIO pin from software
> >> >>         SPI2_CS0(GPIO) == 0 NAND is selected (default)
> >> >>         SPI2_CS0(GPIO) == 1 eMMC is selected
> >> >>     (b) By statically using Jumper (J89) on the board
> >> >
> >> >So which MMC controller has eMMC then? How do we select which one we
> >> >have enabled in the am437x-gp-evm.dts by default?
> >> >
> >> If there is no Jumper on the board, then driving SPI2_CS0 before device
> >> probe decides the selection between NAND and eMMC. Therefore NAND
> >> pin-mux also includes SPI2_CS0 and enables PULLDOWN on it to select NAND.
> >
> >So do they share lines outside omap, not inside omap?
> >
> >The reason I'm asking is I'm worried about the conflicting
> >pinctrl settings if we try to use both. And I guess that's
> >not an issue if the muxing of lines is done outside the
> >omap?
> >
> Yes, the muxing is outside OMAP SoC, so if SPI2_CS0 is correctly
> driven it will not allow contention on GPMC line (as per board design).
> 
> On am437x-gp-evm board, SPI2_CS0 is used to:
> - route GPMC signals to selected device {eMMC | NAND}.
> - keep the de-selected device {eMMC | NAND} in reset.

OK thanks for clarifying that, applying into omap-for-v3.16/dt-v2.

Regards,

Tony

RE: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Gupta, Pekon]

Hi Tony,

Just reviving this thread for some information..

>From: Tony Lindgren [mailto:tony@atomide.com]
>Sent: Monday, May 19, 2014 9:56 PM
>To: Gupta, Pekon
>Cc: linux-omap; Ezequiel Garcia; Stefan Roese; Javier Martinez Canillas; Quadros, Roger
>Subject: Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
>
>* Pekon Gupta <pekon@ti.com> [140519 02:16]:
>> --- a/arch/arm/boot/dts/am335x-bone.dts
>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>> @@ -9,6 +9,7 @@
>>
>>  #include "am33xx.dtsi"
>>  #include "am335x-bone-common.dtsi"
>> +#include "am335x-bone-memory-cape.dts"
>>
>>  &ldo3_reg {
>>  	regulator-min-microvolt = <1800000>;
>> --- a/arch/arm/boot/dts/am335x-boneblack.dts
>> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
>> @@ -9,6 +9,7 @@
>>
>>  #include "am33xx.dtsi"
>>  #include "am335x-bone-common.dtsi"
>> +#include "am335x-bone-memory-cape.dts"
>>
>>  &ldo3_reg {
>>  	regulator-min-microvolt = <1800000>;
>
>Based on the recent discussions on the capes, it seems that nobody
>wants to implement toggling of the capes in u-boot. And as there
>can be other capes using GPMC bus, we can't merge this.

I have been able to get toggling of capes (enabling and disabling of DT nodes)
in u-boot. It was already there in u-boot mainline [1], may be no-body tried it.

Example: Below sequence works for NAND cape patch mentioned in this thread.
---------------
/* load DTB */
u-boot> tftp 0x81000000 am335x-boneblack.dtb
u-boot> fdt addr 0x81000000
/* disable MMC2 node */
u-boot> fdt list /ocp/mmc@481d8000
u-boot> fdt set  /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
u-boot> fdt list /ocp/mmc@481d8000 status
/* enable GPMC node */
u-boot> fdt list /ocp/gpmc
u-boot> fdt set  /ocp/gpmc status \o\k\a\y
u-boot> fdt list /ocp/gpmc status
/* enable ELM node */
u-boot> fdt list /ocp/elm
u-boot> fdt set  /ocp/elm status \o\k\a\y
u-boot> fdt list /ocp/elm status
/* boot uImage */
tftp 0x82000000 uImage
bootm 0x82000000 - 0x81000000

Note: "fdt set" command does not accept string literals
as binding values, it internally converts them to string, so
escape sequenced characters were used here..
"okay" == \o\k\a\y
"disabled" == \d\i\s\a\b\l\e\d"
---------------


> And because
>the capes are stackable, we can't really have .dts files for all
>the combinations. And no, we're not merging any unconnected .dts
>files either, sorry.
>
As per earlier proposal, we can have single DT files for similar
functionality capes like;
- am335x-bone-memory-cape.dts: for all Flash/Memory related capes like NAND, NOR, eMMC, etc.
- am335x-bone-display-cape.dts: for all display related capes like LCD4, LCD7..
This way you will have countable number of DTS files to maintain
And any conflict if ever in between capes can be contained within these files.

Does this suffice the requirement to accept cape DTS in mainline 
(with default state as disabled) ?

I'm re-invoking this thread because there are quite a number of
hobbyist and developers stuck without proper DT support of these
capes, so having them in mainline is better than providing a internal
or separately maintained tree.

>Regards,
>
>Tony

with regards, pekon

[1] http://www.denx.de/wiki/view/DULG/UBootCmdFDT

Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Tony Lindgren]

* Gupta, Pekon <pekon@ti.com> [140622 22:42]:
> Hi Tony,
> 
> Just reviving this thread for some information..
> 
> >From: Tony Lindgren [mailto:tony@atomide.com]
> >Sent: Monday, May 19, 2014 9:56 PM
> >To: Gupta, Pekon
> >Cc: linux-omap; Ezequiel Garcia; Stefan Roese; Javier Martinez Canillas; Quadros, Roger
> >Subject: Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
> >
> >* Pekon Gupta <pekon@ti.com> [140519 02:16]:
> >> --- a/arch/arm/boot/dts/am335x-bone.dts
> >> +++ b/arch/arm/boot/dts/am335x-bone.dts
> >> @@ -9,6 +9,7 @@
> >>
> >>  #include "am33xx.dtsi"
> >>  #include "am335x-bone-common.dtsi"
> >> +#include "am335x-bone-memory-cape.dts"
> >>
> >>  &ldo3_reg {
> >>  	regulator-min-microvolt = <1800000>;
> >> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> >> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> >> @@ -9,6 +9,7 @@
> >>
> >>  #include "am33xx.dtsi"
> >>  #include "am335x-bone-common.dtsi"
> >> +#include "am335x-bone-memory-cape.dts"
> >>
> >>  &ldo3_reg {
> >>  	regulator-min-microvolt = <1800000>;
> >
> >Based on the recent discussions on the capes, it seems that nobody
> >wants to implement toggling of the capes in u-boot. And as there
> >can be other capes using GPMC bus, we can't merge this.
> 
> I have been able to get toggling of capes (enabling and disabling of DT nodes)
> in u-boot. It was already there in u-boot mainline [1], may be no-body tried it.
> 
> Example: Below sequence works for NAND cape patch mentioned in this thread.
> ---------------
> /* load DTB */
> u-boot> tftp 0x81000000 am335x-boneblack.dtb
> u-boot> fdt addr 0x81000000
> /* disable MMC2 node */
> u-boot> fdt list /ocp/mmc@481d8000
> u-boot> fdt set  /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
> u-boot> fdt list /ocp/mmc@481d8000 status
> /* enable GPMC node */
> u-boot> fdt list /ocp/gpmc
> u-boot> fdt set  /ocp/gpmc status \o\k\a\y
> u-boot> fdt list /ocp/gpmc status
> /* enable ELM node */
> u-boot> fdt list /ocp/elm
> u-boot> fdt set  /ocp/elm status \o\k\a\y
> u-boot> fdt list /ocp/elm status
> /* boot uImage */
> tftp 0x82000000 uImage
> bootm 0x82000000 - 0x81000000
> 
> Note: "fdt set" command does not accept string literals
> as binding values, it internally converts them to string, so
> escape sequenced characters were used here..
> "okay" == \o\k\a\y
> "disabled" == \d\i\s\a\b\l\e\d"

Cool. Now all we need is a few helper functions in u-boot
so it can be done a bit easier :)

Regards,

Tony

Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Jason Kridner]

On Mon, Jun 23, 2014 at 1:48 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Gupta, Pekon <pekon@ti.com> [140622 22:42]:
>> Hi Tony,
>>
>> Just reviving this thread for some information..
>>
>> >From: Tony Lindgren [mailto:tony@atomide.com]
>> >Sent: Monday, May 19, 2014 9:56 PM
>> >To: Gupta, Pekon
>> >Cc: linux-omap; Ezequiel Garcia; Stefan Roese; Javier Martinez Canillas; Quadros, Roger
>> >Subject: Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
>> >
>> >* Pekon Gupta <pekon@ti.com> [140519 02:16]:
>> >> --- a/arch/arm/boot/dts/am335x-bone.dts
>> >> +++ b/arch/arm/boot/dts/am335x-bone.dts
>> >> @@ -9,6 +9,7 @@
>> >>
>> >>  #include "am33xx.dtsi"
>> >>  #include "am335x-bone-common.dtsi"
>> >> +#include "am335x-bone-memory-cape.dts"
>> >>
>> >>  &ldo3_reg {
>> >>    regulator-min-microvolt = <1800000>;
>> >> --- a/arch/arm/boot/dts/am335x-boneblack.dts
>> >> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
>> >> @@ -9,6 +9,7 @@
>> >>
>> >>  #include "am33xx.dtsi"
>> >>  #include "am335x-bone-common.dtsi"
>> >> +#include "am335x-bone-memory-cape.dts"
>> >>
>> >>  &ldo3_reg {
>> >>    regulator-min-microvolt = <1800000>;
>> >
>> >Based on the recent discussions on the capes, it seems that nobody
>> >wants to implement toggling of the capes in u-boot. And as there
>> >can be other capes using GPMC bus, we can't merge this.
>>
>> I have been able to get toggling of capes (enabling and disabling of DT nodes)
>> in u-boot. It was already there in u-boot mainline [1], may be no-body tried it.
>>
>> Example: Below sequence works for NAND cape patch mentioned in this thread.
>> ---------------
>> /* load DTB */
>> u-boot> tftp 0x81000000 am335x-boneblack.dtb
>> u-boot> fdt addr 0x81000000
>> /* disable MMC2 node */
>> u-boot> fdt list /ocp/mmc@481d8000
>> u-boot> fdt set  /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
>> u-boot> fdt list /ocp/mmc@481d8000 status
>> /* enable GPMC node */
>> u-boot> fdt list /ocp/gpmc
>> u-boot> fdt set  /ocp/gpmc status \o\k\a\y
>> u-boot> fdt list /ocp/gpmc status
>> /* enable ELM node */
>> u-boot> fdt list /ocp/elm
>> u-boot> fdt set  /ocp/elm status \o\k\a\y
>> u-boot> fdt list /ocp/elm status
>> /* boot uImage */
>> tftp 0x82000000 uImage
>> bootm 0x82000000 - 0x81000000
>>
>> Note: "fdt set" command does not accept string literals
>> as binding values, it internally converts them to string, so
>> escape sequenced characters were used here..
>> "okay" == \o\k\a\y
>> "disabled" == \d\i\s\a\b\l\e\d"
>
> Cool. Now all we need is a few helper functions in u-boot
> so it can be done a bit easier :)
>

The association of devicetree overlay files in /lib/firmware to cape
IDs made it where the kernel-based cape overlay manager could modify
the devicetree as needed without putting extensive cape-specific logic
in the kernel or bootloader. Throwing a bunch of capes into a single
class of capes won't save any work there. If we can get the bootloader
to support the .dtbo files, then we can continue to use the ID in the
cape to provide all the DT modifications we need. If we need to do
scripts for the modifications, we'd still need to associate the cape
ID to that script.

This still doesn't cover the need for run-time devicetree
modification, but I'll leave that for the other on-going thread.

I do agree with the idea of moving more of the potential sources of
conflict that can be resolved out of the overlays and into the main
devicetree, leaving the overlays or scripts simply to deal with the
conflicts that cannot be resolved at run-time given the current
infrastructure. I just think they should go into .dtsi (include) files
for the main .dts/.dtb files for the boards, rather than additional
overlays or alternative .dts files.

RE: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Gupta, Pekon]

>From: Jason Kridner [mailto:jkridner@gmail.com]
>>On Mon, Jun 23, 2014 at 1:48 AM, Tony Lindgren <tony@atomide.com> wrote:
>>> * Gupta, Pekon <pekon@ti.com> [140622 22:42]:
>>> >From: Tony Lindgren [mailto:tony@atomide.com]

[...]

>>> >Based on the recent discussions on the capes, it seems that nobody
>>> >wants to implement toggling of the capes in u-boot. And as there
>>> >can be other capes using GPMC bus, we can't merge this.
>>>
>>> I have been able to get toggling of capes (enabling and disabling of DT nodes)
>>> in u-boot. It was already there in u-boot mainline [1], may be no-body tried it.
>>>
>>> Example: Below sequence works for NAND cape patch mentioned in this thread.
>>> ---------------
>>> /* load DTB */
>>> u-boot> tftp 0x81000000 am335x-boneblack.dtb
>>> u-boot> fdt addr 0x81000000
>>> /* disable MMC2 node */
>>> u-boot> fdt list /ocp/mmc@481d8000
>>> u-boot> fdt set  /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
>>> u-boot> fdt list /ocp/mmc@481d8000 status
>>> /* enable GPMC node */
>>> u-boot> fdt list /ocp/gpmc
>>> u-boot> fdt set  /ocp/gpmc status \o\k\a\y
>>> u-boot> fdt list /ocp/gpmc status
>>> /* enable ELM node */
>>> u-boot> fdt list /ocp/elm
>>> u-boot> fdt set  /ocp/elm status \o\k\a\y
>>> u-boot> fdt list /ocp/elm status
>>> /* boot uImage */
>>> tftp 0x82000000 uImage
>>> bootm 0x82000000 - 0x81000000
>>>
>>> Note: "fdt set" command does not accept string literals
>>> as binding values, it internally converts them to string, so
>>> escape sequenced characters were used here..
>>> "okay" == \o\k\a\y
>>> "disabled" == \d\i\s\a\b\l\e\d"
>>
>> Cool. Now all we need is a few helper functions in u-boot
>> so it can be done a bit easier :)
>>
>
>The association of devicetree overlay files in /lib/firmware to cape
>IDs made it where the kernel-based cape overlay manager could modify
>the devicetree as needed without putting extensive cape-specific logic
>in the kernel or bootloader. Throwing a bunch of capes into a single
>class of capes won't save any work there.
>
I'm classifying capes based on functionality to reduce the number of
DTS files, because in general people will not both LCD4 and LCD7 capes
together, similarly not many will use NAND, NOR and eMMC simulataneously.
- am335x-bone-memory-cape.dts: will have NAND, NOR and storage related capes
- am335x-bone-display-cape.dts: will have LCD4, LCD7, ... etc capes.


> If we can get the bootloader
>to support the .dtbo files, then we can continue to use the ID in the
>cape to provide all the DT modifications we need. If we need to do
>scripts for the modifications, we'd still need to associate the cape
>ID to that script.
>
With ID based auto-identification of Capes, we need EEPROM or
e-fuses on every cape. And today I don't think all third-party capes
have EEPROM on them.
Also, with increase in number of cape, it will be hard to maintain
ID grouping and updating firmware/software for each new cape.


>
>This still doesn't cover the need for run-time devicetree
>modification, but I'll leave that for the other on-going thread.
>
I'm just proposing the u-boot way of enabling/disabling DT.
This is certainly not replacing requirement for DT overlay manager,
But till the time DT overlay is available in kernel, this would at-least
be an placeholder and would encourage Beaglebone users to
continue using mainline kernel.
This why I'm trying to get basic cape DTS in mainline, so that
Beaglebone community continues to be in touch with mainline.
Tomorrow if DT overlay comes, then we may choose to either keep
these cape DTS, or delete them from mainline without breaking any
backward compatibility.


>I do agree with the idea of moving more of the potential sources of
>conflict that can be resolved out of the overlays and into the main
>devicetree, leaving the overlays or scripts simply to deal with the
>conflicts that cannot be resolved at run-time given the current
>infrastructure. I just think they should go into .dtsi (include) files
>for the main .dts/.dtb files for the boards, rather than additional
>overlays or alternative .dts files.
>
Yes, that is the main motive, to resolve _known_ conflicts before
Run-time. And keep things working till 'DT overlay' is mainlined.

Another thing which I'm not sure is how DT overlay will work
with capes which are required during boot?
Example: NAND, NOR capes themselves containing file-system.
I think in such scenarios using u-boot approach for enabling/disabling
capes would be beneficial.


If you and others are okay with this approach, I would request you
to please provide your "Tested-by" for few cape DTS patches I
will be posting soon. This would give confidence that cape DTS
patches are not breaking anything in existing DTS.


Thanks..
with regards, pekon