search

EttusResearch / uhd

The USRP™ Hardware Driver Repository
http://uhd.ettus.com
Other
976 stars 655 forks source link

uhd_image_loader not updated to match Vivado 2021.1 bitfile #655

Closed ri28856 closed 1 year ago

ri28856 commented 1 year ago

Issue Description

I built an FPGA image for UHD v4.3.0, and then tried to flash my USRP x310. I got the following output: /uhd_image_loader --args=type=x300,addr=192.168.40.56 --fpga-path=usrp_x310_fpga_XG.bit [INFO] [UHD] linux; GNU C++ version 11.2.1 20220127 (Red Hat 11.2.1-9); Boost107500; UHD Error: RuntimeError: The specified FPGA image is too large: 15878048 vs. 15878042

Note the bitfile is apparently six bytes too large. I found the following page which suggested a workaround involving chopping the extraneous bytes off the end of the bitfile: https://www.mail-archive.com/usrp-users@lists.ettus.com/msg09082.html

The workaround appears to have worked for me.

Setup Details

I'm using UHD v4.3.0.0 tag, a USRP x310, and a RHEL7 box. I built the FPGA image with AR76780 Patch for Vivado 2021.1

Expected Behavior

I would expect uhd_image_loader to successfully flash the USRP FPGA.

Actual Behaviour

Error: RuntimeError: The specified FPGA image is too large: 15878048 vs. 15878042

Steps to reproduce the problem

Build the UHD 4.3.0.0 x310 XG FPGA image using the standard makefile method. Flash a USRP using uhd_image_loader.

Additional Information

Edit: I originally claimed my OS was RHEL9. I was mistaken, I used a RHEL7 build server.

wordimont commented 1 year ago

@ri28856 Could you share the bitstream you built? I'd like to look at what Vivado did to grow the file. The one I built today is smaller than yours.

wordimont commented 1 year ago

Could you also share the output of vivado -version on the system you built it with?

ri28856 commented 1 year ago

@wordimont I sent you an email with the bitstream. Github doesn't seem to let me attach an arbitrary file type. I am working on getting the vivado version output, unfortunately my build system was re-imaged between when I did the build and now and Vivado isn't set up properly anymore...

ri28856 commented 1 year ago

Okay the Vivado version is as follows: vivado -version Vivado v2021.1_AR76780 (64-bit) SW Build 3247384 on Thu Jun 10 19:36:07 MDT 2021 IP Build 3246043 on Fri Jun 11 00:30:35 MDT 2021 Copyright 1986-2021 Xilinx, Inc. All Rights Reserved.

I also discovered I was mistaken when I claimed I did this on a RHEL9 box, it turns out I was using a RHEL7 system, hence the re-imaging.

wordimont commented 1 year ago

Interesting. The .bit file you shared shows version 2021.1_AR76780_AR76780. The extra _AR76780 is why the file is longer than expected. Thanks for reporting this.

I don't know why Vivado would report the version twice in the bitstream header. Is it possible you have the patch installed twice? For example, maybe you put two copies of the patch the Vivado/2021.1/patches folder, or you installed the patch in the Vivado folder and also set XILINX_PATH to point to the patch?

ri28856 commented 1 year ago

I think I did also set XILINX_PATH in addition to installing it into the patches folder. I'll try rebuilding again early next week. For now I'm going to assume this was user error on my part if you can't replicate it, and close the issue.