| Message ID | 20140312215337.GA5735@kahuna (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
[...] > 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 -- 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
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.
On Thu, Mar 13, 2014 at 8:03 AM, Nishanth Menon <nm@ti.com> wrote: > On 03/13/2014 01:19 AM, Gupta, Pekon wrote: > [..] >>> diff --git a/arch/arm/boot/dts/am335x-bone-memory-cape.dts b/arch/arm/boot/dts/am335x-bone-memory-cape.dts >>> new file mode 100644 >>> index 0000000..7ab088d >>> --- /dev/null >>> +++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts >>> >> From discussions, option I could think are.. >> >> (a) NAND cape node added in both 'am335x-bone.dts' and >> 'am335x-boneblack.dts' but "disabled" by default. >> >> (b) NAND cape node in new '.dts' file (as mentioned above), and generate >> a separate blob individual for cape. >> >> (c) NAND cape node in existing 'am335x-bone-common.dtsi', "disabled" >> by default. But there is no guarantee that future boards remain >> compatible and same 'common_xx.dtsi' can be reused later. >> >> I'll wait for Tony/Benoit-C. to decide on what suits them, as they are the >> ones who have to maintain all these. Tony ? >> > > Key for us is that we'd have to live with what ever we introduce in > the interest of backward dtb compatibility. both (a) and (c) requires > hand modification by user of nand cape - considering this might be the > strategy for "most common capes", we might end up with confusing > entries that in many cases will require additional documentation > example: option a, c: consider both audio cape (which needs hdmi > disabled) and nand cape (which needs mmc2 disabled) - how'd the user > know which entries to enable/disable for the user of the cape - > documentation needed and potentially user error prone implementation > as well. > > There is as well a option (d) where we wait for FDT overlay to mature, > write up a resource manager and support all level capes. (b) is the direction i'm currently trying to transition the beagleboard.org community till (d) actually shows any life/hope again. example: https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.13/patches/static-capes I really like Nishanth's simpler version he posted, so I'll be converting mine to that style later today. Also with u-boot v2014.04-rcX we now have "test -e" (exist support) so we can actively check for the presence of <board>-<cape>.dtb and safely fall back to <board>.dtb if it didn't actually exist. The only requirement is the end user specify the <cape> as a variable in uEnv.txt https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2014.04-rc2/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L76 Regards,
* Robert Nelson <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 -- 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
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>; + }; + }; +};