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

[Nathan Rossi]

On Sat, Dec 5, 2015 at 4:42 AM, Peter Crosthwaite
<crosthwaitepeter at gmail.com> wrote:
> 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?

I am not exactly sure on the specifics of what the toolchain is doing,
but for example the function
(https://github.com/nathanrossi/meta-random/blob/master/meta-toolchain-test/recipes-benchmark/benchmark-float/files/benchmark-float.c#L23)
which has float params, when called from within the same binary
exhibits less overhead than doing the same with the OE toolchain.
However its not as if this performance cannot be obtained by simply
using armhf instead of soft-float with the OE toolchain, which works
even better since it allows for the ABI to work across shared object
boundaries (you can try the benchmark-float application in the layer I
linked if you are interested in seeing the differences).

>
>> 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?

Yes that is exactly how it works.

Regards,
Nathan

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