Personally I appreciate the recent public-facing FPGA development and release cadence, and it's understandable the repos can become out of sync (I seem to remember seeing a warning about more development on the master branches a few months ago). One problem though is that the current tutorials and rfnoc instructions are not exactly set up to handle out-of-sync master branches. Cloning uhd-fpga from the uhd submodule within pybombs sounds like a great solution.
As a matter of good practice, might I suggest updating tutorials and the rfnoc OOT fpga build process to point to the uhd-fpga submodule, rather than an adjacent uhd-rpga repo clone? This would probably help others avoid this sort of compatibility problems in the future. Just a thought, EJ On Fri, Aug 31, 2018, 5:56 PM Andrew Danowitz via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Brent, > > Sounds good. I think the gnuradio pybombs recipe pulls in volk as a > submodule. I think they manage it with the line "gitargs: --recursive" in > their recipe. > > On Fri, Aug 31, 2018 at 2:15 PM, Brent Stapleton via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> The underlying reason for the mismatches is that, because the >> uhd/fpga-src submodule points to a commit on fpga, we need THAT commit to >> be on the fpga master branch. So, by necessity, we'll always have some >> amount of time in which the two repositories are out of sync (that is, fpga >> is ahead of uhd). This window was longer than usual, and we apologize for >> that. In the future, if hiccups like this are an absolute deal-breaker for >> you, please consider using the submodule pointer, or one of the UHD release >> branches. >> >> Regarding PyBOMBS, as far as I can tell, there isn't a silver bullet in >> this situation. I like the idea of the uhd-fpga recipe tracking >> uhd/fpga-src, but I don't think git can clone submodules. The best thing >> that comes to mind is to have the uhd-fpga recipe populate the uhd/fpga-src >> submodule, which just saves the effort of manually updating the submodule. >> If you have a better suggestion, we'd love to hear it. >> >> Best Regards, >> Brent >> >> On Thu, Aug 30, 2018 at 5:28 PM Juan Francisco <jfrancisco1...@gmail.com> >> wrote: >> >>> It seems that this issue has tripped up several people. It might be >>> prudent to not push the FPGA changes to master until you have the >>> corresponding UHD updates ready to go. >>> >>> On Thu, Aug 30, 2018 at 12:49 PM Brent Stapleton < >>> brent.staple...@ettus.com> wrote: >>> >>>> Hi Juan, >>>> >>>> In general, FPGA images built from the submodule in the uhd repository >>>> will be compatible with UHD built from that commit. The HEADs of the two >>>> master branches (uhd and fpga) do not have that guarantee. For example, the >>>> HEAD of uhd master branch (as I write this email) is the git >>>> commit 3b42e6f0, and the submodule points to the commit c3987555 on fpga. >>>> Those both use NoC shell compat number 4. >>>> >>>> We'll get the noc shell compat 5 changes out ASAP though, so don't >>>> throw away that image. >>>> >>>> Regards, >>>> Brent >>>> >>>> On Wed, Aug 29, 2018 at 7:14 PM Juan Francisco via USRP-users < >>>> usrp-users@lists.ettus.com> wrote: >>>> >>>>> There appears to be a compatibility mismatch for the latest FPGA >>>>> master and UHD. I built a new image from fpga master today, but >>>>> uhd_usrp_probe from UHD (w/ -DENABLE_RFNOC=ON) gives me the error message >>>>> below: >>>>> >>>>> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: >>>>> 0xF1F0D00000000000) >>>>> [ERROR] [0/DmaFIFO_0] Major compat number mismatch for noc_shell: >>>>> Expecting 4, got 5. >>>>> Error: RuntimeError: FPGA component `noc_shell' is revision 5 and UHD >>>>> supports revision 4. Please either upgrade UHD (recommended) or downgrade >>>>> the FPGA image. >>>>> >>>>> Thanks, >>>>> Juan >>>>> _______________________________________________ >>>>> USRP-users mailing list >>>>> USRP-users@lists.ettus.com >>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>> >>>> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> > > ------------------------------ > Information contained, linked, or attached to this email and all verbal > communications from WhiteFox Defense to your entity in the prior 30 days > constitute proprietary and confidential information unless otherwise > indicated and is therefore subject to obligations in any executed > confidentiality agreements. Further, this email is intended solely for the > use of the individual or entity to whom they are addressed. If you are not > the intended recipient and this message has been addressed to you in error, > please promptly notify i...@whitefoxdefense.com and destroy all copies of > the message and any attachments. This email and attachments may contain > technical data as defined in the International Traffic In Arms Regulations > (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR > Parts 730 – 780. Export of this material may be controlled by these > regulations and may not be exported or transferred to non-U.S. persons > without prior written approval from the U.S. government. > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
