Patchwork [meta-fsl-arm-extra] nitrogen6x.conf: Allow kernel provider override

login
register
mail settings
Submitter Gary Thomas
Date Oct. 30, 2013, 1:41 p.m.
Message ID <52710C89.7030903@mlbassoc.com>
Download mbox | patch
Permalink /patch/60763/
State Accepted
Delegated to: Otavio Salvador
Headers show

Comments

Gary Thomas - Oct. 30, 2013, 1:41 p.m.
This change lets the user override the choice of kernel in local.conf
Without it, there is no way to build any kernel, e.g. linux-imx, other
than the linux-boundary version.

Signed-off-by: Gary Thomas <gary@mlbassoc.com>
---
  conf/machine/nitrogen6x.conf |    2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
Eric Nelson - Oct. 30, 2013, 2:06 p.m.
On 10/30/2013 06:41 AM, Gary Thomas wrote:
> This change lets the user override the choice of kernel in local.conf
> Without it, there is no way to build any kernel, e.g. linux-imx, other
> than the linux-boundary version.
>
> Signed-off-by: Gary Thomas <gary@mlbassoc.com>
> ---
>   conf/machine/nitrogen6x.conf |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/conf/machine/nitrogen6x.conf b/conf/machine/nitrogen6x.conf
> index dbf31c5..b292d75 100644
> --- a/conf/machine/nitrogen6x.conf
> +++ b/conf/machine/nitrogen6x.conf
> @@ -33,7 +33,7 @@ include conf/machine/include/tune-cortexa9.inc
>   SOC_FAMILY = "mx6:mx6q"
>    PREFERRED_PROVIDER_u-boot = "u-boot-boundary"
> -PREFERRED_PROVIDER_virtual/kernel = "linux-boundary"
> +PREFERRED_PROVIDER_virtual/kernel ?= "linux-boundary"
>    # Use SPI NOR U-Boot by default
>   IMAGE_BOOTLOADER ?= ""

Good catch Gary.

I would warn folks that there are known omissions in the SABRE Lite
code and no Nitrogen6X support in the other trees, but you should
absolutely be able to override this, especially to use a custom tree,
so...

Acked-by: Eric Nelson <eric.nelson@boundarydevices.com>
Otavio Salvador - Oct. 30, 2013, 2:10 p.m.
On Wed, Oct 30, 2013 at 11:41 AM, Gary Thomas <gary@mlbassoc.com> wrote:
> This change lets the user override the choice of kernel in local.conf
> Without it, there is no way to build any kernel, e.g. linux-imx, other
> than the linux-boundary version.
>
> Signed-off-by: Gary Thomas <gary@mlbassoc.com>

I really dislike this.

I understand your need, and it is a valid one, but it'd be better you
to make a new machine (which includes this one) and override it there.

If we start allow all kind of override in machine configuration it
loses its meaning and complicates the support.

Eric? comments?
Eric Nelson - Oct. 30, 2013, 2:25 p.m.
Hi Otavio,

On 10/30/2013 07:10 AM, Otavio Salvador wrote:
> On Wed, Oct 30, 2013 at 11:41 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>> This change lets the user override the choice of kernel in local.conf
>> Without it, there is no way to build any kernel, e.g. linux-imx, other
>> than the linux-boundary version.
>>
>> Signed-off-by: Gary Thomas <gary@mlbassoc.com>
>
> I really dislike this.
>
> I understand your need, and it is a valid one, but it'd be better you
> to make a new machine (which includes this one) and override it there.
>

I'm not sure I understand why. It seems perfectly reasonable to me
to build a new kernel recipe and use it, while retaining other
information from the machine configuration.

I'm thinking specifically of a user who may have a custom kernel
tree with pin-muxing based on their usage.

> If we start allow all kind of override in machine configuration it
> loses its meaning and complicates the support.
>
> Eric? comments?
>

I'm not sure I understand the concern. This seems pretty
straightforward. The default is there, but a user can
over-ride it.

Regards,


