[U-Boot] [PATCH v2 14/23] sunxi: H3: add DRAM controller single bit delay support

[Simon Glass]

Hi Andre,

[...]

>>> I wonder if there is value in moving this to device tree with of-platdata?
>
> While I kind of like the idea of using the DT for this, there are some
> issues:
>
> 1) There is no binding so far for representing the DRAM data. Given the
> lacking documentation for the DRAM controller it sounds very hard to
> come up with a good binding anyway. Also we can't push this through the
> Linux DT binding review, since this is of no interest to the kernel. And
> I'd rather avoid making up some dodgy binding just for this.
>
> There is work underway to improve the DRAM init code and make it more
> robust and flexible. Ideally we can use some autodetection and
> calibration feature the controller offers to get rid of arbitrary magic
> numbers. But this is quite some work ahead and shouldn't block the much
> sought after A64 SPL support for now.
>
> 2) If there is need, we can detect the SoC easily by reading the ID
> register and differentiate at runtime. This is probably less code than
> pulling in DT bits, also more robust.
>
>> I think device tree support is unlikely to fit in SPL for sunxi.
>> IIRC Andre already mentions the space constraints in his cover letter.
>
> 3) Yes, adding DT support for the SPL makes it rather big. I think it
> breaks the 28K limit that the mksunxiboot tool currently has. This can
> (and will) be fixed later, but just for this exercise I'd rather keep it
> small, especially as we would use it only for the DRAM code and not for
> the device drivers.

Take a look at rk3288-firefly if you like. It has an ad-hoc device
tree binding (no one has the energy to try to get this into Linux :-).

With of-platdata, DT support doesn't actually add any space (or at
least very little). There is no libfdt and the only code is that
needed to copy data from the of-platdata struct to the normal one.

That said, there has to be a benefit, and it's much more desirable to
spend the time on this IMO:

>
> Actually I have a plan to make better use of DT, but not for the SPL. To
> a good degree the SPL code mimics the on-SoC boot ROM operation
> (accessing storage devices to load code), which has to work with every
> board already and thus does not need a board specific DT.
> I can elaborate on that if there is interest.

Regards,
Simon