Date   

[bug] gl libraries should not be included if opengl is not in the distro features

Nicola Lunghi
 

Hi all,
I was trying to build a qt commanline application but I have an issue
The dependency for gles2 is automatically added.
Looking at the dependency chain I have:

$PACKAGECONFIG_GL [5 operations]
# set? /home/nlunghiadm/build/xaap/newgw/xaap-new/meta-qt5/recipes-qt/qt5/qtbase_git.bb:42
# "${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'gl',
'no-opengl', d)}"
# _append[use-mainline-bsp]
/home/nlunghiadm/build/xaap/newgw/xaap-new/meta-freescale/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend:23
# " gbm kms"
# override[imxpxp]:set
/home/nlunghiadm/build/xaap/newgw/xaap-new/meta-freescale/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend:20
# "gles2"
# override[imxgpu2d]:set
/home/nlunghiadm/build/xaap/newgw/xaap-new/meta-freescale/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend:21
# "${@bb.utils.contains('DISTRO_FEATURES', 'x11', ' gl', '', d)}"
# override[imxgpu3d]:set
/home/nlunghiadm/build/xaap/newgw/xaap-new/meta-freescale/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend:22
# "gles2"
# pre-expansion value:
# "gles2"
PACKAGECONFIG_GL="gles2"
#
# $PACKAGECONFIG_GL_imxgpu2d
# set /home/nlunghiadm/build/xaap/newgw/xaap-new/meta-freescale/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend:21
# "${@bb.utils.contains('DISTRO_FEATURES', 'x11', ' gl', '', d)}"
PACKAGECONFIG_GL_imxgpu2d=""
#
# $PACKAGECONFIG_GL_imxgpu3d
# set /home/nlunghiadm/build/xaap/newgw/xaap-new/meta-freescale/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend:22
# "gles2"
PACKAGECONFIG_GL_imxgpu3d="gles2"
#
# $PACKAGECONFIG_GL_imxpxp
# set /home/nlunghiadm/build/xaap/newgw/xaap-new/meta-freescale/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend:20
# "gles2"
PACKAGECONFIG_GL_imxpxp="gles2"

and in meta-freescale/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend

SRC_URI_append_imxgpu3d = " \
${@bb.utils.contains('DISTRO_FEATURES', 'x11', '',
'${SRC_URI_APPEND_3D_NOT_X11}', d)} \
"

PACKAGECONFIG_GL_imxpxp = "gles2"
PACKAGECONFIG_GL_imxgpu2d =
"${@bb.utils.contains('DISTRO_FEATURES', 'x11', ' gl', '', d)}"
PACKAGECONFIG_GL_imxgpu3d = "gles2"
PACKAGECONFIG_GL_append_use-mainline-bsp = " gbm kms"

PACKAGECONFIG_PLATFORM = ""
PACKAGECONFIG_PLATFORM_imxgpu2d = "no-opengl linuxfb"
PACKAGECONFIG_PLATFORM_imxgpu3d = " \
${@bb.utils.contains('DISTRO_FEATURES', 'x11', '', \
bb.utils.contains('DISTRO_FEATURES', 'wayland', '', \
'eglfs', d), d)}"
PACKAGECONFIG_PLATFORM_use-mainline-bsp =
"${@bb.utils.contains('DISTRO_FEATURES', 'x11', '', 'eglfs', d)}"
PACKAGECONFIG += "${PACKAGECONFIG_PLATFORM}"

I think the correct behaviour should be to check for opengl in distro
features and not x11 am I wrong?

Thanks
Nicola Lunghi


Re: QorIQ T2080qds board support

Jean-Marc Harang
 

Hi Zhenhua,

Many thanks for the informations ! it's precious ;)

best regards
jean-marc

Le 29/07/2019 à 15:22, Zhenhua Luo a écrit :
Hi Jean-Marc,

The latest QotIQ SDK of t2080qds support is QorIQ SDK 2.0-1703 which is Yocto 2.0 (jethro) based, the SDK can be downloaded from https://www.nxp.com/support/developer-resources/run-time-software/linux-software-and-development-tools/linux-sdk-for-qoriq-processors:SDKLINUX.

T2080QDS was removed from rocko branch(YP2.4) of community meta-freescale layer, currently there is no plan to add it back.


Best Regards,

Zhenhua

-----Original Message-----
From: meta-freescale-bounces@... <meta-freescale-
bounces@...> On Behalf Of Jean-Marc Harang
Sent: 2019年7月24日 17:04
To: meta-freescale@...
Subject: [meta-freescale] QorIQ T2080qds board support

Hello

I see that in 2.4 release, the support of this board has been removed.
The last version with this board is 2.3.

In 2.4, does the support of this board will be added ? or it's deprecated and I
must use 2.3 release ?

therefore, what is the minimum release of Yocto for the 2.3 release of meta-
freescale ? Can I use current yocto main branch. It's not clear for me, sorry if my
question is a dumb one.

many thanks

jean-marc

