1. Topics
  2. sdk-ng

sdk-ng

Erwin Rol
 

Hey All,

when going over the 1.9 plans I noticed "sdk-ng".

When looking into the "sdk-ng" repo I noticed switching from yocto to
crosstools-ng.

One question; why ?

- Erwin
Nashif, Anas
 

The current SDK is very difficult to maintain, requires lots of resources to build and is not compatible with how crosstool compilers from vendors are being distributed. There are a few other issues, for example it is only available on Linux, crosstools-ng gives us support for the Mac as well. Another things is portability, try moving binaries around, this fails with the current SDK. All in all, we are trying to make it simpler and easier to maintain and we want to rely on vendor toolchains rather than build everything ourselves in one giant blob and then have to support it. We are not in the toolchain business, we want to leave this to the experts and rely on recipes that are simple that the way it is right now.

Anas

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Erwin Rol
Sent: Tuesday, June 13, 2017 7:21 PM
To: zephyr-devel <zephyr-devel@...>
Subject: [Zephyr-devel] sdk-ng

Hey All,

when going over the 1.9 plans I noticed "sdk-ng".

When looking into the "sdk-ng" repo I noticed switching from yocto to crosstools-ng.

One question; why ?

- Erwin
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
Erwin Rol
 

Hey Anas,

thanks for the explanation, I just wondered because Intel, Linaro, the
Linux Foundation, etc. all seem Yocto members, where crosstools-ng seems
to be pretty much a one-man-show (looking at the github commits).

On 14-6-2017 2:11, Nashif, Anas wrote:
The current SDK is very difficult to maintain, requires lots of
resources to build
And crosstools-ng is easier? Looking at ptxdist (which I already use for
years) there is still a lot of tuning needed. Same with RTEMS, they also
seem to put a lot of effort in toolchain maintenance and tuning,
especially integration with newlib.

And what about tools like openocd, they aren't part of crosstools-ng,
are they?

and is not compatible with how crosstool compilers
from vendors are being distributed.
In what way "not compatible"? Aren't most vendors distributing some huge
(eclipse)IDE with some GCC deep inside? (I am thinking about things like
AC6, Atmel-Studio, etc.) Is there any "general" way to distribute a
toolchain?

There are a few other issues, for
example it is only available on Linux, crosstools-ng gives us support
for the Mac as well.
Isn't Yocto capable to build SDK/toolchains that can run on Windows, Mac
and Linux?

Another things is portability, try moving binaries
around, this fails with the current SDK.
That sounds a bit like a non-issue to me. Most big software packages can
not be moved around. Of course others might have usecases where being
able to move around the binaries is useful.

