I see. Okay. I would like to investigate the precompiled packages back as far as the Ettus repository has them but being new to Linux I’m ignorant about how to use PPAs to actually get to the code I need and use it so I’ll need to do some intensive research to find a tutorial or instructions as to how to use them. So this will take me a little while to come up to speed on it.
Joe > On May 8, 2019, at 5:38 PM, Marcus D. Leech via USRP-users > <usrp-users@lists.ettus.com> wrote: > > On 05/08/2019 07:34 PM, Joe Martin via USRP-users wrote: >> Thanks Philip, I’ll check out the precompiled versions on the link Robin >> provided, to see if they go back far enough first. I tried the 3.9.0 so I’m >> thinking 3.8.x might still be too recent but if none of these work perhaps I >> can ask you to take a look for something earlier. Thanks! >> >> Joe > The basic issue is that there never were that many R2s about that I recall, > before the R3 and the ADC input change was made, so I don't think there > was much push to retain compatibility for modern versions. > > >> >>> On May 8, 2019, at 4:02 PM, Philip Balister <phi...@balister.org> wrote: >>> >>> I've got the 3.8.4 images zipfile lying around in my OE download >>> directory, if it helps I can put it on dropbox. I might be able to find >>> some older ones if needed. >>> >>> Yeah, I save ancient source in case of a GPL compliance exercise :) >>> >>> Philip >>> >>> On 05/08/2019 05:40 PM, Robin Coxe via USRP-users wrote: >>>> You could try using the .deb or .rpm pre-built binaries if you're running >>>> on Linux. See, for instance: >>>> http://files.ettus.com/binaries/uhd/uhd_003.004.000-release/ >>>> >>>> On Wed, May 8, 2019 at 2:09 PM Joe Martin via USRP-users < >>>> usrp-users@lists.ettus.com> wrote: >>>> >>>>> I’ve successfully built UHD v3.9.0 but it has the same error as 3.14.0 did >>>>> before (“Received invalid reply 32 from device”) and uhd_usrp_probe still >>>>> complains that it is expecting compatibility number 11 but is receiving 6. >>>>> So I think that means I need an earlier version of UHD than 3.9.0. >>>>> >>>>> I will dig into the earliest version in the git tag -l, namely >>>>> 003_007_002_rc1, that would not build without errors and try to work out >>>>> the compiler errors then. Unless someone has a better idea to try. >>>>> Thanks! >>>>> >>>>> Regards, >>>>> >>>>> Joe >>>>> >>>>> On May 8, 2019, at 2:40 PM, Joe Martin via USRP-users < >>>>> usrp-users@lists.ettus.com> wrote: >>>>> >>>>> Okay, thanks, that’s what I thought but that isn’t useful for me until I >>>>> find a UHD version that can communicate with it. I’ve been trying to >>>>> build >>>>> older UHD versions from 003_007_002_rc1 forward but all so far fail to >>>>> build due to compiler errors. Am up to 003_008_005_rc1 now, moving >>>>> forward >>>>> until I can successfully build one to try. Are there any old pre-built >>>>> versions I could simply try without having to build each one myself? >>>>> >>>>> Joe >>>>> >>>>> On May 8, 2019, at 2:31 PM, Nick Foster <bistrom...@gmail.com> wrote: >>>>> >>>>> Yes, code loaded over JTAG is gone at next boot. I can't think of an easy >>>>> way to figure out what image is loaded other than asking UHD to query it >>>>> for FPGA compat number. >>>>> >>>>> On Wed, May 8, 2019 at 1:04 PM Joe Martin <k...@k5so.com> wrote: >>>>> >>>>>> I guess the proper way to ask is “Is there a way to determine what fpga >>>>>> .bin file is in the N210?”, since the .bit file that I loaded into the >>>>>> fpga >>>>>> is volatile code that disappears upon power cycling to be reloaded from >>>>>> an >>>>>> EEPROM or something, yes? >>>>>> >>>>>> Joe >>>>>> >>>>>> On May 8, 2019, at 1:55 PM, Joe Martin via USRP-users < >>>>>> usrp-users@lists.ettus.com> wrote: >>>>>> >>>>>> Hi Nick, >>>>>> >>>>>> Thanks for the comments. Is there a way to determine what bit file is >>>>>> currently in the N210? If so, how please? >>>>>> >>>>>> Joe >>>>>> >>>>>> On May 8, 2019, at 1:33 PM, Nick Foster <bistrom...@gmail.com> wrote: >>>>>> >>>>>> I see you got there already! If you're still having trouble, I'll see >>>>>> what I can dig up over here. >>>>>> >>>>>> On Wed, May 8, 2019 at 12:31 PM Nick Foster <bistrom...@gmail.com> wrote: >>>>>> >>>>>>> You might be best off reverting to a UHD old enough to support the >>>>>>> bitfile currently loaded on your N210. You could then bootstrap your >>>>>>> N210 >>>>>>> by using the old UHD to load a newer FPGA image. >>>>>>> >>>>>>> Otherwise, it's fairly simple to convert the binfiles (which still exist >>>>>>> -- usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from >>>>>>> usrp_n210_r3_fpga.bit and just stick it onto the front of >>>>>>> usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The >>>>>>> header is everything up until FF FF FF FF AA 99 55 66. >>>>>>> >>>>>>> Lastly, the source is all there, so building using ISE should still be >>>>>>> possible. >>>>>>> >>>>>>> Nick >>>>>>> >>>>>>> On Wed, May 8, 2019 at 9:57 AM Joe Martin via USRP-users < >>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>> >>>>>>>> Wow, okay; that’s disheartening. Thanks much for the info, Jason. >>>>>>>> Nope, the Rev3 bit file doesn’t work; tried it. I’ll see if the >>>>>>>> support >>>>>>>> email adr can be of use. >>>>>>>> >>>>>>>> Joe >>>>>>>> >>>>>>>> On May 8, 2019, at 10:44 AM, Jason Matusiak < >>>>>>>> ja...@gardettoengineering.com> wrote: >>>>>>>> >>>>>>>> Joe, I think you might be SOL. If you take a look at this thread from >>>>>>>> me last year, I had no luck: >>>>>>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html >>>>>>>> >>>>>>>> >>>>>>>> Also, when I pinged Ettus directly, here is some info I got back from >>>>>>>> them (from two different emails in the thread): >>>>>>>> "we've been having some trouble tracking down Rev2 bitfiles, because no >>>>>>>> one here was around when that was built. If you're trying to unbrick >>>>>>>> them, Rev3 bitfiles might be OK, but I'm not completely sure. >>>>>>>> >>>>>>>> supp...@ettus.com might know more by know. >>>>>>>> really sorry, but those Rev2s are just so old. And all the people from >>>>>>>> that era seem to be gone. Sorry, can't help you with those Rev2s." >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> *From:* USRP-users <usrp-users-boun...@lists.ettus.com> on behalf of >>>>>>>> Joe Martin via USRP-users <usrp-users@lists.ettus.com> >>>>>>>> *Sent:* Wednesday, May 8, 2019 11:55 AM >>>>>>>> *To:* Joe Martin via USRP-users >>>>>>>> *Subject:* [USRP-users] Bringing an elderly N210 to life by loading >>>>>>>> current firmware/fpga images >>>>>>>> >>>>>>>> I am trying to bring an elderly N210 r2.0 with unknown history to life >>>>>>>> by loading current UHD firmware and fpga images from a 1Gigabit >>>>>>>> ethernet >>>>>>>> connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 >>>>>>>> with >>>>>>>> UHD 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty. >>>>>>>> >>>>>>>> Following instructions in “USRP Hardware Driver and USRP Manual: USRP2 >>>>>>>> and N2x0 Series”: >>>>>>>> >>>>>>>> My initial action was to load the “usrp_n210_r4_fpga.bit" file into the >>>>>>>> N210 xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG >>>>>>>> programming >>>>>>>> cable from a Win7 PC running Xilinx ISE iMPACT, which reported “Program >>>>>>>> Succeeded” for the action. Ethernet LEDs on the N210 are variously >>>>>>>> lighted >>>>>>>> showing activity on the connection port. >>>>>>>> >>>>>>>> With the N210 connected to the Linux PC 1Gbps ethernet port, issuing >>>>>>>> the following commands result in the responses shown in the screenshot >>>>>>>> image below: >>>>>>>> >>>>>>>> <Screenshot from 2019-05-08 08-46-52.png> >>>>>>>> >>>>>>>> My (naive!) interpretation of the above responses is that the FPGA may >>>>>>>> not actually have been programmed with the *.bit code even though >>>>>>>> iMPACT >>>>>>>> reported success in programming. Can someone assist me in >>>>>>>> understanding >>>>>>>> whether my interpretation is correct or not and, most importantly, >>>>>>>> suggest >>>>>>>> what I might try next to bring this N210 to life? >>>>>>>> >>>>>>>> The “Please run:” suggestion results in the “Received invalid reply 32 >>>>>>>> from device” error. It seems no matter what I try the “Received >>>>>>>> invalid >>>>>>>> reply 32 from device” RuntimeError is reported back when I try to load >>>>>>>> any >>>>>>>> new firmware/FPGA images. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> Joe >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > > > _______________________________________________ > 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
