Re: [USRP-users] microSD Size Limit

[Philip Balister via USRP-users]

I'm pretty sure I've used bigger than that, please anyone that finds out
what is too big, let the list know!

Philip

On 2/19/21 11:39 AM, Marcus D Leech via USRP-users wrote:
> I’ve used 32G without any issues. 
> 
> Sent from my iPhone
> 
>> On Feb 19, 2021, at 11:27 AM, Dennis Trask via USRP-users 
>>  wrote:
>>
>> What is the largest microSD card supported by the E310? I want to get 
>> larger cards for development purposes, but don't want to buy a size that 
>> isn't supported.
>>
>> Thanks,
>> Dennis
>>
>> ___
>> 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.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E310 with v4.0.0.0 Image: Configure Static IP

[Philip Balister via USRP-users]

Which issues did you fix? The list I am maintainin gin my head is:

1) fftw segfaults
2) sg3 runs at sg1 processor speed
3) gnuradio 3.8.0 needs updating to 3.8.2
4) issues compiling OOTs for gnuradio
4) and rest of runtime needs updating from zeus

Philip

On 2/10/21 9:44 AM, Ben Magistro via USRP-users wrote:
> I am using an image based on the v4.0.0.0 variant but I needed to rebuild
> it to overcome some other issues with the image.  What you listed does work
> for me.  If the link is not active, looking at the output of `ip addr` will
> not show any inet address(es).  I don't see any obvious typos/differences
> between what you provided and what I am using but including the contents
> just to be safe.  As far as I know the name should not make any difference
> provided it ends with `.network`.
> 
> root@ni-e31x-31D7B0C:~# cat /etc/systemd/network/20-wired.network
> [Match]
> Name=eth0
> 
> [Network]
> Address=192.168.200.250/24
> 
> root@ni-e31x-31D7B0C:~# ip addr
> 1: lo:  mtu 65536 qdisc noqueue qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
>valid_lft forever preferred_lft forever
> 2: eth0:  mtu 1500 qdisc pfifo_fast qlen
> 1000
> link/ether 00:80:2f:30:8f:ca brd ff:ff:ff:ff:ff:ff
> inet 192.168.200.250/24 brd 192.168.200.255 scope global eth0
>valid_lft forever preferred_lft forever
> 
> 
> root@ni-e31x-31D7B0C:~# systemctl | grep -i net
> sys-devices-soc0-amba-e000b000.ethernet-net-eth0.device
>   loaded active plugged
> /sys/devices/soc0/amba/e000b000.ethernet/net/eth0
> 
> sys-subsystem-net-devices-eth0.device
>   loaded active plugged   /sys/subsystem/net/devices/eth0
> 
> systemd-networkd.service
>loaded active running   Network Service
> 
> systemd-resolved.service
>loaded active running   Network Name Resolution
> 
> systemd-timesyncd.service
>   loaded active running   Network Time Synchronization
> 
> systemd-networkd.socket
>   loaded active running   Network Service Netlink Socket
> 
> network-pre.target
>loaded active activeNetwork (Pre)
> 
> network.target
>loaded active activeNetwork
> 
> nss-lookup.target
>   loaded active activeHost and Network Name Lookups
> 
> 
> 
> Hope this helps.
> 
> On Tue, Feb 9, 2021 at 5:47 PM Dennis Trask via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> 
>> Thanks, Marcus.
>>
>> That was actually what I attempted first. As described in the man page (
>> https://www.freedesktop.org/software/systemd/man/systemd.network.html) I
>> created eth0.network under /etc/systemd/network/, with these contents:
>>
>> [Match]
>> Name=eth0
>>
>> [Network]
>> Address=192.168.200.2/24
>>
>> The system seemed to ignore this configuration, however.
>>
>>
>>
>> -
>> From: "Marcus D. Leech via USRP-users"
>> To: usrp-users@lists.ettus.com
>> Cc:
>> Sent: Tuesday February 9 2021 4:42:34PM
>> Subject: Re: [USRP-users] E310 with v4.0.0.0 Image: Configure Static IP
>>
>> On 02/09/2021 04:35 PM, Dennis Trask via USRP-users wrote:
>>
>> I have re-imaged the SD card for my E310 with the v4.0.0.0 image. I cannot
>> figure out how to set a static IP address on eth0 at boot-up. I created an
>> /etc/network/interfaces file that looks like this:
>>
>> auto eth0
>> iface eth0 inet static
>> address 192.168.200.2
>> netmask 255.255.255.0
>>
>> I can run the command "ifup eth0" and bring up the interface with the
>> desired configuration, but it does not initialize when I reboot.
>>
>> The SD image I am using was obtained with the command:
>> uhd_images_downloader -t e310 -t sg3
>>
>> I built the uhd_images_downloder from source, and it's version
>> is 4.0.0.HEAD-0-g90ce6062.
>>
>> Dennis
>>
>>
>>
>> ___
>> USRP-users mailing list
>> "mailto:USRP-users@lists.ettus.com;>USRP-users@lists.ettus.com
>> "http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com;>
>> 
>> target=
>> "_blank">
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> It almost certainly is running systemd/networkd
>>
>> So look under /etc/systemd/networkd
>>
>> In Linux, there have historically been many different ways to configure
>> network devices, and even under systemd, there are a couple of
>>   different schemes "out there".  I believe that in a UHD 4 system image
>> on E310, it is based on Networkd.
>>
>>
>> ___
>> 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
> 

Re: [USRP-users] Failed to compile UHD 3.15 on E310 target

[Philip Balister via USRP-users]

He should have a toolchain file that has this in it.

What stops you from cross compiling it?

I realize there is a lot of bad information on the web :(

Philip

On 2/6/21 2:24 PM, Ron Economos via USRP-users wrote:
> You have to specify a NEON architecture during CMake.
> 
> cmake -DCMAKE_CXX_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard
> -mfpu=neon -mtune=cortex-a9 -Wno-psabi"
> -DCMAKE_C_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard -mfpu=neon
> -mtune=cortex-a9 -Wno-psabi" -DCMAKE_ASM_FLAGS:STRING="-march=armv7-a
> -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 -g" ../
> 
> Ron
> 
> On 2/6/21 07:57, Ofer Saferman via USRP-users wrote:
>> Hello,
>>
>> I made a small modification to UHD and would like to compile and use
>> my version.
>> Since I never succeeded to cross-compile I decided to try to compile
>> it on the target itself.
>> I am working with an USRP E310.
>> I cloned the 3.15.LTS repository, modified one of the files and tried
>> to compile.
>> During compilation I get the following errors (at about 11% of the
>> process):
>> 
>> In file included from
>> /home/root/uhd/uhd-3.15.LTS/host/lib/convert/convert_with_neon.cpp:10:
>> /usr/lib/gcc/arm-oe-linux-musleabi/8.2.0/include/arm_neon.h: In member
>> function ‘virtual void
>> __convert_fc32_1_sc16_item32_le_1_PRIORITY_SIMD::operator()(const
>> input_type&, const output_type&, size_t)’:
>> /usr/lib/gcc/arm-oe-linux-musleabi/8.2.0/include/arm_neon.h:6740:1:
>> error: inlining failed in call to always_inline ‘float32x4_t
>> vdupq_n_f32(float32_t)’: target specific option mismatch
>>  vdupq_n_f32 (float32_t __a)
>>  ^~~
>> /home/root/uhd/uhd-3.15.LTS/host/lib/convert/convert_with_neon.cpp:27:33:
>> note: called from here
>>      float32x4_t Q0 = vdupq_n_f32(float(scale_factor));
>>                       ~~~^
>> In file included from
>> /home/root/uhd/uhd-3.15.LTS/host/lib/convert/convert_with_neon.cpp:10:
>> /usr/lib/gcc/arm-oe-linux-musleabi/8.2.0/include/arm_neon.h:10844:1:
>> error: inlining failed in call to always_inline ‘void
>> vst1_s16(int16_t*, int16x4_t)’: target specific option mismatch
>>  vst1_s16 (int16_t * __a, int16x4_t __b)
>>  ^~~~
>> /home/root/uhd/uhd-3.15.LTS/host/lib/convert/convert_with_neon.cpp:56:17:
>> note: called from here
>>  vst1_s16((reinterpret_cast([i + 6])), D15);
>>  ^~~
>> In file included from
>> /home/root/uhd/uhd-3.15.LTS/host/lib/convert/convert_with_neon.cpp:10:
>> /usr/lib/gcc/arm-oe-linux-musleabi/8.2.0/include/arm_neon.h:9027:1:
>> error: inlining failed in call to always_inline ‘int16x4_t
>> vrev32_s16(int16x4_t)’: target specific option mismatch
>>  vrev32_s16 (int16x4_t __a)
>>  ^~
>> /home/root/uhd/uhd-3.15.LTS/host/lib/convert/convert_with_neon.cpp:55:37:
>> note: called from here
>>          int16x4_t D15   = vrev32_s16(D14);
>>                            ~~^
>> In file included from
>> /home/root/uhd/uhd-3.15.LTS/host/lib/convert/convert_with_neon.cpp:10:
>> /usr/lib/gcc/arm-oe-linux-musleabi/8.2.0/include/arm_neon.h:7552:1:
>> error: inlining failed in call to always_inline ‘int16x4_t
>> vmovn_s32(int32x4_t)’: target specific option mismatch
>>  vmovn_s32 (int32x4_t __a)
>>  ^
>> /home/root/uhd/uhd-3.15.LTS/host/lib/convert/convert_with_neon.cpp:54:36:
>> note: called from here
>>          int16x4_t D14   = vmovn_s32(Q13);
>>                            ~^
>> In file included from
>> /home/root/uhd/uhd-3.15.LTS/host/lib/convert/convert_with_neon.cpp:10:
>> /usr/lib/gcc/arm-oe-linux-musleabi/8.2.0/include/arm_neon.h:7440:1:
>> error: inlining failed in call to always_inline ‘int32x4_t
>> vcvtq_s32_f32(float32x4_t)’: target specific option mismatch
>>  vcvtq_s32_f32 (float32x4_t __a)
>>  ^
>> /home/root/uhd/uhd-3.15.LTS/host/lib/convert/convert_with_neon.cpp:53:40:
>> note: called from here
>>          int32x4_t Q13   = vcvtq_s32_f32(Q11);
>>                            ~^
>> In file included from
>> /home/root/uhd/uhd-3.15.LTS/host/lib/convert/convert_with_neon.cpp:10:
>> /usr/lib/gcc/arm-oe-linux-musleabi/8.2.0/include/arm_neon.h:1172:1:
>> error: inlining failed in call to always_inline ‘float32x4_t
>> vmulq_f32(float32x4_t, float32x4_t)’: target specific option mismatch
>>  vmulq_f32 (float32x4_t __a, float32x4_t __b)
>>  ^
>> /home/root/uhd/uhd-3.15.LTS/host/lib/convert/convert_with_neon.cpp:52:36:
>> note: called from here
>>          float32x4_t Q11 = vmulq_f32(Q10, Q0);
>>                            ~^
>> In file included from
>> /home/root/uhd/uhd-3.15.LTS/host/lib/convert/convert_with_neon.cpp:10:
>> /usr/lib/gcc/arm-oe-linux-musleabi/8.2.0/include/arm_neon.h:10844:1:
>> error: inlining failed in call to always_inline ‘void
>> vst1_s16(int16_t*, int16x4_t)’: target specific option mismatch
>>  vst1_s16 (int16_t * __a, int16x4_t __b)
>>  

Re: [USRP-users] meta-ettus-v4.0.0.0 segfault

[Philip Balister via USRP-users]

I haven't :( I have been looking at packaged testing for volk and
gnuradio. Once I have this sorted, I'll spend a little time looking into
setting this up for fftw to try and catch this problem faster in the future.

Philip

On 1/9/21 3:29 PM, Ben Magistro via USRP-users wrote:
> Finally getting a chance to circle back to this and I would rather be on
> dunfell but the bsp for the E310 doesn't appear to have been ported yet.  I
> made an attempt but cannot build an image successfully and need to do a
> better set of diffs on the kernel patches.
> 
> Has anyone else started on a dunfell port?
> 
> Ben
> 
> 
> ___
> 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

Re: [USRP-users] meta-ettus-v4.0.0.0 segfault

[Philip Balister via USRP-users]

On 12/11/20 4:49 PM, Philip Balister via USRP-users wrote:
> On 12/6/20 10:03 AM, Ron Economos via USRP-users wrote:
>> Unfortunately, that FFTW bug has been around for a while. Issue 213 is a
>> duplicate of issue 182 from a year+ ago.
>>
>> https://github.com/FFTW/fftw3/issues/182
>>
>> On Ubuntu 20.04 armhf, they're just compiling the FFTW package without
>> NEON enabled.
> 
> I poked at this way more than I should have and am 99% certain the issue
> in in gcc-8. Building with -O off led to an fftw that would pass its
> make check. I tried a build on a qemuarm from OE/master and that worked
> (gcc-10). gcc-9 is a question, I fired up a build of OE/dunfell (gcc-9)
> and will run the qemu check and see what happens.

In the bad news, fftw qa tests fail in qemuarm with gcc9.

Philip

> 
> If you are stuck on zeus, you'll need to try and id the patch that fixes
> gcc and apply it to the gcc build. But getting off zeus would be a
> really bood move as it is out of support now.
> 
> Philip
> 
>>
>> Ron
>>
>> On 12/6/20 06:27, Ben Magistro via USRP-users wrote:
>>> Issue appears to be with the compiler that is included in Zeus (gcc
>>> 9.x vs 8.x) and an interaction with fftw. There is an open issue with
>>> fftw (https://github.com/FFTW/fftw3/issues/213) and a request to the
>>> yocto folks to request they consider adding back gcc-8.3 to zeus +
>>> dunfell (https://bugzilla.yoctoproject.org/show_bug.cgi?id=14144)
>>> until this can be better resolved.  I think data point 3 confirms this
>>> as I did not include options to enable neon when I compiled.
>>>
>>> On Wed, Nov 11, 2020 at 1:39 PM Ben Magistro >> <mailto:konce...@gmail.com>> wrote:
>>>
>>>     Adding some more data points.
>>>
>>>     1) I've been trying to rebuild meta-ettus-v4 with debug enabled
>>>     but am hitting an issue with image size and can't seem to get past
>>>     that.  It says I should increase `MENDER_STORAGE_TOTAL_SIZE_MB` if
>>>     the actual size is larger but increasing this seems to have no
>>>     effect.  I am using the ettus docker image for oe-builder with the
>>>     command `./meta-ettus/contrib/build_imgs_package.sh e310_sg3
>>>     v4.0.0.0`.  For the debug portion I've added a few lines to
>>>     `build/conf/local.conf` to add the packages. I'm open to
>>>     suggestions to build the image with debug symbols and provide
>>>     additional feedback.
>>>
>>>     2) I put together a simple flowgraph, UHD source --> frequency
>>>     xlating fft --> null sink.  This also segfaults, no guarantees
>>>     that I got the parameters correct.
>>>
>>>     3) Since the issues seem to be with fftw, I decided to try
>>>     building my own copy of fftw mostly to get debug symbols and
>>>     continue troubleshooting.  For this I used `./configure
>>>     --enable-debug --enable-shared --enable-threads --enable-float`
>>>     and `make CFLAGS="-ggdb"`.  These options are best guesses right
>>>     now since I didn't look at the layers to see what parameters it is
>>>     using (assuming it is in one of the layers).  Using this build
>>>     with `export LD_LIBRARY_PATH=/usr/local/lib/` I do not get a
>>>     segfault with gr-ais or the above flowgraph but I also don't get
>>>     the expected output which makes me question the parameters I used
>>>     to build it.  Output wise I get a string of "D" or "O" to the
>>> console.
>>>
>>>     Thanks
>>>
>>>     Ben
>>>
>>>     On Thu, Nov 5, 2020 at 9:22 AM Michael Dickens
>>>     mailto:michael.dick...@ettus.com>> wrote:
>>>
>>>     Hi Ben - This issue has been reported to R internally. If
>>>     you wish to create a public-facing UHD issue on our Github
>>>     tracker please go ahead & do so, and tag me on it so that we
>>>     can keep track of it internally. - MLD
>>>
>>>     On Wed, Nov 4, 2020 at 11:25 PM Ben Magistro via USRP-users
>>>     >>     <mailto:usrp-users@lists.ettus.com>> wrote:
>>>
>>>     Is anyone else using meta-ettus-v4.0.0.0 yet?  if so, have
>>>     you had any issues with libfftw?
>>>
>>>     Using the image on an E310, adding a single OOT module
>>>     (gr-ais) and trying to run an app distributed with it, the
>>>     app segfaults.  To further troubleshoot, I added

Re: [USRP-users] meta-ettus-v4.0.0.0 segfault

[Philip Balister via USRP-users]

On 12/6/20 10:03 AM, Ron Economos via USRP-users wrote:
> Unfortunately, that FFTW bug has been around for a while. Issue 213 is a
> duplicate of issue 182 from a year+ ago.
> 
> https://github.com/FFTW/fftw3/issues/182
> 
> On Ubuntu 20.04 armhf, they're just compiling the FFTW package without
> NEON enabled.

I poked at this way more than I should have and am 99% certain the issue
in in gcc-8. Building with -O off led to an fftw that would pass its
make check. I tried a build on a qemuarm from OE/master and that worked
(gcc-10). gcc-9 is a question, I fired up a build of OE/dunfell (gcc-9)
and will run the qemu check and see what happens.

If you are stuck on zeus, you'll need to try and id the patch that fixes
gcc and apply it to the gcc build. But getting off zeus would be a
really bood move as it is out of support now.

Philip

> 
> Ron
> 
> On 12/6/20 06:27, Ben Magistro via USRP-users wrote:
>> Issue appears to be with the compiler that is included in Zeus (gcc
>> 9.x vs 8.x) and an interaction with fftw. There is an open issue with
>> fftw (https://github.com/FFTW/fftw3/issues/213) and a request to the
>> yocto folks to request they consider adding back gcc-8.3 to zeus +
>> dunfell (https://bugzilla.yoctoproject.org/show_bug.cgi?id=14144)
>> until this can be better resolved.  I think data point 3 confirms this
>> as I did not include options to enable neon when I compiled.
>>
>> On Wed, Nov 11, 2020 at 1:39 PM Ben Magistro > > wrote:
>>
>>     Adding some more data points.
>>
>>     1) I've been trying to rebuild meta-ettus-v4 with debug enabled
>>     but am hitting an issue with image size and can't seem to get past
>>     that.  It says I should increase `MENDER_STORAGE_TOTAL_SIZE_MB` if
>>     the actual size is larger but increasing this seems to have no
>>     effect.  I am using the ettus docker image for oe-builder with the
>>     command `./meta-ettus/contrib/build_imgs_package.sh e310_sg3
>>     v4.0.0.0`.  For the debug portion I've added a few lines to
>>     `build/conf/local.conf` to add the packages. I'm open to
>>     suggestions to build the image with debug symbols and provide
>>     additional feedback.
>>
>>     2) I put together a simple flowgraph, UHD source --> frequency
>>     xlating fft --> null sink.  This also segfaults, no guarantees
>>     that I got the parameters correct.
>>
>>     3) Since the issues seem to be with fftw, I decided to try
>>     building my own copy of fftw mostly to get debug symbols and
>>     continue troubleshooting.  For this I used `./configure
>>     --enable-debug --enable-shared --enable-threads --enable-float`
>>     and `make CFLAGS="-ggdb"`.  These options are best guesses right
>>     now since I didn't look at the layers to see what parameters it is
>>     using (assuming it is in one of the layers).  Using this build
>>     with `export LD_LIBRARY_PATH=/usr/local/lib/` I do not get a
>>     segfault with gr-ais or the above flowgraph but I also don't get
>>     the expected output which makes me question the parameters I used
>>     to build it.  Output wise I get a string of "D" or "O" to the
>> console.
>>
>>     Thanks
>>
>>     Ben
>>
>>     On Thu, Nov 5, 2020 at 9:22 AM Michael Dickens
>>     mailto:michael.dick...@ettus.com>> wrote:
>>
>>     Hi Ben - This issue has been reported to R internally. If
>>     you wish to create a public-facing UHD issue on our Github
>>     tracker please go ahead & do so, and tag me on it so that we
>>     can keep track of it internally. - MLD
>>
>>     On Wed, Nov 4, 2020 at 11:25 PM Ben Magistro via USRP-users
>>     >     > wrote:
>>
>>     Is anyone else using meta-ettus-v4.0.0.0 yet?  if so, have
>>     you had any issues with libfftw?
>>
>>     Using the image on an E310, adding a single OOT module
>>     (gr-ais) and trying to run an app distributed with it, the
>>     app segfaults.  To further troubleshoot, I added gdb and
>>     it comes back with the following.  I have a separate
>>     development host that has gnuradio 3.8 setup using pybombs
>>     and do not experience this issue there.
>>
>>     Thread 1 "python3" received signal SIGSEGV, Segmentation
>>     fault.
>>     0xb6947836 in ?? () from /usr/lib/libfftw3f.so.3
>>
>>     To compile, I've needed to override PYTHON_EXECUTABLE as
>>     it points to a non-existent path in /home/oe-builder
>>     in /usr/lib/cmake/gnuradio/GnuradioConfig.cmake. To run I
>>     also needed to define LD_EXPORT_PATH pointing to
>>     /usr/local/lib/.
>>
>>     Thanks in advance.
>>     ___
>>     USRP-users mailing list
>>     USRP-users@lists.ettus.com
>> 
>>    
>> 

Re: [USRP-users] meta-ettus-v4.0.0.0 segfault

[Philip Balister via USRP-users]

On 12/6/20 10:03 AM, Ron Economos via USRP-users wrote:
> Unfortunately, that FFTW bug has been around for a while. Issue 213 is a
> duplicate of issue 182 from a year+ ago.

I wonder if the fix is similar to the problem mentioned for AVX in the
3.3.8 release notes:

http://www.fftw.org/release-notes.html

Philip

> 
> https://github.com/FFTW/fftw3/issues/182
> 
> On Ubuntu 20.04 armhf, they're just compiling the FFTW package without
> NEON enabled.
> 
> Ron
> 
> On 12/6/20 06:27, Ben Magistro via USRP-users wrote:
>> Issue appears to be with the compiler that is included in Zeus (gcc
>> 9.x vs 8.x) and an interaction with fftw. There is an open issue with
>> fftw (https://github.com/FFTW/fftw3/issues/213) and a request to the
>> yocto folks to request they consider adding back gcc-8.3 to zeus +
>> dunfell (https://bugzilla.yoctoproject.org/show_bug.cgi?id=14144)
>> until this can be better resolved.  I think data point 3 confirms this
>> as I did not include options to enable neon when I compiled.
>>
>> On Wed, Nov 11, 2020 at 1:39 PM Ben Magistro > > wrote:
>>
>>     Adding some more data points.
>>
>>     1) I've been trying to rebuild meta-ettus-v4 with debug enabled
>>     but am hitting an issue with image size and can't seem to get past
>>     that.  It says I should increase `MENDER_STORAGE_TOTAL_SIZE_MB` if
>>     the actual size is larger but increasing this seems to have no
>>     effect.  I am using the ettus docker image for oe-builder with the
>>     command `./meta-ettus/contrib/build_imgs_package.sh e310_sg3
>>     v4.0.0.0`.  For the debug portion I've added a few lines to
>>     `build/conf/local.conf` to add the packages. I'm open to
>>     suggestions to build the image with debug symbols and provide
>>     additional feedback.
>>
>>     2) I put together a simple flowgraph, UHD source --> frequency
>>     xlating fft --> null sink.  This also segfaults, no guarantees
>>     that I got the parameters correct.
>>
>>     3) Since the issues seem to be with fftw, I decided to try
>>     building my own copy of fftw mostly to get debug symbols and
>>     continue troubleshooting.  For this I used `./configure
>>     --enable-debug --enable-shared --enable-threads --enable-float`
>>     and `make CFLAGS="-ggdb"`.  These options are best guesses right
>>     now since I didn't look at the layers to see what parameters it is
>>     using (assuming it is in one of the layers).  Using this build
>>     with `export LD_LIBRARY_PATH=/usr/local/lib/` I do not get a
>>     segfault with gr-ais or the above flowgraph but I also don't get
>>     the expected output which makes me question the parameters I used
>>     to build it.  Output wise I get a string of "D" or "O" to the
>> console.
>>
>>     Thanks
>>
>>     Ben
>>
>>     On Thu, Nov 5, 2020 at 9:22 AM Michael Dickens
>>     mailto:michael.dick...@ettus.com>> wrote:
>>
>>     Hi Ben - This issue has been reported to R internally. If
>>     you wish to create a public-facing UHD issue on our Github
>>     tracker please go ahead & do so, and tag me on it so that we
>>     can keep track of it internally. - MLD
>>
>>     On Wed, Nov 4, 2020 at 11:25 PM Ben Magistro via USRP-users
>>     >     > wrote:
>>
>>     Is anyone else using meta-ettus-v4.0.0.0 yet?  if so, have
>>     you had any issues with libfftw?
>>
>>     Using the image on an E310, adding a single OOT module
>>     (gr-ais) and trying to run an app distributed with it, the
>>     app segfaults.  To further troubleshoot, I added gdb and
>>     it comes back with the following.  I have a separate
>>     development host that has gnuradio 3.8 setup using pybombs
>>     and do not experience this issue there.
>>
>>     Thread 1 "python3" received signal SIGSEGV, Segmentation
>>     fault.
>>     0xb6947836 in ?? () from /usr/lib/libfftw3f.so.3
>>
>>     To compile, I've needed to override PYTHON_EXECUTABLE as
>>     it points to a non-existent path in /home/oe-builder
>>     in /usr/lib/cmake/gnuradio/GnuradioConfig.cmake. To run I
>>     also needed to define LD_EXPORT_PATH pointing to
>>     /usr/local/lib/.
>>
>>     Thanks in advance.
>>     ___
>>     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.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Fwd: E310: Change MAC Address?

[Philip Balister via USRP-users]

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] Zeus build for E300

[Philip Balister via USRP-users]

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

Re: [USRP-users] Fwd: E310: Change MAC Address?

[Philip Balister via USRP-users]

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.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Fwd: E310: Change MAC Address?

[Philip Balister via USRP-users]

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 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.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Fwd: E310: Change MAC Address?

[Philip Balister via USRP-users]

Mine is different, but both seem to be from the National Instruments
block (which is good):

root@ni-e31x-30D280A:~# ifconfig
eth0  Link encap:Ethernet  HWaddr 00:80:2F:25:02:37
  inet addr:192.168.11.152  Bcast:192.168.11.255

I see a warning early in boot about using a MAC address from ROM. I'm
not sure where that came from.

Philip

On 11/25/20 8:36 AM, Andrew Payne via USRP-users wrote:
> -- Forwarded message -
> From: Andrew Payne 
> Date: Wed, Nov 25, 2020 at 8:35 AM
> Subject: Re: [USRP-users] E310: Change MAC Address?
> To: Philip Balister 
> 
> 
> It is: 00:80:2f:19:4c:37
> 
> When is that .patch file ran, is it during compilation of the BSP?  When
> would I see that error message printf("I2C EEPROM MAC address read
> failed\n");?
> 
> How could I experiment with compiling a new BSP with the UHD 3.15
> environment loaded, so then I may insert my own MAC Address or get the i2c
> EEPROM read to work? Do I need
> https://github.com/EttusResearch/meta-ettus
> and
> https://github.com/Xilinx/u-boot-xlnx
> and may be use this guide:
> https://opencpi.github.io/bsp_e310/Ettus_E3xx_Getting_Started_Guide.pdf
> ?
> 
> Thanks,
> Andrew
> 
> 
> On Wed, Nov 25, 2020 at 8:26 AM Philip Balister  wrote:
> 
>> What is that mac address? I'd like to see if it matches mine.
>>
>> If I recall correctly, the mac address is flashed into the i2c eeprom,
>> u-boot is supposed to read that and use it. Factory test should set it
>> up uniquely. But my memories fade. Inspecting the u-boot source might
>> show us 
>>
>>
>> https://github.com/EttusResearch/meta-ettus/blob/zeus/meta-e31x/recipes-bsp/u-boot/files/0001-ni-zynq-Add-support-for-NI-E31x-SG1-SG3-boards.patch#L397
>>
>> I didn't sift through the ifdef's though.
>>
>> Philip
>>
>> On 11/24/20 7:28 PM, Andrew Payne via USRP-users wrote:
>>> Is there a way to change the mac address of my e310s?  I have imaged
>>> several e310s using the image file in
>>> https://files.ettus.com/binaries/cache/e3xx/meta-ettus-v3.15.0.0/, and
>> they
>>> all have the same MAC address.
>>>
>>> On some searching around the web I can see that it is likely that the MAC
>>> address parameter is specified as a U-boot parameter.  I'd like to know
>>> what my options are for changing it.
>>>
>>> Thanks,
>>> Andrew
>>>
>>>
>>> ___
>>> 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.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E310: Change MAC Address?

[Philip Balister via USRP-users]

What is that mac address? I'd like to see if it matches mine.

If I recall correctly, the mac address is flashed into the i2c eeprom,
u-boot is supposed to read that and use it. Factory test should set it
up uniquely. But my memories fade. Inspecting the u-boot source might
show us 

https://github.com/EttusResearch/meta-ettus/blob/zeus/meta-e31x/recipes-bsp/u-boot/files/0001-ni-zynq-Add-support-for-NI-E31x-SG1-SG3-boards.patch#L397

I didn't sift through the ifdef's though.

Philip

On 11/24/20 7:28 PM, Andrew Payne via USRP-users wrote:
> Is there a way to change the mac address of my e310s?  I have imaged
> several e310s using the image file in
> https://files.ettus.com/binaries/cache/e3xx/meta-ettus-v3.15.0.0/, and they
> all have the same MAC address.
> 
> On some searching around the web I can see that it is likely that the MAC
> address parameter is specified as a U-boot parameter.  I'd like to know
> what my options are for changing it.
> 
> Thanks,
> Andrew
> 
> 
> ___
> 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

Re: [USRP-users] USRP E100/E110 linux update

[Philip Balister via USRP-users]

On 11/23/20 6:09 PM, Robin Coxe via USRP-users wrote:
> There is a legacy Ettus E100 github repo that may or may not be useful:
> https://github.com/EttusResearch/ettus_oe

This directory might help with kernel driver archeology:

https://github.com/EttusResearch/ettus_oe/tree/master/recipes/linux

Philip

> 
> This product has been EOL for >5 years, so as Philip points out, the
> institutional memory of it is basically non-existent.
> 
> On Mon, Nov 23, 2020 at 5:22 AM Sébastien DI MERCURIO via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> 
>> Hi Philips,
>>
>> thank you for your answer. I will have a look to your git repository. I'm
>> not very good with linux kernel intrinsics but I will try to have driver
>> work with newer kernel.
>>
>> If I succed, i will post my results.
>>
>> Thank you !
>> Le 23/11/2020 à 14:10, Philip Balister a écrit :
>>
>> On 11/23/20 7:09 AM, Sébastien DI MERCURIO via USRP-users wrote:
>>
>> Hi,
>>
>> I've got several USRP E100/E110 with outdated Linux and Gnuradio
>> software on it. So I decided to build a Yocto image, more up-to-date and
>> succeeded in after several tries.
>> The new image boots and run a reasonable updated version of Linux and
>> Gnuradio.
>>
>> But, because of Ettus proprietary kernel driver, I cannot connect to
>> FPGA and so the board is useless.
>>
>> It's an open driver, just non of us remember how it works. I did find
>> the code:
>> https://github.com/balister/linux-omap-philip
>>
>> The linux DMA architecture has likely changed, so the driver will need
>> work, but the code is out there. Let me know if you have questions, it
>> would be great to see these running. I'll answer as best I can. It has
>> been like 6-7 years since I last looked at it though.
>>
>> Using it like an N-series is likely not possible. The fpga is connected
>> to the Overo via the GPMC (General Purpose Memory Controller).
>>
>> Philip
>>
>>
>> My questions are:
>>
>> - Did someone achieve to get an updated Linux base and Gnuradio
>> software, with working FPGA communications (whatever the method)
>>   - Is it possible to get source code of Ettus kernel driver, as the
>> board is now End-of-life
>>   - Is it possible to enable Ethernet communication pass-throughto
>> FPGA, a bit like in N series, in order to use it over Ethernet(not
>> standalone)
>>
>> Regards!
>>
>> Sebastien
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> .
>>
>>
>>
>> ___
>> USRP-users mailing 
>> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> --
>> [image: INSA Toulouse]
>>
>> *Sébastien DI MERCURIO*
>> *Ingénieur d'étude Systèmes embarqués et IoT*
>> Département GEI
>> Tél. : 05 61 55 98 34
>> dimer...@insa-toulouse.fr
>>
>> INSA Toulouse
>> 135 avenue de Rangueil
>> 31077 Toulouse CEDEX 04
>>
>> *www.insa-toulouse.fr  *
>> ___
>> 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.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Poor Data Rates with the USRP E312

[Philip Balister via USRP-users]

With the downloaded images for UHD-4.0 I saw a couple of things:

1) The CPU clock speed is set for speed grade 1 parts, not speed grade 3.
2) UHD-4.0 hangs after a while at higher data rates, I've also seen this
on a b200.

