* How to extend SRC_URI_append?
@ 2010-09-03 11:12 Jean-Christophe PLAGNIOL-VILLARD
2010-09-03 14:44 ` Chris Larson
2010-09-04 3:14 ` [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global Jean-Christophe PLAGNIOL-VILLARD
0 siblings, 2 replies; 24+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-03 11:12 UTC (permalink / raw)
To: openembedded-devel
Hi,
I'm currently working on the adding of a sub SH arch the st40
for this I've define the SOC_FAMILY as SOC_FAMILY="st40"
but now I want to apply some patch to gcc, binutils and others
via SRC_URI_append_st40 or SRC_URI_append_sh_st40
how can i do it?
Best Regards,
J.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to extend SRC_URI_append?
2010-09-03 11:12 How to extend SRC_URI_append? Jean-Christophe PLAGNIOL-VILLARD
@ 2010-09-03 14:44 ` Chris Larson
2010-09-03 16:47 ` Jean-Christophe PLAGNIOL-VILLARD
2010-09-04 3:14 ` [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global Jean-Christophe PLAGNIOL-VILLARD
1 sibling, 1 reply; 24+ messages in thread
From: Chris Larson @ 2010-09-03 14:44 UTC (permalink / raw)
To: openembedded-devel
The append syntax you're referring to uses OVERRIDES. FOO_somevalue
replaces FOO if somevalue is in OVERRIDES. FOO_append_somevalue is added to
FOO if somevalue is in OVERRIDES. I don't think SOC_FAMILY is in overrides
at this time.
On Fri, Sep 3, 2010 at 4:12 AM, Jean-Christophe PLAGNIOL-VILLARD <
plagnioj@jcrosoft.com> wrote:
> Hi,
>
> I'm currently working on the adding of a sub SH arch the st40
>
> for this I've define the SOC_FAMILY as SOC_FAMILY="st40"
>
> but now I want to apply some patch to gcc, binutils and others
>
> via SRC_URI_append_st40 or SRC_URI_append_sh_st40
>
> how can i do it?
>
> Best Regards,
> J.
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to extend SRC_URI_append?
2010-09-03 14:44 ` Chris Larson
@ 2010-09-03 16:47 ` Jean-Christophe PLAGNIOL-VILLARD
2010-09-03 16:59 ` Jean-Christophe PLAGNIOL-VILLARD
0 siblings, 1 reply; 24+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-03 16:47 UTC (permalink / raw)
To: openembedded-devel
On 07:44 Fri 03 Sep , Chris Larson wrote:
> The append syntax you're referring to uses OVERRIDES. FOO_somevalue
> replaces FOO if somevalue is in OVERRIDES. FOO_append_somevalue is added to
> FOO if somevalue is in OVERRIDES. I don't think SOC_FAMILY is in overrides
> at this time.
how can I extend it?
Best Regards,
J.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to extend SRC_URI_append?
2010-09-03 16:47 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2010-09-03 16:59 ` Jean-Christophe PLAGNIOL-VILLARD
2010-09-03 20:34 ` Maupin, Chase
0 siblings, 1 reply; 24+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-03 16:59 UTC (permalink / raw)
To: openembedded-devel
On 18:47 Fri 03 Sep , Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 07:44 Fri 03 Sep , Chris Larson wrote:
> > The append syntax you're referring to uses OVERRIDES. FOO_somevalue
> > replaces FOO if somevalue is in OVERRIDES. FOO_append_somevalue is added to
> > FOO if somevalue is in OVERRIDES. I don't think SOC_FAMILY is in overrides
> > at this time.
> how can I extend it?
is this ok?
diff --git a/conf/bitbake.conf b/conf/bitbake.conf
index 677c76a..ecdf245 100644
--- a/conf/bitbake.conf
+++ b/conf/bitbake.conf
@@ -677,9 +677,9 @@ BUILDCFG_NEEDEDVARS ?= "TARGET_ARCH TARGET_OS"
#
# This works for functions as well, they are really just environment variables.
# Default OVERRIDES to make compilation fail fast in case of build system misconfiguration.
-OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}"
+OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:${SOC_FAMILY}:${TARGET_ARCH}_${SOC_FAMILY}:build-${BUILD_OS}:fail-fast:pn-${PN}"
# Alternative OVERRIDES definition without "fail fast", usually only for native building and Scratchbox toolchains.
-#OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}"
+#OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:${SOC_FAMILY}:${TARGET_ARCH}_${SOC_FAMILY}:build-${BUILD_OS}:pn-${PN}"
##################################################################
# Include the rest of the config files.
Best Regards,
J.
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: How to extend SRC_URI_append?
2010-09-03 16:59 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2010-09-03 20:34 ` Maupin, Chase
2010-09-03 21:45 ` Khem Raj
` (2 more replies)
0 siblings, 3 replies; 24+ messages in thread
From: Maupin, Chase @ 2010-09-03 20:34 UTC (permalink / raw)
To: openembedded-devel
> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org
> [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of
> Jean-Christophe PLAGNIOL-VILLARD
> Sent: Friday, September 03, 2010 11:59 AM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] How to extend SRC_URI_append?
>
> On 18:47 Fri 03 Sep , Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 07:44 Fri 03 Sep , Chris Larson wrote:
> > > The append syntax you're referring to uses OVERRIDES. FOO_somevalue
> > > replaces FOO if somevalue is in OVERRIDES. FOO_append_somevalue is
> added to
> > > FOO if somevalue is in OVERRIDES. I don't think SOC_FAMILY is in
> overrides
> > > at this time.
> > how can I extend it?
> is this ok?
>
> diff --git a/conf/bitbake.conf b/conf/bitbake.conf
> index 677c76a..ecdf245 100644
> --- a/conf/bitbake.conf
> +++ b/conf/bitbake.conf
> @@ -677,9 +677,9 @@ BUILDCFG_NEEDEDVARS ?= "TARGET_ARCH TARGET_OS"
> #
> # This works for functions as well, they are really just environment
> variables.
> # Default OVERRIDES to make compilation fail fast in case of build system
> misconfiguration.
> -OVERRIDES =
> "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-
> ${BUILD_OS}:fail-fast:pn-${PN}"
> +OVERRIDES =
> "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:${SOC_FAMILY}:${TA
> RGET_ARCH}_${SOC_FAMILY}:build-${BUILD_OS}:fail-fast:pn-${PN}"
> # Alternative OVERRIDES definition without "fail fast", usually only for
> native building and Scratchbox toolchains.
> -#OVERRIDES =
> "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-
> ${BUILD_OS}:pn-${PN}"
> +#OVERRIDES =
> "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:${SOC_FAMILY}:${TA
> RGET_ARCH}_${SOC_FAMILY}:build-${BUILD_OS}:pn-${PN}"
>
> ##################################################################
> # Include the rest of the config files.
>
> Best Regards,
> J.
Is there really a case for a ${TARGET_ARCH}_${SOC_FAMILY} override. If these devices have different architectures are they really part of the same family?
As for adding this to bitbake.conf I guess I wouldn't object, but I don't know that this is something everyone would want. Instead you could put this in your distro's conf file (like angstrom does) or in your local.conf file.
The distro/include/angstrom.inc file sets:
OVERRIDES .= ":${FEED_ARCH}:${SOC_FAMILY}"
I use SOC_FAMILY overrides in my work.
Just my two cents
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to extend SRC_URI_append?
2010-09-03 20:34 ` Maupin, Chase
@ 2010-09-03 21:45 ` Khem Raj
2010-09-04 3:17 ` Jean-Christophe PLAGNIOL-VILLARD
2010-09-04 11:20 ` Jean-Christophe PLAGNIOL-VILLARD
2 siblings, 0 replies; 24+ messages in thread
From: Khem Raj @ 2010-09-03 21:45 UTC (permalink / raw)
To: openembedded-devel
On Fri, Sep 3, 2010 at 1:34 PM, Maupin, Chase <chase.maupin@ti.com> wrote:
>> -----Original Message-----
>> From: openembedded-devel-bounces@lists.openembedded.org
>> [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of
>> Jean-Christophe PLAGNIOL-VILLARD
>> Sent: Friday, September 03, 2010 11:59 AM
>> To: openembedded-devel@lists.openembedded.org
>> Subject: Re: [oe] How to extend SRC_URI_append?
>>
>> On 18:47 Fri 03 Sep , Jean-Christophe PLAGNIOL-VILLARD wrote:
>> > On 07:44 Fri 03 Sep , Chris Larson wrote:
>> > > The append syntax you're referring to uses OVERRIDES. FOO_somevalue
>> > > replaces FOO if somevalue is in OVERRIDES. FOO_append_somevalue is
>> added to
>> > > FOO if somevalue is in OVERRIDES. I don't think SOC_FAMILY is in
>> overrides
>> > > at this time.
>> > how can I extend it?
>> is this ok?
>>
>> diff --git a/conf/bitbake.conf b/conf/bitbake.conf
>> index 677c76a..ecdf245 100644
>> --- a/conf/bitbake.conf
>> +++ b/conf/bitbake.conf
>> @@ -677,9 +677,9 @@ BUILDCFG_NEEDEDVARS ?= "TARGET_ARCH TARGET_OS"
>> #
>> # This works for functions as well, they are really just environment
>> variables.
>> # Default OVERRIDES to make compilation fail fast in case of build system
>> misconfiguration.
>> -OVERRIDES =
>> "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-
>> ${BUILD_OS}:fail-fast:pn-${PN}"
>> +OVERRIDES =
>> "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:${SOC_FAMILY}:${TA
>> RGET_ARCH}_${SOC_FAMILY}:build-${BUILD_OS}:fail-fast:pn-${PN}"
>> # Alternative OVERRIDES definition without "fail fast", usually only for
>> native building and Scratchbox toolchains.
>> -#OVERRIDES =
>> "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-
>> ${BUILD_OS}:pn-${PN}"
>> +#OVERRIDES =
>> "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:${SOC_FAMILY}:${TA
>> RGET_ARCH}_${SOC_FAMILY}:build-${BUILD_OS}:pn-${PN}"
>>
>> ##################################################################
>> # Include the rest of the config files.
>>
>> Best Regards,
>> J.
>
> Is there really a case for a ${TARGET_ARCH}_${SOC_FAMILY} override. If these devices have different architectures are they really part of the same family?
>
> As for adding this to bitbake.conf I guess I wouldn't object, but I don't know that this is something everyone would want. Instead you could put this in your distro's conf file (like angstrom does) or in your local.conf file.
>
> The distro/include/angstrom.inc file sets:
>
> OVERRIDES .= ":${FEED_ARCH}:${SOC_FAMILY}"
second option is better.
>
> I use SOC_FAMILY overrides in my work.
>
> Just my two cents
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global
2010-09-03 11:12 How to extend SRC_URI_append? Jean-Christophe PLAGNIOL-VILLARD
2010-09-03 14:44 ` Chris Larson
@ 2010-09-04 3:14 ` Jean-Christophe PLAGNIOL-VILLARD
2010-09-04 7:45 ` Frans Meulenbroeks
` (3 more replies)
1 sibling, 4 replies; 24+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-04 3:14 UTC (permalink / raw)
To: openembedded-devel
add global OVERRIDES ${TARGET_SOC_FAMILY} and ${TARGET_ARCH}_${TARGET_SOC_FAMILY}
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
classes/base.bbclass | 4 ++--
conf/bitbake.conf | 6 ++++--
conf/distro/include/angstrom.inc | 6 ++----
conf/machine/include/dm355.inc | 2 +-
conf/machine/include/dm365.inc | 2 +-
conf/machine/include/dm6446.inc | 2 +-
conf/machine/include/dm6467.inc | 2 +-
conf/machine/include/omap3.inc | 2 +-
conf/machine/include/omapl137.inc | 2 +-
conf/machine/include/omapl138.inc | 2 +-
recipes/ti/ti-codec-engine.inc | 2 +-
recipes/ti/ti-dsplink.inc | 2 +-
recipes/ti/ti-linuxutils.inc | 4 ++--
recipes/ti/ti-local-power-manager.inc | 2 +-
14 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/classes/base.bbclass b/classes/base.bbclass
index 299e875..0085655 100644
--- a/classes/base.bbclass
+++ b/classes/base.bbclass
@@ -336,8 +336,8 @@ python () {
import re
this_machine = bb.data.getVar('MACHINE', d, 1)
if this_machine and not re.match(need_machine, this_machine):
- this_soc_family = bb.data.getVar('SOC_FAMILY', d, 1)
- if this_soc_family and not re.match(need_machine, this_soc_family):
+ this_target_soc_family = bb.data.getVar('TARGET_SOC_FAMILY', d, 1)
+ if this_target_soc_family and not re.match(need_machine, this_target_soc_family):
raise bb.parse.SkipPackage("incompatible with machine %s" % this_machine)
need_target = bb.data.getVar('COMPATIBLE_TARGET_SYS', d, 1)
diff --git a/conf/bitbake.conf b/conf/bitbake.conf
index 677c76a..672d8df 100644
--- a/conf/bitbake.conf
+++ b/conf/bitbake.conf
@@ -113,6 +113,8 @@ TARGET_SYS = "${TARGET_ARCH}${TARGET_VENDOR}${@['-' + bb.data.getVar('TARGET_OS'
TARGET_PREFIX = "${TARGET_SYS}-"
TARGET_CC_ARCH = ""
TARGET_EXEEXT = ""
+TARGET_SOC_FAMILY ?= "Unknown"
+
SDK_ARCH ?= "${BUILD_ARCH}"
SDK_OS ?= "${BUILD_OS}"
@@ -677,9 +679,9 @@ BUILDCFG_NEEDEDVARS ?= "TARGET_ARCH TARGET_OS"
#
# This works for functions as well, they are really just environment variables.
# Default OVERRIDES to make compilation fail fast in case of build system misconfiguration.
-OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}"
+OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:${TARGET_SOC_FAMILY}:${TARGET_ARCH}_${TARGET_SOC_FAMILY}:build-${BUILD_OS}:fail-fast:pn-${PN}"
# Alternative OVERRIDES definition without "fail fast", usually only for native building and Scratchbox toolchains.
-#OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}"
+#OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:${TARGET_SOC_FAMILY}:${TARGET_ARCH}_${TARGET_SOC_FAMILY}:build-${BUILD_OS}:pn-${PN}"
##################################################################
# Include the rest of the config files.
diff --git a/conf/distro/include/angstrom.inc b/conf/distro/include/angstrom.inc
index 8983c86..ae6781d 100644
--- a/conf/distro/include/angstrom.inc
+++ b/conf/distro/include/angstrom.inc
@@ -11,10 +11,8 @@ BUILDNAME = "Angstrom ${DISTRO_VERSION}"
TARGET_VENDOR = "-angstrom"
-SOC_FAMILY ?= "Unknown"
-
-# Add FEED_ARCH and SOC_FAMILY to overrides
-OVERRIDES .= ":${FEED_ARCH}:${SOC_FAMILY}"
+# Add FEED_ARCH to overrides
+OVERRIDES .= ":${FEED_ARCH}"
# Put links to sources in deploy/sources to make it easier for people to be GPL compliant
INHERIT += "src_distribute_local"
diff --git a/conf/machine/include/dm355.inc b/conf/machine/include/dm355.inc
index d666d5e..19556691 100644
--- a/conf/machine/include/dm355.inc
+++ b/conf/machine/include/dm355.inc
@@ -1,2 +1,2 @@
-SOC_FAMILY = "dm355"
+TARGET_SOC_FAMILY = "dm355"
diff --git a/conf/machine/include/dm365.inc b/conf/machine/include/dm365.inc
index b974f2c..6793c74 100644
--- a/conf/machine/include/dm365.inc
+++ b/conf/machine/include/dm365.inc
@@ -1,2 +1,2 @@
-SOC_FAMILY = "dm365"
+TARGET_SOC_FAMILY = "dm365"
diff --git a/conf/machine/include/dm6446.inc b/conf/machine/include/dm6446.inc
index 827b375..5e2f16c 100644
--- a/conf/machine/include/dm6446.inc
+++ b/conf/machine/include/dm6446.inc
@@ -1,2 +1,2 @@
-SOC_FAMILY = "dm6446"
+TARGET_SOC_FAMILY = "dm6446"
diff --git a/conf/machine/include/dm6467.inc b/conf/machine/include/dm6467.inc
index 5200f85..b5ed729 100644
--- a/conf/machine/include/dm6467.inc
+++ b/conf/machine/include/dm6467.inc
@@ -1 +1 @@
-SOC_FAMILY = "dm6467"
+TARGET_SOC_FAMILY = "dm6467"
diff --git a/conf/machine/include/omap3.inc b/conf/machine/include/omap3.inc
index 1052296..d1ffcad 100644
--- a/conf/machine/include/omap3.inc
+++ b/conf/machine/include/omap3.inc
@@ -1,4 +1,4 @@
-SOC_FAMILY = "omap3"
+TARGET_SOC_FAMILY = "omap3"
require conf/machine/include/tune-cortexa8.inc
PREFERRED_PROVIDER_virtual/kernel = "linux-omap"
diff --git a/conf/machine/include/omapl137.inc b/conf/machine/include/omapl137.inc
index cd84594..7187572 100644
--- a/conf/machine/include/omapl137.inc
+++ b/conf/machine/include/omapl137.inc
@@ -1 +1 @@
-SOC_FAMILY = "omapl137"
+TARGET_SOC_FAMILY = "omapl137"
diff --git a/conf/machine/include/omapl138.inc b/conf/machine/include/omapl138.inc
index 4c22275..887aabe 100644
--- a/conf/machine/include/omapl138.inc
+++ b/conf/machine/include/omapl138.inc
@@ -1 +1 @@
-SOC_FAMILY = "omapl138"
+TARGET_SOC_FAMILY = "omapl138"
diff --git a/recipes/ti/ti-codec-engine.inc b/recipes/ti/ti-codec-engine.inc
index 1b89ea7..56347b0 100644
--- a/recipes/ti/ti-codec-engine.inc
+++ b/recipes/ti/ti-codec-engine.inc
@@ -25,7 +25,7 @@ DEPENDS_append_omap3 = " ti-dspbios ti-dsplink ti-local-power-manager ti-cgt6x t
DEPENDS_append_omapl137 = " ti-dspbios ti-dsplink ti-cgt6x ti-biosutils ti-edma3lld"
DEPENDS_append_omapl138 = " ti-dspbios ti-dsplink ti-cgt6x ti-biosutils ti-edma3lld"
-# SOC_FAMILY configuration
+# TARGET_SOC_FAMILY configuration
# Define DEVICES variable
CEEXAMPLESDEVICES_dm6446 = "DM6446"
diff --git a/recipes/ti/ti-dsplink.inc b/recipes/ti/ti-dsplink.inc
index 388d057..2fb7079 100644
--- a/recipes/ti/ti-dsplink.inc
+++ b/recipes/ti/ti-dsplink.inc
@@ -28,7 +28,7 @@ SRC_URI = "http://software-dl.ti.com/dsps/dsps_public_sw/${PV_DL_PATH}/dsplink_l
DEPENDS = "ti-dspbios ti-xdctools ti-cgt6x"
DEPENDS += "virtual/kernel perl-native"
-# SOC_FAMILY configuration
+# TARGET_SOC_FAMILY configuration
DSPLINKPLATFORM_dm6446 = "DAVINCI"
DSPLINKPLATFORM_dm6467 = "DAVINCIHD"
diff --git a/recipes/ti/ti-linuxutils.inc b/recipes/ti/ti-linuxutils.inc
index 073416a..c650044 100644
--- a/recipes/ti/ti-linuxutils.inc
+++ b/recipes/ti/ti-linuxutils.inc
@@ -18,7 +18,7 @@ inherit module
do_compile() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
- case ${SOC_FAMILY} in
+ case ${TARGET_SOC_FAMILY} in
dm365)
modules="cmem edma irq";;
omap3)
@@ -53,7 +53,7 @@ do_install () {
EXEC_DIR="${D}${installdir}/ti-linuxutils-app/cmem-app" \
install
# Install EDMA
- if [ ${SOC_FAMILY} == "dm365" ] ; then
+ if [ ${TARGET_SOC_FAMILY} == "dm365" ] ; then
cd ${S}/packages/ti/sdo/linuxutils/edma/apps
make \
LINUXKERNEL_INSTALL_DIR="${STAGING_KERNEL_DIR}" \
diff --git a/recipes/ti/ti-local-power-manager.inc b/recipes/ti/ti-local-power-manager.inc
index a0e3bfd..31f9243 100644
--- a/recipes/ti/ti-local-power-manager.inc
+++ b/recipes/ti/ti-local-power-manager.inc
@@ -22,7 +22,7 @@ SRC_URI = "http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/lp
DEPENDS = "ti-dsplink ti-xdctools"
DEPENDS += "virtual/kernel"
-# SOC_FAMILY configuration
+# TARGET_SOC_FAMILY configuration
LPMDSPPOWERSOC_omap3 = "omap3530"
LPMDSPPOWERSOC_dm6446 = "dm6446"
--
1.7.2
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: How to extend SRC_URI_append?
2010-09-03 20:34 ` Maupin, Chase
2010-09-03 21:45 ` Khem Raj
@ 2010-09-04 3:17 ` Jean-Christophe PLAGNIOL-VILLARD
2010-09-04 11:20 ` Jean-Christophe PLAGNIOL-VILLARD
2 siblings, 0 replies; 24+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-04 3:17 UTC (permalink / raw)
To: openembedded-devel
>
> Is there really a case for a ${TARGET_ARCH}_${SOC_FAMILY} override. If these devices have different architectures are they really part of the same family?
yes I've as I've the same soc family on 2 arch with 2 patch series
I'm preparing it and will send soon I hope
Best Regards
J.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global
2010-09-04 3:14 ` [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global Jean-Christophe PLAGNIOL-VILLARD
@ 2010-09-04 7:45 ` Frans Meulenbroeks
2010-09-04 8:20 ` Frans Meulenbroeks
2010-09-07 14:43 ` Maupin, Chase
` (2 subsequent siblings)
3 siblings, 1 reply; 24+ messages in thread
From: Frans Meulenbroeks @ 2010-09-04 7:45 UTC (permalink / raw)
To: openembedded-devel
2010/9/4 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
> add global OVERRIDES ${TARGET_SOC_FAMILY} and ${TARGET_ARCH}_${TARGET_SOC_FAMILY}
>
What is the rationale for this?
And why not fix the problem there is in base.bbclass as well.
Frans.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global
2010-09-04 7:45 ` Frans Meulenbroeks
@ 2010-09-04 8:20 ` Frans Meulenbroeks
2010-09-07 14:21 ` Maupin, Chase
0 siblings, 1 reply; 24+ messages in thread
From: Frans Meulenbroeks @ 2010-09-04 8:20 UTC (permalink / raw)
To: openembedded-devel
2010/9/4 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
> 2010/9/4 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
>> add global OVERRIDES ${TARGET_SOC_FAMILY} and ${TARGET_ARCH}_${TARGET_SOC_FAMILY}
>>
>
> What is the rationale for this?
> And why not fix the problem there is in base.bbclass as well.
>
> Frans.
>
Forgot about this, but a variable should go with documentation.
This already has been raised with the orginal patch, but was ignored
by the submitters.
Consider this a NAK.
Frans
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: How to extend SRC_URI_append?
2010-09-03 20:34 ` Maupin, Chase
2010-09-03 21:45 ` Khem Raj
2010-09-04 3:17 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2010-09-04 11:20 ` Jean-Christophe PLAGNIOL-VILLARD
2 siblings, 0 replies; 24+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-04 11:20 UTC (permalink / raw)
To: openembedded-devel
> >
> > ##################################################################
> > # Include the rest of the config files.
> >
> > Best Regards,
> > J.
>
> Is there really a case for a ${TARGET_ARCH}_${SOC_FAMILY} override. If these devices have different architectures are they really part of the same family?
>
> As for adding this to bitbake.conf I guess I wouldn't object, but I don't know that this is something everyone would want. Instead you could put this in your distro's conf file (like angstrom does) or in your local.conf file.
I disagree as example I've to apply patch to gcc, binutils or directfb and
other componets so it's absolutelt not distro specific but SoC and hardware
specific
so if we make it distros specific we will have to add it to all of them to
support this familly of SoC
Best Regards,
J.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global
2010-09-04 8:20 ` Frans Meulenbroeks
@ 2010-09-07 14:21 ` Maupin, Chase
2010-09-08 5:58 ` Frans Meulenbroeks
0 siblings, 1 reply; 24+ messages in thread
From: Maupin, Chase @ 2010-09-07 14:21 UTC (permalink / raw)
To: openembedded-devel
> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org
> [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of
> Frans Meulenbroeks
> Sent: Saturday, September 04, 2010 3:20 AM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make
> it global
>
> 2010/9/4 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
> > 2010/9/4 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
> >> add global OVERRIDES ${TARGET_SOC_FAMILY} and
> ${TARGET_ARCH}_${TARGET_SOC_FAMILY}
> >>
> >
> > What is the rationale for this?
> > And why not fix the problem there is in base.bbclass as well.
> >
> > Frans.
> >
> Forgot about this, but a variable should go with documentation.
> This already has been raised with the orginal patch, but was ignored
> by the submitters.
Frans, Are you counting me as one of the original submitters? I mainly use the SOC_FAMILY, I didn't create it. That being said, if you have a recommended section of the usermanual that this should be documented in I'll try to add something.
>
> Consider this a NAK.
>
> Frans
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global
2010-09-04 3:14 ` [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global Jean-Christophe PLAGNIOL-VILLARD
2010-09-04 7:45 ` Frans Meulenbroeks
@ 2010-09-07 14:43 ` Maupin, Chase
2010-09-08 3:47 ` Jean-Christophe PLAGNIOL-VILLARD
2010-09-09 9:26 ` Phil Blundell
2010-09-12 8:11 ` Koen Kooi
3 siblings, 1 reply; 24+ messages in thread
From: Maupin, Chase @ 2010-09-07 14:43 UTC (permalink / raw)
To: openembedded-devel
> add global OVERRIDES ${TARGET_SOC_FAMILY} and
> ${TARGET_ARCH}_${TARGET_SOC_FAMILY}
>
For my part I would ask why you are renaming SOC_FAMILY to TARGET_SOC_FAMILY? Why not leave the name the way it is since others may be using it in overlays, etc?
Also, you might want to make sure your patch would include Fran's fix to base.bbclass that he mentioned at http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-September/023680.html
For what my input is worth I would NAK this patch because:
1. I don't see a reason to add this to the generic set of overrides.
2. I don't understand why the name of the variable SOC_FAMILY needs to be changed. I know this will break existing overlays and I don't see any reason why the change is made.
3. I disagree with the ${TARGET_ARCH}_${TARGET_SOC_FAMILY} override. If you have two patch series for different architectures then you should have two SOC_FAMILY settings or use the MACHINE setting for the override. I think this override is confusing and redundant.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global
2010-09-07 14:43 ` Maupin, Chase
@ 2010-09-08 3:47 ` Jean-Christophe PLAGNIOL-VILLARD
0 siblings, 0 replies; 24+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-08 3:47 UTC (permalink / raw)
To: openembedded-devel
On 09:43 Tue 07 Sep , Maupin, Chase wrote:
> > add global OVERRIDES ${TARGET_SOC_FAMILY} and
> > ${TARGET_ARCH}_${TARGET_SOC_FAMILY}
> >
> For my part I would ask why you are renaming SOC_FAMILY to TARGET_SOC_FAMILY? Why not leave the name the way it is since others may be using it in overlays, etc?
to be consistant it's the TARGET SOC FAMILY not the host
as the ARCH
>
> Also, you might want to make sure your patch would include Fran's fix to base.bbclass that he mentioned at http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-September/023680.html
>
> For what my input is worth I would NAK this patch because:
>
> 1. I don't see a reason to add this to the generic set of overrides.
because you need for SoC support and it's not distrib related but hardware
related (SoC familly)
> 2. I don't understand why the name of the variable SOC_FAMILY needs to be changed. I know this will break existing overlays and I don't see any reason why the change is made.
> 3. I disagree with the ${TARGET_ARCH}_${TARGET_SOC_FAMILY} override. If you have two patch series for different architectures then you should have two SOC_FAMILY settings or use the MACHINE setting for the override. I think this override is confusing and redundant.
no as I describe already the same doc familly can be run on two or more ARCH
so this make sens and no it's no the machine to handle this but each receipe
and no it's not redundant at all it's more precises as at receipe level you
may we do this
SRC_URI_arm += patches
SRC_URI_arm_mnt += patches
SRC_URI_mnt += patches
SRC_URI_mips += patches
SRC_URI_mips_mnt += patches
so yes it's need
Best Regards,
J.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global
2010-09-07 14:21 ` Maupin, Chase
@ 2010-09-08 5:58 ` Frans Meulenbroeks
2010-09-10 18:57 ` Denys Dmytriyenko
0 siblings, 1 reply; 24+ messages in thread
From: Frans Meulenbroeks @ 2010-09-08 5:58 UTC (permalink / raw)
To: openembedded-devel
2010/9/7 Maupin, Chase <chase.maupin@ti.com>:
>> Forgot about this, but a variable should go with documentation.
>> This already has been raised with the orginal patch, but was ignored
>> by the submitters.
>
> Frans, Are you counting me as one of the original submitters? I mainly use the SOC_FAMILY, I didn't create it. That being said, if you have a recommended section of the usermanual that this should be documented in I'll try to add something.
>
Hi Chase,
I see you indeed as the submitter. The commit carries your name and
there is no reference in the commit message of another author.
Wrt the manual: actually I thought we had a section for this, but as
it stands i cannot find it. Guess I saw it somewhere else.
I'm not really sure where it would fit. I guess there are others who
have a better view on the manual and its structure.
Frans
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global
2010-09-04 3:14 ` [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global Jean-Christophe PLAGNIOL-VILLARD
2010-09-04 7:45 ` Frans Meulenbroeks
2010-09-07 14:43 ` Maupin, Chase
@ 2010-09-09 9:26 ` Phil Blundell
2010-09-12 8:11 ` Koen Kooi
3 siblings, 0 replies; 24+ messages in thread
From: Phil Blundell @ 2010-09-09 9:26 UTC (permalink / raw)
To: openembedded-devel
On Sat, 2010-09-04 at 05:14 +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> diff --git a/conf/bitbake.conf b/conf/bitbake.conf
> index 677c76a..672d8df 100644
> --- a/conf/bitbake.conf
> +++ b/conf/bitbake.conf
> @@ -113,6 +113,8 @@ TARGET_SYS = "${TARGET_ARCH}${TARGET_VENDOR}${@['-' + bb.data.getVar('TARGET_OS'
> TARGET_PREFIX = "${TARGET_SYS}-"
> TARGET_CC_ARCH = ""
> TARGET_EXEEXT = ""
> +TARGET_SOC_FAMILY ?= "Unknown"
> +
>
> SDK_ARCH ?= "${BUILD_ARCH}"
> SDK_OS ?= "${BUILD_OS}"
> @@ -677,9 +679,9 @@ BUILDCFG_NEEDEDVARS ?= "TARGET_ARCH TARGET_OS"
> #
> # This works for functions as well, they are really just environment variables.
> # Default OVERRIDES to make compilation fail fast in case of build system misconfiguration.
> -OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}"
> +OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:${TARGET_SOC_FAMILY}:${TARGET_ARCH}_${TARGET_SOC_FAMILY}:build-${BUILD_OS}:fail-fast:pn-${PN}"
I don't have much of an opinion on the renaming, but the overrides part
will cause an unacceptable level of namespace pollution. As it stands,
everybody will suddenly get "Unknown" in their OVERRIDES and this is not
at all desirable.
If you must add these kinds of things to the default OVERRIDES then they
need a suitable namespace prefix, for example something like
soc-family-${SOC_FAMILY}. (Alternatively, put it in your own DISTRO
configuration where you can do whatever you like.)
p.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global
2010-09-08 5:58 ` Frans Meulenbroeks
@ 2010-09-10 18:57 ` Denys Dmytriyenko
2010-09-10 20:32 ` Tom Rini
2010-09-12 7:40 ` Frans Meulenbroeks
0 siblings, 2 replies; 24+ messages in thread
From: Denys Dmytriyenko @ 2010-09-10 18:57 UTC (permalink / raw)
To: openembedded-devel
On Wed, Sep 08, 2010 at 07:58:39AM +0200, Frans Meulenbroeks wrote:
> 2010/9/7 Maupin, Chase <chase.maupin@ti.com>:
>
> >> Forgot about this, but a variable should go with documentation.
> >> This already has been raised with the orginal patch, but was ignored
> >> by the submitters.
> >
> > Frans, Are you counting me as one of the original submitters? I mainly
> > use the SOC_FAMILY, I didn't create it. That being said, if you have a
> > recommended section of the usermanual that this should be documented in
> > I'll try to add something.
>
> Hi Chase,
> I see you indeed as the submitter. The commit carries your name and
> there is no reference in the commit message of another author.
>
> Wrt the manual: actually I thought we had a section for this, but as
> it stands i cannot find it. Guess I saw it somewhere else.
> I'm not really sure where it would fit. I guess there are others who
> have a better view on the manual and its structure.
Frans,
I guess then you haven't read the original discussion closely enough. Chase
only made a change to add existing SOC_FAMILY override into COMPATIBLE_MACHINE
variable... I keep repeating myself - SOC_FAMILY feature is about a year old.
It was introduced as part of a large merge from Arago. Here is the original
commit and some description:
http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=b788499815bfc1974d4277c0a261b9a7c24aa816
--
Denys
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global
2010-09-10 18:57 ` Denys Dmytriyenko
@ 2010-09-10 20:32 ` Tom Rini
2010-09-10 20:43 ` Denys Dmytriyenko
2010-09-12 7:40 ` Frans Meulenbroeks
1 sibling, 1 reply; 24+ messages in thread
From: Tom Rini @ 2010-09-10 20:32 UTC (permalink / raw)
To: openembedded-devel
Denys Dmytriyenko wrote:
> On Wed, Sep 08, 2010 at 07:58:39AM +0200, Frans Meulenbroeks wrote:
>> 2010/9/7 Maupin, Chase <chase.maupin@ti.com>:
>>
>>>> Forgot about this, but a variable should go with documentation.
>>>> This already has been raised with the orginal patch, but was ignored
>>>> by the submitters.
>>> Frans, Are you counting me as one of the original submitters? I mainly
>>> use the SOC_FAMILY, I didn't create it. That being said, if you have a
>>> recommended section of the usermanual that this should be documented in
>>> I'll try to add something.
>> Hi Chase,
>> I see you indeed as the submitter. The commit carries your name and
>> there is no reference in the commit message of another author.
>>
>> Wrt the manual: actually I thought we had a section for this, but as
>> it stands i cannot find it. Guess I saw it somewhere else.
>> I'm not really sure where it would fit. I guess there are others who
>> have a better view on the manual and its structure.
>
> Frans,
>
> I guess then you haven't read the original discussion closely enough. Chase
> only made a change to add existing SOC_FAMILY override into COMPATIBLE_MACHINE
> variable... I keep repeating myself - SOC_FAMILY feature is about a year old.
> It was introduced as part of a large merge from Arago. Here is the original
> commit and some description:
>
> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=b788499815bfc1974d4277c0a261b9a7c24aa816
I suppose you could save Chase some time, Denys, and update the manual
instead :) But to me, it's perfectly reasonable for Frans to ask that
when someone renames a not previously documented variable to go ahead
and document it too (since they must have some knowledge of how it
works, and some correct knowledge being written down is better than none).
--
Tom Rini
Mentor Graphics Corporation
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global
2010-09-10 20:32 ` Tom Rini
@ 2010-09-10 20:43 ` Denys Dmytriyenko
2010-09-11 9:19 ` Frans Meulenbroeks
0 siblings, 1 reply; 24+ messages in thread
From: Denys Dmytriyenko @ 2010-09-10 20:43 UTC (permalink / raw)
To: openembedded-devel
On Fri, Sep 10, 2010 at 01:32:39PM -0700, Tom Rini wrote:
> Denys Dmytriyenko wrote:
>> On Wed, Sep 08, 2010 at 07:58:39AM +0200, Frans Meulenbroeks wrote:
>>> 2010/9/7 Maupin, Chase <chase.maupin@ti.com>:
>>>
>>>>> Forgot about this, but a variable should go with documentation.
>>>>> This already has been raised with the orginal patch, but was ignored
>>>>> by the submitters.
>>>> Frans, Are you counting me as one of the original submitters? I mainly
>>>> use the SOC_FAMILY, I didn't create it. That being said, if you have a
>>>> recommended section of the usermanual that this should be documented in
>>>> I'll try to add something.
>>> Hi Chase,
>>> I see you indeed as the submitter. The commit carries your name and
>>> there is no reference in the commit message of another author.
>>>
>>> Wrt the manual: actually I thought we had a section for this, but as
>>> it stands i cannot find it. Guess I saw it somewhere else.
>>> I'm not really sure where it would fit. I guess there are others who
>>> have a better view on the manual and its structure.
>> Frans,
>> I guess then you haven't read the original discussion closely enough.
>> Chase only made a change to add existing SOC_FAMILY override into
>> COMPATIBLE_MACHINE variable... I keep repeating myself - SOC_FAMILY
>> feature is about a year old. It was introduced as part of a large merge
>> from Arago. Here is the original commit and some description:
>> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=b788499815bfc1974d4277c0a261b9a7c24aa816
>
> I suppose you could save Chase some time, Denys, and update the manual
> instead :) But to me, it's perfectly reasonable for Frans to ask that when
> someone renames a not previously documented variable to go ahead and
> document it too (since they must have some knowledge of how it works, and
> some correct knowledge being written down is better than none).
Thanks, Tom!
Yes, pushing Chase's patch for documentation update is on my TODO list for
later today - I'm giving people last chance to comment...
I agree, updating documentation is very desirable, no objections here. I was
merely commenting on Frans' note here, giving some background:
>>> Hi Chase,
>>> I see you indeed as the submitter. The commit carries your name and
>>> there is no reference in the commit message of another author.
--
Denys
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global
2010-09-10 20:43 ` Denys Dmytriyenko
@ 2010-09-11 9:19 ` Frans Meulenbroeks
0 siblings, 0 replies; 24+ messages in thread
From: Frans Meulenbroeks @ 2010-09-11 9:19 UTC (permalink / raw)
To: openembedded-devel
2010/9/10 Denys Dmytriyenko <denis@denix.org>:
> On Fri, Sep 10, 2010 at 01:32:39PM -0700, Tom Rini wrote:
>> Denys Dmytriyenko wrote:
>>> On Wed, Sep 08, 2010 at 07:58:39AM +0200, Frans Meulenbroeks wrote:
>>>> 2010/9/7 Maupin, Chase <chase.maupin@ti.com>:
>
> Yes, pushing Chase's patch for documentation update is on my TODO list for
> later today - I'm giving people last chance to comment...
Thanks alot!
>
> I agree, updating documentation is very desirable, no objections here. I was
> merely commenting on Frans' note here, giving some background:
>
>>>> Hi Chase,
>>>> I see you indeed as the submitter. The commit carries your name and
>>>> there is no reference in the commit message of another author.
Actually I was not really aware of SOC_FAMILY existing already.
I was triggered by this message which hinted Chase was the owner:
http://thread.gmane.org/gmane.comp.handhelds.openembedded/35141/focus=35236
(and there was no ref to the patch you mentioned).
Anyway, it is documented and that is good!
Frans
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global
2010-09-10 18:57 ` Denys Dmytriyenko
2010-09-10 20:32 ` Tom Rini
@ 2010-09-12 7:40 ` Frans Meulenbroeks
2010-09-21 18:28 ` Denys Dmytriyenko
1 sibling, 1 reply; 24+ messages in thread
From: Frans Meulenbroeks @ 2010-09-12 7:40 UTC (permalink / raw)
To: openembedded-devel
2010/9/10 Denys Dmytriyenko <denis@denix.org>:
:>
> Frans,
>
> I guess then you haven't read the original discussion closely enough. Chase
> only made a change to add existing SOC_FAMILY override into COMPATIBLE_MACHINE
> variable... I keep repeating myself - SOC_FAMILY feature is about a year old.
> It was introduced as part of a large merge from Arago. Here is the original
> commit and some description:
>
> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=b788499815bfc1974d4277c0a261b9a7c24aa816
I did some more research on this, as I could not recall any specific info.
The patch you give above is from dec, so 9 months old.
At that time it was not discussed at the mailing list as far as I can
see. As the commit message said "recipes/ti: merge in updates"
I (and I guess most of the non-ti devs) gave little attention to it.
Also I did a quick grep on the source tree. Currently it is only used
in the following files
frans@linux-suse:~/oe/openembedded> grep -r SOC_FAMILY .
./conf/local.conf:SOC_FAMILY_local = "none"
./conf/distro/include/angstrom.inc:SOC_FAMILY ?= "Unknown"
./conf/distro/include/angstrom.inc:# Add FEED_ARCH and SOC_FAMILY to overrides
./conf/distro/include/angstrom.inc:OVERRIDES .= ":${FEED_ARCH}:${SOC_FAMILY}"
./conf/machine/include/dm6467.inc:SOC_FAMILY = "dm6467"
./conf/machine/include/omap3.inc:SOC_FAMILY = "omap3"
./conf/machine/include/omapl137.inc:SOC_FAMILY = "omapl137"
./conf/machine/include/dm365.inc:SOC_FAMILY = "dm365"
./conf/machine/include/dm6446.inc:SOC_FAMILY = "dm6446"
./conf/machine/include/dm355.inc:SOC_FAMILY = "dm355"
./conf/machine/include/omapl138.inc:SOC_FAMILY = "omapl138"
./recipes/ti/ti-linuxutils.inc: case ${SOC_FAMILY} in
./recipes/ti/ti-linuxutils.inc: if [ ${SOC_FAMILY} == "dm365" ] ; then
./recipes/ti/ti-local-power-manager.inc:# SOC_FAMILY configuration
./recipes/ti/ti-codec-engine.inc:# SOC_FAMILY configuration
./recipes/ti/ti-dsplink.inc:# SOC_FAMILY configuration
./classes/base.bbclass: this_soc_family =
bb.data.getVar('SOC_FAMILY', d, 1)
Anyway, wrt the breakage, I'll push the patch for now as it has been
out for review quite a while (and I got an ack and a looks good).
If SOC_FAMILY is not desired we can also revert that one.
Frans
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global
2010-09-04 3:14 ` [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global Jean-Christophe PLAGNIOL-VILLARD
` (2 preceding siblings ...)
2010-09-09 9:26 ` Phil Blundell
@ 2010-09-12 8:11 ` Koen Kooi
2010-09-13 2:45 ` Jean-Christophe PLAGNIOL-VILLARD
3 siblings, 1 reply; 24+ messages in thread
From: Koen Kooi @ 2010-09-12 8:11 UTC (permalink / raw)
To: openembedded-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04-09-10 05:14, Jean-Christophe PLAGNIOL-VILLARD wrote:
> add global OVERRIDES ${TARGET_SOC_FAMILY} and ${TARGET_ARCH}_${TARGET_SOC_FAMILY}
NAK, introducing a new override that combines 2 existing overrides with
a '_', is not allowed. And it isn't needed as Chase has tried to point
out already
You're also changing the overrides order, which needs a lot more testing
and ACKs from the people using it.
ANd furthermore you're renaming it to have more underscores (adding
'TARGET_', while it was decided at OEDEM that using underscored should
be avoided, since it's out override seperator.
regards,
Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFMjIsoMkyGM64RGpERAjInAJ9XtBKSH7FYLqxisI8qoG0QlDInMgCgjJ0T
NohqEHEYaIp6DB3mrMi+zlU=
=nCWu
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global
2010-09-12 8:11 ` Koen Kooi
@ 2010-09-13 2:45 ` Jean-Christophe PLAGNIOL-VILLARD
0 siblings, 0 replies; 24+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2010-09-13 2:45 UTC (permalink / raw)
To: openembedded-devel
On 10:11 Sun 12 Sep , Koen Kooi wrote:
> On 04-09-10 05:14, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > add global OVERRIDES ${TARGET_SOC_FAMILY} and ${TARGET_ARCH}_${TARGET_SOC_FAMILY}
>
> NAK, introducing a new override that combines 2 existing overrides with
> a '_', is not allowed. And it isn't needed as Chase has tried to point
> out already
except I do point case where it's really needed
and I'm working on adding new soc to oe and I do need it
>
> You're also changing the overrides order, which needs a lot more testing
> and ACKs from the people using it.
currently only TI package use it
and here the idea is not to change the order but extend it
>
> ANd furthermore you're renaming it to have more underscores (adding
> 'TARGET_', while it was decided at OEDEM that using underscored should
> be avoided, since it's out override seperator.
so we need to rename all TARGET_ to TARGET-???
Best Regards,
J.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global
2010-09-12 7:40 ` Frans Meulenbroeks
@ 2010-09-21 18:28 ` Denys Dmytriyenko
0 siblings, 0 replies; 24+ messages in thread
From: Denys Dmytriyenko @ 2010-09-21 18:28 UTC (permalink / raw)
To: openembedded-devel
On Sun, Sep 12, 2010 at 09:40:30AM +0200, Frans Meulenbroeks wrote:
> 2010/9/10 Denys Dmytriyenko <denis@denix.org>:
> :>
> > Frans,
> >
> > I guess then you haven't read the original discussion closely enough. Chase
> > only made a change to add existing SOC_FAMILY override into COMPATIBLE_MACHINE
> > variable... I keep repeating myself - SOC_FAMILY feature is about a year old.
> > It was introduced as part of a large merge from Arago. Here is the original
> > commit and some description:
> >
> > http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=b788499815bfc1974d4277c0a261b9a7c24aa816
Frans,
Sorry for the delay in replying - I was awfully busy lately.
And thank you for your continuing interest in SOC_FAMILY feature. :)
> I did some more research on this, as I could not recall any specific info.
> The patch you give above is from dec, so 9 months old.
Since it was a merge from arago, you can add couple more months for the
design and initial implementation... :)
> At that time it was not discussed at the mailing list as far as I can
> see. As the commit message said "recipes/ti: merge in updates"
> I (and I guess most of the non-ti devs) gave little attention to it.
>
> Also I did a quick grep on the source tree. Currently it is only used
> in the following files
>
> frans@linux-suse:~/oe/openembedded> grep -r SOC_FAMILY .
> ./conf/local.conf:SOC_FAMILY_local = "none"
> ./conf/distro/include/angstrom.inc:SOC_FAMILY ?= "Unknown"
> ./conf/distro/include/angstrom.inc:# Add FEED_ARCH and SOC_FAMILY to overrides
> ./conf/distro/include/angstrom.inc:OVERRIDES .= ":${FEED_ARCH}:${SOC_FAMILY}"
> ./conf/machine/include/dm6467.inc:SOC_FAMILY = "dm6467"
> ./conf/machine/include/omap3.inc:SOC_FAMILY = "omap3"
> ./conf/machine/include/omapl137.inc:SOC_FAMILY = "omapl137"
> ./conf/machine/include/dm365.inc:SOC_FAMILY = "dm365"
> ./conf/machine/include/dm6446.inc:SOC_FAMILY = "dm6446"
> ./conf/machine/include/dm355.inc:SOC_FAMILY = "dm355"
> ./conf/machine/include/omapl138.inc:SOC_FAMILY = "omapl138"
> ./recipes/ti/ti-linuxutils.inc: case ${SOC_FAMILY} in
> ./recipes/ti/ti-linuxutils.inc: if [ ${SOC_FAMILY} == "dm365" ] ; then
> ./recipes/ti/ti-local-power-manager.inc:# SOC_FAMILY configuration
> ./recipes/ti/ti-codec-engine.inc:# SOC_FAMILY configuration
> ./recipes/ti/ti-dsplink.inc:# SOC_FAMILY configuration
> ./classes/base.bbclass: this_soc_family =
> bb.data.getVar('SOC_FAMILY', d, 1)
That is not a correct assessment. As you see, SOC_FAMILY is a variable, which
being mostly used in overrides, so it is referenced not by variable name, but
by its value. See a more accurate grep below...
> Anyway, wrt the breakage, I'll push the patch for now as it has been
> out for review quite a while (and I got an ack and a looks good).
> If SOC_FAMILY is not desired we can also revert that one.
Thank you for taking care of the fix.
$ grep '[_:\"|]\(omap3\|omapl137\|omapl138\|dm355\|dm365\|dm6446\|dm6467\)[ :\"|]' . -r|grep -v -e '.patch' -e '.diff'
conf/machine/include/omapl137.inc:SOC_FAMILY = "omapl137"
conf/machine/include/dm6467.inc:SOC_FAMILY = "dm6467"
conf/machine/include/omap3.inc:SOC_FAMILY = "omap3"
conf/machine/include/dm355.inc:SOC_FAMILY = "dm355"
conf/machine/include/dm365.inc:SOC_FAMILY = "dm365"
conf/machine/include/omapl138.inc:SOC_FAMILY = "omapl138"
conf/machine/include/dm6446.inc:SOC_FAMILY = "dm6446"
conf/machine/nokia900.conf:SOC_FAMILY = "omap3"
conf/distro/include/angstrom-codec-engine-2.25.02-preferred-versions.inc:PREFERRED_VERSION_ti-codecs_omapl137 = "1_00_00"
conf/distro/include/angstrom-codec-engine-2.25.02-preferred-versions.inc:PREFERRED_VERSION_ti-codecs_omapl138 = "1_00_00"
conf/distro/include/angstrom-codec-engine-latestproduction-preferred-versions.inc:PREFERRED_VERSION_ti-codecs_omapl137 = "1_00_00"
conf/distro/include/angstrom-codec-engine-latestproduction-preferred-versions.inc:PREFERRED_VERSION_ti-codecs_omapl138 = "1_00_00"
conf/distro/include/angstrom-codec-engine-latest-preferred-versions.inc:PREFERRED_VERSION_ti-codecs_omapl137 = "1_00_00"
conf/distro/include/angstrom-codec-engine-latest-preferred-versions.inc:PREFERRED_VERSION_ti-codecs_omapl138 = "1_00_00"
conf/distro/include/angstrom-codec-engine-2.25.01-preferred-versions.inc:PREFERRED_VERSION_ti-codecs_omapl137 = "1_00_00"
conf/distro/include/angstrom-codec-engine-2.25.01-preferred-versions.inc:PREFERRED_VERSION_ti-codecs_omapl138 = "1_00_00"
docs/usermanual/chapters/common_use_cases.xml: "omap3" and this value can be used in overrides to prevent
recipes/ti/ti-audio-soc-example.inc:PLATFORM_da830-omapl137-evm = "omapl137"
recipes/ti/ti-audio-soc-example.inc:PLATFORM_da850-omapl138-evm = "omapl138"
recipes/ti/ti-codecs-omap3530_1.01.00.bb:DSPSUFFIX_omap3 = "x64P"
recipes/ti/ti-dmai.inc:DEPENDS_append_dm6446 = " ti-codecs-dm6446 ti-dspbios ti-cgt6x ti-linuxutils"
recipes/ti/ti-dmai.inc:DEPENDS_append_dm6467 = " ti-codecs-dm6467 ti-dspbios ti-cgt6x ti-linuxutils"
recipes/ti/ti-dmai.inc:DEPENDS_append_omap3 = " ti-codecs-omap3530 ti-dspbios ti-cgt6x ti-linuxutils"
recipes/ti/ti-dmai.inc:DEPENDS_append_dm355 = " ti-codecs-dm355"
recipes/ti/ti-dmai.inc:DEPENDS_append_dm365 = " ti-codecs-dm365"
recipes/ti/ti-dmai.inc:DEPENDS_append_omapl137 = " ti-codecs-omapl137 ti-dspbios ti-cgt6x ti-linuxutils"
recipes/ti/ti-dmai.inc:DEPENDS_append_omapl138 = " ti-codecs-omapl138 ti-dspbios ti-cgt6x ti-linuxutils"
recipes/ti/ti-dmai.inc:DMAIPLATFORM_dm6446 = "dm6446_al"
recipes/ti/ti-dmai.inc:DMAIPLATFORM_dm6467 = "dm6467_al"
recipes/ti/ti-dmai.inc:DMAIPLATFORM_omap3 = "o3530_al"
recipes/ti/ti-dmai.inc:DMAIPLATFORM_dm355 = "dm355_al"
recipes/ti/ti-dmai.inc:DMAIPLATFORM_dm365 = "dm365_al"
recipes/ti/ti-dmai.inc:DMAIPLATFORM_omapl137 = "ol137_al"
recipes/ti/ti-dmai.inc:DMAIPLATFORM_omapl138 = "ol138_al"
recipes/ti/ti-dmai.inc:#GPPOS_dm355 = "LINUX_GCC"
recipes/ti/ti-dmai.inc:#GPPOS_dm365 = "LINUX_GCC"
recipes/ti/ti-dmai.inc:RDEPENDS_ti-dmai-apps_dm6446 += "ti-codecs-dm6446-server ti-cmem-module ti-dsplink-module"
recipes/ti/ti-dmai.inc:RDEPENDS_ti-dmai-apps_dm6467 += "ti-codecs-dm6467 ti-cmem-module ti-dsplink-module"
recipes/ti/ti-dmai.inc:RDEPENDS_ti-dmai-apps_omap3 += "ti-codecs-omap3530-server ti-cmem-module ti-dsplink-module ti-lpm-module ti-sdma-module"
recipes/ti/ti-dmai.inc:RDEPENDS_ti-dmai-apps_dm355 += "ti-codecs-dm355 ti-cmem-module ti-dm355mm-module"
recipes/ti/ti-dmai.inc:RDEPENDS_ti-dmai-apps_dm365 += "ti-codecs-dm365 ti-cmem-module ti-dm365mm-module ti-edma-module ti-irq-module"
recipes/ti/ti-dmai.inc:RDEPENDS_ti-dmai-apps_omapl137 += "ti-codecs-omapl137-server ti-cmem-module ti-dsplink-module"
recipes/ti/ti-dmai.inc:RDEPENDS_ti-dmai-apps_omapl138 += "ti-codecs-omapl138-server ti-cmem-module ti-dsplink-module"
recipes/ti/gstreamer-ti.inc:PLATFORM_dm6446 = "dm6446"
recipes/ti/gstreamer-ti.inc:PLATFORM_dm6467 = "dm6467"
recipes/ti/gstreamer-ti.inc:PLATFORM_omap3 = "omap3530"
recipes/ti/gstreamer-ti.inc:PLATFORM_dm355 = "dm355"
recipes/ti/gstreamer-ti.inc:PLATFORM_dm365 = "dm365"
recipes/ti/gstreamer-ti.inc:PLATFORM_omapl137 = "omapl137"
recipes/ti/gstreamer-ti.inc:PLATFORM_omapl138 = "omapl138"
recipes/ti/gstreamer-ti.inc:XDC_PLATFORM_dm6446 = "ti.platforms.evmDM6446"
recipes/ti/gstreamer-ti.inc:XDC_PLATFORM_dm6467 = "ti.platforms.evmDM6467"
recipes/ti/gstreamer-ti.inc:XDC_PLATFORM_omap3 = "ti.platforms.evm3530"
recipes/ti/gstreamer-ti.inc:XDC_PLATFORM_dm355 = "ti.platforms.evmDM355"
recipes/ti/gstreamer-ti.inc:XDC_PLATFORM_dm365 = "ti.platforms.evmDM365"
recipes/ti/gstreamer-ti.inc:XDC_PLATFORM_omapl137 = "ti.platforms.evmOMAPL137"
recipes/ti/gstreamer-ti.inc:XDC_PLATFORM_omapl138 = "ti.platforms.evmOMAPL138"
recipes/ti/gstreamer-ti.inc:RRECOMMENDS_${PN}_append_dm6446 += "ti-codecs-dm6446-server ti-cmem-module ti-dsplink-module"
recipes/ti/gstreamer-ti.inc:RRECOMMENDS_${PN}_append_dm6467 += "ti-codecs-dm6467 ti-cmem-module ti-dsplink-module"
recipes/ti/gstreamer-ti.inc:RRECOMMENDS_${PN}_append_omap3 += "ti-codecs-omap3530-server ti-cmem-module ti-dsplink-module ti-lpm-module ti-sdma-module"
recipes/ti/gstreamer-ti.inc:RRECOMMENDS_${PN}_append_dm355 += "ti-codecs-dm355 ti-cmem-module ti-dm355mm-module"
recipes/ti/gstreamer-ti.inc:RRECOMMENDS_${PN}_append_dm365 += "ti-codecs-dm365 ti-cmem-module ti-dm365mm-module ti-edma-module ti-irq-module"
recipes/ti/gstreamer-ti.inc:RRECOMMENDS_${PN}_append_omapl137 += "ti-codecs-omapl137-server ti-cmem-module ti-dsplink-module"
recipes/ti/gstreamer-ti.inc:RRECOMMENDS_${PN}_append_omapl138 += "ti-codecs-omapl138-server ti-cmem-module ti-dsplink-module"
recipes/ti/gstreamer-ti_svn.bb:SRC_URI_append_dm365 = " file://loadmodules.sh"
recipes/ti/gstreamer-ti_svn.bb:SRC_URI_append_omapl137 = " file://loadmodules.sh"
recipes/ti/gstreamer-ti_svn.bb:SRC_URI_append_omapl138 = " file://loadmodules.sh "
recipes/ti/gstreamer-ti_svn.bb:SRC_URI_append_omap3 = " file://loadmodules.sh "
recipes/ti/ti-codecs-dm6467_1.00.00.03.bb:DSPSUFFIX_dm6467 = "x64P"
recipes/ti/ti-codec-engine.inc:DEPENDS_append_dm6446 = " ti-dspbios ti-dsplink ti-local-power-manager ti-cgt6x ti-biosutils ti-edma3lld"
recipes/ti/ti-codec-engine.inc:DEPENDS_append_dm6467 = " ti-dspbios ti-dsplink ti-cgt6x ti-biosutils ti-edma3lld"
recipes/ti/ti-codec-engine.inc:DEPENDS_append_omapl137 = " ti-dspbios ti-dsplink ti-cgt6x ti-biosutils ti-edma3lld"
recipes/ti/ti-codec-engine.inc:DEPENDS_append_omapl138 = " ti-dspbios ti-dsplink ti-cgt6x ti-biosutils ti-edma3lld"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESDEVICES_dm6446 = "DM6446"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESDEVICES_dm6467 = "DM6467"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESDEVICES_omap3 = "OMAP3530"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESDEVICES_dm355 = "DM355"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESDEVICES_dm365 = "DM365"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESDEVICES_omapl137 = "OMAPL137"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESDEVICES_omapl138 = "OMAPL138"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESGPPOS_dm6446 = "LINUX_GCC"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESGPPOS_dm6467 = "LINUX_GCC"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESGPPOS_omap3 = "LINUX_GCC"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESGPPOS_dm355 = "LINUX_GCC"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESGPPOS_dm365 = "LINUX_GCC"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESGPPOS_omapl137 = "LINUX_GCC"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESGPPOS_omapl138 = "LINUX_GCC"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESPROGRAMS_dm6446 = "APP_CLIENT DSP_SERVER"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESPROGRAMS_dm6467 = "APP_CLIENT DSP_SERVER"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESPROGRAMS_omap3 = "APP_CLIENT DSP_SERVER"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESPROGRAMS_dm355 = "APP_LOCAL"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESPROGRAMS_dm365 = "APP_LOCAL"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESPROGRAMS_omapl137 = "APP_CLIENT DSP_SERVER"
recipes/ti/ti-codec-engine.inc:CEEXAMPLESPROGRAMS_omapl138 = "APP_CLIENT DSP_SERVER"
recipes/ti/ti-codec-engine.inc:RDEPENDS_ti-codec-engine-examples_append_dm6446 = " ti-dsplink-module ti-lpm-module"
recipes/ti/ti-codec-engine.inc:RDEPENDS_ti-codec-engine-examples_append_dm6467 = " ti-dsplink-module"
recipes/ti/ti-codec-engine.inc:RDEPENDS_ti-codec-engine-examples_append_omap3 = " ti-dsplink-module ti-lpm-module"
recipes/ti/ti-codec-engine.inc:RDEPENDS_ti-codec-engine-examples_append_omapl137 = " ti-dsplink-module"
recipes/ti/ti-codec-engine.inc:RDEPENDS_ti-codec-engine-examples_append_omapl138 = " ti-dsplink-module"
recipes/ti/ti-codecs-omapl137_1.00.00.bb:DSPSUFFIX_omapl137 = "x64P"
recipes/ti/ti-dvsdk-demos.inc:DEMOSPLATFORM_dm355 = "dm355"
recipes/ti/ti-dvsdk-demos.inc:DEMOSPLATFORM_dm365 = "dm365"
recipes/ti/ti-dvsdk-demos.inc:DEMOSPLATFORM_dm6446 = "dm6446"
recipes/ti/ti-dvsdk-demos.inc:DEMOSPLATFORM_dm6467 = "dm6467"
recipes/ti/ti-dvsdk-demos.inc:DEMOSPLATFORM_omap3 = "omap3530"
recipes/ti/ti-dvsdk-demos.inc:DEMOSPLATFORM_omapl137 = "ol137"
recipes/ti/ti-dvsdk-demos.inc:DEMOSPLATFORM_omapl138 = "ol138"
recipes/ti/ti-dvsdk-demos.inc:RDEPENDS_ti-dvsdk-demos_dm355 += "ti-dm355mm-module ti-cmem-module alsa-lib libpng freetype jpeg libpng12"
recipes/ti/ti-dvsdk-demos.inc:RDEPENDS_ti-dvsdk-demos_dm365 += "ti-dm365mm-module ti-cmem-module alsa-lib libpng freetype jpeg ti-codecs-dm365 ti-edma-module ti-irq-module libpng12"
recipes/ti/ti-linuxutils.inc: if [ ${SOC_FAMILY} == "dm365" ] ; then
recipes/ti/ti-dsplink.inc:DSPLINKPLATFORM_dm6446 = "DAVINCI"
recipes/ti/ti-dsplink.inc:DSPLINKPLATFORM_dm6467 = "DAVINCIHD"
recipes/ti/ti-dsplink.inc:DSPLINKPLATFORM_omapl137 = "OMAPL1XX"
recipes/ti/ti-dsplink.inc:DSPLINKPLATFORM_omapl138 = "OMAPL138"
recipes/ti/ti-dsplink.inc:DSPLINKPLATFORM_omap3 = "OMAP3530"
recipes/ti/ti-dsplink.inc:DSPLINKDSPCFG_dm6446 = "DM6446GEMSHMEM"
recipes/ti/ti-dsplink.inc:DSPLINKDSPCFG_dm6467 = "DM6467GEMSHMEM"
recipes/ti/ti-dsplink.inc:DSPLINKDSPCFG_omapl137 = "OMAPL1XXGEMSHMEM"
recipes/ti/ti-dsplink.inc:DSPLINKDSPCFG_omapl138 = "OMAPL138GEMSHMEM"
recipes/ti/ti-dsplink.inc:DSPLINKDSPCFG_omap3 = "OMAP3530SHMEM"
recipes/ti/ti-dsplink.inc:DSPLINKDSP_dm6446 = "DM6446GEM_0"
recipes/ti/ti-dsplink.inc:DSPLINKDSP_dm6467 = "DM6467GEM_0"
recipes/ti/ti-dsplink.inc:DSPLINKDSP_omapl137 = "OMAPL1XXGEM_0"
recipes/ti/ti-dsplink.inc:DSPLINKDSP_omapl138 = "OMAPL138GEM_0"
recipes/ti/ti-dsplink.inc:DSPLINKDSP_omap3 = "OMAP3530_0"
recipes/ti/ti-dsplink.inc:DSPLINKGPPOS_dm6446 = "DM6446LSP"
recipes/ti/ti-dsplink.inc:DSPLINKGPPOS_dm6467 = "DM6467LSP"
recipes/ti/ti-dsplink.inc:DSPLINKGPPOS_omapl137 = "ARM"
recipes/ti/ti-dsplink.inc:DSPLINKGPPOS_omapl138 = "ARM"
recipes/ti/ti-dsplink.inc:DSPLINKGPPOS_omap3 = "OMAPLSP"
recipes/ti/ti-dsplink.inc:RDEPENDS_ti-dsplink-examples_append_omap3 += " ti-lpm-module ti-lpm-utils"
recipes/ti/ti-codecs-omapl138_1.00.00.bb:DSPSUFFIX_omapl138 = "x64P"
recipes/ti/ti-codecs-omap3530_1.00.01.bb:DSPSUFFIX_omap3 = "x64P"
recipes/ti/ti-codec-engine_2.25.01.06.bb:SRC_URI_append_dm365 += "file://loadmodules.sh"
recipes/ti/ti-dmai_svn.bb:DMAIBRANCH_dm6446 = "trunk"
recipes/ti/ti-dmai_svn.bb:DMAIBRANCH_dm6467 = "branches/GITPSP_INT_101009"
recipes/ti/ti-dmai_svn.bb:DMAIBRANCH_omap3 = "trunk"
recipes/ti/ti-dmai_svn.bb:DMAIBRANCH_dm355 = "branches/GITPSP_INT_101009"
recipes/ti/ti-dmai_svn.bb:DMAIBRANCH_dm365 = "branches/GITPSP_INT_101009"
recipes/ti/ti-dmai_svn.bb:DMAIBRANCH_omapl137 = "trunk"
recipes/ti/ti-dmai_svn.bb:DMAIBRANCH_omapl138 = "trunk"
recipes/ti/ti-dmai_svn.bb:SRCREV_dm6446 = "423"
recipes/ti/ti-dmai_svn.bb:SRCREV_dm6467 = "441"
recipes/ti/ti-dmai_svn.bb:SRCREV_omap3 = "423"
recipes/ti/ti-dmai_svn.bb:SRCREV_dm355 = "424"
recipes/ti/ti-dmai_svn.bb:SRCREV_dm365 = "441"
recipes/ti/ti-dmai_svn.bb:SRCREV_omapl137 = "423"
recipes/ti/ti-dmai_svn.bb:SRCREV_omapl138 = "423"
recipes/ti/ti-local-power-manager.inc:LPMDSPPOWERSOC_omap3 = "omap3530"
recipes/ti/ti-local-power-manager.inc:LPMDSPPOWERSOC_dm6446 = "dm6446"
recipes/ti/ti-local-power-manager.inc:XDC_PLATFORM_dm6446 = "ti.platforms.evmDM6446"
recipes/ti/ti-local-power-manager.inc:XDC_PLATFORM_omap3 = "ti.platforms.evm3530"
recipes/ti/ti-codecs-dm6446_2.05.00.00.bb:DSPSUFFIX_dm6446 = "x64P"
recipes/ti/ti-codecs-dm6467_1.00.00.08.bb:DSPSUFFIX_dm6467 = "x64P"
recipes/ti/ti-paths.inc:DSPSUFFIX_omapl137 = "x674"
recipes/ti/ti-paths.inc:DSPSUFFIX_omapl138 = "x674"
recipes/tasks/task-arago-toolchain-dvsdk-host.bb:DVSDK_HOST_PACKAGE_dm6446 = "\
recipes/tasks/task-arago-toolchain-dvsdk-host.bb:DVSDK_HOST_PACKAGE_dm6467 = "\
recipes/tasks/task-arago-toolchain-dvsdk-host.bb:DVSDK_HOST_PACKAGE_omap3 = "\
recipes/xorg-xserver/xserver-xorg-conf_0.1.bb:RDEPENDS_omap3 = "xf86-video-omapfb"
recipes/egl/egl.inc:COMPATIBLE_MACHINE = "omap3"
recipes/powertop/powertop_svn.bb:CFLAGS_append_omap3 = " -DOMAP3"
recipes/kexecboot/linux-kexecboot_2.6.32.bb:S_omap3 = "${WORKDIR}/git"
recipes/kexecboot/linux-kexecboot_2.6.32.bb:DEFAULT_PREFERENCE_omap3 = "1"
recipes/kexecboot/linux-kexecboot_2.6.32.bb:SRC_URI_append_omap3 = " git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git;protocol=git;rev=6833f1a8cdcb65a370f898bde6b6af63f81962df \
recipes/kexecboot/kexecboot.inc:EXTRA_OECONF_omap3 = "--with-uimage"
recipes/linux/linux-davinci_git.bb:SRCREV_dm355 = ${ARAGO_DM_REV}
recipes/linux/linux-davinci_git.bb:SRCREV_dm365 = ${ARAGO_DM_REV}
recipes/linux/linux-davinci_git.bb:SRCREV_dm6446 = ${ARAGO_DM_REV}
recipes/linux/linux-davinci_git.bb:SRCREV_dm6467 = ${ARAGO_DM_REV}
recipes/linux/linux-davinci_git.bb:PV_dm355 = ${ARAGO_DM_PV}
recipes/linux/linux-davinci_git.bb:PV_dm365 = ${ARAGO_DM_PV}
recipes/linux/linux-davinci_git.bb:PV_dm6446 = ${ARAGO_DM_PV}
recipes/linux/linux-davinci_git.bb:PV_dm6467 = ${ARAGO_DM_PV}
recipes/linux/linux-davinci_git.bb:BRANCH_dm355 = ${ARAGO_DM_BR}
recipes/linux/linux-davinci_git.bb:BRANCH_dm365 = ${ARAGO_DM_BR}
recipes/linux/linux-davinci_git.bb:BRANCH_dm6446 = ${ARAGO_DM_BR}
recipes/linux/linux-davinci_git.bb:BRANCH_dm6467 = ${ARAGO_DM_BR}
recipes/linux/linux-davinci_git.bb:SRC_URI_append_dm355 = ${ARAGO_DM_URI}
recipes/linux/linux-davinci_git.bb:SRC_URI_append_dm365 = ${ARAGO_DM_URI}
recipes/linux/linux-davinci_git.bb:SRC_URI_append_dm6446 = ${ARAGO_DM_URI}
recipes/linux/linux-davinci_git.bb:SRC_URI_append_dm6467 = ${ARAGO_DM_URI}
recipes/jack/jack_0.118.0.bb:PACKAGE_ARCH_omap3 = "${MACHINE_ARCH}"
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2010-09-21 18:29 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-09-03 11:12 How to extend SRC_URI_append? Jean-Christophe PLAGNIOL-VILLARD
2010-09-03 14:44 ` Chris Larson
2010-09-03 16:47 ` Jean-Christophe PLAGNIOL-VILLARD
2010-09-03 16:59 ` Jean-Christophe PLAGNIOL-VILLARD
2010-09-03 20:34 ` Maupin, Chase
2010-09-03 21:45 ` Khem Raj
2010-09-04 3:17 ` Jean-Christophe PLAGNIOL-VILLARD
2010-09-04 11:20 ` Jean-Christophe PLAGNIOL-VILLARD
2010-09-04 3:14 ` [PATCH] rename SOC_FAMILY to TARGET_SOC_FAMILY and make it global Jean-Christophe PLAGNIOL-VILLARD
2010-09-04 7:45 ` Frans Meulenbroeks
2010-09-04 8:20 ` Frans Meulenbroeks
2010-09-07 14:21 ` Maupin, Chase
2010-09-08 5:58 ` Frans Meulenbroeks
2010-09-10 18:57 ` Denys Dmytriyenko
2010-09-10 20:32 ` Tom Rini
2010-09-10 20:43 ` Denys Dmytriyenko
2010-09-11 9:19 ` Frans Meulenbroeks
2010-09-12 7:40 ` Frans Meulenbroeks
2010-09-21 18:28 ` Denys Dmytriyenko
2010-09-07 14:43 ` Maupin, Chase
2010-09-08 3:47 ` Jean-Christophe PLAGNIOL-VILLARD
2010-09-09 9:26 ` Phil Blundell
2010-09-12 8:11 ` Koen Kooi
2010-09-13 2:45 ` Jean-Christophe PLAGNIOL-VILLARD
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.