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

[Mike Looijmans]

On 08/06/2013 03:51 PM, Philip Balister wrote:
> 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.

My initial setup had that, but there were too many changes going on in 
that same file, that it became too much of a burden to manage. And since 
I failed to raise any interest at Xilinx for these changes, I figured I 
might as well join them in a much easier to merge single patch.

If anyone at xilinx is interested, I'll be happy to rebase and split 
this into useable chunks, and post the git patches wherever you want them.

> 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 :)

I've been using ubifs on the interal flash chips for quite some time. 
I'm planning on expanding that even further, e.g. by storing the kernel 
into the rootfs as well (u-boot can read ubi systems). This will 
increase the boot time a bit, but offers much more flexibility, improves 
load-balancing and doesn't need to waste as much space. This is a 
particularly interesting way of booting for NAND systems. Just put a few 
copies of the bootloader at the start of the NAND, and the rest of the 
NAND is neatly managed by UBI. A bootloader in a small nor flash (~1MB) 
usually has my preference, then you can have all of the NAND flash in a 
nicely load-balanced error-handling filesystem.

If you like read-only systems, make a squashfs root. 32MB of that will 
be able to contain a lot of stuff, like a big GUI. A squashfs can be 
written to the serial flash from within the bootloader.

Personally, a ramdisk would be my last choice. Even while bootstrapping 
a new board, I tend to tftp (or even xmodem) a kernel and squashfs root 
into the board.

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

I guess you saw my today's dastardly deed.

I rather prefer the explicit error at this stage. The u-boot binary 
isn't of any use, and the Xilinx GUI tools can't use it anyway. And 
without a (new) boot.bin, the board won't boot.

A newbie might be tempted to write u-boot.bin in the first flash sector 
(like most other boards) and that just won't work.


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

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