Eric
Gary Thomas - Oct. 30, 2013, 2:25 p.m.
On 2013-10-30 08:10, Otavio Salvador wrote:
> On Wed, Oct 30, 2013 at 11:41 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>> This change lets the user override the choice of kernel in local.conf
>> Without it, there is no way to build any kernel, e.g. linux-imx, other
>> than the linux-boundary version.
>>
>> Signed-off-by: Gary Thomas <gary@mlbassoc.com>
>
> I really dislike this.
>
> I understand your need, and it is a valid one, but it'd be better you
> to make a new machine (which includes this one) and override it there.

Even if I did that (and I have), if I include this config file, I can
never override this setting in a soft (user settable) way.

> If we start allow all kind of override in machine configuration it
> loses its meaning and complicates the support.
>
> Eric? comments?
>

Eric has already approved this change.
Otavio Salvador - Oct. 30, 2013, 2:28 p.m.
Hello Eric,

On Wed, Oct 30, 2013 at 12:25 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
> On 10/30/2013 07:10 AM, Otavio Salvador wrote:
>>
>> On Wed, Oct 30, 2013 at 11:41 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>
>>> This change lets the user override the choice of kernel in local.conf
>>> Without it, there is no way to build any kernel, e.g. linux-imx, other
>>> than the linux-boundary version.
>>>
>>> Signed-off-by: Gary Thomas <gary@mlbassoc.com>
>>
>>
>> I really dislike this.
>>
>> I understand your need, and it is a valid one, but it'd be better you
>> to make a new machine (which includes this one) and override it there.
>>
>
> I'm not sure I understand why. It seems perfectly reasonable to me
> to build a new kernel recipe and use it, while retaining other
> information from the machine configuration.
>
> I'm thinking specifically of a user who may have a custom kernel
> tree with pin-muxing based on their usage.

I see the point and I do have this case internally here; the point is
if we have it 'soft' and someone reports:

Nitrogen6X is not working. Next question needs to be, are you using
linux-boundary or another?

>> If we start allow all kind of override in machine configuration it
>> loses its meaning and complicates the support.
>>
>> Eric? comments?
>>
>
> I'm not sure I understand the concern. This seems pretty
> straightforward. The default is there, but a user can
> over-ride it.

If user forks the kernel, adding a machine .conf  file is the easiest
part of it. I'd to avoid support uncertainty regarding settings.
Otavio Salvador - Oct. 30, 2013, 2:33 p.m.
On Wed, Oct 30, 2013 at 12:25 PM, Gary Thomas <gary@mlbassoc.com> wrote:
> On 2013-10-30 08:10, Otavio Salvador wrote:
>>
>> On Wed, Oct 30, 2013 at 11:41 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>
>>> This change lets the user override the choice of kernel in local.conf
>>> Without it, there is no way to build any kernel, e.g. linux-imx, other
>>> than the linux-boundary version.
>>>
>>> Signed-off-by: Gary Thomas <gary@mlbassoc.com>
>>
>>
>> I really dislike this.
>>
>> I understand your need, and it is a valid one, but it'd be better you
>> to make a new machine (which includes this one) and override it there.
>
> Even if I did that (and I have), if I include this config file, I can
> never override this setting in a soft (user settable) way.

Then you can force it in your machine.

>> If we start allow all kind of override in machine configuration it
>> loses its meaning and complicates the support.
>>
>> Eric? comments?
>>
>
> Eric has already approved this change.

This is not up to me but I'd like to discuss it a little bit further
before merging it...

My main concern about this is the support. As I said it is a valid
use-case but /most/ people will end with a .conf for the custom
settings in the end with their internal fork or so. Do it in
local.conf or environment is not advised as it is easy to be forgotten
or do wrong so for every product it is better to have a .conf in case
it needs specific kernel/u-boot patches.
Eric Nelson - Oct. 30, 2013, 2:42 p.m.
Hi Otavio,

