* [PATCH 1/3] external-csl: add mapping for powerpc-nf @ 2012-03-27 19:51 Christopher Larson 2012-03-27 19:51 ` [PATCH 2/3] powerpc e500: set -mfloat-gprs=double Christopher Larson 2012-03-27 19:51 ` [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf Christopher Larson 0 siblings, 2 replies; 20+ messages in thread From: Christopher Larson @ 2012-03-27 19:51 UTC (permalink / raw) To: openembedded-core; +Cc: Christopher Larson, edmar From: Christopher Larson <chris_larson@mentor.com> This ensures we get the files from the correct multilib dir in the external toolchain when using powerpc with soft-float. Signed-off-by: Christopher Larson <chris_larson@mentor.com> --- meta/conf/distro/include/tcmode-external-csl.inc | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/meta/conf/distro/include/tcmode-external-csl.inc b/meta/conf/distro/include/tcmode-external-csl.inc index 7bb8453..1fc366c 100644 --- a/meta/conf/distro/include/tcmode-external-csl.inc +++ b/meta/conf/distro/include/tcmode-external-csl.inc @@ -48,6 +48,7 @@ def csl_target_core(d): 'i686': 'sgxx-glibc', 'mips': 'mips32', 'mipsel': 'el', + 'powerpc-nf': 'nof', 'ppce500': 'te500v1', 'ppce500mc': 'te500mc', 'ppce500v2': 'te500v2', -- 1.7.7 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PATCH 2/3] powerpc e500: set -mfloat-gprs=double 2012-03-27 19:51 [PATCH 1/3] external-csl: add mapping for powerpc-nf Christopher Larson @ 2012-03-27 19:51 ` Christopher Larson 2012-04-07 5:40 ` Khem Raj 2012-03-27 19:51 ` [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf Christopher Larson 1 sibling, 1 reply; 20+ messages in thread From: Christopher Larson @ 2012-03-27 19:51 UTC (permalink / raw) To: openembedded-core; +Cc: Christopher Larson, edmar From: Christopher Larson <chris_larson@mentor.com> Use of FPRs instead of GPRs is incompatible with e500/SPE, so let's be explicit about the use of GPRs to avoid potential errors. For example, with the Sourcery G++ toolchain, one can hit: conftest.c:1:0: error: E500 and FPRs not supported. Signed-off-by: Christopher Larson <chris_larson@mentor.com> --- meta/conf/machine/include/tune-ppce500.inc | 2 +- meta/conf/machine/include/tune-ppce500v2.inc | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/conf/machine/include/tune-ppce500.inc b/meta/conf/machine/include/tune-ppce500.inc index 1326720..feb1967 100644 --- a/meta/conf/machine/include/tune-ppce500.inc +++ b/meta/conf/machine/include/tune-ppce500.inc @@ -7,7 +7,7 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500", "-mcpu=8540", " TUNE_PKGARCH_tune-ppce500 = "ppce500" TUNEVALID[spe] = "Enable SPE ABI extensions" -TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe", "", d)}" +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe -mfloat-gprs=double", "", d)}" TARGET_FPU = "ppc-efs" diff --git a/meta/conf/machine/include/tune-ppce500v2.inc b/meta/conf/machine/include/tune-ppce500v2.inc index e7b51c6..f0158d0 100644 --- a/meta/conf/machine/include/tune-ppce500v2.inc +++ b/meta/conf/machine/include/tune-ppce500v2.inc @@ -7,7 +7,7 @@ TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", "-mcpu=8548", TUNE_PKGARCH_tune-ppce500v2 = "ppce500v2" TUNEVALID[spe] = "Enable SPE ABI extensions" -TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe", "", d)}" +TUNE_CCARGS += '${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe -mfloat-gprs=double", "", d)}' TARGET_FPU = "ppc-efd" -- 1.7.7 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH 2/3] powerpc e500: set -mfloat-gprs=double 2012-03-27 19:51 ` [PATCH 2/3] powerpc e500: set -mfloat-gprs=double Christopher Larson @ 2012-04-07 5:40 ` Khem Raj 2012-04-07 16:12 ` Chris Larson 0 siblings, 1 reply; 20+ messages in thread From: Khem Raj @ 2012-04-07 5:40 UTC (permalink / raw) To: openembedded-core -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/27/2012 12:51 PM, Christopher Larson wrote: > From: Christopher Larson <chris_larson@mentor.com> > > Use of FPRs instead of GPRs is incompatible with e500/SPE, so let's > be explicit about the use of GPRs to avoid potential errors. For > example, with the Sourcery G++ toolchain, one can hit: > conftest.c:1:0: error: E500 and FPRs not supported. > > Signed-off-by: Christopher Larson <chris_larson@mentor.com> --- > meta/conf/machine/include/tune-ppce500.inc | 2 +- > meta/conf/machine/include/tune-ppce500v2.inc | 2 +- 2 files > changed, 2 insertions(+), 2 deletions(-) > > diff --git a/meta/conf/machine/include/tune-ppce500.inc > b/meta/conf/machine/include/tune-ppce500.inc index 1326720..feb1967 > 100644 --- a/meta/conf/machine/include/tune-ppce500.inc +++ > b/meta/conf/machine/include/tune-ppce500.inc @@ -7,7 +7,7 @@ > TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500", > "-mcpu=8540", " TUNE_PKGARCH_tune-ppce500 = "ppce500" > > TUNEVALID[spe] = "Enable SPE ABI extensions" -TUNE_CCARGS += > "${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe", > "", d)}" +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", > "spe", "-mabi=spe -mspe -mfloat-gprs=double", "", d)}" > IIRC e500v1 does not have double precision floating point support. > TARGET_FPU = "ppc-efs" > > diff --git a/meta/conf/machine/include/tune-ppce500v2.inc > b/meta/conf/machine/include/tune-ppce500v2.inc index > e7b51c6..f0158d0 100644 --- > a/meta/conf/machine/include/tune-ppce500v2.inc +++ > b/meta/conf/machine/include/tune-ppce500v2.inc @@ -7,7 +7,7 @@ > TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500v2", > "-mcpu=8548", TUNE_PKGARCH_tune-ppce500v2 = "ppce500v2" > > TUNEVALID[spe] = "Enable SPE ABI extensions" -TUNE_CCARGS += > "${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe", > "", d)}" +TUNE_CCARGS += '${@bb.utils.contains("TUNE_FEATURES", > "spe", "-mabi=spe -mspe -mfloat-gprs=double", "", d)}' > > TARGET_FPU = "ppc-efd" > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9/0zkACgkQuwUzVZGdMxTMYQCfbnz0j7H+ypE8hRTHoQOuLaCR PcwAn3H5jeibd9N4TzKQdyYh9MiwV0F9 =J93c -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 2/3] powerpc e500: set -mfloat-gprs=double 2012-04-07 5:40 ` Khem Raj @ 2012-04-07 16:12 ` Chris Larson 0 siblings, 0 replies; 20+ messages in thread From: Chris Larson @ 2012-04-07 16:12 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Fri, Apr 6, 2012 at 10:40 PM, Khem Raj <raj.khem@gmail.com> wrote: > On 03/27/2012 12:51 PM, Christopher Larson wrote: >> From: Christopher Larson <chris_larson@mentor.com> >> >> Use of FPRs instead of GPRs is incompatible with e500/SPE, so let's >> be explicit about the use of GPRs to avoid potential errors. For >> example, with the Sourcery G++ toolchain, one can hit: >> conftest.c:1:0: error: E500 and FPRs not supported. >> >> Signed-off-by: Christopher Larson <chris_larson@mentor.com> --- >> meta/conf/machine/include/tune-ppce500.inc | 2 +- >> meta/conf/machine/include/tune-ppce500v2.inc | 2 +- 2 files >> changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/meta/conf/machine/include/tune-ppce500.inc >> b/meta/conf/machine/include/tune-ppce500.inc index 1326720..feb1967 >> 100644 --- a/meta/conf/machine/include/tune-ppce500.inc +++ >> b/meta/conf/machine/include/tune-ppce500.inc @@ -7,7 +7,7 @@ >> TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500", >> "-mcpu=8540", " TUNE_PKGARCH_tune-ppce500 = "ppce500" >> >> TUNEVALID[spe] = "Enable SPE ABI extensions" -TUNE_CCARGS += >> "${@bb.utils.contains("TUNE_FEATURES", "spe", "-mabi=spe -mspe", >> "", d)}" +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", >> "spe", "-mabi=spe -mspe -mfloat-gprs=double", "", d)}" >> > > IIRC e500v1 does not have double precision floating point support. Yeah, I know, I sent a later patch to fix it, but Mark already fixed it in his tuning rework. :) -- Christopher Larson ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf 2012-03-27 19:51 [PATCH 1/3] external-csl: add mapping for powerpc-nf Christopher Larson 2012-03-27 19:51 ` [PATCH 2/3] powerpc e500: set -mfloat-gprs=double Christopher Larson @ 2012-03-27 19:51 ` Christopher Larson 2012-03-27 20:22 ` Mark Hatle 1 sibling, 1 reply; 20+ messages in thread From: Christopher Larson @ 2012-03-27 19:51 UTC (permalink / raw) To: openembedded-core; +Cc: Christopher Larson, edmar From: Christopher Larson <chris_larson@mentor.com> This allows setting DEFAULTTUNE to powerpc or powerpc-nf rather than just the more specific cpu/machine tuning. Signed-off-by: Christopher Larson <chris_larson@mentor.com> --- meta/conf/machine/include/powerpc/arch-powerpc.inc | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc b/meta/conf/machine/include/powerpc/arch-powerpc.inc index c5fd6b7..3438b46 100644 --- a/meta/conf/machine/include/powerpc/arch-powerpc.inc +++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc @@ -26,6 +26,8 @@ AVAILTUNES += "powerpc powerpc-nf" TUNE_FEATURES_tune-powerpc-nf ?= "m32 fpu-soft" BASE_LIB_tune-powerpc-nf = "lib" PACKAGE_EXTRA_ARCHS_tune-powerpc-nf = "powerpc-nf" +TUNE_PKGARCH_tune-powerpc-nf = "powerpc-nf" TUNE_FEATURES_tune-powerpc ?= "m32 fpu-hard" BASE_LIB_tune-powerpc = "lib" PACKAGE_EXTRA_ARCHS_tune-powerpc = "powerpc" +TUNE_PKGARCH_tune-powerpc = "powerpc" -- 1.7.7 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf 2012-03-27 19:51 ` [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf Christopher Larson @ 2012-03-27 20:22 ` Mark Hatle 2012-03-27 21:05 ` Chris Larson 0 siblings, 1 reply; 20+ messages in thread From: Mark Hatle @ 2012-03-27 20:22 UTC (permalink / raw) To: openembedded-core Patch 1 and 2 look fine, but I have questions on this one.... On 3/27/12 2:51 PM, Christopher Larson wrote: > From: Christopher Larson<chris_larson@mentor.com> > > This allows setting DEFAULTTUNE to powerpc or powerpc-nf rather than just the > more specific cpu/machine tuning. > > Signed-off-by: Christopher Larson<chris_larson@mentor.com> > --- > meta/conf/machine/include/powerpc/arch-powerpc.inc | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc b/meta/conf/machine/include/powerpc/arch-powerpc.inc > index c5fd6b7..3438b46 100644 > --- a/meta/conf/machine/include/powerpc/arch-powerpc.inc > +++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc > @@ -26,6 +26,8 @@ AVAILTUNES += "powerpc powerpc-nf" > TUNE_FEATURES_tune-powerpc-nf ?= "m32 fpu-soft" > BASE_LIB_tune-powerpc-nf = "lib" > PACKAGE_EXTRA_ARCHS_tune-powerpc-nf = "powerpc-nf" > +TUNE_PKGARCH_tune-powerpc-nf = "powerpc-nf" > TUNE_FEATURES_tune-powerpc ?= "m32 fpu-hard" > BASE_LIB_tune-powerpc = "lib" > PACKAGE_EXTRA_ARCHS_tune-powerpc = "powerpc" > +TUNE_PKGARCH_tune-powerpc = "powerpc" Why is the above necessary? TUNE_PKGARCH_append is set to "${PPCPKGSFX_FPU}" PPCPKGSFX_FP is set to either '' or '-nf' based on the existance of fpu-soft. TUNE_PKGARCH is set by a number of the PowerPC tuning files... If you are looking for generic PowerPC there should be something setting TUNE_PKGARCH to "powerpc" (or "powerpc64" in the default cases...) --Mark ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf 2012-03-27 20:22 ` Mark Hatle @ 2012-03-27 21:05 ` Chris Larson 2012-03-27 21:50 ` Mark Hatle 0 siblings, 1 reply; 20+ messages in thread From: Chris Larson @ 2012-03-27 21:05 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Tue, Mar 27, 2012 at 1:22 PM, Mark Hatle <mark.hatle@windriver.com> wrote: > Patch 1 and 2 look fine, but I have questions on this one.... > > > On 3/27/12 2:51 PM, Christopher Larson wrote: >> >> From: Christopher Larson<chris_larson@mentor.com> >> >> This allows setting DEFAULTTUNE to powerpc or powerpc-nf rather than just >> the >> more specific cpu/machine tuning. >> >> Signed-off-by: Christopher Larson<chris_larson@mentor.com> >> --- >> meta/conf/machine/include/powerpc/arch-powerpc.inc | 2 ++ >> 1 files changed, 2 insertions(+), 0 deletions(-) >> >> diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc >> b/meta/conf/machine/include/powerpc/arch-powerpc.inc >> index c5fd6b7..3438b46 100644 >> --- a/meta/conf/machine/include/powerpc/arch-powerpc.inc >> +++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc >> @@ -26,6 +26,8 @@ AVAILTUNES += "powerpc powerpc-nf" >> TUNE_FEATURES_tune-powerpc-nf ?= "m32 fpu-soft" >> BASE_LIB_tune-powerpc-nf = "lib" >> PACKAGE_EXTRA_ARCHS_tune-powerpc-nf = "powerpc-nf" >> +TUNE_PKGARCH_tune-powerpc-nf = "powerpc-nf" >> TUNE_FEATURES_tune-powerpc ?= "m32 fpu-hard" >> BASE_LIB_tune-powerpc = "lib" >> PACKAGE_EXTRA_ARCHS_tune-powerpc = "powerpc" >> +TUNE_PKGARCH_tune-powerpc = "powerpc" > > > Why is the above necessary? > > TUNE_PKGARCH_append is set to "${PPCPKGSFX_FPU}" > > PPCPKGSFX_FP is set to either '' or '-nf' based on the existance of > fpu-soft. > > TUNE_PKGARCH is set by a number of the PowerPC tuning files... If you are > looking for generic PowerPC there should be something setting TUNE_PKGARCH > to "powerpc" (or "powerpc64" in the default cases...) This is what I'm saying. If you want to target generic powerpc, you have to force TUNE_PKGARCH, as the generic don't have TUNE_PKGARCH_tune- definitions. It seems to me in most cases you can set DEFAULTTUNE and include an appropriate tune file and not need to set TUNE_PKGARCH directly, which is not the case for the generic ones. Was it not the intent that this was the case? Should every MACHINE have to override TUNE_PKGARCH? -- Christopher Larson ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf 2012-03-27 21:05 ` Chris Larson @ 2012-03-27 21:50 ` Mark Hatle 2012-03-27 21:57 ` Christopher Larson 0 siblings, 1 reply; 20+ messages in thread From: Mark Hatle @ 2012-03-27 21:50 UTC (permalink / raw) To: openembedded-core On 3/27/12 4:05 PM, Chris Larson wrote: > On Tue, Mar 27, 2012 at 1:22 PM, Mark Hatle<mark.hatle@windriver.com> wrote: >> Patch 1 and 2 look fine, but I have questions on this one.... >> >> >> On 3/27/12 2:51 PM, Christopher Larson wrote: >>> >>> From: Christopher Larson<chris_larson@mentor.com> >>> >>> This allows setting DEFAULTTUNE to powerpc or powerpc-nf rather than just >>> the >>> more specific cpu/machine tuning. >>> >>> Signed-off-by: Christopher Larson<chris_larson@mentor.com> >>> --- >>> meta/conf/machine/include/powerpc/arch-powerpc.inc | 2 ++ >>> 1 files changed, 2 insertions(+), 0 deletions(-) >>> >>> diff --git a/meta/conf/machine/include/powerpc/arch-powerpc.inc >>> b/meta/conf/machine/include/powerpc/arch-powerpc.inc >>> index c5fd6b7..3438b46 100644 >>> --- a/meta/conf/machine/include/powerpc/arch-powerpc.inc >>> +++ b/meta/conf/machine/include/powerpc/arch-powerpc.inc >>> @@ -26,6 +26,8 @@ AVAILTUNES += "powerpc powerpc-nf" >>> TUNE_FEATURES_tune-powerpc-nf ?= "m32 fpu-soft" >>> BASE_LIB_tune-powerpc-nf = "lib" >>> PACKAGE_EXTRA_ARCHS_tune-powerpc-nf = "powerpc-nf" >>> +TUNE_PKGARCH_tune-powerpc-nf = "powerpc-nf" >>> TUNE_FEATURES_tune-powerpc ?= "m32 fpu-hard" >>> BASE_LIB_tune-powerpc = "lib" >>> PACKAGE_EXTRA_ARCHS_tune-powerpc = "powerpc" >>> +TUNE_PKGARCH_tune-powerpc = "powerpc" >> >> >> Why is the above necessary? >> >> TUNE_PKGARCH_append is set to "${PPCPKGSFX_FPU}" >> >> PPCPKGSFX_FP is set to either '' or '-nf' based on the existance of >> fpu-soft. >> >> TUNE_PKGARCH is set by a number of the PowerPC tuning files... If you are >> looking for generic PowerPC there should be something setting TUNE_PKGARCH >> to "powerpc" (or "powerpc64" in the default cases...) > > This is what I'm saying. If you want to target generic powerpc, you > have to force TUNE_PKGARCH, as the generic don't have > TUNE_PKGARCH_tune- definitions. It seems to me in most cases you can > set DEFAULTTUNE and include an appropriate tune file and not need to > set TUNE_PKGARCH directly, which is not the case for the generic ones. > Was it not the intent that this was the case? Should every MACHINE > have to override TUNE_PKGARCH? On PowerPC TUNE_PKGARCH should be set to powerpc (or overriden by the machines). On PowerPC64, it should be set to powerpc64. If this is not happening that is the bug, lack of the default TUNE_PKGARCH. (based on the original implementation.) It was intended that having to have multiple TUNE_PKGARCH one for powerpc and one for powerpc-nf was not the intention. I'm open to changing it, but I took a lot of "feedback" over the initial implementation and that is what ended up in it. --Mark ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf 2012-03-27 21:50 ` Mark Hatle @ 2012-03-27 21:57 ` Christopher Larson 2012-03-27 22:13 ` Mark Hatle 0 siblings, 1 reply; 20+ messages in thread From: Christopher Larson @ 2012-03-27 21:57 UTC (permalink / raw) To: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 1203 bytes --] On Tuesday, March 27, 2012 at 2:50 PM, Mark Hatle wrote: > On 3/27/12 4:05 PM, Chris Larson wrote: > > > > > On PowerPC TUNE_PKGARCH should be set to powerpc (or overriden by the machines). > On PowerPC64, it should be set to powerpc64. If this is not happening that is > the bug, lack of the default TUNE_PKGARCH. (based on the original implementation.) I don't think your point of view is covering all the issues. The default TUNE_PKGARCH is TUNE_PKGARCH_${TUNE_PKGARCH_tune-${DEFAULTTUNE}. If arch-powerpc.inc sets TUNE_PKGARCH directly, as it used to, then all the more specific tunings won't have their TUNE_PKGARCH_tune-<tune> obeyed, which was the behavior prior to my submitting a patch which removed the explicit TUNE_PKGARCH override in arch-powerpc.inc. So we have two options. Either we override TUNE_PKGARCH directly in arch-powerpc.inc again, thereby making powerpc tune- files like tune-ppce500v2 not have their TUNE_PKGARCH_tune-<tune> obeyed (or those tune- files have to override TUNE_PKGARCH as well, which seems counter to the whole design of the tuning implementation), or we add TUNE_PKGARCH_tune-<tune> definitions for the generic tunings also. -Chris [-- Attachment #2: Type: text/html, Size: 2892 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf 2012-03-27 21:57 ` Christopher Larson @ 2012-03-27 22:13 ` Mark Hatle 2012-03-27 22:16 ` Chris Larson 0 siblings, 1 reply; 20+ messages in thread From: Mark Hatle @ 2012-03-27 22:13 UTC (permalink / raw) To: openembedded-core On 3/27/12 4:57 PM, Christopher Larson wrote: > On Tuesday, March 27, 2012 at 2:50 PM, Mark Hatle wrote: >> On 3/27/12 4:05 PM, Chris Larson wrote: >> >> On PowerPC TUNE_PKGARCH should be set to powerpc (or overriden by the machines). >> On PowerPC64, it should be set to powerpc64. If this is not happening that is >> the bug, lack of the default TUNE_PKGARCH. (based on the original implementation.) > > I don't think your point of view is covering all the issues. > > The default TUNE_PKGARCH is TUNE_PKGARCH_${TUNE_PKGARCH_tune-${DEFAULTTUNE}. If > arch-powerpc.inc sets TUNE_PKGARCH directly, as it used to, then all the more > specific tunings won't have their TUNE_PKGARCH_tune-<tune> obeyed, which was the > behavior prior to my submitting a patch which removed the explicit TUNE_PKGARCH > override in arch-powerpc.inc. TUNE_PKGARCH_[override] should always replace TUNE_PKGARCH shouldn't it? Why isn't the override being obeyed is my issue. I really don't care much about the implementation other then originally I was told not to do that during various reviews.. and that the tuning (override) would always replace TUNE_PKGARCH. > So we have two options. Either we override TUNE_PKGARCH directly in > arch-powerpc.inc again, thereby making powerpc tune- files like tune-ppce500v2 > not have their TUNE_PKGARCH_tune-<tune> obeyed (or those tune- files have to > override TUNE_PKGARCH as well, which seems counter to the whole design of the > tuning implementation), or we add TUNE_PKGARCH_tune-<tune> definitions for the > generic tunings also. We need to be consistent as far as I'm concerned. If we want to add TUNE_PKGARCH_tune-<tune> to all of the tunings, and base architecture definitions that is fine. What I don't want is a mix of different ways this stuff is implemented. It's already complicated enough for people to look at and identify what is going on today with subtle differences between the files. If you can explain why the override isn't overriding the default TUNE_PKGARCH (and it's intentional and not a bug), and we can consistently modify all of the elements... I'm happy to accept the changes to all of the tunings. --Mark > -Chris > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf 2012-03-27 22:13 ` Mark Hatle @ 2012-03-27 22:16 ` Chris Larson 2012-03-29 4:47 ` McClintock Matthew-B29882 0 siblings, 1 reply; 20+ messages in thread From: Chris Larson @ 2012-03-27 22:16 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Tue, Mar 27, 2012 at 3:13 PM, Mark Hatle <mark.hatle@windriver.com> wrote: > On 3/27/12 4:57 PM, Christopher Larson wrote: >> >> On Tuesday, March 27, 2012 at 2:50 PM, Mark Hatle wrote: >>> >>> On 3/27/12 4:05 PM, Chris Larson wrote: >>> >>> On PowerPC TUNE_PKGARCH should be set to powerpc (or overriden by the >>> machines). >>> On PowerPC64, it should be set to powerpc64. If this is not happening >>> that is >>> the bug, lack of the default TUNE_PKGARCH. (based on the original >>> implementation.) >> >> >> I don't think your point of view is covering all the issues. >> >> The default TUNE_PKGARCH is >> TUNE_PKGARCH_${TUNE_PKGARCH_tune-${DEFAULTTUNE}. If >> arch-powerpc.inc sets TUNE_PKGARCH directly, as it used to, then all the >> more >> specific tunings won't have their TUNE_PKGARCH_tune-<tune> obeyed, which >> was the >> behavior prior to my submitting a patch which removed the explicit >> TUNE_PKGARCH >> override in arch-powerpc.inc. > > > TUNE_PKGARCH_[override] should always replace TUNE_PKGARCH shouldn't it? > Why isn't the override being obeyed is my issue. I really don't care much > about the implementation other then originally I was told not to do that > during various reviews.. and that the tuning (override) would always replace > TUNE_PKGARCH. No, it isn't an override. The way it obeys is through default values in bitbake.conf. As arch-powerpc.inc would override that default value, it would no longer obey it. To do what you want, you'd have to rework how the tune-<tune> specific values are applied in the implementation. >> So we have two options. Either we override TUNE_PKGARCH directly in >> arch-powerpc.inc again, thereby making powerpc tune- files like >> tune-ppce500v2 >> not have their TUNE_PKGARCH_tune-<tune> obeyed (or those tune- files have >> to >> override TUNE_PKGARCH as well, which seems counter to the whole design of >> the >> tuning implementation), or we add TUNE_PKGARCH_tune-<tune> definitions for >> the >> generic tunings also. > > > We need to be consistent as far as I'm concerned. If we want to add > TUNE_PKGARCH_tune-<tune> to all of the tunings, and base architecture > definitions that is fine. What I don't want is a mix of different ways this > stuff is implemented. It's already complicated enough for people to look at > and identify what is going on today with subtle differences between the > files. > > If you can explain why the override isn't overriding the default > TUNE_PKGARCH (and it's intentional and not a bug), and we can consistently > modify all of the elements... I'm happy to accept the changes to all of the > tunings. See above. It's not an override. And plenty of files already specify TUNE_PKGARCH_tune-<tune>, so I don't see how it'd be inconsistent to do so for the defaults, personally. -- Christopher Larson ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf 2012-03-27 22:16 ` Chris Larson @ 2012-03-29 4:47 ` McClintock Matthew-B29882 2012-03-29 4:54 ` Chris Larson 0 siblings, 1 reply; 20+ messages in thread From: McClintock Matthew-B29882 @ 2012-03-29 4:47 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Tue, Mar 27, 2012 at 5:16 PM, Chris Larson <clarson@kergoth.com> wrote: >> If you can explain why the override isn't overriding the default >> TUNE_PKGARCH (and it's intentional and not a bug), and we can consistently >> modify all of the elements... I'm happy to accept the changes to all of the >> tunings. > > See above. It's not an override. And plenty of files already specify > TUNE_PKGARCH_tune-<tune>, so I don't see how it'd be inconsistent to > do so for the defaults, personally. If no one else has complained so far it makes me believe they are not missing any TUNE_PKGARCH_tune-<tune> then. -M ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf 2012-03-29 4:47 ` McClintock Matthew-B29882 @ 2012-03-29 4:54 ` Chris Larson 2012-03-29 5:07 ` McClintock Matthew-B29882 2012-03-29 15:38 ` Mark Hatle 0 siblings, 2 replies; 20+ messages in thread From: Chris Larson @ 2012-03-29 4:54 UTC (permalink / raw) To: McClintock Matthew-B29882, Patches and discussions about the oe-core layer On Wed, Mar 28, 2012 at 9:47 PM, McClintock Matthew-B29882 <B29882@freescale.com> wrote: > On Tue, Mar 27, 2012 at 5:16 PM, Chris Larson <clarson@kergoth.com> wrote: >>> If you can explain why the override isn't overriding the default >>> TUNE_PKGARCH (and it's intentional and not a bug), and we can consistently >>> modify all of the elements... I'm happy to accept the changes to all of the >>> tunings. >> >> See above. It's not an override. And plenty of files already specify >> TUNE_PKGARCH_tune-<tune>, so I don't see how it'd be inconsistent to >> do so for the defaults, personally. > > If no one else has complained so far it makes me believe they are not > missing any TUNE_PKGARCH_tune-<tune> then. I don't understand the point you're attempting to make here. -- Christopher Larson ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf 2012-03-29 4:54 ` Chris Larson @ 2012-03-29 5:07 ` McClintock Matthew-B29882 2012-03-29 15:38 ` Mark Hatle 1 sibling, 0 replies; 20+ messages in thread From: McClintock Matthew-B29882 @ 2012-03-29 5:07 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: McClintock Matthew-B29882 On Wed, Mar 28, 2012 at 11:54 PM, Chris Larson <clarson@kergoth.com> wrote: > On Wed, Mar 28, 2012 at 9:47 PM, McClintock Matthew-B29882 > <B29882@freescale.com> wrote: >> On Tue, Mar 27, 2012 at 5:16 PM, Chris Larson <clarson@kergoth.com> wrote: >>>> If you can explain why the override isn't overriding the default >>>> TUNE_PKGARCH (and it's intentional and not a bug), and we can consistently >>>> modify all of the elements... I'm happy to accept the changes to all of the >>>> tunings. >>> >>> See above. It's not an override. And plenty of files already specify >>> TUNE_PKGARCH_tune-<tune>, so I don't see how it'd be inconsistent to >>> do so for the defaults, personally. >> >> If no one else has complained so far it makes me believe they are not >> missing any TUNE_PKGARCH_tune-<tune> then. > > I don't understand the point you're attempting to make here. Nevermind. Anyways, powerpc64 needs these too... -M ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf 2012-03-29 4:54 ` Chris Larson 2012-03-29 5:07 ` McClintock Matthew-B29882 @ 2012-03-29 15:38 ` Mark Hatle 2012-03-29 15:54 ` Chris Larson 2012-03-29 15:58 ` McClintock Matthew-B29882 1 sibling, 2 replies; 20+ messages in thread From: Mark Hatle @ 2012-03-29 15:38 UTC (permalink / raw) To: openembedded-core On 3/28/12 11:54 PM, Chris Larson wrote: > On Wed, Mar 28, 2012 at 9:47 PM, McClintock Matthew-B29882 > <B29882@freescale.com> wrote: >> On Tue, Mar 27, 2012 at 5:16 PM, Chris Larson<clarson@kergoth.com> wrote: >>>> If you can explain why the override isn't overriding the default >>>> TUNE_PKGARCH (and it's intentional and not a bug), and we can consistently >>>> modify all of the elements... I'm happy to accept the changes to all of the >>>> tunings. >>> >>> See above. It's not an override. And plenty of files already specify >>> TUNE_PKGARCH_tune-<tune>, so I don't see how it'd be inconsistent to >>> do so for the defaults, personally. >> >> If no one else has complained so far it makes me believe they are not >> missing any TUNE_PKGARCH_tune-<tune> then. > > I don't understand the point you're attempting to make here. Just an FYI -- I've not forgotten about this.. I'm going to look into what is currently implemented and figure out how to get it to be consistent.. things have definitely changed since the initial implementation, and things are no longer consistent. Hopefully I'll have an update later today. --Mark ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf 2012-03-29 15:38 ` Mark Hatle @ 2012-03-29 15:54 ` Chris Larson 2012-03-29 15:58 ` McClintock Matthew-B29882 1 sibling, 0 replies; 20+ messages in thread From: Chris Larson @ 2012-03-29 15:54 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Thu, Mar 29, 2012 at 8:38 AM, Mark Hatle <mark.hatle@windriver.com> wrote: > On 3/28/12 11:54 PM, Chris Larson wrote: >> >> On Wed, Mar 28, 2012 at 9:47 PM, McClintock Matthew-B29882 >> <B29882@freescale.com> wrote: >>> >>> On Tue, Mar 27, 2012 at 5:16 PM, Chris Larson<clarson@kergoth.com> >>> wrote: >>>>> >>>>> If you can explain why the override isn't overriding the default >>>>> TUNE_PKGARCH (and it's intentional and not a bug), and we can >>>>> consistently >>>>> modify all of the elements... I'm happy to accept the changes to all of >>>>> the >>>>> tunings. >>>> >>>> >>>> See above. It's not an override. And plenty of files already specify >>>> TUNE_PKGARCH_tune-<tune>, so I don't see how it'd be inconsistent to >>>> do so for the defaults, personally. >>> >>> >>> If no one else has complained so far it makes me believe they are not >>> missing any TUNE_PKGARCH_tune-<tune> then. >> >> >> I don't understand the point you're attempting to make here. > > > Just an FYI -- I've not forgotten about this.. I'm going to look into what > is currently implemented and figure out how to get it to be consistent.. > things have definitely changed since the initial implementation, and things > are no longer consistent. Understood, thanks. It's good that someone with a better grasp of the entirety of the implementation and its goals take that on. This particular patch isn't particularly important to me, the other two were, but I'm very curious as to how you'll address this, since as I mentioned before it seems that the non-override based implementation is a problem for archs that explicitly set TUNE_PKGARCH. Thanks for looking into this. -- Christopher Larson ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf 2012-03-29 15:38 ` Mark Hatle 2012-03-29 15:54 ` Chris Larson @ 2012-03-29 15:58 ` McClintock Matthew-B29882 2012-03-29 16:40 ` Mark Hatle 1 sibling, 1 reply; 20+ messages in thread From: McClintock Matthew-B29882 @ 2012-03-29 15:58 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Thu, Mar 29, 2012 at 10:38 AM, Mark Hatle <mark.hatle@windriver.com> wrote: > On 3/28/12 11:54 PM, Chris Larson wrote: >> >> On Wed, Mar 28, 2012 at 9:47 PM, McClintock Matthew-B29882 >> <B29882@freescale.com> wrote: >>> >>> On Tue, Mar 27, 2012 at 5:16 PM, Chris Larson<clarson@kergoth.com> >>> wrote: >>>>> >>>>> If you can explain why the override isn't overriding the default >>>>> TUNE_PKGARCH (and it's intentional and not a bug), and we can >>>>> consistently >>>>> modify all of the elements... I'm happy to accept the changes to all of >>>>> the >>>>> tunings. >>>> >>>> >>>> See above. It's not an override. And plenty of files already specify >>>> TUNE_PKGARCH_tune-<tune>, so I don't see how it'd be inconsistent to >>>> do so for the defaults, personally. >>> >>> >>> If no one else has complained so far it makes me believe they are not >>> missing any TUNE_PKGARCH_tune-<tune> then. >> >> >> I don't understand the point you're attempting to make here. > > > Just an FYI -- I've not forgotten about this.. I'm going to look into what > is currently implemented and figure out how to get it to be consistent.. > things have definitely changed since the initial implementation, and things > are no longer consistent. > > Hopefully I'll have an update later today. Just for some background: I added the TUNEPKG_ARCH = TUNE_PKGARCH_tune-$DEFAULTTUNE bit because it seemed to make sense and it was missing from this list: meta/conf/bitbake.conf:TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}" meta/conf/bitbake.conf:PACKAGE_EXTRA_ARCHS ??= "${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}" Also it seemed silly (at the time admittedly) to set TUNE_PKGARCH based off a value in TUNE_FEATURES and using bb functions to do this when the way I went with was simply setting a value. I did miss that the default case no longer works properly unless you have a TUNE_PKGARCH_tune-{powerpc,powerpc-nf,powerpc64} = {powerpc,powerpc-nf,powerpc64} set in the default arch files. Anyways, I'm not stuck on one particular method at the time I was trying to get ppce5500 multilib working properly. -M ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf 2012-03-29 15:58 ` McClintock Matthew-B29882 @ 2012-03-29 16:40 ` Mark Hatle 2012-03-29 18:38 ` Chris Larson 0 siblings, 1 reply; 20+ messages in thread From: Mark Hatle @ 2012-03-29 16:40 UTC (permalink / raw) To: openembedded-core (This is going to be a bit rambling I'm afraid.. I'm working my way through investigation and a possible solution.. so be sure to look all the way to the end..) On 3/29/12 10:58 AM, McClintock Matthew-B29882 wrote: > On Thu, Mar 29, 2012 at 10:38 AM, Mark Hatle<mark.hatle@windriver.com> wrote: >> On 3/28/12 11:54 PM, Chris Larson wrote: >>> >>> On Wed, Mar 28, 2012 at 9:47 PM, McClintock Matthew-B29882 >>> <B29882@freescale.com> wrote: >>>> >>>> On Tue, Mar 27, 2012 at 5:16 PM, Chris Larson<clarson@kergoth.com> >>>> wrote: >>>>>> >>>>>> If you can explain why the override isn't overriding the default >>>>>> TUNE_PKGARCH (and it's intentional and not a bug), and we can >>>>>> consistently >>>>>> modify all of the elements... I'm happy to accept the changes to all of >>>>>> the >>>>>> tunings. >>>>> >>>>> >>>>> See above. It's not an override. And plenty of files already specify >>>>> TUNE_PKGARCH_tune-<tune>, so I don't see how it'd be inconsistent to >>>>> do so for the defaults, personally. >>>> >>>> >>>> If no one else has complained so far it makes me believe they are not >>>> missing any TUNE_PKGARCH_tune-<tune> then. >>> >>> >>> I don't understand the point you're attempting to make here. >> >> >> Just an FYI -- I've not forgotten about this.. I'm going to look into what >> is currently implemented and figure out how to get it to be consistent.. >> things have definitely changed since the initial implementation, and things >> are no longer consistent. >> >> Hopefully I'll have an update later today. > > Just for some background: > > I added the TUNEPKG_ARCH = TUNE_PKGARCH_tune-$DEFAULTTUNE bit because > it seemed to make sense and it was missing from this list: > > meta/conf/bitbake.conf:TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}" > meta/conf/bitbake.conf:PACKAGE_EXTRA_ARCHS ??= > "${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}" > > Also it seemed silly (at the time admittedly) to set TUNE_PKGARCH > based off a value in TUNE_FEATURES and using bb functions to do this > when the way I went with was simply setting a value. I did miss that > the default case no longer works properly unless you have a > TUNE_PKGARCH_tune-{powerpc,powerpc-nf,powerpc64} = > {powerpc,powerpc-nf,powerpc64} set in the default arch files. > > Anyways, I'm not stuck on one particular method at the time I was > trying to get ppce5500 multilib working properly. Ok, that makes a bit more sense.. What I see right now is: TUNE_PKGARCH ??= "${TUNE_PKGARCH_tune-${DEFAULTTUNE}}" (This was originally designed that TUNE_PKGARCH was defined based on the overrides... note, not only has the above affected that, but it's not consistent in the other architectures either.. so it was wrong, and is still likely wrong...) Arm defines it as: TUNE_PKGARCH = "${@d.getVar('ARMPKGARCH', True)}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}" That way the ARMPKGARCH is the base of the configuration, while the DSP, ABI, Endian and FPU are added dynamically based on the feature flags (and associated settings).. IA defines is as: TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "m32", "x86", "x86_64", d)}" TUNE_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "mx32", "_x32", "", d)}" And then some (c3, core2, i586) override that, but not all of them.. again this is likely wrong as well.. MIPS defines it as: TUNE_PKGARCH ?= "${TUNE_ARCH}${MIPSPKGSFX_FPU}${MIPSPKGSFX_ABI}" TUNE_ARCH as: TUNE_ARCH = "mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN} and finally powerpc: There is NO TUNE_PKGARCH defined.. but there is an append: TUNE_PKGARCH_append = "${PPCPKGSFX_FPU}" And each of the tunings: tune-ppc603e.inc:TUNE_PKGARCH_tune-ppc603e = "ppc603e" tune-ppce300c2.inc:TUNE_PKGARCH_tune-ppce300c2 = "ppce300c2" tune-ppce500.inc:TUNE_PKGARCH_tune-ppce500 = "ppce500" tune-ppce500mc.inc:TUNE_PKGARCH_tune-ppce500mc = "ppce500mc" tune-ppce500v2.inc:TUNE_PKGARCH_tune-ppce500v2 = "ppce500v2" tune-ppce5500.inc:TUNE_PKGARCH_tune-ppce5500 = "ppce5500" tune-ppce5500.inc:TUNE_PKGARCH_tune-ppc64e5500 = "ppc64e5500" .... so somehow we need to figure out a more consistent approach. Personally I prefer the ARM/MIPS style approach. Build up the format using a consistent set of features/arguments. The one thing I'm still struggling with though is what is the final purpose of these variables. I may be able to make a better determination as to the right values if I truly understood the difference. Below is my attempt at understanding this... (let me know if this is correct or if you have corrections) DEFAULTTUNE - The default tuning for a given machine or build [multilib build uses overrides to change the DEFAULTTUNE setting], tune values are defined by the conf/machine/include/* items TUNE_FEATURES_tune-<tune> - Should not be manually modified (i.e. not in local.conf, only specified by a tune file), but inherited via the DEFAULTTUNE value -- this defines the set of tuning variables that a given tuning uses to setup cflags, pkgarch, abi, etc.. TUNE_CCARGS - Setup the cflags based on the TUNE_FEATURES settings. These should be additive when defined using "+=". All items in this list should be dynamic! i.e. ${@bb.utils.contains("TUNE_FEATURES", "feature", "cflag", "!cflag", d)} AVAILTUNES - This is a list of all available tunes within the machine configuration. This does not mean that all available tunes are compatible with that machine configuration, or with each other. The DEFAULTTUNE must be in this list. Each tuning file can add to this list using "+=". PACKAGE_EXTRA_ARCHS_tune-<tune> - List of all compatible package arches to a given tune. TUNE_ARCH - GNU canonical arch for the architecture. I.e. arm, armeb, mips, mips64, etc. TUNE_PKGARCH - The package architecture listed for the purpose of package feeds. These are the names used by the PACKAGE_EXTRA_ARCHS for compatibility reasons. TARGET_FPU - The FPU setting for a given architecture, hard (generate floating point instructions), soft (generate internal gcc calls), "other" architecture specific floating point. This is synchronized with the compiler and other toolchain items. This should be dynamically configured in the same way the TUNE_CCARGS is. BASE_LIB_tune-<tune> - The "/lib" location for a specific ABI. ---- So how about this for a possible solution: bitbake.conf: Keep - TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}" Remove - TUNE_PKGARCH In the tuning files, specifically the architectural tuning files: Require a default setting of TUNE_PKGARCH. The default setting MIGHT be specific to an arch (as in the ARM case above), or could be TUNE_PKGARCH = ${TUNE_PKGARCH_tune-${DEFAULTTUNE}} for something like PowerPC where it may be easier to specific the exact package arch. Each architecture file needs a small README to indicate how someone is to add a new tuning to that architecture. ---- Does the above seem reasonable? If so I'll try to get started on that... --Mark > -M > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf 2012-03-29 16:40 ` Mark Hatle @ 2012-03-29 18:38 ` Chris Larson 2012-03-29 18:50 ` McClintock Matthew-B29882 0 siblings, 1 reply; 20+ messages in thread From: Chris Larson @ 2012-03-29 18:38 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Thu, Mar 29, 2012 at 9:40 AM, Mark Hatle <mark.hatle@windriver.com> wrote: > (This is going to be a bit rambling I'm afraid.. I'm working my way through > investigation and a possible solution.. so be sure to look all the way to > the end..) > > > On 3/29/12 10:58 AM, McClintock Matthew-B29882 wrote: >> >> On Thu, Mar 29, 2012 at 10:38 AM, Mark Hatle<mark.hatle@windriver.com> >> wrote: >>> >>> On 3/28/12 11:54 PM, Chris Larson wrote: >>>> >>>> >>>> On Wed, Mar 28, 2012 at 9:47 PM, McClintock Matthew-B29882 >>>> <B29882@freescale.com> wrote: >>>>> >>>>> >>>>> On Tue, Mar 27, 2012 at 5:16 PM, Chris Larson<clarson@kergoth.com> >>>>> wrote: >>>>>>> >>>>>>> >>>>>>> If you can explain why the override isn't overriding the default >>>>>>> TUNE_PKGARCH (and it's intentional and not a bug), and we can >>>>>>> consistently >>>>>>> modify all of the elements... I'm happy to accept the changes to all >>>>>>> of >>>>>>> the >>>>>>> tunings. >>>>>> >>>>>> >>>>>> >>>>>> See above. It's not an override. And plenty of files already specify >>>>>> TUNE_PKGARCH_tune-<tune>, so I don't see how it'd be inconsistent to >>>>>> do so for the defaults, personally. >>>>> >>>>> >>>>> >>>>> If no one else has complained so far it makes me believe they are not >>>>> missing any TUNE_PKGARCH_tune-<tune> then. >>>> >>>> >>>> >>>> I don't understand the point you're attempting to make here. >>> >>> >>> >>> Just an FYI -- I've not forgotten about this.. I'm going to look into >>> what >>> is currently implemented and figure out how to get it to be consistent.. >>> things have definitely changed since the initial implementation, and >>> things >>> are no longer consistent. >>> >>> Hopefully I'll have an update later today. >> >> >> Just for some background: >> >> I added the TUNEPKG_ARCH = TUNE_PKGARCH_tune-$DEFAULTTUNE bit because >> it seemed to make sense and it was missing from this list: >> >> meta/conf/bitbake.conf:TUNE_FEATURES ??= >> "${TUNE_FEATURES_tune-${DEFAULTTUNE}}" >> meta/conf/bitbake.conf:PACKAGE_EXTRA_ARCHS ??= >> "${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}" >> >> Also it seemed silly (at the time admittedly) to set TUNE_PKGARCH >> based off a value in TUNE_FEATURES and using bb functions to do this >> when the way I went with was simply setting a value. I did miss that >> the default case no longer works properly unless you have a >> TUNE_PKGARCH_tune-{powerpc,powerpc-nf,powerpc64} = >> {powerpc,powerpc-nf,powerpc64} set in the default arch files. >> >> Anyways, I'm not stuck on one particular method at the time I was >> trying to get ppce5500 multilib working properly. > > > Ok, that makes a bit more sense.. What I see right now is: > > TUNE_PKGARCH ??= "${TUNE_PKGARCH_tune-${DEFAULTTUNE}}" > > (This was originally designed that TUNE_PKGARCH was defined based on the > overrides... note, not only has the above affected that, but it's not > consistent in the other architectures either.. so it was wrong, and is still > likely wrong...) > > Arm defines it as: > > TUNE_PKGARCH = "${@d.getVar('ARMPKGARCH', > True)}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}" > > That way the ARMPKGARCH is the base of the configuration, while the DSP, > ABI, Endian and FPU are added dynamically based on the feature flags (and > associated settings).. > > IA defines is as: > TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "m32", "x86", > "x86_64", d)}" > TUNE_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "mx32", "_x32", "", > d)}" > > And then some (c3, core2, i586) override that, but not all of them.. again > this is likely wrong as well.. > > MIPS defines it as: > > TUNE_PKGARCH ?= "${TUNE_ARCH}${MIPSPKGSFX_FPU}${MIPSPKGSFX_ABI}" > > TUNE_ARCH as: > TUNE_ARCH = "mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN} > > and finally powerpc: > > There is NO TUNE_PKGARCH defined.. but there is an append: > > TUNE_PKGARCH_append = "${PPCPKGSFX_FPU}" > > And each of the tunings: > > tune-ppc603e.inc:TUNE_PKGARCH_tune-ppc603e = "ppc603e" > tune-ppce300c2.inc:TUNE_PKGARCH_tune-ppce300c2 = "ppce300c2" > tune-ppce500.inc:TUNE_PKGARCH_tune-ppce500 = "ppce500" > tune-ppce500mc.inc:TUNE_PKGARCH_tune-ppce500mc = "ppce500mc" > tune-ppce500v2.inc:TUNE_PKGARCH_tune-ppce500v2 = "ppce500v2" > tune-ppce5500.inc:TUNE_PKGARCH_tune-ppce5500 = "ppce5500" > tune-ppce5500.inc:TUNE_PKGARCH_tune-ppc64e5500 = "ppc64e5500" > > > .... so somehow we need to figure out a more consistent approach. > Personally I prefer the ARM/MIPS style approach. Build up the format using > a consistent set of features/arguments. That seems reasonable to me. I personally don't care much about which approach is used as long as we're consistent about it :) > The one thing I'm still struggling with though is what is the final purpose > of these variables. I may be able to make a better determination as to the > right values if I truly understood the difference. Below is my attempt at > understanding this... (let me know if this is correct or if you have > corrections) > > DEFAULTTUNE - The default tuning for a given machine or build > [multilib build uses overrides to change the DEFAULTTUNE setting], tune > values are defined by the conf/machine/include/* items > > TUNE_FEATURES_tune-<tune> - Should not be manually modified (i.e. not in > local.conf, only specified by a tune file), but inherited via the > DEFAULTTUNE value -- this defines the set of tuning variables that a given > tuning uses to setup cflags, pkgarch, abi, etc.. > > TUNE_CCARGS - Setup the cflags based on the TUNE_FEATURES settings. These > should be additive when defined using "+=". All items in this list should > be dynamic! i.e. ${@bb.utils.contains("TUNE_FEATURES", "feature", "cflag", > "!cflag", d)} > > AVAILTUNES - This is a list of all available tunes within the machine > configuration. This does not mean that all available tunes are compatible > with that machine configuration, or with each other. The DEFAULTTUNE must > be in this list. Each tuning file can add to this list using "+=". > > PACKAGE_EXTRA_ARCHS_tune-<tune> - List of all compatible package arches to a > given tune. > > TUNE_ARCH - GNU canonical arch for the architecture. I.e. arm, armeb, mips, > mips64, etc. > > TUNE_PKGARCH - The package architecture listed for the purpose of package > feeds. These are the names used by the PACKAGE_EXTRA_ARCHS for > compatibility reasons. > > TARGET_FPU - The FPU setting for a given architecture, hard (generate > floating point instructions), soft (generate internal gcc calls), "other" > architecture specific floating point. This is synchronized with the > compiler and other toolchain items. This should be dynamically configured > in the same way the TUNE_CCARGS is. > > BASE_LIB_tune-<tune> - The "/lib" location for a specific ABI. That's my understanding of those as well, if someone disagrees, it'd be very interesting to know that. Further, it'd be nice to document these somewhere.. either documentation.conf, though they're intended for the bsp maintainers not the average user, or somewhere else appropriate. > So how about this for a possible solution: > > bitbake.conf: > Keep - TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}" > > Remove - TUNE_PKGARCH > > In the tuning files, specifically the architectural tuning files: > > Require a default setting of TUNE_PKGARCH. The default setting MIGHT be > specific to an arch (as in the ARM case above), or could be > TUNE_PKGARCH = ${TUNE_PKGARCH_tune-${DEFAULTTUNE}} for something like > PowerPC where it may be easier to specific the exact package arch. > > Each architecture file needs a small README to indicate how someone is to > add a new tuning to that architecture. > > ---- > > Does the above seem reasonable? If so I'll try to get started on that... That seems reasonable to me, for what that's worth. I could see simplifying the way the powerpc stuff works in the future, but at least we'd have something functional for now as well. It keeps primary responsibility for TUNE_PKGARCH in arch-powerpc*.inc, which is as it should be -- the arch knows best how to manage it. I'm curious to hear Matthew's perspective on this. -- Christopher Larson ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf 2012-03-29 18:38 ` Chris Larson @ 2012-03-29 18:50 ` McClintock Matthew-B29882 0 siblings, 0 replies; 20+ messages in thread From: McClintock Matthew-B29882 @ 2012-03-29 18:50 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Thu, Mar 29, 2012 at 1:38 PM, Chris Larson <clarson@kergoth.com> wrote: >> Does the above seem reasonable? If so I'll try to get started on that... > > That seems reasonable to me, for what that's worth. I could see > simplifying the way the powerpc stuff works in the future, but at > least we'd have something functional for now as well. It keeps primary > responsibility for TUNE_PKGARCH in arch-powerpc*.inc, which is as it > should be -- the arch knows best how to manage it. I'm curious to hear > Matthew's perspective on this. This is fine with me, I just did not like setting TUNE_FEATURES = foo only to have TUNE_ARCH = ${@bb.utils.contains("TUNE_FEATURES", "foo", "foo", "${PPCPKGARCH}", d)}" when it seemed better to just TUNE_ARCH = foo At least I think that was my thought logic, then it went a step further and thought we could just use TUNE_PKGARCH_tune-$DEFAULTTUNE since these would be available from multilib anyways... -M ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2012-04-07 16:22 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-03-27 19:51 [PATCH 1/3] external-csl: add mapping for powerpc-nf Christopher Larson 2012-03-27 19:51 ` [PATCH 2/3] powerpc e500: set -mfloat-gprs=double Christopher Larson 2012-04-07 5:40 ` Khem Raj 2012-04-07 16:12 ` Chris Larson 2012-03-27 19:51 ` [PATCH 3/3] powerpc: define TUNE_PKGARCH for powerpc/powerpc-nf Christopher Larson 2012-03-27 20:22 ` Mark Hatle 2012-03-27 21:05 ` Chris Larson 2012-03-27 21:50 ` Mark Hatle 2012-03-27 21:57 ` Christopher Larson 2012-03-27 22:13 ` Mark Hatle 2012-03-27 22:16 ` Chris Larson 2012-03-29 4:47 ` McClintock Matthew-B29882 2012-03-29 4:54 ` Chris Larson 2012-03-29 5:07 ` McClintock Matthew-B29882 2012-03-29 15:38 ` Mark Hatle 2012-03-29 15:54 ` Chris Larson 2012-03-29 15:58 ` McClintock Matthew-B29882 2012-03-29 16:40 ` Mark Hatle 2012-03-29 18:38 ` Chris Larson 2012-03-29 18:50 ` McClintock Matthew-B29882
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.