[meta-xilinx] Introduction and feedback on meta-xilinx

[Nathan Rossi]

On Wed, Nov 25, 2015 at 11:12 AM, Manjukumar Harthikote Matha
<manjukumar.harthikote-matha at xilinx.com> wrote:
>
>
> On 11/24/2015 03:36 PM, Peter Crosthwaite wrote:
>>
>> On Tue, Nov 24, 2015 at 3:12 PM, Manjukumar Harthikote Matha
>> <manjukumar.harthikote-matha at xilinx.com> wrote:
>>>
>>> Hi all,
>>>
>>> My name is Manju, I have recently joined Xilinx Inc and will be working
>>> on
>>> meta-xilinx layer to provide continuous support and integration. Nathan
>>> has
>>> been helping out to a lot to maintain this layer, I will be working along
>>> with him to provide the support for this layer.
>>>
>>> Our near term goals for meta-xilinx are
>>>
>>> 1. OSL releases based on meta-xilinx
>>>
>>
>> I don't understand how this would work, and it feels like an inversion
>> of the upstream-downstream relationship. Shouldn't meta-xilinx pull
>> from OSL sources as appropriate and use an appropriate release, in
>> much that same way it does with the major mainline sources? OSL is the
>> upstream for those components and has it's own release schedule which
>> should not need to depend on a downstream. Is that schedule still
>> based on Xilinx tool releases?
>>
>
> Hi Peter,
>
> Our plan was to use all the tagged releases from linux-xlnx, u-boot-xlnx and
> Xilinx toolchain to build the OSL images.
>
> For example we would use v2015.3 tag from all the sources(linux-xlnx,
> u-boot-xlnx) and use v2015.3 Xilinx toolchain to build OSL images. Once the
> images are built and tested, we will tag meta-xilinx as well.
>
> Anything incorrect with this approach?
>
> Yes OSL release schedule will be based on Xilinx tool releases.

Having the Xilinx kernel sources/etc based on xilinx-v* tags is the
current process. What everyone at Xilinx always seemed to forget is
that there is no 1:1 relationship with meta-xilinx releases (aka
branches, or yocto releases) and Xilinx tool versions/releases. Which
means that a meta-xilinx branch might have one or more versions of a
linux-xlnx kernel, and one or more branches of meta-xilinx might have
the same linux-xlnx version. This is why when setting out the
meta-xilinx plan we made sure it was understood (internally within
Xilinx) that meta-xilinx would NEVER be tagged for Xillinx tool
releases, it serves no purpose except to confuse users.

What should be done instead is to provide the specific refs/commit
id's (via repo/submodules/text-on-a-wiki-page) for the layers used in
order to produce the OSL images that are released for a specific
Xilinx tool version.

As for '4. To restructure as a pure BSP layer for direct reuse
across:', no need to do anything there meta-xilinx is a 'pure' BSP
layer. The problem is not the meta-xilinx layer, the problem has
always been trying to convince the respective people at distro vendors
(Mentor, WindRiver, Enea, etc) to actually use the layer as they had
internal versions (because Xilinx was late to the party) that they had
for Zynq which they controlled and were happy using because they could
make changes there for their customers.

Regards,
Nathan

>
> Thanks
> Manju
>
>
>> Regards,
>> Peter
>>
>>> 2. Updates for toolchain, kernel versions, Yocto versions etc.
>>>
>>> 3. Support for UltraScale+ MPSoC platforms (Machine definitions for
>>> ZC1751,
>>> ZCU102 etc)
>>>
> --
> _______________________________________________
> meta-xilinx mailing list
> meta-xilinx at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx