| Message ID | 1400490948-11571-2-git-send-email-pekon@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* 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 -- 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
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 -- 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 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?
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 -- 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 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?
>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
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,
On Mon, May 19, 2014 at 2:11 PM, Kridner, Jason <jdk@ti.com> wrote: > > > On May 19, 2014, at 11:58 AM, "Robert Nelson" <robertcnelson@gmail.com> > wrote: > > 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. > > > I believe this is the same reason I created > https://github.com/beagleboard/cape-firmware. Is something else needed? Hi Jason, Same exact idea. But instead of the "overlay" dts's that get installed in /lib/firmware/ this will be for the main kernel dtb files, that'll be dumped in /boot/dtbs/*.dtb or /boot/*.dtb. In theory we should be able to build these outside kernel.org, so down the road we can add a package for all the other distro's. Regards,
> On May 19, 2014, at 12:22 PM, "Robert Nelson" <robertcnelson@gmail.com> wrote: > >> On Mon, May 19, 2014 at 2:11 PM, Kridner, Jason <jdk@ti.com> wrote: >> >> >> On May 19, 2014, at 11:58 AM, "Robert Nelson" <robertcnelson@gmail.com> >> wrote: >> >> 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. >> >> >> I believe this is the same reason I created >> https://github.com/beagleboard/cape-firmware. Is something else needed? > > Hi Jason, > > Same exact idea. But instead of the "overlay" dts's that get installed > in /lib/firmware/ this will be for the main kernel dtb files, that'll > be dumped in /boot/dtbs/*.dtb or /boot/*.dtb. In theory we should be > able to build these outside kernel.org, so down the road we can add a > package for all the other distro's. Why not reuse the same repo since the capes would be in there too? Does it need renaming? > > Regards, > > -- > Robert Nelson > http://www.rcn-ee.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
>>> >>> I believe this is the same reason I created >>> https://github.com/beagleboard/cape-firmware. Is something else needed? >> >> Hi Jason, >> >> Same exact idea. But instead of the "overlay" dts's that get installed >> in /lib/firmware/ this will be for the main kernel dtb files, that'll >> be dumped in /boot/dtbs/*.dtb or /boot/*.dtb. In theory we should be >> able to build these outside kernel.org, so down the road we can add a >> package for all the other distro's. > > Why not reuse the same repo since the capes would be in there too? Does it need renaming? Okay, i'll work with that repo and get something for v3.15.x/v3.16.x cleaned up. Regards,
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 -- 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
* 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 -- 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 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. -- 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
PkZyb206IEphc29uIEtyaWRuZXIgW21haWx0bzpqa3JpZG5lckBnbWFpbC5jb21dDQo+Pk9uIE1v biwgSnVuIDIzLCAyMDE0IGF0IDE6NDggQU0sIFRvbnkgTGluZGdyZW4gPHRvbnlAYXRvbWlkZS5j b20+IHdyb3RlOg0KPj4+ICogR3VwdGEsIFBla29uIDxwZWtvbkB0aS5jb20+IFsxNDA2MjIgMjI6 NDJdOg0KPj4+ID5Gcm9tOiBUb255IExpbmRncmVuIFttYWlsdG86dG9ueUBhdG9taWRlLmNvbV0N Cg0KWy4uLl0NCg0KPj4+ID5CYXNlZCBvbiB0aGUgcmVjZW50IGRpc2N1c3Npb25zIG9uIHRoZSBj YXBlcywgaXQgc2VlbXMgdGhhdCBub2JvZHkNCj4+PiA+d2FudHMgdG8gaW1wbGVtZW50IHRvZ2ds aW5nIG9mIHRoZSBjYXBlcyBpbiB1LWJvb3QuIEFuZCBhcyB0aGVyZQ0KPj4+ID5jYW4gYmUgb3Ro ZXIgY2FwZXMgdXNpbmcgR1BNQyBidXMsIHdlIGNhbid0IG1lcmdlIHRoaXMuDQo+Pj4NCj4+PiBJ IGhhdmUgYmVlbiBhYmxlIHRvIGdldCB0b2dnbGluZyBvZiBjYXBlcyAoZW5hYmxpbmcgYW5kIGRp c2FibGluZyBvZiBEVCBub2RlcykNCj4+PiBpbiB1LWJvb3QuIEl0IHdhcyBhbHJlYWR5IHRoZXJl IGluIHUtYm9vdCBtYWlubGluZSBbMV0sIG1heSBiZSBuby1ib2R5IHRyaWVkIGl0Lg0KPj4+DQo+ Pj4gRXhhbXBsZTogQmVsb3cgc2VxdWVuY2Ugd29ya3MgZm9yIE5BTkQgY2FwZSBwYXRjaCBtZW50 aW9uZWQgaW4gdGhpcyB0aHJlYWQuDQo+Pj4gLS0tLS0tLS0tLS0tLS0tDQo+Pj4gLyogbG9hZCBE VEIgKi8NCj4+PiB1LWJvb3Q+IHRmdHAgMHg4MTAwMDAwMCBhbTMzNXgtYm9uZWJsYWNrLmR0Yg0K Pj4+IHUtYm9vdD4gZmR0IGFkZHIgMHg4MTAwMDAwMA0KPj4+IC8qIGRpc2FibGUgTU1DMiBub2Rl ICovDQo+Pj4gdS1ib290PiBmZHQgbGlzdCAvb2NwL21tY0A0ODFkODAwMA0KPj4+IHUtYm9vdD4g ZmR0IHNldCAgL29jcC9tbWNANDgxZDgwMDAgc3RhdHVzIFxkXGlcc1xhXGJcbFxlXGQNCj4+PiB1 LWJvb3Q+IGZkdCBsaXN0IC9vY3AvbW1jQDQ4MWQ4MDAwIHN0YXR1cw0KPj4+IC8qIGVuYWJsZSBH UE1DIG5vZGUgKi8NCj4+PiB1LWJvb3Q+IGZkdCBsaXN0IC9vY3AvZ3BtYw0KPj4+IHUtYm9vdD4g ZmR0IHNldCAgL29jcC9ncG1jIHN0YXR1cyBcb1xrXGFceQ0KPj4+IHUtYm9vdD4gZmR0IGxpc3Qg L29jcC9ncG1jIHN0YXR1cw0KPj4+IC8qIGVuYWJsZSBFTE0gbm9kZSAqLw0KPj4+IHUtYm9vdD4g ZmR0IGxpc3QgL29jcC9lbG0NCj4+PiB1LWJvb3Q+IGZkdCBzZXQgIC9vY3AvZWxtIHN0YXR1cyBc b1xrXGFceQ0KPj4+IHUtYm9vdD4gZmR0IGxpc3QgL29jcC9lbG0gc3RhdHVzDQo+Pj4gLyogYm9v dCB1SW1hZ2UgKi8NCj4+PiB0ZnRwIDB4ODIwMDAwMDAgdUltYWdlDQo+Pj4gYm9vdG0gMHg4MjAw MDAwMCAtIDB4ODEwMDAwMDANCj4+Pg0KPj4+IE5vdGU6ICJmZHQgc2V0IiBjb21tYW5kIGRvZXMg bm90IGFjY2VwdCBzdHJpbmcgbGl0ZXJhbHMNCj4+PiBhcyBiaW5kaW5nIHZhbHVlcywgaXQgaW50 ZXJuYWxseSBjb252ZXJ0cyB0aGVtIHRvIHN0cmluZywgc28NCj4+PiBlc2NhcGUgc2VxdWVuY2Vk IGNoYXJhY3RlcnMgd2VyZSB1c2VkIGhlcmUuLg0KPj4+ICJva2F5IiA9PSBcb1xrXGFceQ0KPj4+ ICJkaXNhYmxlZCIgPT0gXGRcaVxzXGFcYlxsXGVcZCINCj4+DQo+PiBDb29sLiBOb3cgYWxsIHdl IG5lZWQgaXMgYSBmZXcgaGVscGVyIGZ1bmN0aW9ucyBpbiB1LWJvb3QNCj4+IHNvIGl0IGNhbiBi ZSBkb25lIGEgYml0IGVhc2llciA6KQ0KPj4NCj4NCj5UaGUgYXNzb2NpYXRpb24gb2YgZGV2aWNl dHJlZSBvdmVybGF5IGZpbGVzIGluIC9saWIvZmlybXdhcmUgdG8gY2FwZQ0KPklEcyBtYWRlIGl0 IHdoZXJlIHRoZSBrZXJuZWwtYmFzZWQgY2FwZSBvdmVybGF5IG1hbmFnZXIgY291bGQgbW9kaWZ5 DQo+dGhlIGRldmljZXRyZWUgYXMgbmVlZGVkIHdpdGhvdXQgcHV0dGluZyBleHRlbnNpdmUgY2Fw ZS1zcGVjaWZpYyBsb2dpYw0KPmluIHRoZSBrZXJuZWwgb3IgYm9vdGxvYWRlci4gVGhyb3dpbmcg YSBidW5jaCBvZiBjYXBlcyBpbnRvIGEgc2luZ2xlDQo+Y2xhc3Mgb2YgY2FwZXMgd29uJ3Qgc2F2 ZSBhbnkgd29yayB0aGVyZS4NCj4NCkknbSBjbGFzc2lmeWluZyBjYXBlcyBiYXNlZCBvbiBmdW5j dGlvbmFsaXR5IHRvIHJlZHVjZSB0aGUgbnVtYmVyIG9mDQpEVFMgZmlsZXMsIGJlY2F1c2UgaW4g Z2VuZXJhbCBwZW9wbGUgd2lsbCBub3QgYm90aCBMQ0Q0IGFuZCBMQ0Q3IGNhcGVzDQp0b2dldGhl ciwgc2ltaWxhcmx5IG5vdCBtYW55IHdpbGwgdXNlIE5BTkQsIE5PUiBhbmQgZU1NQyBzaW11bGF0 YW5lb3VzbHkuDQotIGFtMzM1eC1ib25lLW1lbW9yeS1jYXBlLmR0czogd2lsbCBoYXZlIE5BTkQs IE5PUiBhbmQgc3RvcmFnZSByZWxhdGVkIGNhcGVzDQotIGFtMzM1eC1ib25lLWRpc3BsYXktY2Fw ZS5kdHM6IHdpbGwgaGF2ZSBMQ0Q0LCBMQ0Q3LCAuLi4gZXRjIGNhcGVzLg0KDQoNCj4gSWYgd2Ug Y2FuIGdldCB0aGUgYm9vdGxvYWRlcg0KPnRvIHN1cHBvcnQgdGhlIC5kdGJvIGZpbGVzLCB0aGVu IHdlIGNhbiBjb250aW51ZSB0byB1c2UgdGhlIElEIGluIHRoZQ0KPmNhcGUgdG8gcHJvdmlkZSBh bGwgdGhlIERUIG1vZGlmaWNhdGlvbnMgd2UgbmVlZC4gSWYgd2UgbmVlZCB0byBkbw0KPnNjcmlw dHMgZm9yIHRoZSBtb2RpZmljYXRpb25zLCB3ZSdkIHN0aWxsIG5lZWQgdG8gYXNzb2NpYXRlIHRo ZSBjYXBlDQo+SUQgdG8gdGhhdCBzY3JpcHQuDQo+DQpXaXRoIElEIGJhc2VkIGF1dG8taWRlbnRp ZmljYXRpb24gb2YgQ2FwZXMsIHdlIG5lZWQgRUVQUk9NIG9yDQplLWZ1c2VzIG9uIGV2ZXJ5IGNh cGUuIEFuZCB0b2RheSBJIGRvbid0IHRoaW5rIGFsbCB0aGlyZC1wYXJ0eSBjYXBlcw0KaGF2ZSBF RVBST00gb24gdGhlbS4NCkFsc28sIHdpdGggaW5jcmVhc2UgaW4gbnVtYmVyIG9mIGNhcGUsIGl0 IHdpbGwgYmUgaGFyZCB0byBtYWludGFpbg0KSUQgZ3JvdXBpbmcgYW5kIHVwZGF0aW5nIGZpcm13 YXJlL3NvZnR3YXJlIGZvciBlYWNoIG5ldyBjYXBlLg0KDQoNCj4NCj5UaGlzIHN0aWxsIGRvZXNu J3QgY292ZXIgdGhlIG5lZWQgZm9yIHJ1bi10aW1lIGRldmljZXRyZWUNCj5tb2RpZmljYXRpb24s IGJ1dCBJJ2xsIGxlYXZlIHRoYXQgZm9yIHRoZSBvdGhlciBvbi1nb2luZyB0aHJlYWQuDQo+DQpJ J20ganVzdCBwcm9wb3NpbmcgdGhlIHUtYm9vdCB3YXkgb2YgZW5hYmxpbmcvZGlzYWJsaW5nIERU Lg0KVGhpcyBpcyBjZXJ0YWlubHkgbm90IHJlcGxhY2luZyByZXF1aXJlbWVudCBmb3IgRFQgb3Zl cmxheSBtYW5hZ2VyLA0KQnV0IHRpbGwgdGhlIHRpbWUgRFQgb3ZlcmxheSBpcyBhdmFpbGFibGUg aW4ga2VybmVsLCB0aGlzIHdvdWxkIGF0LWxlYXN0DQpiZSBhbiBwbGFjZWhvbGRlciBhbmQgd291 bGQgZW5jb3VyYWdlIEJlYWdsZWJvbmUgdXNlcnMgdG8NCmNvbnRpbnVlIHVzaW5nIG1haW5saW5l IGtlcm5lbC4NClRoaXMgd2h5IEknbSB0cnlpbmcgdG8gZ2V0IGJhc2ljIGNhcGUgRFRTIGluIG1h aW5saW5lLCBzbyB0aGF0DQpCZWFnbGVib25lIGNvbW11bml0eSBjb250aW51ZXMgdG8gYmUgaW4g dG91Y2ggd2l0aCBtYWlubGluZS4NClRvbW9ycm93IGlmIERUIG92ZXJsYXkgY29tZXMsIHRoZW4g d2UgbWF5IGNob29zZSB0byBlaXRoZXIga2VlcA0KdGhlc2UgY2FwZSBEVFMsIG9yIGRlbGV0ZSB0 aGVtIGZyb20gbWFpbmxpbmUgd2l0aG91dCBicmVha2luZyBhbnkNCmJhY2t3YXJkIGNvbXBhdGli aWxpdHkuDQoNCg0KPkkgZG8gYWdyZWUgd2l0aCB0aGUgaWRlYSBvZiBtb3ZpbmcgbW9yZSBvZiB0 aGUgcG90ZW50aWFsIHNvdXJjZXMgb2YNCj5jb25mbGljdCB0aGF0IGNhbiBiZSByZXNvbHZlZCBv dXQgb2YgdGhlIG92ZXJsYXlzIGFuZCBpbnRvIHRoZSBtYWluDQo+ZGV2aWNldHJlZSwgbGVhdmlu ZyB0aGUgb3ZlcmxheXMgb3Igc2NyaXB0cyBzaW1wbHkgdG8gZGVhbCB3aXRoIHRoZQ0KPmNvbmZs aWN0cyB0aGF0IGNhbm5vdCBiZSByZXNvbHZlZCBhdCBydW4tdGltZSBnaXZlbiB0aGUgY3VycmVu dA0KPmluZnJhc3RydWN0dXJlLiBJIGp1c3QgdGhpbmsgdGhleSBzaG91bGQgZ28gaW50byAuZHRz aSAoaW5jbHVkZSkgZmlsZXMNCj5mb3IgdGhlIG1haW4gLmR0cy8uZHRiIGZpbGVzIGZvciB0aGUg Ym9hcmRzLCByYXRoZXIgdGhhbiBhZGRpdGlvbmFsDQo+b3ZlcmxheXMgb3IgYWx0ZXJuYXRpdmUg LmR0cyBmaWxlcy4NCj4NClllcywgdGhhdCBpcyB0aGUgbWFpbiBtb3RpdmUsIHRvIHJlc29sdmUg X2tub3duXyBjb25mbGljdHMgYmVmb3JlDQpSdW4tdGltZS4gQW5kIGtlZXAgdGhpbmdzIHdvcmtp bmcgdGlsbCAnRFQgb3ZlcmxheScgaXMgbWFpbmxpbmVkLg0KDQpBbm90aGVyIHRoaW5nIHdoaWNo IEknbSBub3Qgc3VyZSBpcyBob3cgRFQgb3ZlcmxheSB3aWxsIHdvcmsNCndpdGggY2FwZXMgd2hp Y2ggYXJlIHJlcXVpcmVkIGR1cmluZyBib290Pw0KRXhhbXBsZTogTkFORCwgTk9SIGNhcGVzIHRo ZW1zZWx2ZXMgY29udGFpbmluZyBmaWxlLXN5c3RlbS4NCkkgdGhpbmsgaW4gc3VjaCBzY2VuYXJp b3MgdXNpbmcgdS1ib290IGFwcHJvYWNoIGZvciBlbmFibGluZy9kaXNhYmxpbmcNCmNhcGVzIHdv dWxkIGJlIGJlbmVmaWNpYWwuDQoNCg0KSWYgeW91IGFuZCBvdGhlcnMgYXJlIG9rYXkgd2l0aCB0 aGlzIGFwcHJvYWNoLCBJIHdvdWxkIHJlcXVlc3QgeW91DQp0byBwbGVhc2UgcHJvdmlkZSB5b3Vy ICJUZXN0ZWQtYnkiIGZvciBmZXcgY2FwZSBEVFMgcGF0Y2hlcyBJDQp3aWxsIGJlIHBvc3Rpbmcg c29vbi4gVGhpcyB3b3VsZCBnaXZlIGNvbmZpZGVuY2UgdGhhdCBjYXBlIERUUw0KcGF0Y2hlcyBh cmUgbm90IGJyZWFraW5nIGFueXRoaW5nIGluIGV4aXN0aW5nIERUUy4NCg0KDQpUaGFua3MuLg0K d2l0aCByZWdhcmRzLCBwZWtvbg0K -- 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/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>;