[meta-freescale] [meta-fsl-demos][PATCH] riotboard: Fix broken image builds against linux-fslc

[Otavio Salvador]

On Mon, May 11, 2015 at 8:42 PM, Nikolay Dimitrov <picmaster at mail.bg> wrote:
> On 05/11/2015 08:46 PM, Otavio Salvador wrote:
>> On Mon, May 11, 2015 at 2:24 PM, Nikolay Dimitrov <picmaster at mail.bg>
>> wrote:
>>>
>>> Hi Otavio,
>>>
>>> On 05/11/2015 08:09 PM, Otavio Salvador wrote:
>>>>
>>>>
>>>> On Mon, May 11, 2015 at 1:43 PM, Nikolay Dimitrov
>>>> <picmaster at mail.bg> wrote:
>>>>>
>>>>>
>>>>> Ping.
>>>>
>>>>
>>>>
>>>> I am building it here for testing.
>>>
>>>
>>>
>>> That's great, thanks for looking into it.
>>
>>
>> Your patch can get a change:
>>
>> diff --git a/conf/machine/imx6dl-riotboard.conf
>> b/conf/machine/imx6dl-riotboard.conf index bf50eaf..260deed 100644
>> --- a/conf/machine/imx6dl-riotboard.conf +++
>> b/conf/machine/imx6dl-riotboard.conf @@ -19,4 +19,4 @@ SERIAL_CONSOLE
>> = "115200 ttymxc1" # FIXME: Workaround for building against
>> linux-fslc MACHINE_EXTRA_RRECOMMENDS_remove = "fsl-alsa-plugins"
>> PREFERRED_VERSION_imx-test = "00.00.00" -MACHINE_GSTREAMER_PLUGIN =
>> "" +MACHINE_GSTREAMER_PLUGIN_imx6dl-riotboard = ""
>>
>> This makes the patch in meta-fsl-demos not needed and seems cleaner.
>>
>> Can you take a look and confirm?
>
>
> This code sits in riotboard-specific conf file, so there's no difference
> between MACHINE_GSTREAMER_PLUGIN and
> MACHINE_GSTREAMER_PLUGIN_imx6dl-riotboard variables. The machine suffix
> is redundant in the 2nd case. But even if I use the proposed
> MACHINE_GSTREAMER_PLUGIN_imx6dl-riotboard, the fsl-image-multimedia-full
> image build still fails.

I reproduced it here. It fails only with X11 and my test was using
Framebuffer. I have sent a patch for review.

> Regarding the meta-fsl-demos patch - the need for this fix is because
> the packagegroup-fsl-gstreamer-full.bb is again adding the
> gst-plugins-gl dependency, disregarding the available capabilities
> (either hardware or kernel).

See above.

> So, my motivation for doing it this way for short term is the following:
> 1. I still have single kernel to maintain (fslc) as of today.
> 2. The board builds are broken at least since 23.April and I have to do
> something about it.
>
> FYI, for a long-term solution I plan to do the following, if you agree:
> - Support building multiple kernels, including both FSL and FSLC
> - Somehow declare the capabilities of the hardware/kernel and take it
> into account by in recipes. We need something like KERNEL_FEATURES and
> MACHINE_FEATURES, and only if a feature is declared by both variables,
> then it should be used (not sure whether this is the same as the
> COMBINED_FEATURES mechanism). I'm looking towards your ideas here, as
> you guys have much more Yocto experience than me.
>
> To summarize: my patch set is not perfect, but as of today we don't
> have all the ingredients to make it perfect. Tomorrow we could have
> these ingredients, but I can't see how far is this tomorrow.

The biggest challenge here is how to express KERNEL_FEATURES which are
recipe/provider specific.

We have some providers:

 linux-fslc
 linux-imx
 linux-<vendor>

and each can provide different kernel features. I agree with the long
term plan but I didn't yet came up with something which scales and
work.


-- 
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