Hi,
I am putting my Colibri imx8xqxp modules through their paces with Torizon 6.3.
We have the need for 2 I2C and so have a custom overlay to allow access to I2C-0.
/dts-v1/;
/plugin/;
/ {
compatible = "toradex,colibri-imx8x";
};
/* enable the i2c0_mipi_lvds0 */
&i2c0_mipi_lvds0 {
status = "okay";
/* SMBUS standard device */
};
So after using easy installer to flash the module, I log in and have a look at the devices.
torizon@colibri-imx8x-07020000:~$ ls -l /dev/i2*
crw-rw-r-- 1 root i2cdev 89, 0 Sep 30 23:56 /dev/i2c-0
crw-rw-r-- 1 root i2cdev 89, 1 Sep 30 23:56 /dev/i2c-1
crw-rw-r-- 1 root i2cdev 89, 16 Sep 30 23:56 /dev/i2c-16
Was expecting i2c-16, i2c-17 and i2c-18.
What should I do about it?
Could this be to do with the update pathway? I did get version 5.7.2 on the module first, and it didn’t have either the gpio-poweroff driver with the “force-mode” option, whilst not having the driver for the RTC I am using (this is in 5.15 and it worked perfectly first time with minor hassle!)
I also notice that my Colibri install had to have its permissions updated to enable Docker to work, and the command history doesn’t work either. Is not putting a 5.7.2 build onto the module not enough to upgrade to 6.3.0. I kind of doubt it because, this was to do with uboot I think?
What process should I follow to install 6.3 on these Colibri imx8x modules?
Yours Truly
Fat Linux
I went right back to the beginning and started over, with just the very basic overlay to get the display to work. Still getting oddly labelled I2C devices
Step 1. Update to version 5.7.2
torizon@colibri-imx8x-xxx:~$ hostnamectl
Static hostname: colibri-imx8x-xxx
Icon name: computer
Machine ID: 8580ebc2aed64b928a0d91a149ebd881
Boot ID: e90096e0316b4250844d061a1ee887eb
Operating System: TorizonCore 5.7.2+build.20 (dunfell)
Kernel: Linux 5.4.193-5.7.2+git.b60d3160fd04
Architecture: arm64
torizon@colibri-imx8x-07021199:~$
Step 2. Update the bootloader with Torizon Platform Services
Bootloader
Type: colibri-imx8x-bootloader
Installed package: bootloader/colibri-imx8x/u-boot-ota.bin
Version: 2022.04-6.2.0-devel+git.0e1f11392251-n216
Hash: xzsdadssdsad
Latest version
Step 3. YAML file easyinstaller image
input:
easy-installer:
local: images/torizon-core-docker-colibri-imx8x-Tezi_6.3.0+build.4.tar
customization:
splash-screen: splash/splash.png
device-tree:
include-dirs:
- linux/include
custom: linux/arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dts
overlays:
clear: true
add:
# Enable the parallel RGB interface on Colibri iMX8X.
- device-trees/overlays/colibri-imx8x_panel-res-touch-7inch_overlay.dts
output:
easy-installer:
local: images/torizon-core-docker-colibri-imx8x-Tezi_6.3.0-CUSTOM
name: "Torizon 6.3.0 on linux 5.15"
description: "Torizon OS with RTC and rev6.3"
Step 4. Build the ting
torizon@Thinkcentrei9:~/Torizon3$ torizoncore-builder build
Building image as per configuration file 'tcbuild.yaml'...
=>> Handling input section
Unpacking Toradex Easy Installer image.
Copying Toradex Easy Installer image.
Unpacking TorizonCore Toradex Easy Installer image.
Importing OSTree revision 704341229e36413cdbda9649bd7e217c01deabb83f3b188769396c05590c5b9a from local repository...
939 metadata, 9193 content objects imported; 574.5 MB content written
0 metadata, 0 content objects imported; 0 bytes content written
Unpacked OSTree from Toradex Easy Installer image:
Commit checksum: 704341229e36413cdbda9649bd7e217c01deabb83f3b188769396c05590c5b9a
TorizonCore Version: 6.3.0+build.4
=>> Handling customization section
=> Setting splash screen
splash screen merged to initramfs
=> Handling device-tree subsection
=> Selecting custom device-tree 'linux/arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dts'
'imx8qxp-colibri-eval-v3.dts' compiles successfully.
warning: removing currently applied device tree overlays
Device tree imx8qxp-colibri-eval-v3.dtb successfully applied.
=> Adding device-tree overlay 'device-trees/overlays/colibri-imx8x_panel-res-touch-7inch_overlay.dts'
'colibri-imx8x_panel-res-touch-7inch_overlay.dts' compiles successfully.
/tmp/tmpul0xy_y4: Device Tree Blob version 17, size=121954, boot CPU=0, string block size=7986, DT structure block size=113912
'colibri-imx8x_panel-res-touch-7inch_overlay.dtbo' can successfully modify the device tree 'imx8qxp-colibri-eval-v3.dtb'.
Overlay colibri-imx8x_panel-res-touch-7inch_overlay.dtbo successfully applied.
=>> Handling output section
Applying changes from STORAGE/splash.
Applying changes from STORAGE/dt.
Commit 150b29cfdc36171d4301e353772dd0b94d852f7616b8c42040439fc738fcf2c4 has been generated for changes and is ready to be deployed.
Deploying commit ref: tcbuilder-20231001165133
Pulling OSTree with ref tcbuilder-20231001165133 from local archive repository...
Commit checksum: 150b29cfdc36171d4301e353772dd0b94d852f7616b8c42040439fc738fcf2c4
TorizonCore Version: 6.3.0+build.4-tcbuilder.20231001165134
Default kernel arguments: quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3
939 metadata, 9193 content objects imported; 574.6 MB content written
Pulling done.
Deploying OSTree with checksum 150b29cfdc36171d4301e353772dd0b94d852f7616b8c42040439fc738fcf2c4
Deploying done.
Copy files not under OSTree control from original deployment.
Packing rootfs...
Packing rootfs done.
Updating TorizonCore image in place.
=>> Build command successfully executed!
Step 5. Copy the custom file onto a USB and run EasyInstaller
Step 6. Boot and login to the module
torizon@colibri-imx8x-XXXX:~$ uname -a
Linux colibri-imx8x-XXXX 5.15.77-6.3.0+git.ddc6ca4d76ea #1-TorizonCore SMP PREEMPT Thu Jun 29 10:14:22 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux
torizon@colibri-imx8x-XXXXX:~$ hostnamectl
torizon@colibri-imx8x-XXXXX:~$ hostnamectl
Static hostname: colibri-imx8x-07021203
Icon name: computer
Machine ID: XXXX
Boot ID: XXXXX
Operating System: TorizonCore 6.3.0+build.4 (kirkstone)
Kernel: Linux 5.15.77-6.3.0+git.ddc6ca4d76ea
Architecture: arm64
check out the user space device labels:
$ ls /dev/i2c*
/dev/i2c-0 /dev/i2c-1
So does this new Linux version NOT create the I2C devices statically, and so I need to find a way to convince the new version to do this? or do I need to rewrite my C++ code to access the I2C devices a different way, as they use the user space drive names like /dev/i2c-16, /dev/i2c-17 and /dev/i2c-18 ?
So looking forward to doing the Bluetooth stuff tomorrow…!
Yours Truly
Richard
Greetings @FatLinux,
I did a quick test and I think I know what’s happening here. Here’s the default i2c devices on Torizon OS 5.7:
i2cdetect -l
i2c-17 i2c 5a810000.i2c I2C adapter
i2c-16 i2c 5a800000.i2c I2C adapter
And here they are on 6.3:
i2cdetect -l
i2c-0 i2c 5a800000.i2c I2C adapter
i2c-1 i2c 5a810000.i2c I2C adapter
As you’ve observed the names are now different. For example 5a800000.i2c refers to the on-module i2c that is not accessible on the module’s edge connector. In 5.7 this was i2c-16 but now in 6.3 it is i2c-0.
Unfortunately, the kernel itself is responsible for how the names are enumerated for devices. It does not guarantee any consistency in these names. Probably between the two Linux versions the naming logic got changed or updates resulting in this.
If you require consistent names for these devices you can use udev rules. For example a udev rule like this:
ACTION=="add|change", KERNEL=="i2c-[0-9]*", ATTRS{name}=="5a810000.i2c", SYMLINK+="colibri-i2c"
ACTION=="add|change", KERNEL=="i2c-[0-9]*", ATTRS{name}=="5a800000.i2c", SYMLINK+="colibri-i2c-on-module"
Will cause the interfaces to be symlinked to consistent names based on the given address. In fact we already use this particular udev rules on our own system as seen here:
torizon@colibri-imx8x-06750825:~$ ls -l /dev/colibri-i2c
lrwxrwxrwx 1 root root 5 Oct 2 19:25 /dev/colibri-i2c -> i2c-1
torizon@colibri-imx8x-06750825:~$ ls -l /dev/colibri-i2c-on-module
lrwxrwxrwx 1 root root 5 Oct 2 19:25 /dev/colibri-i2c-on-module -> i2c-0
This way your application can refer to these names for consistent and predictable naming. Since you require additional i2c interfaces you’ll need to create your own udev rule for this.
Best Regards,
Jeremias
1 Like
Hi @FatLinux !
Complementing @jeremias.tx’s answer, you can use TorizonCore Builder to add that change to your customized TorizonCore.
Best regards,
1 Like
Hi @jeremias.tx
This has turned out to be a happy accident. I was always concerned that my C++ code that uses simple code to open an device name fixed by somebody else, maybe they decide to change it. My code would then break… probably at the weekend. In the previous time, we had i2C-17 and i2C-18 and sure enough something did change !
snprintf (device_filename, sizeof (device_filename), "/dev/i2c-17");
device_file = open (device_filename, O_RDWR);
Since I got access to the udev manager, I changed my links to the i2c hardware a little stronger.
torizon@colibri-imx8x-07021199:/etc/udev/rules.d$ cat 89-custom-i2c.rules
ACTION=="add|change", KERNEL=="i2c-[0-9]*", ATTRS{name}=="5a810000.i2c", SYMLINK+="i2c-ad5933"
ACTION=="add|change", KERNEL=="i2c-[0-9]*", ATTRS{name}=="56226000.i2c", SYMLINK+="i2c-battery"
And then my C++ code got changed a little
snprintf (device_filename, sizeof (device_filename), "/dev/i2c-ad5933");
device_file = open (device_filename, O_RDWR);
I just tested it and it all works fine. It would need some much bigger and fundamental changes to change the names of those I2C devices in the kernel. Maybe more robust?
Thank you for your suggestions
Cheers
Richard
I just tested it and it all works fine. It would need some much bigger and fundamental changes to change the names of those I2C devices in the kernel. Maybe more robust?
What you’ve done here should be perfectly acceptable. Your udev rule looks fairly solid and for it to break would require the kernel to use a different naming scheme then /dev/i2c-[some number], which is highly unlikely to happen. Any such change would only happen on a major change of the kernel version anyways. In which case you’d probably need to review and re-base your solution like you did here going from TorizonCore 5.7 to 6.3.
Best Regards,
Jeremias
