From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Date: Thu, 15 Jun 2017 19:21:07 +0000
Subject: [U-Boot] [PATCH] arc: Move dram_init out of arch code,
	into board code
In-Reply-To: <016844bc-c826-d74f-9087-8b27d91b8cc5@adaptrum.com>
References: <20170605174959.2268-1-alex.g@adaptrum.com>
 <1496690522.2492.4.camel@synopsys.com>
 <016844bc-c826-d74f-9087-8b27d91b8cc5@adaptrum.com>
Message-ID: <1497554466.2945.27.camel@synopsys.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
To: u-boot@lists.denx.de

Hi Alexandru,

On Mon, 2017-06-05 at 13:00 -0700, Alexandru Gagniuc wrote:
> On 06/05/2017 12:22 PM, Alexey Brodkin wrote:
> > 
> > Hi Alexandru,
> > 
> > On Mon, 2017-06-05 at 10:49 -0700, Alexandru Gagniuc wrote:
> > > 
> > > The following commit
> > > f1683aa board_f: Rename initdram() to dram_init()
> > > wrongly assumed that the lack of DRAM init is the property of the
> > > architecture. In fact, it is only the AXS10x boards that do not need a
> > > special raminit. Those assumptions are not true on the ARC SoC we're
> > > looking at.
> > 
> > Actually there're more boards with ARC cores.
> > In particular nSIM for ARC700  and ARC HS38, as well as Abilis TB100.
> 
> Oops. Missed those. I'll have an updated patch later in the week.
> 
> 
> > 
> > So it might make sense to declare generic dram_init() in arch/arc/lib/cpu.c
> > as a weak function and add your own implementations as needed.
> 
> I disagree. The few saved lines of code to properly link the correct 
> function are not worth the lost days when figuring out why my xyz() 
> function is not doing the right thing.
> 
> 
> > 
> > BTW since commit 80e4bbfcd92d "travisci: Add support for ARC"
> 
> I'll give that a try, thanks!

Any progress with that one?
Or I'm missing your respin(s)?

-Alexey