Torizon 6.3 release 4. (5.15.77-6.3.0) I2C causing total mayhem


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.


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

Step 2. Update the bootloader with Torizon Platform Services

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

    local: images/torizon-core-docker-colibri-imx8x-Tezi_6.3.0+build.4.tar

  splash-screen: splash/splash.png
        - linux/include
    custom: linux/arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dts
      clear: true
        # Enable the parallel RGB interface on Colibri iMX8X.
        - device-trees/overlays/colibri-imx8x_panel-res-touch-7inch_overlay.dts
    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


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,

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



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,