--
_______________________________________________
meta-freescale mailing list
meta-freescale@...
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yoct
oproject.org%2Flistinfo%2Fmeta-
freescale&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%7Cb1eecfb51adb4
e4d69eb08d710184de7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7
C636995568891648277&amp;sdata=7rp4Z8XtYxNX8x0E9bsrZ9Ll2nXBS72W%2F4
1QIv0jneU%3D&amp;reserved=0


Re: MPC-8377 BSP - Yocto

Zhenhua Luo
 

Currently we have no plan to add the board in Yocto. I recommend you to refer the following Yocto development manual to add new machine.

 

https://www.yoctoproject.org/docs/2.7/dev-manual/dev-manual.html

 

 

Best Regards,

 

Zhenhua

 

From: Prawn Hongs <prawnhongs@...>
Sent: 2019730 7:05
To: Zhenhua Luo <zhenhua.luo@...>
Cc: meta-freescale@...
Subject: Re: [meta-freescale] MPC-8377 BSP - Yocto

 

Thanks, any plans to support this.

If I have to test and make it supported what I need to do.

What are the steps to start with?

 

Thanks

Shreyas Joshi

 

On Mon, Jul 29, 2019 at 10:37 PM Zhenhua Luo <zhenhua.luo@...> wrote:

Hi Shreyas,

 

MPC8377 is not supported by Yocto, you can get the LTIB BSP from https://www.nxp.com/products/processors-and-microcontrollers/power-architecture-processors/powerquicc-processors/powerquicc-ii-pro-mpc83xx/powerquicc-ii-pro-processor-with-ddr2-pci-pci-express-sata-1-gb-ethernet-usb-security:MPC8377E.

 

 

Best Regards,

 

Zhenhua

 

From: meta-freescale-bounces@... <meta-freescale-bounces@...> On Behalf Of Prawn Hongs
Sent: 2019729 11:36
To: meta-freescale@...
Subject: [meta-freescale] MPC-8377 BSP - Yocto

 

Hi Everyone,

 

I am looking out for a meta-free scale bsp for "MPC8377" processor  to build in Sumo Yocto.

Any idea where will I find this BSP?

 

Thanks

Shreyas Joshi


Re: MPC-8377 BSP - Yocto

Shreyas
 

Thanks, any plans to support this.
If I have to test and make it supported what I need to do.
What are the steps to start with?

Thanks
Shreyas Joshi

On Mon, Jul 29, 2019 at 10:37 PM Zhenhua Luo <zhenhua.luo@...> wrote:

Hi Shreyas,

 

MPC8377 is not supported by Yocto, you can get the LTIB BSP from https://www.nxp.com/products/processors-and-microcontrollers/power-architecture-processors/powerquicc-processors/powerquicc-ii-pro-mpc83xx/powerquicc-ii-pro-processor-with-ddr2-pci-pci-express-sata-1-gb-ethernet-usb-security:MPC8377E.

 

 

Best Regards,

 

Zhenhua

 

From: meta-freescale-bounces@... <meta-freescale-bounces@...> On Behalf Of Prawn Hongs
Sent: 2019729 11:36
To: meta-freescale@...
Subject: [meta-freescale] MPC-8377 BSP - Yocto

 

Hi Everyone,

 

I am looking out for a meta-free scale bsp for "MPC8377" processor  to build in Sumo Yocto.

Any idea where will I find this BSP?

 

Thanks

Shreyas Joshi


Re: QorIQ T2080qds board support

Zhenhua Luo
 

Hi Jean-Marc,

The latest QotIQ SDK of t2080qds support is QorIQ SDK 2.0-1703 which is Yocto 2.0 (jethro) based, the SDK can be downloaded from https://www.nxp.com/support/developer-resources/run-time-software/linux-software-and-development-tools/linux-sdk-for-qoriq-processors:SDKLINUX.

T2080QDS was removed from rocko branch(YP2.4) of community meta-freescale layer, currently there is no plan to add it back.


Best Regards,

Zhenhua

-----Original Message-----
From: meta-freescale-bounces@... <meta-freescale-
bounces@...> On Behalf Of Jean-Marc Harang
Sent: 2019年7月24日 17:04
To: meta-freescale@...
Subject: [meta-freescale] QorIQ T2080qds board support

Hello

I see that in 2.4 release, the support of this board has been removed.
The last version with this board is 2.3.

In 2.4, does the support of this board will be added ? or it's deprecated and I
must use 2.3 release ?

therefore, what is the minimum release of Yocto for the 2.3 release of meta-
freescale ? Can I use current yocto main branch. It's not clear for me, sorry if my
question is a dumb one.

many thanks

jean-marc

--
_______________________________________________
meta-freescale mailing list
meta-freescale@...
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yoct
oproject.org%2Flistinfo%2Fmeta-
freescale&amp;data=02%7C01%7Czhenhua.luo%40nxp.com%7Cb1eecfb51adb4
e4d69eb08d710184de7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7
C636995568891648277&amp;sdata=7rp4Z8XtYxNX8x0E9bsrZ9Ll2nXBS72W%2F4
1QIv0jneU%3D&amp;reserved=0


Re: MPC-8377 BSP - Yocto

Zhenhua Luo
 

