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

[Sipke Vriend]

Hi Mike

On Friday, 26 April 2013 7:52 PM Mike Looijmans wrote
>
>On 04/25/2013 11:54 PM, Sipke Vriend wrote:
>> Hi Mike,
>>
>> You may well have something that we have overlooked, so I've got some
>> questions below to try to further understand.
>>
>> On Wednesday, 24 April 2013 4:11 PM, Mike Looijmans wrote
>>>
>>>> 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')
>>>
>>> What would be the advantage of having a BSP per board?
>>>
>>
>> The multiple board/bsp layers just extract any board info (and this is minimal)
>> into a separate layer. For users, the advantages I guess are primarily for us as
>>   a vendor and new users, not so much for advanced users. Advanced users are
>> likely to ignore these bspboard layers and create their own on top of the
>> architecture layers. New users though have a starting point by having a
>> minimalistic board layer to start investigating.
>
>What I meant was, "why is it better to have a separate overlay for each 
>zynq evaluation board instead of just having one overlay support 
>multiple boards?"
>I don't see how haven a dozen almost identical overlays is going to help 
>users, advanced or beginners. And you'd probably need a "common" layer 
>anyway, because the recipes and config files will be 99% equal.
>

You are right, technically there isn't really any advantage in
thin board layers, it's just a question of preferred layout I guess.
We do have a common layer which deal with the main features, and result 
in the board layers being very thin.

>>> I can mostly only find disadvantages. Many of the OpenEmbedded projects
>>> I work with are designed to build on multiple targets. Usually a single
>>> environment builds two or three different machines, and often this
>>> number increases when there are newer (or prototype) versions of
>>> products. One project now builds for 22 machine configurations.
>>>
>>
>> Are you saying that having multiple 'thin template bsp/board layers' would
>> hinder these multi-machine targeted projects?
>
>Yes. I increases the number of submodules (or whatever one would use to 
>track them) one has to track.
>

I guess this is true only early on, once 'our thin board layers' have been
'proven' by any user, they are likely to replace them with their own, and 
this could be a layer with all machines defined in one layer if they chose?
If this happens, then having thin 'example' board layers as we propose, 
allows them to drop our board layers easily by removing them from bblayers.

>> If so, this is significant and we need to understand it so we can allow
>> for such builds. Some information as to how the builds actually happen,
>> like are there multiple build folders each with local.conf and bblayers
>> files etc would help in understanding the process.
>
>Typically, when building for multiple machines, there is just one build 
>directory. To switch targets to another machine, just change the MACHINE 
>environment variable (either by changing local.conf or by exporting it 
>from the shell into bitbake, so one can type "MACHINE=zedboard bitbake 
>my-image".
>
>OE is pretty good at tracking machines and dependencies. After building 
>an image for the zc702, building the same image for the zedboard target 
>would take about 5 minutes, as it only has to compile the kernel and 
>bootloader and a handful of machine-specific recipes.
>

Right, as a comparison we achieve this by including all meta-boardlayers 
in the bblayers of the build directory and then just switching MACHINE 
value. So the only real difference is if a new board layer is added one 
needs to update bblayers of build directory. If manual update is 
undesired then I guess some python code could be introduced, or we could 
send a patch to OE to allow a wild card to bblayers :-)

>>> I can see a case for a "microblaze" and a "zynq" layer, but I really
>>> don't see the advantage of having a zc702, zedboard, and various other
>>> separate layers that must be versioned and managed separately.
>>>
>>
>> Understood and we have considered having separate microblaze and zynq
>> layers. Currently this is achieved through tune includes only.
>> We are in development and appreciate these kind of comments a lot.
>
>The case here is that a "microblaze" system doesn't actually exist until 
>the FPGA logic has been initialized, along with whatever other steps 
>required to get the bootloader going.
>

Microblaze is a difficult one and hence we intend to provide a base design, 
which users can modify. We'll never cover all bases.
Our main effort for microblaze has been the creation of configurable tunes 
so this is consistent and predictable (see previous emails and our 
repository for details). We still need to add some additional sanity 
checking around this to avoid undesired instruction set combinations.

>A zynq system behaves like a standard ARM platform, where the CPU always 
>exists and can load the bootloader without any assistance. Using the 
>programmable logic is only optional, it isn't really required until a 
>userspace application wants to access it.
>
>That difference has a much larger impact on the way people will want to 
>build images than the CPU architecture. The Zynq platform is further 
>away from the microblaze than a MIPS system.
>
>>> A EVM is usually a starting point for a project. It usually evolves from
>>> there, first just adding hardware to the board, and later with product
>>> prototypes based on similar hardware.
>>
>> Agreed that the EVMs are starting points, and our 'template bsp/board
>> layers' are targeting those starting points, particularly for new users.
>> Let's call them 'EVM layers', to help clarify their purpose.
>>
>>> When problems arise, we usually
>>> evaluate if the other board showed the same symptoms, so we can find out
>>> whether it's the hardware or software to blame. That makes it very
>>> important to always have access to multiple machines. If we need to add
>>> or switch layers to be able to target other machines, we can no longer
>>> be sure that we are using the same software on both, and we would have
>>> to thoroughly investigate the changes that each layer brings.
>>
>> As asked above, I think I need a bit of enlightenment in how the
>> multiple machine targeting actually happens. Examples of existing OE
>> machines targeted, as a comparison, would help also.
>
>The most practical example is the layer I use for the zedboard/zc702. 
>The difference between them is so small, they can share the recipes for 
>bootloader, logic, fsbl, kernel and all the rest.
>
>When building, i typically just execute "MACHINE=zynq-zc702 bitbake 
>my-image" to start a build.
>

So the only difference is that in our layout all board layers would need 
to be added to the bblayers?

Regards
Sipke