Date   

Re: Which u-boot for imx6dlsabresd in Pyro?

Mauro Ziliani
 

Ok.

Thanks

Il 29/08/19 11:25, Marco ha scritto:
Hi Mauro,
the meta-freescale for Pyro says
PREFERRED_PROVIDER_virtual/bootloader ??= "u-boot-fslc"

https://github.com/Freescale/fsl-community-bsp-platform/blob/pyro/default.xml
https://github.com/Freescale/meta-freescale/blob/pyro/conf/machine/include/imx-base.inc

--
Marco Cavallini | KOAN sas | Bergamo - Italia
embedded software engineering
https://KoanSoftware.com

Il giorno gio 22 ago 2019 alle ore 16:28 Mauro Ziliani
<mauro@...> ha scritto:
Hi all.

Which is the right u-boot for a imx6dlsabresd derived board and Pyro?T

The preferred is u-boot-fslc, but in Jethro/Krogoth was u-boot-imx

--
_______________________________________________
meta-freescale mailing list
meta-freescale@...
https://lists.yoctoproject.org/listinfo/meta-freescale


Re: Which u-boot for imx6dlsabresd in Pyro?

Marco <cavallini.koan@...>
 

Hi Mauro,
the meta-freescale for Pyro says
PREFERRED_PROVIDER_virtual/bootloader ??= "u-boot-fslc"

https://github.com/Freescale/fsl-community-bsp-platform/blob/pyro/default.xml
https://github.com/Freescale/meta-freescale/blob/pyro/conf/machine/include/imx-base.inc

--
Marco Cavallini | KOAN sas | Bergamo - Italia
embedded software engineering
https://KoanSoftware.com

Il giorno gio 22 ago 2019 alle ore 16:28 Mauro Ziliani
<mauro@...> ha scritto:

Hi all.

Which is the right u-boot for a imx6dlsabresd derived board and Pyro?T

The preferred is u-boot-fslc, but in Jethro/Krogoth was u-boot-imx

--
_______________________________________________
meta-freescale mailing list
meta-freescale@...
https://lists.yoctoproject.org/listinfo/meta-freescale


Re: linux-fslc-lts-4.19

Andy Pont <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.





Re: linux-fslc-lts-4.19

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


NXP Solo - GPU Error for Chromium Browser 67 on Rocko

Pravin Yadav
 

We ported Chromium 67 on IMX6 Solo Rocko build and we are facing some errors related to GPU. For testing purpose, we disabled the GPU and it works fine but its affect the performance so what could be the reason for such errors? Also many people’s found similar type of error on other platform and suggested to disable the GPU but in embedded Linux it costs performance badly.

 

 

ERROR:gles2_cmd_decoder.cc(4693)] [.DisplayCompositor-0x5cfc8900]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glClear: framebuffer incomplete (check)

[837:837:0823/134415.646701:ERROR:gles2_cmd_decoder.cc(4693)] [.DisplayCompositor-0x5cfc8900]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete (check)

[837:837:0823/134415.648250:ERROR:gles2_cmd_decoder.cc(4693)] [.DisplayCompositor-0x5cfc8900]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete (check)

:ERROR:gles2_cmd_decoder.cc(4693)] [.DisplayCompositor-0x5cfc8900]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete (check)

 

TexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134615.965943:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134616.513997:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134617.559371:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134618.082101:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

 

[837:837:0823/134614.788719:ERROR:texture_manager.cc(3421)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glTexImage2D: <- error from previous GL command

[837:837:0823/134615.399498:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134615.965943:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134616.513997:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

 

 

Kind Regards,
Pravin Yadav
 
Renu Electronics Private Limited /  www.renuelectronics.com
/
Offering Quality Products and Services  

 


NXP Solo - GPU Error for Chromium Browser 67 on Rocko

Pravin Yadav
 

We ported Chromium 67 on IMX6 Solo Rocko build and we are facing some errors related to GPU. For testing purpose, we disabled the GPU and it works fine but its affect the performance so what could be the reason for such errors? Also many people’s found similar type of error on other platform and suggested to disable the GPU but in embedded Linux it costs performance badly.

 

 

ERROR:gles2_cmd_decoder.cc(4693)] [.DisplayCompositor-0x5cfc8900]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glClear: framebuffer incomplete (check)

[837:837:0823/134415.646701:ERROR:gles2_cmd_decoder.cc(4693)] [.DisplayCompositor-0x5cfc8900]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete (check)

[837:837:0823/134415.648250:ERROR:gles2_cmd_decoder.cc(4693)] [.DisplayCompositor-0x5cfc8900]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete (check)

:ERROR:gles2_cmd_decoder.cc(4693)] [.DisplayCompositor-0x5cfc8900]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete (check)

 

TexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134615.965943:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134616.513997:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134617.559371:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134618.082101:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

 