On 10/30/2013 07:28 AM, Otavio Salvador wrote:
> Hello Eric,
>
> On Wed, Oct 30, 2013 at 12:25 PM, Eric Nelson
> <eric.nelson@boundarydevices.com> wrote:
>> On 10/30/2013 07:10 AM, Otavio Salvador wrote:
>>>
>>> On Wed, Oct 30, 2013 at 11:41 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>
>>>> This change lets the user override the choice of kernel in local.conf
>>>> Without it, there is no way to build any kernel, e.g. linux-imx, other
>>>> than the linux-boundary version.
>>>>
>>>> Signed-off-by: Gary Thomas <gary@mlbassoc.com>
>>>
>>>
>>> I really dislike this.
>>>
>>> I understand your need, and it is a valid one, but it'd be better you
>>> to make a new machine (which includes this one) and override it there.
>>>
>>
>> I'm not sure I understand why. It seems perfectly reasonable to me
>> to build a new kernel recipe and use it, while retaining other
>> information from the machine configuration.
>>
>> I'm thinking specifically of a user who may have a custom kernel
>> tree with pin-muxing based on their usage.
>
> I see the point and I do have this case internally here; the point is
> if we have it 'soft' and someone reports:
>
> Nitrogen6X is not working. Next question needs to be, are you using
> linux-boundary or another?
>

I understand your point, but it's going to happen anyway. The beauty
(and curse) of flexible hardware is that it's flexible ;)

I think the best we can hope for in terms of support is to always
ask if a failure occurs with a "stock" build... Fresh "repo sync",
specified U-Boot, et cetera.

I don't know if hard-coding this value will meaningfully change
things.

>>> If we start allow all kind of override in machine configuration it
>>> loses its meaning and complicates the support.
>>>
>>> Eric? comments?
>>>
>>
>> I'm not sure I understand the concern. This seems pretty
>> straightforward. The default is there, but a user can
>> over-ride it.
>
> If user forks the kernel, adding a machine .conf  file is the easiest
> part of it. I'd to avoid support uncertainty regarding settings.
>

That's true, too (machine configurations aren't very complicated), but
my understanding of that is recent.

Regards,


Eric
Gary Thomas - Oct. 30, 2013, 2:44 p.m.
On 2013-10-30 08:33, Otavio Salvador wrote:
> On Wed, Oct 30, 2013 at 12:25 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>> On 2013-10-30 08:10, Otavio Salvador wrote:
>>>
>>> On Wed, Oct 30, 2013 at 11:41 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>
>>>> This change lets the user override the choice of kernel in local.conf
>>>> Without it, there is no way to build any kernel, e.g. linux-imx, other
>>>> than the linux-boundary version.
>>>>
>>>> Signed-off-by: Gary Thomas <gary@mlbassoc.com>
>>>
>>>
>>> I really dislike this.
>>>
>>> I understand your need, and it is a valid one, but it'd be better you
>>> to make a new machine (which includes this one) and override it there.
>>
>> Even if I did that (and I have), if I include this config file, I can
>> never override this setting in a soft (user settable) way.
>
> Then you can force it in your machine.
>
>>> If we start allow all kind of override in machine configuration it
>>> loses its meaning and complicates the support.
>>>
>>> Eric? comments?
>>>
>>
>> Eric has already approved this change.
>
> This is not up to me but I'd like to discuss it a little bit further
> before merging it...
>
> My main concern about this is the support. As I said it is a valid
> use-case but /most/ people will end with a .conf for the custom
> settings in the end with their internal fork or so. Do it in
> local.conf or environment is not advised as it is easy to be forgotten
> or do wrong so for every product it is better to have a .conf in case
> it needs specific kernel/u-boot patches.
>

