linux-fslc-lts-4.19


Andy Pont
 

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.


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.


Andy Pont
 

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.


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.


Andy Pont
 

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.


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.


Otavio Salvador <otavio.salvador@...>
 

Hello Andy,

On Mon, Aug 19, 2019 at 7:08 AM Andy Pont <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”
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


Andy Pont
 

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.


Otavio Salvador <otavio.salvador@...>
 

Hello Andy,

On Wed, Aug 28, 2019 at 3:57 PM Andy Pont <andy.pont@...> 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


Andreas Müller
 

On Wed, Aug 28, 2019 at 9:30 PM Otavio Salvador
<otavio.salvador@...> wrote:

Hello Andy,

On Wed, Aug 28, 2019 at 3:57 PM Andy Pont <andy.pont@...> 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


Andy Pont
 

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.