[837:837:0823/134614.788719:ERROR:texture_manager.cc(3421)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glTexImage2D: <- error from previous GL command

[837:837:0823/134615.399498:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134615.965943:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

[837:837:0823/134616.513997:ERROR:gles2_cmd_decoder.cc(2646)] [.RenderWorker-0x5b7fbe00]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command

 


Re: linux-fslc-lts-4.19

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


Re: linux-fslc-lts-4.19

Andy Pont <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.


Re: linux-fslc-lts-4.19

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


Required build target 'fsl-image-mfgtool-initramfs' has no buildable providers.

sayyed mohsen Zahraee <zahraee.sm@...>
 

here is my local.conf

MACHINE ??= 'imx6qdlsabresd'
DISTRO ?= 'fslc-framebuffer'
PACKAGE_CLASSES ?= 'package_rpm'
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
USER_CLASSES ?= "buildstats image-mklibs image-prelink"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS ??= "\
    STOPTASKS,${TMPDIR},1G,100K \
    STOPTASKS,${DL_DIR},1G,100K \
    STOPTASKS,${SSTATE_DIR},1G,100K \
    STOPTASKS,/tmp,100M,100K \
    ABORT,${TMPDIR},100M,1K \
    ABORT,${DL_DIR},100M,1K \
    ABORT,${SSTATE_DIR},100M,1K \
    ABORT,/tmp,10M,1K"
PACKAGECONFIG_append_pn-qemu-system-native = " sdl"
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
CONF_VERSION = "1"

DL_DIR ?= "${BSPDIR}/downloads/"
ACCEPT_FSL_EULA = "1"

but in case of
bitbake fsl-image-mfgtool-initramfs

i will face with following error:
ERROR: Nothing PROVIDES 'u-boot-mfgtool' (but /media/mohsen/Board/fsl-community-bsp-w/sources/meta-freescale/recipes-fsl/images/fsl-image-mfgtool-initramfs.bb DEPENDS on or otherwise requires it)
u-boot-imx-mfgtool PROVIDES u-boot-mfgtool but was skipped: You cannot use UBOOT_MACHINE and UBOOT_CONFIG at the same time.
ERROR: Required build target 'fsl-image-mfgtool-initramfs' has no buildable providers.
Missing or unbuildable dependency chain was: ['fsl-image-mfgtool-initramfs', 'u-boot-mfgtool']


[PATCH] imx-sc-firmware: change PN to BPN

liu.ming50@...
 

From: Ming Liu <liu.ming50@...>

This fixes a following QA warning:
| QA Issue: imx-sc-firmware: SRC_URI uses PN not BPN [src-uri-bad]

Signed-off-by: Ming Liu <liu.ming50@...>
---
recipes-bsp/imx-sc-firmware/imx-sc-firmware_1.2.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-bsp/imx-sc-firmware/imx-sc-firmware_1.2.bb b/recipes-bsp/imx-sc-firmware/imx-sc-firmware_1.2.bb
index f1a2efe..904c8cc 100644
--- a/recipes-bsp/imx-sc-firmware/imx-sc-firmware_1.2.bb
+++ b/recipes-bsp/imx-sc-firmware/imx-sc-firmware_1.2.bb
@@ -8,7 +8,7 @@ SECTION = "BSP"

inherit fsl-eula-unpack deploy

-SRC_URI = "${FSL_MIRROR}/${PN}-${PV}.bin;fsl-eula=true"
+SRC_URI = "${FSL_MIRROR}/${BPN}-${PV}.bin;fsl-eula=true"

SRC_URI[md5sum] = "1a37cfcb0c7d338f5b69cb8248c452e3"
SRC_URI[sha256sum] = "05efa9ba86533e99cb508c4982afe9de16abbee2710db623359d856384247a64"
--
2.7.4


Which u-boot for imx6dlsabresd in Pyro?

Mauro Ziliani
 

Hi all.

Which is the right u-boot for a imx6dlsabresd derived board and Pyro?T

The preferred is u-boot-fslc, but in Jethro/Krogoth was u-boot-imx


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

Andy Pont <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.


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


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.


linux-fslc-lts-4.19

Andy Pont <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.


Re: [PATCH 01/14] uefi: remove fsl-eula-unpack class

C.r. Guo <chunrong.guo@...>
 

pings

-----Original Message-----
From: C.r. Guo
Sent: 2019年8月12日 11:33
To: meta-freescale@...
Cc: C.r. Guo <chunrong.guo@...>
Subject: [PATCH 01/14] uefi: remove fsl-eula-unpack class

From: Chunrong Guo <chunrong.guo@...>

Signed-off-by: Chunrong Guo <chunrong.guo@...>
---
recipes-bsp/uefi/uefi_git.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-bsp/uefi/uefi_git.bb b/recipes-bsp/uefi/uefi_git.bb index 55344c1..9be05de 100644
--- a/recipes-bsp/uefi/uefi_git.bb
+++ b/recipes-bsp/uefi/uefi_git.bb
@@ -3,9 +3,9 @@ SECTION = "bootloaders"
LICENSE = "NXP-Binary-EULA"
LIC_FILES_CHKSUM = "file://NXP-Binary-EULA;md5=343ec8f06efc37467a6de53686fa6315"

-inherit deploy fsl-eula-unpack
+inherit deploy

-SRC_URI = "git://github.com/NXP/qoriq-uefi-binary.git;fsl-eula=true;nobranch=1"
+SRC_URI = "git://github.com/NXP/qoriq-uefi-binary.git;nobranch=1"
SRCREV= "12963900e9cb4e322df7bff327862de3b8a6371e"

S = "${WORKDIR}/git"
--
2.7.4


[PATCH] ceetm: fix the building warning

C.r. Guo <chunrong.guo@...>
 

From: Chunrong Guo <chunrong.guo@...>

*fix the below warning
|#warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]

*add 0001-Makefile-update-CFLAGS.patch to avoid build Errors.

*remove do_compile_prepend

*Obey LDFLAGS and CFLAGS in Makefile

Signed-off-by: Chunrong Guo <chunrong.guo@...>
---
.../ceetm/ceetm/0001-Makefile-update-CFLAGS.patch | 31 ++++++++++++++++++++++
recipes-kernel/ceetm/ceetm_git.bb | 11 ++++----
2 files changed, 37 insertions(+), 5 deletions(-)
create mode 100644 recipes-kernel/ceetm/ceetm/0001-Makefile-update-CFLAGS.patch

diff --git a/recipes-kernel/ceetm/ceetm/0001-Makefile-update-CFLAGS.patch b/recipes-kernel/ceetm/ceetm/0001-Makefile-update-CFLAGS.patch
new file mode 100644
index 0000000..1369788
--- /dev/null
+++ b/recipes-kernel/ceetm/ceetm/0001-Makefile-update-CFLAGS.patch
@@ -0,0 +1,31 @@
+From fb1fe93a2bab083652a65804be5ddd37a7e86a9f Mon Sep 17 00:00:00 2001
+From: Chunrong Guo <chunrong.guo@...>
+Date: Wed, 14 Aug 2019 04:05:14 +0200
+Subject: [PATCH] Makefile: update CFLAGS
+
+*fix the below error:
+|error: json_print.h: No such file or directory
+
+Upstream-Status: Inappropriate [embedded specific]
+
+Signed-off-by: C.r. Guo <nxa13725@...>
+---
+ Makefile | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Makefile b/Makefile
+index f89700c..49243d8 100644
+--- a/Makefile
++++ b/Makefile
+@@ -8,7 +8,7 @@ LDFLAGS += -Wl,-export-dynamic
+ # if you are not using flex-builder. Download the iproute2 sources for the
+ # desired version and point to those instead.
+ ifneq ($(IPROUTE2_DIR),)
+-CFLAGS += -I$(IPROUTE2_DIR) -I$(IPROUTE2_DIR)/include
++CFLAGS += -I$(IPROUTE2_DIR) -I$(IPROUTE2_DIR)/include -I$(IPROUTE2_DIR)/usr/include/ -I$(IPROUTE2_DIR)/usr/include/include
+ endif
+
+ MODDESTDIR := $(DESTDIR)/usr/lib/tc
+--
+2.7.4
+
diff --git a/recipes-kernel/ceetm/ceetm_git.bb b/recipes-kernel/ceetm/ceetm_git.bb
index 8613e50..68fb67e 100644
--- a/recipes-kernel/ceetm/ceetm_git.bb
+++ b/recipes-kernel/ceetm/ceetm_git.bb
@@ -4,16 +4,17 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=bac620b9883d38a84dfb73ca7122d915"

SRC_URI = "git://source.codeaurora.org/external/qoriq/qoriq-components/ceetm;nobranch=1"
SRCREV = "6a7f2ec2091df2f4380cb8d25a36c399aed5af1b"
-
+SRC_URI_append = " file://0001-Makefile-update-CFLAGS.patch \
+"
DEPENDS = "iproute2"

S = "${WORKDIR}/git"

-EXTRA_OEMAKE = 'CC="${CC}" LD="${CC}" IPROUTE2_DIR="{STAGING_DIR_TARGET}"'
+export IPROUTE2_DIR="${STAGING_DIR_TARGET}"
+WRAP_TARGET_PREFIX ?= "${TARGET_PREFIX}"
+export CROSS_COMPILE="${WRAP_TARGET_PREFIX}"

-do_compile_prepend () {
- cp ${RECIPE_SYSROOT}/usr/include/include/json_print.h ${RECIPE_SYSROOT}/usr/include
-}
+LDFLAGS += "${TOOLCHAIN_OPTIONS}"

do_install(){
mkdir -p ${D}/${libdir}/tc
--
2.7.4