Enrico

Members
  • Content Count

    5
  • Joined

  • Last visited

  1. Hi sbobrowicz, thank you very much for your answer! The TFT LCD screen is now working. The problem was the SS_IN left floating as you suggested. Can you better explain me the reason why this pin creates the issue? Is it only a Vivado bug? Thank you again. Enrico
  2. Hi Mitchell, thank you for your answer. From this Xilinx web-page (https://www.xilinx.com/support/answers/70277.html) I saw that the Petalinux v2017.4 kernel is in the linux-xlnx git repository. Thus, I downloaded the tree and I moved to branch xilinx-v2017.4 before compiling the kernel (version 4.9.0). Anyway, the issue seems to remain also with this kernel version. Trying to go deep into the spi-cadence kernel module, I found out that the system does not go inside the cdns_spi_irq (the interrupt service routine of the SPI controller). Thus, I guess the SPI transfer does not know when the transmission is completed and goes to timeout state. Moreover, I put some printk in the code and suddenly the SPI tranfer worked for a moment. After reboot, the system acts as usual. Do you have any other idea on this issue? Thanks a lot for you support. Regards, Enrico
  3. Dear All, Me and a colleague of mine are facing an SPI timeout issue on a Zynq. We already posted the issue in the Xilinx forum: https://forums.xilinx.com/t5/Embedded-Linux/SPI-transfer-timeout/td-p/833550 but we did not receive any answer, yet. So I would like to ask your help. I am trying to use a TFT LCD screen with the Digilent Artyz7, exploiting the frame buffer. I created a project on Vivado that exports the Zynq PS SPI interface through EMIO. I have already deployed the linux-digilent kernel (v4.4.0) on the Zynq and I am able to see the SPI peripheral under /sys/class/spi_master/spi2.0 (the device tree has been generated using SDK). Thus, as soon as I try to insert the kernel module for the frame buffer support, I get the following error: spi2.0: SPI transfer timed out I attach the images from the logic analyzer: The kernel module of the frame buffer sends the data correctly through the SPI interface before going to timeout state. Any ideas or suggestions regarding this issue? Thanks a lot. Best Regards, Enrico
  4. Thanks for the reply. I solved the problem activating only one UART in the hardware design. Now I can boot petalinux without any problems. Thanks again!! Enrico
  5. Hi @sbobrowicz, I am playing with petalinux and the Zybo Board. I downloaded the last linux_bd project from the Digilent Git repo and I upgraded it to Vivado 2016.4. Then I went through all the steps of UG1144 to run a petalinux system on my Zybo. If I do not modify any settings in the top system configuration menu (that appears after typing petalinux-config) I get the system stalled after "bootconsole [earlycon0] disabled" is printed. So, after reading what you wrote: "Your linux kernel is actually still running, just a terminal is not getting created on ttyPS1 (the USB-UART). This is due to a bug in petalinux where PS0 is always indicated as the serial device in the bootargs if it is enabled in the hardware design. This only pops up if you use the new .hdf because linux_bd has recently been updated to enable UART0 over EMIO and connects it to a Pmod connector. The .hdf included with the petalinux bsp has not been updated yet to incorporate this." ...I unchecked the "generate boot args automatically" option inside the top system configuration menu and I added "console=ttyPS1,115200 earlyprintk" as a "user set kernel bootargs". Now the boot procedure stalls after printing: Public key portion is: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC1786RibT8XBySCvTwuulHe7L/aDRhPsOQbQi7kDjI4A4sqiFR21mSEOQeb9LdrI2MCcFgg8ulo0wQswsWIqQtD7wn8VLSNBCJMYb35fe1AE3CviKR4W8QYGJv6ATI4EuY+o9vMvl9hxkNQVwLIEO7yJfQg97Cd7Dl0h7vU+wtPlgnP++YmhOpdOzSXgWIqYO7F4/ARxkOh5OtFYzfiunEme1b5qB07ejXsOCBPmW5oxuHbM4EZOUve0b7F0HmacsNCqQg04queR3PZtzR/Sq26JjS0op3wijdileQLI6cliXd0riFEOBu8WP4IYjHtYC0m4x+NnKQjPaQ2dcvZsGr root@plnx_arm Fingerprint: md5 85:75:45:a8:93:ee:43:b4:6c:34:68:44:65:72:6a:c2 dropbear. Starting syslogd/klogd: done Starting tcf-agent: OK Could you please help me solve this problem? Thank you Enrico