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

[Bruce Ashfield]

On Fri, Apr 26, 2013 at 5:52 AM, Mike Looijmans <mike.looijmans at topic.nl> 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.
>
>
>>> 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 don't think we were talking about separate git repos, just separate directory
structures. meta-intel/* is all single repo, with the boards clearly separated.
I wouldn't want to see multiple repos either, but directories is another story.

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

This depends on the world you come from I suppose. I regularly build 40
to 50 machines and I don't share a build directory. With a properly located
shared sstate, ccache and output packages, I get all the sharing and re-use
that I need.

There are lots of front ends and scripts floating around to create a local.conf,
so that's typically how the multiple local.conf extra effort is
handled .. at least
that's how I handle it.

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

In the end, I'm ok with small board layers that can easily be picked up when
visually scanning the directories (not that someone who knows can't just
list the conf directories of a single layer and get the same result), and they
provide containers if the board differences get any "thicker" at some point in
the future.

As long as there are base architectures, and reference boards defined
with an associated BSP .. I've got the base that I need.

Cheers,

Bruce

> 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.
>
> _______________________________________________
> meta-xilinx mailing list
> meta-xilinx at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx



--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"