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

[Nathan Rossi]

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), 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.

Regards,
Nathan

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