Running GPP in an embedded target

[rodrigo455]

While running a GPP device, I get the output:

shell-init: error retrieving current directory: getcwd: cannot access parent directories: Success ps: invalid option -- 'o' BusyBox v1.23.1 (2017-05-19 16:57:08 UTC) multi-call binary.

Usage: ps

it seems that ps from busybox doesn't have options like -e or -o. I don't know if its an issue worth solving with a patch. I was able to run a SigGen component using GPP-arm.

[btgoodwin]

Interesting. We have a patch to remove the -e from the call in the GPP's source code, and on one of the Krogoth -based builds we have here, ps -e gives a full process listing. How recent is this build?

Edit: I misspoke there. We remove -e, however I did run -e on a build before writing this comment and it did work. I'm still a bit confused why it's not a valid flag on yours.

[rodrigo455]

this patch removes the -e... well... I'm going to sync the repos and build a new image. to see if it persists... I hope not. thanks!

[rodrigo455]

in order to not open a new issue... I believe there's no --inplace option anymore in nodeconfig.py. Just a small correction for the recipe: usrp-uhd_5.0.0.bb.

[rodrigo455]

just built a new image for zc702-zynq7... usrp was troublesome with this new version, I think the blog procedure is not working.

same thing for the ps command:

root@zc702-zynq7:~# ps -e
ps: invalid option -- 'e'
BusyBox v1.24.1 (2017-07-17 11:23:21 -03) multi-call binary.

Usage: ps
root@zc702-zynq7:~# ps -o
ps: invalid option -- 'o'
BusyBox v1.24.1 (2017-07-17 11:23:21 -03) multi-call binary.

Usage: ps

Running the GPP I get just the ps invalid option --'o'. shell-init: error retrieving current directory: getcwd: cannot access parent directories: Success is not appearing anymore. =)

[btgoodwin]

I've pulled the --inplace comment into the 5.0 I'm working with in pyro -- thanks again. As for this ps issue, hopefully once my build finishes I'll be able to see a work-around/new patch. Hopefully be back with news shortly.

[btgoodwin]

By the way -- I/we really appreciate all the insight and contributions you've made. Do you have any interest in being added as a contributor to this repo?

[rodrigo455]

Thanks Thomas... please save this offer for later, I think I'm not ready for this. I am new to github, to redhawk, to yocto... still learning... I'm happy to contribute, I'll keep raising issues.

[btgoodwin]

Up to you :-) I'm happy to take pull requests as well. It all just makes it easier to pull in community changes.

On Fri, Jul 21, 2017 at 1:56 PM, rodrigo455 notifications@github.com wrote:

Thanks Thomas... please save this offer for later, I think I'm not ready for this. I am new to github, to redhawk, to yocto... still learning... I'm happy to contribute, I'll keep raising issues.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Geontech/meta-redhawk-sdr/issues/9#issuecomment-317070051, or mute the thread https://github.com/notifications/unsubscribe-auth/AFKwS3Vu-h6cnWK3Zt2elcahko0gdqU1ks5sQOZlgaJpZM4Oeeik .

[btgoodwin]

@rodrigo455 I've confirmed that on pyro as well, busybox's implementation of ps has no arguments. The goal of that line is to get the number of active threads, so I've been fooling around with how to replace ps -eo nlwp. This works for me in busybox:

cat /proc/[0-9]*/status | sed -rn 's/(Thread.+)([[:digit:]]+$)/\2/p'

The full patch is:

--- cpp/states/Limits.cpp   2016-07-26 06:56:43.926880000 -0400
+++ cpp-patched/states/Limits.cpp   2016-07-26 06:58:15.362093504 -0400
@@ -122,7 +122,7 @@
   }

   try {
-    std::string line = utils::popen("ps -eo nlwp | tail -n +2 | awk '{ num_threads += $1 } END { print num_threads }' ", true);
+    std::string line = utils::popen("cat /proc/[0-9]*/status | sed -rn 's/(Thread.+)([[:digit:]]+$)/\2/p' | awk '{ num_threads += $1 } END { print num_threads }' ", true);
     if ( line != "ERROR" ) {
       std::vector<std::string> values;
       boost::split(values, line, boost::is_any_of(std::string(" \t")), boost::algorithm::token_compress_on );

[rodrigo455]

hmmmm great! running both commands in ubuntu I get different values:

$ cat /proc/[0-9]*/status | sed -rn 's/(Thread.+)([[:digit:]]+$)/\2/p' | awk '{ num_threads += $1 } END { print num_threads }' 
495
$ ps -eo nlwp | tail -n +2 | awk '{ num_threads += $1 } END { print num_threads }' 
635

thanks so far! I'm going to test this patch later! I'll tell you the results

[btgoodwin]

Interesting the numbers are different. I'm sure it's some nuance of how each procedure counts threads ('active', etc.).

The patch has been pulled into the stack of Pyro commits that I'm still chipping my way through right now.

I just found another bug/glitch in how we build the GPP's first node on startup as well as during the recipe. Then when node-deployer launches on first start-up, it collects those other two generated nodes and gives you two GPPs instead of just the one. Rather worse than that, the core framework's implementation of uuid is trying to call the shell which results in "command not found" and invalid instantiation ID in the node configuration for the one generated at startup. I'm going to setup a patch against the core framework to use the python package and remove one of those node generation scripts in my next commit.

[btgoodwin]

The v2.0.6-1 tag on master now addresses these issues (and pyro branch). I tested it along with several other bugs that were discovered along the way with:

export MACHINE=qemuarm64
bitbake redhawk-test-image
runqemu qemuarm64

The emulated environment will boot with all available components and softpkgs installed along with omninames, omnievents, domain, and GPP node init.d scripts (starting in that order). I then went into the python shell and used the sandbox (from ossie.utils import sb) to create a waveform with a particular component, and then launched it using the domain reference provided by the redhawk package (from ossie.utils import redhawk).

Thanks again @rodrigo455 for pointing the above issues out and the others you opened. A lot of this wasn't touched in a long time, and should have been (I apologize). This is a lot more solid now.

To anyone reading this afterwards wishing the tag was for krogoth: it might as well be. There is likely no issue with using the v2.0.6-1 tag with a krogoth build. If anyone confirms this, please submit an issue or contact us. Thanks!

[rodrigo455]

Thanks Thomas! confirming that it works with krogoth... many enhancements! that's great! For a pyro build... there's no fftwf recipe in the pyro branch of meta-openembedded.

[btgoodwin]

Thanks for the confirmation about krogoth!

And that's another one I somehow missed. 👎 Hopefully this is the last errant/missed commit.

I remember just deleting that line from nativesdk.inc early on since the package does PROVIDES fftwf which is good enough for the libfft softpkg.

Any chance you're at a place where you can test changing it to fftw in nativesdk.inc (or just deleting that line)? If not, I can stand the the environment back up in a bit.

[rodrigo455]

not right now... but I believe it should be enough... Just a new issue:

$ nodeBooter -D
ERROR:nodebooter - Unable to launch DomainManager Softpkg: No matching implementation found

going to investigate

[btgoodwin]

Alright, that's a new one.

I'm starting over from scratch over here to see what else may have gone wrong.

On Thu, Jul 27, 2017 at 1:41 PM, rodrigo455 notifications@github.com wrote:

not right now... fftwf appears in:

[meta-redhawk-sdr]$ grep -r fftwf recipes-core/images/native-sdk.inc: fftwf \ recipes-softpkg/fftlib/rh-fftlib_2.0.0.bb:DEPENDS += "rh-dsp fftwf" recipes-softpkg/fftlib/rh-fftlib2.0.0.bb:RDEPENDS${PN} += "rh-dsp fftwf"

Just a new issue:

$ nodeBooter -D ERROR:nodebooter - Unable to launch DomainManager Softpkg: No matching implementation found

going to investigate

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Geontech/meta-redhawk-sdr/issues/9#issuecomment-318434329, or mute the thread https://github.com/notifications/unsubscribe-auth/AFKwS5yZWSNfbfnP0mcCatrEpb3xR1ARks5sSMvVgaJpZM4Oeeik .

[rodrigo455]

nodebooter gets the processor name using uname (armv7l) while the meta-redhawk-sdr uses PACKAGE_ARCH (cortexa9hf-neon) they can be different...

[btgoodwin]

I was about to bring this up as the reason for the mismatch (mistmatch of processor declarations).

And unfortunately yes it sounds like those two values can be different. I've seen some uname responses on embedded builds come back empty, which is why I patch a lot of these node config python scripts the devices have so that it doesn't try to guess and then default to x86.

What machine are you targeting (if you can say)?

And I think I see the issue for pyro for my build. It started off as a krogoth build, I modified the manifest for pyro and introduced a typo (just fixed that). So when the sync occurred, it didn't throw an error...it just silently failed. So all my commits, etc., I thought were against Pyro were actually against krogoth.

I'm going to pull these last couple tags. It's Revisionist History (a.k.a., bad), but so far I've had to rename iperf to iperf3, fftwf to fftw (in that include file and the fftlib softpkg for the latter). That has my build rolling forward now so I'll see what else is out there over night.

To everyone who has tried to use Pyro so far and is also reading this thread: I apologize and am working this now.

On Thu, Jul 27, 2017 at 2:11 PM, rodrigo455 notifications@github.com wrote:

nodebooter gets the processor name using uname while the meta-redhawk-sdr uses PACKAGE_ARCH... are they different?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Geontech/meta-redhawk-sdr/issues/9#issuecomment-318442427, or mute the thread https://github.com/notifications/unsubscribe-auth/AFKwSzIi1B0B1j0w4Wm_ioi36RgxPGG9ks5sSNLIgaJpZM4Oeeik .

[rodrigo455]

targeting zc702. PACKAGE_ARCH is cortexa9hf-neon uname -m gives me armv7l

[btgoodwin]

If you print out the rest of the environment (bitbake -e > env.txt), are there any other variables getting set to armv7l then? Maybe there's something common being used (I'm searching right now; it looked like PACKAGE_ARCH was it, at a glance).

Thomas

On Thu, Jul 27, 2017 at 2:34 PM, rodrigo455 notifications@github.com wrote:

targeting zc702. PACKAGE_ARCH = cortexa9hf-neon uname -m gives me armv7l

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Geontech/meta-redhawk-sdr/issues/9#issuecomment-318448752, or mute the thread https://github.com/notifications/unsubscribe-auth/AFKwS2vnIHW_3cICwazy4pJsvDIR5Xljks5sSNgngaJpZM4Oeeik .

[rodrigo455]

unfortunately there isn't a patch for nodebooter.cpp at line 1166 might solve this... not the right solution

[btgoodwin]

How would you feel about a top-level variable that can be set by the user (like SDRROOT, etc.)?

For example, UNAME_MACHINE ?= "armv7l" and then that variable would replace the usage of PACKAGE_ARCH in the few patches. If someone needs something other than armv7l, they can set it in their configuration or export it at the command line.

On Thu, Jul 27, 2017 at 2:39 PM, rodrigo455 notifications@github.com wrote:

unfortunately there isn't

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Geontech/meta-redhawk-sdr/issues/9#issuecomment-318450189, or mute the thread https://github.com/notifications/unsubscribe-auth/AFKwS8-y2MSjJllCBcZj_VNDmc9V4Z_7ks5sSNlngaJpZM4Oeeik .

[rodrigo455]

BUILD_ARCH is the variable we want

[btgoodwin]

That seems to be the architecture of the builder (according to the comments). When I do that with MACHINE set to qemuarm64, BUILD_ARCH gets set to x86_64.

On Thu, Jul 27, 2017 at 2:58 PM, rodrigo455 notifications@github.com wrote:

BUILD_ARCH is variable we want

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Geontech/meta-redhawk-sdr/issues/9#issuecomment-318455331, or mute the thread https://github.com/notifications/unsubscribe-auth/AFKwS8I7qo4UIcqlEn8wOvzAX8UnI1fiks5sSN3PgaJpZM4Oeeik .

[rodrigo455]

seems to be a way out... armv7l is nowhere else.

[btgoodwin]

I'm trying to figure out a way to pull it the virtual/kernel build (regex it off wherever it gets hard-coded to the utsname). My download of the kernel is taking a long time today... I may have to come back to this in the morning.

From a couple responses down on this link:

https://unix.stackexchange.com/questions/136959/where-does-uname-get-its-information-from

We might be able to pull it off the #define for UTS_MACHINE once the kernel is setup.

On Thu, Jul 27, 2017 at 3:10 PM, rodrigo455 notifications@github.com wrote:

seems to be a way out... armv7l is nowhere else.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Geontech/meta-redhawk-sdr/issues/9#issuecomment-318458636, or mute the thread https://github.com/notifications/unsubscribe-auth/AFKwS1F760mdoE-p4f5Sir2KpCe0Z9pAks5sSODBgaJpZM4Oeeik .

[btgoodwin]

Yep. That looks positive. After the kernel_configcheck you end up with include/generated/compile.h being populated with #define UTS_MACHINE "some_value". I'll patch this in the morning.

On Thu, Jul 27, 2017 at 3:20 PM, Thomas Goodwin btgoodwin@geontech.com wrote:

I'm trying to figure out a way to pull it the virtual/kernel build (regex it off wherever it gets hard-coded to the utsname). My download of the kernel is taking a long time today... I may have to come back to this in the morning.

From a couple responses down on this link:

https://unix.stackexchange.com/questions/136959/where-does-uname-get-its- information-from

We might be able to pull it off the #define for UTS_MACHINE once the kernel is setup.

On Thu, Jul 27, 2017 at 3:10 PM, rodrigo455 notifications@github.com wrote:

seems to be a way out... armv7l is nowhere else.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Geontech/meta-redhawk-sdr/issues/9#issuecomment-318458636, or mute the thread https://github.com/notifications/unsubscribe-auth/AFKwS1F760mdoE-p4f5Sir2KpCe0Z9pAks5sSODBgaJpZM4Oeeik .

[btgoodwin]

For me, this value matches the environment variable: TRANSLATED_TARGET_ARCH. Does it match for you as well?

On Thu, Jul 27, 2017 at 3:47 PM, Thomas Goodwin btgoodwin@geontech.com wrote:

Yep. That looks positive. After the kernel_configcheck you end up with include/generated/compile.h being populated with #define UTS_MACHINE "some_value". I'll patch this in the morning.

On Thu, Jul 27, 2017 at 3:20 PM, Thomas Goodwin btgoodwin@geontech.com wrote:

I'm trying to figure out a way to pull it the virtual/kernel build (regex it off wherever it gets hard-coded to the utsname). My download of the kernel is taking a long time today... I may have to come back to this in the morning.

From a couple responses down on this link:

https://unix.stackexchange.com/questions/136959/where-does- uname-get-its-information-from

We might be able to pull it off the #define for UTS_MACHINE once the kernel is setup.

On Thu, Jul 27, 2017 at 3:10 PM, rodrigo455 notifications@github.com wrote:

seems to be a way out... armv7l is nowhere else.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Geontech/meta-redhawk-sdr/issues/9#issuecomment-318458636, or mute the thread https://github.com/notifications/unsubscribe-auth/AFKwS1F760mdoE-p4f5Sir2KpCe0Z9pAks5sSODBgaJpZM4Oeeik .

[rodrigo455]

TRANSLATED_TARGET_ARCH="arm" not armv7l

[btgoodwin]

Alright, thank you. What I've come up with is a little bit of a hack. I've made a recipe (uname-machine) that depends on the kernel. Its package pulls the value of UTS_MACHINE from ${STAGING_KERNEL_BUILDDIR}/include/generated/compiled.h and installs it as the text of a file: ${OSSIEHOME}/share/uname_machine. Other recipes can then pull it in as needed (which I'm doing right now to replace PACKAGE_ARCH). I'll post an update on this thread once I push (but I'll hold off on tagging until you have a chance to try it for yours too).

On Fri, Jul 28, 2017 at 7:57 AM, rodrigo455 notifications@github.com wrote:

TRANSLATED_TARGET_ARCH="arm" not armv7l

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Geontech/meta-redhawk-sdr/issues/9#issuecomment-318633552, or mute the thread https://github.com/notifications/unsubscribe-auth/AFKwS96z0cAbkIBQaLgun1Kds0D0Nstuks5sScyYgaJpZM4Oeeik .