[PATCH 02/10] ARM: socfpga: add Mercury+ AA1 SoM support

[Lothar Rubusch]

Hi

On Sun, Oct 20, 2024 at 7:02 AM Marek Vasut <marex at denx.de> wrote:
>
> On 10/18/24 11:47 PM, Lothar Rubusch wrote:
> > On Mon, Oct 14, 2024 at 8:42 PM Marek Vasut <marex at denx.de> wrote:
> >
> > [...]
> >
> >>> diff --git a/board/enclustra/mercury_aa1/fpga.its b/board/enclustra/mercury_aa1/fpga.its
> >>> new file mode 100644
> >>> index 0000000000..cb42d61fbd
> >>> --- /dev/null
> >>> +++ b/board/enclustra/mercury_aa1/fpga.its
> >>> @@ -0,0 +1,32 @@
> >>> +/dts-v1/;
> >>> +
> >>> +/ {
> >>> +     description = "FIT image with FPGA bistream";
> >>> +     #address-cells = <1>;
> >>> +
> >>> +     images {
> >>> +             fpga-periph-1 {
> >>> +                     description = "FPGA peripheral bitstream";
> >>> +                     data = /incbin/("../../../bitstream.periph.rbf");
> >>> +                     type = "fpga";
> >>> +                     arch = "arm";
> >>> +                     compression = "none";
> >>> +             };
> >>> +
> >>> +             fpga-core-1 {
> >>> +                     description = "FPGA core bitstream";
> >>> +                     data = /incbin/("../../../bitstream.core.rbf");
> >>> +                     type = "fpga";
> >>> +                     arch = "arm";
> >>> +                     compression = "none";
> >>> +             };
> >>> +     };
> >>> +
> >>> +     configurations {
> >>> +             default = "config-1";
> >>> +             config-1 {
> >>> +                     description = "Boot with FPGA early IO release config";
> >>> +                     fpga = "fpga-periph-1", "fpga-core-1";
> >>> +             };
> >>> +     };
> >>> +};
> >>
> >> Can this be generated using binman instead ?
> >
> > This would a oportunity for me to learn the binman tool. Great idea! I
> > need to read a bit more on binman to get a better understanding. I'll
> > give it a try and let you know. Thank you.
>
> This commit might help:
>
> 5fccc2891e28 ("ARM: dts: stm32: Generate u-boot.itb using binman on DH
> STM32 DHSOM")
>

I face a problem here. First, to apply binman stances in the .dtsi and
integrating it as -u-boot.dtsi is very interesting and I actually like
the solution to bind everything togerther in this way.

But, I face the situation where the very design specific bitstream(s)
for the FPGA are actually not supposed to be upstreamed. Having u-boot
binaries and bitstream as .itb separate, allows to build the u-boot
part even w/o the bitstream, i.e. the u-boot setup can be quite
generic, can be tested and verified building. Is this still possible
if binman requires it as binary blob? On the otherhand it allows to
wrap the FPGA logic and exchange the .itb separately when developing a
design w/o the need to modify the bootloader.

So, I'd like to hear your opinion on that. Would the .itb appraoch be
acceptable in this case? Is there still a better way? Does it make
sense to make a separate binman setup instead?