On Sat, Feb 9, 2019 at 11:25 AM Marek Vasut <ma...@denx.de> wrote: > > On 2/7/19 10:23 PM, Simon Goldschmidt wrote: > > To clean up reset handling for socfpga gen5, let's move the code snippet > > taking the DDR controller out of reset from SPL to the DDR driver. > > > > While at it, port the ddr driver to UCLASS_RAM and use dts. > > > > Signed-off-by: Simon Goldschmidt <simon.k.r.goldschm...@gmail.com> > > --- > > > > This is an RFC to show what the SDRAM driver moved to DM (UCLASS_RAM) would > > look like. It's RFC both because Dinh did not seem too fond of changing the > > register address of the SDR in devicetree to include what the undocumented > > registers 'sequencer.c' uses as well as because of my observed code growth. > > Dinh, if the SDRAM controller spans some addresses, it should be > described like so in the DT. Whether those registers are documented or > not does not matter, DT is a hardware description and should describe > hardware accurately. > > > Basically, I want to move this to UCLASS_RAM and I want to read the reset > > property for SDR from devicetree. What remains RFC is: do we want/need to > > read the base address from devicetree, or can we live with it being hard- > > coded (and maybe sanity-checked during probe)? > > > > Note that converting sequencer.c from hard-coded address to pointers read > > from devicetree and passed around to every function increased code size by > > ~700 bytes. Not too much, but enough to stop my socrates board working > > (yes, the SPL size check does not work :-( - I'll work on that). > > > > Also note that this is an integrated patch for SoCrates to show what it > > would look like. In the series I prepared, it's better separated and all > > boards are adjusted. > > I wonder, rather than passing $sdr around, could we have a static $sdr > and support only one single instance of the DRAM controller ? Would that > trim down the size growth ?
Let me check that. It's worth trying. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
