discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Moritz Fischer
Subject: Re: [Discuss-gnuradio] [USRP-users] [UHD] Coarse roadmap for USRP E310 Software
Date: Tue, 17 Jul 2018 10:50:28 -0700

Philip,

On Fri, Jul 13, 2018 at 8:03 AM, Philip Balister <address@hidden> 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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]