All in all, we are trying to
make it simpler and easier to maintain and we want to rely on vendor
toolchains rather than build everything ourselves in one giant blob and
then have to support it. We are not in the toolchain business, we want
to leave this to the experts and rely on recipes that are simple that
the way it is right now.
My experience is that those vendors are in the business of selling
chips, and most software that comes from them is terrible. Look at the
AVR32 support from Atmel, they proudly present a GCC 4.4.X
(http://distribute.atmel.no/tools/opensource/Atmel-AVR32-GNU-Toolchain/3.4.3/)
in the form of patches that apparently no GCC developer wants to touch.

And from a user point of view, I thought it was very easy to download
and install the Zephyr toolchains, and get to work with them. I would
hate to have some readme.txt explaining to me I have to install 1
toolchain from Atmel, 1 from ST, 1 from Intel, all with different GUI
installers (of course we want point-and-click) and all with their own
huge (eclipse) IDE.

- Erwin
Nashif, Anas
 

Erwin,
The experience should be the same as with the current SDK. I did not say anything about downloading IDEs and from various vendors. There are well-established, standalone toolchains available that are better supported than what we have in the current SDK. Membership in the yocto project is really not a factor here. We are trying to keep things simple and remove the burden of having to maintain toolchains as part of the project. Believe it or not, the Zephyr SDK is also a one man show, yocto being a tool here that has nothing to do with the content of the SDK itself. And no, yocto does not give us an SDK on no Linux platforms and I am not sure what you mean with ptxdist... For the Zephyr developer just like with the current SDK it will be a downloadable file that installs some toolchains, in other cases it will download toolchains maintained by vendors like ARM, Intel and Synopsys etc.

Anas

-----Original Message-----
From: Erwin Rol [mailto:mailinglists@...]
Sent: Tuesday, June 13, 2017 9:44 PM
To: Nashif, Anas <anas.nashif@...>; zephyr-devel <zephyr-devel@...>
Subject: Re: [Zephyr-devel] sdk-ng

Hey Anas,

thanks for the explanation, I just wondered because Intel, Linaro, the Linux Foundation, etc. all seem Yocto members, where crosstools-ng seems to be pretty much a one-man-show (looking at the github commits).

On 14-6-2017 2:11, Nashif, Anas wrote:
The current SDK is very difficult to maintain, requires lots of
resources to build
And crosstools-ng is easier? Looking at ptxdist (which I already use for
years) there is still a lot of tuning needed. Same with RTEMS, they also seem to put a lot of effort in toolchain maintenance and tuning, especially integration with newlib.

And what about tools like openocd, they aren't part of crosstools-ng, are they?

and is not compatible with how crosstool compilers from vendors are
being distributed.
In what way "not compatible"? Aren't most vendors distributing some huge (eclipse)IDE with some GCC deep inside? (I am thinking about things like AC6, Atmel-Studio, etc.) Is there any "general" way to distribute a toolchain?

There are a few other issues, for
example it is only available on Linux, crosstools-ng gives us support
for the Mac as well.
Isn't Yocto capable to build SDK/toolchains that can run on Windows, Mac and Linux?

Another things is portability, try moving binaries around, this fails
with the current SDK.
That sounds a bit like a non-issue to me. Most big software packages can not be moved around. Of course others might have usecases where being able to move around the binaries is useful.

All in all, we are trying to
make it simpler and easier to maintain and we want to rely on vendor
toolchains rather than build everything ourselves in one giant blob
and then have to support it. We are not in the toolchain business, we
want to leave this to the experts and rely on recipes that are simple
that the way it is right now.
My experience is that those vendors are in the business of selling chips, and most software that comes from them is terrible. Look at the
AVR32 support from Atmel, they proudly present a GCC 4.4.X
(http://distribute.atmel.no/tools/opensource/Atmel-AVR32-GNU-Toolchain/3.4.3/)
in the form of patches that apparently no GCC developer wants to touch.

And from a user point of view, I thought it was very easy to download and install the Zephyr toolchains, and get to work with them. I would hate to have some readme.txt explaining to me I have to install 1 toolchain from Atmel, 1 from ST, 1 from Intel, all with different GUI installers (of course we want point-and-click) and all with their own huge (eclipse) IDE.

- Erwin
Erwin Rol
 

Hey Anas,

On 14-6-2017 3:56, Nashif, Anas wrote:
Erwin,
The experience should be the same as with the current SDK.
Well than I will be happy :-)

I did not
say anything about downloading IDEs and from various vendors. There are
well-established, standalone toolchains available that are better
supported than what we have in the current SDK.
But do they offer what Zephyr needs? Especially when it comes to the C
library. To take the RTEMS example again, newlib has a lot of RTEMS
support in it.

https://www.sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree;f=newlib/libc/sys;hb=HEAD

When things like that are also needed for Zephyr how will those things
end up in the vendor toolchains (and in what timeframe) ?

Membership in the yocto
project is really not a factor here.
When working for small companies one can quickly forget that at Intel
not everybody talks to each other during the coffee break :-)

We are trying to keep things simple
and remove the burden of having to maintain toolchains as part of the
project. Believe it or not, the Zephyr SDK is also a one man show, yocto
being a tool here that has nothing to do with the content of the SDK
itself.
But Yocto does offer infrastructure to download and build tools via a
documented setup.

And no, yocto does not give us an SDK on no Linux platforms and
I thought there was the possibility to do a Candadian cross via
meta-mingw. But never used it so can't say if it would work for the
Zephyr toolchain.

I am not sure what you mean with ptxdist...
www.ptxdist.org is a buildroot-like tool that also used crosstools. It
is mainly used in Germany I guess.

For the Zephyr developer
just like with the current SDK it will be a downloadable file that
installs some toolchains, in other cases it will download toolchains
maintained by vendors like ARM, Intel and Synopsys etc.
Still not convinced it is the right way, but since I can not "put my
money where my mouth is", I will just accept what ever will be offered. :-)

- Erwin
1 - 5 of 5