Kernel Migration IMX8 Apalis

I am trying to migrate the linux-toradex kernel from 5.4.-2.3.x-imx to 6.6-2.0.x-imx version and I am using a custom carrier board with the IMX8 Apalis v1.1 Toradex.

At first glance when migrating the kernel everything seemed fine until I noticed that the GPS Module and Wireless Modem were not being detected with the new kernel build. When using that same build with the Ixora Development board the GPS and Modem were detected without any problems. Later I found out that it looks like the GPS and Modem are sharing GPIO Chip 0 Pin 30 as their reset line and when I set that pin high with gpioset 0 30=1 the GPS and Modem will connect only for a short period of time and then disconnect straight away:

[  236.342383] usb 1-1.3: new full-speed USB device number 3 using ci_hdrc
[  236.497600] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
[  236.503186] usbcore: registered new interface driver cdc_acm
[  236.510021] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[  236.631326] usb 1-1.3: USB disconnect, device number 3

It is also good to note that when I try and set the pin with the -m wait flag (gpioset -m wait 0 30=1) the devices do not disconnect until some user input.

I think the main question is how can I change the device tree so that pin starts up as high and stays that way?

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Hello,

To address the issue of your GPS module and wireless modem not being detected on your custom carrier board after migrating the kernel, you need to modify the device tree to ensure that GPIO Chip 0 Pin 30 is set high by default.

The device tree is a data structure for describing hardware, which the Linux kernel uses to configure devices. To set a GPIO pin high by default, you need to edit the device tree source (DTS) file for your board.

Here are the steps to modify the device tree:

  1. Locate the Device Tree Source File: Identify the DTS file for your custom carrier board. This file is typically named based on your board’s configuration, such as imx8-apalis-custom.dts.

  2. Edit the DTS File: Open the DTS file in a text editor. You need to find the section that defines the GPIO settings for your board.

  3. Modify the GPIO Configuration:

    • Locate the node that corresponds to the GPIO controller, often named something like gpio@30200000.
    • Add or modify the pin configuration to set GPIO Chip 0 Pin 30 high. This is done by adding a gpio-hog entry. For example:
      gpio@30200000 {
          compatible = "fsl,imx8-gpio";
          gpio-controller;
          #gpio-cells = <2>;
          pinctrl-names = "default";
          pinctrl-0 = <&pinctrl_gpio1>;
      
          gps_modem_enable {
              gpio-hog;
              gpios = <&gpio1 30 GPIO_ACTIVE_HIGH>;
              output-high;
          };
      };
      
    • This configuration sets GPIO1_30 high by default.
  4. Recompile the Device Tree: After editing, recompile the device tree to generate the new device tree blob (DTB) file.

  5. Deploy the New DTB: Replace the existing DTB file on your device with the newly compiled one and reboot the system.

By following these steps, GPIO Chip 0 Pin 30 should be set high by default, allowing your GPS module and wireless modem to be detected correctly on your custom carrier board.

Best regards,
Toradex AI Assistant.

Please, also check if these links can help you solve your problem:

Real-time scheduler in TorizonCore container.

Dear @matheus.abrao,

Thank you for contacting us and welcome to our community! :slight_smile:

I have a question regarding this section of your previous message:

Is this behaviour being observed on the custom carrier board or also on the Ixora carrier board?

Best regards,
Collin

Hi Collin,

Thanks for the reply. The behaviour is observed only on the custom carrier board.

Best,
Matheus

Hi all,

Any help with this issue? Please ask any clarifying questions!

Matheus

Dear @matheus.abrao,

Apologies for the late reply.
I am checking this out with my team and will get back to you as soon as possible. We are looking into the functionality of the gpio0 pin 30 and the GPS behaviour.

Best regards,
Collin

Hi Collin,

Thanks for getting back to me :slight_smile:

Wanted to reiterate that with the same carrier board and toradex module, everything worked as expected using the linux-toradex kernel 5.4.-2.3.x-imx and the issue appeared on 6.6-2.0.x-imx.

Furthermore, I believe the reason why it works on the Ixora Board is that the Modem was connected to my Ixora via PCIE and the device tree (imx8-apalis-v1.1.dtsi) coming from the linux-toradex 6.6-2.0.x-imx kernel sets GPIO0 IO30 as the pinctrl_reset_moci:

/* On-module RESET_MOCI#_DRV */
	pinctrl_reset_moci: resetmocigrp {
		fsl,pins = <IMX8QM_SCU_GPIO0_02_LSIO_GPIO0_IO30			0x00000021>;
};

And that then gets used by the picea node:

/* Apalis PCIE1 */
&pciea {
	ext_osc = <1>;
	fsl,max-link-speed = <1>;
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_reset_moci>;
	reset-gpio = <&lsio_gpio0 30 GPIO_ACTIVE_LOW>;
	vpcie-supply = <&reg_pcie_switch>;
};

Since that pin is being used as the reset line for our modem and gps connections (on the custom carrier board), I thought that maybe disabling the pciea node or assigning pinctrl_reset_moci to another unused gpio would help but unfortunately that was not the case or maybe I am not doing those correctly. Let me know if this helps or if you think I am going on the right path…

Best regards,
Matheus

Dear @matheus.abrao,

Thank you for the explanation and the hypothesis regarding the GPIO0 IO30.
I have just checked the device trees with a tool one of my colleagues created called find_in_devicetree. This tool allows us to check the device tree files which are included until the destination defined in the command.

This was done by entering the following in the CLI in both the branches ( 5.4.-2.3.x-imx and 6.6-2.0.x-imx:

find-in-dt imx8qm-apalis-v1.1-ixora-v1.1.dts GPIO0_IO30

Looking at the output it looks identical:

Would it be possible for you to check for differences between the two images by doing:

zcat /proc/config.gz | grep -i gps

and maybe also check the lsmod command and look for the gps output.

Best regards,
Collin