From: meta-freescale-bounces@... <meta-freescale-bounces@...> On Behalf Of Prawn Hongs
Sent: 2019729 11:36
To: meta-freescale@...
Subject: [meta-freescale] MPC-8377 BSP - Yocto

 

Hi Everyone,

 

I am looking out for a meta-free scale bsp for "MPC8377" processor  to build in Sumo Yocto.

Any idea where will I find this BSP?

 

Thanks

Shreyas Joshi


MPC-8377 BSP - Yocto

Shreyas
 

Hi Everyone,

I am looking out for a meta-free scale bsp for "MPC8377" processor  to build in Sumo Yocto.
Any idea where will I find this BSP?

Thanks
Shreyas Joshi


QorIQ T2080qds board support

Jean-Marc Harang
 

Hello

I see that in 2.4 release, the support of this board has been removed. The last version with this board is 2.3.

In 2.4, does the support of this board will be added ? or it's deprecated and I must use 2.3 release ?

therefore, what is the minimum release of Yocto for the 2.3 release of meta-freescale ? Can I use current yocto main branch. It's not clear for me, sorry if my question is a dumb one.

many thanks

jean-marc


Change u-boot boot parameters

JH
 

Hi,

I have a zImage-initramfs built by openwrt, which including following
u-boot boot parameter during the bootload, and it can boot from imx6:

bootargs=console=ttymxc0,115200........

fdt_addr=0x83000000

loadaddr=0x80800000

,,,,

I need to build the Yocto image to include those boot parameters, but
I could not find anyway in meta-freescale to set up those boot
parameters, how would you set up boot parameters in meta-freescale?

Thank you.

Kind regards,

- JH


Re: crypto: mxs-dcp deadlock bug?

Петр Борисенко <peter@...>
 

unsubscribe


On Fri, Jul 12, 2019, 9:21 AM Yang Liu <yliu@...> wrote:
Hi, meta-freescale gurus,

I am testing a simple VPN (openswan) configuration on a customised
i.mx287 board. The Linux kernel is Linux version
5.0.7-fslc+g39f695df6f5f. There is a kernel dump printed on screen
after several seconds. It looks like a deadlock happened in mxs-dcp
driver.


