On Mon, Nov 26, 2012 at 12:49:31PM +0100, Martin Jansa wrote: > 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.
I've added .inc file in meta-shr https://github.com/shr-distribution/meta-smartphone/blob/shr/meta-shr/conf/distro/include/defaulttunes.inc So everybody can decide on their own builder 1) no change needed 2) require that file from local.conf + add DEFAULTTUNE_tuna as comment suggests 3) require that file 4) reply to http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/030076.html that you find it really usefull.. and maybe later you'll find it in oe-core BTW: this changes depend on not-yet merged patchset http://lists.linuxtogo.org/pipermail/openembedded-core/2012-November/032364.html so you need shr or jansa/test branches of all layers 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
