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.
