On 05/10/21, Jorge Ramirez-Ortiz, Foundries wrote:
> On 04/10/21, Alex G. wrote:
> > On 10/4/21 3:32 PM, Jorge Ramirez-Ortiz, Foundries wrote:
> > > Hello,
> > >
>
> hi Alex,
>
> > > We are enabling secure boot on Zynqmp with SPL.
> > >
> > > The issue however is that during secure boot, the bootrom not only
> > > validates the first loader (SPL and PMUFW combo) but it will also
> > > expect a signed bitstream during load(FPGA).
> > >
> > > Since currently the SPL load of an FPGA image from FIT does not
> > > support loading images for authentication (fpga_loads), I'd like to
> > > discuss how to best implement such support.
> >
> > What do you mean by "loading images for authentication" ?
>
> right, it eventually means executing fpga_loads insted of fpga_load (
> a function that will provide additional params to the PMUFW.
>
> "loads" will load FPGA bitstreams that are either signed, encrypted or
> both. When they are only signed, they are first authenticated by the
> PMUFW and then loaded.
>
> > >
> > > A pretty standard file.its description of the FPGA loadable looks like
> > > this:
> > >
> > > fpga {
> > > description = "FPGA binary";
> > > data = /incbin/("${DEPLOY_DIR_IMAGE}/${SPL_FPGA_BINARY}");
> > > type = "fpga";
> > > arch = "${UBOOT_ARCH}";
> > > compression = "none";
> > > load = <${fpgaloadaddr}>;
> > > hash-1 {
> > > algo = "${FIT_HASH_ALG}";
> > > };
> > > };
> > >
> > > We could extend imagetool.h struct image_tool_params to add more
> > > params or perhpas just define different 'types' of fpga?
> >
> >
> > Check "4) '/images' node"
> > in doc/uImage.FIT/source_file_format.txt
> >
> > The intent is to give either:
> > * loadaddr="$(addr)" : copy image to $(addr), Done
> > * compatible="": Use this driver to upload the FPGA
> >
> > It seems to me like the right way to go is to make a new compatible="" FPGA
> > loader is for fpga_load():
> >
> > fpga {
> > description = "FPGA binary";
> > data = /incbin/("${YOCTO_BS_PATH}");
> > type = "fpga";
> > compression = "none";
> > compatible = "zynqmp-fancy-fpga",
>
> so you think we should capture on compatible the characteristics of the FPGA
> image?
um, right, makes sense then, thanks.
- compatible : compatible method for loading image.
Mandatory for types: "fpga", and images that do not specify a load address.
To use the generic fpga loading routine, use "u-boot,fpga-legacy"
>
> > hash-1 {
> > algo = "${FIT_HASHISH}";
> > };
> > };
> >
> >
> > > Something like:
> > > "fpga"
> > > "fpga-auth" : authenticated
> > > "fpga-enc" : encrypted
> > > "fpga-sec" : encrypted and authenticated
> >
> > Can these properties be inferred from the FPGA image? If not, they could be
> > required when using a new fpga loader. I don't think they should be added to
> > "fpga-legacy".
>
> maybe.. with a bit of boot header parsing... But doing so would
> deviate from the current approach making it somewhat inconsistent: ie,
> there is no a common "fpga load" command but instead we have "fpga
> load" and "fpga loads" as separate commands so perhaps the parsing is
> not that obvious or it would have been done differently.
> I'd rather follow the current approach and just explicitly qualify the
> bitstream.
>
>
>
> >
> > Alex
> >
> > > Then it would be a matter of modifying
> > > https://github.com/u-boot/u-boot/blob/master/common/spl/spl_fit.c#L572
> > >
> > > any thoughts?
> > >
> > > TIA
> > > Jorge
> > >