[ 4176.961195] ================================
[ 4176.965485] WARNING: inconsistent lock state
[ 4176.969775] 5.0.7-fslc+g39f695df6f5f #1 Not tainted
[ 4176.974667] --------------------------------
[ 4176.978954] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 4176.984984] swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 4176.989973] 6c0f210d (&(&sdcp->lock[i])->rlock){+.?.}, at:
mxs_dcp_aes_enqueue+0x4c/0x98
[ 4176.998137] {SOFTIRQ-ON-W} state was registered at:
[ 4177.003049]   _raw_spin_lock+0x28/0x38
[ 4177.006828]   dcp_chan_thread_sha+0x4c/0x2e4
[ 4177.011133]   kthread+0x120/0x138
[ 4177.014475]   ret_from_fork+0x14/0x24
[ 4177.018155]     (null)
[ 4177.020531] irq event stamp: 2503736
[ 4177.024150] hardirqs last  enabled at (2503736): [<c0073f74>]
ktime_get_real_seconds+0x90/0xb0
[ 4177.032795] hardirqs last disabled at (2503735): [<c0073f3c>]
ktime_get_real_seconds+0x58/0xb0
[ 4177.041438] softirqs last  enabled at (2503728): [<c001f85c>]
irq_enter+0x64/0x80
[ 4177.048947] softirqs last disabled at (2503729): [<c001f9c0>]
irq_exit+0x148/0x19c
[ 4177.056528]
[ 4177.056528] other info that might help us debug this:
[ 4177.063064]  Possible unsafe locking scenario:
[ 4177.063064]
[ 4177.068991]        CPU0
[ 4177.071446]        ----
[ 4177.073901]   lock(&(&sdcp->lock[i])->rlock);
[ 4177.078281]   <Interrupt>
[ 4177.080910]     lock(&(&sdcp->lock[i])->rlock);
[ 4177.085462]
[ 4177.085462]  *** DEADLOCK ***
[ 4177.085462]
[ 4177.091397] 2 locks held by swapper/0:
[ 4177.095155]  #0: 9c353098 (rcu_read_lock){....}, at:
netif_receive_skb_internal+0x28/0x19c
[ 4177.103503]  #1: 9c353098 (rcu_read_lock){....}, at:
ip_local_deliver_finish+0x2c/0xb8
[ 4177.111500]
[ 4177.111500] stack backtrace:
[ 4177.115883] CPU: 0 PID: 0 Comm: swapper Not tainted
5.0.7-fslc+g39f695df6f5f #1
[ 4177.123208] Hardware name: Freescale MXS (Device Tree)
[ 4177.128415] [<c0010df8>] (unwind_backtrace) from [<c000e730>]
(show_stack+0x10/0x14)
[ 4177.136211] [<c000e730>] (show_stack) from [<c0055a74>]
(mark_lock+0x534/0x6f0)
[ 4177.143560] [<c0055a74>] (mark_lock) from [<c005612c>]
(__lock_acquire+0x484/0x1870)
[ 4177.151339] [<c005612c>] (__lock_acquire) from [<c0057e54>]
(lock_acquire+0xb4/0x178)
[ 4177.159210] [<c0057e54>] (lock_acquire) from [<c068adb8>]
(_raw_spin_lock+0x28/0x38)
[ 4177.166996] [<c068adb8>] (_raw_spin_lock) from [<c049e024>]
(mxs_dcp_aes_enqueue+0x4c/0x98)
[ 4177.175416] [<c049e024>] (mxs_dcp_aes_enqueue) from [<bf0dc52c>]
(esp_input+0x1d8/0x300 [esp4])
[ 4177.184190] [<bf0dc52c>] (esp_input [esp4]) from [<c05d9540>]
(xfrm_input+0x83c/0xad0)
[ 4177.192171] [<c05d9540>] (xfrm_input) from [<c05c8bd0>]
(xfrm4_esp_rcv+0x68/0x120)
[ 4177.199798] [<c05c8bd0>] (xfrm4_esp_rcv) from [<c0564a1c>]
(ip_protocol_deliver_rcu+0x7c/0x2cc)
[ 4177.208547] [<c0564a1c>] (ip_protocol_deliver_rcu) from
[<c0564cf4>] (ip_local_deliver_finish+0x88/0xb8)
[ 4177.218072] [<c0564cf4>] (ip_local_deliver_finish) from
[<c0564e54>] (ip_local_deliver+0x130/0x1a8)
[ 4177.227162] [<c0564e54>] (ip_local_deliver) from [<c0564fe8>]
(ip_rcv+0x11c/0x174)
[ 4177.234778] [<c0564fe8>] (ip_rcv) from [<c05139a8>]
(__netif_receive_skb_one_core+0x4c/0x6c)
[ 4177.243263] [<c05139a8>] (__netif_receive_skb_one_core) from
[<c0519370>] (netif_receive_skb_internal+0x58/0x19c)
[ 4177.253568] [<c0519370>] (netif_receive_skb_internal) from
[<c0519f10>] (napi_gro_receive+0x148/0x1d0)
[ 4177.262924] [<c0519f10>] (napi_gro_receive) from [<c042164c>]
(fec_enet_rx_napi+0x3d0/0x9b8)
[ 4177.271406] [<c042164c>] (fec_enet_rx_napi) from [<c051a668>]
(net_rx_action+0xe4/0x3dc)
[ 4177.279542] [<c051a668>] (net_rx_action) from [<c000a15c>]
(__do_softirq+0x134/0x434)
[ 4177.287416] [<c000a15c>] (__do_softirq) from [<c001f9c0>]
(irq_exit+0x148/0x19c)
[ 4177.294853] [<c001f9c0>] (irq_exit) from [<c006345c>]
(__handle_domain_irq+0x50/0xa8)
[ 4177.302720] [<c006345c>] (__handle_domain_irq) from [<c00099cc>]
(__irq_svc+0x6c/0x8c)
[ 4177.310658] Exception stack(0xc0919f40 to 0xc0919f88)
[ 4177.315744] 9f40: 00000001 00000001 00000000 20000013 ffffe000
c09230c4 c09a453f c07e839c
[ 4177.323953] 9f60: c0923060 c7ee8e80 c090aa50 00000000 00000000
c0919f90 c0058020 c000bc30
[ 4177.332147] 9f80: 20000013 ffffffff
[ 4177.335675] [<c00099cc>] (__irq_svc) from [<c000bc30>]
(arch_cpu_idle+0x28/0x38)
[ 4177.343115] [<c000bc30>] (arch_cpu_idle) from [<c0047078>]
(do_idle+0x8c/0xec)
[ 4177.350374] [<c0047078>] (do_idle) from [<c004745c>]
(cpu_startup_entry+0xc/0x10)
[ 4177.357909] [<c004745c>] (cpu_startup_entry) from [<c08c9d8c>]
(start_kernel+0x3cc/0x474)
[ 4177.460138] NOHZ: local_softirq_pending 08
[ 4177.960322] NOHZ: local_softirq_pending 08
[ 4178.045081] NOHZ: local_softirq_pending 08
[ 4178.126861] NOHZ: local_softirq_pending 08
[ 4178.157288] NOHZ: local_softirq_pending 08
[ 4178.191966] NOHZ: local_softirq_pending 08
[ 4178.218160] NOHZ: local_softirq_pending 08
[ 4178.237144] NOHZ: local_softirq_pending 08
[ 4178.267594] NOHZ: local_softirq_pending 08
[ 4178.286991] NOHZ: local_softirq_pending 08

Can someone give me some suggestions about this bug?

Best Regards,
yliu
--
_______________________________________________
meta-freescale mailing list
meta-freescale@...
https://lists.yoctoproject.org/listinfo/meta-freescale


Re: [yocto] Looking for a recommendation for the right Yocto dev board that supports MIPI CSI-2...

Khem Raj <raj.khem@...>
 

On Wed, Jul 3, 2019 at 4:32 PM Bob Cochran <yocto@...> wrote:

