02-04-2019 05:54 PM
I'm upgrading from ISE/Petalinux to Vivado/Petalinux 2018.3. Running on a custom board using a Zynq 7020. The application I'm working on uses mmap to access the Zynq peripherals (PS SPI, I2C, etc...) and does not use any of the drivers. When I try and run the application all reads from device registers after mmap are returning 0. I run the command line devmem utility and I read all 0's. E.g. For the PS SPI which is at address 0xE0006000 after a reset I read 0, when I run the (working) ISE image I read the expected reset value of 0x20000.
Back to my Vivado image, if I stop the boot and get to a u-boot prompt and do a "md 0xE0006000" (memory display) I indeed see the expected 0x20000, but if I then boot Linux and do devmem I read 0.
So it looks like there is some issue doing the memory mapping? Has anyone else seen this? My ISE/Petalinux kernel is 3.8.11 (devmem works fine), my Vivado/Petalinux kernel is 4.14.0 (devmem always reads 0)
02-06-2019 03:55 AM - edited 02-06-2019 04:39 AM
No ideas on why the md command in u-boot would read device registers correctly but mmap/devmem would return 0s?
02-06-2019 08:41 AM
02-06-2019 12:54 PM
Thank you for the reply. Note I'm also seeing this with other devices, such as I2C..so I don't think this is a problem specifically with the SPI, but I've done a comparision between the older dts and the 2018.3 dts and I've shown the SPI node below. The newer dts is on the right
I'm not too familiar with the dts files so I'm not sure if any of these settings would cause the issues I'm seeing. I also included the aliases section from the dts, the older dts has spi0 as an alias for the ps7 spi but the newer dts has spi0 as an alias for the axi spi, though I don't see how that would contribute to the issue?
02-07-2019 05:22 AM
to follow up, I changed the aliases to match what had was used in the working version and that had no effect.
I know that e.g., devmem works because I can query some system addresses, but when I try to query Ic2, SPI, etc...they return 0. Does that point to the devices not being enabled?
02-07-2019 07:38 AM
02-13-2019 02:41 AM
To start with, Can you try to keep the 2018.3 design as minimal as possible, and give a try with this generated HDF, as I couldnt find any obvvious reasons for failing to accessing registers using devmem with ISE to vivado migration?
02-13-2019 02:50 AM
Can you check to see if the deivces that are not responding to the devmem are getting probed by the kernel?
dmesg | grep <ip name>
02-13-2019 04:28 AM
I also use /dev/mem and mmap() to access AXI addresses directly without the "help" of device drivers and trees.
In a case like this it is nice to see what physical address is actually going out on the AXI bus. Normally, when I am building the FPGA logic design for something like this I attach a System ILA on the AXI master bus. It is very easy to add in the IP Integrator and easy to use in the Hardware Manager.
I think you are on the right path. Good luck.
02-13-2019 08:07 AM
The top image below is the result of dmesg for spi for my latest (2018.3). The bottom image is the result of dmesg spi for my working image (ISE / Petalinux 2014). I'm having issues with the PS spi at e0006000
02-13-2019 09:30 AM - edited 02-13-2019 05:48 PM
I don't see the spi device in /dev, instead in both versions I see it in /sys/devices. The top image shown is from my working ISE/PetaLinux version, the bottom image is from my non-working Vivado/PetaLinux.
It seems to be a problem with the PS SPI and I2C peripherals. I seem to be able to access the registers of the AXI SPI..something specific to the PS.