From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 24979E006EE; Tue, 7 Jul 2015 08:12:56 -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.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (picmaster[at]mail.bg) * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [193.201.172.118 listed in list.dnswl.org] * -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 mx2.mail.bg (mx2.mail.bg [193.201.172.118]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 87FFFE006B7 for ; Tue, 7 Jul 2015 08:12:46 -0700 (PDT) Received: from [192.168.0.62] (unknown [93.152.143.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx2.mail.bg (Postfix) with ESMTPSA id 95A0C60049A2; Tue, 7 Jul 2015 18:12:44 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1436281964; bh=aQfDZ6BnON3j6F9eZfgtjtbTqO1pkZxhSuIC7FEXNLk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=yYfXFqS35zBuipe4m2LmmN0LMkiHR/QOnju3qXsr2AT9lAXtEJTQgoIO9m3JBerol UExnFMsEIEjD3WVR7mAxfSVN8/AcRk4oTp/E69VI7nBkfb/7jeEzGV8gIv5KnqIn6z GN2TwEnMxacAP4KaBFh2mnZpYO+VLscMULilxxDY= Message-ID: <559BEC6C.80407@mail.bg> Date: Tue, 07 Jul 2015 18:12:44 +0300 From: Nikolay Dimitrov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Daiane Angolini , Ann Thornton References: <1436209456-28900-1-git-send-email-ra43240@freescale.com> <559AE65B.6040201@mail.bg> <559AEA1E.8000202@freescale.com> In-Reply-To: Cc: "meta-freescale@yoctoproject.org" Subject: Re: [meta-fsl-arm][PATCH v2] imx-base.inc mxs-base.inc: Add imx MACHINEOVERRIDES 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: Tue, 07 Jul 2015 15:12:56 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Daiane, On 07/07/2015 03:30 PM, Daiane Angolini wrote: > On Mon, Jul 6, 2015 at 5:50 PM, Ann Thornton wrote: >> Hi Nikolay, >> >> QorIQ will be merged into a common layer with i.MX. >> See "[meta-freescale] Freescale meta-freescale announcement of new layer" > > Ann, Nikolay, > > Currently on 1.8 (fido) of meta-fsl-arm we already have 3 different > product lines from Freescale: i.MX, Layerscape/QoirQ and Vybrid. And > currently the OVERRIDE "imx" is not exactly needed (if you think > everything has been working fine so far). > > Please see [1], the heads (imx, vybrid and layerscape) are not from > the meta-fsl-arm source code, but faked for the picture. > > Back to 1.6 RN I was able to find vybrid already being graphically > represented in a SOC Family tree. > > So, the argument that imx is needed because of meta-freescale is not > right. Having a OVERRIDE for imx and vybrid and layerscape may make > sense because of some future differentiation on the BSP regarding > product lines. > > On the other hand, if we have time, we can discuss it a lot. For > example, if you take the imx6, you see, from BSP point of view, we > have more diverging than converging packages. Would it make sense to Indeed, I also think that the "imx" family will cover a set of such widely different SoCs, so I was wondering whether there's any practical use case where we can address all these SoCs as "the imx". We already have "imx6*" overrides, which are both specific and works to separate from qoriq. > keep the "imx6" OVERRIDE today? > > I would like to have the SOC_FAMILY tree reviewed for sure. I know we > have a lot of possible enhancement there. But I really don't get the > overall picture only with this patch. > > And, the commit log is wrong. We already have non-imx machines in meta-fsl-arm. > > [1] http://freescale.github.io/doc/release-notes/1.8/index.html#soc-hierarchy > > Regards, > Daiane > > >> >> Ann >> >> On 7/6/2015 3:34 PM, Nikolay Dimitrov wrote: >> >> Hi Ann, >> >> On 07/06/2015 10:04 PM, Ann Thornton wrote: >> >> Soon non-imx machines will be added to the builds. We need to be able to >> specify imx machines to distinguish between them in recipes. This change >> allows _imx to be used to limit actions to i.MX machines. >> >> >> Can you please explain why there's this need for such generalization? >> This "imx" family covers quite a diverse set of SoCs. >> >> Regards, >> Nikolay >> >> >> >> -- >> 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 >> > > > Regards, Nikolay