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

[Philip Balister]

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