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:
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.
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?
Welcome to our community ! 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?
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.
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.
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.
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.
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?
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.
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.
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 = <®_sd1_vqmmc>;
disable-wp;
wakeup-source;
keep-power-in-suspend;
vmmc-supply = <®_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 = <®_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…
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.
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.
@DaveM Thanks for the above suggestion , it seems that this works perfectly.
It raises only the question why it does not work with the original version (or does not work anymore), can anyone clarify
this? I can only guess that it has something to do with the enable-sdio-wakup, cap-power-off-card or wakeup-source
options. My knowledge about the device tree section is very limited (last embedded kernel development on my part was v2.6).
! Please feel free to roam around.