Hi @Evets ,
it would seem you were using the ECSPI1 pin group, not the ECSPI2 pin group which isn’t in that file. I think the correct thing based on the btuartgrp (uses the same pins I have listed) uses 0x1c4 for all four pins. Let me know if I am incorrect in this case.
If I recall correctly the IOMUXC values vary according to the pin function, so pins allocated as ECSPI should have similar values. In any case, you can try using the values from btuartgrp and see if it works.
BTW, I am using a wifi SOM, so those pins ARE restricted for me. So, I will have to try the I2C4_SCL, SD2_CMD, I2C4_SDA and SD2_CLK pins.
The I2C4 pins are used by the HDMI connection, so using I2C4_SCL and I2C4_SDA will remove HDMI functionality.
So using SD2_CMD, SD2_CLK, SD2_DATA2 and SD2_DATA3 instead, I created a new overlay:
verdin-imx8mp_new_spi2_overlay.dts
// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
// Verdin imx8mp spidev
/dts-v1/;
/plugin/; // Indicates that the file is a Device Tree Overlay
#include <imx8mp-pinfunc.h>
/ {
compatible = "toradex,verdin-imx8mp";
};
// Free pins SD2_CMD, SD2_CLK, SD2_DATA2 and SD2_DATA3
&usdhc2 {
status = "disabled";
};
&iomuxc {
pin_cntl_spi2: spi2_grp {
fsl,pins =
<MX8MP_IOMUXC_SD2_DATA3__ECSPI2_MISO 0x1c4>,
<MX8MP_IOMUXC_SD2_CMD__ECSPI2_MOSI 0x4>,
<MX8MP_IOMUXC_SD2_CLK__ECSPI2_SCLK 0x4>,
<MX8MP_IOMUXC_SD2_DATA2__ECSPI2_SS0 0x1c4>;
};
};
/* Verdin SPI_2 */
&ecspi2 {
#address-cells = <1>;
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&pin_cntl_spi2>;
status = "okay";
spidev@2 {
/* Use compatible "rohm,dh2228fv" to bind spidev driver */
compatible = "rohm,dh2228fv";
reg = <2>;
spi-max-frequency = <10000000>;
};
};
With the overlays below applied on a Verdin Plus 1.1A with Wi-Fi:
$ cat overlays.txt
fdt_overlays=verdin-imx8mp_hdmi_overlay.dtbo verdin-imx8mp_dsi-to-hdmi_overlay.dtbo verdin-imx8mp_spidev_overlay.dtbo verdin-imx8mp_new_spi2_overlay.dtbo
I was able to see two spidev devices in /dev/. Just be aware that the SD reader will not work anymore, as we used the pins originally reserved for it.
Well, I wasn’t doing the unpack as I read something that said I only needed to do that in certain cases. Anyway, I did that and now it won’t boot up. How do I get into UBoot? I see nothing on the screen. Where do I communicate with the SOM? I think I may have broken the board since I disabled all the Uarts due to worry of conflicts.
Are you connecting to the SoM via serial? You should at least be able to see U-Boot initializing TorizonCore with the serial connection, even if you disabled all UARTs in the overlay (U-Boot has its own device tree which we’re not changing).
If you see the U-Boot initialization sequence press any key to stop the autoboot process then type this to disable all overlays in the next boot:
setenv skip_fdt_overlays 1
Then, boot TorizonCore:
boot
You can also try loading Toradex Easy Installer on the module and then once it’s loaded plug in a USB stick with the custom TC image you created with TorizonCore Builder.
Best regards,
Lucas Akira
