[meta-xilinx] Bitstream/Boot.bin/etc - Providers/Virtual targets

[Mike Looijmans]

On 02/20/2014 09:48 AM, Michal Simek wrote:
> On 02/20/2014 08:57 AM, Mike Looijmans wrote:
>> On 02/19/2014 03:02 PM, Mike Looijmans wrote:
>>> One major thing is that the SPL build fails without CONFIG_SPL_FPGA_SUPPORT
>>> defined.
>>
>> This one is still puzzling me.
>>
>> I'd like to build it with FPGA support in the "big" u-boot, but without it in the SPL part.
>
> What about this?
>
> diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
> index 5738ad3..3710baf 100644
> --- a/board/xilinx/zynq/board.c
> +++ b/board/xilinx/zynq/board.c
> @@ -59,7 +59,8 @@ int board_init(void)
>           */
>          writel(0x26d, 0xe0001014);
>
> -#ifdef CONFIG_FPGA
> +#if (defined(CONFIG_FPGA) && !defined(CONFIG_SPL_BUILD)) || \
> +    (defined(CONFIG_SPL_FPGA_SUPPORT) && defined(CONFIG_SPL_BUILD))
>          fpga_init();
>          fpga_add(fpga_xilinx, &fpga);
>   #endif
>

Yeah, something like that should work just fine. I was looking for the define 
that determined whether we were in "SPL" mode. Didn't expect that to be 
CONFIG_SPL_BUILD though.


> Just use what it is suitable for you.
> Load fpga from spl is also correct for example when you have memory controller from PL.
> U-boot is here to support all options which are useful and for this case both are useful.

Of course. I'm just a performance freak, so I don't want the SPL to go hunting 
for files that don't exist.

> If there is compilation problem just report it or fix it yourself and I will
> appreciate if you will provide this patch for others too.

I have it booting from QSPI as well (blazing fast).

One of the things I want to change is to let the SPL loader try harder to 
boot. Now it just tries one method and if that fails, it just gives up.

I want it to try all methods. First, try booting with the device we started 
with, so spi when booting from flash and mmc when booting from SD and so on. 
If that fails, try other methods, for example, after SPI, try SD, then serial, 
etcetera. Makes it easier to debrick a board, especially if you cannot change 
the boot device with jumpers...

I was thinking along the lines of replacing the "hang()" in the various boot 
methods by a "return -1" and let the caller decide on what to do next.

What do you think, interesting or bad?



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.