RE: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
From: Jason Kridner [mailto:jkrid...@gmail.com]
On Mon, Jun 23, 2014 at 1:48 AM, Tony Lindgren t...@atomide.com wrote:
* Gupta, Pekon pe...@ti.com [140622 22:42]:
From: Tony Lindgren [mailto:t...@atomide.com]
[...]
Based on the recent discussions on the capes, it seems that nobody
wants to implement toggling of the capes in u-boot. And as there
can be other capes using GPMC bus, we can't merge this.
I have been able to get toggling of capes (enabling and disabling of DT
nodes)
in u-boot. It was already there in u-boot mainline [1], may be no-body
tried it.
Example: Below sequence works for NAND cape patch mentioned in this thread.
---
/* load DTB */
u-boot tftp 0x8100 am335x-boneblack.dtb
u-boot fdt addr 0x8100
/* 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 0x8200 uImage
bootm 0x8200 - 0x8100
Note: fdt set command does not accept string literals
as binding values, it internally converts them to string, so
escape sequenced characters were used here..
okay == \o\k\a\y
disabled == \d\i\s\a\b\l\e\d
Cool. Now all we need is a few helper functions in u-boot
so it can be done a bit easier :)
The association of devicetree overlay files in /lib/firmware to cape
IDs made it where the kernel-based cape overlay manager could modify
the devicetree as needed without putting extensive cape-specific logic
in the kernel or bootloader. Throwing a bunch of capes into a single
class of capes won't save any work there.
I'm classifying capes based on functionality to reduce the number of
DTS files, because in general people will not both LCD4 and LCD7 capes
together, similarly not many will use NAND, NOR and eMMC simulataneously.
- am335x-bone-memory-cape.dts: will have NAND, NOR and storage related capes
- am335x-bone-display-cape.dts: will have LCD4, LCD7, ... etc capes.
If we can get the bootloader
to support the .dtbo files, then we can continue to use the ID in the
cape to provide all the DT modifications we need. If we need to do
scripts for the modifications, we'd still need to associate the cape
ID to that script.
With ID based auto-identification of Capes, we need EEPROM or
e-fuses on every cape. And today I don't think all third-party capes
have EEPROM on them.
Also, with increase in number of cape, it will be hard to maintain
ID grouping and updating firmware/software for each new cape.
This still doesn't cover the need for run-time devicetree
modification, but I'll leave that for the other on-going thread.
I'm just proposing the u-boot way of enabling/disabling DT.
This is certainly not replacing requirement for DT overlay manager,
But till the time DT overlay is available in kernel, this would at-least
be an placeholder and would encourage Beaglebone users to
continue using mainline kernel.
This why I'm trying to get basic cape DTS in mainline, so that
Beaglebone community continues to be in touch with mainline.
Tomorrow if DT overlay comes, then we may choose to either keep
these cape DTS, or delete them from mainline without breaking any
backward compatibility.
I do agree with the idea of moving more of the potential sources of
conflict that can be resolved out of the overlays and into the main
devicetree, leaving the overlays or scripts simply to deal with the
conflicts that cannot be resolved at run-time given the current
infrastructure. I just think they should go into .dtsi (include) files
for the main .dts/.dtb files for the boards, rather than additional
overlays or alternative .dts files.
Yes, that is the main motive, to resolve _known_ conflicts before
Run-time. And keep things working till 'DT overlay' is mainlined.
Another thing which I'm not sure is how DT overlay will work
with capes which are required during boot?
Example: NAND, NOR capes themselves containing file-system.
I think in such scenarios using u-boot approach for enabling/disabling
capes would be beneficial.
If you and others are okay with this approach, I would request you
to please provide your Tested-by for few cape DTS patches I
will be posting soon. This would give confidence that cape DTS
patches are not breaking anything in existing DTS.
Thanks..
with regards, pekon
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
On Mon, Jun 23, 2014 at 1:48 AM, Tony Lindgren t...@atomide.com wrote:
* Gupta, Pekon pe...@ti.com [140622 22:42]:
Hi Tony,
Just reviving this thread for some information..
From: Tony Lindgren [mailto:t...@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 pe...@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 = 180;
--- 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 = 180;
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 0x8100 am335x-boneblack.dtb
u-boot fdt addr 0x8100
/* 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 0x8200 uImage
bootm 0x8200 - 0x8100
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
Hi Tony,
Just reviving this thread for some information..
From: Tony Lindgren [mailto:t...@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 pe...@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 = 180;
--- 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 = 180;
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 0x8100 am335x-boneblack.dtb
u-boot fdt addr 0x8100
/* 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 0x8200 uImage
bootm 0x8200 - 0x8100
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
* Gupta, Pekon pe...@ti.com [140622 22:42]:
Hi Tony,
Just reviving this thread for some information..
From: Tony Lindgren [mailto:t...@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 pe...@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 = 180;
--- 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 = 180;
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 0x8100 am335x-boneblack.dtb
u-boot fdt addr 0x8100
/* 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 0x8200 uImage
bootm 0x8200 - 0x8100
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
* Pekon Gupta pe...@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 = 180;
--- 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 = 180;
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
Hi Tony,
From: Tony Lindgren [mailto:t...@atomide.com]
* Pekon Gupta pe...@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 = 180;
--- 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 = 180;
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
On 19 May 05:52 PM, Gupta, Pekon wrote:
Hi Tony,
From: Tony Lindgren [mailto:t...@atomide.com]
* Pekon Gupta pe...@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 = 180;
--- 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 = 180;
Based on the recent discussions on the capes, it seems that nobody
wants to implement toggling of the capes in u-boot. And as there
can be other capes using GPMC bus, we can't merge this. And because
the capes are stackable, we can't really have .dts files for all
the combinations. And no, we're not merging any unconnected .dts
files either, sorry.
Yes, I fully understand. This is like death for most of the capes from point
of view of mainline support. But I have submitted this patch just for sake
of completion. And to provide reference if someone wants to locally work
on beaglebone NAND cape.
While I fully agree with Tony on this, I think the reference is much
appreciated. Do you think you can push the NAND cape DT example somewhere?
Maybe some TI wiki page?
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com] On 19 May 05:52 PM, Gupta, Pekon wrote: From: Tony Lindgren [mailto:t...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
On Mon, May 19, 2014 at 1:16 PM, Ezequiel Garcia
ezequiel.gar...@free-electrons.com wrote:
On 19 May 05:52 PM, Gupta, Pekon wrote:
Hi Tony,
From: Tony Lindgren [mailto:t...@atomide.com]
* Pekon Gupta pe...@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 = 180;
--- 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 = 180;
Based on the recent discussions on the capes, it seems that nobody
wants to implement toggling of the capes in u-boot. And as there
can be other capes using GPMC bus, we can't merge this. And because
the capes are stackable, we can't really have .dts files for all
the combinations. And no, we're not merging any unconnected .dts
files either, sorry.
Yes, I fully understand. This is like death for most of the capes from point
of view of mainline support. But I have submitted this patch just for sake
of completion. And to provide reference if someone wants to locally work
on beaglebone NAND cape.
While I fully agree with Tony on this, I think the reference is much
appreciated. Do you think you can push the NAND cape DT example somewhere?
Maybe some TI wiki page?
(resent in text mode for linux-omap list archive)
Since the capes are always some way tied with bb.org hardware, why
don't we put them up on https://github.com/beagleboard/ ?
am335x-capes.git ?
I envision, we should just mirror the base ./arch/arm/boot/dts/
directory (as someday the dts will be external anyways). In that repo,
we will keep these synced with mainline
am335x-bone-common.dtsi
am335x-bone.dts
am335x-boneblack.dts
and add the capes as:
baseboard-cape.dts
as a staging ground till a mainline overlay/etc system appears?
Thoughs?
--
Robert Nelson
http://www.rcn-ee.com/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
From: Robert Nelson [mailto:robertcnel...@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
Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
On Mon, May 19, 2014 at 1:51 PM, Gupta, Pekon pe...@ti.com wrote: From: Robert Nelson [mailto:robertcnel...@gmail.com] [...] Since the capes are always some way tied with bb.org hardware, why don't we put them up on https://github.com/beagleboard/ ? am335x-capes.git ? I envision, we should just mirror the base ./arch/arm/boot/dts/ directory (as someday the dts will be external anyways). In that repo, we will keep these synced with mainline am335x-bone-common.dtsi am335x-bone.dts am335x-boneblack.dts and add the capes as: baseboard-cape.dts as a staging ground till a mainline overlay/etc system appears? Thoughs? If you know and can convince 'Gerald Coley' then plz try. I failed :-) Oh, I'll do it... ;) I just need Jason to create the intial repo for me on github.com/beagleboard and enable my permission for it. Then i'll just pull in the capes in that repo and push it to my --beta-kernel option for users running the new debian image who would like run mainline over the old v3.8.x Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
On Mon, May 19, 2014 at 2:11 PM, Kridner, Jason j...@ti.com wrote: On May 19, 2014, at 11:58 AM, Robert Nelson robertcnel...@gmail.com wrote: On Mon, May 19, 2014 at 1:51 PM, Gupta, Pekon pe...@ti.com wrote: From: Robert Nelson [mailto:robertcnel...@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, -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
On May 19, 2014, at 12:22 PM, Robert Nelson robertcnel...@gmail.com wrote: On Mon, May 19, 2014 at 2:11 PM, Kridner, Jason j...@ti.com wrote: On May 19, 2014, at 11:58 AM, Robert Nelson robertcnel...@gmail.com wrote: On Mon, May 19, 2014 at 1:51 PM, Gupta, Pekon pe...@ti.com wrote: From: Robert Nelson [mailto:robertcnel...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
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, -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
