From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Tue, 6 Dec 2016 22:48:13 -0500 Subject: [U-Boot] [PATCH v2 14/23] sunxi: H3: add DRAM controller single bit delay support In-Reply-To: <39749994-375b-a6ee-d540-fa368128bf20@arm.com> References: <1480902750-839-1-git-send-email-andre.przywara@arm.com> <1480902750-839-15-git-send-email-andre.przywara@arm.com> <39749994-375b-a6ee-d540-fa368128bf20@arm.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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