This question has also been posted to the AMD Adaptive Support forums (https://adaptivesupport.amd.com/s/question/0D5KZ00000pAdsk0AC/zynq-7000-petalinux-20232-spidev-transfer-timed-out).
The team I am a member of is currently working on upgrading a project we inherited from the 2014 tools (Vivado, PetaLinux, etc) to the 2023.2 tools. This project uses PetaLinux running on an Avnet MicroZed AES-Z7MB-7Z020-SOM-G (XC7Z020-1CLG400C). We have encountered an issue with SPI 1 that we have not been able to resolve ("spidev spi1.X: SPI transfer timed out", "spi_master spi1: failed to transfer one message from queue", the state of the SPI 1 pins/signals has been checked and they are in their idle state with no activity observed).
The PetaLinux 2023.2 project was created using the scripts/make_mz7020_som_base.sh script from the Avnet petalinux GitHub repository's 2023.2 branch. The following changes have been made to the petalinux and meta-avnet repositories:
- Made various modifications so that the build can be performed without internet access.
- Made the following build configuration changes:
- Changed BOOT_METHOD to INITRD
- Set BOOT_SUFFIX to _MINIMAL
- Set INITRAMFS_IMAGE to petalinux-image-minimal
- Removed axi_intc_0 and amba_pl entries from meta-avnet/recipes-bsp/device-tree/files/mz/system-bsp.dtsi to fix rebuild errors that occur when the XSA file is swapped out for the one from our Vivado project.
SPI transfers are done using SPI_IOC_MESSAGE ioctl() calls.
SPI 1 is configured as follows in Vivado:
- SPI 1 is enabled and is configured to use MIO 10 .. 15
- MIO 10:
- Signal: mosi
- IO Type: LVCMOS 3.3V
- Speed: slow
- Pullup: disabled
- Direction: inout
- MIO 11:
- Signal: miso
- IO Type: LVCMOS 3.3V
- Speed: slow
- Pullup: enabled
- Direction: inout
- MIO 12:
- Signal: sclk
- IO Type: LVCMOS 3.3V
- Speed: slow
- Pullup: disabled
- Direction: inout
- MIO 13:
- Signal: ss[0]
- IO Type: LVCMOS 3.3V
- Speed: slow
- Pullup: enabled
- Direction: inout
- MIO 14:
- Signal: ss[1]
- IO Type: LVCMOS 3.3V
- Speed: slow
- Pullup: enabled
- Direction: out
- MIO 15:
- Signal: ss[2]
- IO Type: LVCMOS 3.3V
- Speed: slow
- Pullup: enabled
- Direction: out
- MIO 10:
dtsi SPI 1 configuration overrides:
&spi1 {
status = "okay";
num-cs = <3>;
is-decoded-cs = <0>;
speed-hz=<10000000>;
device@0{
status = "okay";
compatible="rohm,dh2228fv"; // Not actually this device, workaround to get /dev/spidev1.0 to appear.
reg=<0>; // Chipselect 0
spi-max-frequency=<10000000>; // 10 Mhz
};
device@1{
status = "okay";
compatible="rohm,dh2228fv"; // Not actually this device, workaround to get /dev/spidev1.0 to appear.
reg=<1>; // Chipselect 1
spi-max-frequency=<10000000>; // 10 Mhz
};
device@2{
status = "okay";
compatible="rohm,dh2228fv"; // Not actually this device, workaround to get /dev/spidev1.0 to appear.
reg=<2>; // Chipselect 2
spi-max-frequency=<10000000>; // 10 Mhz
};
};
SPI 1 device tree entry from decompiled DTB:
spi@e0007000 {
compatible = "xlnx,zynq-spi-r1p6";
reg = <0xe0007000 0x1000>;
status = "okay";
interrupt-parent = <0x04>;
interrupts = <0x00 0x31 0x04>;
clocks = <0x01 0x1a 0x01 0x23>;
clock-names = "ref_clk\0pclk";
#address-cells = <0x01>;
#size-cells = <0x00>;
num-cs = <0x03>;
is-decoded-cs = <0x00>;
speed-hz = <0x989680>;
phandle = <0x24>;
device@0 {
status = "okay";
compatible = "rohm,dh2228fv";
reg = <0x00>;
spi-max-frequency = <0x989680>;
};
device@1 {
status = "okay";
compatible = "rohm,dh2228fv";
reg = <0x01>;
spi-max-frequency = <0x989680>;
};
device@2 {
status = "okay";
compatible = "rohm,dh2228fv";
reg = <0x02>;
spi-max-frequency = <0x989680>;
};
};
We have tried the following to resolve this issue but they were not successful:
- Disabling power management in the kernel configuration as suggested by some adaptivesupport posts
- Increasing the timeout period as was done for https://adaptivesupport.amd.com/s/article/2021-Zynq-7000-Zynq-MPSoC-Versal-Yocto-PetaLinux-kernel-driver-fails-to-configure?language=en_US
- Changing the SPI 1 interrupts configuration (<0 49 4>) to the configuration that was used in the old device tree (<0 49 0>)
Any suggestions for resolving this issue would be greatly appreciated.