On 6/20/19 11:24 PM, Bob Cochran wrote:
Hi,

I'm doing some work with MIPI cameras, and I need a development board
with stable Yocto and MIPI CSI-2 support. At this point, I'm
thinking i.MX, but I'm open to any suggestion.
It looks like we're going to purchase an NXP MCIMX8M-EVK dev board (at
least one to get started). Can someone please confirm that the
imx8mqevk.conf machine file is for this board?

Is this board Yocto Project stable? I need to be able to build the
master branch for this board (or should I be using next?). Any comments
or feedback will be great appreciated.

https://www.nxp.com/support/developer-resources/evaluation-and-development-boards/i.mx-evaluation-and-development-boards/evaluation-kit-for-the-i.mx-8m-applications-processor:MCIMX8M-EVK
seems it is in meta-freescale.
https://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/conf/machine/imx8mqevk.conf?h=master

Thanks

Bob



I'm not sure what type of access I'll have to the D-PHY data streams.
Do they always terminate into a GPU? However, I would like a board
that gives me the most capability to control / route the data with
open source drivers.

I suppose I want CSI-2 in and HDMI out.

Thank you,

Bob

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


Re: Which version of Yocto support ATF?

Otavio Salvador <otavio.salvador@...>
 

On Tue, Apr 9, 2019 at 6:26 PM john matt <john.matt2022@...> wrote:
I am new to ATF, and I know NXP released sdk that supports ATF. I am wondering if yocto supports ATF? If so which version supports atf?
I'd use warrior branch for it.

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


crypto: mxs-dcp deadlock bug?

yliu
 

Hi, meta-freescale gurus,

I am testing a simple VPN (openswan) configuration on a customised
i.mx287 board. The Linux kernel is Linux version
5.0.7-fslc+g39f695df6f5f. There is a kernel dump printed on screen
after several seconds. It looks like a deadlock happened in mxs-dcp
driver.