A reasonable concern.  I do note that having this be soft in <MACHINE>.conf
seems to be common practice in the rest of the Yocto world.
Otavio Salvador - Oct. 30, 2013, 4:01 p.m.
On Wed, Oct 30, 2013 at 12:44 PM, Gary Thomas <gary@mlbassoc.com> wrote:
> On 2013-10-30 08:33, Otavio Salvador wrote:
>>
>> On Wed, Oct 30, 2013 at 12:25 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>
>>> On 2013-10-30 08:10, Otavio Salvador wrote:
>>>>
>>>>
>>>> On Wed, Oct 30, 2013 at 11:41 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>
>>>>>
>>>>> This change lets the user override the choice of kernel in local.conf
>>>>> Without it, there is no way to build any kernel, e.g. linux-imx, other
>>>>> than the linux-boundary version.
>>>>>
>>>>> Signed-off-by: Gary Thomas <gary@mlbassoc.com>
>>>>
>>>>
>>>>
>>>> I really dislike this.
>>>>
>>>> I understand your need, and it is a valid one, but it'd be better you
>>>> to make a new machine (which includes this one) and override it there.
>>>
>>>
>>> Even if I did that (and I have), if I include this config file, I can
>>> never override this setting in a soft (user settable) way.
>>
>>
>> Then you can force it in your machine.
>>
>>>> If we start allow all kind of override in machine configuration it
>>>> loses its meaning and complicates the support.
>>>>
>>>> Eric? comments?
>>>>
>>>
>>> Eric has already approved this change.
>>
>>
>> This is not up to me but I'd like to discuss it a little bit further
>> before merging it...
>>
>> My main concern about this is the support. As I said it is a valid
>> use-case but /most/ people will end with a .conf for the custom
>> settings in the end with their internal fork or so. Do it in
>> local.conf or environment is not advised as it is easy to be forgotten
>> or do wrong so for every product it is better to have a .conf in case
>> it needs specific kernel/u-boot patches.
>>
>
> A reasonable concern.  I do note that having this be soft in <MACHINE>.conf
> seems to be common practice in the rest of the Yocto world.

Ok; you guys won :-)

I applied it to dora and master (I manually applied it as it has not
applied cleanly).

Eric, please, if you have time do the same change in nitrogen6x-lite
so it is kept in sync.
Eric Nelson - Oct. 30, 2013, 4:16 p.m.
On 10/30/2013 09:01 AM, Otavio Salvador wrote:
> On Wed, Oct 30, 2013 at 12:44 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>> On 2013-10-30 08:33, Otavio Salvador wrote:
>>> On Wed, Oct 30, 2013 at 12:25 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>> On 2013-10-30 08:10, Otavio Salvador wrote:
>>>>> On Wed, Oct 30, 2013 at 11:41 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>>
>>>>>> This change lets the user override the choice of kernel in local.conf
>>>>>> Without it, there is no way to build any kernel, e.g. linux-imx, other
>>>>>> than the linux-boundary version.
>>>>>>
>>>>>> Signed-off-by: Gary Thomas <gary@mlbassoc.com>
>>>>>
>>>>> I really dislike this.
>>>>>
>>>>> I understand your need, and it is a valid one, but it'd be better you
>>>>> to make a new machine (which includes this one) and override it there.
>>>>
>>>> Even if I did that (and I have), if I include this config file, I can
>>>> never override this setting in a soft (user settable) way.
>>>
>>> Then you can force it in your machine.
>>>
>>>>> If we start allow all kind of override in machine configuration it
>>>>> loses its meaning and complicates the support.
>>>>>
>>>>> Eric? comments?
>>>>>
>>>> Eric has already approved this change.
>>>
>>> This is not up to me but I'd like to discuss it a little bit further
>>> before merging it...
>>>
>>> My main concern about this is the support. As I said it is a valid
>>> use-case but /most/ people will end with a .conf for the custom
>>> settings in the end with their internal fork or so. Do it in
>>> local.conf or environment is not advised as it is easy to be forgotten
>>> or do wrong so for every product it is better to have a .conf in case
>>> it needs specific kernel/u-boot patches.
>>
>> A reasonable concern.  I do note that having this be soft in <MACHINE>.conf
>> seems to be common practice in the rest of the Yocto world.
>
> Ok; you guys won :-)
>
> I applied it to dora and master (I manually applied it as it has not
> applied cleanly).
>
> Eric, please, if you have time do the same change in nitrogen6x-lite
> so it is kept in sync.
>

