[USRP-users] GR Amateur Radio video meeting
**Saturday 12 December 2020 16:00 UTC** Subject: Transmit / Receive switching and station control Presenter: Gavin Jacobs VE7GSJ Agenda: * Requirements for TX/RX switching * VE7GSJ Solution (hardware & GNURadio Companion) * Demo on 2m repeater See the details at https://wiki.gnuradio.org/index.php/Talk:HamRadio No registration required. 73, -- Barry Duggan KV4FV https://github.com/duggabe ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Fwd: E310: Change MAC Address?
On 12/1/20 12:52 PM, Andrew Payne via USRP-users wrote: > That worked as planned, no more duplicate MAC addresses now. > > As you can see from the following 3 boot message blocks (1. before, 2. > after applying said env settings, 3. thereafter) it knew the environment > MAC didn't match the ROM MAC. But it's just a warning. > > Thanks! Thanks for testing. I'm sure this will come up with work I have, nice to already understand the issue. This definitely should be fixable in u-boot. I suspect it can be done with config options, otherwise the code paths need reviewing. mac addresses follow hardware not removable sd cards. Philip > > --- > 1. before > --- > U-Boot 2018.07 (Dec 16 2019 - 20:52:43 +) > > Model: NI Ettus Research E31x SDR > DRAM: ECC disabled 1 GiB > MMC: sdhci@e010: 0 > Loading Environment from MMC... OK > In:serial@e000 > Out: serial@e000 > Err: serial@e000 > NI Ettus Research E31x SG3 SDR Rev H s/n 31370F8 > Net: ZYNQ GEM: e000b000, phyaddr 0, interface rgmii-id > > Warning: ethernet@e000b000 MAC addresses don't match: > Address in ROM is 00:80:2f:18:24:ef > Address in environment is 00:80:2f:19:4c:37 > eth0: ethernet@e000b000 > Automatic boot in 3s... > Enter 'noautoboot' to enter prompt without timeout > ni-e31x-uboot> > > --- > 2. after applying said env settings > --- > U-Boot 2018.07 (Dec 16 2019 - 20:52:43 +) > > Model: NI Ettus Research E31x SDR > DRAM: ECC disabled 1 GiB > MMC: sdhci@e010: 0 > Loading Environment from MMC... OK > In:serial@e000 > Out: serial@e000 > Err: serial@e000 > NI Ettus Research E31x SG3 SDR Rev H s/n 31370F8 > Net: ZYNQ GEM: e000b000, phyaddr 0, interface rgmii-id > > Warning: ethernet@e000b000 using MAC address from ROM > eth0: ethernet@e000b000 > Automatic boot in 3s... > Enter 'noautoboot' to enter prompt without timeout > Saving Environment to MMC... Writing to redundant MMC(0)... OK > Copying FIT from SD to RAM... > 5866988 bytes read in 336 ms (16.7 MiB/s) > ## Loading kernel from FIT Image at 0200 ... > > --- > 3. thereafter > --- > U-Boot 2018.07 (Dec 16 2019 - 20:52:43 +) > > Model: NI Ettus Research E31x SDR > DRAM: ECC disabled 1 GiB > MMC: sdhci@e010: 0 > Loading Environment from MMC... OK > In:serial@e000 > Out: serial@e000 > Err: serial@e000 > NI Ettus Research E31x SG3 SDR Rev H s/n 31370F8 > Net: ZYNQ GEM: e000b000, phyaddr 0, interface rgmii-id > eth0: ethernet@e000b000 > Automatic boot in 3s... > Enter 'noautoboot' to enter prompt without timeout > Copying FIT from SD to RAM... > 5866988 bytes read in 336 ms (16.7 MiB/s) > ## Loading kernel from FIT Image at 0200 ... > > On Fri, Nov 27, 2020 at 7:39 PM Philip Balister wrote: > >> OK try this at the u-boot prompt: >> >> env default -a >> env save >> >> and then >> >> reset >> >> This should reset the u-boot env to the default values and I think this >> resets the ethaddr variable. Then you write it to the mmc (99% >> certain). On the next hard reset hopefully it reads the address from the >> eeprom. >> >> Philip >> >> On 11/27/20 2:20 PM, Andrew Payne wrote: >>> Thanks Aneesh but the decompiled dts file has no mention of the exact MAC >>> address for eth0, but just to read from the eeprom from what I can >> gather. >>> Plus an md5sum of the dtb file on the sdimg from Ettus is the same >> checksum >>> as an e310 that has booted. >>> >>> On Fri, Nov 27, 2020 at 1:40 PM Philip Balister >> wrote: >>> On 11/27/20 1:34 PM, aneesh patel via USRP-users wrote: > Hi Andrew, > The MAC may be in the devicetree blobs in the boot area of the SD >> image. > You will need dtcedit to decompile, edit, and recompile as needed. I don't think so, since the first time the card boots it does read from the i2c eeprom. I'm guessing u-boot sets the ethaddr env var and saves it in the environment, but I forget where that might be saved. Need to review the u-boot configuration for setting about the u-boot env (maybe getting saved to the sd card). Anyone from Ettus paying attention? This is a pretty serious problem for people copying cards and using them in different units. The correct behavior is follow the MAC address programmed into the i2c eeprom. Philip > Amp > > Sent from Yahoo Mail on Android > > On Fri, Nov 27, 2020 at 1:23 PM, Andrew Payne via USRP-users< usrp-users@
Re: [USRP-users] Fwd: E310: Change MAC Address?
That worked as planned, no more duplicate MAC addresses now. As you can see from the following 3 boot message blocks (1. before, 2. after applying said env settings, 3. thereafter) it knew the environment MAC didn't match the ROM MAC. But it's just a warning. Thanks! --- 1. before --- U-Boot 2018.07 (Dec 16 2019 - 20:52:43 +) Model: NI Ettus Research E31x SDR DRAM: ECC disabled 1 GiB MMC: sdhci@e010: 0 Loading Environment from MMC... OK In:serial@e000 Out: serial@e000 Err: serial@e000 NI Ettus Research E31x SG3 SDR Rev H s/n 31370F8 Net: ZYNQ GEM: e000b000, phyaddr 0, interface rgmii-id Warning: ethernet@e000b000 MAC addresses don't match: Address in ROM is 00:80:2f:18:24:ef Address in environment is 00:80:2f:19:4c:37 eth0: ethernet@e000b000 Automatic boot in 3s... Enter 'noautoboot' to enter prompt without timeout ni-e31x-uboot> --- 2. after applying said env settings --- U-Boot 2018.07 (Dec 16 2019 - 20:52:43 +) Model: NI Ettus Research E31x SDR DRAM: ECC disabled 1 GiB MMC: sdhci@e010: 0 Loading Environment from MMC... OK In:serial@e000 Out: serial@e000 Err: serial@e000 NI Ettus Research E31x SG3 SDR Rev H s/n 31370F8 Net: ZYNQ GEM: e000b000, phyaddr 0, interface rgmii-id Warning: ethernet@e000b000 using MAC address from ROM eth0: ethernet@e000b000 Automatic boot in 3s... Enter 'noautoboot' to enter prompt without timeout Saving Environment to MMC... Writing to redundant MMC(0)... OK Copying FIT from SD to RAM... 5866988 bytes read in 336 ms (16.7 MiB/s) ## Loading kernel from FIT Image at 0200 ... --- 3. thereafter --- U-Boot 2018.07 (Dec 16 2019 - 20:52:43 +) Model: NI Ettus Research E31x SDR DRAM: ECC disabled 1 GiB MMC: sdhci@e010: 0 Loading Environment from MMC... OK In:serial@e000 Out: serial@e000 Err: serial@e000 NI Ettus Research E31x SG3 SDR Rev H s/n 31370F8 Net: ZYNQ GEM: e000b000, phyaddr 0, interface rgmii-id eth0: ethernet@e000b000 Automatic boot in 3s... Enter 'noautoboot' to enter prompt without timeout Copying FIT from SD to RAM... 5866988 bytes read in 336 ms (16.7 MiB/s) ## Loading kernel from FIT Image at 0200 ... On Fri, Nov 27, 2020 at 7:39 PM Philip Balister wrote: > OK try this at the u-boot prompt: > > env default -a > env save > > and then > > reset > > This should reset the u-boot env to the default values and I think this > resets the ethaddr variable. Then you write it to the mmc (99% > certain). On the next hard reset hopefully it reads the address from the > eeprom. > > Philip > > On 11/27/20 2:20 PM, Andrew Payne wrote: > > Thanks Aneesh but the decompiled dts file has no mention of the exact MAC > > address for eth0, but just to read from the eeprom from what I can > gather. > > Plus an md5sum of the dtb file on the sdimg from Ettus is the same > checksum > > as an e310 that has booted. > > > > On Fri, Nov 27, 2020 at 1:40 PM Philip Balister > wrote: > > > >> On 11/27/20 1:34 PM, aneesh patel via USRP-users wrote: > >>> Hi Andrew, > >>> The MAC may be in the devicetree blobs in the boot area of the SD > image. > >>> You will need dtcedit to decompile, edit, and recompile as needed. > >> > >> I don't think so, since the first time the card boots it does read from > >> the i2c eeprom. > >> > >> I'm guessing u-boot sets the ethaddr env var and saves it in the > >> environment, but I forget where that might be saved. Need to review the > >> u-boot configuration for setting about the u-boot env (maybe getting > >> saved to the sd card). > >> > >> Anyone from Ettus paying attention? This is a pretty serious problem for > >> people copying cards and using them in different units. The correct > >> behavior is follow the MAC address programmed into the i2c eeprom. > >> > >> Philip > >> > >>> Amp > >>> > >>> Sent from Yahoo Mail on Android > >>> > >>> On Fri, Nov 27, 2020 at 1:23 PM, Andrew Payne via USRP-users< > >> usrp-users@lists.ettus.com> wrote: > >> ___ > >>> 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
[USRP-users] Zeus build for E300
I am building the zeus branch of meta-ettus for the e3xx and had a conflict applying the patch 0019-spi-cadence-Revert-cs-gpio-using-descriptors.patch to linux-yocto. Dropping the patch leads to the kernel compiling. Hopefully someone from NI can look into this. I did update the other layers to the latest zeus, so I suspect more changes to linux-yocto that fix other problems. Philip ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] DPDK with UHD 4.0
Hi, i'm trying to use DPDK with UHD 4 but it is not detected by cmake. i have ubuntu 20.04.1 which installs DPDK 19.11.3-0ubuntu0.2 when i use apt-get install dpdk dpdk-dev i tried passing manually environment variables for include and library directories but that doesn't work. can you please shed some light on this? thanks, Dario ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Can I detect a wiretype of USB device?
If you have access to the UHD API, the property tree entry is
/mboards/0/link_max_rate.
So, something like
auto value =
my_usrp_object->get_tree()->access("/mboards/0/link_max_rate")
will give you the maximum rate you can transport through your USB link.
Maybe that's actually what you're looking for, but otherwise it suffices
to figure out whether you're on High Speed or USB3 SuperSpeed.
Note this: The Property Tree is **NOT** UHD API! There's No Guarantee At
All This Won't Change.
Best regards,
Marcus
On 01.12.20 02:55, Mikio Fukushima via USRP-users wrote:
> Hi,
>
> I use a B200 and B200mini.
> Often they are connected under USB 2.0 ports, it will cause some problems.
> Can I detect a wire type of USB device by UHD API?
>
> Mikio
>
> ___
> 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