[ 4176.961195] ================================
[ 4176.965485] WARNING: inconsistent lock state
[ 4176.969775] 5.0.7-fslc+g39f695df6f5f #1 Not tainted
[ 4176.974667] --------------------------------
[ 4176.978954] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 4176.984984] swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 4176.989973] 6c0f210d (&(&sdcp->lock[i])->rlock){+.?.}, at:
mxs_dcp_aes_enqueue+0x4c/0x98
[ 4176.998137] {SOFTIRQ-ON-W} state was registered at:
[ 4177.003049] _raw_spin_lock+0x28/0x38
[ 4177.006828] dcp_chan_thread_sha+0x4c/0x2e4
[ 4177.011133] kthread+0x120/0x138
[ 4177.014475] ret_from_fork+0x14/0x24
[ 4177.018155] (null)
[ 4177.020531] irq event stamp: 2503736
[ 4177.024150] hardirqs last enabled at (2503736): [<c0073f74>]
ktime_get_real_seconds+0x90/0xb0
[ 4177.032795] hardirqs last disabled at (2503735): [<c0073f3c>]
ktime_get_real_seconds+0x58/0xb0
[ 4177.041438] softirqs last enabled at (2503728): [<c001f85c>]
irq_enter+0x64/0x80
[ 4177.048947] softirqs last disabled at (2503729): [<c001f9c0>]
irq_exit+0x148/0x19c
[ 4177.056528]
[ 4177.056528] other info that might help us debug this:
[ 4177.063064] Possible unsafe locking scenario:
[ 4177.063064]
[ 4177.068991] CPU0
[ 4177.071446] ----
[ 4177.073901] lock(&(&sdcp->lock[i])->rlock);
[ 4177.078281] <Interrupt>
[ 4177.080910] lock(&(&sdcp->lock[i])->rlock);
[ 4177.085462]
[ 4177.085462] *** DEADLOCK ***
[ 4177.085462]
[ 4177.091397] 2 locks held by swapper/0:
[ 4177.095155] #0: 9c353098 (rcu_read_lock){....}, at:
netif_receive_skb_internal+0x28/0x19c
[ 4177.103503] #1: 9c353098 (rcu_read_lock){....}, at:
ip_local_deliver_finish+0x2c/0xb8
[ 4177.111500]
[ 4177.111500] stack backtrace:
[ 4177.115883] CPU: 0 PID: 0 Comm: swapper Not tainted
5.0.7-fslc+g39f695df6f5f #1
[ 4177.123208] Hardware name: Freescale MXS (Device Tree)
[ 4177.128415] [<c0010df8>] (unwind_backtrace) from [<c000e730>]
(show_stack+0x10/0x14)
[ 4177.136211] [<c000e730>] (show_stack) from [<c0055a74>]
(mark_lock+0x534/0x6f0)
[ 4177.143560] [<c0055a74>] (mark_lock) from [<c005612c>]
(__lock_acquire+0x484/0x1870)
[ 4177.151339] [<c005612c>] (__lock_acquire) from [<c0057e54>]
(lock_acquire+0xb4/0x178)
[ 4177.159210] [<c0057e54>] (lock_acquire) from [<c068adb8>]
(_raw_spin_lock+0x28/0x38)
[ 4177.166996] [<c068adb8>] (_raw_spin_lock) from [<c049e024>]
(mxs_dcp_aes_enqueue+0x4c/0x98)
[ 4177.175416] [<c049e024>] (mxs_dcp_aes_enqueue) from [<bf0dc52c>]
(esp_input+0x1d8/0x300 [esp4])
[ 4177.184190] [<bf0dc52c>] (esp_input [esp4]) from [<c05d9540>]
(xfrm_input+0x83c/0xad0)
[ 4177.192171] [<c05d9540>] (xfrm_input) from [<c05c8bd0>]
(xfrm4_esp_rcv+0x68/0x120)
[ 4177.199798] [<c05c8bd0>] (xfrm4_esp_rcv) from [<c0564a1c>]
(ip_protocol_deliver_rcu+0x7c/0x2cc)
[ 4177.208547] [<c0564a1c>] (ip_protocol_deliver_rcu) from
[<c0564cf4>] (ip_local_deliver_finish+0x88/0xb8)
[ 4177.218072] [<c0564cf4>] (ip_local_deliver_finish) from
[<c0564e54>] (ip_local_deliver+0x130/0x1a8)
[ 4177.227162] [<c0564e54>] (ip_local_deliver) from [<c0564fe8>]
(ip_rcv+0x11c/0x174)
[ 4177.234778] [<c0564fe8>] (ip_rcv) from [<c05139a8>]
(__netif_receive_skb_one_core+0x4c/0x6c)
[ 4177.243263] [<c05139a8>] (__netif_receive_skb_one_core) from
[<c0519370>] (netif_receive_skb_internal+0x58/0x19c)
[ 4177.253568] [<c0519370>] (netif_receive_skb_internal) from
[<c0519f10>] (napi_gro_receive+0x148/0x1d0)
[ 4177.262924] [<c0519f10>] (napi_gro_receive) from [<c042164c>]
(fec_enet_rx_napi+0x3d0/0x9b8)
[ 4177.271406] [<c042164c>] (fec_enet_rx_napi) from [<c051a668>]
(net_rx_action+0xe4/0x3dc)
[ 4177.279542] [<c051a668>] (net_rx_action) from [<c000a15c>]
(__do_softirq+0x134/0x434)
[ 4177.287416] [<c000a15c>] (__do_softirq) from [<c001f9c0>]
(irq_exit+0x148/0x19c)
[ 4177.294853] [<c001f9c0>] (irq_exit) from [<c006345c>]
(__handle_domain_irq+0x50/0xa8)
[ 4177.302720] [<c006345c>] (__handle_domain_irq) from [<c00099cc>]
(__irq_svc+0x6c/0x8c)
[ 4177.310658] Exception stack(0xc0919f40 to 0xc0919f88)
[ 4177.315744] 9f40: 00000001 00000001 00000000 20000013 ffffe000
c09230c4 c09a453f c07e839c
[ 4177.323953] 9f60: c0923060 c7ee8e80 c090aa50 00000000 00000000
c0919f90 c0058020 c000bc30
[ 4177.332147] 9f80: 20000013 ffffffff
[ 4177.335675] [<c00099cc>] (__irq_svc) from [<c000bc30>]
(arch_cpu_idle+0x28/0x38)
[ 4177.343115] [<c000bc30>] (arch_cpu_idle) from [<c0047078>]
(do_idle+0x8c/0xec)
[ 4177.350374] [<c0047078>] (do_idle) from [<c004745c>]
(cpu_startup_entry+0xc/0x10)
[ 4177.357909] [<c004745c>] (cpu_startup_entry) from [<c08c9d8c>]
(start_kernel+0x3cc/0x474)
[ 4177.460138] NOHZ: local_softirq_pending 08
[ 4177.960322] NOHZ: local_softirq_pending 08
[ 4178.045081] NOHZ: local_softirq_pending 08
[ 4178.126861] NOHZ: local_softirq_pending 08
[ 4178.157288] NOHZ: local_softirq_pending 08
[ 4178.191966] NOHZ: local_softirq_pending 08
[ 4178.218160] NOHZ: local_softirq_pending 08
[ 4178.237144] NOHZ: local_softirq_pending 08
[ 4178.267594] NOHZ: local_softirq_pending 08
[ 4178.286991] NOHZ: local_softirq_pending 08

Can someone give me some suggestions about this bug?

Best Regards,
yliu


[PATCH] u-boot-imx-mfgtool: Add u-boot-imx to search path

Gonzalo Ruiz <Gonzalo.Ruiz@...>
 

'u-boot-imx-mfgtool' is unable to find SRC_URI entry
0001-tools-allow-to-override-python.patch which causes a parse warning.
This file is introduced by 'u-boot-imx' recipe under u-boot-imx folder.

