Hello Jan,

On Thu, Jan 20, 2022 at 9:44 AM Jan Claussen via
lists.yoctoproject.org
<claussen.j=eppendorf.de@lists.yoctoproject.org> wrote:

Hi,


I am currently working on adding our custom patches to linux-fslc-imx on honister. Previously, we had patched linux-imx on Gatesgarth but there seems to have changed a lot. Seems like this kernel is a merged version of linux-imx and linux-fslc. In the description "for upgraders" it says to add patches to the linux-fslc in the "corresponding branch". Usually I would create our own branch and add our patches to that one. I have tried to set our branch as KBRANCH and specify our custom_defconfig as KBUILD_DEFCONFIG in linux-fslc.inc, but during the compilation the defonfig is not found.

There are 3 points to be considered here, namely:

1) If those patches do fix the issue in the NXP downstream kernel,
then you can open a PR in [1] against the _corresponding branch_,
which in this case is [5.10.2.1.x-imx]. This gives a chance for those
who use the combined "NXP + Latest LTS" kernel (which `linux-fslc-imx`
is) a chance to review and provide comments on your patches.

2) If those patches are fixing issues in upstream, then you should
report then upstream first and they will eventually land in
linux-fslc-imx kernel via stable upgrade, provided they do qualify for
linux-stable, see [2] for this.

3) If those patches do something that only you need, you are
effectively creating your own "downstream" fork of linux-fslc-imx
repository, hence you need to create your own kernel provider.

The comment in recipe says exactly what it means: one should not
submit Kernel patches as patch files and add them to the layer (with
appending those to SRC_URI), but rather push them into [1] via PR
mechanism. Corresponding branch in this context means: the branch that
is currently set in the recipe. Since branch changes during Kernel
upgrades, there is no way to explicitly mention against which branch
you should submit your PR, hence the term "corresponding branch" is
used here.

So can I only patch the original branch 5.10.2.1.x-imx or why doesn't this work?

Depends on the way you choose to proceed from above, you either would
"patch" the branch (via PR), or you need to switch the Kernel provider
to your own fork.

Cheers,

Jan

________________________________
This email including its attachments is intended for the person or entity only to which it is addressed. It may contain confidential and/or privileged material. Any review, forwarding, dissemination, other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this email in error, please contact the sender and delete the material from any computer system.
________________________________


Eppendorf SE, Hamburg, Barkhausenweg 1, 22339 Hamburg, Amtsgericht Hamburg HRB 171526
Vors. des Aufsichtsrats: Philipp von Loeper
Vorstand: Eva van Pelt (Co-Vorsitzende), Dr. Peter Fruhstorfer (Co-Vorsitzender), Axel Jaeger und Dr. Wilhelm Plüster

Eppendorf Instrumente GmbH, Hamburg, Amtsgericht Hamburg, HRB 69077
Geschäftsführer: Dr. Bernd Petersen und Dr. Alexander Papra

Eppendorf Liquid Handling GmbH, Hamburg, Amtsgericht Hamburg, HRB 92250
Geschäftsführer: Dietmar Stadler


________________________________
According to the general high quality approach of Eppendorf, we apply to our mail traffic the latest protection technologies and methods, including extensive scanning and DMARC, to help our communication partners in protecting their IT environment.
Privacy information according to Articles 13 and 14 GDPR can be found here: www.eppendorf.com/gdpr
________________________________

Link: [1]: https://github.com/Freescale/linux-fslc
Link: [2]: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
--
Regards,
Andrey.

---

This email including its attachments is intended for the person or entity only to which it is addressed. It may contain confidential and/or privileged material. Any review, forwarding, dissemination, other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this email in error, please contact the sender and delete the material from any computer system.

---

Eppendorf SE, Hamburg, Barkhausenweg 1, 22339 Hamburg, Amtsgericht Hamburg HRB 171526
Vors. des Aufsichtsrats: Philipp von Loeper
Vorstand: Eva van Pelt (Co-Vorsitzende), Dr. Peter Fruhstorfer (Co-Vorsitzender), Axel Jaeger und Dr. Wilhelm Plüster

Eppendorf Instrumente GmbH, Hamburg, Amtsgericht Hamburg, HRB 69077
Geschäftsführer: Dr. Bernd Petersen und Dr. Alexander Papra

Eppendorf Liquid Handling GmbH, Hamburg, Amtsgericht Hamburg, HRB 92250
Geschäftsführer: Dietmar Stadler

---

According to the general high quality approach of Eppendorf, we apply to our mail traffic the latest protection technologies and methods, including extensive scanning and DMARC, to help our communication partners in protecting their IT environment.
Privacy information according to Articles 13 and 14 GDPR can be found here: www.eppendorf.com/gdpr

---

On Tue, Jan 11, 2022 at 11:29 PM <benson_young@sercomm.com> wrote:

