[meta-xilinx] Why no support for FSBL?

[Vidhumouli Hunsigida]

Hi Philip,

It is beyond Obscurity. Internal Safety team has given us NO Go as it has some information related architectures of FPGA and some other details that I cannot share in open source here.

Regards,
Vidhumouli

-----Original Message-----
From: Philip Balister [mailto:philip at balister.org] 
Sent: Thursday, November 23, 2017 12:16 AM
To: Vidhumouli Hunsigida <vidhum at xilinx.com>; Nathan Rossi <nathan at nathanrossi.com>; Peter Smith <salerio at gmail.com>
Cc: Prashant Malladi <pmallad at xilinx.com>; Joel A. Seely <jseely at xilinx.com>; meta-xilinx at yoctoproject.org
Subject: Re: [meta-xilinx] Why no support for FSBL?

On 11/22/2017 07:01 AM, Vidhumouli Hunsigida wrote:
> Nathan,
> 
> It is not entirely true that the issue is due to Bootgen being not open sourced.
> 
> Here are few points.
> 
> 1. Bootgen stiches the images as per constrainsts of BootROM and FSBL and the user inputs on images and the related authentication and encryption.
> 2. Customer can write their own FSBL as needed and can give it as input to Bootgen. The flow etc.is more controlled by FSBL than the bootgen.
> 3. The entire information that you mentioned about FSBL related to the tables and formats of the table are well documented in SDG (UG-1137). One is free to write their own code if they wish as needed for their own basic flow.
> 4. There are multiple reasons related to safety, security and support which makes the Bootgen to be not open sourced.

I'm curious. What are these reasons? Security through obscurity was discredited years ago.

Philip

> 
> Regards,
> Vidhumouli
> 
> 
> -----Original Message-----
> From: meta-xilinx-bounces at yoctoproject.org 
> [mailto:meta-xilinx-bounces at yoctoproject.org] On Behalf Of Nathan 
> Rossi
> Sent: Tuesday, November 21, 2017 7:48 PM
> To: Peter Smith <salerio at gmail.com>
> Cc: meta-xilinx at yoctoproject.org
> Subject: Re: [meta-xilinx] Why no support for FSBL?
> 
> On 21 November 2017 at 07:08, Peter Smith <salerio at gmail.com> wrote:
>> Hi, I’m aware of the meta-xilinx-tools layer, but this needs you to 
>> have the Xilinx SDK installed (unless I’m mistaken), I was wondering 
>> ion there were any plans to create support in meta-xilinx for 
>> building the FSBL without the need for the SDK dependency. Peter
>>
>>
>> On 20 Nov 2017, at 21:05, Giordon Stark <kratsg at gmail.com> wrote:
>>
>> Hi (resending from right address),
>>
>> You can indeed build the FSBL + boot.bin using the meta-xilinx-tools layer:
>> https://github.com/Xilinx/meta-xilinx-tools
>>
>> Giordon
>>
>> On Mon, Nov 20, 2017 at 3:03 PM Peter Smith <salerio at gmail.com> wrote:
>>>
>>> A question, I was wondering why there is no support for building 
>>> FSBL in a similar way to that provided by meta-xilinx for the PMU 
>>> firmware, is there a technical reason or is it just one of those 
>>> things that has not yet been got around to? Thanks in advance Peter.
> 
> So it all comes down to bootgen. The boot.bin built by the bootgen tool from XSDK/etc. has an FSBL specific image table which is how it encodes multiple images for u-boot.elf, bitstream, etc. Because this bootgen tool is not available as public code and the special headers/image table are subject to the whim of the FSBL built (and indirectly the target version of the Xilinx tools); it is not easy to provide support for building a complete boot.bin with FSBL outside of the Xilinx tools.
> 
> Building FSBL in the same way as PMU Firmware (as in meta-xilinx) is possible and years ago I had a very rough recipe for it. However since U-Boot SPL support appeared (and subsequent support for boot.bin generation with U-Boot's mkimage) it was much more palatable for Linux users, as for most cases FSBL was used to load U-Boot anyway and U-Boot SPL does a better job at that.
> 
> Now with meta-xilinx-tools covering FSBL/bootgen I don't see much of a benefit in having FSBL built how PMU firmware is in meta-xilinx. Since the reasons behind the users choice to use FSBL are generally because it is the flow which Xilinx provides, and so it makes more sense to use the better supported flow of building/configuring it.
> 
> Regards,
> Nathan
> --
> _______________________________________________
> meta-xilinx mailing list
> meta-xilinx at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
>