scripts/spd_utility patch_sdrroot() not saving updated spd.xml file

[SteveS-Serrano]

@btgoodwin : This code path in spd_utility patch_sdrroot (dunfell-next branch): https://github.com/Geontech/meta-redhawk-sdr/blob/5c176f314886efd3b78aced812f3a476d74b884d/scripts/spd_utility#L219

does not export the updated file. So when I run the install_assets script, if the component already exists in $SDRROOT, the cross-compiled component binary is installed, but the spd.xml file does not show the additional cross-compiled implementation.

Is this a bug? i.e., Doesn't the domain manager need to know about the cross-compiled binary via an implementation entry in the spd.xml file?

[btgoodwin]

Hi @SteveS-Serrano. You're correct that the XML would need to reference the other implementation however you can actually get away with just a file at that location, and when the domain goes to deploy it, it would check the remote to see if it's already installed there and then skip trying to copy what the Domain had locally.

Also, I apologize; a lot of these -next branches are in an unknown state. The ability to merge differences between the installed SDRROOT on an x86 machine and the ones produced via Yocto shifted too over time and was usually one of the last things to get tested as I would push towards updating Yocto release versions at the same time as trying to shore up the REDHAWK installation behavior (on the target) and chase whatever the latest point release was. I've since left the company and do not actively maintain this project anymore or have a way to spin it up quickly to test a fix if one needs to exist. I'm happy to help however I can though.

I recall when developing this script that ownership of the x86 SDRROOT was often the problem because while one might be able to create a directory for the new implementation and copy it into the directory, one may not have the write-ability of the XML file so it wouldn't save the updated information. I thought in that case though the script would fail out with a write error. Does the output log say added about the implementation?

[SteveS-Serrano]

@btgoodwin - thanks for responding. Yes, the log says "added". I stepped through the script code to where it adds the implementation to the existing spd file. After executing the statement " 'l_msg_result = 'added' ", I forced the output by entering a command from the python interpreter to export the target_spd file. This updated the file correctly. So it looks like it's just a bug where the script doesn't export the modified file.

I'm trying to generate a simple multi-arch waveform that's the same as the example in the Waveform Basics 2.0 video (https://www.youtube.com/watch?v=SttCsAIQtSA&ab_channel=GeonTechnologies), but with the Demod running on a Xilinx ZCU102 board.

It turns out I don't need a multi-arch component implementation of the Demod, I just need the cross-complied version installed at the top of the components tree so I can access it in the IDE as a separate component from the built-in REDHAWK demod asset. But I was still curious about why the script didn't actually update the existing components into multi-implementation components.

Do you have any idea if REDHAWK is still being developed? Looks like the IDE had a lot of shortcomings if you ever wanted to develop a real application in a multi-arch embedded environment. I think without the work you did on the meta-redhawk-sdr layer, REDHAWK wouldn't have been much more useful than a host simulation environment...

[btgoodwin]

That's odd and this all sounds weirdly familiar, but I cannot see the fix in any of the more recent branches (thud, warrior, zeus) or the more heavily maintained rocko branch. If I did fix this, it's probably on one of the internal forks (which of course I can no longer access ;-)). @dbanks12 any chance you've run across this or maybe Chris (tried to @ him but it didn't populate)?

I agree and apologize, it's obviously a bug; it looks like it's missing the equivalent call of the project_spd.export() from the upper method for patching source (this.

And thank you, that's very kind. It was a team effort though, getting the embedded build to work reliably (especially in the earlier days). The Yocto community is incredibly helpful.

Also, I'm confident the REDHAWK project is still being maintained at least for x86_64. I still get release e-mails since I'm subscribed to the core framework repo, and originally planned to keep up with embedded redhawk work as a hobby but I just flat don't have the time these days.

As one of the trainers, we usually emphasized that the IDE isn't REDHAWK itself; it's purely for developmental efforts; but you're right, it fell flat when it came to doing cross-compiling. I'm not sure what happened to the effort(s) to make that better.

When developing some embedded components and devices, I found it easiest to produce the project in the IDE and then import it as a recipe into a layer leveraging this one. I would then run the prepare sysroot task so that there is a rootfs on the system with my source off to the side and open an editor from there. I think the Yocto community has made some efforts to integrate that with VSCode (I'm pretty sure I saw a presentation on it in 2020 if not 2021), so perhaps this has become a lot easier (since the build-time variables would all be setup for you like OSSIEHOME, etc.). Either way once the system is deployed, the IDE can take over as a way to orchestrate things or you can write some Yocto OE unit tests to bring up the domain, device, launch and test some waveforms, etc. (my attempts here for base service and component "up down" tests). You can even have the unit test configuration point at a target and remote control things like surge suppressors to power-cycle devices under test.

Beyond that though, if you need a mission/application -specific UI, you need a way to talk to the REDHAWK Python packages. Publicly, Geon has rest-python for that but I do not know how actively it's being maintained these days with Python 3 support coming soon to REDHAWK, etc.