Device tree overlay builds, but the image won't boot back

Technical Support
, , ,
1

Hi!!

While trying to configure the rest of my hardware with a device tree overlay, I ran into a problem. Basically, I need to redefine some pins within the groups included in my code, as I need those pins for other purposes. dtconf runs with no problem, even validate without any problems, but when I enable the overlay, the system won’t boot.

Here’s what the overlay looks like:
/dts-v1/;
/plugin/;

#include "imx6dl-pinfunc.h"


/ {
	compatible = "toradex,colibri_imx6dl", "fsl,imx6dl";
	fragment@0 {
		target = <&iomuxc>;
		__overlay__ {
			pinctrl_uart2_dte: uart2dtegrp {
				fsl,pins = <
					 MX6QDL_PAD_SD4_DAT4__UART2_TX_DATA	0x1b0b1
					 MX6QDL_PAD_SD4_DAT7__UART2_RX_DATA	0x1b0b1
				>;
			};
			pinctrl_uart1_ctrl: uart1ctrlgrp {
				fsl,pins = <
					 MX6QDL_PAD_EIM_D23__UART1_DCD_B		0x1b0b0
				>;
			};
			pinctrl_uart1_dte: uart1dtegrp {
				fsl,pins = <
					 MX6QDL_PAD_CSI0_DAT10__UART1_RX_DATA	0x1b0b1
					 MX6QDL_PAD_CSI0_DAT11__UART1_TX_DATA 	0x1b0b1
				>;
			};
			pintctrl_usdhc1: usdhc1grp {
				fsl,pins = <
					 MX6QDL_PAD_SD1_CLK__SD1_CLK			0x10071
				>;
			};
		};
	};
};

I tried doing it in steps. It is with uart1dtegrp when it crashes. In my board, there is no connection for UART1. I know that is the debugging interface, but I would think that if I left TX and RX untouched, there would be no problem.

Thanks in advance!

2

Greetings @jaimeibk,

Yes this appears to be a recent known issue that has also popped up in another community post here: https://www.toradex.com/community/questions/47979/how-to-enable-pins-as-gpio.html?smartspace=torizon

Though in that case they disabled the uart1 interface completely. Here it seems you kept the uart1 interface enabled but you reassigned some pins correct?

Can you add any more detail for example when you say it doesn’t boot I assume u-boot boots up but it hangs when trying to pass into the Linux kernel? Does the splash screen hang as well?

I’ll look into this a bit but I might need to escalate the issue as it is rather unusual that uart1 has any effect on booting.

Best Regards,
Jeremias

3

Hi, @jeremias.tx !!

So, I am going to look into that post a little more. In the meantime:

–Here it seems you kept the uart1 interface enabled but you reassigned some pins correct?
Yes, that’s correct.

–Can you add any more detail for example when you say it doesn’t boot I assume u-boot boots up but it hangs when trying to pass into the Linux kernel? Does the splash screen hang as well?
U-Boot boots up, but it hangs just when passing into the kernel. Splash screen hangs as well.

I appreciate the help.

Jaime

4

Hi, @jeremias.tx !!

Quick update: I tried disabling uart1 altogether before assigning the pins. It hangs past U-Boot. Furthermore, it surprised me that even when disabling uart1, I was still able to see an output… I should not be able to do that after disabling uart1, am I right?

5

I tried reassigning only the uart1ctrlgrp, rather than the uart1dtegrp to get the same result.

Here’s the output of U-Boot:
U-Boot 2019.07-0.0.0-devel+git.03cac08 (Jan 01 1970 - 00:00:00 +0000)

CPU:   Freescale i.MX6DL rev1.3 996 MHz (running at 792 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 53C
Reset cause: WDOG
DRAM:  512 MiB
PMIC:  device id: 0x10, revision id: 0x21, programmed
MMC:   FSL_SDHC: 1, FSL_SDHC: 0
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
Model: Toradex Colibri iMX6 DualLite 512MB V1.0A, Serial# 05079871
Net:   using PHY at 0
FEC [PRIME]
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
2440 bytes read in 13 ms (182.6 KiB/s)
## Executing script at 17000000
445 bytes read in 18 ms (23.4 KiB/s)
59776 bytes read in 26 ms (2.2 MiB/s)
80 bytes read in 10 ms (7.8 KiB/s)
Applying Overlay: display_5_parallel.dts.dtbo
581 bytes read in 12 ms (46.9 KiB/s)
Applying Overlay: weim_dis_v3.dts.dtbo
441 bytes read in 10 ms (43 KiB/s)
Applying Overlay: uart1dis.dts.dtbo
319 bytes read in 10 ms (30.3 KiB/s)
8000000 bytes read in 226 ms (33.8 MiB/s)
3257668 bytes read in 108 ms (28.8 MiB/s)
## Flattened Device Tree blob at 12100000
   Booting using the fdt blob at 0x12100000
   Using Device Tree in place at 12100000, end 12131fff

As you can see, u-boot sees three overlays I am using. The last one, uart1dis.dts.dtbo is where I set to disable the status. Past this point, it hangs while Starting kernel ...

6

@jaimeibk

Disabling uart1 only disables serial debug output for the kernel. U-Boot should still be unaffected the minute it passes into the kernel though output should cease, which is why after Starting kernel ... you see nothing. Though as we have seen the system just hangs in general as can be seen from the connected display.

Also just an update, the issue seems to be Torizon specific as disabling uart1 in our other BSP still allows the system to boot, though with no serial debug output of course.

I’ve created a ticket and elevated the issue with our Torizon team. I’ll keep this post updated with any developments but expect some delay as the team is in last minute preparations for embedded world next week and also a number of the team will be gone attending the show next week as well.

Best Regards,
Jeremias

8

Hi, @jeremias.tx !!

It makes sense.

– the issue seems to be Torizon specific as disabling uart1 in our other BSP still allows the system to boot, though with no serial debug output of course.

That’s good news. Then we can reasonably expect this to be fixed, right?

– I’ve created a ticket and elevated the issue with our Torizon team. I’ll keep this post updated

Thanks! I will work on other tasks in the meantime.

Cheers!

9

Hi @jaimeibk,

Just wanted to report back that the UART1 issue has been fixed, you can access builds of Torizon with the fix using our CI/CD feeds via Easy Installer. Though this fix will also be a part of the quarterly release at the end of the month.

Best Regards,
Jeremias

10

Hi, @jeremias.tx !

Thank you for the feedback. However, since I need to include the touchscreen driver into the image, I can just go along this and the fix should work, right?

Regards,

Jaime

11

Hi @jaimeibk,

Yes you just need to update your build to get the latest changes. For reference the title of the commit that fixes this is “initramfs-framework: fix a boothang when console=null” which should be in the meta-toradex-torizon layer. In case you wanna confirm if you have pulled in the change proper.

Best Regards,
Jeremias

12

@jeremias.tx

Thanks! I will test this asap.

Cheers!

13

You are welcome. We will wait for your results.