cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Teacher
Teacher
383 Views
Registered: ‎01-28-2008

Ethernet found QSPI vs. JTAG

Hi folks,

  I've been researching my way through Petalinux and found a difference in behavior when the same image is loaded from QSPI and loaded over JTAG, on a custom RFSoC card with xczu39dr.

  In both cases, u-boot finds the GEM1 and has no problem acquiring IP, etc.

  In the working QSPI case, the PHY (TI DP83867) is controlled over MDIO without issue, and Linux is able to if-up and works fine.

  Loading the _same_ image over JTAG however, throws the following message, which seems to indicate some issue finding the PHY or communicating over MDIO to it. The JTAG command is:

[pcarr@storm Petalinux_new]$ petalinux-boot --jtag --hw_server-url TCP:192.168.1.177:3121 --u-boot --fpga 
INFO: sourcing build tools
INFO: Use bitstream: "/home/pcarr/Work/DAQ/Petalinux_new/images/linux/system.bit.
INFO: Please use --fpga --bitstream <BITSTREAM> to specify a bitstream if you want to use other bitstream.
INFO: Launching XSDB for file download and boot.
INFO: This may take a few minutes, depending on the size of your image.
rlwrap: warning: your $TERM is 'xterm-256color' but rlwrap couldn't find it in the terminfo database. Expect some problems.: Inappropriate ioctl for device
INFO: Configuring the FPGA...                                                   
INFO: Downloading bitstream: /home/pcarr/Work/DAQ/Petalinux_new/images/linux/system.bit to the target.
INFO: Downloading ELF file: /home/pcarr/Work/DAQ/Petalinux_new/images/linux/pmufw.elf to the target.
INFO: Downloading ELF file: /home/pcarr/Work/DAQ/Petalinux_new/images/linux/zynqmp_fsbl.elf to the target.
INFO: Downloading ELF file: /home/pcarr/Work/DAQ/Petalinux_new/images/linux/u-boot.elf to the target.
INFO: Downloading ELF file: /home/pcarr/Work/DAQ/Petalinux_new/images/linux/bl31.elf to the target.

  The attached screenshot shows side-by-side the difference between logs: on the left, the working QSPI boot log, and on the right, the JTAG load change.

  I've spent the last 3 days debugging this, thinking it was some issue with the device tree or kernel configuration, but since the same image works when loaded over QSPI, I'm out of ideas.

  Why would loading over JTAG cause this?

 

I appreciate any pointers.

Thanks in advance,

-Pat

 

Give kudos if helpful. Accept as solution if it solves your problem.
https://tuxengineering.com/blog

Screenshot from 2020-04-10 17-53-16.png
0 Kudos
Reply
2 Replies
Voyager
Voyager
365 Views
Registered: ‎06-28-2018

Hi @patocarr 

I've had a similar issue in the past. When booting over JTAG, I've observed that my state machine was entering an illegal state. Then I realized that during boot, at some point after the bitstream is downloaded and the system is up, pl_resetn is driven low and the system is reset. I don't know at which stage or why but it happens. Maybe it messes things up in your system.

0 Kudos
Reply
Teacher
Teacher
348 Views
Registered: ‎01-28-2008

Hi @baltintop 

  I appreciate your reply. That's an interesting theory worth exploring further. While the PL is being loaded and perhaps being reset as you mentioned, it shouldn't be affecting the GEM as it's wholly controlled by the PS. However, perhaps the reset may be changing the PHY strapping resistors and confusing the PHY.

  It's still a mystery why this reset would be happening during JTAG boot and not during QSPI.

Thanks,

-Pat

 

Give kudos if helpful. Accept as solution if it solves your problem.
https://tuxengineering.com/blog

0 Kudos
Reply