Colibri iMX6ULL DeviceTree eval-v3 vs iris-v2

Hello,

We are currently porting our own Yocto distribution towards the Toradex hardware platform, which is going quite well. Our hardware setup uses the iMX6ULL 512MB module (inc. WiFi, BT), for development we use the iris V2 board,
and for production the Viola board is used. The kernel version is 5.4 which comes from the NXP bsp, this boots and functions as expected.

The question that we have is regarding the device tree: by default Toradex loads the imx6ull-colibri-wifi-eval-v3 device tree which works. If we move to the imx6ull-colibri-wifi-iris-v2 then that won’t work, due to errors found during the start up process, one of the error is regarding the SDcard (which can’t be detected correctly), so boot-up fails in our situation.

[   16.393132] imx-sdma 20ec000.sdma: loaded firmware 3.5
[   16.639823] sdhci-esdhc-imx 2190000.usdhc: error -110 requesting status
[   16.648395] mmcblk0: recovery failed!
[   16.653963] blk_update_request: I/O error, dev mmcblk0, sector 62333824 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[  OK  ] Reached target Hardware activated USB gadget.
[   16.719461] sdhci-esdhc-imx 2190000.usdhc: error -110 requesting status
[   16.729022] mmcblk0: recovery failed!
[   16.766678] blk_update_request: I/O error, dev mmcblk0, sector 62333824 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

This brings me to the questions:

  1. Why does the eval-v3 device tree works and the iris-v2 won’t? As far I can tell the basis is identical up to the actual board configurations, which obviously differ.

  2. Do we require to construct two device tree files one for the Viola and one for the Iris, because the Iris board doesn’t have the SDcard pull ups whilst the Viola has them. Or can we just enable the pull-ups and place them in parallel when
    inserted into a Viola board?

Thank you in advance,

Jeffrey.

Hi @Jeffrey, how are you?

Welcome to our community :rocket: ! Please feel free to roam around.

About your questions, we’re checking but we’d need some additional information to reply to them properly. Can you please confirm some additional information for us?

Are you using which Image on your module? Is this the Reference Minimal/Multimedia Image with Downstream Kernel?

From which repository is your kernel coming and which branch? (Please have a look here for completeness: Build U-Boot and Linux Kernel from Source Code | Toradex Developer Center)

Does this happen only when you load the Iris device tree on the Viola Board? If you load the Iris device tree on the Iris board does it boot properly?


Finally, can you please share with us a full dmesg output?

Best regards,

Hello @gclaudino.tx ,

Thank you for your quick response to my question.

We have our own image which is derived from the reference minimal image, Yes it is based on the Downstream kernel (linux-toradex).

Our own distribution was already developed first for hardnott and now kirkstone. We know that you are not fully supporting kirkstone yet, but we use the master branches of all Toradex repos (with the exception of meta-toradex-demos which we don’t use), all the Freescale meta layers are pointing to the kirkstone branches.
Every repository points to the latest commit on their respectable branches. The kernel repository points to the toradex_5.4-2.3.x-imx branch (as per linux-toradex_5.4-2.3.x.bb recipe from the meta-freescale-3rparty layer).

Both Viola and Iris show the same behaviour, regarding detection of the SD-card. The imx6ull-colibri-wifi-eval-v3 device tree works on both with respect to the SDcard interface except for some missing hardware features.
On a site note I could not find any device tree files for the Viola, so I assumed it was compatible with the Iris one?

I also verified your latest Reference image 5.7 from the recovery system, which shows the same behaviour. I attached 3 dmesg outputs, one of your boards with the iris-v2 device tree and two of our custom image with eval-v3 and iris-v2 enabled device trees. One remark I modified the dmesg files by masking my home network properties, I use nfs and tftp for quick validation of the Yocto images.

dmesg-result.tar (70 KB)

I hope that I have addressed everything you requested, otherwise let me know if I have forgotten anything.

With kind regards,

Jeffrey

Edited: resolved a typo.

Hi @Jeffrey,

Thanks for sharing this additional information. We’re going to test it on our side and we may come back to you soon.

Just to be sure of your final goal:

  • Are you trying to boot from SD Card or do you want to have it as a common data device?

And about your question:

Indeed there is no Viola device tree so you should be fine using the Evaluation Board one but, of course, Viola doesn’t have all the devices available.

Best regards,

Hi @gclaudino.tx

Your welcome, I hope that you see the same behaviour as me that would make things easier.

Currently we are still in the process of choosing our main storage device. Although I expect that we will move
towards the storage location in NAND Flash and use the SD Card as a secondary storage device.

