Hi,
I am wondering how I can check which device drivers are available by default in torizoncore?
The devices I am looking for are:
I am trying to choose devices for a carrier board which are already compatible with the available drivers so no modification to the kernel and device tree is required (This stuff is out of my league).
Any guidance would be welcome.
Greetings @geopaxpvtltd,
First of all let me dispel a misunderstanding here.
I am trying to choose devices for a carrier board which are already compatible with the available drivers so no modification to the kernel and device tree is required
Even if a device driver is enabled in the kernel, it may still require additional device tree changes to fully integrate your hardware. Though this is dependent on the hardware/driver itself.
Now as for your main question here’s what you would need to do:
zcat /proc/config.gz | grep <NAME OF KERNEL CONFIG YOU ARE INTERESTED IN>
Now the above is just checking whether the kernel config is enabled or not. As I said some drivers may still require additional device tree changes but that’s dependent on the driver/device and is a case by case basis. Though you can usually determine if device tree changes are needed by either looking at the kernel or looking at the in-kernel documentation for the driver.
With all that written, let me do an example with one of your devices of interest the NAU88C22YG.
CONFIG_SND_SOC_NAU8822$ zcat /proc/config.gz | grep CONFIG_SND_SOC_NAU8822
CONFIG_SND_SOC_NAU8822=m
I hope this helps clear things up.
Best Regards,
Jeremias
Thanks a lot @jeremias.tx
The aim of my question was basically that I had selected the NAU88C22 was that it had been used in a carrier board before. The other devices I have not seen them. so adding the DTO will be easier than enabling a kernel driver or adding one.
I was able to find the following:
According to my understanding before your previous post, I thought DTO is to be added when deviating from the default sets of pins assigned for the module.
but from the gist of your post, it appears that DTO is to be added for each enabled peripheral. which leads to my questions:
how did you arrive on this conclusion? by device tree integration you mean it needs a Device Tree Overlay?
I am sorry if the questions seem too trivial but its the only way to learn.
According to my understanding before your previous post, I thought DTO is to be added when deviating from the default sets of pins assigned for the module.
A device tree is a structure for describing what hardware is found in your system. The Linux kernel and it’s various drivers use the device tree to then figure out how to use the hardware on your system as you describe it.
Imagine this, imagine you have some kind of i2c device that has a respective driver. The driver knows how to interact with this device and make it operate. But, there are things the driver can’t know. For example, what pins is the i2c device connected to? What’s the i2c address of this device? If your device has an interrupt, then what pin is serving as the interrupt?
The device tree is where you tell the driver this information that it can’t know on it’s own. As well as some other information like how you want the device configured or such, if applicable. Since you’re looking to add new hardware for most cases you must therefore tell the software about this new hardware.
are DTOs specific to the carrier boards we use such as Dahlia or Yavia?
Device trees by nature are hardware specific. Depending on how things are hooked up the same device tree/overlay could be applicable to multiple hardware setups. Going back to my i2c example, well if you have the same i2c device connected to the same i2c pins for dahlia and yavia then there’s no effectively no difference. If you’re using different i2c pins between the two carrier boards, then yes that needs different device tree descriptions.
what if a kernel driver is not enabled in kernel but the manufacturer provides it?
Then you can try to integrate the driver as an out of tree driver. We have details on this here: Building External Kernel Modules With Torizon | Toradex Developer Center
Please note with out of tree drivers we can’t really debug or guarantee anything. All we provide is the tools to compile the source of the driver as provided, and place it into the system. It’s use and operation is not something we can really help with.
how did you arrive on this conclusion? by device tree integration you mean it needs a Device Tree Overlay?
I mean in this case you can see the documentation describes device tree bindings for this driver. Therefore it can be assumed that integrating this hardware will require device tree integration, otherwise why would there be documentation on device tree bindings for this driver in the first place? Also if you check the source code of this driver you can see it tries to parse the device tree for information, which corresponds to the device tree bindings documentation.
Also device tree describes the entire device tree. A device tree overlay is a fragment that gets applied on an already existing device tree. Think of a device tree as the source code for something, in which case an overlay would be like a patch to that source code. It doesn’t really matter which one you change as both affect the end result anyways.
Best Regards,
Jeremias
@jeremias.tx Thank you for so much of your time.
I was able to build an image containing an external kernel module and isolating /etc modifications from my device using the following tbuild file:
# >> NOTES:
# >> Lines containing ">>" are simply comments explaining the properties that
# >> follow; if you don't like these comments run:
# >> $ grep -v '>>' tcbuild.yaml > tcbuild-clean.yaml
# >> A line not containing ">>" can be uncommented (by removing the hash mark
# >> plus a space from its beginning); also set the corresponding property to
# >> appropriate values.
# >> When uncommenting a line having a property, remember to uncomment all its
# >> parent properties as well; for example: if you uncomment the
# >> 'splash-screen' property, also uncomment its parent property called
# >> 'customization'.
# >> The input section specifies the image to be taken as the base for the
# >> customization.
input:
easy-installer:
# >> Choose one of the options (REQUIRED):
# >> (1) Image as local folder or tarball.
local: torizon-core-docker-verdin-imx8mm-Tezi_6.3.0+build.4.tar
# >> (2) Remote file (optionally with a filename and or a sha256 checksum):
# remote: "https://artifacts.toradex.com/.../torizon-core-docker-apalis-imx8-Tezi_5.1.0%2Bbuild.1.tar"
# remote: "https://artifacts.toradex.com/.../torizon-core-docker-colibri-imx6-Tezi_5.0.0-devel-202009%2Bbuild.2.tar;filename=torizon-core-docker-colibri-imx6-Tezi_5.0.0-devel-202009+build.2.tar;sha256sum=368595fa3fb00af9604e70311de3b04df6b30b280deec2f8918c46f479026ddb"
# >> (3) Image specification (URL will be generated by the tool)
# toradex-feed:
# version: "5.1.0"
# release: quarterly
# machine: colibri-imx7-emmc
# distro: torizon-upstream
# variant: torizon-core-docker
# build-number: "1"
# # build-date: "20210408"
# >> The customization section defines the modifications to be applied to get
# >> the desired output image.
customization:
# >> Splash screen:
# splash-screen: custom-splash-screen.png
# >> Directories overlayed to the base OSTree
filesystem:
- changes1
# device-tree:
# >> Directories where to look for include files.
# include-dirs:
# - device-trees/include/
# >> Custom device tree source:
# custom: device-trees/dts-arm32/imx6ull-colibri-eval-v3.dts
# >> Device-tree overlays configuration:
# overlays:
# >> Whether to ignore all overlays from the base image (or ostree
# >> archive in the future).
# clear: false
# >> Specific overlays not to use from base image (useful only when
# >> clear is false and not DT has been selected).
# remove:
# - apalis-imx8_hdmi_overlay.dtbo
# >> Overlays to add to output image.
# add:
# - device-trees/overlays/display-edt7_overlay.dts
kernel:
# >> Custom kernel arguments.
# arguments:
# - key1=val1
# - key2=val2
# >> Modules to build and possibly load automatically.
# modules:
# - source-dir: virtual_touchscreen/
# autoload: false
modules:
- source-dir: gpio-pca953x
autoload: true
# >> The output section defines properties of the output image.
output:
# >> OSTree deployment configuration (relevant also for Easy Installer output).
# ostree:
# branch: my-dev-branch
# commit-subject: "OSTree commit subject"
# commit-body: "OSTree commit body"
# >> Parameters for deploying to an Easy Installer image.
easy-installer:
# >> Output directory of the customized image (REQUIRED):
local: output/torizon-core-docker-verdin-imx8mm-Tezi_6.3.0+build.4.CUSTOM
# >> Information used by Toradex Easy Installer:
# name: "My customized image"
# description: "My customized image (description)"
# licence: files/custom-licence.html
# release-notes: files/custom-release-notes.html
# accept-licence: true
# autoinstall: true
# autoreboot: true
# bundle:
# >> Choose one of the options:
# >> (1) Specify a docker-compose file whose referenced images will be downloaded.
# >> Properties platform, username, password and registry are optional.
# compose-file: files/docker-compose.yml
# platform: linux/arm/v7
# username: "${USERNAME}"
# password: "${PASSWORD}"
# registry: hub.docker.com
# >> (2) Specify a local directory containing the bundled images (previously
# >> obtained by 'torizoncore-builder bundle' command).
# dir: bundle/
# >> Provisioning configuration:
# provisioning:
# >> For "online" mode, properties "shared-data" and "online-data" must be specified.
# >> For "offline" mode, property "shared-data" must be specified alone.
# mode: "online"
# shared-data: "shared-data.tar.gz"
# online-data: "${ONLINE_PROVISIONING_DATA:?online provisioning data not supplied}"
Now the remaining question is, when a kernel module is loaded into the image, we need to modify the device tree. following the documentation to checkout the device tree, I get:
ha-01@HA-01-PC:~/tcbdir$ torizoncore-builder dt checkout
The TorizonCore Builder team is re-evaluating the device tree and device tree overlays workflow, and the dt checkout command is currently not supported on TorizonCore 6. Learn how to clone the device trees and overlays repositories on https://developer.toradex.com/torizon/os-customization/use-cases/device-tree-overlays-on-torizon/#clone-toradex-device-tree-and-overlays-repository.
Apologies I found the answer to that one. just to clone repos for these.
My question now is related to device tree and device tree overlay. so when working with a custom carrier board, do we need to specify the device tree by ourselves as well or just overlays for specific peripherals?
Also, once the driver is included in the image, we enable its functionality using the device tree or its specific overlay, right?
Hi @geopaxpvtltd !
Since you are getting started with Device Trees and Device Trees Overlays, I would like to share with you some articles that we created to help those who are starting on this topic or just have some questions.
I am sure it will help you to understand some fundamental aspects related to Device Tree [Overlay] and the examples will serve as a guide to you.
https://developer.toradex.com/software/linux-resources/device-tree/
Best regards,
@henrique.tx Thank you for the resources. I was able to create an overlay such as:
// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
/*
* Copyright 2023 Your Company Name
*/
/dts-v1/;
/plugin/;
/ {
compatible = "toradex,verdin-imx8mm";
};
&i2c1 {
status = "okay";
pca953x: gpio@21 {
compatible = "nxp,pca953x";
reg = <0x21>;
gpio-controller;
#gpio-cells = <2>;
};
};
and include it in the image using:
device-tree:
# >> Directories where to look for include files.
# include-dirs:
# - device-trees/include/
# >> Custom device tree source:
# custom: device-trees/dts-arm32/imx6ull-colibri-eval-v3.dts
# >> Device-tree overlays configuration:
overlays:
# >> Whether to ignore all overlays from the base image (or ostree
# >> archive in the future).
# clear: false
# >> Specific overlays not to use from base image (useful only when
# >> clear is false and not DT has been selected).
# remove:
# - apalis-imx8_hdmi_overlay.dtbo
# >> Overlays to add to output image.
add:
# - device-trees/overlays/display-edt7_overlay.dts
- device-trees/overlays/verdin-imx8mm_pca953x_overlay.dts
after deployment, I get the following msg in dmesg:
torizon@verdin-imx8mm-14756428:~$ dmesg | grep pca953x
[ 1.253226] pca953x 3-0021: using no AI
[ 1.253484] pca953x 3-0021: failed writing register
now since that device is not actually connected to the i2c, this is expected. But does this mean I was able to successfully create the image and the overlay was loaded or is it just a msg from the driver being autoloaded?
I noted the following messages during image build process:
=> Adding device-tree overlay 'device-trees/overlays/verdin-imx8mm_pca953x_overlay.dts'
2023-09-28 13:35:23,334 - torizon.tcbuilder.backend.dt - INFO - 'verdin-imx8mm_pca953x_overlay.dts' compiles successfully.
2023-09-28 13:35:23,388 - torizon.tcbuilder.cli.dto - INFO - Overlay verdin-imx8mm_pca953x_overlay.dtbo successfully applied.
2023-09-28 13:35:23,388 - torizon.tcbuilder.cli.build - INFO -
After this, I unpacked and deployed the image as follows:
ha-01@HA-01-PC:~/tcbdir$ torizoncore-builder images unpack output/torizon-core-docker-verdin-imx8mm-Tezi_6.3.0+build.4.CUSTOM/
Storage not empty. Delete current image before continuing? [y/N] y
Copying Toradex Easy Installer image.
Unpacking TorizonCore Toradex Easy Installer image.
Importing OSTree revision 8ea413da688e7e496937a04d5d217e13a7a3656251808d5fbf0be71b6c363b33 from local repository...
964 metadata, 9255 content objects imported; 588.4 MB content written
0 metadata, 0 content objects imported; 0 bytes content written
Unpacked OSTree from Toradex Easy Installer image:
Commit checksum: 8ea413da688e7e496937a04d5d217e13a7a3656251808d5fbf0be71b6c363b33
TorizonCore Version: 6.3.0+build.4-tcbuilder.20230928133540
ha-01@HA-01-PC:~/tcbdir$ torizoncore-builder deploy --remote-host 192.168.0.158 --remote-username torizon --remote-password hasann99 --reboot
Pulling OSTree with ref base (checksum 8ea413da688e7e496937a04d5d217e13a7a3656251808d5fbf0be71b6c363b33) from local archive repository...
Starting http server to serve OSTree.
OSTree server listening on "localhost:44279".
Starting OSTree pull on the device...
Deploying new OSTree on the device...
Deploying successfully finished.
Device reboot initiated...
But after the deployment, all my previously running application containers were still running as well.
Hi @geopaxpvtltd !
To check if the device tree overlay was loaded, you can:
/boot/ostree/torizon-<ostree-hash>/dtb/overlay.txt and your overlay (the .dtbo) should also be inside /boot/ostree/torizon-<ostree-hash>/dtb/overlays.
<ostree-hash>, you can use tdx-info and check the “Kernel command line”. The hash will be in the parameter ostree=/ostree/boot.1/torizon/<ostree-hash>/0tdx-info: Getting Device Information with Tdx-Info | Toradex Developer CenterBtw, IIRC, you could even set autoload=false, as the drive would be anyway loaded once it is setup on the device tree [overlay] and is physically connected.
Best regards,
Hello @henrique.tx !
Apparently the load was successful.
torizon@verdin-imx8mm-14756428:/$ sudo tdx-info -dt
Device tree
------------------------------------------------------------
Device tree enabled: imx8mm-verdin-wifi-dev.dtb
Compatible string: toradex,verdin-imx8mm-wifi-devtoradex,verdin-imx8mm-wifitoradex,verdin-imx8mmfsl,imx8mm
Device trees available:
imx8mm-verdin-nonwifi-dahlia.dtb
imx8mm-verdin-nonwifi-dev.dtb
imx8mm-verdin-nonwifi-yavia.dtb
imx8mm-verdin-wifi-dahlia.dtb
imx8mm-verdin-wifi-dev.dtb
imx8mm-verdin-wifi-yavia.dtb
------------------------------------------------------------
Device tree overlays
------------------------------------------------------------
Overlays enabled: fdt_overlays=verdin-imx8mm_dsi-to-hdmi_overlay.dtbo verdin-imx8mm_spidev_overlay.dtbo verdin-imx8mm_pca953x_overlay.dtbo
Overlays available:
verdin-imx8mm_20mhz_can1.dtbo
verdin-imx8mm_disable_can1.dtbo
verdin-imx8mm_dsi-to-hdmi_overlay.dtbo
verdin-imx8mm_dsi-to-lvds_panel-cap-touch-10inch-lvds_overlay.dtbo
verdin-imx8mm_hmp_overlay.dtbo
verdin-imx8mm_nau8822-btl_overlay.dtbo
verdin-imx8mm_ov5640_overlay.dtbo
verdin-imx8mm_pca953x_overlay.dtbo
verdin-imx8mm_spidev_overlay.dtbo
------------------------------------------------------------
but the software information does not show the name of my image with a .CUSTOM at the end:
torizon@verdin-imx8mm-14756428:/$ sudo tdx-info -s
Software summary
------------------------------------------------------------
Bootloader: U-Boot
Kernel version: 5.15.77-6.3.0+git.ddc6ca4d76ea #1-TorizonCore SMP PREEMPT Thu Jun 29 10:14:22 UTC 2023
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/9095997cb4a2c8f21e6c7037be71b331dd1f68a1af206c94b8855349db7cf3c4/0
Distro name: NAME="TorizonCore"
Distro version: VERSION_ID=6.3.0-build.4
Hostname: verdin-imx8mm-14756428
------------------------------------------------------------
Now one last question: Will I have to do this for all the peripherals i connect on the custom carrier board? and when done, it will work as the carrier boards by toradex do?
Best Regards,
Hassan.
but the software information does not show the name of my image with a .CUSTOM at the end:
That was just the name of the directory/file you created with TorizonCore Builder. This doesn’t actually reflect on the name of the software or version.
Now one last question: Will I have to do this for all the peripherals i connect on the custom carrier board? and when done, it will work as the carrier boards by toradex do?
More or less yes, some peripherals might have their own quirks or slightly difference processes. It’s hard to say beforehand without doing the work and investigation on a specific peripheral.
Best Regards,
Jeremias