Cellular Network Infrastructure » Radio Access Network » OsmoTRX

yes. and you will probably have to set a path for the fpga images, too.

Hoernchen wrote in #note-1:

yes. and you will probably have to set a path for the fpga images, too.

It's amazing how much Ettus/NI seem to be intent on making sure they loose their brand image as former industry standard of FPGA drivers. What a shame.

the patch introducing the method uhd::get_xdg_data_home() is:

commit 1383fde3457168ed759d6ed3b913dfae8a6085ef
Author:     Martin Braun <martin.braun@ettus.com>
AuthorDate: Thu Mar 5 16:23:07 2020 -0800
Commit:     Aaron Rossetto <aaron.rossetto@ni.com>
CommitDate: Thu Apr 2 12:36:20 2020 -0500

Before the commit UHD_CONFIG_DIR/APPDATA/HOME environment variables were used if present, but not mandatory, as uhd::get_app_path() would simply have returned return uhd::get_tmp_path(); by default.

And of course the commit log only talks about moving around files and/or variable names and doesn't state at all that suddenly there is a significant change in policy, i.e. that those variables are now mandatory and not optional anymore.

bit of insight might help: absolutely sure no one at Ettus intentionally breaks things¹ ;-)
There's been an UHD config file for a long time, there's good reason to put it into XDG directories if possible, and I guess the fact that this would fatally fail if these environment variables aren't set and that this can totally happen in the wild just got overlooked; the docs² contradict this behaviour. Want me to put in an upstream bug report?

If this is required by UHD these days, then we need to adjust our systemd unit accordingly to make sure it has whatever environment variables it deems necessary.

Honestly, setting the firmware image directory explicitly is actually a good idea should testing need to work with different UHD versions; being able to have a test-specific config makes sense to me, as well.

Bit surprised that $HOME isn't set in a systemd service!

¹ There might or might not be stories of people throwing E310 prototypes off roofs or driving over them with heavy cars, but I don't think that's the kind of attempted breakage you're referring to!
² https://uhd.readthedocs.io/en/uhd-4.5/page_configfiles.html#configfiles_location

On Wed, Nov 22, 2023 at 03:31:09PM +0000, funkylab wrote:

There's been an UHD config file for a long time, there's good reason to put it into XDG directories if possible,

yes, certainly. I don't doubt that.

and I guess the fact that this would fatally fail if these environment variables aren't set and that this can totally happen in the wild just got overlooked; the docs² contradict this behaviour. Want me to put in an upstream bug report?

I actually did check the upstream github reports and didn't find any mention of it whatsoever. I presume it's not uncommon for people in production deployments to start their osmo-trx-uhd / yatebts / openbts / srsran / amarisoft / ... cellular base station (or other SDR application) via a systemd unit.

If you think it is a bug, feel free to file it upstream. I can also do that, of course, but I'm less familiar with what is intended.

If this is required by UHD these days, then we need to adjust our systemd unit accordingly to make sure it has whatever environment variables it deems necessary.

Honestly, setting the firmware image directory explicitly is actually a good idea should testing need to work with different UHD versions; being able to have a test-specific config makes sense to me, as well.

Note that I did not have to set a firmware path explicitly, but that might have been because I already loaded the firmware with another invoacation before starting osmo-trx-uhd.

In any case, this is not about testing. This is about production use. Its reasonable to expect that you can install a software package via apt, edit the config file as needed and then simply enable the packaged systemd service.

I'd also not understand why setting a firmware path would be required explicitly. Isn't there one valid
firmware image for one valid piece of hardware (auto-detected) and UHD version (determined by the single UHD
version installed from the distribution pacakge manager)?

Bit surprised that $HOME isn't set in a systemd service!

I'm far from being a systemd expert, but I guess it might if you'd run the service as non-root.
Sadly #4107 is still not completed. I'll do some more experiments.

:) Just submitting a report upstream then, since I can locally reproduce, anyways.

I'd also not understand why setting a firmware path would be required explicitly .

That certainly shouldn't be the case. It should (and does, as far as I can reproduce) default to /usr/share/uhd/images/.

Isn't there one valid firmware image for one valid piece of hardware (auto-detected) and UHD version (determined by the single UHD version installed from the distribution pacakge manager)?

Ah, not quite. The X3x0 series (and newer dual Q?SFP models) come with different FPGA image "flavors" depending on which combination of 1G/10G/… interfaces you want to operate.
Also, let's call them "3-series+" models (so everything after the B200, essentially) all support RFNoC, where the user builds their own FPGA image with their own compute (selection of stock, or self-written) elements next to the fixed, necessary infrastructure, into the FPGA; they all get connected to a central crossbar, and then you can use host-side software to say things like "take the samples coming in packets from the radio frontend, push them through the custom preamble detector, …

That requires that aside from the "default" images that basically make the USRP an RF soundcard on speed there's a need to be able to specify your own images.

Thanks!

On Wed, Nov 22, 2023 at 05:11:07PM +0000, funkylab wrote:

I'd also not understand why setting a firmware path would be required explicitly .

That certainly shouldn't be the case. It should (and does, as far as I can reproduce) default to /usr/share/uhd/images/.

ok, we're all in agreement. for sure it should always be possible to specify a different image as override,
we can all agree on that.