Programming / Flashing a Blank Pluto Board

Please take a look at the content of the pluto-jtag-bootstrap files released with each release.

https://github.com/analogdevicesinc/plutosdr-fw/releases/download/v0.29/plutosdr-jtag-bootstrap-v0.29.zip

It's important to initialize the PS in particular the clocks and the DDR memory. Otherwise you can't load uboot.

This step is done my sourcing he ps7_init.tcl script and then running ps7_init and ps7_post_config.

run.tcl: 

connect arm hw
stop
xreset 64

source ps7_init.tcl
ps7_init
ps7_post_config

dow u-boot.elf
run

disconnect 64

-Michael

Hello, I was able to figure out my issues. I can now use the run.tcl file to program the bitstream, source the ps7_init tcl and download uboot.elf

After the disconnect 64 command, the ready LED turns off and the LED1 LED turns on bright and solid. 

After doing this step, what is the next step in order to fully program the pluto board?

One one of my pluto boards this works. I can download boot.dfu, pluto.dfu and firmware.dfu. 

We have a second pluto board in which i am not able to follow the same steps. 

Pluto 1 - I can follow all these steps.

Pluto 2 has the following output.

Using this pluto, I also cannot see the pluto dfu on the device manager as well

"U-Boot PlutoSDR v0.20-PlutoSDR-00051-gf5f001e (Oct 15 2018 - 20:38:02 +0200)

I2C: ready
DRAM: ECC disabled 512 MiB
SF: Detected N25Q256A with page size 256 Bytes, erase size 4 KiB, total 32 MiB
*** Warning - bad CRC, using default environment

In: serial@e0001000
Out: serial@e0001000
Err: serial@e0001000
Model: Zynq Pluto SDR Board
Hit any key to stop autoboot: 0
## Resetting to default environment
SF: Detected N25Q256A with page size 256 Bytes, erase size 4 KiB, total 32 MiB
SF: Unlocked
gpio: pin 15 (gpio 15) value is 1
Entering DFU SF mode ..."

Any ideas why this could be? 

Update, I was able to fix this issue by interrupting (ctrl c) and lowering to the Pluto> terminal. I then used the cmd saveenv,  to save environment variables. 

From here I no longer get the "bad CRC" error on booting u-boot. 

I still cannot see the USB Pluto DFU device...

I also tried using your recommendation from the below post, but still, my pluto doesn't show up as a USB device...This is very odd...

ez.analog.com/.../pluto-firmware-repair

mhennerich said:

ok - use setenv instead. Maybe your old uboot doesn't know set.

Pluto> setenv dfu_sf_info 'set dfu_alt_info boot.dfu raw 0x0 0x100000\\;firmware.dfu raw 0x200000 0x1E00000\\;uboot-env.dfu raw 0x100000 0x20000'
Pluto> setenv dfu_sf_info 'setenv dfu_alt_info boot.dfu raw 0x0 0x100000\\;firmware.dfu raw 0x200000 0x1E00000\\;uboot-env.dfu raw 0x100000 0x20000'

-Michael

On your failing Pluto was USB working before?

Once in DFU mode can you connect it to a Linux PC and run the lsusb command?

-Michael

Not sure  on this Pluto if the USB worked before, as we have not tested it in this manner. 

I have checked the 24mhz clock feeding into the USB IC and there is a clock there.

I also believe that the USB IC is being powered correctly because both the working and the non-working pluto display the same output for the following scenario.

Interrupt the DFU SF mode and return the pluto> prompt of u-boot, I try running the usb start command and I receive the following output.

Pluto> usb start
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
USB1: usb1 wrong num MIO: 0, Index 1
lowlevel init failed
scanning usb for storage devices... 0 Storage Device(s) found

When running lsusb on a linux machine with the broken pluto connected, there is no sign of any kind of enumeration. When I try the same test with the working pluto, I can see that there is a new analog devices "gadget" connected. Same results with windows.

From this standpoint, there seems to  be no issues with the hardware, as both devices are able to start USB0.

What exactly is happening when running "run dfu_sf" ? It seems like the working pluto board can enumerate when using the "run dfu_sf" command, and disconnect when out of this mode. It can then re-enumerate when running "run dfu_sf" again. 

Does this have to do with switching roles? ie. USB OTG Mode?

Yes likely that’s an issue 

Thank you for your input, I will have to put that pluto aside for now. We are going to have the board parts looked at by our assembly team. 

Thank you mhennerich! We have been successful in flashing the pluto from a "blank" state! This is very helpful and I have learned a lot from this. 

Here were the steps for clarity. Please correct me If I am incorrect at any point as I am hoping this post will help others. 

For these steps to execute correctly, you need to have both a Xilinx Platform Cable II and a UART to USB converter.

1. Ground JTAG_BOOT pin, power on board. After board has been powered on, remove the ground from JTAG_BOOT.

 - This will boot the Zynq into JTAG Mode as opposed to QSPI mode and will allow for writing to the flash.

2. Open Vivado SDK 2017.4 and execute the run.tcl file in the XCST terminal. *Notice the command XMD being used is depreciated in later versions of Vivado. Once this step is completed, you should see uart output of u-boot. There should also be a new USB device recognized on the computer(Gadget Device).

The following steps need to be executed from the run.tcl file. 

 - Program the bitstream into the Zynq

 - Source the ps7_init.tcl

 - Apply ps7_init and ps7_post_config

 - Download u-boot.elf 

3. 

mhennerich said:

Once you have bootstrapped uboot via JTAG. You should see it's command line interface on the uart console.

The next step would be to DFU (boot.dfu) your initial uboot.

$ sudo dfu-util -D boot.dfu -a boot.dfu

But be aware in case you are still in JTAG boot mode, SPI access to NOR flash will fail until you remove the bootmode jumper.

Once you have your initial u-boot in flash, please continue using DFU to load kernel and userspace 

$ sudo dfu-util -D pluto.dfu -a firmware.dfu

One minor comment -

You don't need to write the bitstream.

-Michael

One minor comment -

You don't need to write the bitstream.

-Michael