Hi, my patches for mixing different -mtune params while building shared binary feeds were merged to openembedded-core today.
The change is only in master and wont be backported to danny branches so current shr feeds won't be affected for some time (probably till next OE release). But we have to decide this for shr and jansa/test branches which tracks oe-core master. For more information see: https://bugzilla.yoctoproject.org/show_bug.cgi?id=3219 Short example for our use case: nokia900.conf is using tune-cortexa8.inc which adds -mtune=cortex-a8 tuna.conf is now using tune-cortexa8.inc, but should use tune-cortexa8.inc which adds -mtune=cortex-a9 Without those patches both MACHINEs would build binary packages in armv7a-nofvp-neon feed so some packages there would be built with -mtune=cortex-a8 and some with -mtune=cortex-a9, which isn't fatal, but also not really optimal. What's worse is that with OEBasicHash they are all rebuilt after each MACHINE switch from nokia900 to tuna. End user on target (with opkg) cannot distinguish between those two, so opkg does not upgrade/reinstall anything when binary with better -mtune gets available in feed. With those patches both MACHINEs can include different tune-cortexa*, but by default both will build without any -mtune param so armv7a-nofvp-neon is consistent, but with a bit worse performance on target. We have 4 options now: 1) keep default, build without -mtune + all armv7a packages are built just once + less disk space for feed - worse performance on target 2) To get -mtune back we can set more specific DEFAULTTUNE for all SHR supported devices in distro config, so that binary feed will be renamed from armv7a-novfp-neon to cortexa8-novfp-neon and cortexa9-novfp-neon. + "better" performance on tuna, same on nokia900, om-gta04, crespo - extra disk space needed for separate cortexa9-novfp-neon feed (armv7a-novfp-neon will be removed - replaced by cortexa8-novfp-neon) - 33% longer build time for all SHR supported machines (3 package archs instead of 2) 3) set more specific DEFAULTTUNE but keep cortexa8 include in tuna + same performance as now + same disk space usage 4) implement OPTDEFAULTTUNE in distro, my first version of this patchset added extra variable to tune files called OPTDEFAULTTUNE, so that e.g. tune-cortexa8.inc had OPTDEFAULTTUNE = "cortexa8" and DEFAULTTUNE = "armv7a" and then you could define per package or per machine if you prefer to share feed (DEFAULTTUNE) or optimize feed with -mtune (OPTDEFAULTTUNE) Unfortunattely this version of patch was rejected, as too complex for already complicated arm tunes. I can try to send it again now when the rest of patches is merged. I don't have strong opinion on any option we have now. Oficial buildhost is now building from danny branches, so not influenced by this. Next oe-core release will require use of PR server and that makes OEBasicHash mandatory, so tracking master as close as we did now won't be possible on current infrastructure we have anyway. Please vote on options :). CCing openwebos-gene...@mailman.openwebosproject.org as we will have to discuss the same problem when we decide to upgrade oe-core again. Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
_______________________________________________ Shr-devel mailing list Shr-devel@lists.shr-project.org http://lists.shr-project.org/mailman/listinfo/shr-devel