Understood, thank you for clarifying this.

With kind regard,

Jeffrey

Hey Jeffrey,

Just a shot in the dark, but if you configure the device tree for a slower max frequency for the sdcard, do you get better results? Throw a max-frequency = <5000000>; in there and see if the sd detect works better. I’ve seen quite picky results with different platforms and even different kernel debug options.

Hello @DaveM ,

Thank you for responding, I have validated the current SD settings and they already run at 50MHz.

SDcard with iris-v2 device tree:

clock:       50000000 Hz
vdd:	     21 (3.3 ~ 3.4 V)
bus mode:    2 (push-pull)
chip select: 0 (don't care)
power mode:  2 (on)
bus width:   2 (4 bits)
timing spec: 2 (sd high-speed)
signal voltage: 0 (3.30 V)
driver type:	0 (driver type B)

SDcard with eval-v3 device tree:

clock:       50000000 Hz
vdd:		 21 (3.3 ~ 3.4 V)
bus mode:    2 (push-pull)
chip select: 0 (don't care)
power mode:  2 (on)
bus width:   2 (4 bits)
timing spec:	2 (sd high-speed)
signal voltage:	0 (3.30 V)
driver type:	0 (driver type B)

Or did you mean a different setting?

With kind regards,

Jeffrey

Ya sorry…I meant limit the max speed to 5MHz in the device tree and see if the sdcard works. Or did you mean that you’ve already figured out that the pullups on one board vs the other are the problem with getting a working sdcard environment?

– Dave

@DaveM

Perhaps you misunderstood my original question. I have a working setup when I load the eval-v3 device tree.
It fails to connect to the SDcard when I use the iris-v2 device-tree. The reasoning for my question is that I don’t
know what the reason is why it won’t work, whilst the documentation suggest that the iris-v2 should work.

I looked at the device tree content and I can’t figure out why it behaves like this, iris-v2 inherits almost the
same files as the eval-v3 with some hardware differences.

With kind regards,

Jeffrey

Ah, ok. I read it as “the sdcard works with one board and not the other”. I had a similar situation with our own custom carrier board where the kernel was exactly the same, the device trees were slightly different, and the sdcard behavior was “the sdcard works with one board and not the other”. I ended up having to reduce the max clock speed on the custom carrier board to get the sdcard working correctly on the custom carrier board. I suspect our problem is a layout issue and will be fixed in subsequent revs of the board, but for now, the lower max speed fixes everything for me.

Hi @gclaudino.tx

Any progress or information about our issue?

With kind regards,

Jeffrey

Hi Jeffrey,

I happened to be looking in the dts directory, and did notice a few sd-specific changes between a couple of files that might be relevant to you. These changes are in the usdhc1 node of the device tree:
imx6ull-colibri-eval-v3.dtsi:
cd-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
vqmmc-supply = <&reg_sd1_vqmmc>;
disable-wp;
wakeup-source;
keep-power-in-suspend;
vmmc-supply = <&reg_3v3>;
status = “okay”;

and in imx6ull-colibri-iris-v2.dtsi:
cd-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
disable-wp;
enable-sdio-wakeup;
cap-power-off-card;
vmmc-supply = <&reg_3v3_vmmc>;
status = “okay”;

Maybe those combinations of wakeup-source, keep-power-in-suspend, enable-sdio-wakeup, cap-power-off-card are the difference in operation? Might be worthwhile to fiddle around with those combinations to see if things start working. I know, more shots in the dark…

– Dave

Hi @Jeffrey, how are you?

Sorry for the delay in reaching back to you. Can you please confirm the version of the Viola Board that you have on your side? We tested it with the a Colibri iMX6ULL 512MB WB IT V1.1A and a Viola Plus V1.2. You can see from the following logs that some files that were inside the sd card could be seen on the module after booting. The image we used was the Reference Minimal Image 5.7.0 with Downstream Kernel.

root@colibri-imx6ull-06388259:~# dmesg | grep Iris
[    0.000000] OF: fdt: Machine model: Toradex Colibri iMX6ULL 512MB on Colibri Iris V2
root@colibri-imx6ull-06388259:~# dmesg | grep -i mmc
[    2.066825] mmc0: SDHCI controller on 2190000.usdhc [2190000.usdhc] using ADMA
[    2.082239] sdhci-esdhc-imx 2194000.usdhc: allocated mmc-pwrseq
[    2.125400] mmc1: SDHCI controller on 2194000.usdhc [2194000.usdhc] using ADMA
[    2.262008] mmc1: new high speed SDIO card at address 0001
[   16.897807] btmrvl_sdio mmc1:0001:2: sdio device tree data not available
[   17.017571] mwifiex_sdio mmc1:0001:1: WLAN is not the winner! Skip FW dnld
[   17.527667] mwifiex_sdio mmc1:0001:1: WLAN FW is active
[   17.565623] mwifiex_sdio mmc1:0001:1: Unknown api_id: 3
[   17.571096] mwifiex_sdio mmc1:0001:1: Unknown api_id: 4
[   17.576426] mwifiex_sdio mmc1:0001:1: Unknown GET_HW_SPEC TLV type: 0x217
[   17.669397] mwifiex_sdio mmc1:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (16.68.1.p197)
[   17.677800] mwifiex_sdio mmc1:0001:1: driver_version = mwifiex 1.0 (16.68.1.p197)
[   33.130795] 3v3_vmmc: disabling
root@colibri-imx6ull-06388259:~# ls -la /media/mmcblk0p1/
drwxr-xr-x    2 root     root           160 Sep 16 20:26 .
drwxr-xr-x    3 root     root           232 Sep 16 20:26 ..
root@colibri-imx6ull-06388259:~# dmesg | grep -i mmc
[    2.066825] mmc0: SDHCI controller on 2190000.usdhc [2190000.usdhc] using ADMA
[    2.082239] sdhci-esdhc-imx 2194000.usdhc: allocated mmc-pwrseq
[    2.125400] mmc1: SDHCI controller on 2194000.usdhc [2194000.usdhc] using ADMA
[    2.262008] mmc1: new high speed SDIO card at address 0001
[   16.897807] btmrvl_sdio mmc1:0001:2: sdio device tree data not available
[   17.017571] mwifiex_sdio mmc1:0001:1: WLAN is not the winner! Skip FW dnld
[   17.527667] mwifiex_sdio mmc1:0001:1: WLAN FW is active
[   17.565623] mwifiex_sdio mmc1:0001:1: Unknown api_id: 3
[   17.571096] mwifiex_sdio mmc1:0001:1: Unknown api_id: 4
[   17.576426] mwifiex_sdio mmc1:0001:1: Unknown GET_HW_SPEC TLV type: 0x217
[   17.669397] mwifiex_sdio mmc1:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (16.68.1.p197)
[   17.677800] mwifiex_sdio mmc1:0001:1: driver_version = mwifiex 1.0 (16.68.1.p197)
[   33.130795] 3v3_vmmc: disabling
[   62.125833] mmc0: new high speed SDHC card at address 1234
[   62.147988] mmcblk0: mmc0:1234 SA08G 7.21 GiB
[   62.166458]  mmcblk0: p1
[   62.801999] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
root@colibri-imx6ull-06388259:~# ls -la /media/mmcblk0p1/
drwxrwx---    4 root     disk          4096 Jan  1  1970 .
drwxr-xr-x    3 root     root           232 Sep 16 20:26 ..
drwxrwx---    4 root     disk          4096 Aug  3  2021 .Trash-1000
-rwxrwx---    1 root     disk       1146008 Aug 13  2021 AA6_E0.gcode
drwxrwx---    2 root     disk          4096 Aug  3  2021 colibri_vf
-rwxrwx---    1 root     disk           710 Aug  9  2021 flash_blk.img
-rwxrwx---    1 root     disk           444 Aug  9  2021 flash_eth.img
-rwxrwx---    1 root     disk           307 Aug  9  2021 flash_mmc.img
root@colibri-imx6ull-06388259:~#

Thanks @henrique.tx for testing it :D. Was this what you’re looking for in the end?

When you tested it was it the Reference Minimal or the Reference Multimedia image?

Also, thanks @DaveM for the ideas! Your help is really appreciated. Jeffrey, please also test the suggestions from Dave if the Minimal Image without any modification is not able to reach your goal. Then, you can come back to us with the results.

Best regards,

Edit: Added the module version

1 Like

Hi @gclaudino.tx

Thank you for your response, we use the Iris V2.0 board. I don’t have a V1.2 so I’m unable to validate that behaviour.
This is the version of the Iris board where the pull-resistors where removed, at least that is what I understood from
the documentation (so it should support UHS 1 speeds, not that we require it).

@DaveM I missed those changes somehow, thank you for pointing them out. I will indeed fiddle around with these
settings hopefully this will give us some insight.

I will test it later this week due to other priorities.

Thank you for the idea’s.

With kind regards,

Jeffrey