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

[Nathan Rossi]

On Fri, Dec 4, 2015 at 1:09 PM, Manjukumar Harthikote Matha
<manjukumar.harthikote-matha at xilinx.com> wrote:
>
>
> On 12/03/2015 05: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?
>>
>> Regards,
>> Peter
>
> Xilinx SDK toolchain is structured differently for Zynq, UltraScale+ MPSoC,
> microblaze etc and this needs to be addressed by external toolchain recipe.

Exactly why the one recipe covering all bases has become very hard to
maintain, the completely different build outs for each toolchain makes
it hard to write a one recipe fits all model. I even noticed that the
most recent MicroBlaze toolchains have changed the sysroots breaking
this external-toolchain recipe.

> By default, openembedded toolchain is used to build meta-xilinx and having
> this recipe around will give optional benefit to the user who intend to use
> Xilinx SDK toolchain
>
> Thanks
> Manju
>
>>
>>> we cannot just use meta-sourcery or meta-linaro or any
>>> others. We would want to continue using the external toolchain recipe and
>>> we

I don't see any reasons or inconsistencies that prevent users from
using the meta-sourcery layer to enable the use of the Xilinx
pre-built Zynq toolchain. Also is there something stopping Xilinx from
helping to improve the respective recipes in the linaro/sourcery
layers themselves? (both layers accept contributions)

I would still like to get more user feedback for this topic, if Xilinx
has customer/'marketing' feedback (that is specific to the use of
these toolchains in Yocto/OE) that they would like to share please do.

Regards,
Nathan

>>> 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
>
> --
> _______________________________________________
> meta-xilinx mailing list
> meta-xilinx at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx