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.
