[U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

[Dalon L Westergreen]

I am reading through this thread, and want to point out that it is not that the
FPGA bridge need be actively used in the fpga, but
rather that this port be configured in the FPGA configuration.  This is an
important distinction, ecery FPGA design that
instantiates the HPS does configure the F2S Bridge.  it drives select pins,
control pins, data pins, etc, on the interface to known values, 
and so the apply can always be done as all SoC FPGA designs have the soc
instantiated.  If someone boots the arm, and uses an
FPGA design without having the soc instantiated, it may then cause issues, but i
would argue that is not a supported use
in the first place.

--dalon

On Fri, 2020-02-07 at 14:49 +0100, Marek Vasut wrote:
> On 2/7/20 2:44 PM, Simon Goldschmidt wrote:
> 
> [...]
> 
> > > > This depends on the FPGA image, while currently the Altera work flow compiles
> > > > it into the U-Boot binary.While I'm still working on moving this into the U-Boot
> > > > dts (I still have size issues there), it's still not encoded with the FPGA.
> > > 
> > > Well you can dig this information out of the handoff files , so you can
> > > also make this somehow configurable via either DT or bridge command args.
> > 
> > 
> > My point was this can differ between FPGA images. Once you load an FPGA image
> > that doesn't match what you expected when building (or flashing) U-Boot, the
> > system may lock up again.
> > 
> > DT is not an option, as you hard-code it when flashing U-Boot.
> 
> You can apply a DTO on the U-Boot DT :-)
> 
> > The loaded FPGA
> > image can still change.Bridge command args is a way of how to get this info into
> > the code that runs, but from where do these command args come? You need to
> > somehow parse this info from an FPGA image file read from storage.
> 
> Maybe this could be part of a fitImage or DTO bundled with the FPGA image ?
> 
> > > > What we would need is some kind of meta info with the FPGA image that tells us
> > > > how to configure the bridges (and maybe some clocks or hardware handed off into
> > > > the FPGA) after programming the FPGA.
> > > 
> > > fitImage ? :)
> > I thought of that, too. Maybe a short dts (maybe overlay) beside the FPGA. But
> > then it would again not work when loading a pure rbf. But then again, that might
> > be ok...
> 
> That's probably OK. If you're loading pure RBF, then you know what
> you're doing.
> 
> > So I could imagine this to "just work" when someday I finally have finished my
> > series of moving this handoff info into dts and then including an overlay dts
> > into a fit image that gets applied after programming the FPGA (and by/after
> > applying it, the code that applies bridge settings would run). Would that work?
> 
> I think so.