All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Dimitrov <picmaster@mail.bg>
To: Daiane Angolini <daiane.list@gmail.com>,
	 Ann Thornton <Ann.Thornton@freescale.com>
Cc: "meta-freescale@yoctoproject.org" <meta-freescale@yoctoproject.org>
Subject: Re: [meta-fsl-arm][PATCH v2] imx-base.inc mxs-base.inc: Add imx MACHINEOVERRIDES
Date: Tue, 07 Jul 2015 18:12:44 +0300	[thread overview]
Message-ID: <559BEC6C.80407@mail.bg> (raw)
In-Reply-To: <CA+jg_OUi-2vxG37kMfTSstZPtaBSGmH_WaKeR5vmRwc1feX3TQ@mail.gmail.com>

Hi Daiane,

On 07/07/2015 03:30 PM, Daiane Angolini wrote:
> On Mon, Jul 6, 2015 at 5:50 PM, Ann Thornton <Ann.Thornton@freescale.com> 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


  reply	other threads:[~2015-07-07 15:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-06 19:04 [meta-fsl-arm][PATCH v2] imx-base.inc mxs-base.inc: Add imx MACHINEOVERRIDES Ann Thornton
2015-07-06 20:34 ` Nikolay Dimitrov
2015-07-06 20:50   ` Ann Thornton
2015-07-07 12:30     ` Daiane Angolini
2015-07-07 15:12       ` Nikolay Dimitrov [this message]
2015-07-07 16:33         ` Otavio Salvador
2015-07-08 14:33         ` Ann Thornton
2015-07-08 14:41           ` Otavio Salvador
2015-07-08 15:56             ` Daiane Angolini
2015-07-08 17:00               ` Otavio Salvador
2015-07-08 19:39                 ` Daiane Angolini
2015-07-08 17:58           ` Nikolay Dimitrov
  -- strict thread matches above, loose matches on Subject: below --
2015-07-08 20:11 Ann Thornton
2015-07-08 20:15 ` Ann Thornton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=559BEC6C.80407@mail.bg \
    --to=picmaster@mail.bg \
    --cc=Ann.Thornton@freescale.com \
    --cc=daiane.list@gmail.com \
    --cc=meta-freescale@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.