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

[Nathan Rossi]

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.
* 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.

Thanks,
Nathan