Add u-boot-imx folder to the 'u-boot-imx-mfgtool' recipe search path so
it is also able to find the patch file.

Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@...>
---
recipes-bsp/u-boot/u-boot-imx-mfgtool_2017.03.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-bsp/u-boot/u-boot-imx-mfgtool_2017.03.bb b/recipes-bsp/u-boot/u-boot-imx-mfgtool_2017.03.bb
index 81799ad..d5cb033 100644
--- a/recipes-bsp/u-boot/u-boot-imx-mfgtool_2017.03.bb
+++ b/recipes-bsp/u-boot/u-boot-imx-mfgtool_2017.03.bb
@@ -2,5 +2,7 @@
# Copyright (C) 2014-2016 Freescale Semiconductor
# Copyright 2017 NXP

+FILESEXTRAPATHS_prepend := "${THISDIR}/u-boot-imx:"
+
require u-boot-imx_${PV}.bb
require u-boot-mfgtool.inc


NXP and meta-freescale BSPs workflow

Th?o Bueno
 

Hi everyone,

 

I have some questions regarding meta-freescale's workflow.

 

It is my understanding that meta-freescale should be the BSP of choice for any Yocto project for the i.MX6 platform. It is also the stance of NXP which publishes their own BSP only for testing purposes. This BSP, "meta-fsl-bsp-release" contains NXP recipes for their latest i.MX-specific software branches, such as Weston, Linux and their graphics drivers.

 

Recently, NXP published a new revision of their BSP based on Thud with linux-imx 4.19, weston 6.0 and a graphics drivers bump.

 

What are the guidelines for the integration of those changes into meta-freescale ? Does it follow a specific schedule ?

 

For instance, NXP published Weston 6.0 on their Thud BSP even though Poky's version of Weston is 5.0 on Thud. On meta-freescale, Weston's version is 4.0 on all branches though. Where do we go from here ? This is puzzling me and I suspect there are other reasons that explain why Weston does not get bumped on meta-freescale.

 

To give a bit of context, on Automotive Grade Linux this situation (among other reasons) probably led the developers to drop the proprietary graphics stack for i.MX6 platforms in favor of mainline support with etnaviv, because they have a hard requirement to Weston 6.0. This is a bit problematic as the mainline stack suffers limitations.

 

I would appreciate any help or guidance on those questions.

 

Thanks and best regards,

Théo Bueno.


Re: Kernel Changes to iMX8M-EVK

Saravanan
 

Bob,

Apologies for the delay.
I did not get a chance to build an image yet.
I am experimenting with a minimal Root FS. So i took a prebuilt image from NXP website and swapped out the RootFS.
I was able to boot with the my experimental Root FS.

I am yet to do any validations on Peripherals. I will let you know how it works when i get to it.
Thanks,
Saravanan


From: Bob Cochran <yocto@...>
Sent: Friday, July 5, 2019 11:24 AM
To: Saravanan Somasundaram; meta-freescale@...
Subject: Re: [meta-freescale] Kernel Changes to iMX8M-EVK
 
On 7/4/19 3:34 PM, Saravanan Somasundaram wrote:
Hi,

I have been playing with the Yocto Image for iMX8M-EVK.


Glad to hear that you have one.  Can you please share some feedback on it?  Do all the peripherals work?  Are you using thud with 4.14 kernel?  Is it stable? 


Any & all feedback will be greatly appreciated.


Thank you,


Bob



I would like to use the latest mainstream kernel with this image.
I have been having trouble finding the following information:
  • Has all the changes specifically done for iMX8M-EVK has been merged to mainstream kernel.
  • If not, how to figure the list of kernel patches that has to be applied on top of mainstream kernel.

Any help is very much appreciated.

Thanks,
Saravanan




[PATCH] libimxdmabuffer: Add recipe

Carlos Rafael Giani
 

libimxdmabuffer provides an API for allocating and handling physically
contiguous buffers ("DMA buffers") on imx6, imx7, imx8 machines with the
imx-kernel. The underlying allocation can be backed by the PxP, IPU, ION,
DWL, G2D APIs.

The API is backend agnostic. The same structures and functions can be used
with the underlying PxP and IPU allocators for example. Furthermore, the
library defines a "default" allocator (which one is the "default" is
determined by the library and by the build configuration).

By using this API, libraries can use compatible types for exchanging
DMA buffers in userspace, and can also use the same API and support mx6,
mx7, and mx8 machines, without requiring platform specific code changes.

Signed-off-by: Carlos Rafael Giani <crg7475@...>
---
.../libimxdmabuffer/libimxdmabuffer_1.0.0.bb | 41 +++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 recipes-bsp/libimxdmabuffer/libimxdmabuffer_1.0.0.bb