[Edited Message Follows]

Hello,

We are experiencing kernel crash when we are stress testing WiFi functionality.
please see attachment for kernel dump (near end of log)
we have read that rcu_preempt dump are sometimes caused by spin lock used by driver when kernel has PREEMPT enabled.
and suggested solution is making change as something below
spin_unlock_irq(&signal->obj.wait.lock); ---> raw_spin_unlock_irq(&signal->obj.wait.lock);
spin_lock_irq(&signal->obj.wait.lock); -----> raw_spin_lock_irq(&signal->obj.wait.lock);
however, the wireless driver on our platform doesn't use such calls.

The WiFi device is an RTL8822CS using SDIO interface, it is an out-of-tree driver released by Realtek.

Ok, understood. The RTL8822 driver available in the kernel is for PCI-only.

You should push Realtek to upstream RTL8822CS SDIO support as working
with an out-of-tree driver is too painful.

When we applied the same wireless driver on official NXP BSPs Linux 5.10.9 (gatesgarth) and Linux 4.9.11 (morty) this issue isn't observed.
Attaching the kernel configs for the two BSPs config_5.4.114_dunfell (meta-freescale community BSP). config_5.10.9_gatesgarth (NXP
official BSP)

Can anyone please advise on possible cause and solution?

I suggest you use a 5.10 linux-fslc kernel version.

On Tue, Jan 11, 2022 at 10:06 AM Fabio Estevam via
lists.yoctoproject.org <festevam=gmail.com@lists.yoctoproject.org>
wrote:

Hi Benson,

On Tue, Jan 11, 2022 at 7:08 AM <benson_young@sercomm.com> wrote:

Hello,

We are experiencing kernel crash when we are stress testing WiFi functionality over SDIO interface.
please see attachment for kernel dump (near end of log)

Looking at your log, I see you use an rtl8822 Wifi device, which is
not supported in the mainline kernel.

Ah, the driver is available at drivers/net/wireless/realtek/rtw88/rtw8822c.c

I would suggest you try a more recent kernel, such as 5.15.y then.

If you still observe issues, then please report them to the maintainer
and lists given by:
./scripts/get_maintainer.pl -f drivers/net/wireless/realtek/rtw88/rtw8822c.c

Hope this helps.

Hi Benson,

On Tue, Jan 11, 2022 at 7:08 AM <benson_young@sercomm.com> wrote:

Hello,

We are experiencing kernel crash when we are stress testing WiFi functionality over SDIO interface.
please see attachment for kernel dump (near end of log)

Looking at your log, I see you use an rtl8822 Wifi device, which is
not supported in the mainline kernel.

I assume you use an out-of-tree driver, right?

When using out-of-tree drivers, it is common to see the driver work on
a specific kernel version and then it breaks on a kernel update.

I suggest you consider using a well-supported Wifi chip instead.

Regards,

Fabio Estevam

Hello,

We are experiencing kernel crash when we are stress testing WiFi functionality.
please see attachment for kernel dump (near end of log)
we have read that rcu_preempt dump are sometimes caused by spin lock used by driver when kernel has PREEMPT enabled.
and suggested solution is making change as something below
spin_unlock_irq(&signal->obj.wait.lock);   --->  raw_spin_unlock_irq(&signal->obj.wait.lock);
spin_lock_irq(&signal->obj.wait.lock);   -----> raw_spin_lock_irq(&signal->obj.wait.lock);
however, the wireless driver on our platform doesn't use such calls.

The WiFi device is an RTL8822CS using SDIO interface, it is an out-of-tree driver released by Realtek.
When we applied the same wireless driver on official NXP BSPs Linux 5.10.9 (gatesgarth) and Linux 4.9.11 (morty) this issue isn't observed.
Attaching the kernel configs for the two BSPs config_5.4.114_dunfell (meta-freescale community BSP). config_5.10.9_gatesgarth (NXP
official BSP)

Can anyone please advise on possible cause and solution?

much appreciate the assistance and best regards,

Benson

Hello Leo and Fabio,

On Wed, Jan 5, 2022 at 2:18 PM Fabio Estevam <festevam@gmail.com> wrote:

Hi Leo,

On Wed, Nov 17, 2021 at 7:40 PM Leo <Leo.E.Meza@gmail.com> wrote:

Hello,

I'm using a wandboard (rev d1) and building the fslc-image-network-full-cmdline image (honister branch). I've got ethernet wired to a switch on my home network, but I cannot figure out how to setup this build to bring up eth0 via DHCP. Any help would be appreciated. Is this image supposed to bring up eth0 right out of the box?

There is a recent fix in 5.15.13 for Ethernet on wandboard
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm/boot/dts/imx6qdl-wandboard.dtsi?h=v5.15.13&id=ef73e3b650b7b1ad4080b8e7aeba5e36e19f0932

