[meta-xilinx] what are the canonical xilinx mailing lists/repos these days?

[Philip Balister]

On 08/05/2013 01:53 AM, Mike Looijmans wrote:
> On 08/03/2013 09:24 PM, Michael Rissi wrote:
>> Dear all,
>> Just hooking up on the topic: For the zedboard, I tried out the official
>> meta-xilinx layer, as well as meta-zynq-milo.
>> Both worked great. meta-zynq-milo, however, has 2 main features I liked
>> a lot which are not in meta-xilinx:
>> - One can easily change the device where the root filesystem is located
>> by changing the file autorun.scr. This allows to easily switch from
>> rootfs over nfs  to e.g. the rootfs on the second partition of the sd
>> card.
> 
> In fact you can do much more. For example, you can create an autorun SD
> card that automatically flashes a new image to the internal flash when
> you boot it. This is very convenient for low-volume production boards,
> which can then be programmed simply by inserting a card and switching it
> on.
> 
> The change is only a small patch on u-boot, it mostly modifies the script.
> 
> Also important is to note the change in load addresses. Loading the
> kernel directly into the correct memory location saves u-boot the
> trouble of memcpy-ing it there after unpacking.
> 
> If you need any help, I'll be happy to provide it.

The patch in question is:

https://github.com/milosoftware/meta-zynq/blob/master/recipes-bsp/u-boot/u-boot-zynq-git/0001-Use-bootscript-to-boot-use-fast-XIP-load-address-no-.patch

It looks like this patch does several, unrelated, things. Spitting the
patch into independent chunks should make it easier to move into u-boot
and/or meta-xilinx.

We need to solve the ramdisk only focus in meta-xilinx. I have several
people asking about building gnuradio for the zedboard. This image will
not fit in a ramdisk :)

Finally, given we have no long term solution for building the fsbl, I do
like the idea of adding the binary to the layer (at least for well
defined dev boards) and having a task to build the boot.bin file. One
thing I would do is add a test for the existence of the bootgen utility
and skip building boot.bin if the Xilinx tools are not available on the
build machine.

Are any of the Xilinx u-boot team following discussion on this list?

Philip


> 
>> For meta-xilinx, this is much harder to change and needed quite
>> some recipe editing from my side. The default in meta-xilinx is a ram
>> disk as rootfs, limited to some 12MB.
> 
> The Xilinx layer seems very much targeted at just running that one
> demonstration program. I don't expect anyone, for actual production use,
> to ever use a ramdisk setup like this.
> 
>> - A very nice feature is also the automatic creation of the BOOT.bin
>> file using the xilinx bootgen in meta-zynq-milo.
> 
> Unfortunately it does not create the FSBL yet, I still haven't figured
> out how to automate that. The only way to create it involves lots of
> mouse clicks. Maybe it'll be possible with vivado.
> 
> But I'd still rather see the "boot.bin" be replaced by u-boot-spl or
> something similar.
> 
>> Thus I wondered if there is any change that meta-zynq-milo and
>> meta-xilinx might be merged, or that at least some features from
>> meta-zynq-milo are added to meta-xilinx? I am also willing to contribute
>> and to test if needed.
> 
> You have my blessing. And help, if you want.
> 
> Mike.
> 
> 
> 
> 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