Emil, it's all in the repos (MPM/UHD/FPGA, but also partly in our OE stack as we have some custom kernel drivers). Like Marcus said, this isn't something we can provide a lot of assistance with, but you can find all the code in our repos. If you have access to an X410 (or an E300 or N300 series USRP), you can get a better insight into how the UHD/MPM/FPGA/Linux stacks interact.
--M On Tue, Sep 7, 2021 at 10:25 PM <tywon...@fel.cvut.cz> wrote: > Dear USRP maintainers, > > As my master's thesis I've set out to port the GNU Radio RFNoC to the > RFSoC 2x2 development board for purposes of academic research of > optical communications, and I have some issues. If it's more practical > for you, feel free to forward me to written resources I may have missed. > First some context: The motivation for this is rapid development and > measurement on a digitizer-like platform without RF frontends. Since > USRP x410 has the same SoC on board, the easiest way for me to do this > will be to use as much of the existing open source work done by > forking the USRP design. However, I'm getting stuck on building yocto > due to a symbol duplicate in gdbm build within the oe-core package. > There seem to be several steps involved in this port/fork - stubbing > the RF frontend controls and removing support in the UHD host drivers, > adapting the board constraints, possibly reducing some buffer sizes > due to lower available PL RAM, but right now I am trying to verify if > I'll be able to get access to all the sources and tools required to > make the processing subsystem pipe or filter samples between the hard > logic gigabit ethernet controller and the programmable logic with the > RFNoC crossbar, and to perform the RFNoC control operations. This is > because the RFSoC 2x2 lacks an SFP-like interface for higher bandwidth > data packet streaming. It's only mentioned in one line in the x410 > manual: > Like other USRPs, it is addressable through a 1 GbE RJ45 connector, > which allows full access to the embedded Linux system, as well as data > streaming at low rates. > I'd like to build Linux for the USRP to see what sources it pulls and > to verify and maybe modify the datapath from the gigabit controller > through the driver to the PL. However, I have trouble getting it to > build. > I'm running Arch Linux with GCC 11.1, kas 2.5 (directly, no docker image). > On meta-ettus repository, tag v4.1.0.2-rc3, running > `./contrib/kas_build_imgs_package.sh x4xx` fails the oe-core step: > > | /home/emil/school/meta-ettus/build/tmp-glibc/hosttools/ld: > ./libgdbmapp.a(parseopt.o):(.bss+0x8): multiple definition of > `parseopt_program_args'; gdbmtool.o:(.data.rel.local+0x260): first > defined here > | /home/emil/school/meta-ettus/build/tmp-glibc/hosttools/ld: > ./libgdbmapp.a(parseopt.o):(.bss+0x10): multiple definition of > `parseopt_program_doc'; gdbmtool.o:(.data.rel.local+0x268): first > defined here > > Is this replicable for you? It happens to me with the x4xx-prerelease > tag, too. Is there some frozen development setup environment that > should be used? Is that included in the kas docker? If so, how would I > invoke kas from docker to use the yaml configs? > > Also, I've gone through the "MPM" and "firmware" sections of the UHD > tree looking for software that would run on the SoC and configure the > gigabit ethernet and work with it. For example, in x300, this is done > in firmware/usrp3/x300/x300_init.c but I have not found any > configuration (any eventual calls to xge_* etc). Am I wrong to assume > that this code has not been published yet? Is it going to be made open > source in the future? It really seems like everything else is present, > but the actual userspace software running on the x400. > > Best regards, > > Emil J Tywoniak, > Faculty of Electrical Engineering > Czech Technical University in Prague > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to 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