Will do.
Daiane Angolini - Oct. 30, 2013, 4:56 p.m.
On Wed, Oct 30, 2013 at 2:01 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Wed, Oct 30, 2013 at 12:44 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>> On 2013-10-30 08:33, Otavio Salvador wrote:
>>>
>>> On Wed, Oct 30, 2013 at 12:25 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>
>>>> On 2013-10-30 08:10, Otavio Salvador wrote:
>>>>>
>>>>>
>>>>> On Wed, Oct 30, 2013 at 11:41 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>>
>>>>>>
>>>>>> This change lets the user override the choice of kernel in local.conf
>>>>>> Without it, there is no way to build any kernel, e.g. linux-imx, other
>>>>>> than the linux-boundary version.
>>>>>>
>>>>>> Signed-off-by: Gary Thomas <gary@mlbassoc.com>
>>>>>
>>>>>
>>>>>
>>>>> I really dislike this.
>>>>>
>>>>> I understand your need, and it is a valid one, but it'd be better you
>>>>> to make a new machine (which includes this one) and override it there.
>>>>
>>>>
>>>> Even if I did that (and I have), if I include this config file, I can
>>>> never override this setting in a soft (user settable) way.
>>>
>>>
>>> Then you can force it in your machine.
>>>
>>>>> If we start allow all kind of override in machine configuration it
>>>>> loses its meaning and complicates the support.
>>>>>
>>>>> Eric? comments?
>>>>>
>>>>
>>>> Eric has already approved this change.
>>>
>>>
>>> This is not up to me but I'd like to discuss it a little bit further
>>> before merging it...
>>>
>>> My main concern about this is the support. As I said it is a valid
>>> use-case but /most/ people will end with a .conf for the custom
>>> settings in the end with their internal fork or so. Do it in
>>> local.conf or environment is not advised as it is easy to be forgotten
>>> or do wrong so for every product it is better to have a .conf in case
>>> it needs specific kernel/u-boot patches.
>>>
>>
>> A reasonable concern.  I do note that having this be soft in <MACHINE>.conf
>> seems to be common practice in the rest of the Yocto world.
>
> Ok; you guys won :-)
>
> I applied it to dora and master (I manually applied it as it has not
> applied cleanly).
>
> Eric, please, if you have time do the same change in nitrogen6x-lite
> so it is kept in sync.

I do agree with both sides. But I think you didn´t presented the
complete set of possibilities. I mean, it´s not a "support" X
"flexibility" fight.

If nitrogen-any deserves to be flexible, so all other deserves it the same way.

If it´s "wrong" for one board. It´s "wrong" for any. So, please submit
the patch to fix all/every board.

As I really don´t have an strong position for this. I would say, let´s
change and see what´s happens.

For support nightmare, we always need to say what is
u-boot/kernel/yocto problem in this ML, so the nightmare is already
here.

But, in my opinion, it´s NOT a bug fix, and should NOT be merged in dora.


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
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
Otavio Salvador - Oct. 30, 2013, 5:29 p.m.
On Wed, Oct 30, 2013 at 2:56 PM, Daiane Angolini <daiane.list@gmail.com> wrote:
> On Wed, Oct 30, 2013 at 2:01 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> On Wed, Oct 30, 2013 at 12:44 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>>> On 2013-10-30 08:33, Otavio Salvador wrote:
>>>>
>>>> On Wed, Oct 30, 2013 at 12:25 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>
>>>>> On 2013-10-30 08:10, Otavio Salvador wrote:
>>>>>>
>>>>>>
>>>>>> On Wed, Oct 30, 2013 at 11:41 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> This change lets the user override the choice of kernel in local.conf
>>>>>>> Without it, there is no way to build any kernel, e.g. linux-imx, other
>>>>>>> than the linux-boundary version.
>>>>>>>
>>>>>>> Signed-off-by: Gary Thomas <gary@mlbassoc.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I really dislike this.
>>>>>>
>>>>>> I understand your need, and it is a valid one, but it'd be better you
>>>>>> to make a new machine (which includes this one) and override it there.
>>>>>
>>>>>
>>>>> Even if I did that (and I have), if I include this config file, I can
>>>>> never override this setting in a soft (user settable) way.
>>>>
>>>>
>>>> Then you can force it in your machine.
>>>>
>>>>>> If we start allow all kind of override in machine configuration it
>>>>>> loses its meaning and complicates the support.
>>>>>>
>>>>>> Eric? comments?
>>>>>>
>>>>>
>>>>> Eric has already approved this change.
>>>>
>>>>
>>>> This is not up to me but I'd like to discuss it a little bit further
>>>> before merging it...
>>>>
>>>> My main concern about this is the support. As I said it is a valid
>>>> use-case but /most/ people will end with a .conf for the custom
>>>> settings in the end with their internal fork or so. Do it in
>>>> local.conf or environment is not advised as it is easy to be forgotten
>>>> or do wrong so for every product it is better to have a .conf in case
>>>> it needs specific kernel/u-boot patches.
>>>>
>>>
>>> A reasonable concern.  I do note that having this be soft in <MACHINE>.conf
>>> seems to be common practice in the rest of the Yocto world.
>>
>> Ok; you guys won :-)
>>
>> I applied it to dora and master (I manually applied it as it has not
>> applied cleanly).
>>
>> Eric, please, if you have time do the same change in nitrogen6x-lite
>> so it is kept in sync.
>
> I do agree with both sides. But I think you didn´t presented the
> complete set of possibilities. I mean, it´s not a "support" X
> "flexibility" fight.
>
> If nitrogen-any deserves to be flexible, so all other deserves it the same way.
>
> If it´s "wrong" for one board. It´s "wrong" for any. So, please submit
> the patch to fix all/every board.

