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:
- 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.
- 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.
- 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