* [PATCH v1 0/3] add parallel NAND support for TI's new OMAPx and AMxx platforms (Part-2)
@ 2014-03-12 10:49 ` Pekon Gupta
0 siblings, 0 replies; 60+ messages in thread
From: Pekon Gupta @ 2014-03-12 10:49 UTC (permalink / raw)
To: Tony Lindgren, bcousson; +Cc: linux-omap, linux-mtd, Pekon Gupta
This patch-set adds parallel NAND support on following TI platforms
- AM335x (am335x-bone LT, am335x-boneblack): <disabled by default>
- AM43xx (am437x-gp-evm)
Pekon Gupta (3):
ARM: dts: am335x-bone: add support for beaglebone NAND cape
ARM: dts: am335x-boneblack: add support for beaglebone NAND cape
ARM: dts: am437x-gp-evm: add support for parallel NAND flash
arch/arm/boot/dts/am335x-bone.dts | 123 +++++++++++++++++++++++++++++++++
arch/arm/boot/dts/am335x-boneblack.dts | 120 ++++++++++++++++++++++++++++++++
arch/arm/boot/dts/am437x-gp-evm.dts | 107 ++++++++++++++++++++++++++++
3 files changed, 350 insertions(+)
--
1.8.5.1.163.gd7aced9
^ permalink raw reply [flat|nested] 60+ messages in thread
* [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-03-12 10:49 ` Pekon Gupta
@ 2014-03-12 10:49 ` Pekon Gupta
-1 siblings, 0 replies; 60+ messages in thread
From: Pekon Gupta @ 2014-03-12 10:49 UTC (permalink / raw)
To: Tony Lindgren, bcousson; +Cc: linux-omap, linux-mtd, 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
- Selction of boot modes can be controlled via DIP switch(SW2) present on
Memory Expander cape.
SW2[SWITCH_BOOT] == OFF follow default boot order MMC-> SPI -> UART -> USB
SW2[SWITCH_BOOT] == ON boot mode selected via DIP switch(SW2)
So to flash NAND, first boot via MMC or other sources and then switch to
SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
- 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>
---
arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
1 file changed, 123 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index 94ee427..be2c572 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -10,6 +10,36 @@
#include "am33xx.dtsi"
#include "am335x-bone-common.dtsi"
+&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 */
+ >;
+ };
+};
+
&ldo3_reg {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3300000>;
@@ -27,3 +57,96 @@
&aes {
status = "okay";
};
+
+/*
+ * uncomment following to enable NAND cape support
+ * &mmc2 {
+ * status = "disabled";
+ * };
+ * &elm {
+ * status = "okay";
+ * };
+ * &gpmc {
+ * status = "okay";
+ * };
+ */
+&gpmc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_flash_x16>;
+ ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */
+ nand@0,0 {
+ reg = <0 0 0>; /* CS0, offset 0 */
+ 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-on-read = "true";
+ gpmc,wait-on-write = "true";
+ 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
^ permalink raw reply related [flat|nested] 60+ messages in thread* [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-03-12 10:49 ` Pekon Gupta
0 siblings, 0 replies; 60+ messages in thread
From: Pekon Gupta @ 2014-03-12 10:49 UTC (permalink / raw)
To: Tony Lindgren, bcousson; +Cc: linux-omap, linux-mtd, 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
- Selction of boot modes can be controlled via DIP switch(SW2) present on
Memory Expander cape.
SW2[SWITCH_BOOT] == OFF follow default boot order MMC-> SPI -> UART -> USB
SW2[SWITCH_BOOT] == ON boot mode selected via DIP switch(SW2)
So to flash NAND, first boot via MMC or other sources and then switch to
SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
- 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>
---
arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
1 file changed, 123 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index 94ee427..be2c572 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -10,6 +10,36 @@
#include "am33xx.dtsi"
#include "am335x-bone-common.dtsi"
+&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 */
+ >;
+ };
+};
+
&ldo3_reg {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3300000>;
@@ -27,3 +57,96 @@
&aes {
status = "okay";
};
+
+/*
+ * uncomment following to enable NAND cape support
+ * &mmc2 {
+ * status = "disabled";
+ * };
+ * &elm {
+ * status = "okay";
+ * };
+ * &gpmc {
+ * status = "okay";
+ * };
+ */
+&gpmc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_flash_x16>;
+ ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */
+ nand@0,0 {
+ reg = <0 0 0>; /* CS0, offset 0 */
+ 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-on-read = "true";
+ gpmc,wait-on-write = "true";
+ 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
^ permalink raw reply related [flat|nested] 60+ messages in thread* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-03-12 10:49 ` Pekon Gupta
@ 2014-03-12 14:35 ` Nishanth Menon
-1 siblings, 0 replies; 60+ messages in thread
From: Nishanth Menon @ 2014-03-12 14:35 UTC (permalink / raw)
To: Pekon Gupta, Tony Lindgren, bcousson; +Cc: linux-omap, linux-mtd
On 03/12/2014 05:49 AM, Pekon Gupta wrote:
> 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
>
> - Selction of boot modes can be controlled via DIP switch(SW2) present on
> Memory Expander cape.
> SW2[SWITCH_BOOT] == OFF follow default boot order MMC-> SPI -> UART -> USB
> SW2[SWITCH_BOOT] == ON boot mode selected via DIP switch(SW2)
> So to flash NAND, first boot via MMC or other sources and then switch to
> SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
>
> - 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>
> ---
> arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 123 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
> index 94ee427..be2c572 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
better to make a nand_cape dts which includes the am335x-bone.dts?
> @@ -10,6 +10,36 @@
> #include "am33xx.dtsi"
> #include "am335x-bone-common.dtsi"
>
> +&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 */
> + >;
> + };
> +};
> +
> &ldo3_reg {
> regulator-min-microvolt = <1800000>;
> regulator-max-microvolt = <3300000>;
> @@ -27,3 +57,96 @@
> &aes {
> status = "okay";
> };
> +
> +/*
> + * uncomment following to enable NAND cape support
> + * &mmc2 {
> + * status = "disabled";
> + * };
> + * &elm {
> + * status = "okay";
> + * };
> + * &gpmc {
> + * status = "okay";
> + * };
> + */
> +&gpmc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&nand_flash_x16>;
> + ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */
> + nand@0,0 {
> + reg = <0 0 0>; /* CS0, offset 0 */
> + 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-on-read = "true";
> + gpmc,wait-on-write = "true";
> + 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>;
> + };
> + };
> +};
>
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-03-12 14:35 ` Nishanth Menon
0 siblings, 0 replies; 60+ messages in thread
From: Nishanth Menon @ 2014-03-12 14:35 UTC (permalink / raw)
To: Pekon Gupta, Tony Lindgren, bcousson; +Cc: linux-omap, linux-mtd
On 03/12/2014 05:49 AM, Pekon Gupta wrote:
> 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
>
> - Selction of boot modes can be controlled via DIP switch(SW2) present on
> Memory Expander cape.
> SW2[SWITCH_BOOT] == OFF follow default boot order MMC-> SPI -> UART -> USB
> SW2[SWITCH_BOOT] == ON boot mode selected via DIP switch(SW2)
> So to flash NAND, first boot via MMC or other sources and then switch to
> SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
>
> - 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>
> ---
> arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 123 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
> index 94ee427..be2c572 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
better to make a nand_cape dts which includes the am335x-bone.dts?
> @@ -10,6 +10,36 @@
> #include "am33xx.dtsi"
> #include "am335x-bone-common.dtsi"
>
> +&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 */
> + >;
> + };
> +};
> +
> &ldo3_reg {
> regulator-min-microvolt = <1800000>;
> regulator-max-microvolt = <3300000>;
> @@ -27,3 +57,96 @@
> &aes {
> status = "okay";
> };
> +
> +/*
> + * uncomment following to enable NAND cape support
> + * &mmc2 {
> + * status = "disabled";
> + * };
> + * &elm {
> + * status = "okay";
> + * };
> + * &gpmc {
> + * status = "okay";
> + * };
> + */
> +&gpmc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&nand_flash_x16>;
> + ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */
> + nand@0,0 {
> + reg = <0 0 0>; /* CS0, offset 0 */
> + 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-on-read = "true";
> + gpmc,wait-on-write = "true";
> + 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>;
> + };
> + };
> +};
>
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 60+ messages in thread* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-03-12 14:35 ` Nishanth Menon
(?)
@ 2014-03-12 18:26 ` Gupta, Pekon
2014-03-12 18:57 ` Nishanth Menon
-1 siblings, 1 reply; 60+ messages in thread
From: Gupta, Pekon @ 2014-03-12 18:26 UTC (permalink / raw)
To: Menon, Nishanth, Tony Lindgren, bcousson; +Cc: linux-omap, linux-mtd
Hi,
>From: Menon, Nishanth
>>On 03/12/2014 05:49 AM, Pekon Gupta wrote:
>> 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]
[...]
>> [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>
>> ---
>> arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 123 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
>> index 94ee427..be2c572 100644
>> --- a/arch/arm/boot/dts/am335x-bone.dts
>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>
>better to make a nand_cape dts which includes the am335x-bone.dts?
>
Actually, I'm not in favor of having too many "xx_board_common.dts" files,
because it un-necessarily complexes things.
We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves
some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black.
And, there is no guarantee that Beaglebone-LT(white) will remain compatible to
Beaglebone-black in future.
Example: some capes are not compatible to beaglebone-black [1], [2].
So, I prefer to keep separate GPMC NAND nodes separately in both DTS,
unless there is a strong convincing reason otherwise.
[1] http://elinux.org/CircuitCo:BeagleBoardToys
[2] http://elinux.org/BeagleBone_Black_Capes
with regards, pekon
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-03-12 18:26 ` Gupta, Pekon
@ 2014-03-12 18:57 ` Nishanth Menon
0 siblings, 0 replies; 60+ messages in thread
From: Nishanth Menon @ 2014-03-12 18:57 UTC (permalink / raw)
To: Gupta, Pekon; +Cc: Tony Lindgren, bcousson, linux-omap, linux-mtd
On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon <pekon@ti.com> wrote:
> Hi,
>
>>From: Menon, Nishanth
>>>On 03/12/2014 05:49 AM, Pekon Gupta wrote:
>>> 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]
> [...]
>>> [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>
>>> ---
>>> arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 123 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
>>> index 94ee427..be2c572 100644
>>> --- a/arch/arm/boot/dts/am335x-bone.dts
>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>>
>>better to make a nand_cape dts which includes the am335x-bone.dts?
>>
> Actually, I'm not in favor of having too many "xx_board_common.dts" files,
> because it un-necessarily complexes things.
>
> We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves
> some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black.
> And, there is no guarantee that Beaglebone-LT(white) will remain compatible to
> Beaglebone-black in future.
> Example: some capes are not compatible to beaglebone-black [1], [2].
>
> So, I prefer to keep separate GPMC NAND nodes separately in both DTS,
> unless there is a strong convincing reason otherwise.
>
>
> [1] http://elinux.org/CircuitCo:BeagleBoardToys
> [2] http://elinux.org/BeagleBone_Black_Capes
Right, and adding NAND, GPMC nodes and asking folks to uncomment
sections into a generic board file (which by default has none) makes
more sense? I dont use NAND capes or might create my own cape. overo
has the same challenges as bone family has.I dont see asking folks to
uncomment entries to use the cape is a nicer alternative to having
more dts entries.
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-03-12 18:57 ` Nishanth Menon
0 siblings, 0 replies; 60+ messages in thread
From: Nishanth Menon @ 2014-03-12 18:57 UTC (permalink / raw)
To: Gupta, Pekon; +Cc: Tony Lindgren, linux-omap, linux-mtd, bcousson
On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon <pekon@ti.com> wrote:
> Hi,
>
>>From: Menon, Nishanth
>>>On 03/12/2014 05:49 AM, Pekon Gupta wrote:
>>> 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]
> [...]
>>> [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>
>>> ---
>>> arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 123 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
>>> index 94ee427..be2c572 100644
>>> --- a/arch/arm/boot/dts/am335x-bone.dts
>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>>
>>better to make a nand_cape dts which includes the am335x-bone.dts?
>>
> Actually, I'm not in favor of having too many "xx_board_common.dts" files,
> because it un-necessarily complexes things.
>
> We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves
> some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black.
> And, there is no guarantee that Beaglebone-LT(white) will remain compatible to
> Beaglebone-black in future.
> Example: some capes are not compatible to beaglebone-black [1], [2].
>
> So, I prefer to keep separate GPMC NAND nodes separately in both DTS,
> unless there is a strong convincing reason otherwise.
>
>
> [1] http://elinux.org/CircuitCo:BeagleBoardToys
> [2] http://elinux.org/BeagleBone_Black_Capes
Right, and adding NAND, GPMC nodes and asking folks to uncomment
sections into a generic board file (which by default has none) makes
more sense? I dont use NAND capes or might create my own cape. overo
has the same challenges as bone family has.I dont see asking folks to
uncomment entries to use the cape is a nicer alternative to having
more dts entries.
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-03-12 18:57 ` Nishanth Menon
@ 2014-03-12 19:08 ` Robert Nelson
-1 siblings, 0 replies; 60+ messages in thread
From: Robert Nelson @ 2014-03-12 19:08 UTC (permalink / raw)
To: Nishanth Menon
Cc: Gupta, Pekon, Tony Lindgren, bcousson, linux-omap, linux-mtd
On Wed, Mar 12, 2014 at 1:57 PM, Nishanth Menon <nm@ti.com> wrote:
> On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon <pekon@ti.com> wrote:
>> Hi,
>>
>>>From: Menon, Nishanth
>>>>On 03/12/2014 05:49 AM, Pekon Gupta wrote:
>>>> 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]
>> [...]
>>>> [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>
>>>> ---
>>>> arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 123 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
>>>> index 94ee427..be2c572 100644
>>>> --- a/arch/arm/boot/dts/am335x-bone.dts
>>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>>>
>>>better to make a nand_cape dts which includes the am335x-bone.dts?
>>>
>> Actually, I'm not in favor of having too many "xx_board_common.dts" files,
>> because it un-necessarily complexes things.
>>
>> We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves
>> some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black.
>> And, there is no guarantee that Beaglebone-LT(white) will remain compatible to
>> Beaglebone-black in future.
>> Example: some capes are not compatible to beaglebone-black [1], [2].
>>
>> So, I prefer to keep separate GPMC NAND nodes separately in both DTS,
>> unless there is a strong convincing reason otherwise.
>>
>>
>> [1] http://elinux.org/CircuitCo:BeagleBoardToys
>> [2] http://elinux.org/BeagleBone_Black_Capes
>
>
>
> Right, and adding NAND, GPMC nodes and asking folks to uncomment
> sections into a generic board file (which by default has none) makes
> more sense? I dont use NAND capes or might create my own cape. overo
> has the same challenges as bone family has.I dont see asking folks to
> uncomment entries to use the cape is a nicer alternative to having
> more dts entries.
This is just going to get more messy with every cape addition. Should
we maybe just leave a basic BeagleBone & BeagleBone Black dts file in
mainline kernel.org.
Then create a repo on github.com/beagleboard/ with every
<bone/black>-<first level cape>.dts option?
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-03-12 19:08 ` Robert Nelson
0 siblings, 0 replies; 60+ messages in thread
From: Robert Nelson @ 2014-03-12 19:08 UTC (permalink / raw)
To: Nishanth Menon
Cc: Tony Lindgren, linux-omap, linux-mtd, Gupta, Pekon, bcousson
On Wed, Mar 12, 2014 at 1:57 PM, Nishanth Menon <nm@ti.com> wrote:
> On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon <pekon@ti.com> wrote:
>> Hi,
>>
>>>From: Menon, Nishanth
>>>>On 03/12/2014 05:49 AM, Pekon Gupta wrote:
>>>> 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]
>> [...]
>>>> [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>
>>>> ---
>>>> arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 123 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
>>>> index 94ee427..be2c572 100644
>>>> --- a/arch/arm/boot/dts/am335x-bone.dts
>>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>>>
>>>better to make a nand_cape dts which includes the am335x-bone.dts?
>>>
>> Actually, I'm not in favor of having too many "xx_board_common.dts" files,
>> because it un-necessarily complexes things.
>>
>> We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves
>> some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black.
>> And, there is no guarantee that Beaglebone-LT(white) will remain compatible to
>> Beaglebone-black in future.
>> Example: some capes are not compatible to beaglebone-black [1], [2].
>>
>> So, I prefer to keep separate GPMC NAND nodes separately in both DTS,
>> unless there is a strong convincing reason otherwise.
>>
>>
>> [1] http://elinux.org/CircuitCo:BeagleBoardToys
>> [2] http://elinux.org/BeagleBone_Black_Capes
>
>
>
> Right, and adding NAND, GPMC nodes and asking folks to uncomment
> sections into a generic board file (which by default has none) makes
> more sense? I dont use NAND capes or might create my own cape. overo
> has the same challenges as bone family has.I dont see asking folks to
> uncomment entries to use the cape is a nicer alternative to having
> more dts entries.
This is just going to get more messy with every cape addition. Should
we maybe just leave a basic BeagleBone & BeagleBone Black dts file in
mainline kernel.org.
Then create a repo on github.com/beagleboard/ with every
<bone/black>-<first level cape>.dts option?
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-03-12 19:08 ` Robert Nelson
@ 2014-03-12 19:28 ` Tony Lindgren
-1 siblings, 0 replies; 60+ messages in thread
From: Tony Lindgren @ 2014-03-12 19:28 UTC (permalink / raw)
To: Robert Nelson
Cc: Nishanth Menon, Gupta, Pekon, bcousson, linux-omap, linux-mtd
* Robert Nelson <robertcnelson@gmail.com> [140312 12:11]:
> On Wed, Mar 12, 2014 at 1:57 PM, Nishanth Menon <nm@ti.com> wrote:
> > On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon <pekon@ti.com> wrote:
> >> Hi,
> >>
> >>>From: Menon, Nishanth
> >>>>On 03/12/2014 05:49 AM, Pekon Gupta wrote:
> >>>> 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]
> >> [...]
> >>>> [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>
> >>>> ---
> >>>> arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
> >>>> 1 file changed, 123 insertions(+)
> >>>>
> >>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
> >>>> index 94ee427..be2c572 100644
> >>>> --- a/arch/arm/boot/dts/am335x-bone.dts
> >>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
> >>>
> >>>better to make a nand_cape dts which includes the am335x-bone.dts?
> >>>
> >> Actually, I'm not in favor of having too many "xx_board_common.dts" files,
> >> because it un-necessarily complexes things.
> >>
> >> We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves
> >> some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black.
> >> And, there is no guarantee that Beaglebone-LT(white) will remain compatible to
> >> Beaglebone-black in future.
> >> Example: some capes are not compatible to beaglebone-black [1], [2].
> >>
> >> So, I prefer to keep separate GPMC NAND nodes separately in both DTS,
> >> unless there is a strong convincing reason otherwise.
> >>
> >>
> >> [1] http://elinux.org/CircuitCo:BeagleBoardToys
> >> [2] http://elinux.org/BeagleBone_Black_Capes
> >
> >
> >
> > Right, and adding NAND, GPMC nodes and asking folks to uncomment
> > sections into a generic board file (which by default has none) makes
> > more sense? I dont use NAND capes or might create my own cape. overo
> > has the same challenges as bone family has.I dont see asking folks to
> > uncomment entries to use the cape is a nicer alternative to having
> > more dts entries.
>
> This is just going to get more messy with every cape addition. Should
> we maybe just leave a basic BeagleBone & BeagleBone Black dts file in
> mainline kernel.org.
>
> Then create a repo on github.com/beagleboard/ with every
> <bone/black>-<first level cape>.dts option?
Or just include all devices on the most common capes but have their
status as disabled by default.
For the pinctrl, we need to make sure the pins for a device are not
muxed if it's set to disabled state.
Regards,
Tony
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-03-12 19:28 ` Tony Lindgren
0 siblings, 0 replies; 60+ messages in thread
From: Tony Lindgren @ 2014-03-12 19:28 UTC (permalink / raw)
To: Robert Nelson
Cc: Nishanth Menon, linux-omap, linux-mtd, Gupta, Pekon, bcousson
* Robert Nelson <robertcnelson@gmail.com> [140312 12:11]:
> On Wed, Mar 12, 2014 at 1:57 PM, Nishanth Menon <nm@ti.com> wrote:
> > On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon <pekon@ti.com> wrote:
> >> Hi,
> >>
> >>>From: Menon, Nishanth
> >>>>On 03/12/2014 05:49 AM, Pekon Gupta wrote:
> >>>> 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]
> >> [...]
> >>>> [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>
> >>>> ---
> >>>> arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
> >>>> 1 file changed, 123 insertions(+)
> >>>>
> >>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
> >>>> index 94ee427..be2c572 100644
> >>>> --- a/arch/arm/boot/dts/am335x-bone.dts
> >>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
> >>>
> >>>better to make a nand_cape dts which includes the am335x-bone.dts?
> >>>
> >> Actually, I'm not in favor of having too many "xx_board_common.dts" files,
> >> because it un-necessarily complexes things.
> >>
> >> We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves
> >> some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black.
> >> And, there is no guarantee that Beaglebone-LT(white) will remain compatible to
> >> Beaglebone-black in future.
> >> Example: some capes are not compatible to beaglebone-black [1], [2].
> >>
> >> So, I prefer to keep separate GPMC NAND nodes separately in both DTS,
> >> unless there is a strong convincing reason otherwise.
> >>
> >>
> >> [1] http://elinux.org/CircuitCo:BeagleBoardToys
> >> [2] http://elinux.org/BeagleBone_Black_Capes
> >
> >
> >
> > Right, and adding NAND, GPMC nodes and asking folks to uncomment
> > sections into a generic board file (which by default has none) makes
> > more sense? I dont use NAND capes or might create my own cape. overo
> > has the same challenges as bone family has.I dont see asking folks to
> > uncomment entries to use the cape is a nicer alternative to having
> > more dts entries.
>
> This is just going to get more messy with every cape addition. Should
> we maybe just leave a basic BeagleBone & BeagleBone Black dts file in
> mainline kernel.org.
>
> Then create a repo on github.com/beagleboard/ with every
> <bone/black>-<first level cape>.dts option?
Or just include all devices on the most common capes but have their
status as disabled by default.
For the pinctrl, we need to make sure the pins for a device are not
muxed if it's set to disabled state.
Regards,
Tony
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-03-12 19:28 ` Tony Lindgren
@ 2014-03-12 20:51 ` Nishanth Menon
-1 siblings, 0 replies; 60+ messages in thread
From: Nishanth Menon @ 2014-03-12 20:51 UTC (permalink / raw)
To: Tony Lindgren, Robert Nelson
Cc: Gupta, Pekon, bcousson, linux-omap, linux-mtd
On 03/12/2014 02:28 PM, Tony Lindgren wrote:
> * Robert Nelson <robertcnelson@gmail.com> [140312 12:11]:
>> On Wed, Mar 12, 2014 at 1:57 PM, Nishanth Menon <nm@ti.com> wrote:
>>> On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon <pekon@ti.com> wrote:
>>>> Hi,
>>>>
>>>>> From: Menon, Nishanth
>>>>>> On 03/12/2014 05:49 AM, Pekon Gupta wrote:
>>>>>> 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]
>>>> [...]
>>>>>> [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>
>>>>>> ---
>>>>>> arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
>>>>>> 1 file changed, 123 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
>>>>>> index 94ee427..be2c572 100644
>>>>>> --- a/arch/arm/boot/dts/am335x-bone.dts
>>>>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>>>>>
>>>>> better to make a nand_cape dts which includes the am335x-bone.dts?
>>>>>
>>>> Actually, I'm not in favor of having too many "xx_board_common.dts" files,
>>>> because it un-necessarily complexes things.
>>>>
>>>> We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves
>>>> some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black.
>>>> And, there is no guarantee that Beaglebone-LT(white) will remain compatible to
>>>> Beaglebone-black in future.
>>>> Example: some capes are not compatible to beaglebone-black [1], [2].
>>>>
>>>> So, I prefer to keep separate GPMC NAND nodes separately in both DTS,
>>>> unless there is a strong convincing reason otherwise.
>>>>
>>>>
>>>> [1] http://elinux.org/CircuitCo:BeagleBoardToys
>>>> [2] http://elinux.org/BeagleBone_Black_Capes
>>>
>>>
>>>
>>> Right, and adding NAND, GPMC nodes and asking folks to uncomment
>>> sections into a generic board file (which by default has none) makes
>>> more sense? I dont use NAND capes or might create my own cape. overo
>>> has the same challenges as bone family has.I dont see asking folks to
>>> uncomment entries to use the cape is a nicer alternative to having
>>> more dts entries.
>>
>> This is just going to get more messy with every cape addition. Should
>> we maybe just leave a basic BeagleBone & BeagleBone Black dts file in
>> mainline kernel.org.
>>
>> Then create a repo on github.com/beagleboard/ with every
>> <bone/black>-<first level cape>.dts option?
>
> Or just include all devices on the most common capes but have their
> status as disabled by default.
>
> For the pinctrl, we need to make sure the pins for a device are not
> muxed if it's set to disabled state.
You do have a bunch of "if you want nand, disable mmc2" configuration
in the usage of cape configurations such as this patch, or in the case
of [1] (audio cape), different regulator usage etc. Maintaining out of
tree cape dts might be an option, but that is prone to maintenance
burden as device tree conversion goes on (yeah, all the dt as ABI
stuff aside).
Keeping aside the subjective nature of what entitles a cape being a
"common cape",even introducing nodes that belong to three or four
different first level capes will definitely have it's own sets of
problems.
The ideal solution would be some folks pitching in on what Matt
pointed in [2] - basically "upstream a resource manager on
top of the basic overlay support that's in progress" and introduce
capes as part of that overlay support once it is upstream.
Failing which, keeping the base bone dts to basic stuff that bare
board supports and having per "first level cape" dts which includes
relevant dts sounds to me the only rationale and easily usable (as in:
without much device tree knowledge) - again, I admit "easily" is
subjective here.
[1] https://lkml.org/lkml/2014/2/5/183
[2] https://lkml.org/lkml/2014/2/5/247
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-03-12 20:51 ` Nishanth Menon
0 siblings, 0 replies; 60+ messages in thread
From: Nishanth Menon @ 2014-03-12 20:51 UTC (permalink / raw)
To: Tony Lindgren, Robert Nelson
Cc: linux-omap, linux-mtd, Gupta, Pekon, bcousson
On 03/12/2014 02:28 PM, Tony Lindgren wrote:
> * Robert Nelson <robertcnelson@gmail.com> [140312 12:11]:
>> On Wed, Mar 12, 2014 at 1:57 PM, Nishanth Menon <nm@ti.com> wrote:
>>> On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon <pekon@ti.com> wrote:
>>>> Hi,
>>>>
>>>>> From: Menon, Nishanth
>>>>>> On 03/12/2014 05:49 AM, Pekon Gupta wrote:
>>>>>> 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]
>>>> [...]
>>>>>> [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>
>>>>>> ---
>>>>>> arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
>>>>>> 1 file changed, 123 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
>>>>>> index 94ee427..be2c572 100644
>>>>>> --- a/arch/arm/boot/dts/am335x-bone.dts
>>>>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>>>>>
>>>>> better to make a nand_cape dts which includes the am335x-bone.dts?
>>>>>
>>>> Actually, I'm not in favor of having too many "xx_board_common.dts" files,
>>>> because it un-necessarily complexes things.
>>>>
>>>> We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves
>>>> some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black.
>>>> And, there is no guarantee that Beaglebone-LT(white) will remain compatible to
>>>> Beaglebone-black in future.
>>>> Example: some capes are not compatible to beaglebone-black [1], [2].
>>>>
>>>> So, I prefer to keep separate GPMC NAND nodes separately in both DTS,
>>>> unless there is a strong convincing reason otherwise.
>>>>
>>>>
>>>> [1] http://elinux.org/CircuitCo:BeagleBoardToys
>>>> [2] http://elinux.org/BeagleBone_Black_Capes
>>>
>>>
>>>
>>> Right, and adding NAND, GPMC nodes and asking folks to uncomment
>>> sections into a generic board file (which by default has none) makes
>>> more sense? I dont use NAND capes or might create my own cape. overo
>>> has the same challenges as bone family has.I dont see asking folks to
>>> uncomment entries to use the cape is a nicer alternative to having
>>> more dts entries.
>>
>> This is just going to get more messy with every cape addition. Should
>> we maybe just leave a basic BeagleBone & BeagleBone Black dts file in
>> mainline kernel.org.
>>
>> Then create a repo on github.com/beagleboard/ with every
>> <bone/black>-<first level cape>.dts option?
>
> Or just include all devices on the most common capes but have their
> status as disabled by default.
>
> For the pinctrl, we need to make sure the pins for a device are not
> muxed if it's set to disabled state.
You do have a bunch of "if you want nand, disable mmc2" configuration
in the usage of cape configurations such as this patch, or in the case
of [1] (audio cape), different regulator usage etc. Maintaining out of
tree cape dts might be an option, but that is prone to maintenance
burden as device tree conversion goes on (yeah, all the dt as ABI
stuff aside).
Keeping aside the subjective nature of what entitles a cape being a
"common cape",even introducing nodes that belong to three or four
different first level capes will definitely have it's own sets of
problems.
The ideal solution would be some folks pitching in on what Matt
pointed in [2] - basically "upstream a resource manager on
top of the basic overlay support that's in progress" and introduce
capes as part of that overlay support once it is upstream.
Failing which, keeping the base bone dts to basic stuff that bare
board supports and having per "first level cape" dts which includes
relevant dts sounds to me the only rationale and easily usable (as in:
without much device tree knowledge) - again, I admit "easily" is
subjective here.
[1] https://lkml.org/lkml/2014/2/5/183
[2] https://lkml.org/lkml/2014/2/5/247
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 60+ messages in thread
* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-03-12 20:51 ` Nishanth Menon
@ 2014-03-12 21:13 ` Gupta, Pekon
-1 siblings, 0 replies; 60+ messages in thread
From: Gupta, Pekon @ 2014-03-12 21:13 UTC (permalink / raw)
To: Menon, Nishanth, Tony Lindgren, Robert Nelson
Cc: bcousson, linux-omap, linux-mtd
>-----Original Message-----
>From: Menon, Nishanth
>Sent: Thursday, March 13, 2014 2:21 AM
>To: Tony Lindgren; Robert Nelson
>Cc: Gupta, Pekon; bcousson@baylibre.com; linux-omap; linux-mtd
>Subject: Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
>
>On 03/12/2014 02:28 PM, Tony Lindgren wrote:
>> * Robert Nelson <robertcnelson@gmail.com> [140312 12:11]:
>>> On Wed, Mar 12, 2014 at 1:57 PM, Nishanth Menon <nm@ti.com> wrote:
>>>> On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon <pekon@ti.com> wrote:
>>>>> Hi,
>>>>>
>>>>>> From: Menon, Nishanth
>>>>>>> On 03/12/2014 05:49 AM, Pekon Gupta wrote:
>>>>>>> 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]
>>>>> [...]
>>>>>>> [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>
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
>>>>>>> 1 file changed, 123 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
>>>>>>> index 94ee427..be2c572 100644
>>>>>>> --- a/arch/arm/boot/dts/am335x-bone.dts
>>>>>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>>>>>>
>>>>>> better to make a nand_cape dts which includes the am335x-bone.dts?
>>>>>>
>>>>> Actually, I'm not in favor of having too many "xx_board_common.dts" files,
>>>>> because it un-necessarily complexes things.
>>>>>
>>>>> We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves
>>>>> some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black.
>>>>> And, there is no guarantee that Beaglebone-LT(white) will remain compatible to
>>>>> Beaglebone-black in future.
>>>>> Example: some capes are not compatible to beaglebone-black [1], [2].
>>>>>
>>>>> So, I prefer to keep separate GPMC NAND nodes separately in both DTS,
>>>>> unless there is a strong convincing reason otherwise.
>>>>>
>>>>>
>>>>> [1] http://elinux.org/CircuitCo:BeagleBoardToys
>>>>> [2] http://elinux.org/BeagleBone_Black_Capes
>>>>
>>>>
>>>>
>>>> Right, and adding NAND, GPMC nodes and asking folks to uncomment
>>>> sections into a generic board file (which by default has none) makes
>>>> more sense? I dont use NAND capes or might create my own cape. overo
>>>> has the same challenges as bone family has.I dont see asking folks to
>>>> uncomment entries to use the cape is a nicer alternative to having
>>>> more dts entries.
I think this is different discussion from previous one ..
"common DTS file" v/s "replicated DTS entries in individual board files"
because 'uncomment' issue will remain in both scenarios. (please read below)
>>>
>>> This is just going to get more messy with every cape addition. Should
>>> we maybe just leave a basic BeagleBone & BeagleBone Black dts file in
>>> mainline kernel.org.
>>>
>>> Then create a repo on github.com/beagleboard/ with every
>>> <bone/black>-<first level cape>.dts option?
>>
>> Or just include all devices on the most common capes but have their
>> status as disabled by default.
>>
>> For the pinctrl, we need to make sure the pins for a device are not
>> muxed if it's set to disabled state.
Yes, this is exactly what I intended. Therefore if you revisit the
"uncomment" section, then you would find that there is mmc2=disabled
because on beaglebone-black eMMC (MMC2) pinctrl conflicts with
NAND pin-ctrl.
------------------------
> +/*
> + * uncomment following to enable NAND cape support
> + * &mmc2 {
> + * status = "disabled";
> + * };
> + * &elm {
> + * status = "okay";
> + * };
> + * &gpmc {
> + * status = "okay";
> + * };
------------------------
And I agree 'uncommenting' is not cleaner approach here, so if everyone
agrees, I can remove the above comment and just keep NAND DT node
"disabled" by default.
>
>You do have a bunch of "if you want nand, disable mmc2" configuration
>in the usage of cape configurations such as this patch, or in the case
>of [1] (audio cape), different regulator usage etc. Maintaining out of
>tree cape dts might be an option, but that is prone to maintenance
>burden as device tree conversion goes on (yeah, all the dt as ABI
>stuff aside).
>
>Keeping aside the subjective nature of what entitles a cape being a
>"common cape",even introducing nodes that belong to three or four
>different first level capes will definitely have it's own sets of
>problems.
>
>The ideal solution would be some folks pitching in on what Matt
>pointed in [2] - basically "upstream a resource manager on
>top of the basic overlay support that's in progress" and introduce
>capes as part of that overlay support once it is upstream.
>
I'm not sure how much "capemgr" or "DT overlay" is useful to larger
audience ?
(1) *Usually* actual custom board going to production will have
all devices populated on the board. fixed. It's very rare that an end-user
may buy an extension board (like capes) and add to finished good.
Thus, 'DT overlay' and 'capemgr' are good for development platforms
where you give a generic basic board for people to play (at low cost)
And then give accessory boards (like capes) on top to choose and build
a conceptual solution.
(2) Also, 'capemgr' should be able to detect and identify all the capes
uniquely, and in correct sequence. For which you need some kind
of identification mechanism like EEPROM on each cape connected
to I2C. And I doubt all beaglebone capes have that as-of-today.
(also that makes cape slightly expensive).
So, I'll still prefer Tony's suggestion that,
add support for all Capes in DT, but keep the conflicting ones
"disabled" by default. And let the user choose which ones to enable.
This is simple and keeps maintenance overhead also low.
>Failing which, keeping the base bone dts to basic stuff that bare
>board supports and having per "first level cape" dts which includes
>relevant dts sounds to me the only rationale and easily usable (as in:
>without much device tree knowledge) - again, I admit "easily" is
>subjective here.
>
>
>[1] https://lkml.org/lkml/2014/2/5/183
>[2] https://lkml.org/lkml/2014/2/5/247
>
>--
>Regards,
>Nishanth Menon
with regards, pekon
^ permalink raw reply [flat|nested] 60+ messages in thread* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-03-12 21:13 ` Gupta, Pekon
0 siblings, 0 replies; 60+ messages in thread
From: Gupta, Pekon @ 2014-03-12 21:13 UTC (permalink / raw)
To: Menon, Nishanth, Tony Lindgren, Robert Nelson
Cc: linux-omap, linux-mtd, bcousson
>-----Original Message-----
>From: Menon, Nishanth
>Sent: Thursday, March 13, 2014 2:21 AM
>To: Tony Lindgren; Robert Nelson
>Cc: Gupta, Pekon; bcousson@baylibre.com; linux-omap; linux-mtd
>Subject: Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
>
>On 03/12/2014 02:28 PM, Tony Lindgren wrote:
>> * Robert Nelson <robertcnelson@gmail.com> [140312 12:11]:
>>> On Wed, Mar 12, 2014 at 1:57 PM, Nishanth Menon <nm@ti.com> wrote:
>>>> On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon <pekon@ti.com> wrote:
>>>>> Hi,
>>>>>
>>>>>> From: Menon, Nishanth
>>>>>>> On 03/12/2014 05:49 AM, Pekon Gupta wrote:
>>>>>>> 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]
>>>>> [...]
>>>>>>> [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>
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/am335x-bone.dts | 123 ++++++++++++++++++++++++++++++++++++++
>>>>>>> 1 file changed, 123 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
>>>>>>> index 94ee427..be2c572 100644
>>>>>>> --- a/arch/arm/boot/dts/am335x-bone.dts
>>>>>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>>>>>>
>>>>>> better to make a nand_cape dts which includes the am335x-bone.dts?
>>>>>>
>>>>> Actually, I'm not in favor of having too many "xx_board_common.dts" files,
>>>>> because it un-necessarily complexes things.
>>>>>
>>>>> We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves
>>>>> some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black.
>>>>> And, there is no guarantee that Beaglebone-LT(white) will remain compatible to
>>>>> Beaglebone-black in future.
>>>>> Example: some capes are not compatible to beaglebone-black [1], [2].
>>>>>
>>>>> So, I prefer to keep separate GPMC NAND nodes separately in both DTS,
>>>>> unless there is a strong convincing reason otherwise.
>>>>>
>>>>>
>>>>> [1] http://elinux.org/CircuitCo:BeagleBoardToys
>>>>> [2] http://elinux.org/BeagleBone_Black_Capes
>>>>
>>>>
>>>>
>>>> Right, and adding NAND, GPMC nodes and asking folks to uncomment
>>>> sections into a generic board file (which by default has none) makes
>>>> more sense? I dont use NAND capes or might create my own cape. overo
>>>> has the same challenges as bone family has.I dont see asking folks to
>>>> uncomment entries to use the cape is a nicer alternative to having
>>>> more dts entries.
I think this is different discussion from previous one ..
"common DTS file" v/s "replicated DTS entries in individual board files"
because 'uncomment' issue will remain in both scenarios. (please read below)
>>>
>>> This is just going to get more messy with every cape addition. Should
>>> we maybe just leave a basic BeagleBone & BeagleBone Black dts file in
>>> mainline kernel.org.
>>>
>>> Then create a repo on github.com/beagleboard/ with every
>>> <bone/black>-<first level cape>.dts option?
>>
>> Or just include all devices on the most common capes but have their
>> status as disabled by default.
>>
>> For the pinctrl, we need to make sure the pins for a device are not
>> muxed if it's set to disabled state.
Yes, this is exactly what I intended. Therefore if you revisit the
"uncomment" section, then you would find that there is mmc2=disabled
because on beaglebone-black eMMC (MMC2) pinctrl conflicts with
NAND pin-ctrl.
------------------------
> +/*
> + * uncomment following to enable NAND cape support
> + * &mmc2 {
> + * status = "disabled";
> + * };
> + * &elm {
> + * status = "okay";
> + * };
> + * &gpmc {
> + * status = "okay";
> + * };
------------------------
And I agree 'uncommenting' is not cleaner approach here, so if everyone
agrees, I can remove the above comment and just keep NAND DT node
"disabled" by default.
>
>You do have a bunch of "if you want nand, disable mmc2" configuration
>in the usage of cape configurations such as this patch, or in the case
>of [1] (audio cape), different regulator usage etc. Maintaining out of
>tree cape dts might be an option, but that is prone to maintenance
>burden as device tree conversion goes on (yeah, all the dt as ABI
>stuff aside).
>
>Keeping aside the subjective nature of what entitles a cape being a
>"common cape",even introducing nodes that belong to three or four
>different first level capes will definitely have it's own sets of
>problems.
>
>The ideal solution would be some folks pitching in on what Matt
>pointed in [2] - basically "upstream a resource manager on
>top of the basic overlay support that's in progress" and introduce
>capes as part of that overlay support once it is upstream.
>
I'm not sure how much "capemgr" or "DT overlay" is useful to larger
audience ?
(1) *Usually* actual custom board going to production will have
all devices populated on the board. fixed. It's very rare that an end-user
may buy an extension board (like capes) and add to finished good.
Thus, 'DT overlay' and 'capemgr' are good for development platforms
where you give a generic basic board for people to play (at low cost)
And then give accessory boards (like capes) on top to choose and build
a conceptual solution.
(2) Also, 'capemgr' should be able to detect and identify all the capes
uniquely, and in correct sequence. For which you need some kind
of identification mechanism like EEPROM on each cape connected
to I2C. And I doubt all beaglebone capes have that as-of-today.
(also that makes cape slightly expensive).
So, I'll still prefer Tony's suggestion that,
add support for all Capes in DT, but keep the conflicting ones
"disabled" by default. And let the user choose which ones to enable.
This is simple and keeps maintenance overhead also low.
>Failing which, keeping the base bone dts to basic stuff that bare
>board supports and having per "first level cape" dts which includes
>relevant dts sounds to me the only rationale and easily usable (as in:
>without much device tree knowledge) - again, I admit "easily" is
>subjective here.
>
>
>[1] https://lkml.org/lkml/2014/2/5/183
>[2] https://lkml.org/lkml/2014/2/5/247
>
>--
>Regards,
>Nishanth Menon
with regards, pekon
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-03-12 21:13 ` Gupta, Pekon
@ 2014-03-12 21:53 ` Nishanth Menon
-1 siblings, 0 replies; 60+ messages in thread
From: Nishanth Menon @ 2014-03-12 21:53 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Tony Lindgren, Robert Nelson, bcousson, linux-omap, linux-mtd
On 16:13-20140312, Gupta, Pekon wrote:
> I think this is different discussion from previous one ..
> "common DTS file" v/s "replicated DTS entries in individual board files"
> because 'uncomment' issue will remain in both scenarios. (please read below)
see below patch to highlight what I was mentioning: The build generates the dtb that can be used with
nand cape without any hand modification. the "easy" part I mentioned is
just knowing to select the right dtb corresponding to the cape. There is
no replication, just overriding the default board behavior.
>From b573d557aa09e34b1b587943dfea73bac480286d Mon Sep 17 00:00:00 2001
From: DUMMY AUTHOR <dummy@somewhere.com>
Date: Wed, 12 Mar 2014 16:47:15 -0500
Subject: [REFERENCE PATCH] ARM: dts: am335x-bone: add support for beaglebone NAND cape
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
- Selction of boot modes can be controlled via DIP switch(SW2) present on
Memory Expander cape.
SW2[SWITCH_BOOT] == OFF follow default boot order MMC-> SPI -> UART -> USB
SW2[SWITCH_BOOT] == ON boot mode selected via DIP switch(SW2)
So to flash NAND, first boot via MMC or other sources and then switch to
SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
- 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
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/am335x-bone-memory-cape.dts | 123 +++++++++++++++++++++++++
2 files changed, 124 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0320303..c5e9bfa 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -226,6 +226,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
am335x-boneblack.dtb \
+ am335x-bone-memory-cape.dtb\
am335x-nano.dtb \
am335x-base0033.dtb \
am3517-evm.dtb \
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..7ab088d
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
@@ -0,0 +1,123 @@
+#include "am335x-bone.dts"
+
+&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 */
+ >;
+ };
+};
+
+
+/* NAND cape cannot work with MMC2 */
+&mmc2 {
+ status = "disabled";
+};
+
+&elm {
+ status = "okay";
+};
+
+&gpmc {
+ pinctrl-names = "default";
+ status = "okay";
+ pinctrl-0 = <&nand_flash_x16>;
+ ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */
+ nand@0,0 {
+ reg = <0 0 0>; /* CS0, offset 0 */
+ 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-on-read = "true";
+ gpmc,wait-on-write = "true";
+ 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.7.9.5
--
Regards,
Nishanth Menon
^ permalink raw reply related [flat|nested] 60+ messages in thread* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-03-12 21:53 ` Nishanth Menon
0 siblings, 0 replies; 60+ messages in thread
From: Nishanth Menon @ 2014-03-12 21:53 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Tony Lindgren, linux-mtd, linux-omap, Robert Nelson, bcousson
On 16:13-20140312, Gupta, Pekon wrote:
> I think this is different discussion from previous one ..
> "common DTS file" v/s "replicated DTS entries in individual board files"
> because 'uncomment' issue will remain in both scenarios. (please read below)
see below patch to highlight what I was mentioning: The build generates the dtb that can be used with
nand cape without any hand modification. the "easy" part I mentioned is
just knowing to select the right dtb corresponding to the cape. There is
no replication, just overriding the default board behavior.
>From b573d557aa09e34b1b587943dfea73bac480286d Mon Sep 17 00:00:00 2001
From: DUMMY AUTHOR <dummy@somewhere.com>
Date: Wed, 12 Mar 2014 16:47:15 -0500
Subject: [REFERENCE PATCH] ARM: dts: am335x-bone: add support for beaglebone NAND cape
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
- Selction of boot modes can be controlled via DIP switch(SW2) present on
Memory Expander cape.
SW2[SWITCH_BOOT] == OFF follow default boot order MMC-> SPI -> UART -> USB
SW2[SWITCH_BOOT] == ON boot mode selected via DIP switch(SW2)
So to flash NAND, first boot via MMC or other sources and then switch to
SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
- 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
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/am335x-bone-memory-cape.dts | 123 +++++++++++++++++++++++++
2 files changed, 124 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0320303..c5e9bfa 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -226,6 +226,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
am335x-boneblack.dtb \
+ am335x-bone-memory-cape.dtb\
am335x-nano.dtb \
am335x-base0033.dtb \
am3517-evm.dtb \
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..7ab088d
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
@@ -0,0 +1,123 @@
+#include "am335x-bone.dts"
+
+&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 */
+ >;
+ };
+};
+
+
+/* NAND cape cannot work with MMC2 */
+&mmc2 {
+ status = "disabled";
+};
+
+&elm {
+ status = "okay";
+};
+
+&gpmc {
+ pinctrl-names = "default";
+ status = "okay";
+ pinctrl-0 = <&nand_flash_x16>;
+ ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */
+ nand@0,0 {
+ reg = <0 0 0>; /* CS0, offset 0 */
+ 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-on-read = "true";
+ gpmc,wait-on-write = "true";
+ 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.7.9.5
--
Regards,
Nishanth Menon
^ permalink raw reply related [flat|nested] 60+ messages in thread* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-03-12 21:53 ` Nishanth Menon
@ 2014-03-13 6:19 ` Gupta, Pekon
-1 siblings, 0 replies; 60+ messages in thread
From: Gupta, Pekon @ 2014-03-13 6:19 UTC (permalink / raw)
To: Menon, Nishanth, Tony Lindgren
Cc: Robert Nelson, bcousson, linux-omap, linux-mtd
[...]
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/am335x-bone-memory-cape.dts | 123 +++++++++++++++++++++++++
> 2 files changed, 124 insertions(+)
> create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts
>
>diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>index 0320303..c5e9bfa 100644
>--- a/arch/arm/boot/dts/Makefile
>+++ b/arch/arm/boot/dts/Makefile
>@@ -226,6 +226,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
> am335x-evmsk.dtb \
> am335x-bone.dtb \
> am335x-boneblack.dtb \
>+ am335x-bone-memory-cape.dtb\
> am335x-nano.dtb \
> am335x-base0033.dtb \
> am3517-evm.dtb \
>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..7ab088d
>--- /dev/null
>+++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
>
>From discussions, option I could think are..
(a) NAND cape node added in both 'am335x-bone.dts' and
'am335x-boneblack.dts' but "disabled" by default.
(b) NAND cape node in new '.dts' file (as mentioned above), and generate
a separate blob individual for cape.
(c) NAND cape node in existing 'am335x-bone-common.dtsi', "disabled"
by default. But there is no guarantee that future boards remain
compatible and same 'common_xx.dtsi' can be reused later.
I'll wait for Tony/Benoit-C. to decide on what suits them, as they are the
ones who have to maintain all these. Tony ?
with regards, pekon
^ permalink raw reply [flat|nested] 60+ messages in thread
* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-03-13 6:19 ` Gupta, Pekon
0 siblings, 0 replies; 60+ messages in thread
From: Gupta, Pekon @ 2014-03-13 6:19 UTC (permalink / raw)
To: Menon, Nishanth, Tony Lindgren
Cc: linux-mtd, linux-omap, Robert Nelson, bcousson
[...]
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/am335x-bone-memory-cape.dts | 123 +++++++++++++++++++++++++
> 2 files changed, 124 insertions(+)
> create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts
>
>diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>index 0320303..c5e9bfa 100644
>--- a/arch/arm/boot/dts/Makefile
>+++ b/arch/arm/boot/dts/Makefile
>@@ -226,6 +226,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
> am335x-evmsk.dtb \
> am335x-bone.dtb \
> am335x-boneblack.dtb \
>+ am335x-bone-memory-cape.dtb\
> am335x-nano.dtb \
> am335x-base0033.dtb \
> am3517-evm.dtb \
>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..7ab088d
>--- /dev/null
>+++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
>
>From discussions, option I could think are..
(a) NAND cape node added in both 'am335x-bone.dts' and
'am335x-boneblack.dts' but "disabled" by default.
(b) NAND cape node in new '.dts' file (as mentioned above), and generate
a separate blob individual for cape.
(c) NAND cape node in existing 'am335x-bone-common.dtsi', "disabled"
by default. But there is no guarantee that future boards remain
compatible and same 'common_xx.dtsi' can be reused later.
I'll wait for Tony/Benoit-C. to decide on what suits them, as they are the
ones who have to maintain all these. Tony ?
with regards, pekon
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-03-13 6:19 ` Gupta, Pekon
@ 2014-03-13 13:03 ` Nishanth Menon
-1 siblings, 0 replies; 60+ messages in thread
From: Nishanth Menon @ 2014-03-13 13:03 UTC (permalink / raw)
To: Gupta, Pekon, Tony Lindgren
Cc: Robert Nelson, bcousson, linux-omap, linux-mtd
On 03/13/2014 01:19 AM, Gupta, Pekon wrote:
[..]
>> 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..7ab088d
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
>>
> From discussions, option I could think are..
>
> (a) NAND cape node added in both 'am335x-bone.dts' and
> 'am335x-boneblack.dts' but "disabled" by default.
>
> (b) NAND cape node in new '.dts' file (as mentioned above), and generate
> a separate blob individual for cape.
>
> (c) NAND cape node in existing 'am335x-bone-common.dtsi', "disabled"
> by default. But there is no guarantee that future boards remain
> compatible and same 'common_xx.dtsi' can be reused later.
>
> I'll wait for Tony/Benoit-C. to decide on what suits them, as they are the
> ones who have to maintain all these. Tony ?
>
Key for us is that we'd have to live with what ever we introduce in
the interest of backward dtb compatibility. both (a) and (c) requires
hand modification by user of nand cape - considering this might be the
strategy for "most common capes", we might end up with confusing
entries that in many cases will require additional documentation
example: option a, c: consider both audio cape (which needs hdmi
disabled) and nand cape (which needs mmc2 disabled) - how'd the user
know which entries to enable/disable for the user of the cape -
documentation needed and potentially user error prone implementation
as well.
There is as well a option (d) where we wait for FDT overlay to mature,
write up a resource manager and support all level capes.
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-03-13 13:03 ` Nishanth Menon
0 siblings, 0 replies; 60+ messages in thread
From: Nishanth Menon @ 2014-03-13 13:03 UTC (permalink / raw)
To: Gupta, Pekon, Tony Lindgren
Cc: linux-mtd, linux-omap, Robert Nelson, bcousson
On 03/13/2014 01:19 AM, Gupta, Pekon wrote:
[..]
>> 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..7ab088d
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
>>
> From discussions, option I could think are..
>
> (a) NAND cape node added in both 'am335x-bone.dts' and
> 'am335x-boneblack.dts' but "disabled" by default.
>
> (b) NAND cape node in new '.dts' file (as mentioned above), and generate
> a separate blob individual for cape.
>
> (c) NAND cape node in existing 'am335x-bone-common.dtsi', "disabled"
> by default. But there is no guarantee that future boards remain
> compatible and same 'common_xx.dtsi' can be reused later.
>
> I'll wait for Tony/Benoit-C. to decide on what suits them, as they are the
> ones who have to maintain all these. Tony ?
>
Key for us is that we'd have to live with what ever we introduce in
the interest of backward dtb compatibility. both (a) and (c) requires
hand modification by user of nand cape - considering this might be the
strategy for "most common capes", we might end up with confusing
entries that in many cases will require additional documentation
example: option a, c: consider both audio cape (which needs hdmi
disabled) and nand cape (which needs mmc2 disabled) - how'd the user
know which entries to enable/disable for the user of the cape -
documentation needed and potentially user error prone implementation
as well.
There is as well a option (d) where we wait for FDT overlay to mature,
write up a resource manager and support all level capes.
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-03-13 13:03 ` Nishanth Menon
@ 2014-03-13 13:30 ` Robert Nelson
-1 siblings, 0 replies; 60+ messages in thread
From: Robert Nelson @ 2014-03-13 13:30 UTC (permalink / raw)
To: Nishanth Menon
Cc: Gupta, Pekon, Tony Lindgren, bcousson, linux-omap, linux-mtd
On Thu, Mar 13, 2014 at 8:03 AM, Nishanth Menon <nm@ti.com> wrote:
> On 03/13/2014 01:19 AM, Gupta, Pekon wrote:
> [..]
>>> 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..7ab088d
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
>>>
>> From discussions, option I could think are..
>>
>> (a) NAND cape node added in both 'am335x-bone.dts' and
>> 'am335x-boneblack.dts' but "disabled" by default.
>>
>> (b) NAND cape node in new '.dts' file (as mentioned above), and generate
>> a separate blob individual for cape.
>>
>> (c) NAND cape node in existing 'am335x-bone-common.dtsi', "disabled"
>> by default. But there is no guarantee that future boards remain
>> compatible and same 'common_xx.dtsi' can be reused later.
>>
>> I'll wait for Tony/Benoit-C. to decide on what suits them, as they are the
>> ones who have to maintain all these. Tony ?
>>
>
> Key for us is that we'd have to live with what ever we introduce in
> the interest of backward dtb compatibility. both (a) and (c) requires
> hand modification by user of nand cape - considering this might be the
> strategy for "most common capes", we might end up with confusing
> entries that in many cases will require additional documentation
> example: option a, c: consider both audio cape (which needs hdmi
> disabled) and nand cape (which needs mmc2 disabled) - how'd the user
> know which entries to enable/disable for the user of the cape -
> documentation needed and potentially user error prone implementation
> as well.
>
> There is as well a option (d) where we wait for FDT overlay to mature,
> write up a resource manager and support all level capes.
(b) is the direction i'm currently trying to transition the
beagleboard.org community till (d) actually shows any life/hope again.
example:
https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.13/patches/static-capes
I really like Nishanth's simpler version he posted, so I'll be
converting mine to that style later today.
Also with u-boot v2014.04-rcX we now have "test -e" (exist support) so
we can actively check for the presence of <board>-<cape>.dtb and
safely fall back to <board>.dtb if it didn't actually exist. The only
requirement is the end user specify the <cape> as a variable in
uEnv.txt
https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2014.04-rc2/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L76
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-03-13 13:30 ` Robert Nelson
0 siblings, 0 replies; 60+ messages in thread
From: Robert Nelson @ 2014-03-13 13:30 UTC (permalink / raw)
To: Nishanth Menon
Cc: Tony Lindgren, linux-omap, linux-mtd, Gupta, Pekon, bcousson
On Thu, Mar 13, 2014 at 8:03 AM, Nishanth Menon <nm@ti.com> wrote:
> On 03/13/2014 01:19 AM, Gupta, Pekon wrote:
> [..]
>>> 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..7ab088d
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
>>>
>> From discussions, option I could think are..
>>
>> (a) NAND cape node added in both 'am335x-bone.dts' and
>> 'am335x-boneblack.dts' but "disabled" by default.
>>
>> (b) NAND cape node in new '.dts' file (as mentioned above), and generate
>> a separate blob individual for cape.
>>
>> (c) NAND cape node in existing 'am335x-bone-common.dtsi', "disabled"
>> by default. But there is no guarantee that future boards remain
>> compatible and same 'common_xx.dtsi' can be reused later.
>>
>> I'll wait for Tony/Benoit-C. to decide on what suits them, as they are the
>> ones who have to maintain all these. Tony ?
>>
>
> Key for us is that we'd have to live with what ever we introduce in
> the interest of backward dtb compatibility. both (a) and (c) requires
> hand modification by user of nand cape - considering this might be the
> strategy for "most common capes", we might end up with confusing
> entries that in many cases will require additional documentation
> example: option a, c: consider both audio cape (which needs hdmi
> disabled) and nand cape (which needs mmc2 disabled) - how'd the user
> know which entries to enable/disable for the user of the cape -
> documentation needed and potentially user error prone implementation
> as well.
>
> There is as well a option (d) where we wait for FDT overlay to mature,
> write up a resource manager and support all level capes.
(b) is the direction i'm currently trying to transition the
beagleboard.org community till (d) actually shows any life/hope again.
example:
https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.13/patches/static-capes
I really like Nishanth's simpler version he posted, so I'll be
converting mine to that style later today.
Also with u-boot v2014.04-rcX we now have "test -e" (exist support) so
we can actively check for the presence of <board>-<cape>.dtb and
safely fall back to <board>.dtb if it didn't actually exist. The only
requirement is the end user specify the <cape> as a variable in
uEnv.txt
https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2014.04-rc2/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L76
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-03-13 13:30 ` Robert Nelson
@ 2014-03-13 16:55 ` Tony Lindgren
-1 siblings, 0 replies; 60+ messages in thread
From: Tony Lindgren @ 2014-03-13 16:55 UTC (permalink / raw)
To: Robert Nelson
Cc: Nishanth Menon, Gupta, Pekon, bcousson, linux-omap, linux-mtd
* Robert Nelson <robertcnelson@gmail.com> [140313 06:33]:
> On Thu, Mar 13, 2014 at 8:03 AM, Nishanth Menon <nm@ti.com> wrote:
> > On 03/13/2014 01:19 AM, Gupta, Pekon wrote:
> > [..]
> >>> 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..7ab088d
> >>> --- /dev/null
> >>> +++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
> >>>
> >> From discussions, option I could think are..
> >>
> >> (a) NAND cape node added in both 'am335x-bone.dts' and
> >> 'am335x-boneblack.dts' but "disabled" by default.
The capes can live their own revision cycle from beaglebones,
so separate .dts files for each cape are probably better.
> >> (b) NAND cape node in new '.dts' file (as mentioned above), and generate
> >> a separate blob individual for cape.
(b.2) NAND cape node in new '.dts' file but devices set to disabled
by default. Included into am335x-*bone*.dts files. The found
and configured cape devices set back to enabled by u-boot by
modifying the .dtb by using the existing ft_board_setup() and
fdt_find_and_setprop() in u-boot.
> >> (c) NAND cape node in existing 'am335x-bone-common.dtsi', "disabled"
> >> by default. But there is no guarantee that future boards remain
> >> compatible and same 'common_xx.dtsi' can be reused later.
This also has an issue of different revision cycle between beaglebones
and the capes.
> >> I'll wait for Tony/Benoit-C. to decide on what suits them, as they are the
> >> ones who have to maintain all these. Tony ?
> >>
> >
> > Key for us is that we'd have to live with what ever we introduce in
> > the interest of backward dtb compatibility. both (a) and (c) requires
> > hand modification by user of nand cape - considering this might be the
> > strategy for "most common capes", we might end up with confusing
> > entries that in many cases will require additional documentation
> > example: option a, c: consider both audio cape (which needs hdmi
> > disabled) and nand cape (which needs mmc2 disabled) - how'd the user
> > know which entries to enable/disable for the user of the cape -
> > documentation needed and potentially user error prone implementation
> > as well.
> >
> > There is as well a option (d) where we wait for FDT overlay to mature,
> > write up a resource manager and support all level capes.
Yeah option (d) and having the capes hotpluggable is probably the best
way to go in the long run. Meanwhile, I'd suggest researching if
option (b.2) above is doable for enabling some capes.
> (b) is the direction i'm currently trying to transition the
> beagleboard.org community till (d) actually shows any life/hope again.
>
> example:
> https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.13/patches/static-capes
>
> I really like Nishanth's simpler version he posted, so I'll be
> converting mine to that style later today.
Yeah except most of these capes should be included into the
am335x-*bone*.dts files as in (b.2) above. All the internal omap
devices are still there on the SoC even if not wired to the cape.
The GPMC devices may cause more of an issue as we cannot just override
the chip select wiring by modifying the .dtb. But for the internal
devices modifying the .dtb to enable some of them might be doable.
> Also with u-boot v2014.04-rcX we now have "test -e" (exist support) so
> we can actively check for the presence of <board>-<cape>.dtb and
> safely fall back to <board>.dtb if it didn't actually exist. The only
> requirement is the end user specify the <cape> as a variable in
> uEnv.txt
>
> https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2014.04-rc2/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L76
That's great!
Regards,
Tony
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-03-13 16:55 ` Tony Lindgren
0 siblings, 0 replies; 60+ messages in thread
From: Tony Lindgren @ 2014-03-13 16:55 UTC (permalink / raw)
To: Robert Nelson
Cc: Nishanth Menon, linux-omap, linux-mtd, Gupta, Pekon, bcousson
* Robert Nelson <robertcnelson@gmail.com> [140313 06:33]:
> On Thu, Mar 13, 2014 at 8:03 AM, Nishanth Menon <nm@ti.com> wrote:
> > On 03/13/2014 01:19 AM, Gupta, Pekon wrote:
> > [..]
> >>> 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..7ab088d
> >>> --- /dev/null
> >>> +++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
> >>>
> >> From discussions, option I could think are..
> >>
> >> (a) NAND cape node added in both 'am335x-bone.dts' and
> >> 'am335x-boneblack.dts' but "disabled" by default.
The capes can live their own revision cycle from beaglebones,
so separate .dts files for each cape are probably better.
> >> (b) NAND cape node in new '.dts' file (as mentioned above), and generate
> >> a separate blob individual for cape.
(b.2) NAND cape node in new '.dts' file but devices set to disabled
by default. Included into am335x-*bone*.dts files. The found
and configured cape devices set back to enabled by u-boot by
modifying the .dtb by using the existing ft_board_setup() and
fdt_find_and_setprop() in u-boot.
> >> (c) NAND cape node in existing 'am335x-bone-common.dtsi', "disabled"
> >> by default. But there is no guarantee that future boards remain
> >> compatible and same 'common_xx.dtsi' can be reused later.
This also has an issue of different revision cycle between beaglebones
and the capes.
> >> I'll wait for Tony/Benoit-C. to decide on what suits them, as they are the
> >> ones who have to maintain all these. Tony ?
> >>
> >
> > Key for us is that we'd have to live with what ever we introduce in
> > the interest of backward dtb compatibility. both (a) and (c) requires
> > hand modification by user of nand cape - considering this might be the
> > strategy for "most common capes", we might end up with confusing
> > entries that in many cases will require additional documentation
> > example: option a, c: consider both audio cape (which needs hdmi
> > disabled) and nand cape (which needs mmc2 disabled) - how'd the user
> > know which entries to enable/disable for the user of the cape -
> > documentation needed and potentially user error prone implementation
> > as well.
> >
> > There is as well a option (d) where we wait for FDT overlay to mature,
> > write up a resource manager and support all level capes.
Yeah option (d) and having the capes hotpluggable is probably the best
way to go in the long run. Meanwhile, I'd suggest researching if
option (b.2) above is doable for enabling some capes.
> (b) is the direction i'm currently trying to transition the
> beagleboard.org community till (d) actually shows any life/hope again.
>
> example:
> https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.13/patches/static-capes
>
> I really like Nishanth's simpler version he posted, so I'll be
> converting mine to that style later today.
Yeah except most of these capes should be included into the
am335x-*bone*.dts files as in (b.2) above. All the internal omap
devices are still there on the SoC even if not wired to the cape.
The GPMC devices may cause more of an issue as we cannot just override
the chip select wiring by modifying the .dtb. But for the internal
devices modifying the .dtb to enable some of them might be doable.
> Also with u-boot v2014.04-rcX we now have "test -e" (exist support) so
> we can actively check for the presence of <board>-<cape>.dtb and
> safely fall back to <board>.dtb if it didn't actually exist. The only
> requirement is the end user specify the <cape> as a variable in
> uEnv.txt
>
> https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2014.04-rc2/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L76
That's great!
Regards,
Tony
^ permalink raw reply [flat|nested] 60+ messages in thread
* [PATCH v1 2/3] ARM: dts: am335x-boneblack: add support for beaglebone NAND cape
2014-03-12 10:49 ` Pekon Gupta
@ 2014-03-12 10:49 ` Pekon Gupta
-1 siblings, 0 replies; 60+ messages in thread
From: Pekon Gupta @ 2014-03-12 10:49 UTC (permalink / raw)
To: Tony Lindgren, bcousson; +Cc: linux-omap, linux-mtd, 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
- Selction of boot modes can be controlled via DIP switch(SW2) present on
Memory Expander cape.
SW2[SWITCH_BOOT] == OFF follow default boot order MMC-> SPI -> UART -> USB
SW2[SWITCH_BOOT] == ON boot mode selected via DIP switch(SW2)
So to flash NAND, first boot via MMC or other sources and then switch to
SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
- 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>
---
arch/arm/boot/dts/am335x-boneblack.dts | 120 +++++++++++++++++++++++++++++++++
1 file changed, 120 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts
index 6b71ad9..596cfec 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -60,6 +60,33 @@
0x1b0 0x03 /* xdma_event_intr0, OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */
>;
};
+ 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 */
+ >;
+ };
};
&lcdc {
@@ -76,3 +103,96 @@
status = "okay";
};
};
+
+/*
+ * uncomment following to enable NAND cape support
+ * &mmc2 {
+ * status = "disabled";
+ * };
+ * &elm {
+ * status = "okay";
+ * };
+ * &gpmc {
+ * status = "okay";
+ * };
+ */
+&gpmc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_flash_x16>;
+ ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */
+ nand@0,0 {
+ reg = <0 0 0>; /* CS0, offset 0 */
+ 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-on-read = "true";
+ gpmc,wait-on-write = "true";
+ 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
^ permalink raw reply related [flat|nested] 60+ messages in thread* [PATCH v1 2/3] ARM: dts: am335x-boneblack: add support for beaglebone NAND cape
@ 2014-03-12 10:49 ` Pekon Gupta
0 siblings, 0 replies; 60+ messages in thread
From: Pekon Gupta @ 2014-03-12 10:49 UTC (permalink / raw)
To: Tony Lindgren, bcousson; +Cc: linux-omap, linux-mtd, 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
- Selction of boot modes can be controlled via DIP switch(SW2) present on
Memory Expander cape.
SW2[SWITCH_BOOT] == OFF follow default boot order MMC-> SPI -> UART -> USB
SW2[SWITCH_BOOT] == ON boot mode selected via DIP switch(SW2)
So to flash NAND, first boot via MMC or other sources and then switch to
SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
- 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>
---
arch/arm/boot/dts/am335x-boneblack.dts | 120 +++++++++++++++++++++++++++++++++
1 file changed, 120 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts
index 6b71ad9..596cfec 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -60,6 +60,33 @@
0x1b0 0x03 /* xdma_event_intr0, OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */
>;
};
+ 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 */
+ >;
+ };
};
&lcdc {
@@ -76,3 +103,96 @@
status = "okay";
};
};
+
+/*
+ * uncomment following to enable NAND cape support
+ * &mmc2 {
+ * status = "disabled";
+ * };
+ * &elm {
+ * status = "okay";
+ * };
+ * &gpmc {
+ * status = "okay";
+ * };
+ */
+&gpmc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_flash_x16>;
+ ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */
+ nand@0,0 {
+ reg = <0 0 0>; /* CS0, offset 0 */
+ 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-on-read = "true";
+ gpmc,wait-on-write = "true";
+ 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
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH v1 3/3] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
2014-03-12 10:49 ` Pekon Gupta
@ 2014-03-12 10:49 ` Pekon Gupta
-1 siblings, 0 replies; 60+ messages in thread
From: Pekon Gupta @ 2014-03-12 10:49 UTC (permalink / raw)
To: Tony Lindgren, bcousson; +Cc: linux-omap, linux-mtd, 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>
---
arch/arm/boot/dts/am437x-gp-evm.dts | 107 ++++++++++++++++++++++++++++++++++++
1 file changed, 107 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
index df8798e..0027ea7 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -81,6 +81,27 @@
0x164 MUX_MODE0 /* eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
>;
};
+
+ 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 {
@@ -125,3 +146,89 @@
pinctrl-0 = <&mmc1_pins>;
cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
};
+
+&elm {
+ status = "okay";
+};
+
+&gpmc {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_flash_x8>;
+ ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */
+ nand@0,0 {
+ reg = <0 0 0>; /* CS0, offset 0 */
+ 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-on-read = "true";
+ gpmc,wait-on-write = "true";
+ 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
^ permalink raw reply related [flat|nested] 60+ messages in thread* [PATCH v1 3/3] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
@ 2014-03-12 10:49 ` Pekon Gupta
0 siblings, 0 replies; 60+ messages in thread
From: Pekon Gupta @ 2014-03-12 10:49 UTC (permalink / raw)
To: Tony Lindgren, bcousson; +Cc: linux-omap, linux-mtd, 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>
---
arch/arm/boot/dts/am437x-gp-evm.dts | 107 ++++++++++++++++++++++++++++++++++++
1 file changed, 107 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
index df8798e..0027ea7 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -81,6 +81,27 @@
0x164 MUX_MODE0 /* eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
>;
};
+
+ 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 {
@@ -125,3 +146,89 @@
pinctrl-0 = <&mmc1_pins>;
cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
};
+
+&elm {
+ status = "okay";
+};
+
+&gpmc {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_flash_x8>;
+ ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */
+ nand@0,0 {
+ reg = <0 0 0>; /* CS0, offset 0 */
+ 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-on-read = "true";
+ gpmc,wait-on-write = "true";
+ 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
^ permalink raw reply related [flat|nested] 60+ messages in thread* Re: [PATCH v1 3/3] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
2014-03-12 10:49 ` Pekon Gupta
@ 2014-03-12 14:39 ` Nishanth Menon
-1 siblings, 0 replies; 60+ messages in thread
From: Nishanth Menon @ 2014-03-12 14:39 UTC (permalink / raw)
To: Pekon Gupta, Tony Lindgren, bcousson; +Cc: linux-omap, linux-mtd
On 03/12/2014 05:49 AM, Pekon Gupta wrote:
> 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>
> ---
> arch/arm/boot/dts/am437x-gp-evm.dts | 107 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 107 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
> index df8798e..0027ea7 100644
> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
which branch does this apply on? I assume you mean this for Tony's
omap-for-v3.15/dt branch? it would be nice if you'd make that clear in
cover letter.
> @@ -81,6 +81,27 @@
> 0x164 MUX_MODE0 /* eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
> >;
> };
> +
> + 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 {
> @@ -125,3 +146,89 @@
> pinctrl-0 = <&mmc1_pins>;
> cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
> };
> +
> +&elm {
> + status = "okay";
> +};
> +
> +&gpmc {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&nand_flash_x8>;
> + ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */
> + nand@0,0 {
> + reg = <0 0 0>; /* CS0, offset 0 */
> + 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-on-read = "true";
> + gpmc,wait-on-write = "true";
> + 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>;
> + };
> + };
> +};
>
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH v1 3/3] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
@ 2014-03-12 14:39 ` Nishanth Menon
0 siblings, 0 replies; 60+ messages in thread
From: Nishanth Menon @ 2014-03-12 14:39 UTC (permalink / raw)
To: Pekon Gupta, Tony Lindgren, bcousson; +Cc: linux-omap, linux-mtd
On 03/12/2014 05:49 AM, Pekon Gupta wrote:
> 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>
> ---
> arch/arm/boot/dts/am437x-gp-evm.dts | 107 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 107 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
> index df8798e..0027ea7 100644
> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
which branch does this apply on? I assume you mean this for Tony's
omap-for-v3.15/dt branch? it would be nice if you'd make that clear in
cover letter.
> @@ -81,6 +81,27 @@
> 0x164 MUX_MODE0 /* eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
> >;
> };
> +
> + 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 {
> @@ -125,3 +146,89 @@
> pinctrl-0 = <&mmc1_pins>;
> cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
> };
> +
> +&elm {
> + status = "okay";
> +};
> +
> +&gpmc {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&nand_flash_x8>;
> + ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */
> + nand@0,0 {
> + reg = <0 0 0>; /* CS0, offset 0 */
> + 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-on-read = "true";
> + gpmc,wait-on-write = "true";
> + 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>;
> + };
> + };
> +};
>
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 60+ messages in thread* RE: [PATCH v1 3/3] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
2014-03-12 14:39 ` Nishanth Menon
(?)
@ 2014-03-12 18:30 ` Gupta, Pekon
-1 siblings, 0 replies; 60+ messages in thread
From: Gupta, Pekon @ 2014-03-12 18:30 UTC (permalink / raw)
To: Menon, Nishanth, Tony Lindgren, bcousson; +Cc: linux-omap, linux-mtd
>From: Menon, Nishanth
>>On 03/12/2014 05:49 AM, Pekon Gupta wrote:
>> 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>
>> ---
>> arch/arm/boot/dts/am437x-gp-evm.dts | 107 ++++++++++++++++++++++++++++++++++++
>> 1 file changed, 107 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
>> index df8798e..0027ea7 100644
>> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
>> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
>
>which branch does this apply on? I assume you mean this for Tony's
>omap-for-v3.15/dt branch? it would be nice if you'd make that clear in
>cover letter.
>
Sorry, I missed that. I'll keep a note of this next time.
Yes, this patch series is rebased on
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap omap-for-v3.15/dt
with regards, pekon
^ permalink raw reply [flat|nested] 60+ messages in thread
* [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-24 12:24 [PATCH v1 0/3] ARM: dts: am335x-bone: Beaglebone cape DTS Pekon Gupta
@ 2014-06-24 12:24 ` Pekon Gupta
0 siblings, 0 replies; 60+ messages in thread
From: Pekon Gupta @ 2014-06-24 12:24 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-mtd, Jason Kridner, Robert Nelson, 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[ 1] = ON (SYSBOOT[ 0]==0: NAND boot mode selected )
SW2[ 2] = ON (SYSBOOT[ 1]==0: -- do -- )
SW2[ 3] = OFF (SYSBOOT[ 2]==1: -- do -- )
SW2[ 4] = OFF (SYSBOOT[ 3]==1: -- do -- )
SW2[ 5] = ON (SYSBOOT[ 4]==0: -- do -- )
SW2[ 6] = OFF (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
SW2[ 7] = ON (SYSBOOT[ 9]==0: ECC done by ROM )
SW2[ 8] = ON (SYSBOOT[10]==0: Non Muxed device )
SW2[ 9] = 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 | 127 ++++++++++++++++++++++++++
arch/arm/boot/dts/am335x-bone.dts | 1 +
arch/arm/boot/dts/am335x-boneblack.dts | 1 +
3 files changed, 129 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..6d8ebd8
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
@@ -0,0 +1,127 @@
+/*
+ * 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-White and Beaglebone-Black.
+ */
+
+
+&am33xx_pinmux {
+ bbcape_nand_flash_pins: bbcape_nand_flash_pins {
+ 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_MODE0 | PIN_OUTPUT_PULLUP) /* gpmc_wpn.gpmc_wpn */
+ 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 {
+ ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
+ nand@0,0 {
+ status = "disabled";
+ reg = <0 0 4>; /* device IO registers */
+ pinctrl-names = "default";
+ pinctrl-0 = <&bbcape_nand_flash_pins>;
+ ti,nand-ecc-opt = "bch8";
+ ti,elm-id = <&elm>;
+ /* generic bindings */
+ nand-bus-width = <16>;
+ /* vendor specific bindings */
+ 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 305975d..e6d7e54 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
^ permalink raw reply related [flat|nested] 60+ messages in thread* [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-06-24 12:24 ` Pekon Gupta
0 siblings, 0 replies; 60+ messages in thread
From: Pekon Gupta @ 2014-06-24 12:24 UTC (permalink / raw)
To: Tony Lindgren
Cc: Jason Kridner, Robert Nelson, linux-omap, linux-mtd, 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[ 1] = ON (SYSBOOT[ 0]==0: NAND boot mode selected )
SW2[ 2] = ON (SYSBOOT[ 1]==0: -- do -- )
SW2[ 3] = OFF (SYSBOOT[ 2]==1: -- do -- )
SW2[ 4] = OFF (SYSBOOT[ 3]==1: -- do -- )
SW2[ 5] = ON (SYSBOOT[ 4]==0: -- do -- )
SW2[ 6] = OFF (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
SW2[ 7] = ON (SYSBOOT[ 9]==0: ECC done by ROM )
SW2[ 8] = ON (SYSBOOT[10]==0: Non Muxed device )
SW2[ 9] = 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 | 127 ++++++++++++++++++++++++++
arch/arm/boot/dts/am335x-bone.dts | 1 +
arch/arm/boot/dts/am335x-boneblack.dts | 1 +
3 files changed, 129 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..6d8ebd8
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
@@ -0,0 +1,127 @@
+/*
+ * 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-White and Beaglebone-Black.
+ */
+
+
+&am33xx_pinmux {
+ bbcape_nand_flash_pins: bbcape_nand_flash_pins {
+ 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_MODE0 | PIN_OUTPUT_PULLUP) /* gpmc_wpn.gpmc_wpn */
+ 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 {
+ ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
+ nand@0,0 {
+ status = "disabled";
+ reg = <0 0 4>; /* device IO registers */
+ pinctrl-names = "default";
+ pinctrl-0 = <&bbcape_nand_flash_pins>;
+ ti,nand-ecc-opt = "bch8";
+ ti,elm-id = <&elm>;
+ /* generic bindings */
+ nand-bus-width = <16>;
+ /* vendor specific bindings */
+ 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 305975d..e6d7e54 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
^ permalink raw reply related [flat|nested] 60+ messages in thread* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-24 12:24 ` Pekon Gupta
@ 2014-06-25 15:27 ` Ezequiel Garcia
-1 siblings, 0 replies; 60+ messages in thread
From: Ezequiel Garcia @ 2014-06-25 15:27 UTC (permalink / raw)
To: Pekon Gupta
Cc: Tony Lindgren, linux-omap, linux-mtd, Jason Kridner,
Robert Nelson, Guido Martínez
On 24 Jun 05:54 PM, Pekon Gupta wrote:
> +&gpmc {
> + ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
> + nand@0,0 {
> + status = "disabled";
> + reg = <0 0 4>; /* device IO registers */
> + pinctrl-names = "default";
> + pinctrl-0 = <&bbcape_nand_flash_pins>;
> + ti,nand-ecc-opt = "bch8";
> + ti,elm-id = <&elm>;
Don't you need something like this to turn on the elm device?
&elm {
status = "okay";
};
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-06-25 15:27 ` Ezequiel Garcia
0 siblings, 0 replies; 60+ messages in thread
From: Ezequiel Garcia @ 2014-06-25 15:27 UTC (permalink / raw)
To: Pekon Gupta
Cc: Tony Lindgren, Jason Kridner, linux-mtd, linux-omap,
Robert Nelson, Guido Martínez
On 24 Jun 05:54 PM, Pekon Gupta wrote:
> +&gpmc {
> + ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
> + nand@0,0 {
> + status = "disabled";
> + reg = <0 0 4>; /* device IO registers */
> + pinctrl-names = "default";
> + pinctrl-0 = <&bbcape_nand_flash_pins>;
> + ti,nand-ecc-opt = "bch8";
> + ti,elm-id = <&elm>;
Don't you need something like this to turn on the elm device?
&elm {
status = "okay";
};
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 60+ messages in thread* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-25 15:27 ` Ezequiel Garcia
@ 2014-06-26 5:43 ` Gupta, Pekon
-1 siblings, 0 replies; 60+ messages in thread
From: Gupta, Pekon @ 2014-06-26 5:43 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Tony Lindgren, linux-omap, linux-mtd, Jason Kridner,
Robert Nelson, Guido Martínez
>From: Ezequiel Garcia [mailto:ezequiel@vanguardiasur.com.ar]
>>On 24 Jun 05:54 PM, Pekon Gupta wrote:
>> +&gpmc {
>> + ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
>> + nand@0,0 {
>> + status = "disabled";
>> + reg = <0 0 4>; /* device IO registers */
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&bbcape_nand_flash_pins>;
>> + ti,nand-ecc-opt = "bch8";
>> + ti,elm-id = <&elm>;
>
>Don't you need something like this to turn on the elm device?
>
>&elm {
> status = "okay";
>};
>
No, This was the intend of these patches to keep cape DTS as "disabled"
so that:
(1)These patches should not change the behavior of existing DTS
(am335x-boneblack.dts or am335x-bone.dts), or conflict with
any existing node or other cape DTS.
(2) In-case of share-pin mux where multiple capes use same pins
Cape DTS should not conflict each other.
Now, to enable the choice of cape without hacking any source file,
user can use u-boot commands (refer to example in cover-letter):
/* load DTB */
u-boot> tftp 0x81000000 am335x-boneblack.dtb
u-boot> fdt addr 0x81000000
/* disabled conflicting MMC2 (eMMC) */
u-boot> fdt set /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
/* enable NAND cape*/
u-boot> fdt set /ocp/elm status \o\k\a\y
u-boot> fdt set /ocp/gpmc status \o\k\a\y
u-boot> fdt set /ocp/gpmc/nand status \o\k\a\y
And then boot using this DTB loaded at 0x81000000
(you can put all these commands in uEnv as part of $bootcmd)
with regards, Pekon
^ permalink raw reply [flat|nested] 60+ messages in thread* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-06-26 5:43 ` Gupta, Pekon
0 siblings, 0 replies; 60+ messages in thread
From: Gupta, Pekon @ 2014-06-26 5:43 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Tony Lindgren, Jason Kridner, linux-mtd, linux-omap,
Robert Nelson, Guido Martínez
>From: Ezequiel Garcia [mailto:ezequiel@vanguardiasur.com.ar]
>>On 24 Jun 05:54 PM, Pekon Gupta wrote:
>> +&gpmc {
>> + ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
>> + nand@0,0 {
>> + status = "disabled";
>> + reg = <0 0 4>; /* device IO registers */
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&bbcape_nand_flash_pins>;
>> + ti,nand-ecc-opt = "bch8";
>> + ti,elm-id = <&elm>;
>
>Don't you need something like this to turn on the elm device?
>
>&elm {
> status = "okay";
>};
>
No, This was the intend of these patches to keep cape DTS as "disabled"
so that:
(1)These patches should not change the behavior of existing DTS
(am335x-boneblack.dts or am335x-bone.dts), or conflict with
any existing node or other cape DTS.
(2) In-case of share-pin mux where multiple capes use same pins
Cape DTS should not conflict each other.
Now, to enable the choice of cape without hacking any source file,
user can use u-boot commands (refer to example in cover-letter):
/* load DTB */
u-boot> tftp 0x81000000 am335x-boneblack.dtb
u-boot> fdt addr 0x81000000
/* disabled conflicting MMC2 (eMMC) */
u-boot> fdt set /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
/* enable NAND cape*/
u-boot> fdt set /ocp/elm status \o\k\a\y
u-boot> fdt set /ocp/gpmc status \o\k\a\y
u-boot> fdt set /ocp/gpmc/nand status \o\k\a\y
And then boot using this DTB loaded at 0x81000000
(you can put all these commands in uEnv as part of $bootcmd)
with regards, Pekon
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-24 12:24 ` Pekon Gupta
@ 2014-06-26 10:40 ` Tony Lindgren
-1 siblings, 0 replies; 60+ messages in thread
From: Tony Lindgren @ 2014-06-26 10:40 UTC (permalink / raw)
To: Pekon Gupta; +Cc: linux-omap, linux-mtd, Jason Kridner, Robert Nelson
* Pekon Gupta <pekon@ti.com> [140624 05:26]:
> +
> +&gpmc {
> + ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
> + nand@0,0 {
> + status = "disabled";
> + reg = <0 0 4>; /* device IO registers */
Hmm so what about other capes potentially also using GPMC CS0?
Can you please do a check with two .dtsi files trying to use
GPMC CS0 and see what the produced .dtb file looks like after
decompiling it with dtc?
I'd assume the 16MB GPMC partition will be just fine for many
devices and can be also be larger if NOR needs it so maybe it
can be handled for almost all the cases.
The names for devices must be unique though to avoid them
getting merged. And I don't know if gpmc.c skips disabled devices
properly.
Regards,
Tony
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-06-26 10:40 ` Tony Lindgren
0 siblings, 0 replies; 60+ messages in thread
From: Tony Lindgren @ 2014-06-26 10:40 UTC (permalink / raw)
To: Pekon Gupta; +Cc: Jason Kridner, Robert Nelson, linux-omap, linux-mtd
* Pekon Gupta <pekon@ti.com> [140624 05:26]:
> +
> +&gpmc {
> + ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
> + nand@0,0 {
> + status = "disabled";
> + reg = <0 0 4>; /* device IO registers */
Hmm so what about other capes potentially also using GPMC CS0?
Can you please do a check with two .dtsi files trying to use
GPMC CS0 and see what the produced .dtb file looks like after
decompiling it with dtc?
I'd assume the 16MB GPMC partition will be just fine for many
devices and can be also be larger if NOR needs it so maybe it
can be handled for almost all the cases.
The names for devices must be unique though to avoid them
getting merged. And I don't know if gpmc.c skips disabled devices
properly.
Regards,
Tony
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-26 10:40 ` Tony Lindgren
@ 2014-06-26 15:06 ` Guido Martínez
-1 siblings, 0 replies; 60+ messages in thread
From: Guido Martínez @ 2014-06-26 15:06 UTC (permalink / raw)
To: Tony Lindgren, Pekon Gupta
Cc: linux-omap, linux-mtd, Jason Kridner, Robert Nelson
Hi Tony, Pekon
On Thu, Jun 26, 2014 at 03:40:44AM -0700, Tony Lindgren wrote:
> * Pekon Gupta <pekon@ti.com> [140624 05:26]:
> > +
> > +&gpmc {
> > + ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
> > + nand@0,0 {
> > + status = "disabled";
> > + reg = <0 0 4>; /* device IO registers */
>
> Hmm so what about other capes potentially also using GPMC CS0?
>
> Can you please do a check with two .dtsi files trying to use
> GPMC CS0 and see what the produced .dtb file looks like after
> decompiling it with dtc?
>
> I'd assume the 16MB GPMC partition will be just fine for many
> devices and can be also be larger if NOR needs it so maybe it
> can be handled for almost all the cases.
>
> The names for devices must be unique though to avoid them
> getting merged. And I don't know if gpmc.c skips disabled devices
> properly.
It doesn't. I've just sent a patch for it.
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266966.html
Regards,
Guido
>
> Regards,
>
> Tony
> --
> 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
--
Guido Martínez, VanguardiaSur
www.vanguardiasur.com.ar
--
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
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-06-26 15:06 ` Guido Martínez
0 siblings, 0 replies; 60+ messages in thread
From: Guido Martínez @ 2014-06-26 15:06 UTC (permalink / raw)
To: Tony Lindgren, Pekon Gupta
Cc: Jason Kridner, Robert Nelson, linux-omap, linux-mtd
Hi Tony, Pekon
On Thu, Jun 26, 2014 at 03:40:44AM -0700, Tony Lindgren wrote:
> * Pekon Gupta <pekon@ti.com> [140624 05:26]:
> > +
> > +&gpmc {
> > + ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
> > + nand@0,0 {
> > + status = "disabled";
> > + reg = <0 0 4>; /* device IO registers */
>
> Hmm so what about other capes potentially also using GPMC CS0?
>
> Can you please do a check with two .dtsi files trying to use
> GPMC CS0 and see what the produced .dtb file looks like after
> decompiling it with dtc?
>
> I'd assume the 16MB GPMC partition will be just fine for many
> devices and can be also be larger if NOR needs it so maybe it
> can be handled for almost all the cases.
>
> The names for devices must be unique though to avoid them
> getting merged. And I don't know if gpmc.c skips disabled devices
> properly.
It doesn't. I've just sent a patch for it.
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266966.html
Regards,
Guido
>
> Regards,
>
> Tony
> --
> 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
--
Guido Martínez, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 60+ messages in thread* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-26 15:06 ` Guido Martínez
@ 2014-07-01 7:01 ` Gupta, Pekon
-1 siblings, 0 replies; 60+ messages in thread
From: Gupta, Pekon @ 2014-07-01 7:01 UTC (permalink / raw)
To: Guido Martínez, Tony Lindgren
Cc: linux-omap, linux-mtd, Jason Kridner, Robert Nelson
Hi Guido,
>From: Guido Martínez
>>On Thu, Jun 26, 2014 at 03:40:44AM -0700, Tony Lindgren wrote:
>> * Pekon Gupta <pekon@ti.com> [140624 05:26]:
>> > +
>> > +&gpmc {
>> > + ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
>> > + nand@0,0 {
>> > + status = "disabled";
>> > + reg = <0 0 4>; /* device IO registers */
>>
>> Hmm so what about other capes potentially also using GPMC CS0?
>>
>> Can you please do a check with two .dtsi files trying to use
>> GPMC CS0 and see what the produced .dtb file looks like after
>> decompiling it with dtc?
>>
>> I'd assume the 16MB GPMC partition will be just fine for many
>> devices and can be also be larger if NOR needs it so maybe it
>> can be handled for almost all the cases.
>>
>> The names for devices must be unique though to avoid them
>> getting merged. And I don't know if gpmc.c skips disabled devices
>> properly.
>It doesn't. I've just sent a patch for it.
>
>http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266966.html
>
I don't think we need above patch.
Helper macro "for_each_available_child_of_node" internally takes care
of skipping nodes with status="disabled".
$KERNEL/include/linux/of.h
#define for_each_available_child_of_node(parent, child) \
for (child = of_get_next_available_child(parent, NULL); child != NULL; \
child = of_get_next_available_child(parent, child))
$KERNEL/drivers/of/base.c @@ of_get_next_available_child(...) {
...
if (!__of_device_is_available(next))
continue;
...
with regards, pekon
--
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
^ permalink raw reply [flat|nested] 60+ messages in thread* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-07-01 7:01 ` Gupta, Pekon
0 siblings, 0 replies; 60+ messages in thread
From: Gupta, Pekon @ 2014-07-01 7:01 UTC (permalink / raw)
To: Guido Martínez, Tony Lindgren
Cc: Jason Kridner, Robert Nelson, linux-omap, linux-mtd
Hi Guido,
>From: Guido Martínez
>>On Thu, Jun 26, 2014 at 03:40:44AM -0700, Tony Lindgren wrote:
>> * Pekon Gupta <pekon@ti.com> [140624 05:26]:
>> > +
>> > +&gpmc {
>> > + ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
>> > + nand@0,0 {
>> > + status = "disabled";
>> > + reg = <0 0 4>; /* device IO registers */
>>
>> Hmm so what about other capes potentially also using GPMC CS0?
>>
>> Can you please do a check with two .dtsi files trying to use
>> GPMC CS0 and see what the produced .dtb file looks like after
>> decompiling it with dtc?
>>
>> I'd assume the 16MB GPMC partition will be just fine for many
>> devices and can be also be larger if NOR needs it so maybe it
>> can be handled for almost all the cases.
>>
>> The names for devices must be unique though to avoid them
>> getting merged. And I don't know if gpmc.c skips disabled devices
>> properly.
>It doesn't. I've just sent a patch for it.
>
>http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266966.html
>
I don't think we need above patch.
Helper macro "for_each_available_child_of_node" internally takes care
of skipping nodes with status="disabled".
$KERNEL/include/linux/of.h
#define for_each_available_child_of_node(parent, child) \
for (child = of_get_next_available_child(parent, NULL); child != NULL; \
child = of_get_next_available_child(parent, child))
$KERNEL/drivers/of/base.c @@ of_get_next_available_child(...) {
...
if (!__of_device_is_available(next))
continue;
...
with regards, pekon
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-07-01 7:01 ` Gupta, Pekon
@ 2014-07-01 23:42 ` Guido Martínez
-1 siblings, 0 replies; 60+ messages in thread
From: Guido Martínez @ 2014-07-01 23:42 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Tony Lindgren, linux-omap, linux-mtd, Jason Kridner, Robert Nelson
Hi Pekon,
On Tue, Jul 01, 2014 at 07:01:03AM +0000, Gupta, Pekon wrote:
> >http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266966.html
> >
> I don't think we need above patch.
> Helper macro "for_each_available_child_of_node" internally takes care
> of skipping nodes with status="disabled".
>
> $KERNEL/include/linux/of.h
> #define for_each_available_child_of_node(parent, child) \
> for (child = of_get_next_available_child(parent, NULL); child != NULL; \
> child = of_get_next_available_child(parent, child))
>
> $KERNEL/drivers/of/base.c @@ of_get_next_available_child(...) {
> ...
> if (!__of_device_is_available(next))
> continue;
> ...
Yes, that's why I suggest using that macro. It's not currently used
in gpmc.c and my patch changes the 'for_each_child_of_node' to a
'for_each_available_child_of_node'. Or am I missing something?
Regards,
--
Guido Martínez, VanguardiaSur
www.vanguardiasur.com.ar
--
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
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-07-01 23:42 ` Guido Martínez
0 siblings, 0 replies; 60+ messages in thread
From: Guido Martínez @ 2014-07-01 23:42 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Tony Lindgren, Jason Kridner, linux-omap, linux-mtd, Robert Nelson
Hi Pekon,
On Tue, Jul 01, 2014 at 07:01:03AM +0000, Gupta, Pekon wrote:
> >http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266966.html
> >
> I don't think we need above patch.
> Helper macro "for_each_available_child_of_node" internally takes care
> of skipping nodes with status="disabled".
>
> $KERNEL/include/linux/of.h
> #define for_each_available_child_of_node(parent, child) \
> for (child = of_get_next_available_child(parent, NULL); child != NULL; \
> child = of_get_next_available_child(parent, child))
>
> $KERNEL/drivers/of/base.c @@ of_get_next_available_child(...) {
> ...
> if (!__of_device_is_available(next))
> continue;
> ...
Yes, that's why I suggest using that macro. It's not currently used
in gpmc.c and my patch changes the 'for_each_child_of_node' to a
'for_each_available_child_of_node'. Or am I missing something?
Regards,
--
Guido Martínez, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 60+ messages in thread* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-07-01 23:42 ` Guido Martínez
@ 2014-07-02 5:29 ` Gupta, Pekon
-1 siblings, 0 replies; 60+ messages in thread
From: Gupta, Pekon @ 2014-07-02 5:29 UTC (permalink / raw)
To: Guido Martínez
Cc: Tony Lindgren, linux-omap, linux-mtd, Jason Kridner, Robert Nelson
>From: Guido Martínez [mailto:guido@vanguardiasur.com.ar]
>>On Tue, Jul 01, 2014 at 07:01:03AM +0000, Gupta, Pekon wrote:
>> >http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266966.html
>> >
>> I don't think we need above patch.
>> Helper macro "for_each_available_child_of_node" internally takes care
>> of skipping nodes with status="disabled".
>>
>> $KERNEL/include/linux/of.h
>> #define for_each_available_child_of_node(parent, child) \
>> for (child = of_get_next_available_child(parent, NULL); child != NULL; \
>> child = of_get_next_available_child(parent, child))
>>
>> $KERNEL/drivers/of/base.c @@ of_get_next_available_child(...) {
>> ...
>> if (!__of_device_is_available(next))
>> continue;
>> ...
>Yes, that's why I suggest using that macro. It's not currently used
>in gpmc.c and my patch changes the 'for_each_child_of_node' to a
>'for_each_available_child_of_node'. Or am I missing something?
>
Oops my bad. I was probably dreaming, I already had your patch in my tree
before reviewing the code. So please ignore my previous email.
with regards, pekon
--
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
^ permalink raw reply [flat|nested] 60+ messages in thread* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-07-02 5:29 ` Gupta, Pekon
0 siblings, 0 replies; 60+ messages in thread
From: Gupta, Pekon @ 2014-07-02 5:29 UTC (permalink / raw)
To: Guido Martínez
Cc: Tony Lindgren, Jason Kridner, linux-omap, linux-mtd, Robert Nelson
>From: Guido Martínez [mailto:guido@vanguardiasur.com.ar]
>>On Tue, Jul 01, 2014 at 07:01:03AM +0000, Gupta, Pekon wrote:
>> >http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266966.html
>> >
>> I don't think we need above patch.
>> Helper macro "for_each_available_child_of_node" internally takes care
>> of skipping nodes with status="disabled".
>>
>> $KERNEL/include/linux/of.h
>> #define for_each_available_child_of_node(parent, child) \
>> for (child = of_get_next_available_child(parent, NULL); child != NULL; \
>> child = of_get_next_available_child(parent, child))
>>
>> $KERNEL/drivers/of/base.c @@ of_get_next_available_child(...) {
>> ...
>> if (!__of_device_is_available(next))
>> continue;
>> ...
>Yes, that's why I suggest using that macro. It's not currently used
>in gpmc.c and my patch changes the 'for_each_child_of_node' to a
>'for_each_available_child_of_node'. Or am I missing something?
>
Oops my bad. I was probably dreaming, I already had your patch in my tree
before reviewing the code. So please ignore my previous email.
with regards, pekon
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-24 12:24 ` Pekon Gupta
@ 2014-06-26 19:48 ` Guido Martínez
-1 siblings, 0 replies; 60+ messages in thread
From: Guido Martínez @ 2014-06-26 19:48 UTC (permalink / raw)
To: Pekon Gupta
Cc: Tony Lindgren, linux-omap, linux-mtd, Jason Kridner, Robert Nelson
Hi Pekon,
On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
> 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[ 1] = ON (SYSBOOT[ 0]==0: NAND boot mode selected )
> SW2[ 2] = ON (SYSBOOT[ 1]==0: -- do -- )
> SW2[ 3] = OFF (SYSBOOT[ 2]==1: -- do -- )
> SW2[ 4] = OFF (SYSBOOT[ 3]==1: -- do -- )
> SW2[ 5] = ON (SYSBOOT[ 4]==0: -- do -- )
> SW2[ 6] = OFF (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
> SW2[ 7] = ON (SYSBOOT[ 9]==0: ECC done by ROM )
> SW2[ 8] = ON (SYSBOOT[10]==0: Non Muxed device )
> SW2[ 9] = 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 | 127 ++++++++++++++++++++++++++
> arch/arm/boot/dts/am335x-bone.dts | 1 +
> arch/arm/boot/dts/am335x-boneblack.dts | 1 +
> 3 files changed, 129 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..6d8ebd8
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
> @@ -0,0 +1,127 @@
> +/*
> + * 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-White and Beaglebone-Black.
> + */
> +
> +
> +&am33xx_pinmux {
> + bbcape_nand_flash_pins: bbcape_nand_flash_pins {
> + 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_MODE0 | PIN_OUTPUT_PULLUP) /* gpmc_wpn.gpmc_wpn */
> + 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 {
> + ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
> + nand@0,0 {
> + status = "disabled";
> + reg = <0 0 4>; /* device IO registers */
> + pinctrl-names = "default";
> + pinctrl-0 = <&bbcape_nand_flash_pins>;
This doesn't seem to work as pinctrl properties are not parsed for
childs of the gpmc node. Did this work for you?
Putting this in the gpmc node makes it work, but how will we control
pins for the nand and nor independently? I believe there is currently no
support for muxing individual gpmc devices. If we want to add both
devices to the DT and enable them as needed we'd need to add support for
this, right?
> + ti,nand-ecc-opt = "bch8";
> + ti,elm-id = <&elm>;
> + /* generic bindings */
> + nand-bus-width = <16>;
> + /* vendor specific bindings */
> + 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 305975d..e6d7e54 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
>
> --
> 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
--
Guido Martínez, VanguardiaSur
www.vanguardiasur.com.ar
--
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
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-06-26 19:48 ` Guido Martínez
0 siblings, 0 replies; 60+ messages in thread
From: Guido Martínez @ 2014-06-26 19:48 UTC (permalink / raw)
To: Pekon Gupta
Cc: Tony Lindgren, Jason Kridner, linux-omap, linux-mtd, Robert Nelson
Hi Pekon,
On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
> 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[ 1] = ON (SYSBOOT[ 0]==0: NAND boot mode selected )
> SW2[ 2] = ON (SYSBOOT[ 1]==0: -- do -- )
> SW2[ 3] = OFF (SYSBOOT[ 2]==1: -- do -- )
> SW2[ 4] = OFF (SYSBOOT[ 3]==1: -- do -- )
> SW2[ 5] = ON (SYSBOOT[ 4]==0: -- do -- )
> SW2[ 6] = OFF (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
> SW2[ 7] = ON (SYSBOOT[ 9]==0: ECC done by ROM )
> SW2[ 8] = ON (SYSBOOT[10]==0: Non Muxed device )
> SW2[ 9] = 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 | 127 ++++++++++++++++++++++++++
> arch/arm/boot/dts/am335x-bone.dts | 1 +
> arch/arm/boot/dts/am335x-boneblack.dts | 1 +
> 3 files changed, 129 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..6d8ebd8
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
> @@ -0,0 +1,127 @@
> +/*
> + * 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-White and Beaglebone-Black.
> + */
> +
> +
> +&am33xx_pinmux {
> + bbcape_nand_flash_pins: bbcape_nand_flash_pins {
> + 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_MODE0 | PIN_OUTPUT_PULLUP) /* gpmc_wpn.gpmc_wpn */
> + 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 {
> + ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
> + nand@0,0 {
> + status = "disabled";
> + reg = <0 0 4>; /* device IO registers */
> + pinctrl-names = "default";
> + pinctrl-0 = <&bbcape_nand_flash_pins>;
This doesn't seem to work as pinctrl properties are not parsed for
childs of the gpmc node. Did this work for you?
Putting this in the gpmc node makes it work, but how will we control
pins for the nand and nor independently? I believe there is currently no
support for muxing individual gpmc devices. If we want to add both
devices to the DT and enable them as needed we'd need to add support for
this, right?
> + ti,nand-ecc-opt = "bch8";
> + ti,elm-id = <&elm>;
> + /* generic bindings */
> + nand-bus-width = <16>;
> + /* vendor specific bindings */
> + 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 305975d..e6d7e54 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
>
> --
> 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
--
Guido Martínez, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 60+ messages in thread* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-26 19:48 ` Guido Martínez
@ 2014-06-27 21:06 ` Gupta, Pekon
-1 siblings, 0 replies; 60+ messages in thread
From: Gupta, Pekon @ 2014-06-27 21:06 UTC (permalink / raw)
To: Guido Martínez
Cc: Tony Lindgren, linux-omap, linux-mtd, Jason Kridner, Robert Nelson
>From: Guido Martínez [mailto:guido@vanguardiasur.com.ar]
>>On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
[...]
>> +&gpmc {
>> + ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
>> + nand@0,0 {
>> + status = "disabled";
>> + reg = <0 0 4>; /* device IO registers */
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&bbcape_nand_flash_pins>;
>This doesn't seem to work as pinctrl properties are not parsed for
>childs of the gpmc node. Did this work for you?
>Putting this in the gpmc node makes it work, but how will we control
>pins for the nand and nor independently? I believe there is currently no
>support for muxing individual gpmc devices. If we want to add both
>devices to the DT and enable them as needed we'd need to add support for
>this, right?
>
Yes, And that should be the case, because different devices would be
connected to different chip-selects, so there should be support of
providing individual pin-mux for different GPMC devices.
Currently both NAND and NOR cape share GPMC_CS0, so both NAND and NOR
capes will not work simultaneously. But I'm planning to modify NOR cape
hardware at my end to use GPMC_CS1 instead of GPMC_CS0.
- NAND on GPMC_CS0
- NOR on GPMC_CS1
In addition to pin-mux you may also require following patch:
http://www.spinics.net/lists/linux-omap/msg107950.html
Also, I should have marked this series as RFC as its not fully tested.
My main intention was to get acknowledgement about cape DTS from
various users and Tony Lindgren <tony@atomide.com>.
Now as Tony has given some acceptance for these kind of cape DTS,
I'll clean-up and re-send these patches with better testing and GPMC fixes.
with regards, pekon
with regards, pekon
--
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
^ permalink raw reply [flat|nested] 60+ messages in thread* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-06-27 21:06 ` Gupta, Pekon
0 siblings, 0 replies; 60+ messages in thread
From: Gupta, Pekon @ 2014-06-27 21:06 UTC (permalink / raw)
To: Guido Martínez
Cc: Tony Lindgren, Jason Kridner, linux-omap, linux-mtd, Robert Nelson
>From: Guido Martínez [mailto:guido@vanguardiasur.com.ar]
>>On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
[...]
>> +&gpmc {
>> + ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
>> + nand@0,0 {
>> + status = "disabled";
>> + reg = <0 0 4>; /* device IO registers */
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&bbcape_nand_flash_pins>;
>This doesn't seem to work as pinctrl properties are not parsed for
>childs of the gpmc node. Did this work for you?
>Putting this in the gpmc node makes it work, but how will we control
>pins for the nand and nor independently? I believe there is currently no
>support for muxing individual gpmc devices. If we want to add both
>devices to the DT and enable them as needed we'd need to add support for
>this, right?
>
Yes, And that should be the case, because different devices would be
connected to different chip-selects, so there should be support of
providing individual pin-mux for different GPMC devices.
Currently both NAND and NOR cape share GPMC_CS0, so both NAND and NOR
capes will not work simultaneously. But I'm planning to modify NOR cape
hardware at my end to use GPMC_CS1 instead of GPMC_CS0.
- NAND on GPMC_CS0
- NOR on GPMC_CS1
In addition to pin-mux you may also require following patch:
http://www.spinics.net/lists/linux-omap/msg107950.html
Also, I should have marked this series as RFC as its not fully tested.
My main intention was to get acknowledgement about cape DTS from
various users and Tony Lindgren <tony@atomide.com>.
Now as Tony has given some acceptance for these kind of cape DTS,
I'll clean-up and re-send these patches with better testing and GPMC fixes.
with regards, pekon
with regards, pekon
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-27 21:06 ` Gupta, Pekon
@ 2014-07-01 8:47 ` Tony Lindgren
-1 siblings, 0 replies; 60+ messages in thread
From: Tony Lindgren @ 2014-07-01 8:47 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Guido Martínez, linux-omap, linux-mtd, Jason Kridner, Robert Nelson
* Gupta, Pekon <pekon@ti.com> [140627 14:08]:
> >From: Guido Martínez [mailto:guido@vanguardiasur.com.ar]
> >>On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
>
> [...]
>
> >> +&gpmc {
> >> + ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
> >> + nand@0,0 {
> >> + status = "disabled";
> >> + reg = <0 0 4>; /* device IO registers */
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&bbcape_nand_flash_pins>;
> >This doesn't seem to work as pinctrl properties are not parsed for
> >childs of the gpmc node. Did this work for you?
> >Putting this in the gpmc node makes it work, but how will we control
> >pins for the nand and nor independently? I believe there is currently no
> >support for muxing individual gpmc devices. If we want to add both
> >devices to the DT and enable them as needed we'd need to add support for
> >this, right?
> >
> Yes, And that should be the case, because different devices would be
> connected to different chip-selects, so there should be support of
> providing individual pin-mux for different GPMC devices.
>
> Currently both NAND and NOR cape share GPMC_CS0, so both NAND and NOR
> capes will not work simultaneously. But I'm planning to modify NOR cape
> hardware at my end to use GPMC_CS1 instead of GPMC_CS0.
> - NAND on GPMC_CS0
> - NOR on GPMC_CS1
Hmm but we should have these working with both using CS0 without
any need to modify the hardware though?
In that case we should make sure we always set large enough GPMC
partition and that the pins are muxed for the connected GPMC
devices only.
Regards,
Tony
--
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
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-07-01 8:47 ` Tony Lindgren
0 siblings, 0 replies; 60+ messages in thread
From: Tony Lindgren @ 2014-07-01 8:47 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Jason Kridner, Robert Nelson, linux-omap, linux-mtd, Guido Martínez
* Gupta, Pekon <pekon@ti.com> [140627 14:08]:
> >From: Guido Martínez [mailto:guido@vanguardiasur.com.ar]
> >>On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
>
> [...]
>
> >> +&gpmc {
> >> + ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
> >> + nand@0,0 {
> >> + status = "disabled";
> >> + reg = <0 0 4>; /* device IO registers */
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&bbcape_nand_flash_pins>;
> >This doesn't seem to work as pinctrl properties are not parsed for
> >childs of the gpmc node. Did this work for you?
> >Putting this in the gpmc node makes it work, but how will we control
> >pins for the nand and nor independently? I believe there is currently no
> >support for muxing individual gpmc devices. If we want to add both
> >devices to the DT and enable them as needed we'd need to add support for
> >this, right?
> >
> Yes, And that should be the case, because different devices would be
> connected to different chip-selects, so there should be support of
> providing individual pin-mux for different GPMC devices.
>
> Currently both NAND and NOR cape share GPMC_CS0, so both NAND and NOR
> capes will not work simultaneously. But I'm planning to modify NOR cape
> hardware at my end to use GPMC_CS1 instead of GPMC_CS0.
> - NAND on GPMC_CS0
> - NOR on GPMC_CS1
Hmm but we should have these working with both using CS0 without
any need to modify the hardware though?
In that case we should make sure we always set large enough GPMC
partition and that the pins are muxed for the connected GPMC
devices only.
Regards,
Tony
^ permalink raw reply [flat|nested] 60+ messages in thread* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-07-01 8:47 ` Tony Lindgren
@ 2014-07-01 9:07 ` Gupta, Pekon
-1 siblings, 0 replies; 60+ messages in thread
From: Gupta, Pekon @ 2014-07-01 9:07 UTC (permalink / raw)
To: Tony Lindgren, Guido Martínez
Cc: linux-omap, linux-mtd, Jason Kridner, Robert Nelson
>From: Tony Lindgren [mailto:tony@atomide.com]
>>* Gupta, Pekon <pekon@ti.com> [140627 14:08]:
>> >From: Guido Martínez [mailto:guido@vanguardiasur.com.ar]
>> >>On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
>>
>> [...]
>>
>> >> +&gpmc {
>> >> + ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
>> >> + nand@0,0 {
>> >> + status = "disabled";
>> >> + reg = <0 0 4>; /* device IO registers */
>> >> + pinctrl-names = "default";
>> >> + pinctrl-0 = <&bbcape_nand_flash_pins>;
>> >This doesn't seem to work as pinctrl properties are not parsed for
>> >childs of the gpmc node. Did this work for you?
>> >Putting this in the gpmc node makes it work, but how will we control
>> >pins for the nand and nor independently? I believe there is currently no
>> >support for muxing individual gpmc devices. If we want to add both
>> >devices to the DT and enable them as needed we'd need to add support for
>> >this, right?
>> >
>> Yes, And that should be the case, because different devices would be
>> connected to different chip-selects, so there should be support of
>> providing individual pin-mux for different GPMC devices.
>>
>> Currently both NAND and NOR cape share GPMC_CS0, so both NAND and NOR
>> capes will not work simultaneously. But I'm planning to modify NOR cape
>> hardware at my end to use GPMC_CS1 instead of GPMC_CS0.
>> - NAND on GPMC_CS0
>> - NOR on GPMC_CS1
>
>Hmm but we should have these working with both using CS0 without
>any need to modify the hardware though?
>
Yes, but one at a time. That mean either of 'NAND cape' or 'NOR cape'.
If you need both working simultaneously as 2 separate devices attached
to GPMC, then you need 2 separate chip-selects, which is what I'm trying
to test with [1].
>In that case we should make sure we always set large enough GPMC
>partition
Yes, this is taken care with introduction of NOR cape in
[PATCH v1 2/3] ARM: dts: am335x-bone: add support for beaglebone NOR cape
&gpmc {
- ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
+ ranges = <0 0 0x08000000 0x01000000>; /* address offset=128MB, range=128Mb=16MB */
This GPMC partition suffices for both NAND and NOR requirements.
> and that the pins are muxed for the connected GPMC
>devices only.
>
Pin mux is something I need to re-work, because currently
I've tested either NAND or NOR individually, not together.
Also as mentioned above by Guido, pin-ctrl property is not parsed individually
for GPMC children, Instead pin-ctrl is set once for GPMC as a whole.
Do you have any suggestions on how pin-ctrl should be set if we have
multiple devices connected to GPMC like;
All these devices will share:
- control lines (gpmc_wait, gpmc_ben_cle, gpmc_advn_ale, gpmc_we, gpmc_oe_ren)
- *some* data lines (gpmc_ad[])
- *some* address lines (gpmc_a[])
- but chip-selects will be different:
gpmc_cs0: NAND
gpmc_cs1: NOR
gpmc_cs2: SMSC91xx
gpmc_cs3: Camera
with regards, Pekon
>Regards,
>
>Tony
[1] http://www.spinics.net/lists/linux-omap/msg107950.html
^ permalink raw reply [flat|nested] 60+ messages in thread* RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-07-01 9:07 ` Gupta, Pekon
0 siblings, 0 replies; 60+ messages in thread
From: Gupta, Pekon @ 2014-07-01 9:07 UTC (permalink / raw)
To: Tony Lindgren, Guido Martínez
Cc: Jason Kridner, Robert Nelson, linux-omap, linux-mtd
>From: Tony Lindgren [mailto:tony@atomide.com]
>>* Gupta, Pekon <pekon@ti.com> [140627 14:08]:
>> >From: Guido Martínez [mailto:guido@vanguardiasur.com.ar]
>> >>On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
>>
>> [...]
>>
>> >> +&gpmc {
>> >> + ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
>> >> + nand@0,0 {
>> >> + status = "disabled";
>> >> + reg = <0 0 4>; /* device IO registers */
>> >> + pinctrl-names = "default";
>> >> + pinctrl-0 = <&bbcape_nand_flash_pins>;
>> >This doesn't seem to work as pinctrl properties are not parsed for
>> >childs of the gpmc node. Did this work for you?
>> >Putting this in the gpmc node makes it work, but how will we control
>> >pins for the nand and nor independently? I believe there is currently no
>> >support for muxing individual gpmc devices. If we want to add both
>> >devices to the DT and enable them as needed we'd need to add support for
>> >this, right?
>> >
>> Yes, And that should be the case, because different devices would be
>> connected to different chip-selects, so there should be support of
>> providing individual pin-mux for different GPMC devices.
>>
>> Currently both NAND and NOR cape share GPMC_CS0, so both NAND and NOR
>> capes will not work simultaneously. But I'm planning to modify NOR cape
>> hardware at my end to use GPMC_CS1 instead of GPMC_CS0.
>> - NAND on GPMC_CS0
>> - NOR on GPMC_CS1
>
>Hmm but we should have these working with both using CS0 without
>any need to modify the hardware though?
>
Yes, but one at a time. That mean either of 'NAND cape' or 'NOR cape'.
If you need both working simultaneously as 2 separate devices attached
to GPMC, then you need 2 separate chip-selects, which is what I'm trying
to test with [1].
>In that case we should make sure we always set large enough GPMC
>partition
Yes, this is taken care with introduction of NOR cape in
[PATCH v1 2/3] ARM: dts: am335x-bone: add support for beaglebone NOR cape
&gpmc {
- ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
+ ranges = <0 0 0x08000000 0x01000000>; /* address offset=128MB, range=128Mb=16MB */
This GPMC partition suffices for both NAND and NOR requirements.
> and that the pins are muxed for the connected GPMC
>devices only.
>
Pin mux is something I need to re-work, because currently
I've tested either NAND or NOR individually, not together.
Also as mentioned above by Guido, pin-ctrl property is not parsed individually
for GPMC children, Instead pin-ctrl is set once for GPMC as a whole.
Do you have any suggestions on how pin-ctrl should be set if we have
multiple devices connected to GPMC like;
All these devices will share:
- control lines (gpmc_wait, gpmc_ben_cle, gpmc_advn_ale, gpmc_we, gpmc_oe_ren)
- *some* data lines (gpmc_ad[])
- *some* address lines (gpmc_a[])
- but chip-selects will be different:
gpmc_cs0: NAND
gpmc_cs1: NOR
gpmc_cs2: SMSC91xx
gpmc_cs3: Camera
with regards, Pekon
>Regards,
>
>Tony
[1] http://www.spinics.net/lists/linux-omap/msg107950.html
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-07-01 9:07 ` Gupta, Pekon
@ 2014-07-01 13:28 ` Tony Lindgren
-1 siblings, 0 replies; 60+ messages in thread
From: Tony Lindgren @ 2014-07-01 13:28 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Guido Martínez, linux-omap, linux-mtd, Jason Kridner, Robert Nelson
* Gupta, Pekon <pekon@ti.com> [140701 02:09]:
> >From: Tony Lindgren [mailto:tony@atomide.com]
> >>* Gupta, Pekon <pekon@ti.com> [140627 14:08]:
> >> >From: Guido Martínez [mailto:guido@vanguardiasur.com.ar]
> >> >>On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
> >>
> >> [...]
> >>
> >> >> +&gpmc {
> >> >> + ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
> >> >> + nand@0,0 {
> >> >> + status = "disabled";
> >> >> + reg = <0 0 4>; /* device IO registers */
> >> >> + pinctrl-names = "default";
> >> >> + pinctrl-0 = <&bbcape_nand_flash_pins>;
> >> >This doesn't seem to work as pinctrl properties are not parsed for
> >> >childs of the gpmc node. Did this work for you?
> >> >Putting this in the gpmc node makes it work, but how will we control
> >> >pins for the nand and nor independently? I believe there is currently no
> >> >support for muxing individual gpmc devices. If we want to add both
> >> >devices to the DT and enable them as needed we'd need to add support for
> >> >this, right?
> >> >
> >> Yes, And that should be the case, because different devices would be
> >> connected to different chip-selects, so there should be support of
> >> providing individual pin-mux for different GPMC devices.
> >>
> >> Currently both NAND and NOR cape share GPMC_CS0, so both NAND and NOR
> >> capes will not work simultaneously. But I'm planning to modify NOR cape
> >> hardware at my end to use GPMC_CS1 instead of GPMC_CS0.
> >> - NAND on GPMC_CS0
> >> - NOR on GPMC_CS1
> >
> >Hmm but we should have these working with both using CS0 without
> >any need to modify the hardware though?
> >
> Yes, but one at a time. That mean either of 'NAND cape' or 'NOR cape'.
> If you need both working simultaneously as 2 separate devices attached
> to GPMC, then you need 2 separate chip-selects, which is what I'm trying
> to test with [1].
Right only one enabled at a time, not both enabled at the same time :)
> >In that case we should make sure we always set large enough GPMC
> >partition
> Yes, this is taken care with introduction of NOR cape in
> [PATCH v1 2/3] ARM: dts: am335x-bone: add support for beaglebone NOR cape
> &gpmc {
> - ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
> + ranges = <0 0 0x08000000 0x01000000>; /* address offset=128MB, range=128Mb=16MB */
> This GPMC partition suffices for both NAND and NOR requirements.
OK
> > and that the pins are muxed for the connected GPMC
> >devices only.
> >
> Pin mux is something I need to re-work, because currently
> I've tested either NAND or NOR individually, not together.
>
> Also as mentioned above by Guido, pin-ctrl property is not parsed individually
> for GPMC children, Instead pin-ctrl is set once for GPMC as a whole.
Yes, drivers/base/pinctrl.c should already take care of that though?
> Do you have any suggestions on how pin-ctrl should be set if we have
> multiple devices connected to GPMC like;
> All these devices will share:
> - control lines (gpmc_wait, gpmc_ben_cle, gpmc_advn_ale, gpmc_we, gpmc_oe_ren)
> - *some* data lines (gpmc_ad[])
> - *some* address lines (gpmc_a[])
> - but chip-selects will be different:
> gpmc_cs0: NAND
> gpmc_cs1: NOR
> gpmc_cs2: SMSC91xx
> gpmc_cs3: Camera
Well the pinctrl settings should be done a the child driver level
when it probes so drivers/base/pinctrl.c does what it's supposed
to do.
Regards,
Tony
--
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
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
@ 2014-07-01 13:28 ` Tony Lindgren
0 siblings, 0 replies; 60+ messages in thread
From: Tony Lindgren @ 2014-07-01 13:28 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Jason Kridner, Robert Nelson, linux-omap, linux-mtd, Guido Martínez
* Gupta, Pekon <pekon@ti.com> [140701 02:09]:
> >From: Tony Lindgren [mailto:tony@atomide.com]
> >>* Gupta, Pekon <pekon@ti.com> [140627 14:08]:
> >> >From: Guido Martínez [mailto:guido@vanguardiasur.com.ar]
> >> >>On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
> >>
> >> [...]
> >>
> >> >> +&gpmc {
> >> >> + ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
> >> >> + nand@0,0 {
> >> >> + status = "disabled";
> >> >> + reg = <0 0 4>; /* device IO registers */
> >> >> + pinctrl-names = "default";
> >> >> + pinctrl-0 = <&bbcape_nand_flash_pins>;
> >> >This doesn't seem to work as pinctrl properties are not parsed for
> >> >childs of the gpmc node. Did this work for you?
> >> >Putting this in the gpmc node makes it work, but how will we control
> >> >pins for the nand and nor independently? I believe there is currently no
> >> >support for muxing individual gpmc devices. If we want to add both
> >> >devices to the DT and enable them as needed we'd need to add support for
> >> >this, right?
> >> >
> >> Yes, And that should be the case, because different devices would be
> >> connected to different chip-selects, so there should be support of
> >> providing individual pin-mux for different GPMC devices.
> >>
> >> Currently both NAND and NOR cape share GPMC_CS0, so both NAND and NOR
> >> capes will not work simultaneously. But I'm planning to modify NOR cape
> >> hardware at my end to use GPMC_CS1 instead of GPMC_CS0.
> >> - NAND on GPMC_CS0
> >> - NOR on GPMC_CS1
> >
> >Hmm but we should have these working with both using CS0 without
> >any need to modify the hardware though?
> >
> Yes, but one at a time. That mean either of 'NAND cape' or 'NOR cape'.
> If you need both working simultaneously as 2 separate devices attached
> to GPMC, then you need 2 separate chip-selects, which is what I'm trying
> to test with [1].
Right only one enabled at a time, not both enabled at the same time :)
> >In that case we should make sure we always set large enough GPMC
> >partition
> Yes, this is taken care with introduction of NOR cape in
> [PATCH v1 2/3] ARM: dts: am335x-bone: add support for beaglebone NOR cape
> &gpmc {
> - ranges = <0 0 0 0x01000000>; /* address range = 16MB (minimum GPMC partition) */
> + ranges = <0 0 0x08000000 0x01000000>; /* address offset=128MB, range=128Mb=16MB */
> This GPMC partition suffices for both NAND and NOR requirements.
OK
> > and that the pins are muxed for the connected GPMC
> >devices only.
> >
> Pin mux is something I need to re-work, because currently
> I've tested either NAND or NOR individually, not together.
>
> Also as mentioned above by Guido, pin-ctrl property is not parsed individually
> for GPMC children, Instead pin-ctrl is set once for GPMC as a whole.
Yes, drivers/base/pinctrl.c should already take care of that though?
> Do you have any suggestions on how pin-ctrl should be set if we have
> multiple devices connected to GPMC like;
> All these devices will share:
> - control lines (gpmc_wait, gpmc_ben_cle, gpmc_advn_ale, gpmc_we, gpmc_oe_ren)
> - *some* data lines (gpmc_ad[])
> - *some* address lines (gpmc_a[])
> - but chip-selects will be different:
> gpmc_cs0: NAND
> gpmc_cs1: NOR
> gpmc_cs2: SMSC91xx
> gpmc_cs3: Camera
Well the pinctrl settings should be done a the child driver level
when it probes so drivers/base/pinctrl.c does what it's supposed
to do.
Regards,
Tony
^ permalink raw reply [flat|nested] 60+ messages in thread