On 2021-09-07 4:25 p.m., 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
This seems a very ambitious project, and I wish you luck.
The amount of experience "out there" with the X400 series from Ettus at
this point is very small, so don't be that surprised not to get much in
the way of help
from "the community".
In terms of Ettus R&D folks who may be able to help you, they're pretty
busy working on actual Ettus/NI products, and likely don't have a lot of
time
to help folks porting Ettus code to non-Ettus hardware. Just a
practicality of time management.
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