Agreed here.

> As I really don´t have an strong position for this. I would say, let´s
> change and see what´s happens.
>
> For support nightmare, we always need to say what is
> u-boot/kernel/yocto problem in this ML, so the nightmare is already
> here.

:-(

> But, in my opinion, it´s NOT a bug fix, and should NOT be merged in dora.

Yes I agree it is not a bugfix but I think that it'd be better to be
consistent with dora and master at this point. Most people will keep
using dora for a while and it'd be better to have this deplyed now
than see how it goes in 1.6 only.

Comments?
Eric Nelson - Oct. 30, 2013, 5:46 p.m.
Hi Otavio,

On 10/30/2013 10:29 AM, Otavio Salvador wrote:
> On Wed, Oct 30, 2013 at 2:56 PM, Daiane Angolini <daiane.list@gmail.com> wrote:
>> On Wed, Oct 30, 2013 at 2:01 PM, Otavio Salvador
>> <otavio@ossystems.com.br> wrote:
>>> On Wed, Oct 30, 2013 at 12:44 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>> On 2013-10-30 08:33, Otavio Salvador wrote:
>>>>> On Wed, Oct 30, 2013 at 12:25 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>> On 2013-10-30 08:10, Otavio Salvador wrote:
>>>>>>> On Wed, Oct 30, 2013 at 11:41 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>>>>
>>>>>>>> This change lets the user override the choice of kernel in local.conf
>>>>>>>> Without it, there is no way to build any kernel, e.g. linux-imx, other
>>>>>>>> than the linux-boundary version.
>>>>>>>>
>>>>>>>> Signed-off-by: Gary Thomas <gary@mlbassoc.com>
>>>>>>>
>>
 >> <snip>
 >>
>> I do agree with both sides. But I think you didn´t presented the
>> complete set of possibilities. I mean, it´s not a "support" X
>> "flexibility" fight.
>>
>> If nitrogen-any deserves to be flexible, so all other deserves it the same way.
>>
>> If it´s "wrong" for one board. It´s "wrong" for any. So, please submit
>> the patch to fix all/every board.
>
> Agreed here.
>
Works for me.

Gary, do you want to take the patch? Otavio asked me 'cause he
was asking about our board...

>> As I really don´t have an strong position for this. I would say, let´s
>> change and see what´s happens.
>>
>> For support nightmare, we always need to say what is
>> u-boot/kernel/yocto problem in this ML, so the nightmare is already
>> here.
>
> :-(
>

Aww, it's not a nightmare. It's a jobs program ;)

>> But, in my opinion, it´s NOT a bug fix, and should NOT be merged in dora.
>
> Yes I agree it is not a bugfix but I think that it'd be better to be
> consistent with dora and master at this point. Most people will keep
> using dora for a while and it'd be better to have this deplyed now
> than see how it goes in 1.6 only.
>
> Comments?
>

Gary, did you ever think a single question mark would prompt so much
discussion?

I wish we had a clean "MAKEALL" to make sure nothing breaks, but that
seems unlikely.

Regards,


Eric
Otavio Salvador - Oct. 30, 2013, 5:51 p.m.
Hello,

On Wed, Oct 30, 2013 at 3:46 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
> On 10/30/2013 10:29 AM, Otavio Salvador wrote:
>> On Wed, Oct 30, 2013 at 2:56 PM, Daiane Angolini <daiane.list@gmail.com>
>> wrote:
>>> But, in my opinion, it´s NOT a bug fix, and should NOT be merged in dora.
>>
>>
>> Yes I agree it is not a bugfix but I think that it'd be better to be
>> consistent with dora and master at this point. Most people will keep
>> using dora for a while and it'd be better to have this deplyed now
>> than see how it goes in 1.6 only.
>>
>> Comments?
>>
>
> Gary, did you ever think a single question mark would prompt so much
> discussion?

The 'question mark' has a very strong meaning in 'bitbake-language'.

> I wish we had a clean "MAKEALL" to make sure nothing breaks, but that
> seems unlikely.

I do build /all/ board weekly :-) I look for help here ;-)
Gary Thomas - Oct. 30, 2013, 6:04 p.m.
On 2013-10-30 11:46, Eric Nelson wrote:
> Hi Otavio,
>
> On 10/30/2013 10:29 AM, Otavio Salvador wrote:
>> On Wed, Oct 30, 2013 at 2:56 PM, Daiane Angolini <daiane.list@gmail.com> wrote:
>>> On Wed, Oct 30, 2013 at 2:01 PM, Otavio Salvador
>>> <otavio@ossystems.com.br> wrote:
>>>> On Wed, Oct 30, 2013 at 12:44 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>> On 2013-10-30 08:33, Otavio Salvador wrote:
>>>>>> On Wed, Oct 30, 2013 at 12:25 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>>> On 2013-10-30 08:10, Otavio Salvador wrote:
>>>>>>>> On Wed, Oct 30, 2013 at 11:41 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>>>>>
>>>>>>>>> This change lets the user override the choice of kernel in local.conf
>>>>>>>>> Without it, there is no way to build any kernel, e.g. linux-imx, other
>>>>>>>>> than the linux-boundary version.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Gary Thomas <gary@mlbassoc.com>
>>>>>>>>
>>>
>>> <snip>
>>>
>>> I do agree with both sides. But I think you didn´t presented the
>>> complete set of possibilities. I mean, it´s not a "support" X
>>> "flexibility" fight.
>>>
>>> If nitrogen-any deserves to be flexible, so all other deserves it the same way.
>>>
>>> If it´s "wrong" for one board. It´s "wrong" for any. So, please submit
>>> the patch to fix all/every board.
>>
>> Agreed here.
>>
> Works for me.
>
> Gary, do you want to take the patch? Otavio asked me 'cause he
> was asking about our board...

