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

[Peter Crosthwaite]

On Fri, Dec 4, 2015 at 1:22 AM, Nathan Rossi <nathan at nathanrossi.com> wrote:
> On Fri, Dec 4, 2015 at 4:19 AM, Peter Crosthwaite
> <crosthwaitepeter at gmail.com> wrote:
>> 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.
>
> Its not an easy one to solve, only so much can be done regarding
> building native tools/libs to handle this. In the end you will need to
> install your hosts native dependencies for 32bit (e.g. for libc, ld,
> etc).
>
>>
>>> * 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? :)
>
> Nope, I don't think the meta-sourcery layer contains that much sorcery ;).
>
>> 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.
>
> There are some specific functional differences that I know of with the
> 'arm-xilinx-linux-gnueabi' toolchain vs the OE built version, but
> using the meta-sourcery recipe generates approximately the same
> functional output as using the external-xilinx recipe.
>
> The most important functional difference between the OE toolchain and
> the Xilinx pre-built one is its ability to generate non-global
> functions with similar to hard-float ABI overheads (or lack of
> overheads),

As in they use hard-float?

> although I am not entirely sure whether it does or does
> not break any soft-float ABI compliance. But there are other
> non-technical reasons why users might want the Xilinx toolchain.
> However the idea would be to document how to use the toolchain via the
> use of the meta-sourcery external toolchain recipes instead of
> providing custom recipes in meta-xilinx.
>

Ok so meta-sourcery at the end of the day will still use the SDK
toolchains with the right magic in local.conf?

Regards,
Peter

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