loading bitstream to pluto fails about zynq_timestamping HOT 9 OPEN

It works for me with this order of commands:

# cd /lib/firmware/
# echo system_top.bit.bin > /sys/class/fpga_manager/fpga0/firmware
# echo 79024000.cf-ad9361-dds-core-lpc > /sys/bus/platform/drivers/cf_axi_dds/unbind
# echo 79020000.cf-ad9361-lpc > /sys/bus/platform/drivers/cf_axi_adc/unbind
# echo 7c400000.dma > /sys/bus/platform/drivers/dma-axi-dmac/unbind
# echo 7c420000.dma > /sys/bus/platform/drivers/dma-axi-dmac/unbind
# echo 7c420000.dma > /sys/bus/platform/drivers/dma-axi-dmac/bind
# echo 7c400000.dma > /sys/bus/platform/drivers/dma-axi-dmac/bind
# echo 79024000.cf-ad9361-dds-core-lpc > /sys/bus/platform/drivers/cf_axi_dds/bind
# echo 79020000.cf-ad9361-lpc > /sys/bus/platform/drivers/cf_axi_adc/bind
# echo 79020000.cf-ad9361-lpc > /sys/bus/platform/drivers

from zynq_timestamping.

It still returns the same error on the last echo:
echo 79020000.cf-ad9361-lpc > /sys/bus/platform/drivers/cf_axi_adc/bind
sh: write error: No such device

May be there is something wrong with the generated bitstream system_top.bit.bin,
because if I run the same sequence of commands, but omitting the bitstream replacement:
echo system_top.bit.bin > /sys/class/fpga_manager/fpga0/firmware

then I get no errors in any of the following echo's (but the fpga remains with the default config instead of the new one)

from zynq_timestamping.

Is there any way to check from Vivado that the system_top.bit is well generated?
(its schematic and connections, to see it is including and connecting all expected devices)

Or may be someone else who has a correct and tested system_top.bit.bin version can share it?

from zynq_timestamping.

hi @uptools,

you can find prebuilt (and validated) images for all supported boards in the attached release. In fact, these builds are equivalent to those done from a fresh clone of the repo.

Let us know if this makes any difference, although from the messages it seems that the problem has occurred during bitstream replacement

from zynq_timestamping.

Hi @ofontbach, the prebuilt image throws the same error as the first image.

I tested both images (the one I built here and also the prebuilt-validated images)
on 2 pluto': a pluto-adalm v0.34 and a pluto+ v0.32.

And I get the same error on both pluto's when I execute the last echo:

  echo 79020000.cf-ad9361-lpc > /sys/bus/platform/drivers/cf_axi_adc/bind
  sh: write error: No such device

from zynq_timestamping.

Hi @uptools,

We just verified both the prebuilt image and a fresh build in a pluto-adalm v0.34 (starting from its default bitstream) and it worked fine for us (both when using the make script - e.g., gen-boot + load-reset - and when manually inserting the commands in the pluto after copying the top.bin file).

We have also corrected the path in the tx-rx script for the pluto.

from zynq_timestamping.

You have to make sure that you are using the ADC default configuration which is the AD9363. You can check it using the following commands: "fw_printenv attr_name" and "fw_printenv attr_val".

from zynq_timestamping.

If you are running a Pluto plus The bitstream won't load unless you run the standard Pluto firmware. However if it's loaded it won't transmit anything from other software and it causes ringbuffer errors on srsenb. I have no idea if it's expected to break tx compatibility with other software with the bitstream loaded though.

from zynq_timestamping.

You have to make sure that you are using the ADC default configuration which is the AD9363. You can check it using the following commands: "fw_printenv attr_name" and "fw_printenv attr_val".

When running pluto-adalm as ad9363 the problem goes away and the bitstream loads ok.

from zynq_timestamping.