Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UHD 4.0 Missing RFNOC images for e310 #788

Closed
mgarrett1955 opened this issue Sep 29, 2024 · 4 comments
Closed

UHD 4.0 Missing RFNOC images for e310 #788

mgarrett1955 opened this issue Sep 29, 2024 · 4 comments

Comments

@mgarrett1955
Copy link

Issue Description

I am updating a e310 application that uses python uhd, rfnoc images usrp_e310_fpga_RFNOC_sg3.bit.
The rfnoc images that are provided, include just the radio_0 block: usrp_e310_sg3_fpga.bit

The GNU radio compile was provided in the ettus binaries for ubuntu UHD installation, and is functioning both with the standard IHD block, and the RFNOC radio block. None of the other blocks are on the FPGA.

On the device, e310, I am running the provided binary image:
usrp_e310_fs.sdimg, retrieved by the ubuntu installed UHD 4.0.0 downloader.

If I place new sdcard image in the e310, get the e310 images on the device, do I need to update the FPGA, or does
the boot process apply the image at startup? (I forgot how that worked, you can see the FPGA condifuration below).

Do I need to create a new FPGA image using the uhd_image_builder (Vivado 2021.1)?

Setup Details

UHD 4.0.0
Gnuradio 3.10.9.2
Linux Ubuntu 24.02

Expected Behavior

Find usrp_e310_fpga_RFNOC_sg3.bit in the images database.

Actual Behaviour

mgarrett@rflab-30:~$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 13.2.0; Boost_108300; UHD_4.7.0.0-72-gd6ba2dfb
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.1.131,type=e3xx,product=e310_sg3,serial=31F3C06,name=ni-e31x-31F3C06,fpga=n/a,claimed=False,addr=192.168.1.131
[WARNING] [MPM.RPCServer] A timeout event occured!
[INFO] [MPM.PeriphManager] init() called with device args `fpga=n/a,mgmt_addr=192.168.1.131,name=ni-e31x-31F3C06,product=e310_sg3'.
[WARNING] [UDP] The send buffer could not be resized sufficiently.
Target sock buff size: 2500000 bytes.
Actual sock buff size: 1048576 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=2500000
[INFO] [0/Radio#0] Performing CODEC loopback test on channel 0 ...
[INFO] [0/Radio#0] CODEC loopback test passed
[INFO] [0/Radio#0] Performing CODEC loopback test on channel 1 ...
[INFO] [0/Radio#0] CODEC loopback test passed


/
| Device: E300-Series Device
| _____________________________________________________
| /
| | Mboard: ni-e31x-31F3C06
| | dboard_0_pid: 272
| | dboard_0_serial: 31E839C
| | fs_version: 20231113194348
| | mender_artifact: v4.6.0.0_e310_sg3
| | mpm_sw_version: 4.6.0.0-g50fa3baa
| | pid: 30675
| | product: e310_sg3
| | rev: 10
| | rpc_connection: remote
| | serial: 31F3C06
| | type: e3xx
| | MPM Version: 5.3
| | FPGA Version: 6.1
| | FPGA git hash: 6a990d9.clean
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo
| | Clock sources: internal
| | Sensors: ref_locked, gps_locked, temp_fpga, temp_mb, gps_gpgga, gps_sky, gps_time, gps_tpv
| _____________________________________________________
| /
| | RFNoC blocks on this device:
| |
| | * 0/Radio#0
| _____________________________________________________
| /
| | Static connections on this device:
| |
| | * 0/SEP#0:0==>0/Radio#0:0
| | * 0/Radio#0:0==>0/SEP#0:0
| | * 0/SEP#1:0==>0/Radio#0:1
| | * 0/Radio#0:1==>0/SEP#1:0
| _____________________________________________________
| /
| | TX Dboard: 0/Radio#0
| | _____________________________________________________
| | /
| | | TX Frontend: 0
| | | Name: E3xx
| | | Antennas: TX/RX
| | | Freq range: 47.000 to 6000.000 MHz
| | | Gain range PGA: 0.0 to 89.8 step 0.2 dB
| | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz
| | | Connection Type: IQ
| | | Uses LO offset: No
| | _____________________________________________________
| | /
| | | TX Frontend: 1
| | | Name: E3xx
| | | Antennas: TX/RX
| | | Freq range: 47.000 to 6000.000 MHz
| | | Gain range PGA: 0.0 to 89.8 step 0.2 dB
| | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz
| | | Connection Type: IQ
| | | Uses LO offset: No
| _____________________________________________________
| /
| | RX Dboard: 0/Radio#0
| | _____________________________________________________
| | /
| | | RX Frontend: 0
| | | Name: E3xx
| | | Antennas: RX2, TX/RX
| | | Freq range: 70.000 to 6000.000 MHz
| | | Gain range PGA: 0.0 to 76.0 step 1.0 dB
| | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz
| | | Connection Type: IQ
| | | Uses LO offset: No
| | _____________________________________________________
| | /
| | | RX Frontend: 1
| | | Name: E3xx
| | | Antennas: RX2, TX/RX
| | | Freq range: 70.000 to 6000.000 MHz
| | | Gain range PGA: 0.0 to 76.0 step 1.0 dB
| | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz
| | | Connection Type: IQ
| | | Uses LO offset: No

mgarrett@

Steps to reproduce the problem

Create an UHD e310 sdimage, boot the device, get the fpga images using uhd_images_downloader (on the device, or on host)
use -n -t "RFNOC", no RFNOC images are present.

Additional Information

@mgarrett1955 mgarrett1955 changed the title UHD 4.0 Missing RFNOC images UHD 4.0 Missing RFNOC images for e310 Sep 29, 2024
@mgarrett1955
Copy link
Author

mgarrett1955 commented Sep 29, 2024

I can see in this file: build_instructions_uhd4p0.md content that indicates that all rfnoc images need to be built using the builder, and are no longer provided as binary images. I believe that answers my question!

The only remaining question is do I always need to update the FPGA using uhd_image_loader, in other words the boot process does not load the binary on power up from a stored config?

In other words, given that I have updated to UHD 4.0, if I want to use the supplied default FPGA, I need to run the uhd_image_loader to update the FPGA (The FPGA firmware is stored in non-volotile memory and is written once?)?

Thank you in advance!!

@mbr0wn
Copy link
Contributor

mbr0wn commented Sep 30, 2024

Some comments:

  • The filesystem images contain bitfiles, so you don't need to load bitfiles after updating the sdimg
  • The last image that you load is stored on the SD card and is re-loaded after reboot.

If you update your SD card image, but want to keep the bitfile, you need to back that up separately. There is no other storage on the device for bitfiles other than the SD card.

Hope that clears things up!

@mbr0wn mbr0wn closed this as completed Sep 30, 2024
@mgarrett1955
Copy link
Author

Thenk you Martin, very clear! Thank you for the great products and quick reponse.

@mbr0wn
Copy link
Contributor

mbr0wn commented Sep 30, 2024

@mgarrett1955 you're very welcome -- but please use the mailing list for these support questions, rather than the issue tracker. Use this to report bugs. Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants