[meta-xilinx] Dropping 'external-xilinx-toolchain' support from meta-xilinx

[Peter Crosthwaite]

On Thu, Dec 3, 2015 at 1:21 AM, Nathan Rossi <nathan at nathanrossi.com> wrote:
> Hi All,
>
> So I hinted to this in a previous email. I am looking to drop the
> 'external-xilinx-toolchain' recipe from meta-xilinx. However I would
> like to know if this is a key feature people rely on (for Zynq or
> MicroBlaze specifically).
>
> I just want to mention that their is a better solution to external
> toolchain recipes for the Zynq toolchain. The meta-sourcery layer
> provides support for CodeSourcery toolchains to be used within
> Yocto/OE, this works great for the Xilinx 'arm-xilinx-linux-gnueabi'
> (which is a CodeSourcery toolchain if you were not aware) and even
> provides the ability to use just gcc and rebuild glibc. All that is
> needed to use it is to put the layer in bblayers.conf and add the
> following lines into local.conf:
>
> TCMODE = "external-sourcery"
> EXTERNAL_TOOLCHAIN = "<path to toolchain>"
> EXTERNAL_TARGET_SYSTEMS[arm] = "arm-xilinx-linux-gnueabi"
>
> Now onto why I would like to drop this recipe. Apart from the above
> case of a better alternative recipe implementation:
>
> * Maintaining the recipe to work for a set of several different types
> of toolchain as well as several versions is becoming problematic.
> * Xilinx only provides 32-bit Host binaries for Zynq, meta-sourcery
> handles this quite well (will force building some native libs with
> 32bit support). The current recipe in meta-xilinx just assumes you
> have all the host dependencies in place for things to work.

This is a big broblem that I have run into in the past and worth solving.

> * The toolchains have limits and incompatibles with OE, Xilinx does
> not ship libiberty for example.
> * No support for gcc on target (for any architectures).
> * Also getting the toolchains is an effort (and for some people
> impossible), requiring to download and install the Xilinx tools (and
> agreeing to EULAs), this also makes it harder for users to audit and
> meet license compliance.
>

Does this mean the external sourcery will now be built from source? :)
Anyways, I think all of this sounds right, but is there any functional
difference between arm-xilinx-linux-gnueabi and a toolchain either
built by sourcery recipe or just a regular yocto ARM toolchain for
that matter? I think if we definitely know there is no functionality
needed from arm-xilinx-linux then your plan is good.

Regards,
Peter

> Thanks,
> Nathan
> --
> _______________________________________________
> meta-xilinx mailing list
> meta-xilinx at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx