Many of you are aware of our use of Open Embedded / Yocto as a way to install REDHAWK SDR on a variety of devices (recently, we published the Xilinx ZCU111 instructions for Rocko). We do this easily by using our meta-redhawk-sdr layer, which lately has seen a flurry of activity that is worthy of discussion. In this post, we’ll be discussing multi-architecture Domain support, REDHAWK and Yocto version changes, and other elements that made last week’s ESRA debut possible.
Multi-architecture Domain
As a distributed computing framework, one of the main features REDHAWK SDR provides is to load Components and Softpkgs (libraries) onto remote general purpose processors (GPPs) for execution. Those GPPs can all be of different CPU architectures. For cpp Components and Softpkgs, REDHAWK tries to match the implementation to a GPP’s processor, and then handles the distribution for you automatically.
It’s a great feature, however, to my knowledge, there has never been a public way to easily develop for a multi-architecture Domain. For each Component, you would have to manually create that new implementation, re-run code generation only to probably copy over the other source code, compile with a different toolchain, and so on: it’s a lengthy and somewhat error-prone manual process involving a lot of duplication. And in the past, meta-redhawk-sdr’s package classes (e.g., redhawk-component) would replace the implementation’s processor reference with your build target’s. So sure: you cross-compiled everything. But you cannot install them back at your standard Domain without more legwork, blending the XMLs together and separating where the binaries are stored.
That headache is gone now.
Over the last year, meta-redhawk-sdr’s processes for Components, Devices, and Softpkgs has matured to a point where we use REDHAWK’s own XML parsers to create a new implementation that can cleanly live alongside the original. A hidden feature in that utility also allowed you to do the inverse: install and patch the Yocto-built version into a different SDRROOT. That feature is now exposed in an image class, redhawk-image, which collects the cross-compiled SDRROOT assets along with the installer into a tarball: image_name-image_version-sdrroot.tar.gz. Your multi-architecture installation effort is now:
- Unpack the tarball on your target Domain
- Run
install_assets
Have a nice day.
REDHAWK 2.2.3, Thud
REDHAWK 2.2.2 and 2.2.3 came out in such quick succession this year that no sooner had Alex bumped us to 2.2.2 than we also bumped again to 2.2.3. During that process we made a number of other changes that allowed us to cross-compile ESRA. Some of these changes include:
- Cross-compiling of the ComponentHost, which provides the zero-copy capabilities of the BULKIO streaming interface
- Better handling of Components (and Devices) that are Shared Library implementations (to fully leverage (1) for Components as well as Persona devices)
- Restructuring of the included images to inherit from
redhawk-image(to make use of the Multi-architecture Domain tooling) - Better logging support for installed Domains and Device Managers
- Improved waveform package support added to the
redhawk-waveformpackage class - Patched the DataConverter Component to use
sse2armfor cross-compiling to AARCH64 and some 32-bit ARM devices - Migrated to
PACKAGE_ARCHfor implementations to enable supporting CPU architecture vs. hardware-specific implementations (i.e., Personas)
We also had a very talented intern, Michelle, extend our Yocto version support from Rocko to Thud. That extension coincided with deploying to a new target, for us: the Intel/Altera Stratix 10.
Our current plan is to continue maintaining the Rocko branch for those BSPs that are not seeing much active maintenance but may still want the latest REDHAWK (e.g., the Ettus E310). The older branches are no longer being maintained and will be sunset soon.
Conclusion
As you can see, we’ve been busy! Please feel free contact us or submit issues/pull requests if you need support. We welcome contributions; it is FOSS, as always.
