From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 3213BE009D7; Thu, 9 Jul 2015 07:54:23 -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=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.215.44 listed in list.dnswl.org] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (daiane.list[at]gmail.com) * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id CF56AE009A7 for ; Thu, 9 Jul 2015 07:54:16 -0700 (PDT) Received: by lagc2 with SMTP id c2so245002518lag.3 for ; Thu, 09 Jul 2015 07:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ObczFNvVh3OafdTB/fvDY4RR8jvyl+MeRGQaYi5dNlk=; b=zdbMIL9as9qeyJwwscV7iHWiUVVBWBjy4Fw9q88U4S8H7HtvFbbSf8WAxTjC8gKOgN acLxOJtrtx/EU/rNuBNq5XLZJ9l8jRbfFvDquPChhdgkdTjgV6mRlWDQWry8Z2AFsHj6 bIv9tK0MKNQPE8+xOvbjhYmGj5YLm8KFoZawoh9LuBzh/WAHv5O1dXysBDTLeYuGipWI tEqy8hPUAkDxtqv3Er3QMce/jCSzje7yyjqMNJJRnzGETteN//XNcKCHRB0hGiHX7DQ+ Tao5X6jBt8LBt5lMwZd2Cz2fQb1Uh4ShTNIYH6j4j0hu41WeA1RTDU1BaC7NppMJ3pZ0 kUgg== MIME-Version: 1.0 X-Received: by 10.112.156.70 with SMTP id wc6mr15040833lbb.97.1436453654939; Thu, 09 Jul 2015 07:54:14 -0700 (PDT) Sender: angolini@gmail.com X-Google-Sender-Delegation: angolini@gmail.com Received: by 10.114.81.106 with HTTP; Thu, 9 Jul 2015 07:54:14 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Jul 2015 11:54:14 -0300 X-Google-Sender-Auth: VwL5F9xuroTotXYvanzajcs_SQY Message-ID: From: Daiane Angolini To: Otavio Salvador Cc: "meta-freescale@yoctoproject.org" Subject: Re: SOC_FAMILY Rework 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: Thu, 09 Jul 2015 14:54:23 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 9, 2015 at 11:05 AM, Otavio Salvador wrote: > Hello Daiane, > > First, thank you for preparing this e-mail. > > On Wed, Jul 8, 2015 at 4:42 PM, Daiane Angolini w= rote: >> We have today the following SOC_FAMILY tree (for meta-fsl-arm) >> >> i.MX -> mx3 -> mx31; >> i.MX -> mx3 -> mx35; >> i.MX -> mx5 -> mx51; >> i.MX -> mx5 -> mx53; >> i.MX -> mx6 -> mx6dl; >> i.MX -> mx6 -> mx6q; >> i.MX -> mx6 -> mx6sl; >> i.MX -> mx6 -> mx6sx; >> i.MX -> mxs -> mx23; >> i.MX -> mxs -> mx28; > > Those are fine, as far as I can see. I'm sorry, Otavio, but you are not re-thinking what we have. I don't think this list is fine. I don't see why to separate imx5 from imxs. And, after GCC 5.X is up and linux-imx_2.6.35 is gone, imx5 will be exactly like a imx3. > >> Layerscape -> ls102xa; > > I think this should be: > > qoriq -> qoriq-arm -> ls102xa > >> Vybrid -> vf -> vf50; >> Vybrid -> vf -> vf60; > > I would change this for: > > vybrid > vf50; > vybrid > vf60; > > ... >> Some of the points I think is important to consider when choosing a >> OVERRIDE tree is the SoC divergence and convergence. In i.MX case, we >> have some obvious examples such as GPU type, existence of VPU, and >> machine features such as CAN (although imx6 generally supports CAN, >> there are some board with connector, and other without it). >> >> In CAN case, CAN is a SoC feature enabled by the board or not. In WIFI >> case, it=E2=80=99s only a board feature. >> >> So, the points to rule the OVERRIDE is SoC features and board features. > > Not really. > > The SoC override is to offer a way to modify the source for ALL boards > and also to offer the possibility to cluster binary compatible > binaries. > > This ends affecting the MACHINE_SOCARCH and the SoC subarch we > designed to avoid too much rebuilds. Features as CAN or WIFI are > machine features and shouldn't be mapped for SoC overrides. ok > >> Another important thing to keep in mind is the deepness. How deep >> should be the OVERRIDE tree? Two or tree levels? > > Not a big deal; it depends if it makes usage sense or not. Current set > seems good for me. In fact I think it's a big deal. Maybe there is not so much difference between 2 and 3, but if you think about 30 levels it is indeed a big deal. I understand the number of levels is arbitrary. But it only means we must decide which are the prefect deepness. > >> OVERRIDE should be used to cluster BSP packages and configurations >> accordingly with SoC and machine features. Today the meta-fsl-arm BSP >> packages can be seen in the table [1]. Most of packages are the same >> for all i.MX boards (including kernel and u-boot not included in the >> table), but some are very specific to a group of SoCs only (i.e. >> fsl-alsa-plugins), and there is the case where a package is for only >> one SoC Family, but has big inner segmentation (Vivante) >> >> [1] https://github.com/Freescale/Documentation/blob/master/release-notes= /source/soc-pkg-optimization.inc > > Agreed. > >> The classic example of a crazy OVERRIDE is =E2=80=98mxs=E2=80=99. It was= included in >> the past to cluster imx23 and imx28 because they are the only 2 board >> using imx-bootlets. Does =E2=80=98mxs=E2=80=99 make sense nowaday? Would= imx6UL be >> more related with imx28 than with imx6Q? Would imx6SX be clustered >> with vf60? > > I think UL will end being a mx6ul and it will demand the check of all > mx6 uses to see if it is compatible or not. See Lauren's patch > regarding the GPU presence in Weston for an example. > >> Maybe, we can concentrate the OVERRIDE only around GPU and VPU. We >> have an extensive segmentation of OVERRIDE for imx6, and a cluster for >> all the SoCs without GPU (vf,layerscape?,imx2,imx3,imx6UL, imx7) > > It does not work. The point of OVERRIDE is to make changes in a set of > SoCs and we cannot contaminate other BSP (Intel, TI, Samsung, > Qualcomm...) GPU is a SoC characteristic, and it's obvious it's the most important BSP piece on i.MX6 family. Instead of having a tree like: imx -> imx6 -> everysingle soc We could have something like: imx -> imx6-light -> ligh socs imx -> imx6-heavy -> heavy socs and, instead of list "everysingle soc" when setting GPU BSP, we can list only "light and heavy". The downside is to list "light and heavy" in packages for imx6 I don't see how it will contaminate other BSP. I'm trying to stress the imx OVERRIDE just included. > >> I only thing this is the right timing to review and rework SOC_FAMILY. >> I'm i.MX biased, so I can only say about i.MX, would be glad to hear >> feedback from Vybrid and QoirQ. > > As I said before, the QorIQ should have common and arch specific > overrides (I see the former going to be most used) and i.MX global > override will be rarely used. One argument to keep things like it is today is learning curve one argument to change it in meta-freescale is upgrade path Daiane > > -- > Otavio Salvador O.S. Systems > http://www.ossystems.com.br http://code.ossystems.com.br > Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750