diff --git a/recipes-bsp/libimxdmabuffer/libimxdmabuffer_1.0.0.bb b/recipes-bsp/libimxdmabuffer/libimxdmabuffer_1.0.0.bb
new file mode 100644
index 00000000..a4252a7b
--- /dev/null
+++ b/recipes-bsp/libimxdmabuffer/libimxdmabuffer_1.0.0.bb
@@ -0,0 +1,41 @@
+DESCRIPTION = 'Library for allocating and managing physically contiguous memory \
+ ("DMA memory" or "DMA buffers") on i.MX devices.'
+HOMEPAGE = "https://github.com/Freescale/libimxdmabuffer"
+LICENSE = "LGPLv2.1"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=38fa42a5a6425b26d2919b17b1527324"
+SECTION = "base"
+
+PV = "1.0.0+git${SRCPV}"
+
+SRCBRANCH ?= "master"
+SRCREV = "db17cb57d1087cf590b28487c43cb5c47bf76fe7"
+SRC_URI = "git://github.com/Freescale/libimxdmabuffer.git;branch=${SRCBRANCH}"
+
+S = "${WORKDIR}/git"
+
+inherit pkgconfig waf use-imx-headers ptest
+
+EXTRA_OECONF = "--imx-linux-headers-path=${STAGING_INCDIR_IMX} \
+ --libdir=${libdir} \
+ ${PACKAGECONFIG_CONFARGS}"
+
+PACKAGECONFIG ?= " "
+PACKAGECONFIG_append_imxgpu2d = " g2d"
+PACKAGECONFIG_append_imxipu = " ipu"
+PACKAGECONFIG_append_imxpxp = " pxp"
+PACKAGECONFIG_append_mx8m = " dwl ion"
+
+HANTRO_CONF = "--hantro-headers-path=${STAGING_INCDIR}/hantro_dec --hantro-decoder-version=G2"
+
+PACKAGECONFIG[dwl] = "--with-dwl-allocator=yes ${HANTRO_CONF},--with-dwl-allocator=no,imx-vpu-hantro"
+PACKAGECONFIG[ion] = "--with-ion-allocator=yes, --with-ion-allocator=no,"
+PACKAGECONFIG[ipu] = "--with-ipu-allocator=yes, --with-ipu-allocator=no,"
+PACKAGECONFIG[g2d] = "--with-g2d-allocator=yes, --with-g2d-allocator=no,virtual/libg2d"
+PACKAGECONFIG[pxp] = "--with-pxp-allocator=yes, --with-pxp-allocator=no,"
+
+do_install_ptest () {
+ install -d ${D}${PTEST_PATH}/tests
+ install -m 0755 ${B}/test-alloc ${D}${PTEST_PATH}/tests
+}
+
+COMPATIBLE_MACHINE = "(mx6|mx7|mx8)"
--
2.17.1


[PATCH] gstreamer1.0-plugins-base: Move bbappend to 1.16 version

Carlos Rafael Giani
 

This follows the OE-Core upgrade.

Signed-off-by: Carlos Rafael Giani <crg7475@...>
---
..._1.14.%.bbappend => gstreamer1.0-plugins-base_1.16.%.bbappend} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename recipes-multimedia/gstreamer/{gstreamer1.0-plugins-base_1.14.%.bbappend => gstreamer1.0-plugins-base_1.16.%.bbappend} (100%)

diff --git a/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.14.%.bbappend b/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.16.%.bbappend
similarity index 100%
rename from recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.14.%.bbappend
rename to recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.16.%.bbappend
--
2.17.1


Re: Kernel Changes to iMX8M-EVK

Bob Cochran
 

On 7/4/19 3:34 PM, Saravanan Somasundaram wrote:
Hi,

I have been playing with the Yocto Image for iMX8M-EVK.


Glad to hear that you have one.  Can you please share some feedback on it?  Do all the peripherals work?  Are you using thud with 4.14 kernel?  Is it stable? 


Any & all feedback will be greatly appreciated.


Thank you,


Bob



I would like to use the latest mainstream kernel with this image.
I have been having trouble finding the following information:
  • Has all the changes specifically done for iMX8M-EVK has been merged to mainstream kernel.
  • If not, how to figure the list of kernel patches that has to be applied on top of mainstream kernel.

Any help is very much appreciated.

Thanks,
Saravanan




[PATCH 24/24] ddr-phy: fix typo

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

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

Signed-off-by: Chunrong Guo <chunrong.guo@...>
---
recipes-bsp/ddr-phy/ddr-phy_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-bsp/ddr-phy/ddr-phy_git.bb b/recipes-bsp/ddr-phy/ddr-phy_git.bb
index 1496b51..98a9b02 100644
--- a/recipes-bsp/ddr-phy/ddr-phy_git.bb
+++ b/recipes-bsp/ddr-phy/ddr-phy_git.bb
@@ -5,7 +5,7 @@ LIC_FILES_CHKSUM = "file://NXP-Binary-EULA.txt;md5=89cc852481956e861228286ac7430
inherit deploy fsl-eula-unpack

SRC_URI = "git://github.com/nxp/ddr-phy-binary.git;fsl-eula=true;nobranch=1 \
- git://source.codeaurora.org/external/qoriq/qoriq-components/atf;nobranch=1;nobranch=1;destsuffix=git/atf;name=atf"
+ git://source.codeaurora.org/external/qoriq/qoriq-components/atf;nobranch=1;destsuffix=git/atf;name=atf"
SRCREV = "14d03e6e748ed5ebb9440f264bb374f1280b061c"
SRCREV_atf = "17f94e4315e81e3d1b22d863d9614d724e8273dc"

--
2.7.4

821 - 840 of 24848