There is a PR in meta-freescale layer against [master] branch, which
upgrades the Kernel to 5.15.13:
https://github.com/Freescale/meta-freescale/pull/936

Once merged, you can build the image of [master] to verify if your
problem persists.

After applying this fix, I can confirm Ethernet is functional.

To get an IP address via DHCP:
udhcpc -i eth0

--
Regards,
Andrey.

Hi Leo,

On Wed, Nov 17, 2021 at 7:40 PM Leo <Leo.E.Meza@gmail.com> wrote:

Hello,

I'm using a wandboard (rev d1) and building the fslc-image-network-full-cmdline image (honister branch). I've got ethernet wired to a switch on my home network, but I cannot figure out how to setup this build to bring up eth0 via DHCP. Any help would be appreciated. Is this image supposed to bring up eth0 right out of the box?

There is a recent fix in 5.15.13 for Ethernet on wandboard
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm/boot/dts/imx6qdl-wandboard.dtsi?h=v5.15.13&id=ef73e3b650b7b1ad4080b8e7aeba5e36e19f0932

After applying this fix, I can confirm Ethernet is functional.

To get an IP address via DHCP:
udhcpc -i eth0

Hi,

On Wed, Nov 17, 2021 at 11:40 PM, Leo wrote:

Hello,

I'm using a wandboard (rev d1) and building the fslc-image-network-full-cmdline image (honister branch). I've got ethernet wired to a switch on my home network, but I cannot figure out how to setup this build to bring up eth0 via DHCP. Any help would be appreciated. Is this image supposed to bring up eth0 right out of the box?

Build Configuration:
BB_VERSION           = "1.52.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "ubuntu-20.04"
TARGET_SYS           = "arm-poky-linux-gnueabi"
MACHINE              = "wandboard"
DISTRO               = "poky"
DISTRO_VERSION       = "3.4"
TUNE_FEATURES        = "arm vfp cortexa9 neon thumb callconvention-hard"
TARGET_FPU           = "hard"
meta                 
meta-poky            = "HEAD:da5d1b540e052c862232f8bd464d30bb387fe86e"
meta-oe              
meta-multimedia      
meta-python          
meta-networking      = "HEAD:ad52a41de8b4b7d619d1376d0a0090ebcfff56da"
meta-freescale       = "HEAD:ed3435620a2404c241fef3c4ef90d1f31d3b7a8a"
meta-freescale-3rdparty = "HEAD:fd3c4aa47c93b77942dfcf1ab8ded0c54cb589d5"
meta-freescale-distro = "HEAD:d2e27cc4778663450495a67bfb036cba600cb27a"


