From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id DB119E009BE; Wed, 15 Jul 2015 09:21:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.0 SPF_HELO_PASS SPF: HELO matches SPF record * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no * trust * [157.56.110.141 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 HTML_MESSAGE BODY: HTML included in message Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0141.outbound.protection.outlook.com [157.56.110.141]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id A7E9BE00978 for ; Wed, 15 Jul 2015 09:21:46 -0700 (PDT) Received: from BLUPR03MB277.namprd03.prod.outlook.com (10.255.213.15) by BLUPR03MB551.namprd03.prod.outlook.com (10.141.77.14) with Microsoft SMTP Server (TLS) id 15.1.213.14; Wed, 15 Jul 2015 16:21:43 +0000 Received: from BN3PR0301CA0063.namprd03.prod.outlook.com (10.160.152.159) by BLUPR03MB277.namprd03.prod.outlook.com (10.255.213.15) with Microsoft SMTP Server (TLS) id 15.1.219.9; Wed, 15 Jul 2015 16:21:43 +0000 Received: from BY2FFO11FD020.protection.gbl (2a01:111:f400:7c0c::143) by BN3PR0301CA0063.outlook.office365.com (2a01:111:e400:401e::31) with Microsoft SMTP Server (TLS) id 15.1.219.17 via Frontend Transport; Wed, 15 Jul 2015 16:21:42 +0000 Authentication-Results: spf=fail (sender IP is 192.88.158.2) smtp.mailfrom=freescale.com; gmail.com; dkim=none (message not signed) header.d=none; Received-SPF: Fail (protection.outlook.com: domain of freescale.com does not designate 192.88.158.2 as permitted sender) receiver=protection.outlook.com; client-ip=192.88.158.2; helo=az84smr01.freescale.net; Received: from az84smr01.freescale.net (192.88.158.2) by BY2FFO11FD020.mail.protection.outlook.com (10.1.14.137) with Microsoft SMTP Server (TLS) id 15.1.213.8 via Frontend Transport; Wed, 15 Jul 2015 16:21:42 +0000 Received: from [127.0.0.1] (RA43240-03.am.freescale.net [10.81.17.26]) by az84smr01.freescale.net (8.14.3/8.14.0) with ESMTP id t6FGLe3V019273; Wed, 15 Jul 2015 09:21:41 -0700 Message-ID: <55A68895.9040404@freescale.com> Date: Wed, 15 Jul 2015 11:21:41 -0500 From: Ann Thornton User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Daiane Angolini References: <559EA15B.2060606@freescale.com> In-Reply-To: X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD020; 1:LTV1qNT9OoKs3zxSygYg7Wi/XtZTUOsl1XwN3VfQzwox2R0P34vkR0dO5Imvi9VRby3WNhDho0YJYjF/9js8AYDcH5O7IhTrFTx9quIdlasJFG/Shc1rHjgEIMm1PYz3jK9jd5sqAa1Hcr0IRphUDitkqlX5zejiIszXYbyPi8Ac41FboV9pdAvCKtG7dW7nNXfOWGdE/4tdKpx96TIxK+hQ9kwvLqPkGOyJucAcnUQmM6g/p+v5UJG7SL7zuH8r1cWXh5DreQ2B9k54qCcncGe8kMXfrP0b6wynHOUqBVJF0iLF/2TYmWZUd8gj2vRHfN0Xob4BrJJgHxkfa+6/Il6pwAUs8Osx29zY/MP8z9ZfU2gelXjHN/wBTEyWKLjL X-Forefront-Antispam-Report: CIP:192.88.158.2; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(339900001)(199003)(51704005)(252514010)(479174004)(24454002)(189002)(377454003)(50986999)(87266999)(65816999)(54356999)(76176999)(77096005)(189998001)(65956001)(104016003)(46102003)(15975445007)(36756003)(65806001)(4001350100001)(105606002)(5001920100001)(19617315012)(106466001)(33656002)(512874002)(85426001)(83506001)(19580395003)(19580405001)(6806004)(64126003)(110136002)(92566002)(120886001)(87936001)(2950100001)(5001960100002)(59896002)(86362001)(84326002)(62966003)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB277; H:az84smr01.freescale.net; FPR:; SPF:Fail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB277; 2:cZQaVMz0fHIbC+NyZgbiNP4RItB1mxHKWIOkQixD6luHpkjOTpk0NtNJrv06Rh/F; 3:OwSbskHgw5pxzuIZPShzQkPeLImCq/g4gg/X+bkXkGVSICHmBB1gdn17v84lsmzV6xl4G17Xbg7QFH6eXKMcRd3TZYh0hjwh7iQjEtRnpnalDNt1ZN2G8yuP5LK6crUpss0oAwjREE5wrg1ya54Oke/s6TLXEwDcyzw7Gr4sr3A273XgypsTOnPWcUsiPk3s1Egi+XENOFVAYAl3WmGU9FzxEHFF7VqKgCD01f93Aq8=; 25:E3LaphfWdQQZ9EHKi0hrx2nrvnyfZ8TcQkRKYSkN1SKS3x5Zph0TZa224dcC50gaxYBFC3rNcCI5wSL1ZelDazi0JYSuFew3C7a6omq1WWzQ+eqq3OCWuhOYGdTX6CXcuVRYotZ8RbIEoHDDUZ2xrYUngvjiD0FqCInxy8+yuF+DEoaPL7DzW5mv+6OCzWznjEo3Cn+JMF/Fr4TfL4W3bsepQZqib4EahQbaAdBfC3214DlFUmJefvg9HdD8RLrizYTeTsvkMEyC/tX5xrb/6A==; 20:q+xsFZ01V7Kp5niV2o9gPlFesKEBOp/vvSsERFgwytNfieGCe3RLv5yRO6VmoSXgRci6O7kCde4XQSajP6zK8hn5428bjumeYw3yOd42fveaaCcwH73uDuSoCR6DG4XDe6/mg1ICdWyhIuZfq3ZKMeHbUJX84teoUYotWmzRs/sfYtUSHncex1fEjowv+F/H8yEZTkPSbIlwVFcxlmk8cSlAG2yKXZqf+TRJOnkFnzIJbcUwiuLoBxeUK66pO2VGf4L376f/pq1fSVY+pdhbw635gZmt4ahPSeH+M3eklXQNXVdTa2T7NiDUTaPOBeNpqcpMoJSkEdAX5hDXlOXcP7Dif7HHtFc1WHS67cbhXs4= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB277; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB551; BLUPR03MB277: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR03MB277; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB277; X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB277; 4:kVvo/woHp8X6fIUl0onEOGJhee6dwdKpRljToDy4QfWFprt5Cmni6T0bXJO6wS780Sj9Whym1DW+3OMYSRotywo0iIYSdhRQ/3s7x8wL+Z5WIKuGXYFPzky2ZVSYRqzFDgKoVo/B6abgu65xe/T7Z6rPIPV/VcPCkhLrnR/Sq+gUhroCt3Hzwm6ToAzKHuCqGJ/lRvasxVm2e8ztHgHWkC9qhsjajiZFEHdvIbdEvFp/Brmm1XRJtZnXJdqjnAklme9RhZdSC16va0tu1y5vcadWowbIPquH7BE5KDAPVps= X-Forefront-PRVS: 0638FD5066 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR03MB277; 23:wDvV7Uqc3eybwKBKCYwRDn08DyYYUukeujMd1FV1ii?= =?us-ascii?Q?YFLJveNA2X8IOb18Aj2T0Be/piDoSz8LvcR5hOGCWucP6vrpS3cTKLnjX41O?= =?us-ascii?Q?1EHWbX+2NCl6aljtX38pbcm0tWqiWPCNu4VFiLUzz0A1ZIme0Kz376giAKTU?= =?us-ascii?Q?6s/O7hp+/0IscUNOmMw1uhgMmCizqhqfERBY7SK3PKrJSaEHIv9FXHITvpw9?= =?us-ascii?Q?cLw0ybmAeq5/fNz/WNq/swaC0fNO3L9jjma/iO/+B9Mli6R8/mbG4IOeNdj4?= =?us-ascii?Q?Tr7OYbUsxt2sj/4XxokCjIPjPUzm2uUFTWHUibyOJ57DNoA9b2ovHiRdPA8e?= =?us-ascii?Q?LKzWmG/DUOTgN42bupZq2l896aZgj8cjURKz+qa1+jb6MT0FC2slkWnuxtPQ?= =?us-ascii?Q?L4RquGfM6p7mQX49woEbmgm16cuvhsOVp+bDFxL/kr9z/TF1nxGzmylwGYYA?= =?us-ascii?Q?DdeyCK74vFidSFSi5bEdnZKEwjgo2ZNhSVxfNSZcHNlVei1vNHdbSlWwP+km?= =?us-ascii?Q?sVkDtlFL8NRweudTV8ewfPFV9Qc6L0SDk2POsWdwMYhxFPvC/U/w37umDppV?= =?us-ascii?Q?MUlVf5+tQbElWU53LuumTL9l+GBqCkXtthX7bqQCRdCrOQhYQThc8ab+Aw+G?= =?us-ascii?Q?q5552eJP1preJ0Bh9uTMrDb4eFhsvjriip0W258l/2v3Aq3JWdFfh0ZYhFUC?= =?us-ascii?Q?WlE1O97fMkNC2Erv9Ed3QROy+kW6KW2jXV4w6gqPDDGykOSyhPjjPUj7Qz3l?= =?us-ascii?Q?Eo2RGdMcG29MChKMZwhMVkl2OSBWADnLHDpfCVNGstr8unRkpaGji6VbVRz5?= =?us-ascii?Q?URT/VwNp5unkPQoGxHrKVvZufDgsKutSXgoyMETr+/XdXP/mGsEP6hesF5mQ?= =?us-ascii?Q?B+7nr5mNZyeyloYv4sXSW0ESDHv90uMqg1wGffh5nmDI5ySfI3ho/Xfu6Ag9?= =?us-ascii?Q?D9Xb3uacn2i6VUj+XzJFrwwqe+bk/38YuV8ZqAvSj/4Hp9a/heJ2Ig3H4eYr?= =?us-ascii?Q?BysRZ7x33PCgRfdsGW3km8qDwhSHsL2PwJq6IFI5CjwEceooNLZrl61SWAbF?= =?us-ascii?Q?FTiBH2/8kuWlhN/JJQkQFD1+pYZPTj++9JHYqhli2Khl2S8QTFYLMj4EiZhV?= =?us-ascii?Q?Hgm2CELbrUymrQtBgbbQ+eXtOaPxdlxpYdtVqI7s1xQT7F9qx5FvNNqCjQxZ?= =?us-ascii?Q?brc5XlDr+AOHAzfYEoqZmEV05pFAiWV0ZK?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB277; 5:FSUSwb6gPohruSW8D1iq1ceG1Yxg7mIk0CvutD/gjFWO9QokrXLcvXnjw28UogBJvYdqd+eVJQO3VUq7R7X0V5Z7X2dSiSg+dZwjeQK2Upi1za/iYqApUN8T3IluRXZIa3/w3nK1GFeAxHQLLJjmDA==; 24:Urko+a0N5hkZl9ytTAwDTKownLF+GSc8KkoKD7e5AYJbVNS/UeCMmNn9nDzTvMetshHaBfGIywwitwoF9ty1+0c8aGwhUqBh+pGsnb/BLPI=; 20:mdCbS67Cysv1M5BqMY3RCJqSa8g90SPhoFEaUiHPOmcF5kl01zmVDJaZWLEysYs5FmZ9fh3axabwlPnuXnc7sg== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jul 2015 16:21:42.3351 (UTC) X-MS-Exchange-CrossTenant-Id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=710a03f5-10f6-4d38-9ff4-a80b81da590d; Ip=[192.88.158.2]; Helo=[az84smr01.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB277 X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB551; 2:2M8nta1dFi+Zk4kWYMshevD/+QCx4KE1NQW88nMB3WFI2QlKKujptLR4PK7TT9Lf; 3:GuiMo1V5MupUOI/h1tXIDLoXSYSekfMVKmPfS1bjwGuH4c+6cBVHxM0+yRDJMQqvkLv94VHmVLFBHg7DbCjl3K8UfyP5VE84f8w19NL6AFWDnMhV4nQwedlCpQKy/TvhreB1BmpqFlIg3wOXbIi8NHXu/BwG6fIg2G8PyU+k/MwsaeYxcv5v+VtZsau/0g8i7BR5ST4hsgQ4/0sy9LzFe4+qJt7OIMvr3unN8HAzzr8=; 25:0ZzS+lM8wgzwbZo4eUiS87yulDXrmOzdS375MJvErAiM0W574ZimkRPOjNOMIJQ3n+COZ/CYPyNRsNTPw3qgkzA2VlB625+fY8XtMUD23nuhwZkvFsknw0h4EealMoru5Yga0ne2hhw0bs7r4eAlJ6dsq1x8jisHqVUsunisFlJqSyoTDKeYJFtsxCZuC0AOQCHxoekdGQRdK1PkIBQYpNWPK5TkENvNLfxHFh6xEMYuiqWLwY6542Iig2YHvYWxw2zNWatpTP9/Ui2jNCDa0Q==; 23:6I7DBlfvIPSDaltKUZNxgAWeEfHmJYIMWyIG4+v4QEq3eLkRwnAi9ul+lexf24KISvMdO4OO7kYn7y2lm2SGw493t6LVPXseIzGS87pWEQwvlyu1mMf5Y+zGsJs9pdhOx9PJRpQkE7kkm1Vqd+vfFOf2O028f6cO51/AIMfyKibXVy6NHCB1VkpqQeEIYEEwvVbN6dw1P6h9S7QGmOF8ri6u14smHYuC0DuqGF3yaGodfFSI4I1Ne/oHNlp8W0Ri X-OriginatorOrg: freescale.com Cc: "meta-freescale@yoctoproject.org" Subject: Re: BSP Packagegroup X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 16:21:49 -0000 Content-Type: multipart/alternative; boundary="------------050906070709080002040301" --------------050906070709080002040301 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit I am thinking of packagegroups as a way to make life easier. Graphics in particular is complicated, with some things working in one place and not another. Graphics packagegroups can handle a lot of that so a common image recipe can easily work in multiple environments and new recipes can be created more easily without having to know every detail. Having different levels allows an easy way to choose how much to include in a particular image. Packagegroups are not specific to BSP or SDK or whatever. They can be used wherever desired. Ann On 7/11/2015 9:24 AM, Daiane Angolini wrote: > On Thu, Jul 9, 2015 at 1:29 PM, Ann Thornton wrote: >> For packagegroup divisions, how about >> graphics >> multimedia >> networking >> tools >> (probably others I haven't thought of) > When we think about a set of packagegroups intended to give users a > set of useful packages or an example on how to group applications more > is more. As much as possible is good enough. (meta-fsl-demos) > > However, when you think about a BSP packagegroup, less is more. As > less as possible, as much closer to only critical packages, the > minimal set, is the optimal packagegroup. (meta-fsl-arm) > > Do we need BSP packagegroups? > > In case we do, I cannot see the need of a BSP packagegroup for graphic > (GPU) or tools. > > I would accept "tools" to be split into other sets like "audio", but > definitively not "tools". > > In fact, I can only see the need of a VPU and a CAN package groups. > Maybe audio. But I'm trying to stress the BSP packagegroup idea here, > something I'm not completely convinced of. > > > Daiane >> Each of those groups might be further divided into minimal, core, demos, >> extended as needed. >> >> Each packagegroup could check DISTRO-FEATURES, etc so that they would be as >> generic as possible. >> >> Then recipes could include the level of detail desired and they would work >> across product lines. >> >> Ann Thornton >> >> >> On 7/9/2015 9:56 AM, Daiane Angolini wrote: >> >> For me, packagegroup is only a set of packages wrapped together to >> make my life easier. >> >> Should BSP provide packagegroups to ease the addition (and removal) of >> set o BSP packages, or their “functional” dependency. For example an >> application such as aplay is needed to stress the audio functionality, >> even though there is no dependency from alsa driver from kernel with >> alsa-utils. Should BSP provide packagegroups? >> >> I think offering packagegroup options to enable BSP pieces may really >> ease the BSP usage, however I main point here is how far should BSP >> go. What is the limit between a BSP packagegroup and a "demo" >> packagegroup (as we does in meta-fsl-demos)? >> >> Thinking about a package group to provide BSP packages related with >> VPU, in my opinion it should have: >> >> * VPU firmware >> * VPU lib >> >> In case I’m using gstreamer, I would like a packagegroup like: >> >> * VPU firmware >> * VPU lib >> * gstreamer plugins for VPU (gstreamer-imx or gst1.0-fsl-plugin) >> >> In case I’m using gstreamer with kernel mainline: >> >> * VPU firmware >> * gstreamer >> >> >> Should mp3 encoder (such as lame) be part of a BSP packagegroup? And >> in GPU case? Would DEPENDS and PROVIDES be enough to include needed >> packages? >> >> Should meta-fsl-arm (or meta-freescale) provide a bluetooth BSP >> packagegroup even though there is no special hardware acceleration >> provided by meta-fsl-arm for bluetooth? >> >> >> Daiane >> >> >> >> -- >> Ann Thornton >> >> Microcontrollers Software and Applications >> Freescale Semiconductors >> email: Ann.Thornton@freescale.com >> >> -- >> _______________________________________________ >> meta-freescale mailing list >> meta-freescale@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/meta-freescale >> -- Ann Thornton /Microcontrollers Software and Applications Freescale Semiconductors email: Ann.Thornton@freescale.com/ --------------050906070709080002040301 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

I am thinking of packagegroups as a way to make life easier.  Graphics in particular is complicated, with some things working in one place and not another.  Graphics packagegroups can handle a lot of that so a common image recipe can easily work in multiple environments and new recipes can be created more easily without having to know every detail.  Having different levels allows an easy way to choose how much to include in a particular image.  Packagegroups are not specific to BSP or SDK or whatever.  They can be used wherever desired.

Ann

On 7/11/2015 9:24 AM, Daiane Angolini wrote:
On Thu, Jul 9, 2015 at 1:29 PM, Ann Thornton <Ann.Thornton@freescale.com> wrote:

For packagegroup divisions, how about
graphics
multimedia
networking
tools
(probably others I haven't thought of)

When we think about a set of packagegroups intended to give users a
set of useful packages or an example on how to group applications more
is more. As much as possible is good enough. (meta-fsl-demos)

However, when you think about a BSP packagegroup, less is more. As
less as possible, as much closer to only critical packages, the
minimal set, is the optimal packagegroup. (meta-fsl-arm)

Do we need BSP packagegroups?

In case we do, I cannot see the need of a BSP packagegroup for graphic
(GPU) or tools.

I would accept "tools" to be split into other sets like "audio", but
definitively not "tools".

In fact, I can only see the need of a VPU and a CAN package groups.
Maybe audio. But I'm trying to stress the BSP packagegroup idea here,
something I'm not completely convinced of.


Daiane

Each of those groups might be further divided into minimal, core, demos,
extended as needed.

Each packagegroup could check DISTRO-FEATURES, etc so that they would be as
generic as possible.

Then recipes could include the level of detail desired and they would work
across product lines.

Ann Thornton


On 7/9/2015 9:56 AM, Daiane Angolini wrote:

For me, packagegroup is only a set of packages wrapped together to
make my life easier.

Should BSP provide packagegroups to ease the addition (and removal) of
set o BSP packages, or their “functional” dependency. For example an
application such as aplay is needed to stress the audio functionality,
even though there is no dependency from alsa driver from kernel with
alsa-utils. Should BSP provide packagegroups?

I think offering packagegroup options to enable BSP pieces may really
ease the BSP usage, however I main point here is how far should BSP
go. What is the limit between a BSP packagegroup and a "demo"
packagegroup (as we does in meta-fsl-demos)?

Thinking about a package group to provide BSP packages related with
VPU, in my opinion it should have:

* VPU firmware
* VPU lib

In case I’m using gstreamer, I would like a packagegroup like:

* VPU firmware
* VPU lib
* gstreamer plugins for VPU (gstreamer-imx or gst1.0-fsl-plugin)

In case I’m using gstreamer with kernel mainline:

* VPU firmware
* gstreamer


Should mp3 encoder (such as lame) be part of a BSP packagegroup? And
in GPU case? Would DEPENDS and PROVIDES be enough to include needed
packages?

Should meta-fsl-arm (or meta-freescale) provide a bluetooth BSP
packagegroup even though there is no special hardware acceleration
provided by meta-fsl-arm for bluetooth?


Daiane



--
Ann Thornton

Microcontrollers Software and Applications
Freescale Semiconductors
email: Ann.Thornton@freescale.com

--
_______________________________________________
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale


--
Ann Thornton

Microcontrollers Software and Applications
Freescale Semiconductors
email: Ann.Thornton@freescale.com
--------------050906070709080002040301--