* [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-05-19 9:15 [PATCH v7 0/4] add parallel NAND support for TI's new OMAPx and AMxx platforms (Part-2) Pekon Gupta
@ 2014-05-19 9:15 ` Pekon Gupta
2014-05-19 16:25 ` Tony Lindgren
2014-05-19 9:15 ` [PATCH v7 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash Pekon Gupta
` (2 subsequent siblings)
3 siblings, 1 reply; 26+ messages in thread
From: Pekon Gupta @ 2014-05-19 9:15 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, Ezequiel Garcia, Stefan Roese,
Javier Martinez Canillas, Roger Quadros, Pekon Gupta
Beaglebone Board can be connected to expansion boards to add devices to them.
These expansion boards are called 'capes'. This patch adds support for
following versions of Beaglebone(AM335x) NAND capes
(a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64
(b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224
Further information and datasheets can be found at [1] and [2]
* How to boot from NAND using Memory Expander + NAND Cape ? *
- Important: As BOOTSEL values are sampled only at POR, so after changing any
setting on SW2 (DIP switch), disconnect and reconnect all board power supply
(including mini-USB console port) to POR the beaglebone.
- Selection of ECC scheme
for NAND cape(a), ROM code expects BCH8_HW ecc-scheme
for NAND cape(b), ROM code expects BCH16_HW ecc-scheme
- Selection of boot modes can be controlled via DIP switch(SW2) present on
Memory Expander cape, so first boot via MMC or other sources to flash NAND
device and then switch to SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
SW2[SWITCH_BOOT] == OFF follow default boot order MMC-> SPI -> UART -> USB
SW2[SWITCH_BOOT] == ON boot mode selected via DIP switch(SW2)
- For NAND boot following switch settings need to be followed
SW2[ 0] = ON (SYSBOOT[ 0]==0: NAND boot mode selected )
SW2[ 1] = ON (SYSBOOT[ 1]==0: -- do -- )
SW2[ 2] = OFF (SYSBOOT[ 2]==1: -- do -- )
SW2[ 3] = OFF (SYSBOOT[ 3]==1: -- do -- )
SW2[ 4] = ON (SYSBOOT[ 4]==0: -- do -- )
SW2[ 8] = OFF (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
SW2[ 9] = ON (SYSBOOT[ 9]==0: ECC done by ROM )
SW2[10] = ON (SYSBOOT[10]==0: Non Muxed device )
SW2[11] = ON (SYSBOOT[11]==0: -- do -- )
[1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion
[2] http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module
Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
---
arch/arm/boot/dts/am335x-bone-memory-cape.dts | 123 ++++++++++++++++++++++++++
arch/arm/boot/dts/am335x-bone.dts | 1 +
arch/arm/boot/dts/am335x-boneblack.dts | 1 +
3 files changed, 125 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts
diff --git a/arch/arm/boot/dts/am335x-bone-memory-cape.dts b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
new file mode 100644
index 0000000..ce3f87d
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
@@ -0,0 +1,123 @@
+/*
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This DTS adds supports for capes using GPMC interface to connect external
+ * memory like NAND, NOR Flash to Beaglebone-LT (white) and Beaglebone-Black.
+ */
+
+
+&am33xx_pinmux {
+ nand_flash_x16: nand_flash_x16 {
+ pinctrl-single,pins = <
+ 0x00 (MUX_MODE0 | PIN_INPUT) /* gpmc_ad0.gpmc_ad0 */
+ 0x04 (MUX_MODE0 | PIN_INPUT) /* gpmc_ad1.gpmc_ad1 */
+ 0x08 (MUX_MODE0 | PIN_INPUT) /* gpmc_ad2.gpmc_ad2 */
+ 0x0c (MUX_MODE0 | PIN_INPUT) /* gpmc_ad3.gpmc_ad3 */
+ 0x10 (MUX_MODE0 | PIN_INPUT) /* gpmc_ad4.gpmc_ad4 */
+ 0x14 (MUX_MODE0 | PIN_INPUT) /* gpmc_ad5.gpmc_ad5 */
+ 0x18 (MUX_MODE0 | PIN_INPUT) /* gpmc_ad6.gpmc_ad6 */
+ 0x1c (MUX_MODE0 | PIN_INPUT) /* gpmc_ad7.gpmc_ad7 */
+ 0x20 (MUX_MODE0 | PIN_INPUT) /* gpmc_ad8.gpmc_ad8 */
+ 0x24 (MUX_MODE0 | PIN_INPUT) /* gpmc_ad9.gpmc_ad9 */
+ 0x28 (MUX_MODE0 | PIN_INPUT) /* gpmc_ad10.gpmc_ad10 */
+ 0x2c (MUX_MODE0 | PIN_INPUT) /* gpmc_ad11.gpmc_ad11 */
+ 0x30 (MUX_MODE0 | PIN_INPUT) /* gpmc_ad12.gpmc_ad12 */
+ 0x34 (MUX_MODE0 | PIN_INPUT) /* gpmc_ad13.gpmc_ad13 */
+ 0x38 (MUX_MODE0 | PIN_INPUT) /* gpmc_ad14.gpmc_ad14 */
+ 0x3c (MUX_MODE0 | PIN_INPUT) /* gpmc_ad15.gpmc_ad15 */
+ 0x70 (MUX_MODE0 | PIN_INPUT_PULLUP ) /* gpmc_wait0.gpmc_wait0 */
+ 0x74 (MUX_MODE7 | PIN_OUTPUT_PULLUP) /* gpmc_wpn.gpio0_30 */
+ 0x7c (MUX_MODE0 | PIN_OUTPUT_PULLUP) /* gpmc_csn0.gpmc_csn0 */
+ 0x90 (MUX_MODE0 | PIN_OUTPUT) /* gpmc_advn_ale.gpmc_advn_ale */
+ 0x94 (MUX_MODE0 | PIN_OUTPUT) /* gpmc_oen_ren.gpmc_oen_ren */
+ 0x98 (MUX_MODE0 | PIN_OUTPUT) /* gpmc_wen.gpmc_wen */
+ 0x9c (MUX_MODE0 | PIN_OUTPUT) /* gpmc_be0n_cle.gpmc_be0n_cle */
+ >;
+ };
+};
+
+&gpmc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_flash_x16>;
+ ranges = <0 0 0 0x01000000>; /* minimum GPMC partition = 16MB */
+ nand@0,0 {
+ reg = <0 0 4>; /* device IO registers */
+ ti,nand-ecc-opt = "bch8";
+ ti,elm-id = <&elm>;
+ nand-bus-width = <16>;
+ gpmc,device-width = <2>;
+ gpmc,sync-clk-ps = <0>;
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <80>;
+ gpmc,cs-wr-off-ns = <80>;
+ gpmc,adv-on-ns = <0>;
+ gpmc,adv-rd-off-ns = <80>;
+ gpmc,adv-wr-off-ns = <80>;
+ gpmc,we-on-ns = <20>;
+ gpmc,we-off-ns = <60>;
+ gpmc,oe-on-ns = <20>;
+ gpmc,oe-off-ns = <60>;
+ gpmc,access-ns = <40>;
+ gpmc,rd-cycle-ns = <80>;
+ gpmc,wr-cycle-ns = <80>;
+ gpmc,wait-pin = <0>;
+ gpmc,wait-on-read;
+ gpmc,wait-on-write;
+ gpmc,bus-turnaround-ns = <0>;
+ gpmc,cycle2cycle-delay-ns = <0>;
+ gpmc,clk-activation-ns = <0>;
+ gpmc,wait-monitoring-ns = <0>;
+ gpmc,wr-access-ns = <40>;
+ gpmc,wr-data-mux-bus-ns = <0>;
+ /* MTD partition table */
+ /* All SPL-* partitions are sized to minimal length
+ * which can be independently programmable. For
+ * NAND flash this is equal to size of erase-block */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "NAND.SPL";
+ reg = <0x00000000 0x00040000>;
+ };
+ partition@1 {
+ label = "NAND.SPL.backup1";
+ reg = <0x00040000 0x00040000>;
+ };
+ partition@2 {
+ label = "NAND.SPL.backup2";
+ reg = <0x00080000 0x00040000>;
+ };
+ partition@3 {
+ label = "NAND.SPL.backup3";
+ reg = <0x000c0000 0x00040000>;
+ };
+ partition@4 {
+ label = "NAND.u-boot-spl-os";
+ reg = <0x00100000 0x00080000>;
+ };
+ partition@5 {
+ label = "NAND.u-boot";
+ reg = <0x00180000 0x00100000>;
+ };
+ partition@6 {
+ label = "NAND.u-boot-env";
+ reg = <0x00280000 0x00040000>;
+ };
+ partition@7 {
+ label = "NAND.u-boot-env.backup1";
+ reg = <0x002c0000 0x00040000>;
+ };
+ partition@8 {
+ label = "NAND.kernel";
+ reg = <0x00300000 0x00700000>;
+ };
+ partition@9 {
+ label = "NAND.file-system";
+ reg = <0x00a00000 0x1f600000>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index 94ee427..f16bfcf 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -9,6 +9,7 @@
#include "am33xx.dtsi"
#include "am335x-bone-common.dtsi"
+#include "am335x-bone-memory-cape.dts"
&ldo3_reg {
regulator-min-microvolt = <1800000>;
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts
index 6b71ad9..c030b24 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -9,6 +9,7 @@
#include "am33xx.dtsi"
#include "am335x-bone-common.dtsi"
+#include "am335x-bone-memory-cape.dts"
&ldo3_reg {
regulator-min-microvolt = <1800000>;
--
1.8.5.1.163.gd7aced9
^ permalink raw reply related [flat|nested] 26+ messages in thread* Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-05-19 9:15 ` [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape Pekon Gupta
@ 2014-05-19 16:25 ` Tony Lindgren
2014-05-19 17:52 ` Gupta, Pekon
2014-06-23 5:40 ` Gupta, Pekon
0 siblings, 2 replies; 26+ messages in thread
From: Tony Lindgren @ 2014-05-19 16:25 UTC (permalink / raw)
To: Pekon Gupta
Cc: linux-omap, Ezequiel Garcia, Stefan Roese,
Javier Martinez Canillas, Roger Quadros
* Pekon Gupta <pekon@ti.com> [140519 02:16]:
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -9,6 +9,7 @@
>
> #include "am33xx.dtsi"
> #include "am335x-bone-common.dtsi"
> +#include "am335x-bone-memory-cape.dts"
>
> &ldo3_reg {
> regulator-min-microvolt = <1800000>;
> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> @@ -9,6 +9,7 @@
>
> #include "am33xx.dtsi"
> #include "am335x-bone-common.dtsi"
> +#include "am335x-bone-memory-cape.dts"
>
> &ldo3_reg {
> regulator-min-microvolt = <1800000>;
Based on the recent discussions on the capes, it seems that nobody
wants to implement toggling of the capes in u-boot. And as there
can be other capes using GPMC bus, we can't merge this. And because
the capes are stackable, we can't really have .dts files for all
the combinations. And no, we're not merging any unconnected .dts
files either, sorry.
Regards,
Tony
^ permalink raw reply [flat|nested] 26+ messages in thread* RE: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-05-19 16:25 ` Tony Lindgren
@ 2014-05-19 17:52 ` Gupta, Pekon
2014-05-19 18:16 ` Ezequiel Garcia
2014-06-23 5:40 ` Gupta, Pekon
1 sibling, 1 reply; 26+ messages in thread
From: Gupta, Pekon @ 2014-05-19 17:52 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, Ezequiel Garcia, Stefan Roese,
Javier Martinez Canillas, Quadros, Roger
Hi Tony,
>From: Tony Lindgren [mailto:tony@atomide.com]
>
>* Pekon Gupta <pekon@ti.com> [140519 02:16]:
>> --- a/arch/arm/boot/dts/am335x-bone.dts
>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>> @@ -9,6 +9,7 @@
>>
>> #include "am33xx.dtsi"
>> #include "am335x-bone-common.dtsi"
>> +#include "am335x-bone-memory-cape.dts"
>>
>> &ldo3_reg {
>> regulator-min-microvolt = <1800000>;
>> --- a/arch/arm/boot/dts/am335x-boneblack.dts
>> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
>> @@ -9,6 +9,7 @@
>>
>> #include "am33xx.dtsi"
>> #include "am335x-bone-common.dtsi"
>> +#include "am335x-bone-memory-cape.dts"
>>
>> &ldo3_reg {
>> regulator-min-microvolt = <1800000>;
>
>Based on the recent discussions on the capes, it seems that nobody
>wants to implement toggling of the capes in u-boot. And as there
>can be other capes using GPMC bus, we can't merge this. And because
>the capes are stackable, we can't really have .dts files for all
>the combinations. And no, we're not merging any unconnected .dts
>files either, sorry.
>
Yes, I fully understand. This is like death for most of the capes from point
of view of mainline support. But I have submitted this patch just for sake
of completion. And to provide reference if someone wants to locally work
on beaglebone NAND cape.
You may ignore this patch, and take the remaining ones if they are suitable.
with regards, pekon
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-05-19 17:52 ` Gupta, Pekon
@ 2014-05-19 18:16 ` Ezequiel Garcia
2014-05-19 18:22 ` Gupta, Pekon
2014-05-19 18:39 ` Robert Nelson
0 siblings, 2 replies; 26+ messages in thread
From: Ezequiel Garcia @ 2014-05-19 18:16 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Tony Lindgren, linux-omap, Stefan Roese, Javier Martinez Canillas,
Quadros, Roger
On 19 May 05:52 PM, Gupta, Pekon wrote:
> Hi Tony,
>
> >From: Tony Lindgren [mailto:tony@atomide.com]
> >
> >* Pekon Gupta <pekon@ti.com> [140519 02:16]:
> >> --- a/arch/arm/boot/dts/am335x-bone.dts
> >> +++ b/arch/arm/boot/dts/am335x-bone.dts
> >> @@ -9,6 +9,7 @@
> >>
> >> #include "am33xx.dtsi"
> >> #include "am335x-bone-common.dtsi"
> >> +#include "am335x-bone-memory-cape.dts"
> >>
> >> &ldo3_reg {
> >> regulator-min-microvolt = <1800000>;
> >> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> >> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> >> @@ -9,6 +9,7 @@
> >>
> >> #include "am33xx.dtsi"
> >> #include "am335x-bone-common.dtsi"
> >> +#include "am335x-bone-memory-cape.dts"
> >>
> >> &ldo3_reg {
> >> regulator-min-microvolt = <1800000>;
> >
> >Based on the recent discussions on the capes, it seems that nobody
> >wants to implement toggling of the capes in u-boot. And as there
> >can be other capes using GPMC bus, we can't merge this. And because
> >the capes are stackable, we can't really have .dts files for all
> >the combinations. And no, we're not merging any unconnected .dts
> >files either, sorry.
> >
> Yes, I fully understand. This is like death for most of the capes from point
> of view of mainline support. But I have submitted this patch just for sake
> of completion. And to provide reference if someone wants to locally work
> on beaglebone NAND cape.
While I fully agree with Tony on this, I think the reference is much
appreciated. Do you think you can push the NAND cape DT example somewhere?
Maybe some TI wiki page?
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 26+ messages in thread* RE: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-05-19 18:16 ` Ezequiel Garcia
@ 2014-05-19 18:22 ` Gupta, Pekon
2014-05-19 18:39 ` Robert Nelson
1 sibling, 0 replies; 26+ messages in thread
From: Gupta, Pekon @ 2014-05-19 18:22 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Tony Lindgren, linux-omap, Stefan Roese, Javier Martinez Canillas,
Quadros, Roger
From: Ezequiel Garcia [mailto:ezequiel.garcia@free-electrons.com]
>On 19 May 05:52 PM, Gupta, Pekon wrote:
>> >From: Tony Lindgren [mailto:tony@atomide.com]
>> >Based on the recent discussions on the capes, it seems that nobody
>> >wants to implement toggling of the capes in u-boot. And as there
>> >can be other capes using GPMC bus, we can't merge this. And because
>> >the capes are stackable, we can't really have .dts files for all
>> >the combinations. And no, we're not merging any unconnected .dts
>> >files either, sorry.
>> >
>> Yes, I fully understand. This is like death for most of the capes from point
>> of view of mainline support. But I have submitted this patch just for sake
>> of completion. And to provide reference if someone wants to locally work
>> on beaglebone NAND cape.
>
>While I fully agree with Tony on this, I think the reference is much
>appreciated. Do you think you can push the NAND cape DT example somewhere?
>
>Maybe some TI wiki page?
Yes, that's my intent. I usually keep updating following TI wiki pages [1] and [2]
which I think are helpful for NAND users on OMAP platforms.
[1] https://processors.wiki.ti.com/index.php/Linux_Core_NAND_User%27s_Guide#Board_specific_configurations
[2] https://processors.wiki.ti.com/index.php/Linux_Core_NAND_User%27s_Guide
with regards, pekon
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-05-19 18:16 ` Ezequiel Garcia
2014-05-19 18:22 ` Gupta, Pekon
@ 2014-05-19 18:39 ` Robert Nelson
2014-05-19 18:51 ` Gupta, Pekon
1 sibling, 1 reply; 26+ messages in thread
From: Robert Nelson @ 2014-05-19 18:39 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: Gupta, Pekon, Tony Lindgren, linux-omap, Stefan Roese,
Javier Martinez Canillas, Quadros, Roger, Jason Kridner
On Mon, May 19, 2014 at 1:16 PM, Ezequiel Garcia
<ezequiel.garcia@free-electrons.com> wrote:
> On 19 May 05:52 PM, Gupta, Pekon wrote:
>> Hi Tony,
>>
>> >From: Tony Lindgren [mailto:tony@atomide.com]
>> >
>> >* Pekon Gupta <pekon@ti.com> [140519 02:16]:
>> >> --- a/arch/arm/boot/dts/am335x-bone.dts
>> >> +++ b/arch/arm/boot/dts/am335x-bone.dts
>> >> @@ -9,6 +9,7 @@
>> >>
>> >> #include "am33xx.dtsi"
>> >> #include "am335x-bone-common.dtsi"
>> >> +#include "am335x-bone-memory-cape.dts"
>> >>
>> >> &ldo3_reg {
>> >> regulator-min-microvolt = <1800000>;
>> >> --- a/arch/arm/boot/dts/am335x-boneblack.dts
>> >> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
>> >> @@ -9,6 +9,7 @@
>> >>
>> >> #include "am33xx.dtsi"
>> >> #include "am335x-bone-common.dtsi"
>> >> +#include "am335x-bone-memory-cape.dts"
>> >>
>> >> &ldo3_reg {
>> >> regulator-min-microvolt = <1800000>;
>> >
>> >Based on the recent discussions on the capes, it seems that nobody
>> >wants to implement toggling of the capes in u-boot. And as there
>> >can be other capes using GPMC bus, we can't merge this. And because
>> >the capes are stackable, we can't really have .dts files for all
>> >the combinations. And no, we're not merging any unconnected .dts
>> >files either, sorry.
>> >
>> Yes, I fully understand. This is like death for most of the capes from point
>> of view of mainline support. But I have submitted this patch just for sake
>> of completion. And to provide reference if someone wants to locally work
>> on beaglebone NAND cape.
>
> While I fully agree with Tony on this, I think the reference is much
> appreciated. Do you think you can push the NAND cape DT example somewhere?
>
> Maybe some TI wiki page?
(resent in text mode for linux-omap list archive)
Since the capes are always some way tied with bb.org hardware, why
don't we put them up on https://github.com/beagleboard/ ?
am335x-capes.git ?
I envision, we should just mirror the base ./arch/arm/boot/dts/
directory (as someday the dts will be external anyways). In that repo,
we will keep these synced with mainline
am335x-bone-common.dtsi
am335x-bone.dts
am335x-boneblack.dts
and add the capes as:
<baseboard>-<cape>.dts
as a staging ground till a mainline overlay/etc system appears?
Thoughs?
--
Robert Nelson
http://www.rcn-ee.com/
^ permalink raw reply [flat|nested] 26+ messages in thread* RE: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-05-19 18:39 ` Robert Nelson
@ 2014-05-19 18:51 ` Gupta, Pekon
2014-05-19 18:58 ` Robert Nelson
0 siblings, 1 reply; 26+ messages in thread
From: Gupta, Pekon @ 2014-05-19 18:51 UTC (permalink / raw)
To: Robert Nelson, Ezequiel Garcia
Cc: Tony Lindgren, linux-omap, Stefan Roese, Javier Martinez Canillas,
Quadros, Roger, Kridner, Jason
>From: Robert Nelson [mailto:robertcnelson@gmail.com]
[...]
>Since the capes are always some way tied with bb.org hardware, why
>don't we put them up on https://github.com/beagleboard/ ?
>
>am335x-capes.git ?
>
>I envision, we should just mirror the base ./arch/arm/boot/dts/
>directory (as someday the dts will be external anyways). In that repo,
>we will keep these synced with mainline
>
>am335x-bone-common.dtsi
>am335x-bone.dts
>am335x-boneblack.dts
>
>and add the capes as:
>
><baseboard>-<cape>.dts
>
>as a staging ground till a mainline overlay/etc system appears?
>
>Thoughs?
>
If you know and can convince 'Gerald Coley' then plz try. I failed :-)
with regards, pekon
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-05-19 18:51 ` Gupta, Pekon
@ 2014-05-19 18:58 ` Robert Nelson
[not found] ` <DAEAC432-DB0E-4C30-9B85-71D8987FBF77@ti.com>
0 siblings, 1 reply; 26+ messages in thread
From: Robert Nelson @ 2014-05-19 18:58 UTC (permalink / raw)
To: Gupta, Pekon
Cc: Ezequiel Garcia, Tony Lindgren, linux-omap, Stefan Roese,
Javier Martinez Canillas, Quadros, Roger, Kridner, Jason
On Mon, May 19, 2014 at 1:51 PM, Gupta, Pekon <pekon@ti.com> wrote:
>>From: Robert Nelson [mailto:robertcnelson@gmail.com]
> [...]
>>Since the capes are always some way tied with bb.org hardware, why
>>don't we put them up on https://github.com/beagleboard/ ?
>>
>>am335x-capes.git ?
>>
>>I envision, we should just mirror the base ./arch/arm/boot/dts/
>>directory (as someday the dts will be external anyways). In that repo,
>>we will keep these synced with mainline
>>
>>am335x-bone-common.dtsi
>>am335x-bone.dts
>>am335x-boneblack.dts
>>
>>and add the capes as:
>>
>><baseboard>-<cape>.dts
>>
>>as a staging ground till a mainline overlay/etc system appears?
>>
>>Thoughs?
>>
>
> If you know and can convince 'Gerald Coley' then plz try. I failed :-)
Oh, I'll do it... ;)
I just need Jason to create the intial "repo" for me on
github.com/beagleboard and enable my permission for it.
Then i'll just pull in the capes in that repo and push it to my
"--beta-kernel" option for users running the new debian image who
would like run mainline over the old v3.8.x
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-05-19 16:25 ` Tony Lindgren
2014-05-19 17:52 ` Gupta, Pekon
@ 2014-06-23 5:40 ` Gupta, Pekon
2014-06-23 5:48 ` Tony Lindgren
1 sibling, 1 reply; 26+ messages in thread
From: Gupta, Pekon @ 2014-06-23 5:40 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, Ezequiel Garcia, Stefan Roese,
Javier Martinez Canillas, Quadros, Roger,
Jason Kridner (jkridner@gmail.com),
Robert Nelson (robertcnelson@gmail.com)
Hi Tony,
Just reviving this thread for some information..
>From: Tony Lindgren [mailto:tony@atomide.com]
>Sent: Monday, May 19, 2014 9:56 PM
>To: Gupta, Pekon
>Cc: linux-omap; Ezequiel Garcia; Stefan Roese; Javier Martinez Canillas; Quadros, Roger
>Subject: Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
>
>* Pekon Gupta <pekon@ti.com> [140519 02:16]:
>> --- a/arch/arm/boot/dts/am335x-bone.dts
>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>> @@ -9,6 +9,7 @@
>>
>> #include "am33xx.dtsi"
>> #include "am335x-bone-common.dtsi"
>> +#include "am335x-bone-memory-cape.dts"
>>
>> &ldo3_reg {
>> regulator-min-microvolt = <1800000>;
>> --- a/arch/arm/boot/dts/am335x-boneblack.dts
>> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
>> @@ -9,6 +9,7 @@
>>
>> #include "am33xx.dtsi"
>> #include "am335x-bone-common.dtsi"
>> +#include "am335x-bone-memory-cape.dts"
>>
>> &ldo3_reg {
>> regulator-min-microvolt = <1800000>;
>
>Based on the recent discussions on the capes, it seems that nobody
>wants to implement toggling of the capes in u-boot. And as there
>can be other capes using GPMC bus, we can't merge this.
I have been able to get toggling of capes (enabling and disabling of DT nodes)
in u-boot. It was already there in u-boot mainline [1], may be no-body tried it.
Example: Below sequence works for NAND cape patch mentioned in this thread.
---------------
/* load DTB */
u-boot> tftp 0x81000000 am335x-boneblack.dtb
u-boot> fdt addr 0x81000000
/* disable MMC2 node */
u-boot> fdt list /ocp/mmc@481d8000
u-boot> fdt set /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
u-boot> fdt list /ocp/mmc@481d8000 status
/* enable GPMC node */
u-boot> fdt list /ocp/gpmc
u-boot> fdt set /ocp/gpmc status \o\k\a\y
u-boot> fdt list /ocp/gpmc status
/* enable ELM node */
u-boot> fdt list /ocp/elm
u-boot> fdt set /ocp/elm status \o\k\a\y
u-boot> fdt list /ocp/elm status
/* boot uImage */
tftp 0x82000000 uImage
bootm 0x82000000 - 0x81000000
Note: "fdt set" command does not accept string literals
as binding values, it internally converts them to string, so
escape sequenced characters were used here..
"okay" == \o\k\a\y
"disabled" == \d\i\s\a\b\l\e\d"
---------------
> And because
>the capes are stackable, we can't really have .dts files for all
>the combinations. And no, we're not merging any unconnected .dts
>files either, sorry.
>
As per earlier proposal, we can have single DT files for similar
functionality capes like;
- am335x-bone-memory-cape.dts: for all Flash/Memory related capes like NAND, NOR, eMMC, etc.
- am335x-bone-display-cape.dts: for all display related capes like LCD4, LCD7..
This way you will have countable number of DTS files to maintain
And any conflict if ever in between capes can be contained within these files.
Does this suffice the requirement to accept cape DTS in mainline
(with default state as disabled) ?
I'm re-invoking this thread because there are quite a number of
hobbyist and developers stuck without proper DT support of these
capes, so having them in mainline is better than providing a internal
or separately maintained tree.
>Regards,
>
>Tony
with regards, pekon
[1] http://www.denx.de/wiki/view/DULG/UBootCmdFDT
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-23 5:40 ` Gupta, Pekon
@ 2014-06-23 5:48 ` Tony Lindgren
2014-06-23 6:13 ` Jason Kridner
0 siblings, 1 reply; 26+ messages in thread
From: Tony Lindgren @ 2014-06-23 5:48 UTC (permalink / raw)
To: Gupta, Pekon
Cc: linux-omap, Ezequiel Garcia, Stefan Roese,
Javier Martinez Canillas, Quadros, Roger,
Jason Kridner (jkridner@gmail.com),
Robert Nelson (robertcnelson@gmail.com)
* Gupta, Pekon <pekon@ti.com> [140622 22:42]:
> Hi Tony,
>
> Just reviving this thread for some information..
>
> >From: Tony Lindgren [mailto:tony@atomide.com]
> >Sent: Monday, May 19, 2014 9:56 PM
> >To: Gupta, Pekon
> >Cc: linux-omap; Ezequiel Garcia; Stefan Roese; Javier Martinez Canillas; Quadros, Roger
> >Subject: Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
> >
> >* Pekon Gupta <pekon@ti.com> [140519 02:16]:
> >> --- a/arch/arm/boot/dts/am335x-bone.dts
> >> +++ b/arch/arm/boot/dts/am335x-bone.dts
> >> @@ -9,6 +9,7 @@
> >>
> >> #include "am33xx.dtsi"
> >> #include "am335x-bone-common.dtsi"
> >> +#include "am335x-bone-memory-cape.dts"
> >>
> >> &ldo3_reg {
> >> regulator-min-microvolt = <1800000>;
> >> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> >> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> >> @@ -9,6 +9,7 @@
> >>
> >> #include "am33xx.dtsi"
> >> #include "am335x-bone-common.dtsi"
> >> +#include "am335x-bone-memory-cape.dts"
> >>
> >> &ldo3_reg {
> >> regulator-min-microvolt = <1800000>;
> >
> >Based on the recent discussions on the capes, it seems that nobody
> >wants to implement toggling of the capes in u-boot. And as there
> >can be other capes using GPMC bus, we can't merge this.
>
> I have been able to get toggling of capes (enabling and disabling of DT nodes)
> in u-boot. It was already there in u-boot mainline [1], may be no-body tried it.
>
> Example: Below sequence works for NAND cape patch mentioned in this thread.
> ---------------
> /* load DTB */
> u-boot> tftp 0x81000000 am335x-boneblack.dtb
> u-boot> fdt addr 0x81000000
> /* disable MMC2 node */
> u-boot> fdt list /ocp/mmc@481d8000
> u-boot> fdt set /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
> u-boot> fdt list /ocp/mmc@481d8000 status
> /* enable GPMC node */
> u-boot> fdt list /ocp/gpmc
> u-boot> fdt set /ocp/gpmc status \o\k\a\y
> u-boot> fdt list /ocp/gpmc status
> /* enable ELM node */
> u-boot> fdt list /ocp/elm
> u-boot> fdt set /ocp/elm status \o\k\a\y
> u-boot> fdt list /ocp/elm status
> /* boot uImage */
> tftp 0x82000000 uImage
> bootm 0x82000000 - 0x81000000
>
> Note: "fdt set" command does not accept string literals
> as binding values, it internally converts them to string, so
> escape sequenced characters were used here..
> "okay" == \o\k\a\y
> "disabled" == \d\i\s\a\b\l\e\d"
Cool. Now all we need is a few helper functions in u-boot
so it can be done a bit easier :)
Regards,
Tony
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-23 5:48 ` Tony Lindgren
@ 2014-06-23 6:13 ` Jason Kridner
2014-06-24 8:03 ` Gupta, Pekon
0 siblings, 1 reply; 26+ messages in thread
From: Jason Kridner @ 2014-06-23 6:13 UTC (permalink / raw)
To: Tony Lindgren
Cc: Gupta, Pekon, linux-omap, Ezequiel Garcia, Stefan Roese,
Javier Martinez Canillas, Quadros, Roger,
Robert Nelson (robertcnelson@gmail.com)
On Mon, Jun 23, 2014 at 1:48 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Gupta, Pekon <pekon@ti.com> [140622 22:42]:
>> Hi Tony,
>>
>> Just reviving this thread for some information..
>>
>> >From: Tony Lindgren [mailto:tony@atomide.com]
>> >Sent: Monday, May 19, 2014 9:56 PM
>> >To: Gupta, Pekon
>> >Cc: linux-omap; Ezequiel Garcia; Stefan Roese; Javier Martinez Canillas; Quadros, Roger
>> >Subject: Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
>> >
>> >* Pekon Gupta <pekon@ti.com> [140519 02:16]:
>> >> --- a/arch/arm/boot/dts/am335x-bone.dts
>> >> +++ b/arch/arm/boot/dts/am335x-bone.dts
>> >> @@ -9,6 +9,7 @@
>> >>
>> >> #include "am33xx.dtsi"
>> >> #include "am335x-bone-common.dtsi"
>> >> +#include "am335x-bone-memory-cape.dts"
>> >>
>> >> &ldo3_reg {
>> >> regulator-min-microvolt = <1800000>;
>> >> --- a/arch/arm/boot/dts/am335x-boneblack.dts
>> >> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
>> >> @@ -9,6 +9,7 @@
>> >>
>> >> #include "am33xx.dtsi"
>> >> #include "am335x-bone-common.dtsi"
>> >> +#include "am335x-bone-memory-cape.dts"
>> >>
>> >> &ldo3_reg {
>> >> regulator-min-microvolt = <1800000>;
>> >
>> >Based on the recent discussions on the capes, it seems that nobody
>> >wants to implement toggling of the capes in u-boot. And as there
>> >can be other capes using GPMC bus, we can't merge this.
>>
>> I have been able to get toggling of capes (enabling and disabling of DT nodes)
>> in u-boot. It was already there in u-boot mainline [1], may be no-body tried it.
>>
>> Example: Below sequence works for NAND cape patch mentioned in this thread.
>> ---------------
>> /* load DTB */
>> u-boot> tftp 0x81000000 am335x-boneblack.dtb
>> u-boot> fdt addr 0x81000000
>> /* disable MMC2 node */
>> u-boot> fdt list /ocp/mmc@481d8000
>> u-boot> fdt set /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
>> u-boot> fdt list /ocp/mmc@481d8000 status
>> /* enable GPMC node */
>> u-boot> fdt list /ocp/gpmc
>> u-boot> fdt set /ocp/gpmc status \o\k\a\y
>> u-boot> fdt list /ocp/gpmc status
>> /* enable ELM node */
>> u-boot> fdt list /ocp/elm
>> u-boot> fdt set /ocp/elm status \o\k\a\y
>> u-boot> fdt list /ocp/elm status
>> /* boot uImage */
>> tftp 0x82000000 uImage
>> bootm 0x82000000 - 0x81000000
>>
>> Note: "fdt set" command does not accept string literals
>> as binding values, it internally converts them to string, so
>> escape sequenced characters were used here..
>> "okay" == \o\k\a\y
>> "disabled" == \d\i\s\a\b\l\e\d"
>
> Cool. Now all we need is a few helper functions in u-boot
> so it can be done a bit easier :)
>
The association of devicetree overlay files in /lib/firmware to cape
IDs made it where the kernel-based cape overlay manager could modify
the devicetree as needed without putting extensive cape-specific logic
in the kernel or bootloader. Throwing a bunch of capes into a single
class of capes won't save any work there. If we can get the bootloader
to support the .dtbo files, then we can continue to use the ID in the
cape to provide all the DT modifications we need. If we need to do
scripts for the modifications, we'd still need to associate the cape
ID to that script.
This still doesn't cover the need for run-time devicetree
modification, but I'll leave that for the other on-going thread.
I do agree with the idea of moving more of the potential sources of
conflict that can be resolved out of the overlays and into the main
devicetree, leaving the overlays or scripts simply to deal with the
conflicts that cannot be resolved at run-time given the current
infrastructure. I just think they should go into .dtsi (include) files
for the main .dts/.dtb files for the boards, rather than additional
overlays or alternative .dts files.
^ permalink raw reply [flat|nested] 26+ messages in thread* RE: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
2014-06-23 6:13 ` Jason Kridner
@ 2014-06-24 8:03 ` Gupta, Pekon
0 siblings, 0 replies; 26+ messages in thread
From: Gupta, Pekon @ 2014-06-24 8:03 UTC (permalink / raw)
To: Jason Kridner, Tony Lindgren
Cc: linux-omap, Ezequiel Garcia, Stefan Roese,
Javier Martinez Canillas, Quadros, Roger,
Robert Nelson (robertcnelson@gmail.com)
>From: Jason Kridner [mailto:jkridner@gmail.com]
>>On Mon, Jun 23, 2014 at 1:48 AM, Tony Lindgren <tony@atomide.com> wrote:
>>> * Gupta, Pekon <pekon@ti.com> [140622 22:42]:
>>> >From: Tony Lindgren [mailto:tony@atomide.com]
[...]
>>> >Based on the recent discussions on the capes, it seems that nobody
>>> >wants to implement toggling of the capes in u-boot. And as there
>>> >can be other capes using GPMC bus, we can't merge this.
>>>
>>> I have been able to get toggling of capes (enabling and disabling of DT nodes)
>>> in u-boot. It was already there in u-boot mainline [1], may be no-body tried it.
>>>
>>> Example: Below sequence works for NAND cape patch mentioned in this thread.
>>> ---------------
>>> /* load DTB */
>>> u-boot> tftp 0x81000000 am335x-boneblack.dtb
>>> u-boot> fdt addr 0x81000000
>>> /* disable MMC2 node */
>>> u-boot> fdt list /ocp/mmc@481d8000
>>> u-boot> fdt set /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
>>> u-boot> fdt list /ocp/mmc@481d8000 status
>>> /* enable GPMC node */
>>> u-boot> fdt list /ocp/gpmc
>>> u-boot> fdt set /ocp/gpmc status \o\k\a\y
>>> u-boot> fdt list /ocp/gpmc status
>>> /* enable ELM node */
>>> u-boot> fdt list /ocp/elm
>>> u-boot> fdt set /ocp/elm status \o\k\a\y
>>> u-boot> fdt list /ocp/elm status
>>> /* boot uImage */
>>> tftp 0x82000000 uImage
>>> bootm 0x82000000 - 0x81000000
>>>
>>> Note: "fdt set" command does not accept string literals
>>> as binding values, it internally converts them to string, so
>>> escape sequenced characters were used here..
>>> "okay" == \o\k\a\y
>>> "disabled" == \d\i\s\a\b\l\e\d"
>>
>> Cool. Now all we need is a few helper functions in u-boot
>> so it can be done a bit easier :)
>>
>
>The association of devicetree overlay files in /lib/firmware to cape
>IDs made it where the kernel-based cape overlay manager could modify
>the devicetree as needed without putting extensive cape-specific logic
>in the kernel or bootloader. Throwing a bunch of capes into a single
>class of capes won't save any work there.
>
I'm classifying capes based on functionality to reduce the number of
DTS files, because in general people will not both LCD4 and LCD7 capes
together, similarly not many will use NAND, NOR and eMMC simulataneously.
- am335x-bone-memory-cape.dts: will have NAND, NOR and storage related capes
- am335x-bone-display-cape.dts: will have LCD4, LCD7, ... etc capes.
> If we can get the bootloader
>to support the .dtbo files, then we can continue to use the ID in the
>cape to provide all the DT modifications we need. If we need to do
>scripts for the modifications, we'd still need to associate the cape
>ID to that script.
>
With ID based auto-identification of Capes, we need EEPROM or
e-fuses on every cape. And today I don't think all third-party capes
have EEPROM on them.
Also, with increase in number of cape, it will be hard to maintain
ID grouping and updating firmware/software for each new cape.
>
>This still doesn't cover the need for run-time devicetree
>modification, but I'll leave that for the other on-going thread.
>
I'm just proposing the u-boot way of enabling/disabling DT.
This is certainly not replacing requirement for DT overlay manager,
But till the time DT overlay is available in kernel, this would at-least
be an placeholder and would encourage Beaglebone users to
continue using mainline kernel.
This why I'm trying to get basic cape DTS in mainline, so that
Beaglebone community continues to be in touch with mainline.
Tomorrow if DT overlay comes, then we may choose to either keep
these cape DTS, or delete them from mainline without breaking any
backward compatibility.
>I do agree with the idea of moving more of the potential sources of
>conflict that can be resolved out of the overlays and into the main
>devicetree, leaving the overlays or scripts simply to deal with the
>conflicts that cannot be resolved at run-time given the current
>infrastructure. I just think they should go into .dtsi (include) files
>for the main .dts/.dtb files for the boards, rather than additional
>overlays or alternative .dts files.
>
Yes, that is the main motive, to resolve _known_ conflicts before
Run-time. And keep things working till 'DT overlay' is mainlined.
Another thing which I'm not sure is how DT overlay will work
with capes which are required during boot?
Example: NAND, NOR capes themselves containing file-system.
I think in such scenarios using u-boot approach for enabling/disabling
capes would be beneficial.
If you and others are okay with this approach, I would request you
to please provide your "Tested-by" for few cape DTS patches I
will be posting soon. This would give confidence that cape DTS
patches are not breaking anything in existing DTS.
Thanks..
with regards, pekon
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH v7 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
2014-05-19 9:15 [PATCH v7 0/4] add parallel NAND support for TI's new OMAPx and AMxx platforms (Part-2) Pekon Gupta
2014-05-19 9:15 ` [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape Pekon Gupta
@ 2014-05-19 9:15 ` Pekon Gupta
2014-05-19 22:06 ` Tony Lindgren
2014-05-19 9:15 ` [PATCH v7 3/4] ARM: dts: dra7: " Pekon Gupta
2014-05-19 9:15 ` [PATCH v7 4/4] ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition Pekon Gupta
3 siblings, 1 reply; 26+ messages in thread
From: Pekon Gupta @ 2014-05-19 9:15 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, Ezequiel Garcia, Stefan Roese,
Javier Martinez Canillas, Roger Quadros, Pekon Gupta
Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
am437x-gp-evm board.
(1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled:
(a) By dynamically driving following GPIO pin from software
SPI2_CS0(GPIO) == 0 NAND is selected (default)
SPI2_CS0(GPIO) == 1 eMMC is selected
(b) By statically using Jumper (J89) on the board
(2) As NAND device connnected to this board has page-size=4K and oob-size=224,
So ROM code expects boot-loaders to be flashed in BCH16 ECC scheme for
NAND boot.
Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
---
arch/arm/boot/dts/am437x-gp-evm.dts | 108 ++++++++++++++++++++++++++++++++++++
1 file changed, 108 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
index 30ace1b..f432685 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -150,6 +150,27 @@
0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
>;
};
+
+ nand_flash_x8: nand_flash_x8 {
+ pinctrl-single,pins = <
+ 0x26c(PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* spi2_cs0.gpio/eMMCorNANDsel */
+ 0x0 (PIN_INPUT | MUX_MODE0) /* gpmc_ad0.gpmc_ad0 */
+ 0x4 (PIN_INPUT | MUX_MODE0) /* gpmc_ad1.gpmc_ad1 */
+ 0x8 (PIN_INPUT | MUX_MODE0) /* gpmc_ad2.gpmc_ad2 */
+ 0xc (PIN_INPUT | MUX_MODE0) /* gpmc_ad3.gpmc_ad3 */
+ 0x10 (PIN_INPUT | MUX_MODE0) /* gpmc_ad4.gpmc_ad4 */
+ 0x14 (PIN_INPUT | MUX_MODE0) /* gpmc_ad5.gpmc_ad5 */
+ 0x18 (PIN_INPUT | MUX_MODE0) /* gpmc_ad6.gpmc_ad6 */
+ 0x1c (PIN_INPUT | MUX_MODE0) /* gpmc_ad7.gpmc_ad7 */
+ 0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_wait0.gpmc_wait0 */
+ 0x74 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* gpmc_wpn.gpmc_wpn */
+ 0x7c (PIN_OUTPUT | MUX_MODE0) /* gpmc_csn0.gpmc_csn0 */
+ 0x90 (PIN_OUTPUT | MUX_MODE0) /* gpmc_advn_ale.gpmc_advn_ale */
+ 0x94 (PIN_OUTPUT | MUX_MODE0) /* gpmc_oen_ren.gpmc_oen_ren */
+ 0x98 (PIN_OUTPUT | MUX_MODE0) /* gpmc_wen.gpmc_wen */
+ 0x9c (PIN_OUTPUT | MUX_MODE0) /* gpmc_be0n_cle.gpmc_be0n_cle */
+ >;
+ };
};
&i2c0 {
@@ -246,3 +267,90 @@
phy_id = <&davinci_mdio>, <0>;
phy-mode = "rgmii";
};
+
+&elm {
+ status = "okay";
+};
+
+&gpmc {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_flash_x8>;
+ ranges = <0 0 0 0x01000000>; /* minimum GPMC partition = 16MB */
+ nand@0,0 {
+ reg = <0 0 4>; /* device IO registers */
+ ti,nand-ecc-opt = "bch8";
+ ti,elm-id = <&elm>;
+ nand-bus-width = <8>;
+ gpmc,device-width = <1>;
+ gpmc,sync-clk-ps = <0>;
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <40>;
+ gpmc,cs-wr-off-ns = <40>;
+ gpmc,adv-on-ns = <0>;
+ gpmc,adv-rd-off-ns = <25>;
+ gpmc,adv-wr-off-ns = <25>;
+ gpmc,we-on-ns = <0>;
+ gpmc,we-off-ns = <20>;
+ gpmc,oe-on-ns = <3>;
+ gpmc,oe-off-ns = <30>;
+ gpmc,access-ns = <30>;
+ gpmc,rd-cycle-ns = <40>;
+ gpmc,wr-cycle-ns = <40>;
+ gpmc,wait-pin = <0>;
+ gpmc,wait-on-read;
+ gpmc,wait-on-write;
+ gpmc,bus-turnaround-ns = <0>;
+ gpmc,cycle2cycle-delay-ns = <0>;
+ gpmc,clk-activation-ns = <0>;
+ gpmc,wait-monitoring-ns = <0>;
+ gpmc,wr-access-ns = <40>;
+ gpmc,wr-data-mux-bus-ns = <0>;
+ /* MTD partition table */
+ /* All SPL-* partitions are sized to minimal length
+ * which can be independently programmable. For
+ * NAND flash this is equal to size of erase-block */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "NAND.SPL";
+ reg = <0x00000000 0x00040000>;
+ };
+ partition@1 {
+ label = "NAND.SPL.backup1";
+ reg = <0x00040000 0x00040000>;
+ };
+ partition@2 {
+ label = "NAND.SPL.backup2";
+ reg = <0x00080000 0x00040000>;
+ };
+ partition@3 {
+ label = "NAND.SPL.backup3";
+ reg = <0x000c0000 0x00040000>;
+ };
+ partition@4 {
+ label = "NAND.u-boot-spl-os";
+ reg = <0x00100000 0x00080000>;
+ };
+ partition@5 {
+ label = "NAND.u-boot";
+ reg = <0x00180000 0x00100000>;
+ };
+ partition@6 {
+ label = "NAND.u-boot-env";
+ reg = <0x00280000 0x00040000>;
+ };
+ partition@7 {
+ label = "NAND.u-boot-env.backup1";
+ reg = <0x002c0000 0x00040000>;
+ };
+ partition@8 {
+ label = "NAND.kernel";
+ reg = <0x00300000 0x00700000>;
+ };
+ partition@9 {
+ label = "NAND.file-system";
+ reg = <0x00a00000 0x1f600000>;
+ };
+ };
+};
--
1.8.5.1.163.gd7aced9
^ permalink raw reply related [flat|nested] 26+ messages in thread* Re: [PATCH v7 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
2014-05-19 9:15 ` [PATCH v7 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash Pekon Gupta
@ 2014-05-19 22:06 ` Tony Lindgren
2014-05-20 4:06 ` Gupta, Pekon
0 siblings, 1 reply; 26+ messages in thread
From: Tony Lindgren @ 2014-05-19 22:06 UTC (permalink / raw)
To: Pekon Gupta
Cc: linux-omap, Ezequiel Garcia, Stefan Roese,
Javier Martinez Canillas, Roger Quadros
* Pekon Gupta <pekon@ti.com> [140519 02:16]:
> Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
> am437x-gp-evm board.
> (1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
> eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled:
> (a) By dynamically driving following GPIO pin from software
> SPI2_CS0(GPIO) == 0 NAND is selected (default)
> SPI2_CS0(GPIO) == 1 eMMC is selected
> (b) By statically using Jumper (J89) on the board
So which MMC controller has eMMC then? How do we select which one we
have enabled in the am437x-gp-evm.dts by default?
Regards,
Tony
> (2) As NAND device connnected to this board has page-size=4K and oob-size=224,
> So ROM code expects boot-loaders to be flashed in BCH16 ECC scheme for
> NAND boot.
>
> Signed-off-by: Pekon Gupta <pekon@ti.com>
> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
> ---
> arch/arm/boot/dts/am437x-gp-evm.dts | 108 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 108 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
> index 30ace1b..f432685 100644
> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
> @@ -150,6 +150,27 @@
> 0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
> >;
> };
> +
> + nand_flash_x8: nand_flash_x8 {
> + pinctrl-single,pins = <
> + 0x26c(PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* spi2_cs0.gpio/eMMCorNANDsel */
> + 0x0 (PIN_INPUT | MUX_MODE0) /* gpmc_ad0.gpmc_ad0 */
> + 0x4 (PIN_INPUT | MUX_MODE0) /* gpmc_ad1.gpmc_ad1 */
> + 0x8 (PIN_INPUT | MUX_MODE0) /* gpmc_ad2.gpmc_ad2 */
> + 0xc (PIN_INPUT | MUX_MODE0) /* gpmc_ad3.gpmc_ad3 */
> + 0x10 (PIN_INPUT | MUX_MODE0) /* gpmc_ad4.gpmc_ad4 */
> + 0x14 (PIN_INPUT | MUX_MODE0) /* gpmc_ad5.gpmc_ad5 */
> + 0x18 (PIN_INPUT | MUX_MODE0) /* gpmc_ad6.gpmc_ad6 */
> + 0x1c (PIN_INPUT | MUX_MODE0) /* gpmc_ad7.gpmc_ad7 */
> + 0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_wait0.gpmc_wait0 */
> + 0x74 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* gpmc_wpn.gpmc_wpn */
> + 0x7c (PIN_OUTPUT | MUX_MODE0) /* gpmc_csn0.gpmc_csn0 */
> + 0x90 (PIN_OUTPUT | MUX_MODE0) /* gpmc_advn_ale.gpmc_advn_ale */
> + 0x94 (PIN_OUTPUT | MUX_MODE0) /* gpmc_oen_ren.gpmc_oen_ren */
> + 0x98 (PIN_OUTPUT | MUX_MODE0) /* gpmc_wen.gpmc_wen */
> + 0x9c (PIN_OUTPUT | MUX_MODE0) /* gpmc_be0n_cle.gpmc_be0n_cle */
> + >;
> + };
> };
>
> &i2c0 {
> @@ -246,3 +267,90 @@
> phy_id = <&davinci_mdio>, <0>;
> phy-mode = "rgmii";
> };
> +
> +&elm {
> + status = "okay";
> +};
> +
> +&gpmc {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&nand_flash_x8>;
> + ranges = <0 0 0 0x01000000>; /* minimum GPMC partition = 16MB */
> + nand@0,0 {
> + reg = <0 0 4>; /* device IO registers */
> + ti,nand-ecc-opt = "bch8";
> + ti,elm-id = <&elm>;
> + nand-bus-width = <8>;
> + gpmc,device-width = <1>;
> + gpmc,sync-clk-ps = <0>;
> + gpmc,cs-on-ns = <0>;
> + gpmc,cs-rd-off-ns = <40>;
> + gpmc,cs-wr-off-ns = <40>;
> + gpmc,adv-on-ns = <0>;
> + gpmc,adv-rd-off-ns = <25>;
> + gpmc,adv-wr-off-ns = <25>;
> + gpmc,we-on-ns = <0>;
> + gpmc,we-off-ns = <20>;
> + gpmc,oe-on-ns = <3>;
> + gpmc,oe-off-ns = <30>;
> + gpmc,access-ns = <30>;
> + gpmc,rd-cycle-ns = <40>;
> + gpmc,wr-cycle-ns = <40>;
> + gpmc,wait-pin = <0>;
> + gpmc,wait-on-read;
> + gpmc,wait-on-write;
> + gpmc,bus-turnaround-ns = <0>;
> + gpmc,cycle2cycle-delay-ns = <0>;
> + gpmc,clk-activation-ns = <0>;
> + gpmc,wait-monitoring-ns = <0>;
> + gpmc,wr-access-ns = <40>;
> + gpmc,wr-data-mux-bus-ns = <0>;
> + /* MTD partition table */
> + /* All SPL-* partitions are sized to minimal length
> + * which can be independently programmable. For
> + * NAND flash this is equal to size of erase-block */
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + label = "NAND.SPL";
> + reg = <0x00000000 0x00040000>;
> + };
> + partition@1 {
> + label = "NAND.SPL.backup1";
> + reg = <0x00040000 0x00040000>;
> + };
> + partition@2 {
> + label = "NAND.SPL.backup2";
> + reg = <0x00080000 0x00040000>;
> + };
> + partition@3 {
> + label = "NAND.SPL.backup3";
> + reg = <0x000c0000 0x00040000>;
> + };
> + partition@4 {
> + label = "NAND.u-boot-spl-os";
> + reg = <0x00100000 0x00080000>;
> + };
> + partition@5 {
> + label = "NAND.u-boot";
> + reg = <0x00180000 0x00100000>;
> + };
> + partition@6 {
> + label = "NAND.u-boot-env";
> + reg = <0x00280000 0x00040000>;
> + };
> + partition@7 {
> + label = "NAND.u-boot-env.backup1";
> + reg = <0x002c0000 0x00040000>;
> + };
> + partition@8 {
> + label = "NAND.kernel";
> + reg = <0x00300000 0x00700000>;
> + };
> + partition@9 {
> + label = "NAND.file-system";
> + reg = <0x00a00000 0x1f600000>;
> + };
> + };
> +};
> --
> 1.8.5.1.163.gd7aced9
>
^ permalink raw reply [flat|nested] 26+ messages in thread* RE: [PATCH v7 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
2014-05-19 22:06 ` Tony Lindgren
@ 2014-05-20 4:06 ` Gupta, Pekon
2014-05-20 5:52 ` Tony Lindgren
0 siblings, 1 reply; 26+ messages in thread
From: Gupta, Pekon @ 2014-05-20 4:06 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, Ezequiel Garcia, Stefan Roese,
Javier Martinez Canillas, Quadros, Roger
From: Tony Lindgren [mailto:tony@atomide.com]
>* Pekon Gupta <pekon@ti.com> [140519 02:16]:
>> Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
>> am437x-gp-evm board.
>> (1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
>> eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled:
>> (a) By dynamically driving following GPIO pin from software
>> SPI2_CS0(GPIO) == 0 NAND is selected (default)
>> SPI2_CS0(GPIO) == 1 eMMC is selected
>> (b) By statically using Jumper (J89) on the board
>
>So which MMC controller has eMMC then? How do we select which one we
>have enabled in the am437x-gp-evm.dts by default?
>
If there is no Jumper on the board, then driving SPI2_CS0 before device
probe decides the selection between NAND and eMMC. Therefore NAND
pin-mux also includes SPI2_CS0 and enables PULLDOWN on it to select NAND.
+ 0x26c(PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* spi2_cs0.gpio/eMMCorNANDsel */
>Regards,
>
>Tony
>
>> (2) As NAND device connnected to this board has page-size=4K and oob-size=224,
>> So ROM code expects boot-loaders to be flashed in BCH16 ECC scheme for
>> NAND boot.
>>
>> Signed-off-by: Pekon Gupta <pekon@ti.com>
>> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
>> ---
>> arch/arm/boot/dts/am437x-gp-evm.dts | 108 ++++++++++++++++++++++++++++++++++++
>> 1 file changed, 108 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
>> index 30ace1b..f432685 100644
>> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
>> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
>> @@ -150,6 +150,27 @@
>> 0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
>> >;
>> };
>> +
>> + nand_flash_x8: nand_flash_x8 {
>> + pinctrl-single,pins = <
>> + 0x26c(PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* <------
>spi2_cs0.gpio/eMMCorNANDsel */
with regards, pekon
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v7 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
2014-05-20 4:06 ` Gupta, Pekon
@ 2014-05-20 5:52 ` Tony Lindgren
2014-05-20 6:09 ` Gupta, Pekon
0 siblings, 1 reply; 26+ messages in thread
From: Tony Lindgren @ 2014-05-20 5:52 UTC (permalink / raw)
To: Gupta, Pekon
Cc: linux-omap, Ezequiel Garcia, Stefan Roese,
Javier Martinez Canillas, Quadros, Roger
* Gupta, Pekon <pekon@ti.com> [140519 21:07]:
> From: Tony Lindgren [mailto:tony@atomide.com]
> >* Pekon Gupta <pekon@ti.com> [140519 02:16]:
> >> Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
> >> am437x-gp-evm board.
> >> (1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
> >> eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled:
> >> (a) By dynamically driving following GPIO pin from software
> >> SPI2_CS0(GPIO) == 0 NAND is selected (default)
> >> SPI2_CS0(GPIO) == 1 eMMC is selected
> >> (b) By statically using Jumper (J89) on the board
> >
> >So which MMC controller has eMMC then? How do we select which one we
> >have enabled in the am437x-gp-evm.dts by default?
> >
> If there is no Jumper on the board, then driving SPI2_CS0 before device
> probe decides the selection between NAND and eMMC. Therefore NAND
> pin-mux also includes SPI2_CS0 and enables PULLDOWN on it to select NAND.
So do they share lines outside omap, not inside omap?
The reason I'm asking is I'm worried about the conflicting
pinctrl settings if we try to use both. And I guess that's
not an issue if the muxing of lines is done outside the
omap?
Regards,
Tony
^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: [PATCH v7 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
2014-05-20 5:52 ` Tony Lindgren
@ 2014-05-20 6:09 ` Gupta, Pekon
2014-05-27 21:19 ` Tony Lindgren
0 siblings, 1 reply; 26+ messages in thread
From: Gupta, Pekon @ 2014-05-20 6:09 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, Ezequiel Garcia, Stefan Roese,
Javier Martinez Canillas, Quadros, Roger
From: Tony Lindgren [mailto:tony@atomide.com]
>* Gupta, Pekon <pekon@ti.com> [140519 21:07]:
>> From: Tony Lindgren [mailto:tony@atomide.com]
>> >* Pekon Gupta <pekon@ti.com> [140519 02:16]:
>> >> Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
>> >> am437x-gp-evm board.
>> >> (1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
>> >> eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled:
>> >> (a) By dynamically driving following GPIO pin from software
>> >> SPI2_CS0(GPIO) == 0 NAND is selected (default)
>> >> SPI2_CS0(GPIO) == 1 eMMC is selected
>> >> (b) By statically using Jumper (J89) on the board
>> >
>> >So which MMC controller has eMMC then? How do we select which one we
>> >have enabled in the am437x-gp-evm.dts by default?
>> >
>> If there is no Jumper on the board, then driving SPI2_CS0 before device
>> probe decides the selection between NAND and eMMC. Therefore NAND
>> pin-mux also includes SPI2_CS0 and enables PULLDOWN on it to select NAND.
>
>So do they share lines outside omap, not inside omap?
>
>The reason I'm asking is I'm worried about the conflicting
>pinctrl settings if we try to use both. And I guess that's
>not an issue if the muxing of lines is done outside the
>omap?
>
Yes, the muxing is outside OMAP SoC, so if SPI2_CS0 is correctly
driven it will not allow contention on GPMC line (as per board design).
On am437x-gp-evm board, SPI2_CS0 is used to:
- route GPMC signals to selected device {eMMC | NAND}.
- keep the de-selected device {eMMC | NAND} in reset.
with regards, pekon
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH v7 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
2014-05-20 6:09 ` Gupta, Pekon
@ 2014-05-27 21:19 ` Tony Lindgren
0 siblings, 0 replies; 26+ messages in thread
From: Tony Lindgren @ 2014-05-27 21:19 UTC (permalink / raw)
To: Gupta, Pekon
Cc: linux-omap, Ezequiel Garcia, Stefan Roese,
Javier Martinez Canillas, Quadros, Roger
* Gupta, Pekon <pekon@ti.com> [140519 23:10]:
> From: Tony Lindgren [mailto:tony@atomide.com]
> >* Gupta, Pekon <pekon@ti.com> [140519 21:07]:
> >> From: Tony Lindgren [mailto:tony@atomide.com]
> >> >* Pekon Gupta <pekon@ti.com> [140519 02:16]:
> >> >> Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
> >> >> am437x-gp-evm board.
> >> >> (1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
> >> >> eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled:
> >> >> (a) By dynamically driving following GPIO pin from software
> >> >> SPI2_CS0(GPIO) == 0 NAND is selected (default)
> >> >> SPI2_CS0(GPIO) == 1 eMMC is selected
> >> >> (b) By statically using Jumper (J89) on the board
> >> >
> >> >So which MMC controller has eMMC then? How do we select which one we
> >> >have enabled in the am437x-gp-evm.dts by default?
> >> >
> >> If there is no Jumper on the board, then driving SPI2_CS0 before device
> >> probe decides the selection between NAND and eMMC. Therefore NAND
> >> pin-mux also includes SPI2_CS0 and enables PULLDOWN on it to select NAND.
> >
> >So do they share lines outside omap, not inside omap?
> >
> >The reason I'm asking is I'm worried about the conflicting
> >pinctrl settings if we try to use both. And I guess that's
> >not an issue if the muxing of lines is done outside the
> >omap?
> >
> Yes, the muxing is outside OMAP SoC, so if SPI2_CS0 is correctly
> driven it will not allow contention on GPMC line (as per board design).
>
> On am437x-gp-evm board, SPI2_CS0 is used to:
> - route GPMC signals to selected device {eMMC | NAND}.
> - keep the de-selected device {eMMC | NAND} in reset.
OK thanks for clarifying that, applying into omap-for-v3.16/dt-v2.
Regards,
Tony
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH v7 3/4] ARM: dts: dra7: add support for parallel NAND flash
2014-05-19 9:15 [PATCH v7 0/4] add parallel NAND support for TI's new OMAPx and AMxx platforms (Part-2) Pekon Gupta
2014-05-19 9:15 ` [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape Pekon Gupta
2014-05-19 9:15 ` [PATCH v7 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash Pekon Gupta
@ 2014-05-19 9:15 ` Pekon Gupta
2014-05-19 22:12 ` Tony Lindgren
2014-05-19 9:15 ` [PATCH v7 4/4] ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition Pekon Gupta
3 siblings, 1 reply; 26+ messages in thread
From: Pekon Gupta @ 2014-05-19 9:15 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, Ezequiel Garcia, Stefan Roese,
Javier Martinez Canillas, Roger Quadros, Minal Shah, Pekon Gupta
From: Minal Shah <minalkshah@gmail.com>
DRA7xx platform has in-build GPMC and ELM h/w engines which can be used
for accessing externel NAND flash device. This patch:
- adds generic DT binding in dra7.dtsi for enabling GPMC and ELM h/w engines
- adds DT binding for Micron NAND Flash (MT29F2G16AADWP) present on dra7-evm
*Important*
On DRA7 EVM, GPMC_WPN and NAND_BOOTn are controlled by DIP switch
So following board settings are required for NAND device detection:
SW5.9 (GPMC_WPN) = LOW
SW5.1 (NAND_BOOTn) = HIGH
Signed-off-by: Minal Shah <minalkshah@gmail.com>
Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
---
arch/arm/boot/dts/dra7-evm.dts | 118 +++++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/dra7.dtsi | 20 +++++++
2 files changed, 138 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index ec77907..4adc280 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -120,6 +120,37 @@
0x284 (PIN_INPUT_SLEW | MUX_MODE0) /* usb2_drvvbus */
>;
};
+
+ nand_flash_x16: nand_flash_x16 {
+ /* On DRA7 EVM, GPMC_WPN and NAND_BOOTn comes from DIP switch
+ * So NAND flash requires following switch settings:
+ * SW5.9 (GPMC_WPN) = LOW
+ * SW5.1 (NAND_BOOTn) = HIGH */
+ pinctrl-single,pins = <
+ 0x0 (PIN_INPUT | MUX_MODE0) /* gpmc_ad0 */
+ 0x4 (PIN_INPUT | MUX_MODE0) /* gpmc_ad1 */
+ 0x8 (PIN_INPUT | MUX_MODE0) /* gpmc_ad2 */
+ 0xc (PIN_INPUT | MUX_MODE0) /* gpmc_ad3 */
+ 0x10 (PIN_INPUT | MUX_MODE0) /* gpmc_ad4 */
+ 0x14 (PIN_INPUT | MUX_MODE0) /* gpmc_ad5 */
+ 0x18 (PIN_INPUT | MUX_MODE0) /* gpmc_ad6 */
+ 0x1c (PIN_INPUT | MUX_MODE0) /* gpmc_ad7 */
+ 0x20 (PIN_INPUT | MUX_MODE0) /* gpmc_ad8 */
+ 0x24 (PIN_INPUT | MUX_MODE0) /* gpmc_ad9 */
+ 0x28 (PIN_INPUT | MUX_MODE0) /* gpmc_ad10 */
+ 0x2c (PIN_INPUT | MUX_MODE0) /* gpmc_ad11 */
+ 0x30 (PIN_INPUT | MUX_MODE0) /* gpmc_ad12 */
+ 0x34 (PIN_INPUT | MUX_MODE0) /* gpmc_ad13 */
+ 0x38 (PIN_INPUT | MUX_MODE0) /* gpmc_ad14 */
+ 0x3c (PIN_INPUT | MUX_MODE0) /* gpmc_ad15 */
+ 0xd8 (PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_wait0 */
+ 0xcc (PIN_OUTPUT | MUX_MODE0) /* gpmc_wen */
+ 0xb4 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* gpmc_csn0 */
+ 0xc4 (PIN_OUTPUT | MUX_MODE0) /* gpmc_advn_ale */
+ 0xc8 (PIN_OUTPUT | MUX_MODE0) /* gpmc_oen_ren */
+ 0xd0 (PIN_OUTPUT | MUX_MODE0) /* gpmc_be0n_cle */
+ >;
+ };
};
&i2c1 {
@@ -377,3 +408,90 @@
pinctrl-names = "default";
pinctrl-0 = <&usb2_pins>;
};
+
+&elm {
+ status = "okay";
+};
+
+&gpmc {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_flash_x16>;
+ ranges = <0 0 0 0x01000000>; /* minimum GPMC partition = 16MB */
+ nand@0,0 {
+ reg = <0 0 4>; /* device IO registers */
+ ti,nand-ecc-opt = "bch8";
+ ti,elm-id = <&elm>;
+ nand-bus-width = <16>;
+ gpmc,device-width = <2>;
+ gpmc,sync-clk-ps = <0>;
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <40>;
+ gpmc,cs-wr-off-ns = <40>;
+ gpmc,adv-on-ns = <0>;
+ gpmc,adv-rd-off-ns = <30>;
+ gpmc,adv-wr-off-ns = <30>;
+ gpmc,we-on-ns = <5>;
+ gpmc,we-off-ns = <25>;
+ gpmc,oe-on-ns = <2>;
+ gpmc,oe-off-ns = <20>;
+ gpmc,access-ns = <20>;
+ gpmc,wr-access-ns = <40>;
+ gpmc,rd-cycle-ns = <40>;
+ gpmc,wr-cycle-ns = <40>;
+ gpmc,wait-pin = <0>;
+ gpmc,wait-on-read;
+ gpmc,wait-on-write;
+ gpmc,bus-turnaround-ns = <0>;
+ gpmc,cycle2cycle-delay-ns = <0>;
+ gpmc,clk-activation-ns = <0>;
+ gpmc,wait-monitoring-ns = <0>;
+ gpmc,wr-data-mux-bus-ns = <0>;
+ /* MTD partition table */
+ /* All SPL-* partitions are sized to minimal length
+ * which can be independently programmable. For
+ * NAND flash this is equal to size of erase-block */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "NAND.SPL";
+ reg = <0x00000000 0x000020000>;
+ };
+ partition@1 {
+ label = "NAND.SPL.backup1";
+ reg = <0x00020000 0x00020000>;
+ };
+ partition@2 {
+ label = "NAND.SPL.backup2";
+ reg = <0x00040000 0x00020000>;
+ };
+ partition@3 {
+ label = "NAND.SPL.backup3";
+ reg = <0x00060000 0x00020000>;
+ };
+ partition@4 {
+ label = "NAND.u-boot-spl-os";
+ reg = <0x00080000 0x00040000>;
+ };
+ partition@5 {
+ label = "NAND.u-boot";
+ reg = <0x000c0000 0x00100000>;
+ };
+ partition@6 {
+ label = "NAND.u-boot-env";
+ reg = <0x001c0000 0x00020000>;
+ };
+ partition@7 {
+ label = "NAND.u-boot-env";
+ reg = <0x001e0000 0x00020000>;
+ };
+ partition@8 {
+ label = "NAND.kernel";
+ reg = <0x00200000 0x00800000>;
+ };
+ partition@9 {
+ label = "NAND.file-system";
+ reg = <0x00a00000 0x0f600000>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 6af8b08..a8a0cee 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -964,6 +964,26 @@
dr_mode = "otg";
};
};
+
+ elm: elm@48078000 {
+ compatible = "ti,am3352-elm";
+ reg = <0x48078000 0xfc0>; /* device IO registers */
+ interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+ ti,hwmods = "elm";
+ status = "disabled";
+ };
+
+ gpmc: gpmc@50000000 {
+ compatible = "ti,am3352-gpmc";
+ ti,hwmods = "gpmc";
+ reg = <0x50000000 0x37c>; /* device IO registers */
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ status = "disabled";
+ };
};
};
--
1.8.5.1.163.gd7aced9
^ permalink raw reply related [flat|nested] 26+ messages in thread* Re: [PATCH v7 3/4] ARM: dts: dra7: add support for parallel NAND flash
2014-05-19 9:15 ` [PATCH v7 3/4] ARM: dts: dra7: " Pekon Gupta
@ 2014-05-19 22:12 ` Tony Lindgren
0 siblings, 0 replies; 26+ messages in thread
From: Tony Lindgren @ 2014-05-19 22:12 UTC (permalink / raw)
To: Pekon Gupta
Cc: linux-omap, Ezequiel Garcia, Stefan Roese,
Javier Martinez Canillas, Roger Quadros, Minal Shah
* Pekon Gupta <pekon@ti.com> [140519 02:16]:
> From: Minal Shah <minalkshah@gmail.com>
>
> DRA7xx platform has in-build GPMC and ELM h/w engines which can be used
> for accessing externel NAND flash device. This patch:
> - adds generic DT binding in dra7.dtsi for enabling GPMC and ELM h/w engines
> - adds DT binding for Micron NAND Flash (MT29F2G16AADWP) present on dra7-evm
> *Important*
> On DRA7 EVM, GPMC_WPN and NAND_BOOTn are controlled by DIP switch
> So following board settings are required for NAND device detection:
> SW5.9 (GPMC_WPN) = LOW
> SW5.1 (NAND_BOOTn) = HIGH
>
> Signed-off-by: Minal Shah <minalkshah@gmail.com>
> Signed-off-by: Pekon Gupta <pekon@ti.com>
> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
Thanks applying this into omap-for-v3.16/dt.
Tony
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH v7 4/4] ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition
2014-05-19 9:15 [PATCH v7 0/4] add parallel NAND support for TI's new OMAPx and AMxx platforms (Part-2) Pekon Gupta
` (2 preceding siblings ...)
2014-05-19 9:15 ` [PATCH v7 3/4] ARM: dts: dra7: " Pekon Gupta
@ 2014-05-19 9:15 ` Pekon Gupta
2014-05-19 22:12 ` Tony Lindgren
3 siblings, 1 reply; 26+ messages in thread
From: Pekon Gupta @ 2014-05-19 9:15 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, Ezequiel Garcia, Stefan Roese,
Javier Martinez Canillas, Roger Quadros, Pekon Gupta
MTD NAND partition for file-system should start at offset=0xA00000
Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
---
arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
index 2a0fbbb..ad362c5 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -366,7 +366,7 @@
};
partition@9 {
label = "NAND.file-system";
- reg = <0x00800000 0x1F600000>;
+ reg = <0x00a00000 0x1f600000>;
};
};
};
--
1.8.5.1.163.gd7aced9
^ permalink raw reply related [flat|nested] 26+ messages in thread* Re: [PATCH v7 4/4] ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition
2014-05-19 9:15 ` [PATCH v7 4/4] ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition Pekon Gupta
@ 2014-05-19 22:12 ` Tony Lindgren
0 siblings, 0 replies; 26+ messages in thread
From: Tony Lindgren @ 2014-05-19 22:12 UTC (permalink / raw)
To: Pekon Gupta
Cc: linux-omap, Ezequiel Garcia, Stefan Roese,
Javier Martinez Canillas, Roger Quadros
* Pekon Gupta <pekon@ti.com> [140519 02:16]:
> MTD NAND partition for file-system should start at offset=0xA00000
>
> Signed-off-by: Pekon Gupta <pekon@ti.com>
> Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>
Applying this too into omap-for-v3.16/dt.
Tony
> ---
> arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
> index 2a0fbbb..ad362c5 100644
> --- a/arch/arm/boot/dts/am43x-epos-evm.dts
> +++ b/arch/arm/boot/dts/am43x-epos-evm.dts
> @@ -366,7 +366,7 @@
> };
> partition@9 {
> label = "NAND.file-system";
> - reg = <0x00800000 0x1F600000>;
> + reg = <0x00a00000 0x1f600000>;
> };
> };
> };
> --
> 1.8.5.1.163.gd7aced9
>
^ permalink raw reply [flat|nested] 26+ messages in thread