loading bitstream to pluto fails

[uptools]

Current "Make gen-boot-load" fails. Probably there is a problem in the order of the commands. If I run them individually in pluto, after uploading the bitstream to /lib/firmware I get:

$ 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
sh: write error: No such device

$ iio_info -a local | egrep iio:device
Using auto-detected IIO context at URI "local:"
iio:device0: ad9361-phy
iio:device1: xadc
iio:device2: cf-ad9361-dds-core-lpc (buffer capable)

It can be seen that device iio:device3: cf-ad9361-lpc (buffer capable) is missing at this point, so the echo command fails.

Any clues how to reorder commands to fix it?

[mbound]

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

[uptools]

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)

[uptools]

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?

[ofontbach]

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

[uptools]

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

[ofontbach]

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.

[nicolasflorio1]

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".

[LunaWuna]

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.

[uptools]

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.