We’re working with the Colibri iMX7d SOM for a production project and we want to enable multiple SPI
controllers. It was simple enough to enable ecspi3 by disabling CAN (I get /dev/spidev2.0), but I’m just learning device trees and I’m having a lot of trouble defining additional SPI controllers. Specifically, I’m trying to enable ecspi1 with MOSI on X1-103 and SCLK on X1-101. In this application MISO and CS are not used. Edits to the device tree are shown below.
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -108,6 +108,13 @@
pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_ecspi3_cs>;
};
+&ecspi1 {
+ fsl,spi-num-chipselects = <1>;
+ cs-gpios = <&gpio4 19 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1 &pinctrl_ecspi1_cs>;
+};
+
&fec1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet1>;
@@ -439,6 +446,20 @@
>;
};
+ pinctrl_ecspi1_cs: ecspi1_cs_grp {
+ fsl,pins = <
+ MX7D_PAD_ECSPI1_SS0__GPIO4_IO19 0x2
+ >;
+ };
+
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <
+ MX7D_PAD_ECSPI1_MISO__ECSPI1_MISO 0x2
+ MX7D_PAD_ECSPI1_MOSI__ECSPI1_MOSI 0x2
+ MX7D_PAD_ECSPI1_SCLK__ECSPI1_SCLK 0x2
+ >;
+ };
+
--- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
@@ -52,17 +52,29 @@
interrupt-parent = <&gpio3>;
interrupts = <27 0x2>;
spi-max-frequency = <10000000>;
- status = "okay";
+ status = "disabled";
};
spidev0: spidev@1 {
compatible = "toradex,evalspi";
reg = <0>;
spi-max-frequency = <23000000>;
- status = "disabled";
+ status = "okay";
};
};
+&ecspi1 {
+ status = "okay";
+
+ spidev1: spidev@2 {
+ compatible = "toradex,evalspi";
+ reg = <1>;
+ spi-max-frequency = <23000000>;
+ status = "okay";
+ };
+};
+
+
2nd SPI controller: ecspi1
Signals required:
- MOSI on X1 pin 103
- SCLK on X1 pin 101
This is the info from the pinout designer tool:
The signals are in bank 4, bits 16 and 17.
I/O bank position:
- SPI1 MOSI: gpio4.IO[9] ecspi3.MOSI
92
- SPI1 CLK: gpio4.IO[10] ecspi3.SCLK
88
- GPIO_SODIMM_97 97
SPI_2_MASTER_CS0 gpio4.IO[19]
- GPIO_SODIMM_129 129
SPI_2_MASTER_CS0 gpio4.IO[7]
Really appreciate any help…
Dave
When you re-purpose pins you need to remove them from the current pinctrl configuration, in this case the pins are in the pinctrl_hog_2. If you don’t need any of those GPIOs you can also remove the complete block by removing &pinctrl_hog_2 from the pinctrl-0 property in the iomxuc node (of imx7-colibri.dtsi).
Otherwise the changes overall look good to me. Some small details: Since this is a base board specific change I would add all changes to the carrier board specific device tree (e.g. arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi, and you might consider use your own device tree by coping ...-eval-v3 to ...-yourboard). The reg = <1>; property relates to the chip select used in that SPI instance and usually starts with 0.
The Device Tree Customization article on our developer website has some more introduction material about device trees.
Stefan, thanks for the response. I agree, creating a company version of the board-level device tree is the next step…I just want to get it running.
Removing the reference to pinctrl_hog_2 from the dtsi file makes sense but I removed the setting from the pinctrl-0 property and it didn’t work. I still only get the one SPI controller (/dev/spidev2.0). There is another reference to pinctrl_hog_2 in imx7d-sdb.dts but the pin reference is different.
thanks,
Dave
Hm, I don’t see why it would still fail when the pins are no longer referenced. Can you provide the kernel boot log file? Either by copy & paste or dmesg > logfile.txt and uploading that file…
It does not look like you are using the modified device tree, the boot log is also mentioning mcp251x still…
Do you build, copy and flash the new device tree?
I’ve been trying to add things one at a time and building the whole image -
- bitbake angstrom-lxde-image
Step 1:
I change the CAN status to “disabled” and ecspi3 to “okay” -
Step 2:
Once I just add ecspi1 to imx7-colibri-eval-v3.dtsi, even /dev/spidev2.0 doesn’t show -
&ecspi1 {
status = "okay";
spidev1: spidev@2 {
compatible = "toradex,evalspi";
reg = <0>;
spi-max-frequency = <23000000>;
status = "okay";
};
};
Each time I’m recompiling the whole image. The boot log I posted is from when it reverts back as if even ecspi3 is set to disabled. Up against some deadlines so any help would be appreciated.
thanks…
Where do you edit that? You need to create patch files in OE to have it applied. Otherwise your sources might be overwritten.
It is really hard to do development iterations with OE. I would recommend to first make the changes outside of OE, as described in the Build U-Boot and Linux Kernel from Source Code article.
Basically, setup the toolchain as described, then clone the right Linux branch, checkout the right release (I assume 2.7b2 since you mention that Linux release above), edit the dtsi files, and build the device tree:
$ git clone -b toradex_4.1-2.0.x-imx git://git.toradex.com/linux-toradex.git
$ cd linux-toradex
$ git checkout Colibri-iMX7_LXDE-Image_2.7b2-20170410
$ make colibri_imx7_defconfig
$ vi arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
....
$ make dtbs
$ cp arch/arm/boot/dts/imx7d-colibri-eval-v3.dtb /to/your/sd/colibri-imx7/
Flash the new device tree to the target
Colibri iMX7 # run setupdate
Colibri iMX7 # run prepare_ubi
Colibri iMX7 # run update_fdt
Once that works, you can reintegrate the changes into OE
$ git diff > colibri-imx7-dt-changes.patch
And then add that patch file to the linux-toradex bitbake file, similar as we have done in the meta-toradex-lpd demo layer.
Certainly wasn’t trying to turn this into too much iterative development - all I wanted to do was to enable one more SPI port in addition to ecspi3…I thought
this would’ve been relatively simple…
Thanks for the organized steps you’ve described for device tree updates. I’ve been doing some combination of those over time. The Toradex tutorials I’ve watched and OE docs I’ve read are good resources, but they often list different steps on how to do things. I’m relatively new to OE and device trees, but it can’t be this convoluted. I get that there are differences between working with Bitbake and directly with the kernel, but I was struggling with it.
The problem is solved and now 2 SPI devices appear in the dev directory and they both work. I used ecspi1 and ecspi3 and map to those pins above. Thanks again for your help.
Dave
Ok, yeah if not that many iterations are necessary, OE is fine. For a little change, I also would go down that road. The issue is just it does not work… Unfortunately, since OE is more complex, it is also harder to debug remotely what could have gone wrong… That is why I recommend using the manual mode…
Glad you could resolve the problem, thanks for the update!
