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

login
register
mail settings
Submitter pekon gupta
Date March 12, 2014, 10:49 a.m.
Message ID <1394621360-2457-2-git-send-email-pekon@ti.com>
Download mbox | patch
Permalink /patch/329382/
State New
Headers show

Comments

pekon gupta - March 12, 2014, 10:49 a.m.
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(+)
Nishanth Menon - March 12, 2014, 2:35 p.m.
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>;
> +		};
> +	};
> +};
>
pekon gupta - March 12, 2014, 6:26 p.m.
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
Nishanth Menon - March 12, 2014, 6:57 p.m.
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
robertcnelson@gmail.com - March 12, 2014, 7:08 p.m.
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,
Tony Lindgren - March 12, 2014, 7:28 p.m.
* 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
Nishanth Menon - March 12, 2014, 8:51 p.m.
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
pekon gupta - March 12, 2014, 9:13 p.m.
>-----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

Patch

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