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

[Michal Simek]

On 02/20/2014 07:26 PM, Mike Looijmans wrote:
> 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.

ok good.


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

That's why there are config options.


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


I can imagine any better logic there especially when image in one location doesn't exist
you should use any golden images to be able to boot from different location.
The question is if that location should be on different device and I can also imagine
that too.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20140221/a3cc5d86/attachment.pgp>