Sure, I'll take this on for all the boards in meta-fsl-arm-*  Look for
it later today or tomorrow.

>
>>> As I really don´t have an strong position for this. I would say, let´s
>>> change and see what´s happens.
>>>
>>> For support nightmare, we always need to say what is
>>> u-boot/kernel/yocto problem in this ML, so the nightmare is already
>>> here.
>>
>> :-(
>>
>
> Aww, it's not a nightmare. It's a jobs program ;)
>
>>> But, in my opinion, it´s NOT a bug fix, and should NOT be merged in dora.
>>
>> Yes I agree it is not a bugfix but I think that it'd be better to be
>> consistent with dora and master at this point. Most people will keep
>> using dora for a while and it'd be better to have this deplyed now
>> than see how it goes in 1.6 only.
>>
>> Comments?
>>
>
> Gary, did you ever think a single question mark would prompt so much
> discussion?

Not unlike the recent headline "Single bit error in Toyota firmware kills ..."

>
> I wish we had a clean "MAKEALL" to make sure nothing breaks, but that
> seems unlikely.

Patch

diff --git a/conf/machine/nitrogen6x.conf b/conf/machine/nitrogen6x.conf
index dbf31c5..b292d75 100644
--- a/conf/machine/nitrogen6x.conf
+++ b/conf/machine/nitrogen6x.conf
@@ -33,7 +33,7 @@  include conf/machine/include/tune-cortexa9.inc
  SOC_FAMILY = "mx6:mx6q"
   PREFERRED_PROVIDER_u-boot = "u-boot-boundary"
-PREFERRED_PROVIDER_virtual/kernel = "linux-boundary"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-boundary"
   # Use SPI NOR U-Boot by default
  IMAGE_BOOTLOADER ?= ""
-- 
1.7.9.5
_______________________________________________