Can0 Device Missing

Hello all,

So I have a custom carrier board with an Apalis iMX6Q IT module. I have been running a custom Dunfell build with no problems, but I recently upgraded the build to Kirkstone. After this upgrade, the ‘can0’ device has vanished from ‘/dev’. Is there something that changed from Dunfell to Kirkstone with regards to ‘can0’ in the OS build or the Device Tree setup?

Hello @morgan1361,

Would you mind including what OS image/version you are including with your build?


@eric.tx yes my apologies. Its a custom Kirkstone build. Linux Version: 5.4.129+g828ec42a6a320


I believe the issue may be coming from the mismatch between the yocto version and the Linux version. While there isn’t a strict compatibility issue with yocto -kirkstone and kernel 5.4. There are correction that would need to happen on the recipe level.

If we look at our release matrix we recommend going with Linux 5.15/BSP6 with Kirkstone and Dunfell with linux 5.4/BSP5.7 Release Matrix here

If you want to also upgrade the kernel version to 5.15 this would be the mainline version, which by default would be compatible with yocto -Kirkstone. This is one possible route. The second would be to stay with Dunfell. And the third would be to modify the layer and transplant all of the required 5.4 components.



So what would be the procedure for updating to Linux 5.15, the following correct?

$ repo init -u git:// -b kirkstone-6.1.0 -m tdxref/default.xml
$ repo sync

Then rebuild? The release matrix that you linked states that the current mainline Linux kernel for the iMX6 and BSP 6.1.0 is 6.0.17, will that be a problem?

Yup! that would be the correct steps.

There is actually no direct relation to the BSP layer version and the kernel version. Even though they look like they might be the same.


Ok I will give it a shot, I will report back or mark the previous as the solution depending on outcome.

Thank you!!


So I am getting the same results here. Oddly the kernel version didn’t change

U-Boot 2022.07-6.1.0-devel
Linux version 5.4.129+g828ec42a6a320 (oe-user@oe-host) (gcc version 11.3.0 (GCC)) #1 SMP Wed Oct 27 12:15:27 UTC 2021

I am doing this build in a VM with Ubuntu 18 as the guest OS, I don’t see how that could be an issue but maybe?

Hey @morgan1361,

Correct, I don’t believe those would have an effect. It looks when you are building it it still referencing the previous setup or compiling with the 5.4 linux recipes.

If you run a command while in setup such as :

> bitbake -e virtual/kernel | grep "PREFERRED_VERSION_linux-yocto"

You should see an output similar to:

# $PREFERRED_VERSION_linux-yocto PREFERRED_VERSION_linux-yocto="5.15%"



Ok, so I may have found the problem, and if so, it was a complete goof on my part. I have written recipes for a custom DISTRO and the line to include the $MACHINE.conf file (in local.conf) had the wrong name in it, so it was including the basic apalis-imx6 file. I am doing a clean build now and its showing that its fetching linux-toradex-mainline-rt-6.0.17 so that is promising. I will let you know when its done if it solves my CAN issue.


hey @morgan1361,

Good catch! hopefully this solves the issue. If not, we can figure it out. Keep me posted.



So the build is failing

ERROR: linux-toradex-mainline-rt-6.0.17+gitAUTOINC+040e3123e9-r0 do_kernel_metadata: A KBUILD_DEFCONFIG ‘apalis_imx6_defconfig’ was specified, but not present in the source tree (/home/mmorgan/oe-core/build/tmp/work-shared/apalis-imx6/kernel-source-arch/arm/configs/)

I have confirmed that this file is not in the stated location. I do not provide a custom defconfig file so I am very confused by this error. I did find where a defconfig is defined

in /oe-core/layers/meta-freescale-3rdparty/conf/machine/apalis-imx6.conf
KBUILD_DEFCONFIG:use-nxp-bsp ?= “apalis_imx6_defconfig”

So obviously there have been some changes from BSP 5 as everything used to work. Any thoughts on how to proceed?


Hey @morgan1361,

It’s possible that somewhere in your yocto build project file you are defining the KBUILD_DEFCONFIG and it is expecting a config file that isn’t there. Often migration to a newer kernel requires a bit of trail and error to correct. It’s usually not a plug and play situation. But by either fielding each error that comes out, or by building up from a working base and adding functionality can be method to upgrading.



OK, so after much messing around, I have it building and can0 is present which solves the initial point of this thread so thank you very much. I do have another question though, is there any way to verify if my linux_toradex_%.bbappend file is being executed during the build or not?

This is all that is contains

FILESEXTRAPATHS:prepend := "${THISDIR}/linux-toradex:"

inherit kernel

SRC_URI += " \
	file://imx6q-apalis-acu3.dts \

do_configure:append() {
	# Copy Device Tree File
	cp ${WORKDIR}/imx6q-apalis-acu3.dts ${S}/arch/arm/boot/dts
	# Add device tree to Makefile
	echo "dtb-$(CONFIG_SOC_IMX6Q) += imx6q-apalis-acu3.dtb" >> ${S}/arch/arm/boot/Makefile


However if I delete the .dts from where OpenEmbedded builds the .dtb or if I remove the line from the Makefile, the build throws errors that it can’t find the .dts or no source to build. Also adding kernel configs to the acu3config.cfg file has no effect. If you have any thoughts on this I would appreciate it and I think i will be good to go afterwards


Good to hear it!

We do like to have one issue per ticket, so if this issue is significantly different we ask for a new ticket.

But while in the build directory and source export (i.e bitbake running). You can run:

bitbake-layers show-appends | grep "linux_toradex_%.bbappend"

and it should pull the file w/ location so you can verify.




Thank you so much for the assistance. I was able to figure out the issue. Historically the bbappend file needed to be linux-toradex_%.bbappend, apparently now is needs to be linux-toradex%.bbappend. This worked like a charm. Thanks again, you have been very helpful.