[meta-xilinx] ZC702 support in Xilinx meta-xilinx

Tue Apr 23 21:03:27 PDT 2013

Hi Elvis

On Tuesday, 23 April 2013 5:20 PM, Elvis Dowson wrote
>
>Hi Sipke,
>I like the idea of creating meta-board ayers, but do you intend to build 
>a meta-board layer for each development board? e.g meta-zedboard, 
>meta-zc702, meta-zc706, meta-zc770, meta-vc707, meta-vc709, etc?
>

Yes we intend to provide layers for a number of boards likely starting with 
zedboard, ZC702, ZC706 for Zynq and SP605, ML605, KC705 for Microblaze.  

>I've seen the meta-intel layers, as well, and the thing that comes to mind 
>is that the Xilinx platforms are a bit unique in that things are not fixed 
>and are hardware programmable by nature.
>For all classes of development boards across the Spartan, Artix, Kintex and 
>Virtex families, you can end up using the microblaze processor, with kernel 
>support derived from a single source for the kernel and bootloader. 

You are right that Xilinx platforms are unique, especially Microblaze. 
For each of the boards you mention the important factor for Linux (or any
other OS I guess) is that they will 'run' Microblaze. Hence 
our intention would be to have the 'Microblaze architecture' in the 
meta-xilinx layer and supported 'boards' in seperate board/bsp layers.

>You can 
>supply defconfigs and dts files and patches in a single layer or multiple 
>layers, but do you intend to create a meta-layer for each board? 

Yes it is our intention at this point to have a layer per board. I think 
there is an advantage in layering because it will help distinguish between 
architecture and bsp (i.e. Zynq and Microblaze vs Board/BSP 'configuration')

>There will 
>be a lot of commonality between boards, so while I really like the concept 
>of using meta-board layers, 

This is a good point. We can probably cover the commonalities using include 
files from the meta-xilinx layer (as per current ?tune.inc files ) when it 
makes sense. This will include things like common kernel recipe features 
(e.g. kconfig fragments) especially for IP that works on any FPGA fabric 
(e.g. PCIe drivers).

>at some point the return on investment for the 
>split doesnt pay back, versus just simply supplying a board specific machine-
>config in a common layer.
>

I think the investment is minimal as the  board layers are likely to be
very thin layers and can be seen as 'templates' or 'kick start' layer which 
can be expanded by users.

>Perhaps you should organize using SOC_FAMILY in meta layers instead, e.g 
>meta-microblaze, meta-zynq-7, etc, and then create meta-board layers like 
>meta-zedboard, meta-zc702, meta-zc770, etc that leverage those meta SOC_FAMILY
>layers. This way you would have core SOC support, and others can leverage of 
>example meta-board layer templates.
>

We investigated the SOC_FAMILY concept slightly and were unsure whether we 
could cleanly apply it to Microblaze and Zynq. Good that you bring it up 
though as we need to investigate this further in case it is a better solution.
Feedback from others as regards the appropriateness or not of using SOC_FAMILY 
as compared to current setup would be appreciated.

Either way, as you suggest, we would still like to use the meta-board layers 
as templates to provide a stable/known starting point for users.

>Additionally while on this topic, any thoughts on how one would maintain 
>different configurations for a board, using different kernel sources, e.g 
>Xilinx and Analog Devices, and manage this in an easy way in a custom board 
>layer and switch between them?
>

If I understand your question, we have done some investigation, but found
that it seems to be common practice to have kernel and bsps/machine 
definitions quite inter-related, so other than overiding the preferred 
provider as Mike mentioned in his reply, there will likely remain a 
'connection' between a bsp/board layer and a kernel. This does of course  
have the advantage that it would be a 'supported' combination, so users 
have a good starting point.

Regards
Sipke

>Elvis Dowson
>
>On Apr 23, 2013, at 10:26, Sipke Vriend <sipke.vriend at xilinx.com> wrote:
>
>> Hi Philip,
>> 
>> I've pushed the current state of our kernel and u-boot recipes in 
>> github.com/Xilinx/meta-xilinx.
>> They are both in development, but show our current thoughts on how they
>> might look. Only a meta-zedboard bsp layer at this point, but the ZC702 fill follow 
>> the same concept. There will still be some refactoring, including fragments 
>> for defconfigs and dts.
>> The meta-workarounds/misc/build folder has the corresponding local.conf 
>> files as examples.
>> 
>> Regards
>> Sipke
>> 
>> 
>>> On 04/17/2013 12:20 AM, Sipke Vriend wrote:
>>>> Hi Philip,
>>>> 
>>>>> 
>>>>> -----Original Message-----
>>>>> From: meta-xilinx-bounces at yoctoproject.org 
>>>>> [mailto:meta-xilinx-bounces at yoctoproject.org] On Behalf Of Philip Balister
>>>>> Sent: Wednesday, 17 April 2013 3:53 AM
>>>>> To: meta-xilinx at yoctoproject.org
>>>>> Subject: [meta-xilinx] ZC702 support in Xilinx meta-xilinx
>>>>> 
>>>>> Will Xilinx take patches adding support for the zc702 to their
>>>>> meta-xilinx layer? I'd like to start adding it to my layer stack so I
>>>>> can make sure it works for me (and I do not get any breakage from the
>>>>> other changes in the layer :)
>>>> 
>>>> If the 'patches' you are referring to are something not already exemplified 
>>>> in your repository then feel free to email me with requests or suggestions. 
>>>> Our work is very developmental so real patches are not desired at this point. 
>>>> Currently we have been using all layers as pseudo-patches, i.e inspiration 
>>>> for our work in an attempt to ensure our 'bottom rung architecture' layer 
>>>> is successful.
>>>> 
>>>>> I am trying to avoid chasing layers to find the best one for each
>>>>> situation and also would like the zynq community to have a central place
>>>>> for a BSP.
>>>> 
>>>> I guess that falls into our plan, though remember our layer will  
>>>> possibly be more minimalistic than needed by some - i.e will require a
>>>> layer on top.
>>> 
>>> Can you push your zynq kernel recipe? That is really my main focus at
>>> the moment.
>>> 
>>> Philip
>>> 
>>>> 
>>>> We are planning to model our meta-xilinx similar to meta-intel where the core 
>>>> architecture items are in the root directory of meta-xilinx and then there will be 
>>>> numerous meta- folders for each supported bsp or bsp group. This is not visible in 
>>>> repository currently.
>>>> Source code wise (kernel, uboot, qemu) all recipes will firstly be based on Xilinx 
>>>> repositories and will select known stable commits.
>>>> 
>>>>> Philip
>>>>> _______________________________________________
>>>>> meta-xilinx mailing list
>>>>> meta-xilinx at yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/meta-xilinx
>> 
>> 
>> _______________________________________________
>> meta-xilinx mailing list
>> meta-xilinx at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-xilinx
>
>