Moving to Sumo/Thud

[meriturva]

Just to know, are you planning to move to Sumo (Yocto 2.5)? A just would like to add meta-java layer (latest version is on sumo) and meta-iot-cloud that uses thud:

https://github.com/intel-iot-devkit/meta-iot-cloud

I mean, we could easily refer to specific rocko branches of both projects but is there any roadmap or milestone on update process?

So thanks.

[jan-kiszka]

Moving to 2.5 or 2.6 has one hurdle to overcome, discontinued Quark support in meta-intel, but it is surely technically doable. However, when this will be done has not yet been scheduled. Any contribution to this layer into that direction can help to accelerate this, though.

[jan-kiszka]

I started looking into a thud update. The major blocker is unfortunately nodejs:

• nodejs 6 is the last (stable) version to officially support Quark-class processors, so we currently depend on it
• nodejs 6 no longer builds with thud, likely due to the newer openssl version

Will have to look deeper into this to asses if there is a way out. Options so far:

• fix build by (also) providing the older dependency that nodejs expects
• patch a newer nodejs to work with Quark again

The first option looks simpler but will not solve the fundamental issue (several unmaintained components that are also security sensitive), and the second can be very complicated.

[deinok]

just to look if this receipe could help: https://github.com/openembedded/meta-openembedded/tree/master/meta-oe/recipes-devtools/nodejs

Also, why Node is interacting to the CPU directly other than executing i586 native code?

[jan-kiszka]

I didn't check the nodejs code myself yet, but I was told that it assumes SSE & Co. support by now (8.x and newer), and that is missing on Quark.

[deinok]

Not sure also, but I think that Node do checks at runtime to check SIMD instructions.

We could check with just the board layer if it is able to run some foreach code in javascript (That should trigger the SIMD issue if it exists)

[jan-kiszka]

FWIW, I explored path 1 (use openssl 1.0 rather than 1.1 for nodejs6), and that - after some swearing - led to successful nodejs and nodejs-native builds. HOWEVER, mraa fails now as it both pulls python (with openssl 1.1) and nodejs. And there might be more conflicts. Seems this is not leading to quick success, if at all.

Will dig into path 2 the other day, checking first what colleagues already tried. I think there was a thread in the forum on that.

[nospam2000]

see issue #104

[jan-kiszka]

For reference https://groups.google.com/forum/#!topic/v8-dev/SJU63-g84fQ (V8 is the JavaScript engine used by node.js).

This change went into node.js 8.7.0 initially. OK, then let's go back in time, using 8.4.0 recipes from OE. But that would have been too simple: only 8.11.0 gained openssl 1.1 support.

I also looked at the x87-removal diff briefly. It's huge, but we may get it hammered into the 8.x branch. Newer versions seem unrealistic. Or we back-port the openssl 1.1 changes to 8.6. In any case: node.quark will be the result, at best.

[jan-kiszka]

@nospam2000 Yes, now I remember :smile:. In line with my findings, will try the porting nevertheless.

[deinok]

@jan-kiszka Seems like we are having a lot of problems due Intel Quark. What are the probabilities that the next hardware iteration of IOT20XX move to another more modern CPU and Arch (like for example a Broadcom BCM2837)

Also, I think that is important to split the bsp layer from the example. In our case seems like we can move to thud due node issues. Even that we dont use anything from the example image (Most of our work is done in C++ and in Mono)

[jan-kiszka]

@deinok The next generation of this device will use a recent powerful processor. It will also use a Linux distro, Debian, as baseline, rather than a distro generator (AKA Yocto) that requires local maintenance.

The layers are already split, they are just coupled via kas configuration management to the same Yocto version. And I have a patch that allows to build meta-iot200-bsp against thud. I still need to test if the result also runs, but then I will make this available as preview so that you can choose the target Yocto version more freely when only using the bsp.

[Themesaul]

@deinok The next generation of this device will use a recent powerful processor. It will also use a Linux distro, Debian, as baseline, rather than a distro generator (AKA Yocto) that requires local maintenance.

The layers are already split, they are just coupled via kas configuration management to the same Yocto version. And I have a patch that allows to build meta-iot200-bsp against thud. I still need to test if the result also runs, but then I will make this available as preview so that you can choose the target Yocto version more freely when only using the bsp.

What is the new device? When will it come out?

[jan-kiszka]

@Themesaul I cannot comment on product details and schedules beyond what has been announced already. Please talk to our official support channels regarding this.

[Themesaul]

Okay thank you very much 😊

[jan-kiszka]

Just pushed https://github.com/siemens/meta-iot2000/commits/jan/thud, after validating it on a real target. It's only thud for the BSP so far.

I've also made some progress with Node.js 8 for our target, but no breakthough and no idea if that is reachable (node builds with re-enabled x87 support but crashes somewhere in generated code).

[jan-kiszka]

To keep you posted: Since today, after almost 2 weeks of porting and debugging, Node.js 8.15.0 works on the IOT2000, running at least our demo flow without issues. Quite a bit of integration work remains to get the layer in similar shape, but this is clearly an important milestone. The patch itself is already "saved" to jan/thud (7a190771b6ea5a78eaedc5e23bf0dd127dc903a9)

[jan-kiszka]

New version in jan/thud (c8fcc9fa1a0aecd1f90f7f80be30771c9fc17b68), now providing a full image with updated yocto and Node.js. I still need to update the node-red recipes to pull the latest versions, though. Any early testing would be appreciated!

[jan-kiszka]

Merged into master.