Re: [USRP-users] E320 with larger SD card
My understanding of the partiitons on the card are (in order); Mender allows you to boot from one of the A/B partitions as your primary filesystem (mounted as /), plus the persistent data (mounted as /home/ or /data or similar). My experience is if you perform resizing while keeping the partitions contiguous (no free space between them), and have the A and B partitions identical in size, it "just works". So my steps in the previous reply would look like: # original image on large SD Card # shift persistent data to the end # maximise A/B partitions, keeping A and B the same size Rather than extending the data partition, I wanted to add new libraries and applications in /usr, which is located on the A/B partitions. Hence my instructions involve me resizing those partitions instead of the data partition. If you're simply extending the size of the persistent data partition without shifting it's start point (while leaving the other partitions alone) I'm at a loss as to why it wouldn't work. But when you do this you may need some extra linux-fu to shift your new binary/library locations to that partition rather than the default /usr. Cheers,Chris - Original Message - From: "Jason Matusiak" To:"Chris Gobbett" Cc:"Ettus Mail List" Sent:Wed, 19 Jun 2019 23:12:40 + Subject:Re: [USRP-users] E320 with larger SD card Chris, thanks for the tips. So I put a fresh load on a card, then used gparted to extend the data partition to fill things out. That isn't enough, and your instructions certainly show more steps. But I don't understand what you mean with the partitions in the middle. I'll read up on Mender and see if that answers it for me. Thanks again. On Jun 19, 2019, at 6:56 PM, Chris Gobbett wrote: Hi Jason, I've had luck with the following: - backup/clone the original SDCard image to disk and/or larger SDCard (using dd or otherwise) - on the new card, resize/shift the data partion to the end of the card (using gparted) - resize the two filesystem/kernel partitions to fill in the empty space in the middle, but they need to be the same size (using gparted) Read up on Mender for more info on the partition layout (https://docs.mender.io/1.7/devices/general-system-requirements#partition-layout). It's a pain that they went with Mender for the default E320 card; it cuts the 'usable' file system space in half, at the benefit of having 2 independent filesystem partitions... I haven't had time to fiddle around and ditch the mender for a 'normal' partition layout, but I'd assume it's possible. Cheers, Chris - Original Message - From: "Jason Matusiak" To: "Ettus Mail List" Cc: Sent: Wed, 19 Jun 2019 16:29:38 + Subject: [USRP-users] E320 with larger SD card I wanted to use a larger SD card than the one that as supplied, but I am having issues. I loaded up the card, and then extended the data partition to use up the rest of the free space (about 100GB). But then it doesn't boot. I am wondering if the change to a partition size screwed up something in a config file somewhere. Is there a way to fix this without rebuilding a docker image? I am using the UHD 3.14.0.0. that has the smaller data partition (UHD 3.14.1.0 has a larger data partition, but doesn't include any GR/python packages, so I need to use the older image). Thanks. Links: -- [1] mailto:go...@tpg.com.au ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] E320 with larger SD card
Hi Jason, I've had luck with the following:- backup/clone the original SDCard image to disk and/or larger SDCard (using dd or otherwise)- on the new card, resize/shift the data partion to the end of the card (using gparted)- resize the two filesystem/kernel partitions to fill in the empty space in the middle, but they need to be the same size (using gparted) Read up on Mender for more info on the partition layout (https://docs.mender.io/1.7/devices/general-system-requirements#partition-layout). It's a pain that they went with Mender for the default E320 card; it cuts the 'usable' file system space in half, at the benefit of having 2 independent filesystem partitions... I haven't had time to fiddle around and ditch the mender for a 'normal' partition layout, but I'd assume it's possible. Cheers,Chris - Original Message - From: "Jason Matusiak" To:"Ettus Mail List" Cc: Sent:Wed, 19 Jun 2019 16:29:38 + Subject:[USRP-users] E320 with larger SD card I wanted to use a larger SD card than the one that as supplied, but I am having issues. I loaded up the card, and then extended the data partition to use up the rest of the free space (about 100GB). But then it doesn't boot. I am wondering if the change to a partition size screwed up something in a config file somewhere. Is there a way to fix this without rebuilding a docker image? I am using the UHD 3.14.0.0. that has the smaller data partition (UHD 3.14.1.0 has a larger data partition, but doesn't include any GR/python packages, so I need to use the older image). Thanks. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Running E310 in Network Mode
Also Ramazan note that even then you will still get far reduced bandwidth as compared to N210/B210 over ethernet or USB: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-April/041697.html [1] If cutting FPGA code isn't an option but you wish to have a larger bandwidth with the small form-factor, perhaps something like the B200 mini might suffice?- Original Message -From: "Jason Matusiak" To:"usrp-users@lists.ettus.com" , "Ramazan Çetin" Cc: Sent:Wed, 8 May 2019 14:14:46 + Subject:Re: [USRP-users] Running E310 in Network Mode See here: https://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_network_mode [2] - FROM: USRP-users on behalf of Ramazan Çetin via USRP-users SENT: Wednesday, May 8, 2019 8:02 AM TO: Ettus Research Support; usrp-users@lists.ettus.com SUBJECT: [USRP-users] Running E310 in Network Mode Hello, We want to run USRP E310 in network mode. I think the samples coming from FPGA passing through CPU before sending to network. This decreases bandwidth because of CPU limitations. So, is there any ettus image or suggestions that we can run E310 directly from FPGA to network without speed limitations? (like N210 or B210) Best regards. Ramazan ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [3] Links: -- [1] http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-April/041697.html [2] https://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_network_mode [3] 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] E320 Auto-Booting function not working?
Following the steps from the E320 getting started guide [1], I'm not having any luck with the unit auto booting when power is applied The command "eeprom-set-flags 0x1" seems to take effect successfully, and sets the value of MCU_FLAGS[0] to 0x1 (noting that the default value is 0x8, which I'm assuming means auto boot is "off") . This is also verified as holding its value between power cycles, by looking at the output of the eeprom-dump command. But... removing power to the unit, then applying power again doesn't result in the unit booting by itself. Anyone had any experience with this and/or able to offer help? I'm hesitant to trial-and-error different values into eeprom-set-flags, for fear of breaking something... :) Cheers,Chris [1] https://kb.ettus.com/E320_Getting_Started_Guide [1] Links: -- [1] https://kb.ettus.com/E320_Getting_Started_Guide ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] E320 numpy missing?
I've had similar problems since this post in March, and still waiting on a 'clean' way forwardhttp://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-March/059332.html In the interim I've done lots of cross-compiling and also stealing libraries/binaries from working E310 images; many of the included binaries seem gimped or a step down from what was on the E310. - Original Message - From: "Jason Matusiak" To:"Philip Balister" , "Ettus Mail List" Cc: Sent:Wed, 1 May 2019 14:40:16 + Subject:Re: [USRP-users] E320 numpy missing? I just double-checked and ENABLE_PYTHON is on in my system (which was apparently the default since I didn't spell it out in my cmake command). - FROM: Jason Matusiak SENT: Wednesday, May 1, 2019 10:36 AM TO: Philip Balister; Ettus Mail List SUBJECT: Re: [USRP-users] E320 numpy missing? I actually was using a .sh file from earlier in April, but pulling down the most recent: e3xx_e320_sdk_default-v3.13.0.2-20190415.zip, I still don't see pretty much any site-packages in the sysroot. Those things seem to be there automatically when using the .sh info with the e310 files. I will try including python in the cmake path (which I've never needed to do before), but is that going to be enough? I feel like the back-and-forth you and I had last year with the rocko build for the E310 were for pretty similar issues. But honestly, I need to look back at the emails for the exact issues at the time. - FROM: Philip Balister SENT: Wednesday, May 1, 2019 10:31 AM TO: Jason Matusiak; Ettus Mail List SUBJECT: Re: [USRP-users] E320 numpy missing? 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 [1] 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 [2] > Links: -- [1] https://github.com/EttusResearch/meta-ettus/blob/master/meta-ettus-core/recipes-core/images/developer-image.bb [2] 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] E320 SD Image lacking libraries; cross-compile help
We’ve just purchase a shiny new E320 or three and are looking to translate some gnuradio-generated python code from an E310 across, but I’m having problems which weren’t apparent during development for the E310. Some differences which took me by surprise: - The Python2.7 libraries are severely lacking; some of the standard libraries (e.g. decimal, numbers, runpy) aren’t present?! - No gnuradio present at all? No binaries, nor the python 2.7 modules I thought the lack of python2.7 modules may just be a side effect of Gnuradio heading towards Python 3, but given that UHD still defaults to Python 2.7 I’m wondering if I’ve missed something more obvious?? - Do I need to manually cross-compile and install Python2.7 in addition to installing gnuradio on the target? - Will rebuilding my GRC to use Python3 rather than Python2.7 solve my problems? (longer background + steps taken...) Over the last few days I’ve tried combinations of cross-compiling uhd and gnuradio, though given the reliance of my code on python2.7 this in turn leads to extra dependencies which aren’t there; e.g. uhd_swig is now after a newer libboost than what is on the card. I’ve tried copying the missing python2.7 modules (above) from my e310 image as a stopgap measure, but while it works on the surface I think this is just adding more pain rather than helping. The guides I used for the cross-compiling are included below. I’ve successfully built and run uhd and gnuradio by themselves on the E320 (e.g. gnuradio-config-info and uhd_usrp_probe run fine in isolation), but when it comes time to ‘from gnuradio import uhd’ is when the wheels fall off. First guides were used to build UHD on the host; to download the sdcard image, and to get the toolchain: https://kb.ettus.com/E320_Getting_Started_Guide (Feb19) http://files.ettus.com/manual/page_build_guide.html The steps regarding ldconfig linking the libraries on target aren’t included in the other guides; are they necessary? I’ve mainly followed these steps: https://wiki.gnuradio.org/index.php/Cross_compile_an_OOT_and_install_on_target (Mar17) https://wiki.gnuradio.org/index.php/Cross_compile_GNU_Radio_and_install_on_target (Mar17) https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source (Sep17) Short of building the code, this page doesn’t help much (e310-focussed): https://files.ettus.com/manual/page_usrp_e3x0.html Apologies for the large ramble... this has been several days coming, and I seem to be only going in circles... :( Host running Ubuntu 18.04 ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
