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 considered running a side-branch (e310-devel or something > like that) to do all of these changes. However, our experience with > rfnoc-devel was that this actually delays the release of features, and > we have the safety net of the UHD-3.9.LTS branch. Also, one of the main > reasons to do this is to share code with other USRPs, and it's a lot > easier to keep things shared when you're only developing code on the > same branch. > > > Please let us know if you have any questions. > > Regards, > Martin Braun > > _______________________________________________ > 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
