From owner-svn-src-all@freebsd.org Fri Apr 22 21:40:08 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0AF07B18A93 for ; Fri, 22 Apr 2016 21:40:08 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5C3D1EEA for ; Fri, 22 Apr 2016 21:40:07 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: b6e95894-08d2-11e6-b8f9-33a5b3560672 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 22 Apr 2016 21:39:38 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u3MLdw8h044801; Fri, 22 Apr 2016 15:39:58 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1461361198.1191.39.camel@freebsd.org> Subject: Re: svn commit: r298477 - in head/sys: conf riscv/riscv From: Ian Lepore To: Marko Zec , Ruslan Bukin Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Fri, 22 Apr 2016 15:39:58 -0600 In-Reply-To: <20160422233137.7f37bb47@x23> References: <201604221615.u3MGFxCM088374@repo.freebsd.org> <20160422233137.7f37bb47@x23> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 21:40:08 -0000 On Fri, 2016-04-22 at 23:31 +0200, Marko Zec wrote: > On Fri, 22 Apr 2016 16:15:59 +0000 > Ruslan Bukin wrote: > > > Author: br > > Date: Fri Apr 22 16:15:58 2016 > > New Revision: 298477 > > URL: https://svnweb.freebsd.org/changeset/base/298477 > > > > Log: > > Clear the DDR memory. This should be done by bootloaders, > > but they have no such feature yet. > > > > This fixes operation on Rocket Core and lowRISC. > > > > Modified: > > head/sys/conf/options.riscv > > head/sys/riscv/riscv/locore.S > > > > Modified: head/sys/conf/options.riscv > > ============================================================================== > > --- head/sys/conf/options.riscv> > > > Fri Apr 22 15:12:05 > > 2016> > > > (r298476) +++ head/sys/conf/options.riscv> > > > Fri Apr > > 22 16:15:58 2016> > > > (r298477) @@ -2,3 +2,4 @@ > > > > RISCV> > > > > > > > > > opt_global.h > > VFP> > > > > > > > > > opt_global.h > > +DDR_CLEAR_SIZE> > > > > > > > opt_global.h > > > > Modified: head/sys/riscv/riscv/locore.S > > ============================================================================== > > --- head/sys/riscv/riscv/locore.S> > > > Fri Apr 22 15:12:05 > > 2016> > > > (r298476) +++ head/sys/riscv/riscv/locore.S> > > > Fri > > Apr 22 16:15:58 2016> > > > (r298477) @@ -126,6 +126,17 @@ _start: > > > > > > csrr> > > > a0, mhartid > > > > > > bnez> > > > a0, mpentry > > > > +#if defined(DDR_CLEAR_SIZE) > > +> > > > /* Clear DDR memory */ > > +> > > > la> > > > t0, _end > > +> > > > li> > > > t1, DDR_CLEAR_SIZE > > +1: > > +> > > > sd> > > > zero, 0(t0) > > +> > > > addi> > > > t0, t0, 8 > > +> > > > bltu> > > > t0, t1, 1b > > Usually _end appears to be (double) word aligned, but that happens out > of pure luck, since compilers do not provide firm guarantees about > _end's alignment (at least gcc doesn't, as far as I know). > > So depending on which kind of RV this code would run, sometimes it may > end up doing a lot of traps emulating unaligned access in software, or > worse... > > Hence it would't hurt to check for _end's alignment first and do a few > byte-by-byte bzero()ing if needed, before proceeding a dword pace. > > All of our kernel linker scripts ensure that _end is aligned correctly for the platform, except powerpc and powerpc64. I'm not sure if it's just not required for those, or maybe it's an oversight that has been harmless so far. -- Ian