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

[Philip Balister]

On 12/03/2015 08:48 PM, Peter Crosthwaite wrote:
> On Thu, Dec 3, 2015 at 4:38 PM, Manjukumar Harthikote Matha
> <manjukumar.harthikote-matha at xilinx.com> wrote:
>> Hi Nathan,
>>
>> On 12/03/2015 01:21 AM, Nathan Rossi 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).
>>>
>> For all SOC's (Zynq, UltraScale+ MPSoC, microblaze)
>>
>>> 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.
>>>
>> We need to support Xilinx toolchain for various SOC's. Due to inconsistency
>> in Xilinx toolchain
> 
> What are the inconsistencies?
> 

Just to add my two cents, I only intend to use toolchains from
OpenEmbedded. I can't imagine any reason to use a vendor toolchain in
this day and age. If I have long term support issues, I expect the
toolchain vendor to support their toolchain, not the SOC vendor.

Philip

> Regards,
> Peter
> 
>> we cannot just use meta-sourcery or meta-linaro or any
>> others. We would want to continue using the external toolchain recipe and we
>> are going to send out a series of patches to update this recipe (including
>> support for aarch64).
>>
>> Thanks
>> Manju
>>
>> --
>> _______________________________________________
>> meta-xilinx mailing list
>> meta-xilinx at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-xilinx