If there are fixes for these issues, you might get a bit more transfer
rate. Not sure it will get you the speed you need though.

Philip

On 11/22/20 9:20 PM, Joe Crossen wrote:
>  Hi all,
> 
> I'm attempting to use the USRP E312 as a wifi node using the gr-ieee802.11
> module...
> though for now I'm testing basic USRP functionality with a couple of simple
> GNU graphs.
> 
> Here's my setup:
> - the host is an Ubuntu 18.04 virtual machine with a bridged adaptor.
> Firewall disabled.
> - the USRP is the E312, connected via ethernet to the host network.
> - the host and USRP are both running GR3.8 and UHD4.0 (Zeus branch).
> - the host can see the USRP with uhd_usrp_probe.
> - the USRP is running the following GNU graph - UHD:USRP Source -> UDP Sink.
> - host is running the following GNU graph - UDP Source -> QT GUI Sink.
> - all block parameters are default.
> 
> I'm experiencing the following issues:
> 1. For sample rates > ~2Msps, the USRP spams overrun "O" and "D" characters
> (what does the "D" signify?) , regardless of whether the host graph is
> running or not.
> 2. At any sample rate the host graph spams the following message (when the
> USRP graph is running) - "gr::log :WARN: udp_source0 - Too much data;
> dropping packet."
> 
> And a question:
> 3. What sample rates are realistic for this setup, and what are the
> limitations? wifi channels span 20MHz, so I'm hoping to run at 20Msps
> 
> Thanks,
> Joe
> 

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP E100/E110 linux update

[Philip Balister via USRP-users]

On 11/23/20 7:09 AM, Sébastien DI MERCURIO via USRP-users wrote:
> Hi,
> 
> I've got several USRP E100/E110 with outdated Linux and Gnuradio
> software on it. So I decided to build a Yocto image, more up-to-date and
> succeeded in after several tries.
> The new image boots and run a reasonable updated version of Linux and
> Gnuradio.
> 
> But, because of Ettus proprietary kernel driver, I cannot connect to
> FPGA and so the board is useless.

It's an open driver, just non of us remember how it works. I did find
the code:

https://github.com/balister/linux-omap-philip

The linux DMA architecture has likely changed, so the driver will need
work, but the code is out there. Let me know if you have questions, it
would be great to see these running. I'll answer as best I can. It has
been like 6-7 years since I last looked at it though.

Using it like an N-series is likely not possible. The fpga is connected
to the Overo via the GPMC (General Purpose Memory Controller).

Philip

> 
> My questions are:
> 
> - Did someone achieve to get an updated Linux base and Gnuradio
> software, with working FPGA communications (whatever the method)
>   - Is it possible to get source code of Ettus kernel driver, as the
> board is now End-of-life
>   - Is it possible to enable Ethernet communication pass-throughto
> FPGA, a bit like in N series, in order to use it over Ethernet(not
> standalone)
> 
> Regards!
> 
> Sebastien
> 
> 
> 
> 
> 
> 
> 
> 
> 
> .
> 
> 
> 
> ___
> 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

Re: [USRP-users] Building Debug FS Image

[Philip Balister via USRP-users]

The quick answer is switch the bsp layer from

meta-e31x-mender

to meta-e31x

and see what happens. I find I ahve to fiddle a lot with the ettus
builds, so it does help to know OpenEmbedded/Yocto.

Anyone know the status of the clock speed issue I reported a while back?
A quick scan of metta-ettus shows no updates since Sep 13.

Philip

On 11/20/20 10:44 AM, Ben Magistro via USRP-users wrote:
> I'm open to that idea but am not familiar with openembedded/yocto/mender or
> what that process would look like (and the little bit of googling hasn't
> shed enough light yet) so I fall back to the tools that I have found and
> that is the ettus docker container with oe-build (
> https://github.com/EttusResearch/ettus-docker/tree/master/oe-build) and the
> instructions there.  As far as I know I only need the sdimg, but this goes
> back to not being familiar with the build process so I could be off base.
> Looking at the `setup_build_env.sh` script, mender seems to be tied in both
> as a layer and what the image may inherit from.  I don't know if it is as
> simple as removing the references to mender in that file and calling build
> or if that will break the resulting image (technically already broken since
> it segfaults for me -- libfftw see
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2020-November/063062.html)
> but I'd like to know I'm not introducing new problems at the same time I am
> trying to resolve my first problem.
> 
> Ben
> 
> On Thu, Nov 19, 2020 at 5:22 PM Philip Balister  wrote:
> 
>> Build without mender?
>>
>> Philip
>>
>> On 11/19/20 4:51 PM, Ben Magistro via USRP-users wrote:
>>> I've been trying to rebuild meta-ettus (in this case -v4.0.0.0) with
>> debug
>>> enabled but am hitting an issue with image size being larger than an 8GB
>> sd
>>> card and can't seem to get past that.  It says I should increase
>>> `MENDER_STORAGE_TOTAL_SIZE_MB` if the actual size is larger but
>> increasing
>>> this in `local.conf` this seems to have no effect.  I am using the ettus
>>> docker image for oe-builder with the command
>>> `./meta-ettus/contrib/build_imgs_package.sh e310_sg3 v4.0.0.0`.  For the
>>> debug portion I've added a few lines to `build/conf/local.conf` to add
>> the
>>> packages.  Anyone know how to increase the total storage size so that it
>>> can build the image?
>>>
>>> Thanks in advance.
>>>
>>>
>>> ___
>>> 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.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Building Debug FS Image

[Philip Balister via USRP-users]

Build without mender?

Philip

On 11/19/20 4:51 PM, Ben Magistro via USRP-users wrote:
> I've been trying to rebuild meta-ettus (in this case -v4.0.0.0) with debug
> enabled but am hitting an issue with image size being larger than an 8GB sd
> card and can't seem to get past that.  It says I should increase
> `MENDER_STORAGE_TOTAL_SIZE_MB` if the actual size is larger but increasing
> this in `local.conf` this seems to have no effect.  I am using the ettus
> docker image for oe-builder with the command
> `./meta-ettus/contrib/build_imgs_package.sh e310_sg3 v4.0.0.0`.  For the
> debug portion I've added a few lines to `build/conf/local.conf` to add the
> packages.  Anyone know how to increase the total storage size so that it
> can build the image?
> 
> Thanks in advance.
> 
> 
> ___
> 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

Re: [USRP-users] uhd_fft hangs with uhd 4.0 file system at higher rates

[Philip Balister via USRP-users]

Anyone else seeing this?

Philip

On 10/10/20 10:18 AM, Philip Balister via USRP-users wrote:
> I setup the an e310 with the file system from:
> 
> https://files.ettus.com/binaries/cache/e3xx/meta-ettus-v4.0.0.0/
> 
> And installed uhd-4.0 + gnuradio 3.8.2 on a desktop.
> 
> running uhd_fft on the desktop finds the e310 and basically works, but
> at a sample rate of 3e6, uhd_fft hangs after say "10 minutes". I see a
> handful of O's. Not linked to the hang.
> 
> If I reduce the sample rate to 1e6, uhd_fft ran overnight.
> 
> There was also some discussion in #gnuradio that indicates the b205 mini
> shows a similar issue, but I haven't confirmed this personally.
> 
> Philip
> 
> ___
> 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

Re: [USRP-users] Cross-Compile Issues with E320

[Philip Balister via USRP-users]

On 10/14/20 6:00 AM, Martin Braun via USRP-users wrote:
> A quick reminder that
> 
> uhd_images_downloader -t e320 -t sdk
> 
> will download the corresponding SDK for your UHD version even when the link
> Michael provided is no longer accurate.

Installing uhd on a machine just to figure out a download link seems
excessive. Can you publish direct links in a form that do not go stale?

Philip

> 
> M
> 
> On Mon, 12 Oct 2020, 17:48 Michael Dickens via USRP-users, <
> usrp-users@lists.ettus.com> wrote:
> 
>> Hi Mark - You need to use a more recent SDK for the cross-build. Here are
>> the SDKs for the 2 most recent UHD releases. I hope this helps! - MLD
>>
>> <
>> https://files.ettus.com/binaries/cache/e3xx/meta-ettus-v3.15.0.0/e3xx_e320_sdk_default-v3.15.0.0.zip
>>>
>> <
>> https://files.ettus.com/binaries/cache/e3xx/meta-ettus-v4.0.0.0/e3xx_e320_sdk_default-v4.0.0.0.zip
>>>
>>
>>
>> On Mon, Oct 12, 2020 at 10:47 AM Andrews, Mark J. via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello,
>>>
>>> I am trying to cross-compile UHD on an E320 with the OE SDK, but I cannot
>>> get past the cmake step due to multiple errors.  On the host PC, I am able
>>> to install the SDK and source the environment variable without issues.
>>> When I go to build UHD, the first error is that the CMakeLists.txt file for
>>> UHD 3.15 has a minimum CMake version of 3.5.1, but the OE SDK cmake is
>>> version 2.8.12.2 (my host PC is version 3.18.4).  I manually edited the
>>> CMakeLists.txt to accept the older version of CMake, but then it has a
>>> boost version error and cannot find several python packages (platform,
>>> mako, requests, numpy).  I again edited it for the Boost version, but it
>>> still can't find the python packages.  Do I need to somehow install all the
>>> UHD dependencies in the OE SDK paths after installing it?  Or am I doing
>>> something else wrong?
>>>
>>> I also tried running "import sys" to see the Python path configuration
>>> and the "program name", "sys._base_executable", and "sys.executable" are
>>> all pointing to "/usr/bin/python3" instead of the
>>> "/home/~/oe/sysroots/x86_64-oesdk-linux" path.  Not sure if that's part of
>>> the problem or not, but it seemed suspicious.  The cmake and import sys
>>> outputs are copied below.
>>>
>>>
>>> ===
>>> cmake -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake
>>> -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_E300=ON ..
>>>
>>> -- Configuring the Python interpreter...
>>> -- Manually determining build Python version...
>>> ImportError: No module named site
>>> -- Python interpreter:
>>> /home/~/oe/sysroots/x86_64-oesdk-linux/usr/bin/python Version:
>>> -- Override with: -DPYTHON_EXECUTABLE=
>>> -- Manually determining runtime Python version...
>>> ImportError: No module named site
>>> -- Python runtime interpreter:
>>> /home/~/oe/sysroots/x86_64-oesdk-linux/usr/bin/python Version:
>>> -- Override with: -DRUNTIME_PYTHON_EXECUTABLE=
>>> -- Finding Python Libraries...
>>> CMake Warning (dev) at cmake/Modules/UHDPython.cmake:168 (find_package):
>>>   Ignoring EXACT since no version is requested.
>>> Call Stack (most recent call first):
>>>   cmake/Modules/UHDVersion.cmake:9 (include)
>>>   cmake/Modules/UHDPackage.cmake:9 (include)
>>>   CMakeLists.txt:103 (include)
>>> This warning is for project developers.  Use -Wno-dev to suppress it.
>>>
>>> -- Python Libraries:
>>> /home/~/oe/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/lib/
>>> libpython2.7.so
>>> -- Python include directories:
>>> /home/`/oe/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/python2.7
>>> -- Working off of feature or development branch. Updating version number.
>>> ImportError: No module named site
>>> ImportError: No module named site
>>> ImportError: No module named site
>>> -- Using UHD Images Directory: /usr/share/uhd/images
>>> -- Build type not specified: defaulting to release.
>>> --
>>> -- Configuring Boost C++ Libraries...
>>> --
>>> -- Checking for Boost version 1.57 or greater
>>> --   Looking for required Boost components...
>>> -- Disabling boost::asio use of std::string_view
>>> --   Boost version: 1.57.0
>>> --   Boost include directories:
>>> /home/~/oe/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include
>>> --   Boost library directories:
>>> /home/~/oe/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/lib
>>> --   Boost libraries:
>>> 

Re: [USRP-users] Ettus E320 & PetaLinux

[Philip Balister via USRP-users]

On 10/13/20 1:34 AM, Turner, Ben via USRP-users wrote:
> Martin,
> 
> Thank you for your reply.
> 
> Unfortunately simply modifying the filesystem is not enough - I need to be 
> able to customise u-boot and the kernel. As it is a Xilinx based system I was 
> under the impression that PetaLinux was the sensible approach and I seem to 
> be most of the way there, with the exception being this FSBL error and the 
> generated u-boot not outputting to the serial terminal.
> 
> By saying you are unable to help with PetaLinux issues, are you implying you 
> are able to help with another mechanism for generating the FSBL, u-boot and 
> kernel? Or are you stating that you flat out refuse to help with issues 
> related to generating these binaries?

I can't speak for NI, but Petalinux is almost always not the sensible
approach :)

I would go about creating my own layer and using the bbappend mechanism
to modify the meta-ettus kernel and u-boot recipes. with your changes
included as patches against the NI sources.

Here are some starting points. Unfortunately, meta-ettus is carrying an
annoying number of layers and you need to really dig to find all the
recipes appending the base recipe :(

https://github.com/EttusResearch/meta-ettus/tree/thud/meta-neon/recipes-bsp/u-boot
https://github.com/EttusResearch/meta-ettus/tree/thud/meta-neon/recipes-kernel/linux

You likely want things from the zeus branch, I just linked the default
view on github. In case it isn't clear e320 is neon.

Philip

> 
> Regards,
> 
> Ben
> 
> From: USRP-users  On Behalf Of Martin 
> Braun via USRP-users
> Sent: 12 October 2020 09:59
> Cc: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] Ettus E320 & PetaLinux
> 
> Ben,
> 
> we can't provide you with PetaLinux support, but you can rebuild our OE-Based 
> filesystems. For novice OpenEmbedded users, we provide a Docker image (here's 
> a link from the E320 manual: 
> https://github.com/EttusResearch/ettus-docker/blob/master/oe-build/README.md),
>  and if you're more of an expert, you can go straight to our manifests 
> (https://github.com/EttusResearch/oe-manifests)
>  which contain references to all the layers used to build our filesystems.
> 
> A bunch of USRP users build custom filesystems (with their own software etc.) 
> and use this workflow.
> 
> Cheers,
> M
> 
> 
> Roke Manor Research Limited, Romsey, Hampshire, SO51 0ZN, United Kingdom.Part 
> of the Chemring Group. 
> Registered in England & Wales. Registered No: 00267550
> http://www.roke.co.uk
> ___
> The information contained in this e-mail and any attachments is proprietary 
> to Roke Manor Research Limited and 
> must not be passed to any third party without permission. This communication 
> is for information only and shall 
> not create or change any contractual relationship.
> 
> On Mon, Oct 12, 2020 at 10:43 AM Turner, Ben via USRP-users 
> mailto:usrp-users@lists.ettus.com>> wrote:
> I am attempting to build PetaLinux targeting the E320. As there is no BSP 
> (that I can find) for the E320, I have attempted to generate a hardware 
> description file from the Vivado project that can be created from the Ettus 
> FPGA github repository.
> 
> I successfully created the Vivado project by running make E320_1G GUI=1, ran 
> synthesis and implementation and then exported the .hdf. I then configured 
> the PetaLinux project:
> 
> petalinux-config –get-hw-description=
> 
> And attempted to build it:
> 
> petalinux-build
> 
> It is during this build stage that I get the following error:
> 
> NOTE: Executing RunQueue Tasks
> ERROR: fsbl-2018.3+gitAUTOINC+56f3da2afb-r0 do_configure: Function failed: 
> do_configure (log file is located at 
> /home/devel/Projects/e320/plnx-2018.3-e320/build/tmp/work/plnx_zynq7-xilinx-linux-gnueabi/fsbl/2018.3+gitAUTOINC+56f3da2afb-r0/temp/log.do_configure.18082)
> ERROR: Logfile of failure stored in: 
> /home/devel/Projects/e320/plnx-2018.3-e320/build/tmp/work/plnx_zynq7-xilinx-linux-gnueabi/fsbl/2018.3+gitAUTOINC+56f3da2afb-r0/temp/log.do_configure.18082
> Log data follows:
> | DEBUG: Executing shell function do_configure
> | MISC_ARG is  -yamlconf 
> /home/devel/Projects/e320/plnx-2018.3-e320/build/tmp/work/plnx_zynq7-xilinx-linux-gnueabi/fsbl/2018.3+gitAUTOINC+56f3da2afb-r0/fsbl.yaml
> | APP_ARG is  -app "Zynq FSBL"
> | Using xsct from: /opt/Xilinx/PetaLinux/2018.3/tools/xsct/SDK/2018.3/bin/xsct
> | cmd is: xsct -sdx -nodisp 
> /home/devel/Projects/e320/plnx-2018.3-e320/build/tmp/work/plnx_zynq7-xilinx-linux-gnueabi/fsbl/2018.3+gitAUTOINC+56f3da2afb-r0/app.tcl
>  -ws 
> /home/devel/Projects/e320/plnx-2018.3-e320/build/tmp/work/plnx_zynq7-xilinx-linux-gnueabi/fsbl/2018.3+gitAUTOINC+56f3da2afb-r0/build
>  -pname fsbl -rp 
> 

[USRP-users] uhd_fft hangs with uhd 4.0 file system at higher rates

[Philip Balister via USRP-users]

I setup the an e310 with the file system from:

https://files.ettus.com/binaries/cache/e3xx/meta-ettus-v4.0.0.0/

And installed uhd-4.0 + gnuradio 3.8.2 on a desktop.

running uhd_fft on the desktop finds the e310 and basically works, but
at a sample rate of 3e6, uhd_fft hangs after say "10 minutes". I see a
handful of O's. Not linked to the hang.

If I reduce the sample rate to 1e6, uhd_fft ran overnight.

There was also some discussion in #gnuradio that indicates the b205 mini
shows a similar issue, but I haven't confirmed this personally.

Philip

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E300 sg3 images with uhd 4.0

[Philip Balister via USRP-users]

Ping? Anyone noticed sg3 units running slower with the uhd 4.0 image?

Philip

On 9/24/20 1:28 PM, Philip Balister via USRP-users wrote:
> I booted an image from:
> 
> https://files.ettus.com/binaries/cache/e3xx/meta-ettus-v4.0.0.0/
> 
> on a sg3 unit. The BogoMIPS display suggests the clocks are set to what
> I expect for a sg1 unit though. I couldn't find any knobs in /sys or
> /proc. I compared with the ancient release-4 image and that has the
> number of BogoMIPS expected from that unit.
> 
> Anyone at Ettus have any insite into how cpu clock speed is handled with
> that image. Diffing the ps7 files didn't show many diffs in clock setup.
> (And they looked like they came from a source besides vivado)
> 
> Philip
> 
> ___
> 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] E300 sg3 images with uhd 4.0

[Philip Balister via USRP-users]

I booted an image from:

https://files.ettus.com/binaries/cache/e3xx/meta-ettus-v4.0.0.0/

on a sg3 unit. The BogoMIPS display suggests the clocks are set to what
I expect for a sg1 unit though. I couldn't find any knobs in /sys or
/proc. I compared with the ancient release-4 image and that has the
number of BogoMIPS expected from that unit.

Anyone at Ettus have any insite into how cpu clock speed is handled with
that image. Diffing the ps7 files didn't show many diffs in clock setup.
(And they looked like they came from a source besides vivado)

Philip

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] GPS Antenna for E310

[Philip Balister via USRP-users]

On 9/4/20 11:06 AM, Marcus D Leech wrote:
> Any 5V active GPS antenna will do. They’re a dime a dozen these days. Get 
> two. 

Thanks, I wish I had. In fact I probably did and can't remember where
the other is ...

Philip

> 
> Sent from my iPhone
> 
>> On Sep 4, 2020, at 11:03 AM, Philip Balister via USRP-users 
>>  wrote:
>>
>> Is there a recommended GPA antenna for the E310? I had one but the dof
>> ate it :(
>>
>> Philip
>>
>> ___
>> 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] GPS Antenna for E310

[Philip Balister via USRP-users]

Is there a recommended GPA antenna for the E310? I had one but the dof
ate it :(

Philip

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] gr-ettus / GNU Radio 3.8

[Philip Balister via USRP-users]

On 8/19/20 10:57 PM, Jonathon Pendlum via USRP-users wrote:
> Hi Sam,
> 
> That branch is still a work in progress.

Any estimate when it will be ready?

Philip

> 
> Jonathon
> 
> On Sun, Aug 9, 2020 at 6:12 PM Carey, Samuel Craig via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> 
>> Howdy,
>>
>>
>>
>> I see there’s a gr-ettus maint-3.8 branch for adding GNU Radio 3.8
>> support, which seems to be finished as of this commit:
>>
>>
>> https://github.com/EttusResearch/gr-ettus/commit/b69260655e974786ea6e611bd91ab578b13ec72a
>>
>>
>>
>> Is this branch good to go?
>>
>> Are there any known drawbacks?
>>
>> Will I theoretically be able to use this in the context of rfnoc/e310
>> cross-compiling, etc.?
>>
>>
>>
>> I ask because there are a couple open issue about 3.8 without any replies
>> (#37, #46), so I’m wary of investing time if it’s not ready.
>>
>>
>>
>> Thanks,
>>
>> Sam
>> ___
>> 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.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Current state of GNURadio on the E320

[Philip Balister via USRP-users]

Any tips for getting GNU Radio on the E320? I see a zeus branch. Anyone
built that?

Philip

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Remote Power Cycle of the E310/E312

[Philip Balister via USRP-users]

Is there a setting you can tweak to change this behavior?

Philip

On 4/28/20 5:20 AM, Marcus Müller via USRP-users wrote:
> Hey Joshua,
> 
> the firmware can be found in the UHD source code repo under
> firmware/e310/battery. If I remember correctly, you'll need avr-gcc,
> avr-libc and avrdude (the latter only for flashing using the `make
> install` target).
> 
> Note that the software is a bit tight on space on the Attiny88 – so
> maybe try to avoid integrating too many features without removing
> anything ;)
> 
> Best regards,
> Marcus
> 
> On 27.04.20 16:20, Joshua Monson via USRP-users wrote:
>> Hello,
>>
>>  
>>
>> Under the current (COVID19) circumstances, I am having to use my
>> E310/E312’s remotely. I have them connected to a remotely controllable
>> PDU that allows me to power cycle the E310 devices when they
>> occasionally crash (as long as they have been switched on once).
>> However, the battery-backed E312s do not respond to the power-cycling in
>> the same way the E310s do and thus I am cannot power-cycle them. We
>> disconnected the battery and tested the remote power-cycling to no
>> avail. Is there a version of the AVR code that would allow me to disable
>> the battery and use the input power to power-cycle the device? (I could
>> go into the office to reflash the AVR). Alternatively, could I recompile
>> the AVR code with different parameters to force this behavior?
>>
>>  
>>
>> Thanks,
>>
>>
>> Josh
>>
>>  
>>
>>
>> ___
>> 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.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E310 Cross-compiling UHD / GNU Radio (volk?)

[Philip Balister via USRP-users]

Volk needs to be told to use thumb mode with asm. This flag isn't making
it all the way into the cmake for some cases. I also have a suspicion
the issue may go away in the current toolchains. Various patches have
been around for to fix this, take a look at the volk commit history.

Philip

On 4/2/20 4:45 PM, Jeff S via USRP-users wrote:
> I had a problem with the initial build environment when setting up my 
> environment for the E310.  Up to now, I have been able to get the UHD 
> cross-compiled, a new image for the microSD card built, and checked up to the 
> # uhd_usrp_probe step on the E310 (from 
> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source)
>  with success.
> 
> I am now at the point where I am Cross-Compiling GNU Radio.  I have been 
> using e3xx_e310_sdk_default-v3.15.0.0.zip, and at the point where I am 
> building GNU Radio, I am getting an error:
> 
> 
> Scanning dependencies of target volk_obj
> [  3%] Building ASM object 
> volk/lib/CMakeFiles/volk_obj.dir/__/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s.o
> /home/sdr/sdr/e310/rfnoc/src/gnuradio/volk/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:
>  Assembler messages:
> /home/sdr/sdr/e310/rfnoc/src/gnuradio/volk/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:9:
>  Error: selected processor does not support `pld [r1:128]' in ARM mode
> /home/sdr/sdr/e310/rfnoc/src/gnuradio/volk/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:20:
>  Error: selected processor does not support `pld [r4:128]' in ARM mode
> /home/sdr/sdr/e310/rfnoc/src/gnuradio/volk/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:44:
>  Error: selected processor does not support `sxth r6,r6' in ARM mode
> volk/lib/CMakeFiles/volk_obj.dir/build.make:1572: recipe for target 
> 'volk/lib/CMakeFiles/volk_obj.dir/__/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s.o'
>  failed
> make[2]: *** 
> [volk/lib/CMakeFiles/volk_obj.dir/__/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s.o]
>  Error 1
> CMakeFiles/Makefile2:220: recipe for target 
> 'volk/lib/CMakeFiles/volk_obj.dir/all' failed
> make[1]: *** [volk/lib/CMakeFiles/volk_obj.dir/all] Error 2
> Makefile:162: recipe for target 'all' failed
> make: *** [all] Error 2
> 
> 
> I have searched unsuccessfully for an answer to this one, and figure it's 
> some sort of configuration error that I missed.  The commands I am using are:
> 
> $ cd ~/sdr/e310/rfnoc/oe/
> $ source ./environment-setup-cortexa9t2hf-neon-oe-linux-musleabi
> $ cd ~/sdr/e310/rfnoc/src/gnuradio
> $ mkdir build-arm
> $ cd build-arm/
> $ cmake -Wno-dev 
> -DCMAKE_TOOLCHAIN_FILE=~/sdr/e310/rfnoc/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
>  -DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF -DENABLE_GR_DTV=OFF 
> -DENABLE_GR_ATSC=OFF -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ../
> $ make
> 
> Any obvious issues?  Could there be something cached from the earlier build 
> in the directions?  I'll post the cmake output below my signature to keep it 
> out of the way.
> 
> Thanks,
> Jeff
> 
> 
> 
> $ cmake -Wno-dev 
> -DCMAKE_TOOLCHAIN_FILE=~/sdr/e310/rfnoc/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
>  -DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF -DENABLE_GR_DTV=OFF 
> -DENABLE_GR_ATSC=OFF -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ../
> -- The CXX compiler identification is GNU 8.2.0
> -- The C compiler identification is GNU 8.2.0
> -- Check for working CXX compiler: 
> /home/sdr/sdr/e310/rfnoc/oe/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-musleabi/arm-oe-linux-musleabi-g++
> -- Check for working CXX compiler: 
> /home/sdr/sdr/e310/rfnoc/oe/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-musleabi/arm-oe-linux-musleabi-g++
>  -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Check for working C compiler: 
> /home/sdr/sdr/e310/rfnoc/oe/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-musleabi/arm-oe-linux-musleabi-gcc
> -- Check for working C compiler: 
> /home/sdr/sdr/e310/rfnoc/oe/sysroots/x86_64-oesdk-linux/usr/bin/arm-oe-linux-musleabi/arm-oe-linux-musleabi-gcc
>  -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Build type not specified: defaulting to release.
> -- Build type set to Release.
> -- Found Git: /usr/bin/git
> -- Extracting version information from git describe...
> -- Performing Test HAVE_VISIBILITY_HIDDEN
> -- Performing Test HAVE_VISIBILITY_HIDDEN - Success
> -- Performing Test HAVE_WARN_SIGN_COMPARE
> -- Performing Test HAVE_WARN_SIGN_COMPARE - Success
> -- Performing Test HAVE_WARN_ALL
> -- Performing Test HAVE_WARN_ALL - Success
> -- Performing Test HAVE_WARN_NO_UNINITIALIZED
> -- Performing Test HAVE_WARN_NO_UNINITIALIZED - Success
> -- Compiler Version: 

Re: [USRP-users] [EXT] Re: Question about the IMU (MPU-9150) on the E310

[Philip Balister via USRP-users]

This might help:

https://github.com/EttusResearch/meta-ettus/blob/fido/e300-bsp/recipes-suppport/rtimulib/rtimulib/ettus-e300/RTIMULib.ini

At some point the rtimulib source moved around and was a bit funny to
build and was dropped from the image. The comment about probing and the
ini file made me think to look at the old build to see how I handled it.

Philip

On 11/18/19 2:03 PM, Samuel Prager via USRP-users wrote:
> Hi Isaac,
> 
> Yes this is exactly the error we had seen before. I was able to reproduce 
> these errors on our E312.
> 
> For some reason it looks like the auto discover isn’t working properly (not 
> finding correct device type and not assigning correct I2c bus or 
> I2CSlaveAddress).
> 
> You should be able to fix the issue by following these steps:
> 
> 1) root@ettus-e3xx-sg3:~# mv /etc/RTIMULib.ini /etc/RTIMULib.ini.backup
> 
> This will force creation of a new /etc/RTIMULib.ini file
> 
> 2) Now run the program. You should see the following output (as before):
> 
> root@ettus-e3xx-sg3:~# E312IMUTest
> Do something here with example option input: for example
> Settings file not found. Using defaults and creating settings file
> Failed to open I2C bus 1
> Failed to open SPI bus 0, select 0
> No IMU detected
> Using fusion algorithm RTQF
> No IMU found
> 
> 3) In the newly created /etc/RTIMULib.ini file make the following changes:
> 
> IMUType=2
> 
> #
> # Fusion type type -
> #   0 - Null. Use if only sensor data required without fusion
> #   1 - Kalman STATE4
> #   2 - RTQF
> FusionType=2
> 
> #
> # Is bus I2C: 'true' for I2C, 'false' for SPI
> BusIsI2C=true
> 
> #
> # I2C Bus (between 0 and 7)
> I2CBus=0
> 
> #
> # SPI Bus (between 0 and 7)
> SPIBus=0
> 
> #
> # SPI select (between 0 and 1)
> SPISelect=0
> 
> #
> # SPI Speed in Hz
> SPISpeed=50
> 
> #
> # I2C slave address (filled in automatically by auto discover)
> I2CSlaveAddress=105
> 
> 
> 5) You should now be able to run the program successfully (If you get I2C 
> read errors, try restarting the E310. Everything should work afterwards).
> 
> For reference, I have included my complete /etc/RTIMULib.ini file:
> 
> root@ettus-e3xx-sg3:~# cat /etc/RTIMULib.ini
> # #
> #
> # RTIMULib settings file
> 
> # General settings
> #
> 
> # IMU type -
> #   0 = Auto discover
> #   1 = Null (used when data is provided from a remote IMU
> #   2 = InvenSense MPU-9150
> #   3 = STM L3GD20H + LSM303D
> #   4 = STM L3GD20 + LSM303DLHC
> #   5 = STM LSM9DS0
> #   6 = STM LSM9DS1
> #   7 = InvenSense MPU-9250
> #   8 = STM L3GD20H + LSM303DLHC
> #   9 = Bosch BMX055
> #   10 = Bosch BNX055
> IMUType=2
> 
> #
> # Fusion type type -
> #   0 - Null. Use if only sensor data required without fusion
> #   1 - Kalman STATE4
> #   2 - RTQF
> FusionType=2
> 
> #
> # Is bus I2C: 'true' for I2C, 'false' for SPI
> BusIsI2C=true
> 
> #
> # I2C Bus (between 0 and 7)
> I2CBus=0
> 
> #
> # SPI Bus (between 0 and 7)
> SPIBus=0
> 
> #
> # SPI select (between 0 and 1)
> SPISelect=0
> 
> #
> # SPI Speed in Hz
> SPISpeed=50
> 
> #
> # I2C slave address (filled in automatically by auto discover)
> I2CSlaveAddress=105
> 
> #
> # IMU axis rotation - see RTIMU.h for details
> AxisRotation=0
> 
> # Pressure sensor type -
> #   0 = Auto discover
> #   1 = Null (no hardware or don't use)
> #   2 = BMP180
> #   3 = LPS25H
> #   4 = MS5611
> #   5 = MS5637
> PressureType=0
> 
> #
> # I2C pressure sensor address (filled in automatically by auto discover)
> I2CPressureAddress=0
> 
> # Humidity sensor type -
> #   0 = Auto discover
> #   1 = Null (no hardware or don't use)
> #   2 = HTS221
> #   3 = HTU21D
> HumidityType=0
> 
> #
> # I2C humidity sensor address (filled in automatically by auto discover)
> I2CHumidityAddress=0
> 
> # #
> #
> 
> # Compass calibration settings
> CompassCalValid=false
> CompassCalMinX=0.00
> CompassCalMinY=0.00
> CompassCalMinZ=0.00
> CompassCalMaxX=0.00
> CompassCalMaxY=0.00
> CompassCalMaxZ=0.00
> 
> # #
> #
> 
> # Compass adjustment settings
> # Compass declination is in radians and is subtracted from calculated heading
> compassAdjDeclination=0.00
> 
> # #
> #
> 
> # Compass ellipsoid calibration
> compassCalEllipsoidValid=false
> compassCalOffsetX=0.00
> compassCalOffsetY=0.00
> compassCalOffsetZ=0.00
> compassCalCorr11=1.00
> compassCalCorr12=0.00
> compassCalCorr13=0.00
> compassCalCorr21=0.00
> compassCalCorr22=1.00
> compassCalCorr23=0.00
> compassCalCorr31=0.00
> compassCalCorr32=0.00
> compassCalCorr33=1.00
> 
> # #
> #
> 
> # Accel calibration
> AccelCalValid=false
> AccelCalMinX=0.00
> AccelCalMinY=0.00
> 

Re: [USRP-users] Musl default for future E320 builds?

[Philip Balister via USRP-users]

On 11/7/19 9:35 PM, Philip Balister via USRP-users wrote:
> I'm working on getting gnuradio on the E#@) and am testing the thud
> branch of meta-ettus (Which is still a bit dated :(). I noticed in:
> 
> https://github.com/EttusResearch/meta-ettus/commit/14ae3db3d794c90b40a16639e63d5a2cd58c1693#diff-e349d3011c378939978585aa9c11e201
> 
> the default c library changed from glibc to musl. Any particular reason
> for this switch? Has anyone built gnuradio with musl yet?

To answer my own question, yes gnuradio builds with musl :)

At least "python -c "import gnuradio" doesn't error.

Unfortunately, as we discussed at the OpenEmbedded meeting last week,
the combination of musl and systemd has some issues that leads to
security concerns of that combination of PID 1 and c library :(

Philip

> 
> Philip
> 
> ___
> 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] Musl default for future E320 builds?

[Philip Balister via USRP-users]

I'm working on getting gnuradio on the E#@) and am testing the thud
branch of meta-ettus (Which is still a bit dated :(). I noticed in:

https://github.com/EttusResearch/meta-ettus/commit/14ae3db3d794c90b40a16639e63d5a2cd58c1693#diff-e349d3011c378939978585aa9c11e201

the default c library changed from glibc to musl. Any particular reason
for this switch? Has anyone built gnuradio with musl yet?

Philip

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Problems when Running UHD_3.14.1 Examples on E310

[Philip Balister via USRP-users]

On 11/4/19 9:25 PM, z...@c3commsystems.com wrote:
> Philip,
> 
> Thanks for the response. That’s what we did to get through the issue. 
> 
> But is it what we supposed to do, i.e., edit these UHD provided python 
> scripts manually?

No, hopefully someone from Ettus entered this into the bug tracker.

Philip

> 
> Thanks,
> Zhongren
> 
>> On Nov 4, 2019, at 2:27 PM, Philip Balister  wrote:
>>
>> On 11/4/19 5:04 PM, zcao--- via USRP-users wrote:
>>> Hi, 
>>>
>>> We are trying to run UHD examples on E310. The process we took are as the 
>>> following.
>>>
>>> 1. Flash a fresh SDcard using the dev image located at 
>>> http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg3/ 
>>> 
>>>
>>> 2. Cross-compile UHD source code on a development machine and install the 
>>> build on to the E310 device using sshfs. Note that this is a different from 
>>> what is proposed in AN-311. We installed UHD 3.14 onto the device directly.
>>>
>>> 3. Running /usr/bin/uhd_find_devices, we got the following output, looks 
>>> normal.
>>>
>>> [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700; 
>>> UHD_3.14.1.1-0-g0347a6d8
>>> --
>>> -- UHD Device 0
>>> --
>>> Device Address:
>>>serial: 31819A1
>>>name: 
>>>node: /dev/axi_fpga
>>>product: E3XX SG3
>>>type: e3x0
>>>
>>>
>>> However, we ran into the following problems, which seem to be related.
>>>
>>> 1. We cannot run /usr/bin/uhd_usrp_probe, because of the FPGA 
>>> compatibility. Specifically, the error messages are
>>>
>>> Error: RuntimeError: Expected FPGA compatibility number 255.x, but got 14.0:
>>> The FPGA build is not compatible with the host code build.
>>> Please run:
>>>
>>> "/usr/lib/uhd/utils/uhd_images_downloader.py"
>>>
>>>
>>> 2. But running the above python script gives us the following error 
>>> messages.
>>>
>>> -sh: /usr/lib/uhd/utils/uhd_images_downloader.py: 
>>> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/python2: bad 
>>> interpreter: No such file or directory/
>>
>> Look at the script /usr/lib/uhd/utils/uhd_images_downloader.py and edit
>> the #!/bin/fo/bar/python to something reasonable.
>>
>> Philip
>>
>>>
>>>
>>> Note that the python script is looking for the SDK, which should be on the 
>>> development machine, instead of the device itself.
>>>
>>> Would really appreciate it if anyone knows how to handle above issues in 
>>> E310 device itself?
>>>
>>> Thanks,
>>> Arnold
>>>
>>>
>>>
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
> 
> Arnold Z. Cao, Ph.D.
> 
> C-3 Comm Systems, LLC
> 3100 Clarendon Blvd., Suite 200
> Arlington, VA 22201
> Phone: (703) 829-0588
> Email : z...@c3commsystems.com 
> 

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Problems when Running UHD_3.14.1 Examples on E310

[Philip Balister via USRP-users]

On 11/4/19 5:04 PM, zcao--- via USRP-users wrote:
> Hi, 
> 
> We are trying to run UHD examples on E310. The process we took are as the 
> following.
> 
> 1. Flash a fresh SDcard using the dev image located at 
> http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg3/ 
> 
> 
> 2. Cross-compile UHD source code on a development machine and install the 
> build on to the E310 device using sshfs. Note that this is a different from 
> what is proposed in AN-311. We installed UHD 3.14 onto the device directly.
> 
> 3. Running /usr/bin/uhd_find_devices, we got the following output, looks 
> normal.
> 
> [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700; 
> UHD_3.14.1.1-0-g0347a6d8
> --
> -- UHD Device 0
> --
> Device Address:
> serial: 31819A1
> name: 
> node: /dev/axi_fpga
> product: E3XX SG3
> type: e3x0
> 
> 
> However, we ran into the following problems, which seem to be related.
> 
> 1. We cannot run /usr/bin/uhd_usrp_probe, because of the FPGA compatibility. 
> Specifically, the error messages are
> 
> Error: RuntimeError: Expected FPGA compatibility number 255.x, but got 14.0:
> The FPGA build is not compatible with the host code build.
> Please run:
> 
>  "/usr/lib/uhd/utils/uhd_images_downloader.py"
> 
> 
> 2. But running the above python script gives us the following error messages.
> 
> -sh: /usr/lib/uhd/utils/uhd_images_downloader.py: 
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/python2: bad 
> interpreter: No such file or directory/

Look at the script /usr/lib/uhd/utils/uhd_images_downloader.py and edit
the #!/bin/fo/bar/python to something reasonable.

Philip

> 
> 
> Note that the python script is looking for the SDK, which should be on the 
> development machine, instead of the device itself.
> 
> Would really appreciate it if anyone knows how to handle above issues in E310 
> device itself?
> 
> Thanks,
> Arnold
> 
> 
> 
> ___
> 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

Re: [USRP-users] cannot gr-uhd in poky

[Philip Balister via USRP-users]

Ettus seems to only maintain the uhd recipe for their embedded products.
You can find it in their meta-ettus layer. I'm not sure how easy it is
to add that and build for people using non-embedded USRP's with boards
like the wandboard. I'd love to see a pull request so meta-sdr can fully
support usrp's and things like wandboards etc again.

Philip

On 10/28/19 9:37 AM, Wael Ali wrote:
> Dear all,
> 
> I'm building a new poky yocto image with gnuradio and uhd pre-installed for
> a wandboard, and I'm using meta-sdr (sumo) layer, and I'm bitbaking a
> gnuradio-dev-image.
> And the problem is,
> 1- when I used the default recipes in meta-sdr sumo branch, uhd package
> gives a compilation error.
> 2- then I changed to uhd 3.13 but I kept all recipes in sumo branch as the
> same, after doing this, bitbake gives no errors, but after finishing, I
> didn't find any uhd installed.
> 3- I've tried many things for example,
>  - I add "uhd" to PACKAGECONFIG in gnuradio core recipe.
>  - I've created a new image recipe (gnuradio-custom-image.bb) where
> I manually add uhd and uhd-examples in "CORE_IMAGE_EXTRA_INSTALL".
>  - I changed all meta-sdr to "master" branch and I faced a
> integration problem with other layers as they are all "sumo" branch.
> 4- in all my trails I always get a gnuradio package with gr-uhd missing.
> 
> I hope I was missing something, and it's easy to solve.
> please I need help with this,
> thanks in advance
> 

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] python 2.7 on N310

[Philip Balister via USRP-users]

With all the annoying issues on this list with Ettus Embedded products,
I'm curious if there is any interest in a gofundme for an image that
supports gnuradio and rfnoc without a bunch of screwing around
rebuilding uhd and manually updating sdks?

Philip

On 10/21/19 12:36 PM, Jason Matusiak via USRP-users wrote:
> I am just starting to play with the N310 and I am having issues with some of 
> our flowgraphs that work fine with the X310 and the E320.  The issue seems to 
> be that there seems to be minimal support for python 2.7 for the N310.  Is 
> there a toolchain or anything else I can do to get better support?  Things 
> like threading.py are missing and only in python3.5 for it.
> 
> Thanks.
> ~Jason
> 
> 
> ___
> 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

Re: [USRP-users] E310 GPS time source?

[Philip Balister via USRP-users]

On 10/16/19 10:33 AM, zcao--- via USRP-users wrote:
> Hi,
> 
> UHD lib provides a function, get_time_last_pps(), which suppose to provides 
> the time stamp for the latest PPS right edge. I am wondering what is the 
> source of the time information the above function uses? 
> 
> Specifically, we are aiming at synchronize multiple E310 devices for a TDMA 
> system. Each E310 is standalone and has no network connect to a common NTP 
> server. From the schematics of E310, it seems to me that the GPS receiver 
> chip only provides the PPS output to the FPGA. I didn’t find any hardware 
> support that allows E310 to obtain the time information from GPS, other than 
> the edge of each second. 

I know the E300 can sync NTP time to GPS time. Searching the memory
banks makes me think gpsd is providing the time to ntpd and the pps
driver is doing the pps interface to ntpd.

I don't know about the uhd time though.

Pihlip

> 
> Am I right? If so, what time information the function get_time_last_pps() 
> actually returns? Is there a way to sync the time across multiple standalone 
> E310?
> 
> Thanks,
> Arnold 
> 
> C-3 Comm Systems, LLC
> 3100 Clarendon Blvd., Suite 200
> Arlington, VA 22201
> Phone: (703) 829-0588
> Email : z...@c3commsystems.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.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] cannot load fpga to b205mini from wandboard

[Philip Balister via USRP-users]

On 9/15/19 11:38 AM, Marcus D Leech via USRP-users wrote:
> My guess is the Wandboard doesn’t supply enough power, so it’s getting taken 
> off the bus. 
> 
> Might need one of those Y cables to supply external power. 

Also a good guess, my pi thing has issues with the b205 also.

Philip

> 
> Sent from my iPhone
> 
>> On Sep 15, 2019, at 8:09 AM, Philip Balister via USRP-users 
>>  wrote:
>>
>>> On 9/15/19 7:55 AM, Wael Ali via USRP-users wrote:
>>> Dear all,
>>> please help me with this issue,
>>>
>>> I've built a poky distro. with yocto project for wandboard and uhd package
>>> is pre-installed.
>>>
>>> the problem is, when I tried to use "uhd_usrp_probe"  with (three different
>>> usrp 205mini) I faced the following error
>>>
>>> root@wandboard:~# uhd_usrp_probe
>>> linux; GNU C++ version 7.3.0; Boost_106600; UHD_003.010.002.000-release
>>>
>>> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
>>> -- Detected Device: B205mini
>>> -- Loading FPGA image: /usr/share/uhd/images/usrp_b205mini_fpga.bin...
>>> 39%Error: EnvironmentError: IOError: load_fpga: cannot write bitstream to
>>> FX3 (-4: LIBUSB_ERROR_CODE -4)
>>
>> A quick google suggest error -4 is No device, are you sure the USB is
>> working? Do you seen messages when you insert/remove the b205? What does
>> ls usb say?
>>
>> Philip
>>
>>
>>
>>> root@wandboard:~# uhd_usrp_probe
>>> linux; GNU C++ version 7.3.0; Boost_106600; UHD_003.010.002.000-release
>>>
>>> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
>>> -- Detected Device: B205mini
>>> -- Loading FPGA image: /usr/share/uhd/images/usrp_b205mini_fpga.bin...
>>> 38%Error: EnvironmentError: IOError: load_fpga: cannot write bitstream to
>>> FX3 (-4: LIBUSB_ERROR_CODE -4)
>>> root@wandboard:~# uhd_usrp_probe
>>> linux; GNU C++ version 7.3.0; Boost_106600; UHD_003.010.002.000-release
>>>
>>> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
>>> -- Detected Device: B205mini
>>> -- Loading FPGA image: /usr/share/uhd/images/usrp_b205mini_fpga.bin...
>>> 38%Error: EnvironmentError: IOError: load_fpga: cannot write bitstream to
>>> FX3 (-4: LIBUSB_ERROR_CODE -4)
>>>
>>> As you can see, uhd: 3.10.2
>>> also, I faced the same problem after re-downloading fpga image from ettus
>>> website
>>>
>>> thanks in advance
>>>
>>>
>>> ___
>>> 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.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

Re: [USRP-users] cannot load fpga to b205mini from wandboard

[Philip Balister via USRP-users]

On 9/15/19 7:55 AM, Wael Ali via USRP-users wrote:
> Dear all,
> please help me with this issue,
> 
> I've built a poky distro. with yocto project for wandboard and uhd package
> is pre-installed.
> 
> the problem is, when I tried to use "uhd_usrp_probe"  with (three different
> usrp 205mini) I faced the following error
> 
> root@wandboard:~# uhd_usrp_probe
> linux; GNU C++ version 7.3.0; Boost_106600; UHD_003.010.002.000-release
> 
> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
> -- Detected Device: B205mini
> -- Loading FPGA image: /usr/share/uhd/images/usrp_b205mini_fpga.bin...
> 39%Error: EnvironmentError: IOError: load_fpga: cannot write bitstream to
> FX3 (-4: LIBUSB_ERROR_CODE -4)

A quick google suggest error -4 is No device, are you sure the USB is
working? Do you seen messages when you insert/remove the b205? What does
ls usb say?

Philip



> root@wandboard:~# uhd_usrp_probe
> linux; GNU C++ version 7.3.0; Boost_106600; UHD_003.010.002.000-release
> 
> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
> -- Detected Device: B205mini
> -- Loading FPGA image: /usr/share/uhd/images/usrp_b205mini_fpga.bin...
> 38%Error: EnvironmentError: IOError: load_fpga: cannot write bitstream to
> FX3 (-4: LIBUSB_ERROR_CODE -4)
> root@wandboard:~# uhd_usrp_probe
> linux; GNU C++ version 7.3.0; Boost_106600; UHD_003.010.002.000-release
> 
> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
> -- Detected Device: B205mini
> -- Loading FPGA image: /usr/share/uhd/images/usrp_b205mini_fpga.bin...
> 38%Error: EnvironmentError: IOError: load_fpga: cannot write bitstream to
> FX3 (-4: LIBUSB_ERROR_CODE -4)
> 
> As you can see, uhd: 3.10.2
> also, I faced the same problem after re-downloading fpga image from ettus
> website
> 
> thanks in advance
> 
> 
> ___
> 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

Re: [USRP-users] Pybombs UHD install for development machine CMake version failure

[Philip Balister via USRP-users]

On 9/11/19 12:38 PM, Marcus Müller via USRP-users wrote:
> Dear David,
> 
> I've seen that happen on specific Ubuntu versions, where they somehow
> missed to clean up / mark conflict between CMake 2.x packages and newer
> CMake (I'm perpetually disappointed by Canonical). Make twice as sure
> that you only got one CMake installed - if this is actually Ubuntu,
> "apt search cmake" might be the way to start.

For the E-series I would expect cmake to be the one in the sdk, unless
something is screwed up.

Philip

> 
> Best regards,
> Marcus
> 
> On Wed, 2019-09-11 at 16:42 +0100, David Scott via USRP-users wrote:
>> Hi all,
>>
>> I have recently acquired a USRP E312 and have been following the 
>> quickstart guide at: -
>>
>> https://kb.ettus.com/Software_Development_on_the_E310_and_E312
>>
>> The relevant commands being: -
>>
>>$ sudo pip install git+https://github.com/gnuradio/pybombs.git
>>$ pybombs recipes add gr-recipes 
>> git+https://github.com/gnuradio/gr-recipes.git
>>$ pybombs recipes add ettus 
>> https://github.com/EttusResearch/ettus-pybombs.git
>>$ sudo dpkg-reconfigure dash # select NO
>>$ pybombs prefix init ~/prefix -R e3xx-rfnoc -a e300
>>
>> Everything proceeds well up until the CMake is carried out at which
>> it 
>> complains that the installed version of CMake is below the minimum.
>> The 
>> output log is : -
>>
>>
>> 1511750 kB / 1511750 kB 
>> (100%
>> 
>>
>> [INFO] Installing SDK 
>> `e3xx-release4-
>> sdk'
>>
>> The directory "/home/david/prefix" already contains a SDK for this 
>> architecture.)))
>>
>> If you continue, existing files will be overwritten! 
>> Proceed[y/N]?Y))Extracting 
>> SDK...done)))
>> )
>>
>> Setting it 
>> up...done
>> )
>>
>> SDK has been successfully set up and is ready to be 
>> used.
>>
>> [INFO] Cleaning up 
>> files...)
>> )
>>
>> [INFO] Prefix Python version is: 
>> 2.7.15)))
>> )))
>>
>> [INFO] Installing default packages for 
>> prefix...)
>>
>> [INFO] 
>> )
>> ) 
>> - uhd)
>>- gnuradio
>>- gr-ettus
>> [INFO] Install python-apt to speed up apt processing.
>> [INFO] Phase 1: Creating install tree and installing binary packages:
>> Install tree:
>> \- gr-ettus
>> |
>> +- uhd
>> |
>> \- gnuradio
>>|
>>\- uhd
>> [INFO] Phase 1 complete: All binary dependencies installed.
>> [INFO] Phase 2: Recursively installing source packages to prefix:
>> [INFO] Installing package: uhd
>> [WARNING] A source build for package uhd was requested, but binary 
>> install was found!
>> Install uhd from source despite binary install available Y/[N]?
>> [INFO] Install python-apt to speed up apt processing.
>> [WARNING] Build dir already exists:
>> /home/david/prefix/src/uhd/host/build
>> Configuring: (100%) 
>> [
>> ==]
>> [WARNING] Configuration failed. Re-trying with higher verbosity.
>> CMake Error at CMakeLists.txt:13 (cmake_minimum_required):
>>CMake 3.5.1 or higher is required.  You are running version
>> 2.8.12.2
>>
>> -- Configuring incomplete, errors occurred!
>>
>> Running cmake --version on my system shows: -
>>
>>cmake version 3.10.2
>>
>>CMake suite maintained and supported by Kitware
>> (kitware.com/cmake).
>>
>> I have no idea why pybombs thinks I am running cmake 2.8. I have 
>> searched online and can find no reference to the issue. Has anyone
>> else 
>> encountered this issue or does anyone know of a solution?
>>
>> Thanks,
>>
>> David
>>
>>
>> ___
>> 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.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Interrupt Request on N310

[Philip Balister via USRP-users]

On 8/14/19 9:59 AM, Marcus D. Leech via USRP-users wrote:
> On 08/14/2019 09:43 AM, Erivelton Castro via USRP-users wrote:
>> Hello,
>>
>> I need to implement interrupt request on linux, using the N310
>> hardware. There are some example on UHD? I need to read the I/Q Data
>> when to occur hardware even. I must to use interrupt request. The UHD
>> has support for it? Or I need to implement IRQ on linux embedded?
>>
>> Best Regards
>>
>> Erivelton.
>>
> If you need to directly respond to interrupts on Linux, you'll likely
> need to write a kernel-level device driver.


I did a really quick google for some things I recalled that are
deprecated now. Then came across this, if you aren't high performance,
this might help.

https://www.kernel.org/doc/html/v4.17/driver-api/gpio/consumer.html

Philip

> 
> 
> ___
> 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

Re: [USRP-users] cmake error : Cross-Compiling GNU Radio on Ubuntu 16.04

[Philip Balister via USRP-users]

On 08/01/2019 10:58 PM, Nate Temple via USRP-users wrote:
> Hi,
> 
> I hope to have the E310 version posted tomorrow. Don't have a firm timeline
> for the E320/N3xx version yet.
> 
> The process is mostly the same, except you should not use rfnoc-devel, but
> instead use a modern UHD version such as v3.14.1.0, and then during the
> cmake configuration step, pass the arg -DENABLE_RFNOC=ON.
> 
> You can fetch the E320 SDK using uhd_images_downloader with the command
> (with UHD 3.14.1.0 on your host):
> 
> uhd_images_downloader -t sdk -t e320

What if I haven't installed uhd on the machine I plan to development
work on?

Philip

> 
> I would recommend to use maint-3.7 for the GR version with the E320.
> 
> 
> Regards,
> Nate Temple
> 
> On Thu, Aug 1, 2019 at 7:53 PM 福島幹雄  wrote:
> 
>> Hi Nate
>> Thank you for always your support and quick reply.
>>
>>> Are you using the E320 SDK?
>> No, I use the *E310 SDK*.
>> bacause I am training to get used to build the UHD and GR for cross
>> compiling environment.
>> next step, I will use the *E320 SDK*.
>>
>>> Also that app note is outdated, and I will be posted an updated version
>> soon. Another app note that covers the E320/N3xx will follow.
>>
>> Oh!!!
>> I have no words to thank you.
>> When do you think that will be?
>>
>> Thanks.
>>
> 
> 
> 
> ___
> 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

Re: [USRP-users] USRP E312 configuration

[Philip Balister via USRP-users]

Why not post the instructions to the list and save people a bunch of time 
getting to this point?

Philip


On July 18, 2019 7:00:01 PM GMT+02:00, Nate Temple via USRP-users 
 wrote:
>Hi Andreas,
>
>The errors you see when loading the idle FPGA can be safely ignored and
>are
>fixed in the new MPM based file system.
>
>We have a pending update for that application note that uses modern UHD
>that will be posted soon. I can follow up with you off list with the
>instructions for now.
>
>Regards,
>Nate Temple
>
>On Thu, Jul 18, 2019 at 9:36 AM Andreas Weinand via USRP-users <
>usrp-users@lists.ettus.com> wrote:
>
>> Hello,
>>
>> has someone already sucessfully made the E312 running using RFNOC
>> scripts? like in the example in
>>
>>
>https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
>>
>>
>> Unfortunately, i got the similar errors when following these
>> instructions as reported here before (e.g.
>>
>>
>http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-March/056028.html
>> ). I tried a lot of OS, UHD, gnuradio and gr-ettus combinations but
>all
>> ended in some errors like this earlier or later.
>>
>> I am currently trying with Ubuntu 18.04., if anyone has a working
>setup,
>> please let me know. Other OS are also fine for me.
>>
>> BR
>>
>> Andreas
>>
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E310 Startup/Boot not working

[Philip Balister via USRP-users]

The image creates the partitions.

Philip

On June 18, 2019 8:55:53 AM CDT, Donnie C via USRP-users 
 wrote:
>The download sizes appear to be fine, and I am not using FTP, could it
>be
>something to do with the partitions of the microSD card? I was reading
>the
>Ettus tutorial again and it refered to the sd card having a few
>partitions
>one of which is a boot partition, is the image suppose to create this
>partition?
>
>On Mon, Jun 17, 2019 at 3:30 PM Marcus D. Leech
>
>wrote:
>
>> On 06/17/2019 05:27 PM, Donnie C wrote:
>>
>> Its definitely being written to the right place /dev folder doesnt
>have
>> anything large under it, but how would you check if the image was
>> downloaded in text mode?
>>
>> Some windows FTP clients default to text mode, even when downloading
>> binary data.  But that would only apply if you used FTP.
>>
>> You sure your download didn't fail in the middle?  Compare the sizes.
>>
>>
>>
>> On Mon, Jun 17, 2019 at 3:17 PM Marcus D. Leech
>
>> wrote:
>>
>>> On 06/17/2019 05:09 PM, Donnie C wrote:
>>> > Im pretty sure the speed grade matches so it must be an incorrect
>sd
>>> > card burn, but as far as I can tell I followed the ettus tutorial
>for
>>> > sd image burning, is there any extra steps involved they don't go
>over?
>>> Bad card?  Bad card burner?  Pulled the card before the I/O had been
>>> fully flushed out to it?  Downloaded the image in text mode?  Got
>the
>>>device name wrong when burning, and now you have a large file
>under
>>> /dev, instead of written out to the actual card?
>>>
>>>
>>>
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E310 Startup/Boot not working

[Philip Balister via USRP-users]

As I recall, the LEDs default tonon and then an image is loaded into the fpha 
that turns them off. If they stay on, it suggests things are going wrong very 
early 

Philip

On June 17, 2019 3:52:54 PM CDT, Donnie C via USRP-users 
 wrote:
>Hello,
>
>I'm currently trying to get the E310 to boot with the most recent image
>release (
>http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg1/sdimage-gnuradio-demo.direct.xz
>) which I burned onto an microSD card using bitmap, but I cannot serial
>connect into it and the device has all the antennae LEDs on. I cannot
>find
>what the LEDs mean or why the E310 wont boot

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E320 hogging the network

[Philip Balister via USRP-users]

On 06/07/2019 03:17 PM, Jason Matusiak via USRP-users wrote:
> OK, I will keep an eye on that.  No GR will kill us for now though.  I've 
> been playing with the build system for an E320 the last 2 weeks and have 
> learned to build //some// extra things in (including GR, but I haven't moved 
> that image onto a device yet), so I could probably take a swag at it, but it 
> probably would be easier for me to just wait.  The main issue with GR on the 
> E320 for me (which I assume will be an issue on the E310 as well) is that 
> scipy isn't built for it.  Lots of GR examples use it, and I am worried that 
> some of our internal OOT modules might, so I tried to build it in, but I went 
> down a 2 day rabbit hole trying to get python-scipy working (it seems to be 
> hard to do in oe based on other people in other projects struggling with it).
> 

I think some of the gnuradio scipy stuff was replaced with numpy
operations, which helps.

Yet another of my hobby projects is to collect all the fortran/scipy
stuff in a layer and try and get it built. I think it is possible, but
have no personal motivation to make it happen, and no one is willing to pay.

Philip

> 
> I'll keep an eye on the MPM and knowledge base updates, thanks.
> 
> 
> 
> From: Nate Temple 
> Sent: Friday, June 7, 2019 3:10 PM
> To: Jason Matusiak
> Cc: Ettus Mail List
> Subject: Re: [USRP-users] E320 hogging the network
> 
> Hi Jason,
> 
> You could try running the new 3.15 MPM based file system for the E310, but it 
> has some caveats, more details here: 
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-May/059897.html
> 
> 
> 
> Regards,
> Nate Temple
> 
> On Fri, Jun 7, 2019 at 12:05 PM Jason Matusiak 
> mailto:ja...@gardettoengineering.com>> wrote:
> 
> OK, this is actually an E310 problem.  The E310 always looks off device 
> first.  A coworker reminded me that we spent a couple days years back trying 
> to figure out why the device was asking like it was working, but we weren't 
> seeing any results.  It was because it was actually talking to an N2xx on the 
> network even with the IP address arg.
> 
> 
> We never found a solution (using both the 127 and 192 address as an argument 
> still causes issues).  So, it would be nice to clean this up on the E310 at 
> some point, but for now I will try not to mix the E310 and E320 on the same 
> subnet.
> 
> 
> 
> From: Jason Matusiak
> Sent: Friday, June 7, 2019 12:41 PM
> To: Nate Temple
> Cc: Marcus D Leech; Philip Balister; Ettus Mail List
> Subject: Re: [USRP-users] E320 hogging the network
> 
> 
> OK, maybe based on my last email (which crossed yours I think).  The addr 
> flag doesn't seem to work at all with the uhd_usrp_probe on the E310 (at 
> least my version).
> 
> 
> From: Nate Temple mailto:nate.tem...@ettus.com>>
> Sent: Friday, June 7, 2019 12:37 PM
> To: Jason Matusiak
> Cc: Marcus D Leech; Philip Balister; Ettus Mail List
> Subject: Re: [USRP-users] E320 hogging the network
> 
> Hi Jason,
> 
> For what its worth, I haven't personally ran this exact combo (E310 w/ UHD 
> 3.11 and E320 w/ 3.14) on the same subnet, but I have ran two N320's on the 
> same subnet (192.168.10.2 and 192.168.10.3, both with 3.14). I did run into 
> the issue where probing in embedded mode would pickup the other device first, 
> but when providing a localhost addr, it worked as expected. I could use both 
> devices from a common host in network mode.
> 
> Trying the E320/E310 on different subnets would be worth a try.
> 
> I'll open an internal issue on our bug tracker for this, there is likely 
> improvements we can make to the device discovery.
> 
> 
> Regards,
> Nate Temple
> 
> On Fri, Jun 7, 2019 at 9:22 AM Jason Matusiak 
> mailto:ja...@gardettoengineering.com>> wrote:
> 
> Howdy.
> 
> 
> Nope, but it fails in a weird way.  I disconnected the E320 to make sure this 
> issue wasn't due to it, but it still acts the same.
> 
> 
> If I run: uhd_usrp_probe --args "addr=127.0.0.1"
> 
> root@ettus-e3xx-sg3:~# uhd_usrp_probe --args "addr=127.0.0.1"
> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106400; 
> UHD_3.11.0.1-0-unknown
> Error: i2c_zc_impl recv timeout
> 
> 
> 
> Reading up on the USRP2, they specifically say that you need to be on 
> different subnets if you are using more than on device.  I wonder if this is 
> the case here too?
> https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev
> 
> 
> 
> From: Nate Temple mailto:nate.tem...@ettus.com>>
> Sent: Friday, June 7, 2019 12:17 PM
> To: Jason Matusiak
> Cc: Marcus D Leech; Philip Balister; Ettus Mail List
> Subject: Re: [USRP-users] E320 hogging the network
> 
> Hi Jason,
> 
> On the E310, if you pass the device arg addr with 127.0.0.1 does it work as 
> expected?
> 
> uhd_usrp_probe --args "addr=127.0.0.1"
> 
> 
> Regards,
> Nate Temple
> 
> On Fri, Jun 7, 2019 at 9:10 AM Jason 

Re: [USRP-users] E320 hogging the network

[Philip Balister via USRP-users]

Check each ones ip address, likely by running ifconfig. In the back of
my mind, I recall something like this in the E100 days. Do they have the
same hostname?

Philip

On 06/07/2019 07:37 AM, Jason Matusiak via USRP-users wrote:
> It looks like I am misunderstanding something with how the E320 handles the 
> network.
> 
> 
> I have my E320 on my subnet with the sfp0 assigned to 10.45 (instead of the 
> default 10.2).  I can ssh into it and things seem to run fine in embedded 
> mode.
> 
> 
> Now, if I ssh onto an E312 that is on the same network (IP 10.95), it doesn't 
> work right as long as the E320 is plugged in.  When I do a probe or run any 
> other UHD-type commands on the E310, it seems to always talk to the E320 
> first and it screws everything up.  It doesn't matter if I put the E310's 
> address into the command or not, the E320 responds.  I also remember seeing 
> this occur when I was on my host machine running commands (the E320 bullied 
> its way into being the main attraction).
> 
> 
> My current work-around is to unplug Ethernet from the E320, run my command on 
> the E310, plug back into the E320, then run its command.  This seems to allow 
> things to work as I intended, but is obviously not ideal and is fairly 
> difficult to do when devices are remote.
> 
> 
> So what am I missing here?
> 
> 
> 
> ___
> 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

Re: [USRP-users] [UHD] Update to USRP E310 filesystem (v3.15.0.0 pre-release)

[Philip Balister via USRP-users]

On 05/24/2019 07:55 PM, Sugandha Gupta via USRP-users wrote:
> Hi all
> 
> We finally have a new filesystem for E310. This is an early release so
> people can try it out before the final UHD-3.15.0.0 release.
> The filesystem is now very similar to N3XX and E320 filesystem and will be
> updated with every UHD release in future.

Is there a table the maps code names (like neon and sulfur) to the
products they support?

Philip

> 
> Here is a summary of the changes:
> -  The new filesystem ( 
> v3.15.0.0-e310_prerelease
> 
> )  uses Linux kernel 4.15.
> Customers can build custom filesystems as well. More details on that are in
> the README
> . We
> plan to move to Linux 4.18 for the final 3.15.0.0 release. Timeline for
> that is still TBD.
> - UHD version: v3.15.0.0-e310_prerelease
> 
> - E310 FPGA
> 
> architecture now supports MPM .
> If you have been using RFNoC, you should able to use your existing blocks
> with no changes. The only change is the name of the image bit files
> generated.
> - These filesystems do not include GNURadio. Adding GNURadio maint 3.7
> means adding python2 support on top of python3 which blows up the size of
> the filesystem. In order to keep rootfs size small and have faster remote
> mender 
> updates, we decided to leave it out the default image. In order to use
> GNURadio, custom images need to be created. We will add instructions for
> adding GNURadio to the manual/knowledge base soon.
> 
> Note that the SD card shipped with E310s does not contain the latest
> filesystem images. In order to use the new filesystems, the SD cards need
> to be manually flashed. You can download the filesystem and new SDK here
> .
> Follow the instructions in E310 manual page
>  to burn a new SD card
> and get started. The manual page also contains a Migration Guide to help
> setup the device and suggests possible changes to customer applications.
> Please let us know if you have any questions. You can report bugs here
> https://github.com/EttusResearch/uhd/issues.
> 
> - Sugandha
> 
> 
> 
> 
> ___
> 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

Re: [USRP-users] GR in the E320

[Philip Balister via USRP-users]

Which branch of meta-sdr are you using? GNURadio 3.7 is python2 only.
The master branch works with python3.

It looks like you have numpy for both verions, but the config is
different or something, I've never run into this problem.

Philip

On 05/23/2019 03:16 PM, Jason Matusiak via USRP-users wrote:
> Here is what I get:
> root@ni-neon-rev2-mender:~# python
> Python 2.7.15 (default, May 17 2019, 15:52:34)
> [GCC 7.3.0] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
 import numbers
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: No module named numbers

> 
> 
> But python3.5 does work.
> root@ni-neon-rev2-mender:~# python3.5
> Python 3.5.5 (default, May 17 2019, 15:48:40)
> [GCC 7.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
 import numbers

> 
> 
> 
> From: Philip Balister 
> Sent: Thursday, May 23, 2019 1:45 PM
> To: Jason Matusiak; Ettus Mail List
> Subject: Re: [USRP-users] GR in the E320
> 
> On 05/23/2019 12:25 PM, Jason Matusiak via USRP-users wrote:
>> OK, I've actually done that before, but when I boot up and run this command, 
>> it isn't happy:
>> root@ni-neon-rev2-mender:/usr/share/gnuradio/examples/analog# python 
>> ./fmtest.py
>> Traceback (most recent call last):
>>   File "./fmtest.py", line 23, in 
>> from gnuradio import gr
>>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/__init__.py", line 44, 
>> in 
>> from top_block import *
>>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", line 30, 
>> in 
>> from hier_block2 import hier_block2
>>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/hier_block2.py", line 
>> 25, in 
>> import pmt
>>   File "/usr/lib/python2.7/site-packages/pmt/__init__.py", line 58, in 
>> 
>> from pmt_to_python import pmt_to_python as to_python
>>   File "/usr/lib/python2.7/site-packages/pmt/pmt_to_python.py", line 22, in 
>> 
>> import numpy
>>   File "/usr/lib/python2.7/site-packages/numpy/__init__.py", line 142, in 
>> 
>> from . import add_newdocs
>>   File "/usr/lib/python2.7/site-packages/numpy/add_newdocs.py", line 13, in 
>> 
>> from numpy.lib import add_newdoc
>>   File "/usr/lib/python2.7/site-packages/numpy/lib/__init__.py", line 8, in 
>> 
>> from .type_check import *
>>   File "/usr/lib/python2.7/site-packages/numpy/lib/type_check.py", line 11, 
>> in 
>> import numpy.core.numeric as _nx
>>   File "/usr/lib/python2.7/site-packages/numpy/core/__init__.py", line 35, 
>> in 
>> from . import _internal  # for freeze programs
>>   File "/usr/lib/python2.7/site-packages/numpy/core/_internal.py", line 18, 
>> in 
>> from .numerictypes import object_
>>   File "/usr/lib/python2.7/site-packages/numpy/core/numerictypes.py", line 
>> 87, in 
>> import numbers
>> ImportError: No module named numbers
> 
> 
> Run python and then try "import numbers". See that fail :)
> 
> Now try to figure what package provides numbers. I'm busy on a
> non-gnuradio thing at them moment, but will try and make sure this isn't
> a problem with the numpy recipe.
> 
> Philip
> 
>>
>>
>> 
>> From: Philip Balister 
>> Sent: Thursday, May 23, 2019 12:04 PM
>> To: Jason Matusiak; Ettus Mail List
>> Subject: Re: [USRP-users] GR in the E320
>>
>> On 05/23/2019 11:54 AM, Jason Matusiak via USRP-users wrote:
>>> OK, thanks Philip,
>>>
>>> This is all a little new/different for me.
>>>
>>> So once I've added in meta-sdr, all I should need to do is run 
>>> gnuradio-demo-image?
>>>
>>> also, would I need to modify the following environment variables since I am 
>>> building something out of meta-sdr?
>>>
>>> $ TEMPLATECONF=$(pwd)/meta-ettus//conf
>>> $ source ./oe-core/oe-init-build-env ./build ./bitbake
>>
>> My email fu is terrible today 
>>
>> Probably use the templates for the E320 build then add meta-sdr by hand,
>> I'd build dev image first, it doesn't have an x server.
>>
>> And once again, I do contract work to make this stuff work, beyond the
>> cases I can play with personally.
>>
>> Philip
>>
>>
>>>
>>>
>>> 
>>> From: Philip Balister 
>>> Sent: Thursday, May 23, 2019 11:43 AM
>>> To: Jason Matusiak; Ettus Mail List
>>> Subject: Re: [USRP-users] GR in the E320
>>>
>>> Oops, replied to copy in my inbox ...
>>>
>>> Adding meta-sdr to pick up gnuradio shouldn't have changed any machine
>>> specific config.
>>>
>>> Regarding mender, it is great if you have a rack of usrp's to update,
>>> but if you are working with one, I'd skip it and write cards by hand.
>>> >From what I understand this would be much quicker.
>>>
>>> I don't have an E320, so pretty much flying blind regarding hardware issues.
>>>
>>> Philip
>>>
>>> On 05/23/2019 11:16 AM, Jason Matusiak via USRP-users wrote:
 Philip, before building one of your images, does anything need to be done 
 to get ethernet to work?  It 

Re: [USRP-users] GR in the E320

[Philip Balister via USRP-users]

On 05/23/2019 12:25 PM, Jason Matusiak via USRP-users wrote:
> OK, I've actually done that before, but when I boot up and run this command, 
> it isn't happy:
> root@ni-neon-rev2-mender:/usr/share/gnuradio/examples/analog# python 
> ./fmtest.py
> Traceback (most recent call last):
>   File "./fmtest.py", line 23, in 
> from gnuradio import gr
>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/__init__.py", line 44, 
> in 
> from top_block import *
>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", line 30, 
> in 
> from hier_block2 import hier_block2
>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/hier_block2.py", line 
> 25, in 
> import pmt
>   File "/usr/lib/python2.7/site-packages/pmt/__init__.py", line 58, in 
> 
> from pmt_to_python import pmt_to_python as to_python
>   File "/usr/lib/python2.7/site-packages/pmt/pmt_to_python.py", line 22, in 
> 
> import numpy
>   File "/usr/lib/python2.7/site-packages/numpy/__init__.py", line 142, in 
> 
> from . import add_newdocs
>   File "/usr/lib/python2.7/site-packages/numpy/add_newdocs.py", line 13, in 
> 
> from numpy.lib import add_newdoc
>   File "/usr/lib/python2.7/site-packages/numpy/lib/__init__.py", line 8, in 
> 
> from .type_check import *
>   File "/usr/lib/python2.7/site-packages/numpy/lib/type_check.py", line 11, 
> in 
> import numpy.core.numeric as _nx
>   File "/usr/lib/python2.7/site-packages/numpy/core/__init__.py", line 35, in 
> 
> from . import _internal  # for freeze programs
>   File "/usr/lib/python2.7/site-packages/numpy/core/_internal.py", line 18, 
> in 
> from .numerictypes import object_
>   File "/usr/lib/python2.7/site-packages/numpy/core/numerictypes.py", line 
> 87, in 
> import numbers
> ImportError: No module named numbers


Run python and then try "import numbers". See that fail :)

Now try to figure what package provides numbers. I'm busy on a
non-gnuradio thing at them moment, but will try and make sure this isn't
a problem with the numpy recipe.

Philip

> 
> 
> 
> From: Philip Balister 
> Sent: Thursday, May 23, 2019 12:04 PM
> To: Jason Matusiak; Ettus Mail List
> Subject: Re: [USRP-users] GR in the E320
> 
> On 05/23/2019 11:54 AM, Jason Matusiak via USRP-users wrote:
>> OK, thanks Philip,
>>
>> This is all a little new/different for me.
>>
>> So once I've added in meta-sdr, all I should need to do is run 
>> gnuradio-demo-image?
>>
>> also, would I need to modify the following environment variables since I am 
>> building something out of meta-sdr?
>>
>> $ TEMPLATECONF=$(pwd)/meta-ettus//conf
>> $ source ./oe-core/oe-init-build-env ./build ./bitbake
> 
> My email fu is terrible today 
> 
> Probably use the templates for the E320 build then add meta-sdr by hand,
> I'd build dev image first, it doesn't have an x server.
> 
> And once again, I do contract work to make this stuff work, beyond the
> cases I can play with personally.
> 
> Philip
> 
> 
>>
>>
>> 
>> From: Philip Balister 
>> Sent: Thursday, May 23, 2019 11:43 AM
>> To: Jason Matusiak; Ettus Mail List
>> Subject: Re: [USRP-users] GR in the E320
>>
>> Oops, replied to copy in my inbox ...
>>
>> Adding meta-sdr to pick up gnuradio shouldn't have changed any machine
>> specific config.
>>
>> Regarding mender, it is great if you have a rack of usrp's to update,
>> but if you are working with one, I'd skip it and write cards by hand.
>> >From what I understand this would be much quicker.
>>
>> I don't have an E320, so pretty much flying blind regarding hardware issues.
>>
>> Philip
>>
>> On 05/23/2019 11:16 AM, Jason Matusiak via USRP-users wrote:
>>> Philip, before building one of your images, does anything need to be done 
>>> to get ethernet to work?  It seems like after using mender to setup a new 
>>> image and rebooting, I cannot bring up sfp0 to save my life.  It won't work 
>>> until I reboot again, but I think that that drops the mender image reverts 
>>> to the old one since I didn't commit it.   Any steps I am missing?
>>>
>>>
>>> 
>>> From: Jason Matusiak
>>> Sent: Tuesday, May 21, 2019 11:18 AM
>>> To: Philip Balister; Ettus Mail List
>>> Subject: Re: [USRP-users] GR in the E320
>>>
>>> OK, that seems to be building (who knows if it will succeed), thanks.
>>>
>>> I can't seem to find directions online about how to add in my own recipes, 
>>> or those written up somewhere?  Basically, I am trying to figure out how I 
>>> can add something like gr-my_blocks to the project (either part of bitbake, 
>>> or as a stand-alone build I move over to the device afterwards.
>>>
>>> 
>>> From: Philip Balister 
>>> Sent: Tuesday, May 21, 2019 11:05 AM
>>> To: Jason Matusiak; Ettus Mail List
>>> Subject: Re: [USRP-users] GR in the E320
>>>
>>> Edit bblayers.conf in your conf directory. There is also an add layer
>>> command, but I'm old fashioned :)
>>>

Re: [USRP-users] GR in the E320

[Philip Balister via USRP-users]

On 05/23/2019 11:54 AM, Jason Matusiak via USRP-users wrote:
> OK, thanks Philip,
> 
> This is all a little new/different for me.
> 
> So once I've added in meta-sdr, all I should need to do is run 
> gnuradio-demo-image?
> 
> also, would I need to modify the following environment variables since I am 
> building something out of meta-sdr?
> 
> $ TEMPLATECONF=$(pwd)/meta-ettus//conf
> $ source ./oe-core/oe-init-build-env ./build ./bitbake

My email fu is terrible today 

Probably use the templates for the E320 build then add meta-sdr by hand,
I'd build dev image first, it doesn't have an x server.

And once again, I do contract work to make this stuff work, beyond the
cases I can play with personally.

Philip


> 
> 
> 
> From: Philip Balister 
> Sent: Thursday, May 23, 2019 11:43 AM
> To: Jason Matusiak; Ettus Mail List
> Subject: Re: [USRP-users] GR in the E320
> 
> Oops, replied to copy in my inbox ...
> 
> Adding meta-sdr to pick up gnuradio shouldn't have changed any machine
> specific config.
> 
> Regarding mender, it is great if you have a rack of usrp's to update,
> but if you are working with one, I'd skip it and write cards by hand.
>>From what I understand this would be much quicker.
> 
> I don't have an E320, so pretty much flying blind regarding hardware issues.
> 
> Philip
> 
> On 05/23/2019 11:16 AM, Jason Matusiak via USRP-users wrote:
>> Philip, before building one of your images, does anything need to be done to 
>> get ethernet to work?  It seems like after using mender to setup a new image 
>> and rebooting, I cannot bring up sfp0 to save my life.  It won't work until 
>> I reboot again, but I think that that drops the mender image reverts to the 
>> old one since I didn't commit it.   Any steps I am missing?
>>
>>
>> 
>> From: Jason Matusiak
>> Sent: Tuesday, May 21, 2019 11:18 AM
>> To: Philip Balister; Ettus Mail List
>> Subject: Re: [USRP-users] GR in the E320
>>
>> OK, that seems to be building (who knows if it will succeed), thanks.
>>
>> I can't seem to find directions online about how to add in my own recipes, 
>> or those written up somewhere?  Basically, I am trying to figure out how I 
>> can add something like gr-my_blocks to the project (either part of bitbake, 
>> or as a stand-alone build I move over to the device afterwards.
>>
>> 
>> From: Philip Balister 
>> Sent: Tuesday, May 21, 2019 11:05 AM
>> To: Jason Matusiak; Ettus Mail List
>> Subject: Re: [USRP-users] GR in the E320
>>
>> Edit bblayers.conf in your conf directory. There is also an add layer
>> command, but I'm old fashioned :)
>>
>> Philip
>>
>> On 05/21/2019 10:50 AM, Jason Matusiak via USRP-users wrote:
>>> Interesting, thanks.  They are using sumo, so I will try to check that 
>>> branch out and see how it works.
>>>
>>> I will need to research how to add it in and build it as I see pulling it 
>>> down and checking out sumo alone isn't enough.
>>>
>>> Thanks for the insights.
>>>
>>> 
>>> From: Philip Balister 
>>> Sent: Tuesday, May 21, 2019 10:39 AM
>>> To: Jason Matusiak; Ettus Mail List
>>> Subject: Re: [USRP-users] GR in the E320
>>>
>>> You need the meta-sdr layer. Choosing a branch may be tricky, only the
>>> older ones have 3.7 support. My recent work in master is all in support
>>> of transitioning to the unreleased 3.8 gnuradio, which is much better
>>> for embedded builds.
>>>
>>> Might also be some pain due to Ettus forking the uhd recipe.
>>>
>>> Philip
>>>
>>> On 05/21/2019 10:30 AM, Jason Matusiak via USRP-users wrote:
 OK, so I am a total newbie when it comes to open-embedded.  I know that 
 the docker to build doesn't include a gnuradio-image bitbake option (only 
 developer-image), so I tried to make one.  I created a new 
 gnuradio-image.bb file and added gnuradio to the list of things to build.  
 Sadly, I appear to need to do more than that as it won't build:

 oe-builder@b3d40f15af25:~$ bitbake gnuradio-image --verbose
 Loading cache: 100% 
 |##|
  Time: 0:00:00
 Loaded 2964 entries from dependency cache.
 NOTE: Resolving any missing task queue dependencies
 NOTE: selecting opkg-utils-native to satisfy 
 virtual/update-alternatives-native due to PREFERRED_PROVIDERS
 NOTE: selecting linux-yocto to satisfy virtual/kernel due to 
 PREFERRED_PROVIDERS
 NOTE: selecting pseudo-native to satisfy virtual/fakeroot-native due to 
 PREFERRED_PROVIDERS
 NOTE: selecting opkg-native to satisfy opkg-native due to 
 PREFERRED_PROVIDERS
 NOTE: selecting nativesdk-glibc to satisfy runtime nativesdk-glibc due to 
 PREFERRED_PROVIDER_virtual/nativesdk-libc = nativesdk-glibc

Re: [USRP-users] GR in the E320

[Philip Balister via USRP-users]

Oops, replied to copy in my inbox ...

Adding meta-sdr to pick up gnuradio shouldn't have changed any machine
specific config.

Regarding mender, it is great if you have a rack of usrp's to update,
but if you are working with one, I'd skip it and write cards by hand.
>From what I understand this would be much quicker.

I don't have an E320, so pretty much flying blind regarding hardware issues.

Philip

On 05/23/2019 11:16 AM, Jason Matusiak via USRP-users wrote:
> Philip, before building one of your images, does anything need to be done to 
> get ethernet to work?  It seems like after using mender to setup a new image 
> and rebooting, I cannot bring up sfp0 to save my life.  It won't work until I 
> reboot again, but I think that that drops the mender image reverts to the old 
> one since I didn't commit it.   Any steps I am missing?
> 
> 
> 
> From: Jason Matusiak
> Sent: Tuesday, May 21, 2019 11:18 AM
> To: Philip Balister; Ettus Mail List
> Subject: Re: [USRP-users] GR in the E320
> 
> OK, that seems to be building (who knows if it will succeed), thanks.
> 
> I can't seem to find directions online about how to add in my own recipes, or 
> those written up somewhere?  Basically, I am trying to figure out how I can 
> add something like gr-my_blocks to the project (either part of bitbake, or as 
> a stand-alone build I move over to the device afterwards.
> 
> 
> From: Philip Balister 
> Sent: Tuesday, May 21, 2019 11:05 AM
> To: Jason Matusiak; Ettus Mail List
> Subject: Re: [USRP-users] GR in the E320
> 
> Edit bblayers.conf in your conf directory. There is also an add layer
> command, but I'm old fashioned :)
> 
> Philip
> 
> On 05/21/2019 10:50 AM, Jason Matusiak via USRP-users wrote:
>> Interesting, thanks.  They are using sumo, so I will try to check that 
>> branch out and see how it works.
>>
>> I will need to research how to add it in and build it as I see pulling it 
>> down and checking out sumo alone isn't enough.
>>
>> Thanks for the insights.
>>
>> 
>> From: Philip Balister 
>> Sent: Tuesday, May 21, 2019 10:39 AM
>> To: Jason Matusiak; Ettus Mail List
>> Subject: Re: [USRP-users] GR in the E320
>>
>> You need the meta-sdr layer. Choosing a branch may be tricky, only the
>> older ones have 3.7 support. My recent work in master is all in support
>> of transitioning to the unreleased 3.8 gnuradio, which is much better
>> for embedded builds.
>>
>> Might also be some pain due to Ettus forking the uhd recipe.
>>
>> Philip
>>
>> On 05/21/2019 10:30 AM, Jason Matusiak via USRP-users wrote:
>>> OK, so I am a total newbie when it comes to open-embedded.  I know that the 
>>> docker to build doesn't include a gnuradio-image bitbake option (only 
>>> developer-image), so I tried to make one.  I created a new 
>>> gnuradio-image.bb file and added gnuradio to the list of things to build.  
>>> Sadly, I appear to need to do more than that as it won't build:
>>>
>>> oe-builder@b3d40f15af25:~$ bitbake gnuradio-image --verbose
>>> Loading cache: 100% 
>>> |##|
>>>  Time: 0:00:00
>>> Loaded 2964 entries from dependency cache.
>>> NOTE: Resolving any missing task queue dependencies
>>> NOTE: selecting opkg-utils-native to satisfy 
>>> virtual/update-alternatives-native due to PREFERRED_PROVIDERS
>>> NOTE: selecting linux-yocto to satisfy virtual/kernel due to 
>>> PREFERRED_PROVIDERS
>>> NOTE: selecting pseudo-native to satisfy virtual/fakeroot-native due to 
>>> PREFERRED_PROVIDERS
>>> NOTE: selecting opkg-native to satisfy opkg-native due to 
>>> PREFERRED_PROVIDERS
>>> NOTE: selecting nativesdk-glibc to satisfy runtime nativesdk-glibc due to 
>>> PREFERRED_PROVIDER_virtual/nativesdk-libc = nativesdk-glibc
>>> ERROR: Nothing RPROVIDES 'gnuradio' (but 
>>> /home/oe-builder/meta-ettus/meta-ettus-core/recipes-core/images/gnuradio-image.bb
>>>  RDEPENDS on or otherwise requires it)
>>> NOTE: Runtime target 'gnuradio' is unbuildable, removing...
>>> Missing or unbuildable dependency chain was: ['gnuradio']
>>> NOTE: Target 'gnuradio-image' is unbuildable, removing...
>>> Missing or unbuildable dependency chain was: ['gnuradio-image', 'gnuradio']
>>> ERROR: Required build target 'gnuradio-image' has no buildable providers.
>>> Missing or unbuildable dependency chain was: ['gnuradio-image', 'gnuradio']
>>>
>>> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
>>>
>>> Anyone know how to do add it (once that works, I'll want to add some of my 
>>> own OOT packages as well)?
>>>
>>>
>>>
>>>
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>>

Re: [USRP-users] Connect Eth Phy to FPGA

[Philip Balister via USRP-users]

On 05/21/2019 02:56 PM, Sylvain Munaut wrote:
> Hi,
> 
> Yes, it's connected to the PS and not the PL.
> _However_ ... you could just remove the ethernet driver from the linux
> side, then drive the built-in ethernet mac from the FPGA by just
> acting as an AXI master.
> 
> None of this is trivial however ...

But it is possible. I'd love to see someone try it.

Philip

> 
> 
> Cheers,
> 
> Sylvain
> 

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] GR in the E320

[Philip Balister via USRP-users]

https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html

Also:

https://training.linuxfoundation.org/training/embedded-linux-development-with-yocto-project/

Philip

On 05/21/2019 11:18 AM, Jason Matusiak via USRP-users wrote:
> OK, that seems to be building (who knows if it will succeed), thanks.
> 
> I can't seem to find directions online about how to add in my own recipes, or 
> those written up somewhere?  Basically, I am trying to figure out how I can 
> add something like gr-my_blocks to the project (either part of bitbake, or as 
> a stand-alone build I move over to the device afterwards.
> 
> 
> From: Philip Balister 
> Sent: Tuesday, May 21, 2019 11:05 AM
> To: Jason Matusiak; Ettus Mail List
> Subject: Re: [USRP-users] GR in the E320
> 
> Edit bblayers.conf in your conf directory. There is also an add layer
> command, but I'm old fashioned :)
> 
> Philip
> 
> On 05/21/2019 10:50 AM, Jason Matusiak via USRP-users wrote:
>> Interesting, thanks.  They are using sumo, so I will try to check that 
>> branch out and see how it works.
>>
>> I will need to research how to add it in and build it as I see pulling it 
>> down and checking out sumo alone isn't enough.
>>
>> Thanks for the insights.
>>
>> 
>> From: Philip Balister 
>> Sent: Tuesday, May 21, 2019 10:39 AM
>> To: Jason Matusiak; Ettus Mail List
>> Subject: Re: [USRP-users] GR in the E320
>>
>> You need the meta-sdr layer. Choosing a branch may be tricky, only the
>> older ones have 3.7 support. My recent work in master is all in support
>> of transitioning to the unreleased 3.8 gnuradio, which is much better
>> for embedded builds.
>>
>> Might also be some pain due to Ettus forking the uhd recipe.
>>
>> Philip
>>
>> On 05/21/2019 10:30 AM, Jason Matusiak via USRP-users wrote:
>>> OK, so I am a total newbie when it comes to open-embedded.  I know that the 
>>> docker to build doesn't include a gnuradio-image bitbake option (only 
>>> developer-image), so I tried to make one.  I created a new 
>>> gnuradio-image.bb file and added gnuradio to the list of things to build.  
>>> Sadly, I appear to need to do more than that as it won't build:
>>>
>>> oe-builder@b3d40f15af25:~$ bitbake gnuradio-image --verbose
>>> Loading cache: 100% 
>>> |##|
>>>  Time: 0:00:00
>>> Loaded 2964 entries from dependency cache.
>>> NOTE: Resolving any missing task queue dependencies
>>> NOTE: selecting opkg-utils-native to satisfy 
>>> virtual/update-alternatives-native due to PREFERRED_PROVIDERS
>>> NOTE: selecting linux-yocto to satisfy virtual/kernel due to 
>>> PREFERRED_PROVIDERS
>>> NOTE: selecting pseudo-native to satisfy virtual/fakeroot-native due to 
>>> PREFERRED_PROVIDERS
>>> NOTE: selecting opkg-native to satisfy opkg-native due to 
>>> PREFERRED_PROVIDERS
>>> NOTE: selecting nativesdk-glibc to satisfy runtime nativesdk-glibc due to 
>>> PREFERRED_PROVIDER_virtual/nativesdk-libc = nativesdk-glibc
>>> ERROR: Nothing RPROVIDES 'gnuradio' (but 
>>> /home/oe-builder/meta-ettus/meta-ettus-core/recipes-core/images/gnuradio-image.bb
>>>  RDEPENDS on or otherwise requires it)
>>> NOTE: Runtime target 'gnuradio' is unbuildable, removing...
>>> Missing or unbuildable dependency chain was: ['gnuradio']
>>> NOTE: Target 'gnuradio-image' is unbuildable, removing...
>>> Missing or unbuildable dependency chain was: ['gnuradio-image', 'gnuradio']
>>> ERROR: Required build target 'gnuradio-image' has no buildable providers.
>>> Missing or unbuildable dependency chain was: ['gnuradio-image', 'gnuradio']
>>>
>>> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
>>>
>>> Anyone know how to do add it (once that works, I'll want to add some of my 
>>> own OOT packages as well)?
>>>
>>>
>>>
>>>
>>> ___
>>> 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.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

Re: [USRP-users] Connect Eth Phy to FPGA

[Philip Balister via USRP-users]

You should check the schematic, but as I recall the ethernet interface
is connected directly to the ARM and not via the FPGA fabric.

Philip

On 05/21/2019 10:32 AM, Ramazan Çetin via USRP-users wrote:
> Hello,
> 
> We want to use E310 as a peripheral network device like N210. We want
> the RF samples come to ethernet interface through FPGA without passing
> from CPU. In short, we don't want to use CPU. So, can we configure FPGA
> to achieve this task? (Connecting ethernet interface directly to FPGA)
> 
> Best regards.
> 
> 
> 
> 
> 
> ___
> 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

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Philip Balister via USRP-users]

I've got the 3.8.4 images zipfile lying around in my OE download
directory, if it helps I can put it on dropbox. I might be able to find
some older ones if needed.

Yeah, I save ancient source in case of a GPL compliance exercise :)

Philip

On 05/08/2019 05:40 PM, Robin Coxe via USRP-users wrote:
> You could try using the .deb or .rpm pre-built binaries if you're running
> on Linux.  See, for instance:
> http://files.ettus.com/binaries/uhd/uhd_003.004.000-release/
> 
> On Wed, May 8, 2019 at 2:09 PM Joe Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> 
>> I’ve successfully built UHD v3.9.0 but it has the same error as 3.14.0 did
>> before (“Received invalid reply 32 from device”) and uhd_usrp_probe still
>> complains that it is expecting compatibility number 11 but is receiving 6.
>> So I think that means I need an earlier version of UHD than 3.9.0.
>>
>> I will dig into the earliest version in the git tag -l, namely
>> 003_007_002_rc1, that would not build without errors and try to work out
>> the compiler errors then.  Unless someone has a better idea to try.
>> Thanks!
>>
>> Regards,
>>
>> Joe
>>
>> On May 8, 2019, at 2:40 PM, Joe Martin via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>> Okay, thanks, that’s what I thought but that isn’t useful for me until I
>> find a UHD version that can communicate with it.  I’ve been trying to build
>> older UHD versions from 003_007_002_rc1 forward but all so far fail to
>> build due to compiler errors.  Am up to 003_008_005_rc1 now, moving forward
>> until I can successfully build one to try.  Are there any old pre-built
>> versions I could simply try without having to build each one myself?
>>
>> Joe
>>
>> On May 8, 2019, at 2:31 PM, Nick Foster  wrote:
>>
>> Yes, code loaded over JTAG is gone at next boot. I can't think of an easy
>> way to figure out what image is loaded other than asking UHD to query it
>> for FPGA compat number.
>>
>> On Wed, May 8, 2019 at 1:04 PM Joe Martin  wrote:
>>
>>> I guess the proper way to ask is “Is there a way to determine what fpga
>>> .bin file is in the N210?”, since the .bit file that I loaded into the fpga
>>> is volatile code that disappears upon power cycling to be reloaded from an
>>> EEPROM or something, yes?
>>>
>>> Joe
>>>
>>> On May 8, 2019, at 1:55 PM, Joe Martin via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>> Hi Nick,
>>>
>>> Thanks for the comments.  Is there a way to determine what bit file is
>>> currently in the N210?  If so, how please?
>>>
>>> Joe
>>>
>>> On May 8, 2019, at 1:33 PM, Nick Foster  wrote:
>>>
>>> I see you got there already! If you're still having trouble, I'll see
>>> what I can dig up over here.
>>>
>>> On Wed, May 8, 2019 at 12:31 PM Nick Foster  wrote:
>>>
 You might be best off reverting to a UHD old enough to support the
 bitfile currently loaded on your N210. You could then bootstrap your N210
 by using the old UHD to load a newer FPGA image.

 Otherwise, it's fairly simple to convert the binfiles (which still exist
 -- usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from
 usrp_n210_r3_fpga.bit and just stick it onto the front of
 usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The
 header is everything up until FF FF FF FF AA 99 55 66.

 Lastly, the source is all there, so building using ISE should still be
 possible.

 Nick

 On Wed, May 8, 2019 at 9:57 AM Joe Martin via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Wow, okay; that’s disheartening.  Thanks much for the info, Jason.
> Nope, the Rev3 bit file doesn’t work; tried it.  I’ll see if the support
> email adr can be of use.
>
> Joe
>
> On May 8, 2019, at 10:44 AM, Jason Matusiak <
> ja...@gardettoengineering.com> wrote:
>
> Joe, I think you might be SOL.  If you take a look at this thread from
> me last year, I had no luck:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
>
>
> Also, when I pinged Ettus directly, here is some info I got back from
> them (from two different emails in the thread):
> "we've been having some trouble tracking down Rev2 bitfiles, because no
> one here was around when that was built. If you're trying to unbrick
> them, Rev3 bitfiles might be OK, but I'm not completely sure.
>
> supp...@ettus.com might know more by know.
> really sorry, but those Rev2s are just so old. And all the people from
> that era seem to be gone. Sorry, can't help you with those Rev2s."
>
> --
> *From:* USRP-users  on behalf of
> Joe Martin via USRP-users 
> *Sent:* Wednesday, May 8, 2019 11:55 AM
> *To:* Joe Martin via USRP-users
> *Subject:* [USRP-users] Bringing an elderly N210 to life by loading
> current firmware/fpga images
>
> I am trying to bring an elderly N210 r2.0 with unknown 

Re: [USRP-users] E320 numpy missing?

[Philip Balister via USRP-users]

On 05/01/2019 09:55 AM, Jason Matusiak via USRP-users wrote:
> I also get a "ImportError: No module named sip" when I try to run: 
> uhd_siggen_gui
> 
> So I think a few things might be missing from the cross-compile setup.

I took a few minutes and looked at the current state of the BSP. It
looks like you might have this image:

https://github.com/EttusResearch/meta-ettus/blob/master/meta-ettus-core/recipes-core/images/developer-image.bb

I forget where numpy is the gnuradio dependency tree, but I'm going to
guess if you enable python support in gnuradio (yes it might be possible
to use gnuradio without python) you will need numpy to build/run.

Philip

> 
> 
> From: Jason Matusiak
> Sent: Wednesday, May 1, 2019 8:46 AM
> To: Ettus Mail List
> Subject: E320 numpy missing?
> 
> Finally got my E320 in and I cross-compiled a new setup.  I tried to fire up 
> my flowgraph (which works fine on an E310) and it is complaining about numpy 
> missing.
> 
> If I do a search from / on the E320, the only numpy that is showing up is:
> /usr/include/boost/python/numpy
> 
> If I do a search from a good E310 in / I see:
> ./usr/lib/python2.7/site-packages/numpy
> ./usr/lib/python2.7/site-packages/numpy/core/include/numpy
> ./usr/lib/python2.7/site-packages/Cython/Includes/numpy
> ./usr/include/boost/python/numpy
> 
> 
> Back on the host machine, my E320 cross-compile prefix shows numpy:
> ./sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy
> 
> My good E310 prefix shows:
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy/core/include/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy/core/include/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/Cython/Includes/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy/core/include/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy
> 
> So, was numpy forgotten?  Left out for a reason?  I am going to attempt to 
> build it by hand, but I have a fear that I am going to go down dependency 
> hell with this and other missing packages that GR might want.
> 
> 
> 
> 
> ___
> 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] Fwd: [Discuss-gnuradio] European GNU Radio Days contribution deadline (March 21st)

[Philip Balister via USRP-users]

 Forwarded Message 
Subject: [Discuss-gnuradio] European GNU Radio Days contribution
deadline (March 21st)
Date: Mon, 18 Mar 2019 10:50:51 +
From: jean-michel.fri...@femto-st.fr 
To: discuss-gnura...@gnu.org

The European GNU Radio Days contribution deadline is getting close (set to
March 21st). Please consider contributing if you wish to share the results
of your work either as oral presentation, demonstration or tutorial.

The template and submission site are available at
https://gnuradio-fr-19.sciencesconf.org/
Contributions will be published on the GRCon Proceeding web site at
https://pubs.gnuradio.org

See you there, Jean-Michel

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

___
Discuss-gnuradio mailing list
discuss-gnura...@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E310 Overflows

[Philip Balister via USRP-users]

On 12/19/2018 11:56 AM, Devin Kelly via USRP-users wrote:
> Hello,
> 
> I have an X310 transmitting packets to an E310, the E310 can successfully
> demodulate the packet and estimate the time of flight.  I'm sending one
> packet per second for about half an hour and the ToF estimate is very
> consistent, except for when I have an overflow on the E310.  I get an
> overflow once every 15-20 minutes or so.

Running "perf top" might help give you ideas where to optimize code. I'd
also look at all processes running in the background and start shutting
off ones you do not need.

Philip

> 
> When I get an overflow my ToF estimate increases permanently by a small
> amount, enough to affect my application.  For example, I might get 500
> packets in a row with a ToF of 100 us each, then I get an overflow and all
> my remaining packets have a ToF of 101.6 us.  All the USRPs are wired
> together so my channel isn't changing.  I tried to figure out if I could
> compensate for the difference but I couldn't figure it out.  I also tried
> to reset the PPS on the E310, which didn't work.
> 
> I know it's on the receive side because I have multiple receivers and I can
> match each overflow to each ToF change.  On the E310 I'm using UHD 3.9.2.
> Can anyone help me figure this out?
> 
> Also, is there a newer image I should be using for the E310?  Or, a newer
> UHD?  It doesn't look like the E310 is supported much anymore, or is there
> something I'm not seeing?
> 
> Thanks,
> Devin
> 
> 
> 
> ___
> 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

Re: [USRP-users] cross-compiling for N310

[Philip Balister via USRP-users]

Do you really need to install uhd on a machine to install an sdk on it?

Philip

On December 18, 2018 11:19:38 AM EST, Jason Matusiak via USRP-users 
 wrote:
>I got it by running: uhd_images_downloader -t sdk -t n3xx
> 
>based on instructions here:
>https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_software_dev_sdk
> 
>It does not appear to have gnuradio installed
> 
>OK, gnuradio seems to build fine for cross-compile, it is when I get to
>the gr-ettus step which is next (needed for RFNoC).  I haven't tried
>running gnuradio, but it builds.
> 
> 
>- Original Message - Subject: Re: [USRP-users]
>cross-compiling for N310
>From: "Philip Balister" 
>Date: 12/18/18 10:25 am
>To: "Jason Matusiak" , "Ettus Mail List"
>
>
>On 12/18/2018 08:17 AM, Jason Matusiak via USRP-users wrote:
>> It looks like qt4 was not included in the cross-compile build. If I
>look at my working e300 cross-compile, I have a folder:
>/opt/gnuradio/e300/sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/qt4/
> > 
> > (in fact, there is a tone of stuff in that include).
> > 
>> If I look in the N310 directory, it doesn't exist:
>/opt/gnuradio/N310/sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/
> > 
> > (and there are very few files/folders in there at all.
> > 
>> I will look into building it by hand, but I am guessing that it will
>just lead to more things needing to be cross-compiled
> 
>Where did you get the toolchain? Does the N310 have gnuradio installed?
>Feels like the sdk may not have the packages you need to build gnuradio
> installed.
> 
>Try disabling qt4 and seeing if you can get gnuradio to build like that
> as a test.
> 
> Philip
> 
> > 
> > 
> > 
>> - Original Message - Subject: RE: cross-compiling for
>N310
> > From: "Jason Matusiak" 
> > Date: 12/17/18 3:15 pm
> > To: "Ettus Mail List" 
> > 
>> OK, I see the first mistake. I was copying-and-pasting my notes for
>the E310 which had a different sysroot. Once I made the change to the
>proper one, it seems like it got past the rfnoc issue (or I haven't hit
>it yet with this new error).
> > 
> > I am not getting:
>> - Found PkgConfig:
>/opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config
>(found version "0.29.2") 
>> -- Found UHD:
>/opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/libuhd.so
>
>> -- Found PythonLibs:
>/opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/libpython2.7.so
>(found suitable version "2.7.14", minimum required is "2") 
>> CMake Warning at
>/opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/share/cmake-3.10/Modules/FindQt4.cmake:620
>(message):
>> /usr/bin/qmake-qt4 reported QT_INSTALL_LIBS as "/usr/lib64" but
>QtCore
>> could not be found there. Qt is NOT installed correctly for the
>target
> > build environment.
> > Call Stack (most recent call first):
> > CMakeLists.txt:149 (find_package)
> > 
> > CMake Error at CMakeLists.txt:151 (message):
> > Qt not found.
> > 
> > -- Configuring incomplete, errors occurred!
>> See also
>"/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeOutput.log".
>> See also
>"/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeError.log".
> > 
>> I feel like I had this issue before with an E310 build and Phil B had
>to make mods to the toolchain. Has anyone else seen and got around
>this?
> > 
> > 
> > 
>> - Original Message - Subject: cross-compiling for
>N310
> > From: "Jason Matusiak" 
> > Date: 12/17/18 1:35 pm
> > To: "Ettus Mail List" 
> > 
>> Has anyone successfully created a new build for an N310 (RFNoC
>version in particular)? I was going to bring it up to date, but seem to
>be having issues.
> > 
> > I ran: uhd_images_downloader -t sdimg -v
>> To get the *.sh image for cross-compiling:
>oecore-x86_64-cortexa9hf-neon-toolchain-nodistro.0.sh
> > 
> > I then install it like I do for the E310.
> > 
>> I create a src directory and pull down uhd and its sub-module
>fpga-src. I've tried main, master, and UHD-3.13, and they all build
>fine, but give me issues later on. In my cmake I make sure to have
>-DENABLE_RFNOC=ON and I see it checked when I run cmake-gui.
> > 
> > I then pull down gnuradio, and build like I normally do.
> > 
>> Lastly, I pull down gr-ettus. When I run: cmake
>-DCMAKE_TOOLCHAIN_FILE=$PREFIX/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
>-DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ..
> > 
> > It mostly works and then errors out with:
> > 
>> -- Found PkgConfig:
>/opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config
>(found version "0.29.2") 
>> -- Found UHD:
>/opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/libuhd.so
>
> > CMake Error at CMakeLists.txt:140 (message):
> > RFNoC not found.
> > 
> > -- Configuring incomplete, errors occurred!
>> See also
>"/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeOutput.log".
>> See also
>"/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeError.log".
> > 
>> In the past, I 

Re: [USRP-users] cross-compiling for N310

[Philip Balister via USRP-users]

On 12/18/2018 08:17 AM, Jason Matusiak via USRP-users wrote:
> It looks like qt4 was not included in the cross-compile build.  If I look at 
> my working e300 cross-compile, I have a folder: 
> /opt/gnuradio/e300/sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/qt4/
>  
> (in fact, there is a tone of stuff in that include).
>  
> If I look in the N310 directory, it doesn't exist: 
> /opt/gnuradio/N310/sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/
>  
> (and there are very few files/folders in there at all.
>  
> I will look into building it by hand, but I am guessing that it will just 
> lead to more things needing to be cross-compiled

Where did you get the toolchain? Does the N310 have gnuradio installed?
Feels like the sdk may not have the packages you need to build gnuradio
installed.

Try disabling qt4 and seeing if you can get gnuradio to build like that
as a test.

Philip

>  
>  
>  
> - Original Message - Subject: RE: cross-compiling for N310
> From: "Jason Matusiak" 
> Date: 12/17/18 3:15 pm
> To: "Ettus Mail List" 
> 
>  OK, I see the first mistake.  I was copying-and-pasting my notes for the 
> E310 which had a different sysroot.  Once I made the change to the proper 
> one, it seems like it got past the rfnoc issue (or I haven't hit it yet with 
> this new error).
>  
> I am not getting:
> - Found PkgConfig: 
> /opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config (found 
> version "0.29.2") 
> -- Found UHD: 
> /opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/libuhd.so
>  
> -- Found PythonLibs: 
> /opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/libpython2.7.so
>  (found suitable version "2.7.14", minimum required is "2") 
> CMake Warning at 
> /opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/share/cmake-3.10/Modules/FindQt4.cmake:620
>  (message):
>  /usr/bin/qmake-qt4 reported QT_INSTALL_LIBS as "/usr/lib64" but QtCore
>  could not be found there. Qt is NOT installed correctly for the target
>  build environment.
> Call Stack (most recent call first):
>  CMakeLists.txt:149 (find_package)
>  
> CMake Error at CMakeLists.txt:151 (message):
>  Qt not found.
>  
> -- Configuring incomplete, errors occurred!
> See also 
> "/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeOutput.log".
> See also 
> "/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeError.log".
>   
>  I feel like I had this issue before with an E310 build and Phil B had to 
> make mods to the toolchain.  Has anyone else seen and got around this?
>  
>  
>  
> - Original Message - Subject: cross-compiling for N310
> From: "Jason Matusiak" 
> Date: 12/17/18 1:35 pm
> To: "Ettus Mail List" 
> 
>  Has anyone successfully created a new build for an N310 (RFNoC version in 
> particular)?  I was going to bring it up to date, but seem to be having 
> issues.
>  
> I ran: uhd_images_downloader -t sdimg -v
> To get the *.sh image for cross-compiling: 
> oecore-x86_64-cortexa9hf-neon-toolchain-nodistro.0.sh
>  
> I then install it like I do for the E310.
>  
> I create a src directory and pull down uhd and its sub-module fpga-src.  I've 
> tried main, master, and UHD-3.13, and they all build fine, but give me issues 
> later on.  In my cmake I make sure to have -DENABLE_RFNOC=ON and I see it 
> checked when I run cmake-gui.
>  
> I then pull down gnuradio, and build like I normally do.
>  
> Lastly, I pull down gr-ettus.  When I run: cmake 
> -DCMAKE_TOOLCHAIN_FILE=$PREFIX/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
>  -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ..
>  
> It mostly works and then errors out with:
>  
> -- Found PkgConfig: 
> /opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config (found 
> version "0.29.2") 
> -- Found UHD: 
> /opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/libuhd.so
>  
> CMake Error at CMakeLists.txt:140 (message):
>  RFNoC not found.
>  
> -- Configuring incomplete, errors occurred!
> See also 
> "/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeOutput.log".
> See also 
> "/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeError.log".
>   
>  In the past, I thought that that usually means uhd was not built properly to 
> have RFNoC enabled, but it looks to me like it is here.
>  Anyone happen to see what I am missing here?
> 
> 
> 
> ___
> 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

Re: [USRP-users] E310 Kernel Sources

[Philip Balister via USRP-users]

On 12/17/2018 10:43 AM, Said Uçar via USRP-users wrote:
> Hi Philip,
> 
> 
> I tested the latest image in dropbox, it is worked too with debugfs.
> Then I tried to follow [1] for minimal image. However, I couldn't make
> it. Here is the problems I faced;
> 
> 1. bitbake gnuradio-minimal-image throws error while building
> 'rtimulib'. It complaines that couldn't find some Qt includes. I think
> this dependency comes from the file
> 'meta-ettus/conf/machine/ettus-e300.inc' . I removed the rtimulib and
> rtimulib-conf dependencies and able to finish build. However, there is
> no *.wic and *.bmap  files in directory
> 'tmp-glibc/deploy/images/ettus-e3xx-sg3'. Are there additional step to
> generate these images?

You might need to add the image recipe to RM_WORK_EXCLUDE in local.conf.
Don't recall if that is still needed.

> 
> 2. While building newly created recipe gnuradio-minimal-image.bb, it
> still builds the qt4-x11-free.bb. Shouldn't qt relevant recipes be
> discarded?

look in build/buildhistory and see if you can find which packages are
listing qt4 as a dependency. The see if you can drop the package or
change is build config not to need qt4

> 
> 3. I also see some wireless drivers also included the image. Since e310
> has no wi-fi, broadcom drivers still required or can it be removed? I'm
> trying to reduce both build time and image size.
> 

Well, I think they are there in case somon uses a usb wifi adapter.

I can't recall how they get in the image and I need to pack. Taking off
between now and Christmas.

Philip


> 
> Best Regards,
> 
> Said U.
> 
> 
> On 12/13/18 7:11 PM, Philip Balister wrote:
>> On 12/13/2018 11:06 AM, Philip Balister via USRP-users wrote:
>>> On 12/13/2018 08:26 AM, Said Uçar wrote:
>>>> Hi Philip,
>>>>
>>>>
>>>> Thank you for your effort, you help a lot! Last image you provided
>>>> worked without trouble and I managed to run batman in e310. I didn't
>>>> test the toolchain yet but I think it will work too. Besides, I
>>>> tried to
>>>> build whole image on my own and it worked also. At this point I have
>>>> some questions;
>>>>
>>>> 1. Although the batman works without trouble, to trace batman logs, I
>>>> need debugfs. When I tried to use batctl (since batman-adv implemented
>>>> as kernel module, to control batman they provide batctl application), I
>>>> given an error;
>>>>
>>>>              "Error - can't mount or find debugfs"
>>>>
>>>> How could I add debugfs to image?
>>> Do this:
>>>
>>> https://github.com/balister/meta-ettus-1/commit/5be7f1ef6c47315cc7fac7c957ed399ef7726ab1
>>>
>>>
>>> and this:
>>>
>>> https://github.com/balister/sdr-build/commit/e90faa63e79843f5193e6344d4bc30d8721fdeed
>>>
>> Or look on the dropbox later, I am going to kick a build with that in it.
>>
>> Philip
>>
>>> You don't really need to bump the submodule hash until the image is
>>> tested. I do it because the machine that builds the images for dropbox
>>> uses it.
>>>
>>>> 2. I tried to build image on a computer that has 128 Core processor and
>>>> 128GB RAM. It took almost 4 hours to complete. And I only built dev
>>>> image, not demo image. Can I remove some packages from image (if so,
>>>> how?) to reduce built time? It builds too many packages and I think we
>>>> don't need all of them.
>>>>
>>> How fast is the internet connection? the first time it is going to
>>> download a lot of source. It is saved for future builds (be careful no
>>> to delete the downloads directory) I do the build on 4+HT and like 16GB
>>> and 4 images + 2 sdks is like 6 hours.
>>>
>>> Review the image recipes here:
>>>
>>> https://github.com/balister/meta-sdr/tree/master/recipes-images/images
>>>
>>> If you are using gnuradio, you can use he PACKAGECONFIG variable to turn
>>> off unused features like qtgui. See:
>>> http://opensdr.com/posts/building-small-gnuradio-images/
>>>
>>>
>>>> 3. I believe at some point in future, we need to configure kernel for
>>>> our image, how can I tweak the kernel image before build? (I used 'make
>>>> menuconfig' for another device's kernel build once, but it wasn't built
>>>> with bitbake)
>>>>
>>> I sort of hinted how I do this above. I find config fraqments work work
>>> better than copying around the entire config file. Easier 

Re: [USRP-users] E310 Kernel Sources

[Philip Balister via USRP-users]

On 12/13/2018 11:06 AM, Philip Balister via USRP-users wrote:
> On 12/13/2018 08:26 AM, Said Uçar wrote:
>> Hi Philip,
>>
>>
>> Thank you for your effort, you help a lot! Last image you provided
>> worked without trouble and I managed to run batman in e310. I didn't
>> test the toolchain yet but I think it will work too. Besides, I tried to
>> build whole image on my own and it worked also. At this point I have
>> some questions;
>>
>> 1. Although the batman works without trouble, to trace batman logs, I
>> need debugfs. When I tried to use batctl (since batman-adv implemented
>> as kernel module, to control batman they provide batctl application), I
>> given an error;
>>
>>                 "Error - can't mount or find debugfs"
>>
>> How could I add debugfs to image?
> 
> Do this:
> 
> https://github.com/balister/meta-ettus-1/commit/5be7f1ef6c47315cc7fac7c957ed399ef7726ab1
> 
> and this:
> 
> https://github.com/balister/sdr-build/commit/e90faa63e79843f5193e6344d4bc30d8721fdeed

Or look on the dropbox later, I am going to kick a build with that in it.

Philip

> 
> You don't really need to bump the submodule hash until the image is
> tested. I do it because the machine that builds the images for dropbox
> uses it.
> 
>>
>> 2. I tried to build image on a computer that has 128 Core processor and
>> 128GB RAM. It took almost 4 hours to complete. And I only built dev
>> image, not demo image. Can I remove some packages from image (if so,
>> how?) to reduce built time? It builds too many packages and I think we
>> don't need all of them.
>>
> 
> How fast is the internet connection? the first time it is going to
> download a lot of source. It is saved for future builds (be careful no
> to delete the downloads directory) I do the build on 4+HT and like 16GB
> and 4 images + 2 sdks is like 6 hours.
> 
> Review the image recipes here:
> 
> https://github.com/balister/meta-sdr/tree/master/recipes-images/images
> 
> If you are using gnuradio, you can use he PACKAGECONFIG variable to turn
> off unused features like qtgui. See:
> http://opensdr.com/posts/building-small-gnuradio-images/
> 
> 
>> 3. I believe at some point in future, we need to configure kernel for
>> our image, how can I tweak the kernel image before build? (I used 'make
>> menuconfig' for another device's kernel build once, but it wasn't built
>> with bitbake)
>>
> 
> I sort of hinted how I do this above. I find config fraqments work work
> better than copying around the entire config file. Easier to move kernel
> version etc.
> 
> The Yocto Project Mega Manual is very useful:
> 
> https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html
> 
>>
>> Thank you again,
>>
>> Best Regards,
>>
>> Said U.
>>
>>
>> On 12/13/18 5:24 AM, Philip Balister wrote:
>>> OK Dropbox updated:
>>>
>>> https://www.dropbox.com/sh/6qfjjqlfzmyegyd/AABu45Ney1xRoen-NyJim5dGa?dl=0
>>>
>>> Thanks for testing.
>>>
>>> Philip
>>>
>>> On 12/12/2018 07:16 AM, Philip Balister via USRP-users wrote:
>>>> On 12/12/2018 05:42 AM, Said Uçar via USRP-users wrote:
>>>>> Hi Philip,
>>>>>
>>>>>
>>>>> I write the image you provided and it booted without trouble. I set the
>>>>> KERNELPATH to /usr/src/kernel. Then, I tried to build batman-adv module
>>>>> but failed at first, as expected. I given an error;
>>>>>
>>>>>              /bin/sh: scripts/basic/fixdep: No such file or directory
>>>>>
>>>>> Then I built all modules in kernel sources using the following
>>>>> commands;
>>>>>
>>>>>          cd /usr/src/kernel
>>>>>
>>>>>          make modules_prepare
>>>>>
>>>>>          make modules
>>>>>
>>>>>          make modules_install
>>>>>
>>>>> That took some time, but at the end I can manage to build batman
>>>>> without
>>>>> error. However, I couldn't use the build batman-adv.ko. When I tried to
>>>>> insmod the module, I given an error;
>>>>>
>>>>>          modprobe: ERROR: could not insert 'batman_adv': Unknown
>>>>> symbol in module, or unknown parameter (see dmesg)
>>>>>
>>>>> And the kernel log was;
>>>>>
>>>>>          [ 1896.210237] batman_adv

Re: [USRP-users] E310 Kernel Sources

[Philip Balister via USRP-users]

On 12/13/2018 08:26 AM, Said Uçar wrote:
> Hi Philip,
> 
> 
> Thank you for your effort, you help a lot! Last image you provided
> worked without trouble and I managed to run batman in e310. I didn't
> test the toolchain yet but I think it will work too. Besides, I tried to
> build whole image on my own and it worked also. At this point I have
> some questions;
> 
> 1. Although the batman works without trouble, to trace batman logs, I
> need debugfs. When I tried to use batctl (since batman-adv implemented
> as kernel module, to control batman they provide batctl application), I
> given an error;
> 
>                 "Error - can't mount or find debugfs"
> 
> How could I add debugfs to image?

Do this:

https://github.com/balister/meta-ettus-1/commit/5be7f1ef6c47315cc7fac7c957ed399ef7726ab1

and this:

https://github.com/balister/sdr-build/commit/e90faa63e79843f5193e6344d4bc30d8721fdeed

You don't really need to bump the submodule hash until the image is
tested. I do it because the machine that builds the images for dropbox
uses it.

> 
> 2. I tried to build image on a computer that has 128 Core processor and
> 128GB RAM. It took almost 4 hours to complete. And I only built dev
> image, not demo image. Can I remove some packages from image (if so,
> how?) to reduce built time? It builds too many packages and I think we
> don't need all of them.
> 

How fast is the internet connection? the first time it is going to
download a lot of source. It is saved for future builds (be careful no
to delete the downloads directory) I do the build on 4+HT and like 16GB
and 4 images + 2 sdks is like 6 hours.

Review the image recipes here:

https://github.com/balister/meta-sdr/tree/master/recipes-images/images

If you are using gnuradio, you can use he PACKAGECONFIG variable to turn
off unused features like qtgui. See:
http://opensdr.com/posts/building-small-gnuradio-images/


> 3. I believe at some point in future, we need to configure kernel for
> our image, how can I tweak the kernel image before build? (I used 'make
> menuconfig' for another device's kernel build once, but it wasn't built
> with bitbake)
> 

I sort of hinted how I do this above. I find config fraqments work work
better than copying around the entire config file. Easier to move kernel
version etc.

The Yocto Project Mega Manual is very useful:

https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html

> 
> Thank you again,
> 
> Best Regards,
> 
> Said U.
> 
> 
> On 12/13/18 5:24 AM, Philip Balister wrote:
>> OK Dropbox updated:
>>
>> https://www.dropbox.com/sh/6qfjjqlfzmyegyd/AABu45Ney1xRoen-NyJim5dGa?dl=0
>>
>> Thanks for testing.
>>
>> Philip
>>
>> On 12/12/2018 07:16 AM, Philip Balister via USRP-users wrote:
>>> On 12/12/2018 05:42 AM, Said Uçar via USRP-users wrote:
>>>> Hi Philip,
>>>>
>>>>
>>>> I write the image you provided and it booted without trouble. I set the
>>>> KERNELPATH to /usr/src/kernel. Then, I tried to build batman-adv module
>>>> but failed at first, as expected. I given an error;
>>>>
>>>>              /bin/sh: scripts/basic/fixdep: No such file or directory
>>>>
>>>> Then I built all modules in kernel sources using the following
>>>> commands;
>>>>
>>>>          cd /usr/src/kernel
>>>>
>>>>          make modules_prepare
>>>>
>>>>          make modules
>>>>
>>>>          make modules_install
>>>>
>>>> That took some time, but at the end I can manage to build batman
>>>> without
>>>> error. However, I couldn't use the build batman-adv.ko. When I tried to
>>>> insmod the module, I given an error;
>>>>
>>>>          modprobe: ERROR: could not insert 'batman_adv': Unknown
>>>> symbol in module, or unknown parameter (see dmesg)
>>>>
>>>> And the kernel log was;
>>>>
>>>>          [ 1896.210237] batman_adv: Unknown symbol crc32c (err 0)
>>> I think there is another kernel option needed:
>>>
>>> https://cateee.net/lkddb/web-lkddb/LIBCRC32C.html
>>>
>>> I'll make the change and kick off the sausage machine. Unfortunately it
>>> is set to do a clean build (to avoid a certain class of failures) so the
>>> build takes along time to create all the images and sdks, then another
>>> few hours to upload. Doing incremental builds locally would save you a
>>> lot of time:
>>>
>>> I think the README here will walk you through the process:
>>>
>>&

Re: [USRP-users] E310 Kernel Sources

[Philip Balister via USRP-users]

OK Dropbox updated:

https://www.dropbox.com/sh/6qfjjqlfzmyegyd/AABu45Ney1xRoen-NyJim5dGa?dl=0

Thanks for testing.

Philip

On 12/12/2018 07:16 AM, Philip Balister via USRP-users wrote:
> On 12/12/2018 05:42 AM, Said Uçar via USRP-users wrote:
>> Hi Philip,
>>
>>
>> I write the image you provided and it booted without trouble. I set the
>> KERNELPATH to /usr/src/kernel. Then, I tried to build batman-adv module
>> but failed at first, as expected. I given an error;
>>
>>             /bin/sh: scripts/basic/fixdep: No such file or directory
>>
>> Then I built all modules in kernel sources using the following commands;
>>
>>             cd /usr/src/kernel
>>
>>             make modules_prepare
>>
>>             make modules
>>
>>             make modules_install
>>
>> That took some time, but at the end I can manage to build batman without
>> error. However, I couldn't use the build batman-adv.ko. When I tried to
>> insmod the module, I given an error;
>>
>>             modprobe: ERROR: could not insert 'batman_adv': Unknown
>> symbol in module, or unknown parameter (see dmesg)
>>
>> And the kernel log was;
>>
>>             [ 1896.210237] batman_adv: Unknown symbol crc32c (err 0)
> 
> I think there is another kernel option needed:
> 
> https://cateee.net/lkddb/web-lkddb/LIBCRC32C.html
> 
> I'll make the change and kick off the sausage machine. Unfortunately it
> is set to do a clean build (to avoid a certain class of failures) so the
> build takes along time to create all the images and sdks, then another
> few hours to upload. Doing incremental builds locally would save you a
> lot of time:
> 
> I think the README here will walk you through the process:
> 
> https://github.com/balister/sdr-build/tree/rocko-e300
> 
> I'll let you know when the upload is done.
> 
>>
>>
>> The output of  'cat /proc/kallsyms | grep crc'  command;
>>
>>             c02cd8d8 t crc32c_cra_init
>>             c0303250 t crc32_generic_shift
>>             c03032d8 T crc32_le_shift
>>             c03032e4 T __crc32c_le_shift
>>             c03032f0 T crc32_le
>>             c0303438 T __crc32c_le
>>             c0303580 T crc32_be
>>             c030a2f0 t crc32_validate
>>             c091364c t crc32c_mod_init
>>
>> And I assume that crc32c module is exists? I stuck at this point, and
>> googling didn't helped.
>>
>>
>> There is one more thing, I asked the kernel upgrade process to the ETTUS
>> Support, they replied with the following;
>>
>>             "Upgrading the kernel would require you to port our drivers.
>> That probably isn't feasible."
> 
> Um, clearly that isn't an accurate statement. I've seen it done a few
> times, and Kurt Kiefer published his work which I built on to make these
> images.
> 
> Philip
> 
> 
>>
>>
>> Regarding that answer, how could you managed to build image with kernel
>> 4.9 for e310 devices?
>>
>>
>> Thank you again,
>>
>> Best Regards,
>>
>> Said U.
>>
>>
>> On 12/12/18 12:58 AM, Philip Balister wrote:
>>> On 12/10/2018 04:20 PM, Philip Balister via USRP-users wrote:
>>>> On 12/10/2018 03:03 AM, Said Uçar via USRP-users wrote:
>>>>> Hi Philip,
>>>>>
>>>>>
>>>>> Thank you for your answer. I believe the first option is simpler than
>>>>> the second. However, I'm not familiar to building and tweaking kernel.
>>>>> Is there a documentation for building and tweaking kernel for E300
>>>>> series? You are definitely right about the kernel version issue (batman
>>>>> did most of its features after kernel 4), I would like to test older
>>>>> version because it may be sufficient for us.
>>>> I don't have any docs that would help and don't know of any on the Ettus
>>>> site. I've had an idea that might help. I have a more recent build based
>>>> on the OpenEmbedded rocko branches that use a 4.9 kernel, I am adding
>>>> the kernel-devsrc package to the image. That should let you build the
>>>> kernel module on the device. No warranty though. The builder is running
>>>> now and it is a long job, I'll post a link to the updated images when
>>>> they are done.
>>> OK, the sausage machine spit out new images to try:
>>>
>>> https://www.dropbox.com/sh/6qfjjqlfzmyegyd/AABu45Ney1xRoen-NyJim5dGa?dl=0
>>>
>>> Use bmaptool to write to an SD card:
>>>
&g

Re: [USRP-users] E310 Kernel Sources

[Philip Balister via USRP-users]

On 12/12/2018 05:42 AM, Said Uçar via USRP-users wrote:
> Hi Philip,
> 
> 
> I write the image you provided and it booted without trouble. I set the
> KERNELPATH to /usr/src/kernel. Then, I tried to build batman-adv module
> but failed at first, as expected. I given an error;
> 
>             /bin/sh: scripts/basic/fixdep: No such file or directory
> 
> Then I built all modules in kernel sources using the following commands;
> 
>             cd /usr/src/kernel
> 
>             make modules_prepare
> 
>             make modules
> 
>             make modules_install
> 
> That took some time, but at the end I can manage to build batman without
> error. However, I couldn't use the build batman-adv.ko. When I tried to
> insmod the module, I given an error;
> 
>             modprobe: ERROR: could not insert 'batman_adv': Unknown
> symbol in module, or unknown parameter (see dmesg)
> 
> And the kernel log was;
> 
>             [ 1896.210237] batman_adv: Unknown symbol crc32c (err 0)

I think there is another kernel option needed:

https://cateee.net/lkddb/web-lkddb/LIBCRC32C.html

I'll make the change and kick off the sausage machine. Unfortunately it
is set to do a clean build (to avoid a certain class of failures) so the
build takes along time to create all the images and sdks, then another
few hours to upload. Doing incremental builds locally would save you a
lot of time:

I think the README here will walk you through the process:

https://github.com/balister/sdr-build/tree/rocko-e300

I'll let you know when the upload is done.

> 
> 
> The output of  'cat /proc/kallsyms | grep crc'  command;
> 
>             c02cd8d8 t crc32c_cra_init
>             c0303250 t crc32_generic_shift
>             c03032d8 T crc32_le_shift
>             c03032e4 T __crc32c_le_shift
>             c03032f0 T crc32_le
>             c0303438 T __crc32c_le
>             c0303580 T crc32_be
>             c030a2f0 t crc32_validate
>             c091364c t crc32c_mod_init
> 
> And I assume that crc32c module is exists? I stuck at this point, and
> googling didn't helped.
> 
> 
> There is one more thing, I asked the kernel upgrade process to the ETTUS
> Support, they replied with the following;
> 
>             "Upgrading the kernel would require you to port our drivers.
> That probably isn't feasible."

Um, clearly that isn't an accurate statement. I've seen it done a few
times, and Kurt Kiefer published his work which I built on to make these
images.

Philip


> 
> 
> Regarding that answer, how could you managed to build image with kernel
> 4.9 for e310 devices?
> 
> 
> Thank you again,
> 
> Best Regards,
> 
> Said U.
> 
> 
> On 12/12/18 12:58 AM, Philip Balister wrote:
>> On 12/10/2018 04:20 PM, Philip Balister via USRP-users wrote:
>>> On 12/10/2018 03:03 AM, Said Uçar via USRP-users wrote:
>>>> Hi Philip,
>>>>
>>>>
>>>> Thank you for your answer. I believe the first option is simpler than
>>>> the second. However, I'm not familiar to building and tweaking kernel.
>>>> Is there a documentation for building and tweaking kernel for E300
>>>> series? You are definitely right about the kernel version issue (batman
>>>> did most of its features after kernel 4), I would like to test older
>>>> version because it may be sufficient for us.
>>> I don't have any docs that would help and don't know of any on the Ettus
>>> site. I've had an idea that might help. I have a more recent build based
>>> on the OpenEmbedded rocko branches that use a 4.9 kernel, I am adding
>>> the kernel-devsrc package to the image. That should let you build the
>>> kernel module on the device. No warranty though. The builder is running
>>> now and it is a long job, I'll post a link to the updated images when
>>> they are done.
>> OK, the sausage machine spit out new images to try:
>>
>> https://www.dropbox.com/sh/6qfjjqlfzmyegyd/AABu45Ney1xRoen-NyJim5dGa?dl=0
>>
>> Use bmaptool to write to an SD card:
>>
>> sudo bmaptool copy long-file-name /dev/sdX
>>
>> make sure the wic and bmap files are in the same directory.
>>
>> Completely untested. But the kernel dev sources should be available for
>> building OOT kernel modules.
>>
>> Good luck,
>>
>> Philip
>>
>>
>>> Philip
>>>
>>>>
>>>> Best Regards,
>>>>
>>>>
>>>> On 12/7/18 9:48 PM, Philip Balister wrote:
>>>>> On 12/05/2018 04:05 AM, Said Uçar via USRP-users wrote:
>>>>>> Hi all,
>>>>>>
>>&

Re: [USRP-users] E310 Kernel Sources

[Philip Balister via USRP-users]

On 12/10/2018 04:20 PM, Philip Balister via USRP-users wrote:
> On 12/10/2018 03:03 AM, Said Uçar via USRP-users wrote:
>> Hi Philip,
>>
>>
>> Thank you for your answer. I believe the first option is simpler than
>> the second. However, I'm not familiar to building and tweaking kernel.
>> Is there a documentation for building and tweaking kernel for E300
>> series? You are definitely right about the kernel version issue (batman
>> did most of its features after kernel 4), I would like to test older
>> version because it may be sufficient for us.
> 
> I don't have any docs that would help and don't know of any on the Ettus
> site. I've had an idea that might help. I have a more recent build based
> on the OpenEmbedded rocko branches that use a 4.9 kernel, I am adding
> the kernel-devsrc package to the image. That should let you build the
> kernel module on the device. No warranty though. The builder is running
> now and it is a long job, I'll post a link to the updated images when
> they are done.

OK, the sausage machine spit out new images to try:

https://www.dropbox.com/sh/6qfjjqlfzmyegyd/AABu45Ney1xRoen-NyJim5dGa?dl=0

Use bmaptool to write to an SD card:

sudo bmaptool copy long-file-name /dev/sdX

make sure the wic and bmap files are in the same directory.

Completely untested. But the kernel dev sources should be available for
building OOT kernel modules.

Good luck,

Philip


> 
> Philip
> 
>>
>>
>> Best Regards,
>>
>>
>> On 12/7/18 9:48 PM, Philip Balister wrote:
>>> On 12/05/2018 04:05 AM, Said Uçar via USRP-users wrote:
>>>> Hi all,
>>>>
>>>>
>>>> I'm trying to build batman-adv^[1] for E310 however it required the
>>>> kernel sources since it builds /batman-adv.ko/ kernel object. I built
>>>> the batctl^[2] and alfred^[3] without problem. I searched on the
>>>> internet for kernel sources however couldn't find it. Is there a way to
>>>> build batman for e310?
>>>>
>>> So a couple of approaches to take:
>>>
>>> 1) Build the E300 linux distro locally and add recipes for the kernel
>>> module and other parts of the software.
>>>
>>> 2) Inspect the linux kernel recipe used on the E300 and build a local
>>> git tree, and copy the kernel config from the build area. Then build the
>>> module against those sources.
>>>
>>> Both are fairly straightforward, but you'll need to figure out some
>>> OpenEmbedded stuff. All the information is a available to you.
>>>
>>> I did peek at the kernel module to see if it would build aainst a 3.14
>>> kernel. They do have an ifdef for kernels below 4.0, but it is clear
>>> most work is targeted at later kernels.
>>>
>>> Good luck!
>>>
>>> Philip
>>>
>>>
>>>
>>>>
>>>> Here is the output of 'uname -a':
>>>>
>>>>     Linux ettus-e3xx-sg3 3.14.2-xilinx #1 SMP PREEMPT Thu Jan 7 14:49:20
>>>>     PST 2016 armv7l GNU/Linux
>>>>
>>>>
>>>> [1] = https://git.open-mesh.org/batman-adv.git
>>>>
>>>> [2] = https://git.open-mesh.org/batctl.git
>>>>
>>>> [3] = https://git.open-mesh.org/alfred.git
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>>
>>>>
>>>> ___
>>>> 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.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

Re: [USRP-users] E310 Kernel Sources

[Philip Balister via USRP-users]

On 12/10/2018 03:03 AM, Said Uçar via USRP-users wrote:
> Hi Philip,
> 
> 
> Thank you for your answer. I believe the first option is simpler than
> the second. However, I'm not familiar to building and tweaking kernel.
> Is there a documentation for building and tweaking kernel for E300
> series? You are definitely right about the kernel version issue (batman
> did most of its features after kernel 4), I would like to test older
> version because it may be sufficient for us.

I don't have any docs that would help and don't know of any on the Ettus
site. I've had an idea that might help. I have a more recent build based
on the OpenEmbedded rocko branches that use a 4.9 kernel, I am adding
the kernel-devsrc package to the image. That should let you build the
kernel module on the device. No warranty though. The builder is running
now and it is a long job, I'll post a link to the updated images when
they are done.

Philip

> 
> 
> Best Regards,
> 
> 
> On 12/7/18 9:48 PM, Philip Balister wrote:
>> On 12/05/2018 04:05 AM, Said Uçar via USRP-users wrote:
>>> Hi all,
>>>
>>>
>>> I'm trying to build batman-adv^[1] for E310 however it required the
>>> kernel sources since it builds /batman-adv.ko/ kernel object. I built
>>> the batctl^[2] and alfred^[3] without problem. I searched on the
>>> internet for kernel sources however couldn't find it. Is there a way to
>>> build batman for e310?
>>>
>> So a couple of approaches to take:
>>
>> 1) Build the E300 linux distro locally and add recipes for the kernel
>> module and other parts of the software.
>>
>> 2) Inspect the linux kernel recipe used on the E300 and build a local
>> git tree, and copy the kernel config from the build area. Then build the
>> module against those sources.
>>
>> Both are fairly straightforward, but you'll need to figure out some
>> OpenEmbedded stuff. All the information is a available to you.
>>
>> I did peek at the kernel module to see if it would build aainst a 3.14
>> kernel. They do have an ifdef for kernels below 4.0, but it is clear
>> most work is targeted at later kernels.
>>
>> Good luck!
>>
>> Philip
>>
>>
>>
>>>
>>> Here is the output of 'uname -a':
>>>
>>>     Linux ettus-e3xx-sg3 3.14.2-xilinx #1 SMP PREEMPT Thu Jan 7 14:49:20
>>>     PST 2016 armv7l GNU/Linux
>>>
>>>
>>> [1] = https://git.open-mesh.org/batman-adv.git
>>>
>>> [2] = https://git.open-mesh.org/batctl.git
>>>
>>> [3] = https://git.open-mesh.org/alfred.git
>>>
>>>
>>> Best Regards,
>>>
>>>
>>>
>>> ___
>>> 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.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E310 Kernel Sources

[Philip Balister via USRP-users]

On 12/05/2018 04:05 AM, Said Uçar via USRP-users wrote:
> Hi all,
> 
> 
> I'm trying to build batman-adv^[1] for E310 however it required the
> kernel sources since it builds /batman-adv.ko/ kernel object. I built
> the batctl^[2] and alfred^[3] without problem. I searched on the
> internet for kernel sources however couldn't find it. Is there a way to
> build batman for e310?
> 

So a couple of approaches to take:

1) Build the E300 linux distro locally and add recipes for the kernel
module and other parts of the software.

2) Inspect the linux kernel recipe used on the E300 and build a local
git tree, and copy the kernel config from the build area. Then build the
module against those sources.

Both are fairly straightforward, but you'll need to figure out some
OpenEmbedded stuff. All the information is a available to you.

I did peek at the kernel module to see if it would build aainst a 3.14
kernel. They do have an ifdef for kernels below 4.0, but it is clear
most work is targeted at later kernels.

Good luck!

Philip



> 
> 
> Here is the output of 'uname -a':
> 
>    Linux ettus-e3xx-sg3 3.14.2-xilinx #1 SMP PREEMPT Thu Jan 7 14:49:20
>    PST 2016 armv7l GNU/Linux
> 
> 
> [1] = https://git.open-mesh.org/batman-adv.git
> 
> [2] = https://git.open-mesh.org/batctl.git
> 
> [3] = https://git.open-mesh.org/alfred.git
> 
> 
> Best Regards,
> 
> 
> 
> ___
> 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

Re: [USRP-users] upgrading gcc on the E310

[Philip Balister via USRP-users]

On 11/05/2018 07:58 AM, Jason Matusiak via USRP-users wrote:
> (sorry for the hijack, but I felt it was somewhat on topic)
>  

Barely :)

Basically, kernel config fragments are your friend, study this change
and others like it:

https://github.com/balister/meta-ettus-1/commit/aa0e2d12c5114269b3a94dfbebd433e4fd11826d#diff-9b732ab86ef3483bb0e54684c28fd84b

Philip

> Just curious, I am sure there is a good reason, but why can't we build in our 
> own custom drivers (I am not a low-level linux guy, so I am sure it is 
> probably obvious)?  So far we have been OK, but we have been a little nervous 
> with some of our USB devices attached to the E310 that they might not be 
> supported and then we would be SOL.  Will the updated Linux build now allow 
> this?
>  
>  
> - Original Message - Subject: Re: [USRP-users] upgrading gcc 
> on the E310
> From: "Philip Balister via USRP-users" 
> Date: 11/3/18 6:31 pm
> To: "Luke Whittlesey" 
> Cc: usrp-users@lists.ettus.com
> 
> On 11/03/2018 10:33 AM, Luke Whittlesey via USRP-users wrote:
>  > Thank you! I'll give the new image a try. I was struggling getting a newer
>  > version of gcc installed from source.
>  > I hadn't heard of bmaptool, so thanks for the introduction.
>  
>  It is much better than dd, and pretty much eliminates the risk of wiping
>  your hard drive. That was a bad day :)
>  
>  Philip
>  
>  > 
>  > Thanks,
>  > Luke
>  > 
>  > On Fri, Nov 2, 2018 at 3:51 PM Philip Balister  wrote:
>  > 
>  >> On 11/01/2018 04:56 PM, Luke Whittlesey via USRP-users wrote:
>  >>> Hello,
>  >>> The e310 comes with an older version of gcc (4.9.2). Is there a
>  >> recommended
>  >>> way to upgrade gcc?
>  >>
>  >> I had similar issues and assembled some updates that include a more
>  >> recent gcc:
>  >>
>  >> https://www.dropbox.com/sh/6qfjjqlfzmyegyd/AABu45Ney1xRoen-NyJim5dGa?dl=0
>  >>
>  >> Get the .wic and corresponding bmap file and use bmaptool to write an DS
>  >> card
>  >>
>  >> sudo bmaptool copy foo.wic /dev/mySDcard
>  >>
>  >> Philip
>  >>
>  >>
>  >>>
>  >>> Thanks,
>  >>> Luke
>  >>>
>  >>>
>  >>>
>  >>> ___
>  >>> 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.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.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] upgrading gcc on the E310

[Philip Balister via USRP-users]

On 11/03/2018 10:33 AM, Luke Whittlesey via USRP-users wrote:
> Thank you! I'll give the new image a try. I was struggling getting a newer
> version of gcc installed from source.
> I hadn't heard of bmaptool, so thanks for the introduction.

It is much better than dd, and pretty much eliminates the risk of wiping
your hard drive. That was a bad day :)

Philip

> 
> Thanks,
> Luke
> 
> On Fri, Nov 2, 2018 at 3:51 PM Philip Balister  wrote:
> 
>> On 11/01/2018 04:56 PM, Luke Whittlesey via USRP-users wrote:
>>> Hello,
>>> The e310 comes with an older version of gcc (4.9.2). Is there a
>> recommended
>>> way to upgrade gcc?
>>
>> I had similar issues and assembled some updates that include a more
>> recent gcc:
>>
>> https://www.dropbox.com/sh/6qfjjqlfzmyegyd/AABu45Ney1xRoen-NyJim5dGa?dl=0
>>
>> Get the .wic and corresponding bmap file and use bmaptool to write an DS
>> card
>>
>> sudo bmaptool copy foo.wic /dev/mySDcard
>>
>> Philip
>>
>>
>>>
>>> Thanks,
>>> Luke
>>>
>>>
>>>
>>> ___
>>> 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.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] upgrading gcc on the E310

[Philip Balister via USRP-users]

On 11/01/2018 04:56 PM, Luke Whittlesey via USRP-users wrote:
> Hello,
> The e310 comes with an older version of gcc (4.9.2). Is there a recommended
> way to upgrade gcc?

I had similar issues and assembled some updates that include a more
recent gcc:

https://www.dropbox.com/sh/6qfjjqlfzmyegyd/AABu45Ney1xRoen-NyJim5dGa?dl=0

Get the .wic and corresponding bmap file and use bmaptool to write an DS
card

sudo bmaptool copy foo.wic /dev/mySDcard

Philip


> 
> Thanks,
> Luke
> 
> 
> 
> ___
> 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

Re: [USRP-users] E310 - Store last leap seconds value from GPS

[Philip Balister via USRP-users]

On 10/11/2018 10:08 AM, David Zamorano Fernández via USRP-users wrote:
> Hi all!
> 
> Each time I turn on the E310 and the GPS is synchronized I have a
> difference of 15 seconds between the GPS time and the UTC time. To have the
> appropriate leap seconds, 18, it is necessary to wait to receive the GPS
> almanac. Is it possible to save this value of leap seconds so that in later
> executions it has the correct time? Whenever I turn on the USRP, even
> though the E310 has been working for hours, I always have this problem.
> 
> Attached is a screenshot of the cgps execution in two USRPs. One has the
> correct time (leap seconds = 18) and the other has the UTC time with three
> more seconds (leap seconds = 15).

So this number is basically a constant until the next leap second? It
seems like ntpd should have a way of knowing, especially when using a
gps time source. I did some quick googling and didn't find an answer,
but it feels like this isn't a unique problem and someone else should
have a solution.

And time has always made my head hurt :)

Philip


> 
> Regards,
> David.
> 
> --
> 
> 
> [image: logo_170x100px.png] 
> 
> 
> 
> David Zamorano Fernández
> Investigador - Desarrollador | Área de Comunicaciones Avanzadas
> Researcher - Developer | Advanced Communications Department
> 
> 
> 
> Ph. (+34) 986 120 430  Ext. 3012
> dzamor...@gradiant.org   |  www.gradiant.org
> 
> [image: Iconos Redes Sociales GRD Firma email-01]
>   [image: Iconos Redes Sociales GRD
> Firma email-02]   [image: Iconos Redes
> Sociales GRD Firma email-03] 
>  [image: Iconos Redes Sociales GRD Firma email-04]
> 
> Take care of the environment. Try not to print this email.
> The information contained in this email message may be confidential
> information, and may also be the subject of legal professional privilege.
> If you are not the intended recipient, any use, interference with,
> disclosure or copying of this material is unauthorized and prohibited.
> Please inform us immediately and destroy the email. Thank you for your
> cooperation.
> 
> 
> 
> ___
> 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

Re: [USRP-users] installing rfnoc using pybombs

[Philip Balister via USRP-users]

On 09/11/2018 01:17 PM, Jason Matusiak via USRP-users wrote:
> Rob,
>  
> Honestly, it seems like stuff has gotten sideways all over the place.  Things 
> I used to be able to do are no longer working (granted, I am working on an 
> E310, so that increases the complexities).
>  
> Try this instruction though: 
> https://github.com/gnuradio/gnuradio/issues/1706#issuecomment-408298178
>  
> It helped me in one particular case.  I have no idea what will happen 
> long-term making that change.

I think the problem is an sdk containing an older uhd. This leads to the
header clash. I haven't confirmed this.

The fix is someone sends me a pull request for meta-sdr with a working
update to uhd (including fpga packaging updates).

The other thing you can do is after building uhd, you can "install" the
output back into the sdk. Not optimal, but should solve the problem.

Another idea is make an sdk with all packages needed for gnuradio and
uhd, but not containing them. Once again, a pull rwuest adding such an
sdk to meta-sdr would be welcome.

It isn't that hard, you just need specialized knowledge and time to test
the output for a few cases.

Philip


>  
>  
> - Original Message - Subject: [USRP-users] installing rfnoc 
> using pybombs
> From: "Rob Kossler via USRP-users" 
> Date: 9/11/18 1:06 pm
> To: "usrp-users" 
> 
>Hi,
> I just tried to install rfnoc using pybombs according to the RFNoC getting 
> started guide.  The build fails with the following messages during the 
> gnuradio build.  Any way around this?
> Rob
>  
> [ 88%] Built target tags_demo
> [ 88%] Built target _uhd_swig_doc_tag
> [ 88%] Built target uhd_swig_swig_doc
> [ 88%] Built target _uhd_swig_swig_tag
> [ 88%] Built target uhd_swig_gr_uhd_swig_5e3ce
> [ 88%] Building CXX object 
> gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o
> /home/irisheyes1/rfnoc/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:
>  In function 'PyObject* _wrap_time_spec_t_get_system_time(PyObject*, 
> PyObject*)':
> /home/irisheyes1/rfnoc/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:19511:16:
>  error: 'get_system_time' is not a member of 'uhd::time_spec_t'
>result = uhd::time_spec_t::get_system_time();
> ^
> /home/irisheyes1/rfnoc/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:
>  In function 'PyObject* _wrap_dboard_iface_set_gpio_debug(PyObject*, 
> PyObject*, PyObject*)':
> /home/irisheyes1/rfnoc/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:27597:15:
>  error: 'class uhd::usrp::dboard_iface' has no member named 'set_gpio_debug'
>(arg1)->set_gpio_debug(arg2,arg3);
>^
> /home/irisheyes1/rfnoc/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:
>  In function 'PyObject* _wrap_dboard_iface_sptr_set_gpio_debug(PyObject*, 
> PyObject*, PyObject*)':
> /home/irisheyes1/rfnoc/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:28960:16:
>  error: 'class uhd::usrp::dboard_iface' has no member named 'set_gpio_debug'
>(*arg1)->set_gpio_debug(arg2,arg3);
> 
> 
> 
> 
> ___ 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.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)

[Philip Balister via USRP-users]

On 09/06/2018 02:52 PM, Philip Balister via USRP-users wrote:
> On 09/06/2018 08:52 AM, Jason Matusiak wrote:
>> Just finished running the second command just mentioned below, still died 
>> with the package "six" error.
> 
> I found the problem, will regenerate images and sdk tonight and update
> Dropbox in the morning. Thanks for testing this and finding I still had
> an issue with the E300 sdk.

Jason, give this a shot if you can:

https://www.dropbox.com/sh/6qfjjqlfzmyegyd/AABu45Ney1xRoen-NyJim5dGa?dl=0

Philip


> 
> Philip
> 
>>  
>>  
>> - Original Message - Subject: RE: Re: [USRP-users] Issues 
>> installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)
>> From: "Jason Matusiak" 
>> Date: 9/6/18 8:44 am
>> To: "Philip Balister" 
>> Cc: "USRP-users@lists.ettus.com" 
>>
>>  Thanks Philip, that will be very helpful.  Will the steps be the same as 
>> before? :
>>  
>> 1 - sh ./oecore-x86_64-armv7ahf-neon-toolchain-nodistro.0.sh
>> 2 - pybombs prefix init /opt/gnuradio/e300 -R e3xx-rfnoc -a e300
>>  
>> Or will something need to change there?
>>  
>> - Original Message - Subject: Re: [USRP-users] Issues 
>> installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)
>> From: "Philip Balister" 
>> Date: 9/5/18 3:35 pm
>> To: "Jason Matusiak" 
>> Cc: "USRP-users@lists.ettus.com" 
>>
>> On 09/05/2018 03:25 PM, Jason Matusiak via USRP-users wrote:
>>  > Philip, I know I am digging this up from early in the year, but I didn't 
>> see an answer. I am having the exact same issue with the six package. Were 
>> you ever able to fix this?
>>  
>>  Pretty sure the sdk from here is fixed:
>>  
>>  https://www.dropbox.com/sh/4w19l8ixwm2ke24/AAB3aGPAkjqe9SvG32TsyK5Ia?dl=0
>>  
>>  These are newer images based of rocko I ended creating out of another
>>  job. Posted in case others find them useful.
>>  
>>  Philip
>>  
>>  > 
>>  > 
>>  > - Original Message - On 04/02/2018 06:58 PM, Marcus D. 
>> Leech wrote:
>>  > > On 04/02/2018 06:09 PM, Philip Balister wrote:
>>  > >> On 04/02/2018 05:01 PM, MASDR GS wrote:
>>  > >>> I'm having issues with installing GNU radio using PYBOMBS. It
>>  > >>> successfully
>>  > >>> installs the SDK and UHD but once it reaches to GNU Radio I receive a
>>  > >>> missing python six message. I have been using this guide from Ettus 
>> for
>>  > >>> reference.
>>  > >>>
>>  > >>> 
>> https://kb.ettus.com/Software_Development_on_the_E310_and_E312#Preparation_using_PyBOMBS
>>  > >>>
>>  > >>>
>>  > >>>
>>  > >>> -- Python checking for six - python 2 and 3 compatibility library - 
>> not
>>  > >>> found
>>  > >>> CMake Error at volk/CMakeLists.txt:93 (message):
>>  > >>> six - python 2 and 3 compatibility library required to build VOLK
>>  > >>>
>>  > >> Looks like the volk added a dependency on python-six and the E300 image
>>  > >> doesn't have it. Ettus needs to create a new file system image with 
>> that
>>  > >> package installed.
>>  > >>
>>  > >> Philip
>>  > > WHile that is actually, true, in this case the user is doing
>>  > > cross-builds on their PC host, and had installed python-six into their
>>  > > cross-build
>>  > > environment, and still no joy.
>>  > 
>>  > Adding python-six-native cleared up my build issue. Likely the real
>>  > solution is regenerate the sdk including the native-sdk version of
>>  > python-six.
>>  > 
>>  > I'll poke meta-sdr for this soon to cover other users.
>>  > 
>>  > Philip
>>  > 
>>  > >
>>  > >
>>  > >>
>>  > >>> -- Configuring incomplete, errors occurred!
>>  > >>>
>>  > >>>
>>  > >>> Someone also posted the same issue but I couldn't find a response to 
>> his
>>  > >>> question along with how to bypass this error. I've tried installing 
>> the
>>  > >>> lastest version of python six-1.11.0 onto my local computer still but
>>  > >>> having no luck. Any guidance or help is appreciated.
>>  > >>>
>>  >

Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)

[Philip Balister via USRP-users]

On 09/06/2018 08:52 AM, Jason Matusiak wrote:
> Just finished running the second command just mentioned below, still died 
> with the package "six" error.

I found the problem, will regenerate images and sdk tonight and update
Dropbox in the morning. Thanks for testing this and finding I still had
an issue with the E300 sdk.

Philip

>  
>  
> - Original Message - Subject: RE: Re: [USRP-users] Issues 
> installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)
> From: "Jason Matusiak" 
> Date: 9/6/18 8:44 am
> To: "Philip Balister" 
> Cc: "USRP-users@lists.ettus.com" 
> 
>  Thanks Philip, that will be very helpful.  Will the steps be the same as 
> before? :
>  
> 1 - sh ./oecore-x86_64-armv7ahf-neon-toolchain-nodistro.0.sh
> 2 - pybombs prefix init /opt/gnuradio/e300 -R e3xx-rfnoc -a e300
>  
> Or will something need to change there?
>  
> - Original Message - Subject: Re: [USRP-users] Issues 
> installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)
> From: "Philip Balister" 
> Date: 9/5/18 3:35 pm
> To: "Jason Matusiak" 
> Cc: "USRP-users@lists.ettus.com" 
> 
> On 09/05/2018 03:25 PM, Jason Matusiak via USRP-users wrote:
>  > Philip, I know I am digging this up from early in the year, but I didn't 
> see an answer. I am having the exact same issue with the six package. Were 
> you ever able to fix this?
>  
>  Pretty sure the sdk from here is fixed:
>  
>  https://www.dropbox.com/sh/4w19l8ixwm2ke24/AAB3aGPAkjqe9SvG32TsyK5Ia?dl=0
>  
>  These are newer images based of rocko I ended creating out of another
>  job. Posted in case others find them useful.
>  
>  Philip
>  
>  > 
>  > 
>  > - Original Message - On 04/02/2018 06:58 PM, Marcus D. 
> Leech wrote:
>  > > On 04/02/2018 06:09 PM, Philip Balister wrote:
>  > >> On 04/02/2018 05:01 PM, MASDR GS wrote:
>  > >>> I'm having issues with installing GNU radio using PYBOMBS. It
>  > >>> successfully
>  > >>> installs the SDK and UHD but once it reaches to GNU Radio I receive a
>  > >>> missing python six message. I have been using this guide from Ettus for
>  > >>> reference.
>  > >>>
>  > >>> 
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312#Preparation_using_PyBOMBS
>  > >>>
>  > >>>
>  > >>>
>  > >>> -- Python checking for six - python 2 and 3 compatibility library - not
>  > >>> found
>  > >>> CMake Error at volk/CMakeLists.txt:93 (message):
>  > >>> six - python 2 and 3 compatibility library required to build VOLK
>  > >>>
>  > >> Looks like the volk added a dependency on python-six and the E300 image
>  > >> doesn't have it. Ettus needs to create a new file system image with that
>  > >> package installed.
>  > >>
>  > >> Philip
>  > > WHile that is actually, true, in this case the user is doing
>  > > cross-builds on their PC host, and had installed python-six into their
>  > > cross-build
>  > > environment, and still no joy.
>  > 
>  > Adding python-six-native cleared up my build issue. Likely the real
>  > solution is regenerate the sdk including the native-sdk version of
>  > python-six.
>  > 
>  > I'll poke meta-sdr for this soon to cover other users.
>  > 
>  > Philip
>  > 
>  > >
>  > >
>  > >>
>  > >>> -- Configuring incomplete, errors occurred!
>  > >>>
>  > >>>
>  > >>> Someone also posted the same issue but I couldn't find a response to 
> his
>  > >>> question along with how to bypass this error. I've tried installing the
>  > >>> lastest version of python six-1.11.0 onto my local computer still but
>  > >>> having no luck. Any guidance or help is appreciated.
>  > >>>
>  > >>> 
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-February/023677.html
>  > >>>
>  > >>>
>  > >>>
>  > >>>
>  > >>> ___
>  > >>> Discuss-gnuradio mailing list
>  > >>> address@hidden
>  > >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>  > >>>
>  > >> ___
>  > >> Discuss-gnuradio mailing list
>  > >> address@hidden
>  > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>  > >
>  > >
>  > > ___
>  > > Discuss-gnuradio mailing list
>  > > address@hidden
>  > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>  > >
>  > 
>  > 
>  > 
>  > ___
>  > 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

Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)

[Philip Balister via USRP-users]

On 09/06/2018 08:52 AM, Jason Matusiak wrote:
> Just finished running the second command just mentioned below, still died 
> with the package "six" error.

I looked at the sdk manifest in Dropbox and don't see the python-six
included, but it looks like the sdk should. Going to run some builds
here, maybe just a matter of updating Dropbox from the output of the
Jenkins job doing test builds.

Philip

>  
>  
> - Original Message - Subject: RE: Re: [USRP-users] Issues 
> installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)
> From: "Jason Matusiak" 
> Date: 9/6/18 8:44 am
> To: "Philip Balister" 
> Cc: "USRP-users@lists.ettus.com" 
> 
>  Thanks Philip, that will be very helpful.  Will the steps be the same as 
> before? :
>  
> 1 - sh ./oecore-x86_64-armv7ahf-neon-toolchain-nodistro.0.sh
> 2 - pybombs prefix init /opt/gnuradio/e300 -R e3xx-rfnoc -a e300
>  
> Or will something need to change there?
>  
> - Original Message - Subject: Re: [USRP-users] Issues 
> installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)
> From: "Philip Balister" 
> Date: 9/5/18 3:35 pm
> To: "Jason Matusiak" 
> Cc: "USRP-users@lists.ettus.com" 
> 
> On 09/05/2018 03:25 PM, Jason Matusiak via USRP-users wrote:
>  > Philip, I know I am digging this up from early in the year, but I didn't 
> see an answer. I am having the exact same issue with the six package. Were 
> you ever able to fix this?
>  
>  Pretty sure the sdk from here is fixed:
>  
>  https://www.dropbox.com/sh/4w19l8ixwm2ke24/AAB3aGPAkjqe9SvG32TsyK5Ia?dl=0
>  
>  These are newer images based of rocko I ended creating out of another
>  job. Posted in case others find them useful.
>  
>  Philip
>  
>  > 
>  > 
>  > - Original Message - On 04/02/2018 06:58 PM, Marcus D. 
> Leech wrote:
>  > > On 04/02/2018 06:09 PM, Philip Balister wrote:
>  > >> On 04/02/2018 05:01 PM, MASDR GS wrote:
>  > >>> I'm having issues with installing GNU radio using PYBOMBS. It
>  > >>> successfully
>  > >>> installs the SDK and UHD but once it reaches to GNU Radio I receive a
>  > >>> missing python six message. I have been using this guide from Ettus for
>  > >>> reference.
>  > >>>
>  > >>> 
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312#Preparation_using_PyBOMBS
>  > >>>
>  > >>>
>  > >>>
>  > >>> -- Python checking for six - python 2 and 3 compatibility library - not
>  > >>> found
>  > >>> CMake Error at volk/CMakeLists.txt:93 (message):
>  > >>> six - python 2 and 3 compatibility library required to build VOLK
>  > >>>
>  > >> Looks like the volk added a dependency on python-six and the E300 image
>  > >> doesn't have it. Ettus needs to create a new file system image with that
>  > >> package installed.
>  > >>
>  > >> Philip
>  > > WHile that is actually, true, in this case the user is doing
>  > > cross-builds on their PC host, and had installed python-six into their
>  > > cross-build
>  > > environment, and still no joy.
>  > 
>  > Adding python-six-native cleared up my build issue. Likely the real
>  > solution is regenerate the sdk including the native-sdk version of
>  > python-six.
>  > 
>  > I'll poke meta-sdr for this soon to cover other users.
>  > 
>  > Philip
>  > 
>  > >
>  > >
>  > >>
>  > >>> -- Configuring incomplete, errors occurred!
>  > >>>
>  > >>>
>  > >>> Someone also posted the same issue but I couldn't find a response to 
> his
>  > >>> question along with how to bypass this error. I've tried installing the
>  > >>> lastest version of python six-1.11.0 onto my local computer still but
>  > >>> having no luck. Any guidance or help is appreciated.
>  > >>>
>  > >>> 
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-February/023677.html
>  > >>>
>  > >>>
>  > >>>
>  > >>>
>  > >>> ___
>  > >>> Discuss-gnuradio mailing list
>  > >>> address@hidden
>  > >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>  > >>>
>  > >> ___
>  > >> Discuss-gnuradio mailing list
>  > >> address@hidden
>  > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>  > >
>  > >
>  > > ___
>  > > Discuss-gnuradio mailing list
>  > > address@hidden
>  > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>  > >
>  > 
>  > 
>  > 
>  > ___
>  > 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

Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)

[Philip Balister via USRP-users]

On 09/05/2018 03:25 PM, Jason Matusiak via USRP-users wrote:
> Philip, I know I am digging this up from early in the year, but I didn't see 
> an answer.  I am having the exact same issue with the six package.  Were you 
> ever able to fix this?

Pretty sure the sdk from here is fixed:

https://www.dropbox.com/sh/4w19l8ixwm2ke24/AAB3aGPAkjqe9SvG32TsyK5Ia?dl=0

These are newer images based of rocko I ended creating out of another
job. Posted in case others find them useful.

Philip

>  
>  
> - Original Message -On 04/02/2018 06:58 PM, Marcus D. 
> Leech wrote:
>  > On 04/02/2018 06:09 PM, Philip Balister wrote:
>  >> On 04/02/2018 05:01 PM, MASDR GS wrote:
>  >>> I'm having issues with installing GNU radio using PYBOMBS. It
>  >>> successfully
>  >>> installs the SDK and UHD but once it reaches to GNU Radio I receive a
>  >>> missing python six message. I have been using this guide from Ettus for
>  >>> reference.
>  >>>
>  >>> 
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312#Preparation_using_PyBOMBS
>  >>>
>  >>>
>  >>>
>  >>> -- Python checking for six - python 2 and 3 compatibility library - not
>  >>> found
>  >>> CMake Error at volk/CMakeLists.txt:93 (message):
>  >>>six - python 2 and 3 compatibility library required to build VOLK
>  >>>
>  >> Looks like the volk added a dependency on python-six and the E300 image
>  >> doesn't have it. Ettus needs to create a new file system image with that
>  >> package installed.
>  >>
>  >> Philip
>  > WHile that is actually, true, in this case the user is doing
>  > cross-builds on their PC host, and had installed python-six into their
>  > cross-build
>  >   environment, and still no joy.
>  
>  Adding python-six-native cleared up my build issue. Likely the real
>  solution is regenerate the sdk including the native-sdk version of
>  python-six.
>  
>  I'll poke meta-sdr for this soon to cover other users.
>  
>  Philip
>  
>  >
>  >
>  >>
>  >>> -- Configuring incomplete, errors occurred!
>  >>>
>  >>>
>  >>> Someone also posted the same issue but I couldn't find a response to his
>  >>> question along with how  to bypass this error. I've tried installing the
>  >>> lastest version of  python six-1.11.0 onto my local computer still but
>  >>> having no luck. Any guidance or help is appreciated.
>  >>>
>  >>> 
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-February/023677.html
>  >>>
>  >>>
>  >>>
>  >>>
>  >>> ___
>  >>> Discuss-gnuradio mailing list
>  >>> address@hidden
>  >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>  >>>
>  >> ___
>  >> Discuss-gnuradio mailing list
>  >> address@hidden
>  >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>  >
>  >
>  > ___
>  > Discuss-gnuradio mailing list
>  > address@hidden
>  > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>  >
> 
> 
> 
> ___
> 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

Re: [USRP-users] Error Installing the SDK (& UHD, GNURadio) for E310 Using Ettus-Pybombs

[Philip Balister via USRP-users]

Try an image from here:

https://www.dropbox.com/sh/4w19l8ixwm2ke24/AAB3aGPAkjqe9SvG32TsyK5Ia?dl=0

pretty sure they include python-six. If not, I can easily add it.

Philip

On 07/29/2018 01:42 AM, shachar J. brown via USRP-users wrote:
> Hi Everyone,
> 
> I have noticed the previous discussion on the matter from February 2017,
> but seemingly there hasn't been any resolution.
> 
> I have worked up till now on B210 and X310. I am now trying to set up a
> brand new E310.
> 
> I carefully followed the instructions given at
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312. I recloned
> all the mentioned recipes and started the instalation. To my utmost
> despair, I get the following error:
> 
> -- Python checking for six - python 2 and 3 compatibility library - not
> found
> CMake Error at volk/CMakeLists.txt:93 (message):
>   six - python 2 and 3 compatibility library required to build VOLK
> -- Configuring incomplete, errors occurred!
> 
> Please help!
> Steve
> 
> 
> 
> (Full output:
> 
> user@user-OptiPlex-7040:~$ pybombs recipes add gr-recipes git+
> https://github.com/gnuradio/gr-recipes.git
> PyBOMBS.ConfigManager - INFO - Prefix Python version is: 2.7.12
> PyBOMBS - INFO - PyBOMBS Version 2.3.3a0
> Alias `gr-recipes' already exists, overwrite Y/[N]? Y
> PyBOMBS.recipes - WARNING - Cache dir
> /home/user/.pybombs/recipes/gr-recipes for remote recipe location
> gr-recipes already exists! Deleting.
> Cloning into 'gr-recipes'...
> remote: Counting objects: 1599, done.
> remote: Total 1599 (delta 0), reused 0 (delta 0), pack-reused 1599
> Receiving objects: 100% (1599/1599), 308.46 KiB | 0 bytes/s, done.
> Resolving deltas: 100% (1331/1331), done.
> Checking connectivity... done.
> user@user-OptiPlex-7040:~$ pybombs recipes add gr-etcetera git+
> https://github.com/gnuradio/gr-etcetera.git
> PyBOMBS.ConfigManager - INFO - Prefix Python version is: 2.7.12
> PyBOMBS - INFO - PyBOMBS Version 2.3.3a0
> Alias `gr-etcetera' already exists, overwrite Y/[N]? Y
> PyBOMBS.recipes - WARNING - Cache dir
> /home/user/.pybombs/recipes/gr-etcetera for remote recipe location
> gr-etcetera already exists! Deleting.
> Cloning into 'gr-etcetera'...
> remote: Counting objects: 321, done.
> remote: Total 321 (delta 0), reused 0 (delta 0), pack-reused 321
> Receiving objects: 100% (321/321), 56.80 KiB | 0 bytes/s, done.
> Resolving deltas: 100% (218/218), done.
> Checking connectivity... done.
> user@user-OptiPlex-7040:~$ pybombs recipes add ettus
> https://github.com/EttusResearch/ettus-pybombs.git
> PyBOMBS.ConfigManager - INFO - Prefix Python version is: 2.7.12
> PyBOMBS - INFO - PyBOMBS Version 2.3.3a0
> Alias `ettus' already exists, overwrite Y/[N]? Y
> PyBOMBS.recipes - WARNING - Cache dir /home/user/.pybombs/recipes/ettus for
> remote recipe location ettus already exists! Deleting.
> Cloning into 'ettus'...
> remote: Counting objects: 61, done.
> remote: Total 61 (delta 0), reused 0 (delta 0), pack-reused 61
> Unpacking objects: 100% (61/61), done.
> Checking connectivity... done.
> user@user-OptiPlex-7040:~$ pybombs prefix init /home/user/prefix -R
> e3xx-rfnoc -a e310
> PyBOMBS.ConfigManager - INFO - Prefix Python version is: 2.7.12
> PyBOMBS - INFO - PyBOMBS Version 2.3.3a0
> PyBOMBS.prefix - INFO - Creating directory `/home/user/prefix'
> PyBOMBS.ConfigManager - INFO - Prefix Python version is: 2.7.12
> PyBOMBS.prefix - INFO - Installing SDK recipe e3xx-release4-sdk.
> PyBOMBS.prefix - INFO - Reloading configuration...
> PyBOMBS.ConfigManager - INFO - Prefix Python version is: 2.7.12
> /usr/local/lib/python2.7/dist-packages/pip/_vendor/requests/__init__.py:83:
> RequestsDependencyWarning: Old version of cryptography ([1, 2, 3]) may
> cause slowdown.
>   warnings.warn(warning, RequestsDependencyWarning)
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following packages were automatically installed and are no longer
> required:
>   culmus libappindicator1 libindicator7 linux-headers-4.13.0-36
>   linux-headers-4.13.0-36-generic linux-headers-4.13.0-37
>   linux-headers-4.13.0-37-generic linux-headers-4.13.0-38
>   linux-headers-4.13.0-38-generic linux-headers-4.13.0-39
>   linux-headers-4.13.0-39-generic linux-headers-4.13.0-41
>   linux-headers-4.13.0-41-generic linux-headers-4.13.0-43
>   linux-headers-4.13.0-43-generic linux-headers-4.8.0-36
>   linux-headers-4.8.0-36-generic linux-image-4.13.0-36-generic
>   linux-image-4.13.0-37-generic linux-image-4.13.0-38-generic
>   linux-image-4.13.0-39-generic linux-image-4.13.0-41-generic
>   linux-image-4.13.0-43-generic linux-image-4.8.0-36-generic
>   linux-image-extra-4.13.0-36-generic linux-image-extra-4.13.0-37-generic
>   linux-image-extra-4.13.0-38-generic linux-image-extra-4.13.0-39-generic
>   linux-image-extra-4.13.0-41-generic linux-image-extra-4.13.0-43-generic
>   linux-image-extra-4.8.0-36-generic snap-confine
> Use 'sudo apt autoremove' to remove them.
> The following additional packages 

Re: [USRP-users] [Discuss-gnuradio] [UHD] Coarse roadmap for USRP E310 Software

[Philip Balister via USRP-users]

On 07/17/2018 01:50 PM, Moritz Fischer via USRP-users wrote:
> Philip,
> 
> On Fri, Jul 13, 2018 at 8:03 AM, Philip Balister  wrote:
>> A couple of notes based on updating the E300 to rocko 
>>
>> 1) The N310 branch added a bbappend on something called salt which added
>> the need for the meta-openstack and meta-virtualization layers. For
>> basic E300 support, this is crazy layer bloat. I removed the bbappend.
>> If you really need it, I'd create a layer for specific applications,
>> salt seems to be some form of enterprise software config management
>> system ( https://en.wikipedia.org/wiki/Salt_(software) ) Certainly not
>> every E300 project needs this.
> 
> That's a good point, I'll look into making it more modular.
> 
>>
>> 2) The uhd recipe in meta-sdr needs updating. I'd suggest moving it to
>> meta-ettus, but it also supports users using other Ettus products with
>> other embedded hardware, so the recipe doesn't belong there. It would be
>> silly having to add the meta-ettus bsp to use a b200 with a pi-s.
> 
> I have made an attempt at splitting up meta-ettus more into separate layers,
> the result of that is on github (master). I was hesitant to push it public 
> since
> in it current form E31x does not work. N310 will move over to that (and the 
> sumo
> release with the next release).
> 
> Personally having the uhd recipe in meta-sdr was not convenient and we ended 
> up
> building most of the filesystems with bbappends to the UHD recipe
> anyways, so I've
> decided to host the UHD recipe in meta-ettus in a meta-ettus-core sublayer.

Well, moving it out of meta-sdr means I'll need to drop the uhd
packagegroups and have the default images not include any usrp hardware,
including things like the b200. Since uhd doesn't build in master, I'll
go ahead and drop uhd and associated bitsfrom meta-sdr there.

I suspect this might make things easier for engineering development, but
long term, I think it will be harder for end users to use usrps with
random dev boards. Time will tell.

Philip


> 
> With upcoming products I hope the modularization makes sense and helps keeping
> changes separate while not reinventing the wheel every time.
> 
>> 3) While messing with uhd, it is time to have the firmware recipe
>> package the fpga files on a per device basis, instead of all images on
>> one package.
> 
> We are/were already working on that. Thanks for your input.
> 
> Cheers,
> Moritz
> 
> ___
> 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

Re: [USRP-users] [UHD] Coarse roadmap for USRP E310 Software

[Philip Balister via USRP-users]

A couple of notes based on updating the E300 to rocko 

1) The N310 branch added a bbappend on something called salt which added
the need for the meta-openstack and meta-virtualization layers. For
basic E300 support, this is crazy layer bloat. I removed the bbappend.
If you really need it, I'd create a layer for specific applications,
salt seems to be some form of enterprise software config management
system ( https://en.wikipedia.org/wiki/Salt_(software) ) Certainly not
every E300 project needs this.

2) The uhd recipe in meta-sdr needs updating. I'd suggest moving it to
meta-ettus, but it also supports users using other Ettus products with
other embedded hardware, so the recipe doesn't belong there. It would be
silly having to add the meta-ettus bsp to use a b200 with a pi-s.

3) While messing with uhd, it is time to have the firmware recipe
package the fpga files on a per device basis, instead of all images on
one package.

4) There are some other smaller fixes in
https://github.com/balister/meta-ettus-1

Philip

On 07/10/2018 01:54 PM, Martin Braun via USRP-users wrote:
> 
> Hi all E310/E312/E313 users,
> 
> I would like to focus people's attention to some changes we have just
> started rolling out, and will continue to roll out over the next months.
> 
> Executive Summary
> =
> - For those requiring *no* RFNoC support whatsoever, just plain RX/TX
> and UHD support, we recommend sticking with the 3.9 LTS version of UHD
> for now (this advice is for the E310/E312/E313 only!).
> - Going forward, we will be moving the E310 to a more modern RFNoC
> architecture, and start incorporating things we've learned from other
> embedded USRPs.
> - However, this means that certain features (most importantly, network
> mode) will be unavailable for the time being on newer UHD versions until
> the transition is complete.
> 
> 
> Full Story
> ==
> As we've rolled out the USRP N310 and other devices using embedded
> Linux, we have gotten a little smarter with respect to OpenEmbedded and
> other embedded-Linux related topics. For example, the USRP N310 features
> the MPM architecture, which moves a lot of the hardware controls onto
> the device itself, as opposed to toggling every bit in every register
> from within UHD, and we have a better way of creating file systems which
> makes it easier for us to upgrade to newer OE and kernel versions.
> 
> The USRP E310, even though it was released years ago, is still a great
> product, with an amazing form factor. Unfortunately, its software design
> hasn't kept up with the times, and the currently shipping filesystems
> have fairly old kernels, among other things. Over the course of the next
> few months, we intend to remedy that. We will be taking the following steps:
> 
> 1. Port all RFNoC code from E310 onto master branch. This means we no
> longer support different architectures between the master and
> rfnoc-devel branches (note: On X310, we did this for the 3.10 release).
> The main downside of this is that it will disable network mode (i.e.,
> the ability to run the E310 like an N210, with UHD running on a host
> computer, over Ethernet).
> 
> 2. Forward-port the E310 code to the same OE release as we use for N310.
> Since this entails a major kernel upgrade, it will take some time to
> have all the power management up to date. There may be periods of time
> where the E312 (the battery-powered version) will have reduced
> capabilities. We will send out more updates when we know more.
> 
> 3. Forward-port the E310 code the same UHD software architecture as the
> N310. Once this is complete, network mode will be back in place, albeit
> with more capabilities. For RFNoC development in particular, this will
> be useful, because full RFNoC support will be made available over
> network mode (the bandwidth limitations for E310 network will remain the
> same, we expect a nominal sampling rate of 1 Msps over network mode).
> 
> Timeline
> 
> We plan to complete these steps by the end of 2018. The first step,
> however, has already been completed on master branch: Here, the E310 has
> already been synchronized with the code from rfnoc-devel.
> 
> Once this transition is complete, we will be able to keep providing
> updates for the E310 more easily than before, and they will stay in
> lockstep with the N310 filesystem releases.
> 
> Note that since we're merging all of this into master branch, there will
> be intermediate releases of UHD with different feature sets for the E310.
> 
> 
> Which branch/release should I run?
> ==
> If you are using none of the RFNoC features, i.e., you are simply doing
> send() and recv() calls, then we recommend sticking with the UHD-3.9.LTS
> branch.
> If you are doing RFNoC development, then simply move from rfnoc-devel to
> master branch, and everything else stays the same.
> 
> 
> Why do all of this on master branch?
> 
> We could have 

Re: [USRP-users] run app on single core in usrp e310

[Philip Balister via USRP-users]

Take a look at this and serach around the Xilinx website for the ZYnq
equivalent:

http://www.wiki.xilinx.com/OpenAMP

Philip

On 07/03/2018 10:05 PM, carry chen via USRP-users wrote:
> Hi,
> 
> I play usrp e310 this days.
> 
> can I run my app with single core and run os on another core?
> 
> thank you!
> 
> 
> Best, Regards,
> 
> Carry
> 
> 
> 
> ___
> 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

Re: [USRP-users] USRP E312 sample rate dips occasionally

[Philip Balister via USRP-users]

And how are you saving to ram?

On June 22, 2018 6:41:16 AM GMT+10:00, "Marcus D. Leech via USRP-users" 
 wrote:
>On 06/21/2018 04:17 PM, Cho, Daniel J (332C) via USRP-users wrote:
>>
>> Hello –
>>
>> I am using the USRP E312 and I am doing a 2 RX channel capture into 
>> the onboard 1GB RAM.  Sample rate is set to 5Mhz.  I am able to 
>> achieve capturing from both antennas at this sample rate but for some
>
>> odd reason, I am not able to maintain consistent 5Mhz sample rate.  
>> i.e. The status will show that I am capturing at 5Mhz then after some
>
>> time, it will dip to the kHz sample rate, then jump back up to 5Mhz 
>> again.  What is the reason for this dip?
>>
>> Thanks
>>
>Are you getting 'O' printed on the console as well?
>
>How are you measuring the dynamic sample rate?

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] [UHD] Announcing 3.12.0.0 Release

[Philip Balister via USRP-users]

On 06/06/2018 11:26 AM, Martin Braun via USRP-users wrote:
> Hi all,
> 
> after release-candidating, we have now finalized the 3.12.0.0 release.
> As mentioned before, you might not want to upgrade, but simply run the
> 3.11.1.0 release which has fewer feature-related changes, but most of
> the bugfixes. Here's the decision guidelines which were already in the
> RC1 notes:
> 
> 
> - 3.12.0.0 added White Rabbit support for the N310, so if you need that,
>   you need the newest release.
> - 3.12.0.0 removed some public API calls, it is thus an API-breaking
>   release (note that these were some obscure API calls, most users
>   won't see a difference. GNU Radio users certainly won't).
>   If you want to keep everything as stable as possible, but want all the
>   recent bugfixes, pick the 3.11.1.0 release.
> - If you're still unsure, go through the changelog (pasted below) and
>   see if some of the new features are relevant to your project.
>   Most notably, the addition of the BasicRX A/B muxing for X310 (which
>   was not available since UHD 3.10) and the re-added ability to modulate
>   the DAC on the N210/N200 could be relevant.
> 
> 
> Tag, FPGA images and github-auto-produced tarballs can be found here:
> https://github.com/EttusResearch/uhd/releases/tag/v3.12.0.0

If you are using tarball checksums to validate the tarball, github will
occasionally regenerate the tarball leading to a changed checksum. So if
you are validating tarballs before use, don't depend on stable checksums
from github automatically generated tarballs. Sadly, this makes github
auto created tarballs pretty useless.

Philip

> 
> Windows installers will be found here (they're still being finalized,
> for the next half-day or so this link will still be dead):
> http://files.ettus.com/binaries/uhd/uhd_003.012.000.000-release/
> 
> Cheers all,
> 
> Martin
> 
> 
> 
> 
> 
> 
> 
> Changelog:
> 
> 
> * N3x0: Add White Rabbit support, add N300 support, standard BIST
> 
> includes fan, fix issue with 1GigE, switch to 2 radio blocks
> 
> with 2 channels each, upgrade TDC to version 2.0, fix issue in
> 
> ARM deframer
> 
> * X300: Enable BasicRX to use A/B/AB/BA muxing setups, more consistent
> 
> logging, fix enumeration issue with TwinRX
> 
> * USRP2/N2x0: Re-add ability to modulate in the DAC, improve ISE
> 
>   settings to better meet timing
> 
> * B205mini: Fix global reset, improve timing in b205_ref_pll
> 
> * UHD: Remove a lot of Boost usage, mostly replaced by C++11 features,
> 
>more unit tests, fix Boost 1.67 compatibility, fix compiler
> 
>warnings, add API to query clock rate range, fix get_usrp_?x_info
> 
> * MPM: Refactored N3xx code, moved C++ standard to 14, refactor
> 
>Boost.Python bindings, use CMake variable MPM_DEVICE
> 
> * Logging: Allow disabling fastpath msgs at runtime
> 
> * Docs: Clarified meaning of DSP frequencies, improved manual
> 
> section on synchronization, added some known issues to B100,
> 
> USRP2, and USRP1, update test test procedure description
> 
> * Examples: Improved benchmark_rate (added failure thresholds, fixed
> 
>   incorrect calculation of samples on drops, fixed timeout values),
> 
>   minor fixes to txrx_loopback_to_file
> 
> * Utils: Handle U's in calibration tools, create-lvbitx.py is now Py3k
> 
>  compatible, fixed git-hash.sh
> 
> * RFNoC: DDCs/DUCs use DDSes instead of CORDIC, add DMA-based replay
> 
>  block in FPGA, add 64-bit support to axi_wrapper, add compat
> 
>  number to radio block,
> 
> * Debian: Fix rules file, fix Changelog format
> 
> * Fix license headers
> 
> * This release includes all bugfixes and features from previous
> 
>   releases, in particular, the 3.11.* release cycle
> 
> * Known issues: N310: In some rare scenarios at high rates, streaming
> 
>   can fail and even bring the FPGA into a bad state.
> 
> 
> ___
> 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] Rocko images for E3XX (and bonus 32 bit SDK)

[Philip Balister via USRP-users]

As a side effect of some paying work, I ended up with a Jenkins job that
builds E300 images from the OpenEmbedded branches for Rocko (dates from
last fall and currently still receiving updates). The kernel is built
from Kurt Kiefer's excellent work
(https://github.com/kekiefer/meta-ettus/tree/rocko+e3xx).

Using bmaptool to flash the images onto an 8 GB card goes quickly since
the newer image generation code creates the bmaps for the images.

SO very roughly:

sudo bmaptool copy gnuradio-dev-image.wic /dev/sdMYSDCARD

should work. (download the wic and bmap file)

I've switched from repo to git submodules to track layers and versions.
The git repository documenting the build is:

https://github.com/balister/sdr-build/tree/rocko-e300

The build output is:

https://www.dropbox.com/sh/4w19l8ixwm2ke24/AAB3aGPAkjqe9SvG32TsyK5Ia?dl=0

As an added bonus I made a 32 bit SDK for people to try.

These images will get updated occasionally by me running:

git submodule update --remote; git push

and letting Jenkins see if this builds. When it builds, the images will
get updated.

These images are not heavily tested, but I know something close has
booted on an sg1 unit.

All feedback on these should go to the usrp-users list. Sending me
private email is not a great way to get help (unless we have worked out
a contract).

Philip

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP E312 stops transmission when disconnected from computer

[Philip Balister via USRP-users]

On 05/29/2018 08:47 PM, Marcus D. Leech via USRP-users wrote:
> On 05/29/2018 08:40 PM, Cho, Daniel J (332C) via USRP-users wrote:
>>
>> Hello –
>>
>> I am using a USRP E312 to transmit a signal from a file.  I have a
>> computer connected to the USRP E312 via serial USB and I SSH into the
>> USRP E312.  Inside the USRP E312, I have a file that is transmitted. 
>> I use the out of the box program that is already in the USRP E312
>> (tx_from_file program) to transmit the file and the program is set to
>> transmit repeatedly (file loops).  For some reason, when I disconnect
>> the USRP E312 from the computer, it will still transmit the file for a
>> little less than a minute then it will stop transmitting.  Since the
>> USRP E312 is meant to be used as a standalone with its own OS, why
>> does it have to stay connected to a computer in order for it to
>> continually transmit?  Is there some kind of “wait” in the code where
>> if the USRP E312 does not sense a computer connected to it, it will
>> timeout?
>>
>> Thanks
>>
> A straight SSH connection to ANY linux box has the property that if the
> SSH server cannot maintain contact with the client, it will terminate the
>   session.  This is not specific to E312 or USRPs.
> 
> If I had a long-running process that I wanted to "kick off" using an SSH
> session, I'd probably use "nohup" and background it prior to disconnecting.

Us young guys might also use the screen command to create a long running
terminal you can reconnect to ifyou re-establish the connection.

Philip

> 
> 
> 
> 
> 
> 
> ___
> 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

Re: [USRP-users] Updated BSP for e3xx

[Philip Balister via USRP-users]

On 05/24/2018 12:19 PM, Kurt Kiefer via USRP-users wrote:
> 
>> On May 24, 2018, at 8:31 AM, Philip Balister  wrote:
>>
>> On 04/28/2018 12:39 PM, Kurt Kiefer via USRP-users wrote:
 On Apr 19, 2018, at 2:21 PM, Martin Braun  wrote:

 On 04/16/2018 09:25 PM, Kurt Kiefer via USRP-users wrote:
> The last release of the BSP and firmware for e3xx devices is either back 
> at fido, which was over two years ago, or jethro a year ago (though it's 
> still listed as "beta" on files.ettus.com). This age makes it 
> increasingly difficult to find compatible tooling without performing 
> complicated manual builds of software on the host and device, we miss out 
> on features only present in newer kernels, and miss out on updates to 
> various packages that would be included in an up-to-date Yocto build.
>
> Moving forward, does Ettus Research plan to keep the BSP updated for 
> these radios?

 Kurt,

 yes we plan to update the E310 and keep its BSP aligned with other BSPs
 that we have (e.g., the N310 BSP). There is significant work required to
 get the architectures aligned, and we have not started migrating the
 E310 to a newer BSP (and won't until we've come out of some other 
 projects).

 I apologize for the delay in this -- you're correct, fido is pretty old.
 We don't have a schedule for this yet.

 Regards,
 Martin
>>>
>>> If anyone is interested, I've done the work to update the E310 BSP to Rocko 
>>> with the latest versions of everything available. You can find the layer 
>>> here, forked from upstream meta-ettus/rocko/n3xx:
>>> https://github.com/kekiefer/meta-ettus/tree/rocko+e3xx
>>>
>>> Here is the updated manifest:
>>> https://github.com/kekiefer/e300-manifest/tree/rocko
>>>
>>> The BSP is set up to use the current u-boot from upstream (2017.09) and 
>>> Kernel from meta-xilinx (2017.03, which is version 4.9). This was a fair 
>>> amount of work, so I really hope this helps people out and kickstarts the 
>>> Ettus efforts to get the platform back up-to-date.
>>
>> Maybe not Ettus, but I need an e310-sg1 to work with rocko. Thanks for
>> making this available :)
>>
>> For anyone trying, it looks like there is some work needed so sg1 units
>> actually work. (Sadly, all I have are sg1 units)
>>
>> I'm pushing fixes here:
>>
>> https://github.com/balister/meta-ettus-1/tree/rocko-updates 
>> 
>>
>> I'll send Kurt a pull request when I'm done. We don't need a lot of forks.
>>
>> I've also been playing with git submodules to replace repo for checking
>> out layers:
>>
>> https://github.com/balister/sdr-build/tree/rocko-e300 
>> 
>>
>> Yeah, no README (yet).
>>
>> Philip
> 
> Great, I'll be looking for it. All I've got is an sg3 so I didn't pay much 
> mind to the sg1 issue. Maybe Ettus can send us some hardware so we can be 
> sure we didn't break other platforms, I'll take an N310 as well :P
> 

I'm trying to clean up a few things and will post some images you can
install with bmaptool (complete with block maps so you can create a card
in a few minutes)

> Just FYI, once meta-ettus upstream updates UHD to the latest release 3.11.1.0 
> ,
>  I'll most likely rebase rocko+e3xx on that.

I was hoping Ettus would submit an update to meta-sdr for uhd. Haven't
seen anything. I don't have any hardware to test updates with.

Philip

> 
> Kurt
> 
> 
> 
> ___
> 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

Re: [USRP-users] Updated BSP for e3xx

[Philip Balister via USRP-users]

On 04/28/2018 12:39 PM, Kurt Kiefer via USRP-users wrote:
>> On Apr 19, 2018, at 2:21 PM, Martin Braun  wrote:
>>
>> On 04/16/2018 09:25 PM, Kurt Kiefer via USRP-users wrote:
>>> The last release of the BSP and firmware for e3xx devices is either back at 
>>> fido, which was over two years ago, or jethro a year ago (though it's still 
>>> listed as "beta" on files.ettus.com). This age makes it increasingly 
>>> difficult to find compatible tooling without performing complicated manual 
>>> builds of software on the host and device, we miss out on features only 
>>> present in newer kernels, and miss out on updates to various packages that 
>>> would be included in an up-to-date Yocto build.
>>>
>>> Moving forward, does Ettus Research plan to keep the BSP updated for these 
>>> radios?
>>
>> Kurt,
>>
>> yes we plan to update the E310 and keep its BSP aligned with other BSPs
>> that we have (e.g., the N310 BSP). There is significant work required to
>> get the architectures aligned, and we have not started migrating the
>> E310 to a newer BSP (and won't until we've come out of some other projects).
>>
>> I apologize for the delay in this -- you're correct, fido is pretty old.
>> We don't have a schedule for this yet.
>>
>> Regards,
>> Martin
> 
> If anyone is interested, I've done the work to update the E310 BSP to Rocko 
> with the latest versions of everything available. You can find the layer 
> here, forked from upstream meta-ettus/rocko/n3xx:
> https://github.com/kekiefer/meta-ettus/tree/rocko+e3xx
> 
> Here is the updated manifest:
> https://github.com/kekiefer/e300-manifest/tree/rocko
> 
> The BSP is set up to use the current u-boot from upstream (2017.09) and 
> Kernel from meta-xilinx (2017.03, which is version 4.9). This was a fair 
> amount of work, so I really hope this helps people out and kickstarts the 
> Ettus efforts to get the platform back up-to-date.

Maybe not Ettus, but I need an e310-sg1 to work with rocko. Thanks for
making this available :)

For anyone trying, it looks like there is some work needed so sg1 units
actually work. (Sadly, all I have are sg1 units)

I'm pushing fixes here:

https://github.com/balister/meta-ettus-1/tree/rocko-updates

I'll send Kurt a pull request when I'm done. We don't need a lot of forks.

I've also been playing with git submodules to replace repo for checking
out layers:

https://github.com/balister/sdr-build/tree/rocko-e300

Yeah, no README (yet).

Philip

> 
> Kurt
> ___
> 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] Update for uhd in meta-sdr

[Philip Balister via USRP-users]

Any chance of getting an update for meta-sdr for uhd to avoid the
bbappends in meta-etts/n3xx/rocko?

https://github.com/EttusResearch/meta-ettus/blob/rocko/n3xx/recipes-support/uhd/uhd_git.bbappend

Would be better handled by update the uhd_3.x.y in meta-sdr. Also, it is
beginning to look lke hte uhd recipe needs to be machine specific.

Pull requests welcome.

Philip

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Updated BSP for e3xx

[Philip Balister via USRP-users]

On 04/28/2018 10:39 AM, Kurt Kiefer via USRP-users wrote:
>> On Apr 19, 2018, at 2:21 PM, Martin Braun  wrote:
>>
>> On 04/16/2018 09:25 PM, Kurt Kiefer via USRP-users wrote:
>>> The last release of the BSP and firmware for e3xx devices is either back at 
>>> fido, which was over two years ago, or jethro a year ago (though it's still 
>>> listed as "beta" on files.ettus.com). This age makes it increasingly 
>>> difficult to find compatible tooling without performing complicated manual 
>>> builds of software on the host and device, we miss out on features only 
>>> present in newer kernels, and miss out on updates to various packages that 
>>> would be included in an up-to-date Yocto build.
>>>
>>> Moving forward, does Ettus Research plan to keep the BSP updated for these 
>>> radios?
>>
>> Kurt,
>>
>> yes we plan to update the E310 and keep its BSP aligned with other BSPs
>> that we have (e.g., the N310 BSP). There is significant work required to
>> get the architectures aligned, and we have not started migrating the
>> E310 to a newer BSP (and won't until we've come out of some other projects).
>>
>> I apologize for the delay in this -- you're correct, fido is pretty old.
>> We don't have a schedule for this yet.
>>
>> Regards,
>> Martin
> 
> If anyone is interested, I've done the work to update the E310 BSP to Rocko 
> with the latest versions of everything available. You can find the layer 
> here, forked from upstream meta-ettus/rocko/n3xx:
> https://github.com/kekiefer/meta-ettus/tree/rocko+e3xx
> 
> Here is the updated manifest:
> https://github.com/kekiefer/e300-manifest/tree/rocko
> 
> The BSP is set up to use the current u-boot from upstream (2017.09) and 
> Kernel from meta-xilinx (2017.03, which is version 4.9). This was a fair 
> amount of work, so I really hope this helps people out and kickstarts the 
> Ettus efforts to get the platform back up-to-date.
> 

it looks like this N300 adds a dependency on meta-openstack for a
bbappend. Do you mind if I go ahead and drop that bbappend? it seems
like a pretty heavy layer addition for most use cases.

Philip

> Kurt
> ___
> 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

Re: [USRP-users] Updated BSP for e3xx

[Philip Balister via USRP-users]

On 04/28/2018 12:39 PM, Kurt Kiefer via USRP-users wrote:
>> On Apr 19, 2018, at 2:21 PM, Martin Braun  wrote:
>>
>> On 04/16/2018 09:25 PM, Kurt Kiefer via USRP-users wrote:
>>> The last release of the BSP and firmware for e3xx devices is either back at 
>>> fido, which was over two years ago, or jethro a year ago (though it's still 
>>> listed as "beta" on files.ettus.com). This age makes it increasingly 
>>> difficult to find compatible tooling without performing complicated manual 
>>> builds of software on the host and device, we miss out on features only 
>>> present in newer kernels, and miss out on updates to various packages that 
>>> would be included in an up-to-date Yocto build.
>>>
>>> Moving forward, does Ettus Research plan to keep the BSP updated for these 
>>> radios?
>>
>> Kurt,
>>
>> yes we plan to update the E310 and keep its BSP aligned with other BSPs
>> that we have (e.g., the N310 BSP). There is significant work required to
>> get the architectures aligned, and we have not started migrating the
>> E310 to a newer BSP (and won't until we've come out of some other projects).
>>
>> I apologize for the delay in this -- you're correct, fido is pretty old.
>> We don't have a schedule for this yet.
>>
>> Regards,
>> Martin
> 
> If anyone is interested, I've done the work to update the E310 BSP to Rocko 
> with the latest versions of everything available. You can find the layer 
> here, forked from upstream meta-ettus/rocko/n3xx:
> https://github.com/kekiefer/meta-ettus/tree/rocko+e3xx
> 
> Here is the updated manifest:
> https://github.com/kekiefer/e300-manifest/tree/rocko
> 
> The BSP is set up to use the current u-boot from upstream (2017.09) and 
> Kernel from meta-xilinx (2017.03, which is version 4.9). This was a fair 
> amount of work, so I really hope this helps people out and kickstarts the 
> Ettus efforts to get the platform back up-to-date.
> 

Nice work. I may have a chance to poke it next week.

Philip

> Kurt
> ___
> 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

Re: [USRP-users] Updated BSP for e3xx

[Philip Balister via USRP-users]

On 04/17/2018 12:25 AM, Kurt Kiefer via USRP-users wrote:
> The last release of the BSP and firmware for e3xx devices is either back at 
> fido, which was over two years ago, or jethro a year ago (though it's still 
> listed as "beta" on files.ettus.com). This age makes it increasingly 
> difficult to find compatible tooling without performing complicated manual 
> builds of software on the host and device, we miss out on features only 
> present in newer kernels, and miss out on updates to various packages that 
> would be included in an up-to-date Yocto build.

Wearing my OpenEmbedded hat, here is the release schedule for the meta
data used to build the Linux distro:

https://wiki.yoctoproject.org/wiki/Releases

Releases are only supported by the Yocto Project for about 18 months.
Beyond that is up to interested in members of the community to provide
support. Support means, bug fixes, security fixes, and general house
cleaning. (Note you typically need to use a container to build Jethro
due to host tool version issues)

You can check if there is active work by checking the commit log:

https://github.com/openembedded/openembedded-core/commits/jethro

Which suggests no major players are providing support.

This lack of support post shipment is not a unique problem to Ettus, it
is industry wide. The only way to change this is complain loudly to the
people that matter, so don't beat up engineering teams :) Sales and
marketing need to know that long term product support matters.

As I mentioned in my GRCon lightening talk, getting patches upstream and
working against recent software (be it kernels or OpenEmbedded metadata)
leaves more time for people to do interesting SDR work, and less time
doing the software vendors job for them.

Philip

> 
> Moving forward, does Ettus Research plan to keep the BSP updated for these 
> radios?
> 
> Kurt
> ___
> 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

Re: [USRP-users] Assistance In Stopping Python Script After Removing Ethernet Connection

[Philip Balister via USRP-users]

On 04/04/2018 01:32 AM, Ian Buckley via USRP-users wrote:
> 
>> On Apr 3, 2018, at 10:24 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
>> TECHNOLOGIES INC] via USRP-users  wrote:
>>
>> Thanks Marcus…
>>  
>> Actually, this is what I am looking into currently.
>>  
>> Unfortunately, I get the PID, but when I reconnect and go to terminal, the 
>> kill -9 PID seems to not stop it.
>>  
>> I am currently using a VM to do this on a Windows OS platform.  I am not 
>> sure if this is the reason…
>>  
>> So, it seems that when I reconnect, I cannot kill the process.
>>  
>> Any more advice?
>>  
>> Thanks
>>  
>> From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com 
>> ] On Behalf Of Marcus D. Leech 
>> via USRP-users
>> Sent: Wednesday, April 04, 2018 12:51 AM
>> To: usrp-users@lists.ettus.com 
>> Subject: Re: [USRP-users] Assistance In Stopping Python Script After 
>> Removing Ethernet Connection
>>  
>> On 04/04/2018 12:37 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES 
>> INC] via USRP-users wrote:
>> To All,
>>  
>> I have tried to use the Header block approach which is found on the Internet 
>> to try to fix this issue…
>>  
>> Here is the issue…
>>  
>> I am capturing samples via an antenna on the E310.
>>  
>> I used GRC to create the flowgraph to capture samples to go to a file.
>>  
>> But, I have to remove the ethernet cable to the E310.
>>  
>> When this is done, it seems the data collecting process stops.
>>  
>> Is there a work around using GRC?
>>  
>> Or do I have to create another python code to run the GRC created python 
>> code for a certain amount of time using Linux or python code?
>>  
>> If anyone has any advice or example code, it would be much appreciated.
>>  
>> Thanks,
>>  
>> Konstantin
>>  
>> WHen you SSH into a machine, and disconnect the cable, eventually, SSH will 
>> drop the connection, which causes your session to be terminated, including
>>   any processes that you have have started from that session.
>>
>> You could look into the "nohup" command
>>
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com 
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com 
>> 
> 
> Could this be as simple as running your python in a shell under “screen” so 
> the shell doesn’t die on disconnect and you can reconnect to the interactive 
> shell later?
> 
> https://www.gnu.org/software/screen/manual/screen.html 
> 

What Ian said :)

Philip

> 
> 
> 
> ___
> 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

Re: [USRP-users] Installing Python Modules into E310

[Philip Balister via USRP-users]

On 01/29/2018 04:35 PM, MASDR GS via USRP-users wrote:
> Is there a specific method/process to install external modules into the
> E310? For example, "python bit-array". We would need this module installed
> to run a .grc file using GNUradio directly on the E310. I have tired
> installing bitarray directly onto the radio using 'python setup.py install'
> but wasn't successful. Any help would be appreciated.

I'm thinking this image might have that module:

http://files.ettus.com/e3xx_images/beta/jethro-test/ettus-e3xx-sg3/

Philip

> 
> 
> 
> ___
> 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

Re: [USRP-users] UHD not working with the B200 USB 2.0 on ARM64 platform

[Philip Balister via USRP-users]

Try strace uhd_usrp_probe

and see if you can see which system call returns -EPERM. Yes this is a
hail mary operation.

Philip

On 12/28/2017 01:13 PM, Michael Don via USRP-users wrote:
> I'm still getting the same error with the USB 2.0 for the B200 on my tegra
> system.
> 
> Using lsusb I can see the B200 listed as:
> 
> Bus 001 Device 031: ID 2500:0020
> 
> I can then find /dev/bus/usb/001/031 and verify that it has the correct
> permissions:
> 
> crw-rw-rw- 1 root flirimaging 189, 30 Dec 28 18:04 031
> 
> Just to test things out, I've even changed the permissions, reloaded the
> udev rules, and noted that the permissions change back.
> 
> So in spite of verifying the B200 permissions, I still get the same error
> listed in my original email.  Does anyone have any other suggestions?
> 
> -Mike
> 
> 
> On Fri, Dec 22, 2017 at 3:13 PM, Michael Don <miked...@gmail.com> wrote:
> 
>> Marcus,
>>
>> Yes, "sudo udevadm control --reload-rules" is included in the "Setup Udev 
>> for USB" instructions.  I also tried replugging in the unit.  I'll try 
>> debugging some more and let you know if I come up with anything.
>>
>> Philip - thanks for letting me know about the acceleration, once I get 
>> things working I may ask you more about it.
>>
>> -Mike
>>
>>
>> On Tue, Dec 19, 2017 at 7:58 PM, Philip Balister via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 12/19/2017 06:44 PM, Marcus D. Leech via USRP-users wrote:
>>>> On 12/19/2017 05:09 PM, Michael Don via USRP-users wrote:
>>>>>
>>>>> I've build and installed UHD 3.10.1.1 on a Tegra TX2 (ARM64
>>>>> platform).  The USB 3.0 is working, but I'm getting errors with the
>>>>> USB 2.0 on a USRP B200.
>>>
>>> I know UHD works on several aarch64 platforms. I do carry a patch in
>>> meta-sdr that enables neon acceleration for the uhd type convertors.
>>>
>>> Philip
>>>
>>>>>
>>>>> uhd_find_devices works, but uhd_usrp_probe, and the uhd application
>>>>> examples give the error below.  Note that I've tried running with
>>>>> sudo, and have followed the instructions "Setup Udev for USB" about
>>>>> the uhd-usrp.rules file.  Any advice?
>>>>>
>>>>> Thanks, -Mike
>>>>>
>>>>>
>>>>> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>>>>> UHD_003.010.001.001-0-unknown
>>>>>
>>>>> -- Detected Device: B200
>>>>> -- Operating over USB 2.
>>>>> -- Initialize CODEC control...
>>>>>
>>>>> UHD Error:
>>>>> An unexpected exception was caught in a task loop.
>>>>> The task loop will now exit, things may not work.
>>>>> EnvironmentError: IOError: usb rx8 transfer status:
>>>>> LIBUSB_TRANSFER_ERROR
>>>>> -- Detected bad USB state; resetting.
>>>>>
>>>>> UHD Error:
>>>>> USB open failed: insufficient permissions.
>>>>> See the application notes for your device.
>>>>> Error: AssertionError: libusb_open(_dev->get(), &_handle) == 0
>>>>>   in
>>>>> libusb_device_handle_impl::libusb_device_handle_impl(uhd::
>>> transport::libusb::device::sptr)
>>>>>
>>>>>   at
>>>>> /home/nvidia/Documents/USB3/uhd-release_003_010_001_001/host
>>> /lib/transport/libusb1_base.cpp:261
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> Did you:
>>>>
>>>> sudo udevadm control --reload-rules
>>>>
>>>> After installing the usrp rules file?
>>>>
>>>> Did you unplug/replug, after updating the rules?  The rules are only
>>>> *triggered* when a USB device event happens, so if it's still plugged in
>>>> when you change
>>>>   the rules, nothing will happen until you re-plug.
>>>>
>>>>
>>>>
>>>>
>>>> ___
>>>> 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.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

Re: [USRP-users] UHD not working with the B200 USB 2.0 on ARM64 platform

[Philip Balister via USRP-users]

On 12/19/2017 06:44 PM, Marcus D. Leech via USRP-users wrote:
> On 12/19/2017 05:09 PM, Michael Don via USRP-users wrote:
>>
>> I've build and installed UHD 3.10.1.1 on a Tegra TX2 (ARM64
>> platform).  The USB 3.0 is working, but I'm getting errors with the
>> USB 2.0 on a USRP B200.

I know UHD works on several aarch64 platforms. I do carry a patch in
meta-sdr that enables neon acceleration for the uhd type convertors.

Philip

>>
>> uhd_find_devices works, but uhd_usrp_probe, and the uhd application
>> examples give the error below.  Note that I've tried running with
>> sudo, and have followed the instructions "Setup Udev for USB" about
>> the uhd-usrp.rules file.  Any advice?
>>
>> Thanks, -Mike
>>
>>
>> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>> UHD_003.010.001.001-0-unknown
>>
>> -- Detected Device: B200
>> -- Operating over USB 2.
>> -- Initialize CODEC control...
>>
>> UHD Error:
>>     An unexpected exception was caught in a task loop.
>>     The task loop will now exit, things may not work.
>>     EnvironmentError: IOError: usb rx8 transfer status:
>> LIBUSB_TRANSFER_ERROR
>> -- Detected bad USB state; resetting.
>>
>> UHD Error:
>>     USB open failed: insufficient permissions.
>>     See the application notes for your device.
>> Error: AssertionError: libusb_open(_dev->get(), &_handle) == 0
>>   in
>> libusb_device_handle_impl::libusb_device_handle_impl(uhd::transport::libusb::device::sptr)
>>
>>   at
>> /home/nvidia/Documents/USB3/uhd-release_003_010_001_001/host/lib/transport/libusb1_base.cpp:261
>>
>>
>>
>>
> 
> Did you:
> 
> sudo udevadm control --reload-rules
> 
> After installing the usrp rules file?
> 
> Did you unplug/replug, after updating the rules?  The rules are only
> *triggered* when a USB device event happens, so if it's still plugged in
> when you change
>   the rules, nothing will happen until you re-plug.
> 
> 
> 
> 
> ___
> 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

Re: [USRP-users] Problem burning image to SD card for E312

[Philip Balister via USRP-users]

On 11/16/2017 04:37 PM, Anon Lister wrote:
> Make sure to run sync after to dd.

Interesting, I thought dd would run below the buffer cache layer.

> 
> Also curious as to reason for the recommendation against dd?
> 

bmaptool is faster. bmaptool also checks to see if the device has a
mounted file system, so prevent you form overwriting something like
/dev/sda. Basically, safer and faster.

Philip


> On Nov 16, 2017 12:35 PM, "Philip Balister via USRP-users" <
> usrp-users@lists.ettus.com> wrote:
> 
>> Try bmaptool. dd is a bad idea, yeah I killed my hard drive once.
>>
>> https://wiki.gnuradio.org/index.php/Copy_an_image_file_to_the_SD_card
>>
>> The might even be package with Ubuntu. After writing, re-insert the card
>> in the writer and see if it mounts the partitions.
>>
>> Philip
>>
>> On 11/16/2017 10:54 AM, Mann, John - 0662 - MITLL via USRP-users wrote:
>>> Running Ubuntu 16 on my host computer...
>>>
>>> I downloaded the image from:
>>>
>>> http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-
>> e3xx-sg3/http://files.ettus.com/e3xx_images/e3xx-release-
>> 4/ettus-e3xx-sg3/sdimage-gnuradio-dev.direct.xz
>>>
>>> Then I decompressed the xz file using xzdec:
>>>
>>> xzdec sdimage-gnuradio-dev.direct.xz >> sdimage-gnuradio-dev.direct
>>>
>>> And burned the sd image using the dd command:
>>>
>>> sudo dd if=sdimage-gnuradio-dev.direct of=/dev/sdb1 bs=1M
>>>
>>> The dd command apparently finishes without error after about 10 minutes,
>> and I can see flashing lights on the SD card USB adapter, so I'm pretty
>> sure it is getting written to the correct place.
>>>
>>> But the card does not work in the E312.  When I turn it on, the 4 LEDs
>> next to the Tx/Rx ports light up, but there is no activity on the console
>> window.  I have another SD card that boots up fine, so I know the E312 is
>> fine.  There is clearly something wrong with the SD card.  When I plug the
>> old working card into my Ubuntu host machine, I can actually see the files
>> on the card.  When I plug the newly burned card back into the Ubuntu
>> machine, I see nothing.
>>>
>>> Any idea what I am doing wrong?
>>>
>>> John Mann
>>> MIT Lincoln Laboratory
>>>
>>> ___
>>> 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.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Problem burning image to SD card for E312

[Philip Balister via USRP-users]

Try bmaptool. dd is a bad idea, yeah I killed my hard drive once.

https://wiki.gnuradio.org/index.php/Copy_an_image_file_to_the_SD_card

The might even be package with Ubuntu. After writing, re-insert the card
in the writer and see if it mounts the partitions.

Philip

On 11/16/2017 10:54 AM, Mann, John - 0662 - MITLL via USRP-users wrote:
> Running Ubuntu 16 on my host computer...
> 
> I downloaded the image from:
> 
> http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg3/http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg3/sdimage-gnuradio-dev.direct.xz
>  
> 
> Then I decompressed the xz file using xzdec:
> 
> xzdec sdimage-gnuradio-dev.direct.xz >> sdimage-gnuradio-dev.direct
> 
> And burned the sd image using the dd command:
> 
> sudo dd if=sdimage-gnuradio-dev.direct of=/dev/sdb1 bs=1M
> 
> The dd command apparently finishes without error after about 10 minutes, and 
> I can see flashing lights on the SD card USB adapter, so I'm pretty sure it 
> is getting written to the correct place.
> 
> But the card does not work in the E312.  When I turn it on, the 4 LEDs  next 
> to the Tx/Rx ports light up, but there is no activity on the console window.  
> I have another SD card that boots up fine, so I know the E312 is fine.  There 
> is clearly something wrong with the SD card.  When I plug the old working 
> card into my Ubuntu host machine, I can actually see the files on the card.  
> When I plug the newly burned card back into the Ubuntu machine, I see nothing.
> 
> Any idea what I am doing wrong?
> 
> John Mann
> MIT Lincoln Laboratory
> 
> ___
> 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

Re: [USRP-users] Compiling UHD Host Library: Problem Enabling ARM Neon Support

[Philip Balister via USRP-users]

On 11/10/2017 06:52 AM, Philip Balister via USRP-users wrote:
> On 11/10/2017 06:41 AM, Philip Balister via USRP-users wrote:
>> On 11/10/2017 04:11 AM, Ron Economos via USRP-users wrote:
>>> I guess this is a little late, but you can pass in compiler flags on the
>>> command line with -DCMAKE_CXX_FLAGS. For example:
>>>
>>> cmake -DCMAKE_CXX_FLAGS:STRING="-mfloat-abi=hard -mfpu=neon
>>> -mtune=cortex-a15" ../
>>
>> That would be the preferred way. The patch mentioned assumes that
>> anytime you are using a compiler with the neon.h header file, the SoC
>> you are compiling for has a neon unit. This is a bad assumption. There
>> are a few examples of SoC's around that do not have a neon unit. Now UHD
>> will generate neon and create runtime failures.
>>
>> Bottom line, in the ARM world, you cannot test compiler features to
>> figure out what features the runtime system has.
> 
> Also, another quick look suggests neon for aarch64 is no longer built.

Never mind. The code to allow the neon convertors to build for aarch64
never made it into uhd.

Philip


> 
> Philip
> 
> 
>>
>> Philip
>>
>>
>>>
>>> Ron
>>>
>>> On 11/10/2017 12:07 AM, Gwenhael Goavec-Merou via USRP-users wrote:
>>>> Hello,
>>>>
>>>> maybe this : https://github.com/EttusResearch/uhd/pull/135
>>>> will help you
>>>>
>>>> Gwen
>>>>
>>>> On Fri, 10 Nov 2017 00:29:25 -0600
>>>> Kevin McGuire via USRP-users <usrp-users@lists.ettus.com> wrote:
>>>>
>>>>> I was able to get the compiler flags passed in so that the check for
>>>>> the header arm_neon.h passes. I added it to the CMakeList root file
>>>>> with SET(CMAKE_CXX_FLAGS, "${CMAKE_CXX_FLAGS} -mfloat-abi=softfp
>>>>> -mfpu=neon").
>>>>>
>>>>> Then, it would detect neon. However, I spent considerable time
>>>>> cleaning up whatever package problems I had since I ended up with a
>>>>> bunch of weird errors.
>>>>>
>>>>> Once I straightened my packages up (Debian), it is compiling with
>>>>> neon! And, hopefully, it will actually use the ARM neon routines.
>>>>>
>>>>> On Thu, Nov 9, 2017 at 3:22 AM, Kevin McGuire <kmcg3...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I have noticed that neon support for the converter is not enabling.
>>>>>> The CMakeError.log has this output. I am not certain as I am not
>>>>>> really familiar with ARM and NEON, but I checked my CPU and it does
>>>>>> support it. Also, the error message below is saying it is just a
>>>>>> matter of passing certain flags.
>>>>>>
>>>>>> /mnt/extra/usr/lib/gcc/arm-linux-gnueabihf/4.8/include/arm_neon.h:32:2:
>>>>>> error: #error You must enable NEON instructions (e.g.
>>>>>> -mfloat-abi=softfp -mfpu=neon) to use arm_neon.h
>>>>>>   #error You must enable NEON instructions (e.g. -mfloat-abi=softfp
>>>>>> -mfpu=neon) to use arm_neon.h
>>>>>>
>>>>>> Normally, I would just fix it myself and move forward, but me and
>>>>>> CMake mix like oil and water. It is kind of embarrassing but I
>>>>>> swear it never does what I want it do - such as adding a darn flag.
>>>>>> I even tried to force the options, lol, and all be danged if CMake
>>>>>> finds some way to error.
>>>>>>
>>>>>> Will work on this tomorrow, but if anyone has a solution I am all
>>>>>> ears. If not then no problem and I will reply when I figure it out.
>>>>>>
>>>>>> This came about when I noticed what really seemed like abnormally
>>>>>> high CPU usage on my ARM code for a simple shuffling of data out of
>>>>>> the network packets. I traced what I felt like was the biggest
>>>>>> possible hot spot to the converter routine. Anyway, that is my plan
>>>>>> right now, to see if NEON might help if the converter is having to
>>>>>> swap byte order.
>>>> ___
>>>> 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.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.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com