Display not working with iMX6D module that works with iMX7D and same hardware

Problems with a PowerTip 480x272 display wired for 24-bit display. I observe a correct display with a Colibri iMX7D-512 v1.1D module running your latest version of WEC2013.

The settings I use are:

On the same hardware with the same display settings, with a Colibri iMX6D-512 v1.1B module running your latest version of WEC2013, I get:


I should note the iMX6D module boot-up looks like this:


What is wrong? Same display settings on the same hardware other than the module change. I have read everything, checked everything multiple times, reset and rebooted… no dice. I need some help.

Since at bootloader stage your display works properly the splash screen settings are OK. Please doublecheck if [HKLM\Drivers\Display\Colibri] UseSplashSettings set to 1.

According to picture of your iMX6D module boot-up you are using V1.6 bootloader. Please update bootloader and OS image to the \1.7 version.

Where is v1.7 bootloader? Is that different than a general v1.7 WinCE8 release? The latest I can find is 1.6b2.

The UseSplashSettings is 1:

You can download the 1/7 image/bootloader here. Then you can update older OS image using the UpdateTool included in v1.7 package.

Ok, version 1.7 works. The “(Older Versions)” note beside the CE8 link on your distribution page make me think it was only the older versions, so I was not checking there. I suggest instead a note: “(Latest and prior versions)”

Ok, more on this topic… I have the Colibri iMX6D and Colibri iMX7D-512 booting in CE8 on our PCB.

I also have the Colibri iMX7D-1G booting on our PCB running a kernel image we compiled from:

Repository: linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules
Branch: toradex_5.4-2.3.x-imx

However, with Torizon installed on the iMX6D on the same PCB, I cannot get anything to execute on power-up. The UART-A console simply displays:

þ-Boot SPL 2020.07-5.5.0+git.421a6ba683f9 (Jan 01 1970 - 00:00:00 +0000)

and stops. Nothing further. Can you provide a hint as to why the iMX7D-512 (CE8), iMX7D-1G (Linux Debian kernel), and iMX6D (CE8) would boot on our PCB, but the iMX6D (Torizon) refuses? Without any console messages to provide a hint, I am at a loss.

The iMX6D (Torizon) module boots fine on an Aster carrier board.

U-Boot 2020.07-5.5.0+git.421a6ba683f9 (Jan 01 1970 - 00:00:00 +0000)

CPU:   Freescale i.MX6DL rev1.4 at 792MHz
CPU:   Industrial temperature grade (-40C to 105C) at 31C
Reset cause: POR
DRAM:  512 MiB
PMIC:  wait_for_sr_state: Arbitration lost sr=93 cr=80 state=2020
i2c_init_transfer: failed for chip 0x8 retry=0
wait_for_sr_state: Arbitration lost sr=93 cr=80 state=2020
i2c_init_transfer: failed for chip 0x8 retry=1
wait_for_sr_state: Arbitration lost sr=93 cr=80 state=2020
i2c_init_transfer: failed for chip 0x8 retry=2
i2c_init_transfer: give up i2c_regs=0x21a4000
failed to get device for PMIC at address 0x8
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
Model: Toradex Colibri iMX6 DualLite 512MB IT V1.1A, Serial# 10784400
Net:   eth0: ethernet@2188000
Hit any key to stop autoboot:  0
Unknown command 'set-io' - try 'help'
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
1182 bytes read in 12 ms (95.7 KiB/s)
## Executing script at 17000000
5374 bytes read in 22 ms (238.3 KiB/s)
62518 bytes read in 30 ms (2 MiB/s)
112 bytes read in 23 ms (3.9 KiB/s)
Applying Overlay: colibri-imx6_parallel-rgb_overlay.dtbo
766 bytes read in 32 ms (22.5 KiB/s)
Applying Overlay: colibri-imx6_stmpe-ts_overlay.dtbo
402 bytes read in 30 ms (12.7 KiB/s)
Applying Overlay: display-vga_overlay.dtbo
807 bytes read in 32 ms (24.4 KiB/s)
8376832 bytes read in 238 ms (33.6 MiB/s)
8051416 bytes read in 232 ms (33.1 MiB/s)
## Flattened Device Tree blob at 12100000
   Booting using the fdt blob at 0x12100000
   Loading Ramdisk to 1f852000, end 1ffffad8 ... OK
   Loading Device Tree to 1f81f000, end 1f851fff ... OK

Starting kernel ...

I notice that we have “SPL” for Secondary Program Loader" on our PCB. What does that imply about the failing boot process?


Could you please create a new thread for that question?