Patchwork [v1,1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape

login
register
mail settings
Submitter Nishanth Menon
Date March 12, 2014, 9:53 p.m.
Message ID <20140312215337.GA5735@kahuna>
Download mbox | patch
Permalink /patch/329720/
State New
Headers show

Comments

Nishanth Menon - March 12, 2014, 9:53 p.m.
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
pekon gupta - March 13, 2014, 6:19 a.m.
[...]
> 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
Nishanth Menon - March 13, 2014, 1:03 p.m.
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.
robertcnelson@gmail.com - March 13, 2014, 1:30 p.m.
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,
Tony Lindgren - March 13, 2014, 4:55 p.m.
* 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

Patch

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>;
+		};
+	};
+};