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
>> 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:
> 0xF1F0D000)
> [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 Re
