Hi David & Wade, I would just like to chime in on this that I've been having exactly the same issue, repeatably, building for N310&320 series devices. I'm running a heavily customised image with plenty of (known good) custom logic, and the error comes up seemingly at random following a commit.
The only (semi-) repeatable way I've found of fixing this is renaming the image_core.yml file from which rfnoc_image_builder is running. Strange, I know, though it seems to work 50% of the time, at least for me. If you find any tricks other than those previously mentioned please let me know. I'm going to do some digging once I'm not under deadline-pressure, as this issue is getting on my nerves somewhat. Kind Regards, Sam ________________________________ From: Wade Fife <wade.f...@ettus.com> Sent: 06 March 2025 17:01 To: David <vitishlsfa...@gmail.com> Cc: USRP-users@lists.ettus.com <usrp-users@lists.ettus.com> Subject: [USRP-users] Re: rfnoc_image_builder error: trying to tool lock on already tool locked arc Hi David, I'm surprised that you're seeing it that frequently. The Ettus continuous integration tests build FPGAs regularly and from what I understand this issue is pretty rare there. This makes me wonder if there's something about the images you're building that causes this to reproduce more frequently for you. Can you estimate what percentage of unique builds (with a unique build seed or git hash) fail? Which FPGA image are you building? Does it have custom logic in it? You could use the repeat_fpga_build.py script to automate building the FPGA multiple times to get a successful build. It automates the process of selecting a unique seed for each build and can even run multiple build jobs at a time. Thanks, Wade On Mon, Mar 3, 2025 at 1:30 PM David <vitishlsfa...@gmail.com<mailto:vitishlsfa...@gmail.com>> wrote: Using UHD 4.6/Ubuntu 22.04/x310, I have built many images in the last year or so with rfnoc_image_builder. Recently in the last month, I get the following error on almost all images: [image.png] I have tried the following, after referencing this the known issues section in the USRP3 build instructions (https://files.ettus.com/manual/md_usrp3_build_instructions.html): 1. doing the suggested and making a non-functional source code change and recommitting the git 2. deleting the .git directory in both the block directory and the uhd/ directory where the fpga build happens 3. changing the build seed in uhd/fpga/usrp3/top/x300/Makefile 4. Running on a different machine, copying the block source code and using a different UHD git all together (private rehost vs the github UHD). The vivado 2021.1 install is the same as its on a network file system These do not produce repeatable good results. Maybe once a week or once every two weeks one of these things will finish the build. This has been happening for about a month or two, and I don't know how else to troubleshoot. Any advice? Thanks, David _______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> To unsubscribe send an email to usrp-users-le...@lists.ettus.com<mailto:usrp-users-le...@lists.ettus.com>
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
