linux-fslc-lts-4.19

linux-fslc-lts-4.19

[Andy Pont]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

I am trying to create a Yocto Warrior buid for the i.MX6Q SABRE SDP 
board that I have using the linux-fslc-lts-4.19 kernel.  In my 
local.conf file I have the following:

MACHINE = “imx6qdlsabresd”
DISTRO = "fslc-framebuffer”

PREFERRED_PROVIDER_virtual/kernel = "linux-fslc-lts-4.19”

When I try to build it fails saying it doesn’t know how to build 
imx6qp-sabresd-btwifi.dtb

  make[3]: *** No rule to make target 
'arch/arm/boot/dts/imx6qp-sabresd-btwifi.dtb'.  Stop.

Is there some magic needed to only get it to use the default DTS file?

-Andy.

[-- Attachment #2: Type: text/html, Size: 1288 bytes --]

Re: linux-fslc-lts-4.19

[Bas Mevissen]

On 8/19/19 12:01 PM, Andy Pont wrote:
> I am trying to create a Yocto Warrior buid for the i.MX6Q SABRE SDP 
> board that I have using the linux-fslc-lts-4.19 kernel.  In my 
> local.conf file I have the following:
> 
> MACHINE = “imx6qdlsabresd”
> DISTRO = "fslc-framebuffer”
> 
> PREFERRED_PROVIDER_virtual/kernel = "linux-fslc-lts-4.19”
> 
> When I try to build it fails saying it doesn’t know how to build 
> imx6qp-sabresd-btwifi.dtb
> 
>   make[3]: *** No rule to make target 
> 'arch/arm/boot/dts/imx6qp-sabresd-btwifi.dtb'.  Stop.
> 
> Is there some magic needed to only get it to use the default DTS file?
> 

You need to specify KERNEL_DEVICETREE=imx6qp-sabresd.dts in your local.conf

The reason is that the default DTS file (imx6qp-sabresd-btwifi.dts in 
this case) is not available in the kernel version you choose.

It also makes me wonder why you are using the linux-fslc-lts-4.19 
instead of the default.

> -Andy.
> 

-- bas.

Re: linux-fslc-lts-4.19

[Andy Pont]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

Bas wrote...

>You need to specify KERNEL_DEVICETREE=imx6qp-sabresd.dts in your local.conf
>
>The reason is that the default DTS file (imx6qp-sabresd-btwifi.dts in this case) is not available in the kernel version you choose.
I can try adding that and seeing if it resolves the problem.

>It also makes me wonder why you are using the linux-fslc-lts-4.19 instead of the default.
By default it is building a kernel that, according to uname, is 4.9.67 
which is along way behind the information on the front page of 
www.kernel.org that has the latest 4.9.x kernel at 4.9.189.

With the 4.9.67b kernel that is being built, the Timesys Vigiles service 
reports a large number of kernel issues that have been fixed in later 
versions.

-Andy.

[-- Attachment #2: Type: text/html, Size: 1901 bytes --]

Re: linux-fslc-lts-4.19

[Bas Mevissen]

On 8/19/19 1:35 PM, Andy Pont wrote:
> Bas wrote...
> 
>> You need to specify KERNEL_DEVICETREE=imx6qp-sabresd.dts in your 
>> local.conf
>> The reason is that the default DTS file (imx6qp-sabresd-btwifi.dts in 
>> this case) is not available in the kernel version you choose.
> I can try adding that and seeing if it resolves the problem.
> 
>> It also makes me wonder why you are using the linux-fslc-lts-4.19 
>> instead of the default.
> By default it is building a kernel that, according to uname, is 4.9.67 
> which is along way behind the information on the front page of 
> www.kernel.org that has the latest 4.9.x kernel at 4.9.189.
> 

Ah, I assumed the default to be at the 4.9-2.3.x-imx branch. That one is 
based upon 4.9.166, which is much more close to the latest upstream.

> With the 4.9.67b kernel that is being built, the Timesys Vigiles service 
> reports a large number of kernel issues that have been fixed in later 
> versions.
> 

A recent kernel from a longterm branch is probable the best to have. 
However, I feel that it is mostly important later in the development. 
Starting with defaults usually gets you going without too much hassle.

For small, short-lived projects, starting with any LTS kernel is fine as 
long as you get to a recent one before release. With larger and 
long-living developments, you have to cater for major kernel version 
jumps anyway.

> -Andy.

Re: linux-fslc-lts-4.19

[Andy Pont]

[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]

Bas wrote...

>Ah, I assumed the default to be at the 4.9-2.3.x-imx branch. That one is based upon 4.9.166, which is much more close to the latest upstream.

Now I’m wondering if I have the wrong version of meta-freescale. The 
recipes-kernel/linux directory contains the following files:

linux-qoriq_4.19.bb
linux-imx_4.9.123.bb
linux-fslc-lts-4.19.bb
linux-fslc-imx_4.9-1.0.x.bb
linux-qoriq_4.14.bb
linux-imx-headers_4.9.123.bb
linux-fslc-imx-rt_4.1-2.0.x.bb
linux-fslc_5.0.bb
linux-imx-mfgtool_4.9.123.bb

I guess I could use linux-imx_4.9.123 to get me a bit further forward or 
bbappend linux-fslc-imx_4.9-1.0.x.bb and pull the latest SRVREV out of 
git://github.com/Freescale/linux-fslc.git


>A recent kernel from a longterm branch is probable the best to have. However, I feel that it is mostly important later in the development. Starting with defaults usually gets you going without too much hassle.
>
>For small, short-lived projects, starting with any LTS kernel is fine as long as you get to a recent one before release. With larger and long-living developments, you have to cater for major kernel version jumps anyway.
The default 4.9.67 boots and I have run the initial tests on it 
successfully.  I was looking to update it to something that would be a 
better long term option if this test exercise turns into a full product 
development.

Having built the 4.19.66 kernel with the changed KERNEL_DEVICETREE 
setting I now have a compile issue with the Vivante drivers which 
appears to come from some DMA related functions having moved header file 
somewhere along the way.

-Andy.

[-- Attachment #2: Type: text/html, Size: 3336 bytes --]

Re: linux-fslc-lts-4.19

[Bas Mevissen]

On 8/19/19 2:18 PM, Andy Pont wrote:
> Bas wrote...
> 
>> Ah, I assumed the default to be at the 4.9-2.3.x-imx branch. That one 
>> is based upon 4.9.166, which is much more close to the latest upstream.
> 
> Now I’m wondering if I have the wrong version of meta-freescale. The 
> recipes-kernel/linux directory contains the following files:
> 
> linux-qoriq_4.19.bb
> linux-imx_4.9.123.bb
> linux-fslc-lts-4.19.bb
> linux-fslc-imx_4.9-1.0.x.bb
> linux-qoriq_4.14.bb
> linux-imx-headers_4.9.123.bb
> linux-fslc-imx-rt_4.1-2.0.x.bb
> linux-fslc_5.0.bb
> linux-imx-mfgtool_4.9.123.bb
> 

No, looks fine. Just tip of Warrior branch.

> I guess I could use linux-imx_4.9.123 to get me a bit further forward or 
> bbappend linux-fslc-imx_4.9-1.0.x.bb and pull the latest SRVREV out of 
> git://github.com/Freescale/linux-fslc.git
> 

That one seems to be targeted by NXP at supporting the i.MX8 series (only).

Maybe Otavio can shed some light on what best to use. The most recent 
FSL Community work seems to be done at the 4.9-2.3.x-imx branch (just a 
week ago).
> 
>> A recent kernel from a longterm branch is probable the best to have. 
>> However, I feel that it is mostly important later in the development. 
>> Starting with defaults usually gets you going without too much hassle.
>> For small, short-lived projects, starting with any LTS kernel is fine 
>> as long as you get to a recent one before release. With larger and 
>> long-living developments, you have to cater for major kernel version 
>> jumps anyway.
> The default 4.9.67 boots and I have run the initial tests on it 
> successfully.  I was looking to update it to something that would be a 
> better long term option if this test exercise turns into a full product 
> development.
> 
Maybe postpone that update and stick to 4.9.67 and work on the stuff you 
need to do.

> Having built the 4.19.66 kernel with the changed KERNEL_DEVICETREE 
> setting I now have a compile issue with the Vivante drivers which 
> appears to come from some DMA related functions having moved header file 
> somewhere along the way.
> 
My bet would be to stick to something 4.9-ish (or possible 4.14 from 
4.14-2.0.x-imx branch) as they will be supported for a very long time, 
see <https://www.kernel.org/category/releases.html> and will stay most 
likely compatible with your current Vivante drivers.


> -Andy.

-- bas.

Re: linux-fslc-lts-4.19

[Otavio Salvador]

Hello Andy,

On Mon, Aug 19, 2019 at 7:08 AM Andy Pont <andy.pont@sdcsystems.com> wrote:
>
> I am trying to create a Yocto Warrior buid for the i.MX6Q SABRE SDP board that I have using the linux-fslc-lts-4.19 kernel.  In my local.conf file I have the following:
>
> MACHINE = “imx6qdlsabresd”
> DISTRO = "fslc-framebuffer”
>
> PREFERRED_PROVIDER_virtual/kernel = "linux-fslc-lts-4.19”

The use of Linux mainline requires the use of 'use-mainline-bsp'
override. To do that, you can:

At local.conf add:

MACHINEOVERRIDES_append = ":use-mainline-bsp"

Or add it to your machine definition.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

Re: linux-fslc-lts-4.19

[Andy Pont]

[-- Attachment #1: Type: text/plain, Size: 665 bytes --]

Otavio wrote….

>The use of Linux mainline requires the use of 'use-mainline-bsp'
>override. To do that, you can:
>
>At local.conf add:
>
>MACHINEOVERRIDES_append = ":use-mainline-bsp"
>
>Or add it to your machine definition.
That just seems to cause too many problems with building the rest of the 
system. The first complaint was:

ERROR: Nothing RPROVIDES 'gstreamer1.0-plugins-imx’

If I remove that from the local.conf file then:

ERROR: Nothing PROVIDES 'imx-gpu-viv’

For the time being I think the jump from 4.9 to 4.19 is too big a jump. 
Is there an easy way to get closer to to 4.9.190 the current 4.9 LTS 
version?

-Andy.

[-- Attachment #2: Type: text/html, Size: 2017 bytes --]

Re: linux-fslc-lts-4.19

[Otavio Salvador]

Hello Andy,

On Wed, Aug 28, 2019 at 3:57 PM Andy Pont <andy.pont@sdcsystems.com> wrote:
> The use of Linux mainline requires the use of 'use-mainline-bsp'
> override. To do that, you can:
>
> At local.conf add:
>
> MACHINEOVERRIDES_append = ":use-mainline-bsp"
>
> Or add it to your machine definition.
>
> That just seems to cause too many problems with building the rest of the system. The first complaint was:
>
> ERROR: Nothing RPROVIDES 'gstreamer1.0-plugins-imx’
>
> If I remove that from the local.conf file then:
>
> ERROR: Nothing PROVIDES 'imx-gpu-viv’
>
> For the time being I think the jump from 4.9 to 4.19 is too big a jump. Is there an easy way to get closer to to 4.9.190 the current 4.9 LTS version?

Yes, it is. But it is managed by our packagegroups and like.

Likely your image uses them hardcoded. We are using 5.2.10 internally
for few customers.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

Re: linux-fslc-lts-4.19

[Andreas Müller]

On Wed, Aug 28, 2019 at 9:30 PM Otavio Salvador
<otavio.salvador@ossystems.com.br> wrote:
>
> Hello Andy,
>
> On Wed, Aug 28, 2019 at 3:57 PM Andy Pont <andy.pont@sdcsystems.com> wrote:
> > The use of Linux mainline requires the use of 'use-mainline-bsp'
> > override. To do that, you can:
> >
> > At local.conf add:
> >
> > MACHINEOVERRIDES_append = ":use-mainline-bsp"
> >
> > Or add it to your machine definition.
> >
> > That just seems to cause too many problems with building the rest of the system. The first complaint was:
> >
> > ERROR: Nothing RPROVIDES 'gstreamer1.0-plugins-imx’
> >
> > If I remove that from the local.conf file then:
> >
> > ERROR: Nothing PROVIDES 'imx-gpu-viv’
> >
> > For the time being I think the jump from 4.9 to 4.19 is too big a jump. Is there an easy way to get closer to to 4.9.190 the current 4.9 LTS version?
>
> Yes, it is. But it is managed by our packagegroups and like.
>
> Likely your image uses them hardcoded. We are using 5.2.10 internally
> for few customers.
>
FWIW - We use linux-fscl-lts for our products. That*s why I introduced
linux-fscl-lts. It is on variscite-som imx6 and am VERY happy about it
since using un-tailored sources (have to admit that our images do not
contain much of multimedia but that is not the focus of energy meter
devices exactly...). Starts that I can have X AND wayland in same
image / our Qt/QML applications perform at least as good with vivante.
And Qt/X11 updates do not cause pain anymore (not matching headers /
API changes).

Maybe [1] - helps to see what is required from kernel point of view
and: do not use imx-specific recipes/packagegroups: they fail and are
not necessary.

Cheers

Andreas

[1] https://github.com/Freescale/meta-freescale-3rdparty/blob/master/conf/machine/imx6qdl-variscite-som.conf

Re: linux-fslc-lts-4.19

[Andy Pont]

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]

Andreas wrote...

>FWIW - We use linux-fscl-lts for our products. That*s why I introduced
>linux-fscl-lts. It is on variscite-som imx6 and am VERY happy about it
>since using un-tailored sources (have to admit that our images do not
>contain much of multimedia but that is not the focus of energy meter
>devices exactly...). Starts that I can have X AND wayland in same
>image / our Qt/QML applications perform at least as good with vivante.
>And Qt/X11 updates do not cause pain anymore (not matching headers /
>API changes).
The more I read on this and the more answers come in from people the 
more confused I am making myself. Let me explain the background to what 
I am trying to do to see if someone can give me an idiots guide!

I am using the i.MX6Q SABRE SDP as an evaluation platform prior to 
custom hardware being designed.  The front end is based on Cog and WPE 
Webkit using the i.MX6 wpebackend-rdk which, as I understand it, runs 
directly on top of the framebuffer but needs the GPU drivers.  We think 
that is the best implementation as it means we can dispense with all the 
overhead of X11, Wayland and Qt.

In my current build I have the following set in local.conf:

MACHINE = “imx6qdlsabresd”
DISTRO = "fslc-framebuffer”

IMAGE_INSTALL_append then includes (amongst other things): 
packagegroup-fsl-tools-gpu gstreamer1.0-plugins-imx 
gstreamer1.0-plugins-imx-meta based on (a probable misinterpretation) of 
the information that I got from [1].

Am I using the right setting for DISTRO?  Is there a difference between 
using fsl-framebuffer and fslc-framebuffer?  Should it just be the 
regular Poky?

-Andy.


[1] https://github.com/Igalia/meta-webkit/wiki/i.MX6



[-- Attachment #2: Type: text/html, Size: 3496 bytes --]