Hi,
I have build the reference-multimedia -image for imx6ull module. Now I change the device tree files (dtsi)to introduce CAN. For this, I created the patch necessary for CAN from dtsi files located inside the /arch/arm/boot/dts folder. I saved the patches inside new layers and append those changes using .bbappend file. Now I run the following command:
bitbake tdx-reference-multimedia-image -f -c clean linux-toradex
bitbake tdx-reference-multimedia-image -f -c compile u-boot
bitbake tdx-reference-multimedia-image
bitbake -c menuconfig virtual/kernel
The build is complete without any error and then I download the Colibri-iMX6ULL_Reference-Multimedia-Image-Tezi_5.7.0-devel-20220628084045+build.0 from build/deploy/images/colibri-imx6ull/ expecting that changes in kernel is applied on Image and flash the image on target but nothing has changed.
I am new to Toradex and this is basic question I am asking but what I did wrong and what steps should I follow so that CAN should be introduce on Target.
How are you? Thanks for reaching out. I have a few questions for you.
Can you share with us the output of a dmesg command? And of a fwprintenv fdt_board?
What do you have on your conf/local.conf file? Could you please share it with us? It would also help if we could have a look on the layer.conf of your recipe.
Are the following steps executed on that order? If so, have you tried doing the menuconfig before the final image generation with bitbake tdx-reference-multimedia-image?
I saw that there may be a typo on linux-toradex%.bbappend. Is this right? Could you also please share with us this file?
Yes, I do bitbake -c menuconfig virtual/kernel before the bitbake tdx-reference-multimedia-image. GUI is open and I do not know which thing to configure in the kernel for enabling the CAN. I leave the kernel configuration as before without any change. Then I do Bitbake -c savedefconfig virtual/kernel.
This shows that your module is running the device tree for the Colibri Evaluation Board. Is this the one that you did your patches to or do you have another carrier board?
Thanks! Can you please also share the output of a bitbake-layers show layers?
To check it, you could for instance search for CAN on the menuconfig. CAN (Linux) | Toradex Developer Center On this page, you can see that for instance what to do with CONFIG_CAN_MCP251X or CONFIG_FLEXCAN.
Ok! Can you also share this file? Maybe you could create a zip with your patches as well and send through share.toradex.com. This will give us more information to work with.
It seems that your recipe is not being used at all from your show-layers command. I couldn’t find meta-customer there. You shall add it to a file called bblayers.conf do you have it there?
I think that there may be a misconception. The kernel and the device trees are built separately. The dts are built at a time and then loaded while booting as long as the kernel. Sometimes, when a kernel configuration is set as module and you have a node on the device tree that is compatible with this configuration, it will be enabled after boot as if it was built-in.
Did you change them on your own? How did you generate the patch files? If you’re trying to give these files another name then you’d need to make additional steps to ensure that you’re deploying the right device tree to the module. Otherwise, just use the patches and keep the original names.
Also, on your patch2 file, you should not have the pinctrl_flexcan inside pinctrl_0. This may cause conflicts to the definition on your patch1. Please tell me if changing this line helps you already
Change the path of patch.
7.Copy the patch file to the my own layer > meta-spark/custom-recipes-kernel/linux-toradex/0003-colibri.patch.
I will change the patch. Then rebuild the image and flash it on colibri module.
I also has one question to ask:-
As I use the colibri-imx6ull module on voila carrier board, Is it neccessary to connect the external transreciever to the TX/RX pin of Voila carrier board to get the can0 in /dev directory? Or there exist any alternate method ?
Thanks and Regards,
Eiti
Where a and b are supposed to be the original and the resulting file paths. There you can see that you have two paths for b. You could also check this to see if this syntax can indeed work. I’d suggest you to use the first line as diff --git a/imx6ull-colibri.dtsi b/imx6ull-colibri.dtsi
Please tell me if this has helped.
I’ll check what would be the best way to do this and I’ll get back to you.
I applied the changes in the patch files suggested by you but still those changes are not visible on the image. When I use bitbake tdx-reference-multimedia-image it use the recipes inside the meta-toradex-nxp instead of my custom-layer.
If your meta is shown on the bitbake-layers show-layers command it means that the recipes are being used. The problem may lie somewhere else.
Can you please provide us the following outputs?
dmesg output after a new build. You can use dmesg >> log.txt → Check for any trace of the device tree change on the go.
lsmod → See what drivers are being used
ls /dev → Check the dev folder for any possible device
gpioinfo → This way we can see if the pins you edited are not listed as gpio’s anymore.
Also, please do not update pictures for your codes/recipes as this doesn’t allow us to reproduce it on our side without copying everything by hand. Always prefer the original formats/text files as this allow us for better debugging in order to support you. If this is the output of a command such as bitbake-layers show-layers you can make it into a text file with something like: CMD_WANTED >> LOGFILE_NAME.txt. Also, it’s not clear to me what you do have on your defconfig and what you do have on your can.cfg. Can you please share your hole meta-spark?
I think looking at the following output I managed to get the can0 interface on colibri-imx6ull. You can also check this.
This is my dmesg | fgrep -i can output:
root@colibri-imx6ull-06900383:~# dmesg | fgrep -i can
[ 0.076608] device: ‘2090000.flexcan’: device_add
[ 0.076662] bus: ‘platform’: add device 2090000.flexcan
[ 0.076775] PM: Adding info for platform:2090000.flexcan
[ 11.341339] CAN device driver interface
[ 11.527839] bus: ‘platform’: add driver flexcan
[ 11.528151] bus: ‘platform’: driver_probe_device: matched device 2090000.flexcan with driver flexcan
[ 11.528174] bus: ‘platform’: really_probe: probing driver flexcan with device 2090000.flexcan
[ 11.528402] flexcan 2090000.flexcan: no init pinctrl state
[ 11.528435] flexcan 2090000.flexcan: no sleep pinctrl state
[ 11.528448] flexcan 2090000.flexcan: no idle pinctrl state
[ 11.528571] flexcan 2090000.flexcan: 2090000.flexcan supply xceiver not found, using dummy regulator
[ 11.691165] devices_kset: Moving 2090000.flexcan to end of list
[ 11.691187] PM: Moving platform:2090000.flexcan to end of list
[ 11.691207] flexcan 2090000.flexcan: Linked as a consumer to regulator.0
[ 11.696469] device: ‘can0’: device_add
[ 11.712402] PM: Adding info for No Bus:can0
[ 11.713094] flexcan 2090000.flexcan: gpr iomuxc-gpr@20e4000 req_gpr=0x0210 req_bit=1 ack_gpr=0x0210 ack_bit=17
[ 11.725545] driver: ‘flexcan’: driver_bound: bound to device ‘2090000.flexcan’
[ 11.725570] devices_kset: Moving 2090000.flexcan to end of list
[ 11.725581] PM: Moving platform:2090000.flexcan to end of list
[ 11.725592] devices_kset: Moving can0 to end of list
[ 11.725600] PM: Moving No Bus:can0 to end of list
[ 11.732340] bus: ‘platform’: really_probe: bound device 2090000.flexcan to driver flexcan
[ 5463.132233] can: controller area network core (rev 20170425 abi 9)
[ 5463.173014] can: raw protocol (rev 20170425)
[quote=“gclaudino.tx, post:13, topic:17365”]
Can you please share your hole meta-spark?
[/quote]
This are the file in my meta-spark folder:https://share.toradex.com/w6mmsz2m5u7y28p
It shows that the drivers have been properly loaded, this is great. The dmesg output also shows that the interfaces have been created.
I checked your files and your error may be linked with the following file: 0003-colibri.patch. You commented the gpio pins but left the group there without any pin. Therefore, you have a structure like: fsl,pins=<>; and this notation is invalid. What I’d suggest you is to comment this whole pinctrl_gpio7 in case you want to ensure that they’re not conflicting. Can you please test it and then check if this error disappears?
I didn’t check with transceiver but on kernel side there is can0.
I comment out the whole pinctrl_gpio7 but then error occurs which says patch is not applied correctly. This is my log file:
DEBUG: Executing python function extend_recipe_sysroot
NOTE: Direct dependencies are [‘/home/spark/oe-core/build/…/layers/openembedded-core/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb:do_populate_sysroot’, ‘virtual:native:/home/spark/oe-core/build/…/layers/openembedded-core/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot’, ‘/home/spark/oe-core/build/…/layers/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.66.bb:do_populate_sysroot’]
NOTE: Installed into sysroot:
NOTE: Skipping as already exists in sysroot: [‘kern-tools-native’, ‘patch-native’, ‘quilt-native’, ‘attr-native’, ‘gnu-config-native’, ‘autoconf-native’, ‘automake-native’, ‘libtool-native’, ‘gettext-minimal-native’, ‘texinfo-dummy-native’, ‘m4-native’]
DEBUG: Python function extend_recipe_sysroot finished
DEBUG: Executing shell function do_patch
(1/3) 0001-add-flexcan.patch
[INFO]: check of .kernel-meta//patches///0001-add-flexcan.patch with “git am” did not pass, trying reduced context.
[INFO]: Context reduced git-am of .kernel-meta//patches///0001-add-flexcan.patch with “git am” did not work, trying “apply”.
(2/3) 0002-nonwifi.patch
[INFO]: check of .kernel-meta//patches///0002-nonwifi.patch with “git am” did not pass, trying reduced context.
[INFO]: Context reduced git-am of .kernel-meta//patches///0002-nonwifi.patch with “git am” did not work, trying “apply”.
(3/3) 0004-new-colibri.patch
[INFO]: check of .kernel-meta//patches///0004-new-colibri.patch with “git am” did not pass, trying reduced context.
[INFO]: Context reduced git-am of .kernel-meta//patches///0004-new-colibri.patch with “git am” did not work, trying “apply”.
error: patch failed: arch/arm/boot/dts/imx6ull-colibri.dtsi:435
error: arch/arm/boot/dts/imx6ull-colibri.dtsi: patch does not apply
[ERROR]: Application of .kernel-meta//patches///0004-new-colibri.patch failed.
Patch needs to be refreshed. Sample resolution script:
.git/rebase-apply/resolve_rejects
ERROR: Could not apply patches for colibri-imx6ull.
ERROR: Patch failures can be resolved in the linux source directory /home/spark/oe-core/build/tmp/work/colibri_imx6ull-tdx-linux-gnueabi/linux-toradex/5.4.193+gitAUTOINC+5a24da287b-r0/git)
WARNING: exit code 1 from a shell command.
ERROR: Execution of ‘/home/spark/oe-core/build/tmp/work/colibri_imx6ull-tdx-linux-gnueabi/linux-toradex/5.4.193+gitAUTOINC+5a24da287b-r0/temp/run.do_patch.7097’ failed with exit code 1
I replaced the old patch and create the new one, here is my patch file:
The error from your last log shows this: Reference to non-existent node or label "pinctrl_gpio7". And it also says that this group is being referenced in other files like:
also defined at /home/spark/oe-core/build/tmp/work-shared/colibri-imx6ull/kernel-source/arch/arm/boot/dts/imx6ul.dtsi:783.27-786.6
also defined at /home/spark/oe-core/build/tmp/work-shared/colibri-imx6ull/kernel-source/arch/arm/boot/dts/imx6ull-colibri-lcdif.dtsi:21.9-61.3
also defined at /home/spark/oe-core/build/tmp/work-shared/colibri-imx6ull/kernel-source/arch/arm/boot/dts/imx6ull-colibri.dtsi:296.9-629.3
also defined at /home/spark/oe-core/build/tmp/work-shared/colibri-imx6ull/kernel-source/arch/arm/boot/dts/imx6ull-colibri-wifi.dtsi:174.9-179.3
also defined at /home/spark/oe-core/build/tmp/work-shared/colibri-imx6ull/kernel-source/arch/arm/boot/dts/imx6ull-colibri-eval-v3.dtsi:184.9-193.3
This explains why your final dts folder is ending empty. Therefore, I see two options for you:
Either create a patch that removes every reference to this node.
Either remove patches 3 and 4. As you removed the group from the pinctrl0 on your patch 2 you may not need to have patches 3 and 4.
So I’d suggest you testing option 2 first and come back with the results.
I tried this second option and it worked. There is no conflict of pins now and there is can on board.This is my dmesg output: dmesg-output.txt (145.8 KB)
The dts folder is empty. Is this going to create any problems in future?
Also for every change does I have to build the image again?
About your point, if your Colibri is either the 256 MB or the 512 MB versions, your module uses NAND memory and there, the device trees work a bit differently and the dts folder will be empty. You can see here for better reference: Updating NAND-based modules from userspace | Toradex Developer Center
If you want to deploy them to production yes, the changes need to be built so that they go by default on every module. For debug/development, there are other alternatives such as creating device tree overlays for specific stuff and so on. You can test it and then, later on, you’d need to rebuild it. So, it will depend on the use case.
