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

[Marek Vasut]

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.