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

[Mike Looijmans]

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.

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

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

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

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.




Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) – (0)499 - 33.69.79
Telefax: (+31) - (0)499 - 33.69.70
E-mail: mike.looijmans at topic.nl
Website: www.topic.nl

Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u verzocht de afzender hierover direct te informeren en het e-mail bericht met de bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of acceptatie van dit e-mail bericht of de daarbij behorende bijlagen.

The contents of this message, as well as any enclosures, are addressed personally to, and thus solely intended for the addressee. They may contain information regarding a third party. A recipient who is neither the addressee, nor empowered to receive this message on behalf of the addressee, is kindly requested to immediately inform the sender of receipt, and to destroy the message and the enclosures. Any use of the contents of this message and/or the enclosures by any other person than the addressee or person who is empowered to receive this message, is illegal towards the sender and/or the aforementioned third party. TOPIC Embedded Systems is not  liable for any damage as a result of the use and/or acceptance of this message and as well as any enclosures.