root@wandboard:~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::21f:7bff:fe0a:90b8  prefixlen 64  scopeid 0x20<link>
        ether 00:1f:7b:0a:90:b8  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 1200 (1.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 32  bytes 6786 (6.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@wandboard:~# cat /etc/network/interfaces
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface
auto lo
iface lo inet loopback

# Wireless interfaces
iface wlan0 inet dhcp
        wireless_mode managed
        wireless_essid any
        wpa-driver wext
        wpa-conf /etc/wpa_supplicant.conf

iface atml0 inet dhcp

# Wired or wireless interfaces
auto eth0
iface eth0 inet dhcp
iface eth1 inet dhcp

# Ethernet/RNDIS gadget (g_ether)
# ... or on host side, usbnet and random hwaddr
iface usb0 inet static
        address 192.168.7.2
        netmask 255.255.255.0
        network 192.168.7.0
        gateway 192.168.7.1

# Bluetooth networking
iface bnep0 inet dhcp

I have this issue after updating meta layers to honister and kernel to version 5.10. My problem was fixed by changing fec node in device tree - phy-mode value should be rgmii-id and phy-reset-duration should be increased:

phy-mode = "rgmii-id";
phy-reset-duration = <10>;

You can see at commit logs in imx devicetrees on kernel repository for more information.

Best regards,

-- 
Michał Kotyla
Embedded Linux Developer
GPG: 14FC54DC259CF70A
https://3mdeb.com | @3mdeb_com

Hello Ken,

Em sex., 17 de dez. de 2021 às 19:18, Ken Davidson
<ken.davidson@pobox.com> escreveu:

There is no subgroup for meta-imx, so I'm guessing this one is the closest.

I'm trying to create a Hardknott version of Yocto for the i.MX 8M Mini board that we're using. The manufacturer (Congatec) only has code up to Zeus, so I'm starting with the Hardknott version of fsl-community-bsp and am trying to add in code from the manufacturer's Zeus implementation.

This is something which is expected to happen when you mix branches
... I'd suggest you to use meta-freescale and move to mainline
releases if it is supported. If it doesn't, you should contact
Congatec support and ask them.

I've run into a problem with the Hardknott release of meta-imx. Under meta-bsp/recipes-bsp/u-boot, the u-boot-imx_2021.04.bb recipe is trying to find u-boot-imx-common.inc. However, the only file present is u-boot-common.inc. This is true for all three Hardknott branches of meta-imx.

The equivalent folder under meta-freescale does include the proper file. Is this a bug or am I missing something? Or should I be using only meta-freescale and abandon meta-imx?

We try to be as close as possible to meta-imx; eventually they diverge
when NXP does new releases but they are pretty close nowadays.

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

There is no subgroup for meta-imx, so I'm guessing this one is the closest.

I'm trying to create a Hardknott version of Yocto for the i.MX 8M Mini board that we're using. The manufacturer (Congatec) only has code up to Zeus, so I'm starting with the Hardknott version of fsl-community-bsp and am trying to add in code from the manufacturer's Zeus implementation.

I've run into a problem with the Hardknott release of meta-imx. Under meta-bsp/recipes-bsp/u-boot, the u-boot-imx_2021.04.bb recipe is trying to find u-boot-imx-common.inc. However, the only file present is u-boot-common.inc. This is true for all three Hardknott branches of meta-imx.

The equivalent folder under meta-freescale does include the proper file. Is this a bug or am I missing something? Or should I be using only meta-freescale and abandon meta-imx?

Thanks.

Hi, 

Is there anyone on this forum who can help me ? 

Thanks,
Maneesh

Hi Sir,

I am using NXP iMX8M Mini EVK and Yocto imx-linux-hardknott  imx-5.10.52 version.

Default GStreamer provided in NXP iMX BSP does not support the GStreamer C application it only supports the command line. 

Hence I need to install and compile GStreamer using iMX yocto. 

To do that I did the following steps -

1) I added the following code in local.conf file -> 

 IMAGE_INSTALL_append += "gstreamer1.0-rtsp-server gstreamer1.0 gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-plugins-bad gstreamer1.0-plugins-ugly gstreamer1.0-libav"

LICENSE_FLAGS_WHITELIST = "commercial"

2) After that I compiled and build the SDK and flashed it to iMX board.

but when I try to compile a simple GStreamer hello world application on my imx8 Mini board then 
It gives me an error saying - 

fatal error: gst/gst.h: No such file or directory
#include <gst/gst.h>

 

Am I Missing Anything? 

please suggest me how can I cross-compile the GStreamer for  iMX yocto ?

Thanks,

Maneesh

Hello,

I'm using a wandboard (rev d1) and building the fslc-image-network-full-cmdline image (honister branch). I've got ethernet wired to a switch on my home network, but I cannot figure out how to setup this build to bring up eth0 via DHCP. Any help would be appreciated. Is this image supposed to bring up eth0 right out of the box?

Build Configuration:
BB_VERSION           = "1.52.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "ubuntu-20.04"
TARGET_SYS           = "arm-poky-linux-gnueabi"
MACHINE              = "wandboard"
DISTRO               = "poky"
DISTRO_VERSION       = "3.4"
TUNE_FEATURES        = "arm vfp cortexa9 neon thumb callconvention-hard"
TARGET_FPU           = "hard"
meta                 
meta-poky            = "HEAD:da5d1b540e052c862232f8bd464d30bb387fe86e"
meta-oe              
meta-multimedia      
meta-python          
meta-networking      = "HEAD:ad52a41de8b4b7d619d1376d0a0090ebcfff56da"
meta-freescale       = "HEAD:ed3435620a2404c241fef3c4ef90d1f31d3b7a8a"
meta-freescale-3rdparty = "HEAD:fd3c4aa47c93b77942dfcf1ab8ded0c54cb589d5"
meta-freescale-distro = "HEAD:d2e27cc4778663450495a67bfb036cba600cb27a"


root@wandboard:~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::21f:7bff:fe0a:90b8  prefixlen 64  scopeid 0x20<link>
        ether 00:1f:7b:0a:90:b8  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 1200 (1.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 32  bytes 6786 (6.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@wandboard:~# cat /etc/network/interfaces
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface
auto lo
iface lo inet loopback

# Wireless interfaces
iface wlan0 inet dhcp
        wireless_mode managed
        wireless_essid any
        wpa-driver wext
        wpa-conf /etc/wpa_supplicant.conf

iface atml0 inet dhcp

# Wired or wireless interfaces
auto eth0
iface eth0 inet dhcp
iface eth1 inet dhcp

# Ethernet/RNDIS gadget (g_ether)
# ... or on host side, usbnet and random hwaddr
iface usb0 inet static
        address 192.168.7.2
        netmask 255.255.255.0
        network 192.168.7.0
        gateway 192.168.7.1

# Bluetooth networking
iface bnep0 inet dhcp