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

[Nathan Rossi]

On Sun, Dec 6, 2015 at 6:56 AM, Peter Crosthwaite
<crosthwaitepeter at gmail.com> wrote:
> On Sat, Dec 5, 2015 at 12:47 AM, Nathan Rossi <nathan at nathanrossi.com> wrote:
>> 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).
>>
>
> So the only reason you would want to do this is to link perf critical
> float code with random soft-float pre-built binaries. But with Yocto
> building everything in the target from source, you should have access
> to across the board HF which is correct solution. But if this local-hf
> feature is to have longevity shouldn't it be upstreamed? Also, is it
> simply available via some sort of generic sourcery release?

I think you answered your own question. The upstream solution is
'hard-float' :D. And using multilib if there is a need to run
softfloat mixed with hardfloat on the same system (bit like the
32bit/64bit host).

I am not sure if it's available in a generic arm soft float linux
toolchain from codesourcery, I went to go download it but as Peter
Smith noted its not available any more (at least without registering).

So essentially users that want this Xilinx SDK toolchain are mainly
after it for non-technical reasons, at least that is my understanding.

>
>>>
>>>> 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.
>>
>
> Ok, so you are not actually defeaturing the SDK toolchain and there is
> no functional limitation here. Just the way it is done. Users will
> still have access to the SDK toolchain via a well documented flow.

Half/Half, for the Zynq/arm toolchain provided by Xilinx you would
still be able to use it with the meta-sourcery layer. However for
MicroBlaze toolchain provided by Xilinx there would be no recipe, so
it would be de-featured.

Regards,
Nathan

>
> Regards,
> Peter
>
>> 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