* [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; 34+ 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] 34+ 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; 34+ 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] 34+ 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; 34+ 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] 34+ 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; 34+ 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] 34+ 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; 34+ 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] 34+ 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; 34+ messages in thread
From: Gupta, Pekon @ 2014-03-12 18:26 UTC (permalink / raw)
To: Menon, Nishanth, Tony Lindgren, bcousson@baylibre.com
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] 34+ 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; 34+ 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@baylibre.com
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] 34+ 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; 34+ messages in thread
From: Nishanth Menon @ 2014-03-12 18:57 UTC (permalink / raw)
To: Gupta, Pekon; +Cc: Tony Lindgren, bcousson@baylibre.com, 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] 34+ 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; 34+ 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@baylibre.com
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] 34+ 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; 34+ messages in thread
From: Robert Nelson @ 2014-03-12 19:08 UTC (permalink / raw)
To: Nishanth Menon
Cc: Gupta, Pekon, Tony Lindgren, bcousson@baylibre.com, 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] 34+ 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; 34+ 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@baylibre.com
* 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] 34+ 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; 34+ messages in thread
From: Tony Lindgren @ 2014-03-12 19:28 UTC (permalink / raw)
To: Robert Nelson
Cc: Nishanth Menon, Gupta, Pekon, bcousson@baylibre.com, 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] 34+ 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; 34+ 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@baylibre.com
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] 34+ 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; 34+ messages in thread
From: Nishanth Menon @ 2014-03-12 20:51 UTC (permalink / raw)
To: Tony Lindgren, Robert Nelson
Cc: Gupta, Pekon, bcousson@baylibre.com, 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] 34+ 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; 34+ 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@baylibre.com
>-----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] 34+ 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; 34+ messages in thread
From: Gupta, Pekon @ 2014-03-12 21:13 UTC (permalink / raw)
To: Menon, Nishanth, Tony Lindgren, Robert Nelson
Cc: bcousson@baylibre.com, 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] 34+ 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; 34+ 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@baylibre.com
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] 34+ 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; 34+ messages in thread
From: Nishanth Menon @ 2014-03-12 21:53 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Tony Lindgren, Robert Nelson, bcousson@baylibre.com, 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] 34+ 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; 34+ 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@baylibre.com
[...]
> 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] 34+ 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; 34+ messages in thread
From: Gupta, Pekon @ 2014-03-13 6:19 UTC (permalink / raw)
To: Menon, Nishanth, Tony Lindgren
Cc: Robert Nelson, bcousson@baylibre.com, 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] 34+ 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; 34+ 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@baylibre.com
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] 34+ 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; 34+ messages in thread
From: Nishanth Menon @ 2014-03-13 13:03 UTC (permalink / raw)
To: Gupta, Pekon, Tony Lindgren
Cc: Robert Nelson, bcousson@baylibre.com, 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] 34+ 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; 34+ 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@baylibre.com
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] 34+ 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; 34+ messages in thread
From: Robert Nelson @ 2014-03-13 13:30 UTC (permalink / raw)
To: Nishanth Menon
Cc: Gupta, Pekon, Tony Lindgren, bcousson@baylibre.com, 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] 34+ 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; 34+ 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@baylibre.com
* 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] 34+ 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; 34+ messages in thread
From: Tony Lindgren @ 2014-03-13 16:55 UTC (permalink / raw)
To: Robert Nelson
Cc: Nishanth Menon, Gupta, Pekon, bcousson@baylibre.com, 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] 34+ 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; 34+ 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] 34+ 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; 34+ 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] 34+ 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; 34+ 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] 34+ 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; 34+ 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] 34+ 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; 34+ 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] 34+ 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; 34+ 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] 34+ 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; 34+ messages in thread
From: Gupta, Pekon @ 2014-03-12 18:30 UTC (permalink / raw)
To: Menon, Nishanth, Tony Lindgren, bcousson@baylibre.com
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] 34+ messages in thread