From owner-freebsd-arm@FreeBSD.ORG Mon Aug 6 11:07:05 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42213106568A for ; Mon, 6 Aug 2012 11:07:05 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2656F8FC08 for ; Mon, 6 Aug 2012 11:07:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q76B754B021702 for ; Mon, 6 Aug 2012 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q76B74YD021700 for freebsd-arm@FreeBSD.org; Mon, 6 Aug 2012 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 Aug 2012 11:07:04 GMT Message-Id: <201208061107.q76B74YD021700@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 11:07:05 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/166256 arm build fail in pmap.c o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) o arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 p arm/134338 arm [patch] Lock GPIO accesses on ixp425 13 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Aug 6 14:40:04 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34E8410656B6; Mon, 6 Aug 2012 14:40:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 82D608FC15; Mon, 6 Aug 2012 14:40:03 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B91D1B981; Mon, 6 Aug 2012 10:40:02 -0400 (EDT) From: John Baldwin To: Peter Jeremy Date: Mon, 6 Aug 2012 10:26:06 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <20120703111753.GB72292@server.rulingia.com> <20120708110516.GA38312@server.rulingia.com> <201207120826.05577.jhb@freebsd.org> In-Reply-To: <201207120826.05577.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201208061026.06328.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 06 Aug 2012 10:40:02 -0400 (EDT) Cc: arm@freebsd.org, mips@freebsd.org Subject: On-stack allocation of DMA S/G lists X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 14:40:04 -0000 On Thursday, July 12, 2012 8:26:05 am John Baldwin wrote: > On Sunday, July 08, 2012 7:05:16 am Peter Jeremy wrote: > > BTW(2): Whilst studying busdma_machdep.c for arm and mips, I've > > noticed they appear to potentially allocate substantial kernel stack > > under some conditions as several bus_dma(9) functions include: > > bus_dma_segment_t dm_segments[dmat->nsegments]; > > What prevents this overflowing the kernel stack? > > That does seem dubious. x86 stores the array in the tag instead. I have an untested patch to change bus-dma on arm and mips to allocate a dynamic S/G list in each DMA tag on first use instead of using on-stack allocation (which I think is rather bogus). Can folks review and test this patch please? Thanks. http://www.FreeBSD.org/~jhb/patches/arm_mips_dynamic_dma_segs.patch -- John Baldwin From owner-freebsd-arm@FreeBSD.ORG Mon Aug 6 19:42:06 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EDC9D106564A; Mon, 6 Aug 2012 19:42:05 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (cl-414.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:19d::2]) by mx1.freebsd.org (Postfix) with ESMTP id 904708FC08; Mon, 6 Aug 2012 19:42:05 +0000 (UTC) Received: from orion.swifttest.com (unknown [74.3.97.61]) by mx0.deglitch.com (Postfix) with ESMTPA id 644DA8FC36; Mon, 6 Aug 2012 23:42:04 +0400 (MSK) Received: from orion.swifttest.com (localhost [127.0.0.1]) by orion.swifttest.com (Postfix) with SMTP id DFD235C3C; Mon, 6 Aug 2012 12:41:50 -0700 (PDT) Date: Mon, 6 Aug 2012 12:41:50 -0700 From: Stanislav Sedov To: John Baldwin Message-Id: <20120806124150.52fb0be17155cac723866d63@FreeBSD.org> In-Reply-To: <201208061026.06328.jhb@freebsd.org> References: <20120703111753.GB72292@server.rulingia.com> <20120708110516.GA38312@server.rulingia.com> <201207120826.05577.jhb@freebsd.org> <201208061026.06328.jhb@freebsd.org> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, Peter Jeremy , mips@freebsd.org Subject: Re: On-stack allocation of DMA S/G lists X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 19:42:06 -0000 On Mon, 6 Aug 2012 10:26:06 -0400 John Baldwin mentioned: > On Thursday, July 12, 2012 8:26:05 am John Baldwin wrote: > > On Sunday, July 08, 2012 7:05:16 am Peter Jeremy wrote: > > > BTW(2): Whilst studying busdma_machdep.c for arm and mips, I've > > > noticed they appear to potentially allocate substantial kernel stack > > > under some conditions as several bus_dma(9) functions include: > > > bus_dma_segment_t dm_segments[dmat->nsegments]; > > > What prevents this overflowing the kernel stack? > > > > That does seem dubious. x86 stores the array in the tag instead. > > I have an untested patch to change bus-dma on arm and mips to allocate a > dynamic S/G list in each DMA tag on first use instead of using on-stack > allocation (which I think is rather bogus). Can folks review and test this > patch please? Thanks. > > http://www.FreeBSD.org/~jhb/patches/arm_mips_dynamic_dma_segs.patch > Seems to work fine for me on ARM. I had to initialize mflags to 0 in one place to get it compiling though. -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From owner-freebsd-arm@FreeBSD.ORG Mon Aug 6 20:13:27 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC1091065670; Mon, 6 Aug 2012 20:13:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C187B8FC16; Mon, 6 Aug 2012 20:13:26 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0B081B96C; Mon, 6 Aug 2012 16:13:26 -0400 (EDT) From: John Baldwin To: Stanislav Sedov Date: Mon, 6 Aug 2012 15:53:40 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <20120703111753.GB72292@server.rulingia.com> <201208061026.06328.jhb@freebsd.org> <20120806124150.52fb0be17155cac723866d63@FreeBSD.org> In-Reply-To: <20120806124150.52fb0be17155cac723866d63@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208061553.40588.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 06 Aug 2012 16:13:26 -0400 (EDT) Cc: arm@freebsd.org, Peter Jeremy , mips@freebsd.org Subject: Re: On-stack allocation of DMA S/G lists X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 20:13:27 -0000 On Monday, August 06, 2012 3:41:50 pm Stanislav Sedov wrote: > On Mon, 6 Aug 2012 10:26:06 -0400 > John Baldwin mentioned: > > > On Thursday, July 12, 2012 8:26:05 am John Baldwin wrote: > > > On Sunday, July 08, 2012 7:05:16 am Peter Jeremy wrote: > > > > BTW(2): Whilst studying busdma_machdep.c for arm and mips, I've > > > > noticed they appear to potentially allocate substantial kernel stack > > > > under some conditions as several bus_dma(9) functions include: > > > > bus_dma_segment_t dm_segments[dmat->nsegments]; > > > > What prevents this overflowing the kernel stack? > > > > > > That does seem dubious. x86 stores the array in the tag instead. > > > > I have an untested patch to change bus-dma on arm and mips to allocate a > > dynamic S/G list in each DMA tag on first use instead of using on-stack > > allocation (which I think is rather bogus). Can folks review and test this > > patch please? Thanks. > > > > http://www.FreeBSD.org/~jhb/patches/arm_mips_dynamic_dma_segs.patch > > > > Seems to work fine for me on ARM. > I had to initialize mflags to 0 in one place to get it compiling though. Ah, yes. That's why x86 did that. :) I've updated it to fix that, thanks for testing! -- John Baldwin From owner-freebsd-arm@FreeBSD.ORG Tue Aug 7 16:09:53 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0B94106566C for ; Tue, 7 Aug 2012 16:09:53 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 908378FC14 for ; Tue, 7 Aug 2012 16:09:52 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta03.emeryville.ca.mail.comcast.net with comcast id jo651j0031GXsucA3s9mZ4; Tue, 07 Aug 2012 16:09:46 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta07.emeryville.ca.mail.comcast.net with comcast id js9l1j00J4NgCEG8Us9ldh; Tue, 07 Aug 2012 16:09:46 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q77G9hdj008330; Tue, 7 Aug 2012 10:09:43 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: John Baldwin In-Reply-To: <201208061026.06328.jhb@freebsd.org> References: <20120703111753.GB72292@server.rulingia.com> <20120708110516.GA38312@server.rulingia.com> <201207120826.05577.jhb@freebsd.org> <201208061026.06328.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Tue, 07 Aug 2012 10:09:42 -0600 Message-ID: <1344355782.1128.186.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, mips@freebsd.org, Peter Jeremy Subject: Re: On-stack allocation of DMA S/G lists X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 16:09:53 -0000 On Mon, 2012-08-06 at 10:26 -0400, John Baldwin wrote: > On Thursday, July 12, 2012 8:26:05 am John Baldwin wrote: > > On Sunday, July 08, 2012 7:05:16 am Peter Jeremy wrote: > > > BTW(2): Whilst studying busdma_machdep.c for arm and mips, I've > > > noticed they appear to potentially allocate substantial kernel stack > > > under some conditions as several bus_dma(9) functions include: > > > bus_dma_segment_t dm_segments[dmat->nsegments]; > > > What prevents this overflowing the kernel stack? > > > > That does seem dubious. x86 stores the array in the tag instead. > > I have an untested patch to change bus-dma on arm and mips to allocate a > dynamic S/G list in each DMA tag on first use instead of using on-stack > allocation (which I think is rather bogus). Can folks review and test this > patch please? Thanks. > > http://www.FreeBSD.org/~jhb/patches/arm_mips_dynamic_dma_segs.patch > I'm worried about changing a per-mapping-call resource to a per-dma-tag resource here. What prevents the situation where you have two bus_dmamap_load() calls in progress at the same time using different buffers but the same tag? I can't find anything in the docs that indicates you have to provide external locking of the tag for map load/unload calls, or that even implies the tag can be modified by a mapping operation. The lockfunc stuff related to creating the tag is documented as being used only during a deferred callback. The existing code seems to go out of its way to avoid modifying the tag during a mapping operation. For example, it decides at tag creation time whether any bounce pages might ever be needed for the tag, and if so it pre-sets a bounce zone in the tag, then at mapping time the bounce zone is protected with its own lock when it gets modified. To me this feels like a way to specifically avoid the need to lock or modify the tag during a mapping operation. Assuming that all of the foregoing is moot for some reason I've overlooked, then on a purely implementation level, could all the duplicated code to allocate the array when necessary be moved into bus_dmamap_load_buffer(), triggered by a NULL 'segs' pointer? And just for the record, looking at the problem from an even more distant vantage... is there really a problem with stack-allocating the segments? On a 64-bit arch the struct is like 16 bytes. Typical usage is to allocate a tag allowing 1 or just a few segments. Is anyone really going to create a tag specifying hundreds of segments that would overflow the stack? If they try, wouldn't failing the tag create be good enough? -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Aug 7 18:09:41 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6713E1065670; Tue, 7 Aug 2012 18:09:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3A2318FC14; Tue, 7 Aug 2012 18:09:41 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 908D6B91C; Tue, 7 Aug 2012 14:09:40 -0400 (EDT) From: John Baldwin To: Ian Lepore Date: Tue, 7 Aug 2012 14:06:44 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <20120703111753.GB72292@server.rulingia.com> <201208061026.06328.jhb@freebsd.org> <1344355782.1128.186.camel@revolution.hippie.lan> In-Reply-To: <1344355782.1128.186.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208071406.45172.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 07 Aug 2012 14:09:40 -0400 (EDT) Cc: arm@freebsd.org, mips@freebsd.org, Peter Jeremy Subject: Re: On-stack allocation of DMA S/G lists X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 18:09:41 -0000 On Tuesday, August 07, 2012 12:09:42 pm Ian Lepore wrote: > On Mon, 2012-08-06 at 10:26 -0400, John Baldwin wrote: > > On Thursday, July 12, 2012 8:26:05 am John Baldwin wrote: > > > On Sunday, July 08, 2012 7:05:16 am Peter Jeremy wrote: > > > > BTW(2): Whilst studying busdma_machdep.c for arm and mips, I've > > > > noticed they appear to potentially allocate substantial kernel stack > > > > under some conditions as several bus_dma(9) functions include: > > > > bus_dma_segment_t dm_segments[dmat->nsegments]; > > > > What prevents this overflowing the kernel stack? > > > > > > That does seem dubious. x86 stores the array in the tag instead. > > > > I have an untested patch to change bus-dma on arm and mips to allocate a > > dynamic S/G list in each DMA tag on first use instead of using on-stack > > allocation (which I think is rather bogus). Can folks review and test this > > patch please? Thanks. > > > > http://www.FreeBSD.org/~jhb/patches/arm_mips_dynamic_dma_segs.patch > > > > I'm worried about changing a per-mapping-call resource to a per-dma-tag > resource here. What prevents the situation where you have two > bus_dmamap_load() calls in progress at the same time using different > buffers but the same tag? > > I can't find anything in the docs that indicates you have to provide > external locking of the tag for map load/unload calls, or that even > implies the tag can be modified by a mapping operation. The lockfunc > stuff related to creating the tag is documented as being used only > during a deferred callback. Actually, I do think it is implicit that you won't do concurrent loads on a DMA tag, though that may not be obvious. Keep in mind that this is what x86's bus_dma has always done. For storage drivers you certainly can't do this or risk completeing I/O requests out-of-order which can break an upper-layer assumption in a filesystem. Note that all other platforms do this as well, only arm and mips allocate on the stack. > The existing code seems to go out of its way to avoid modifying the tag > during a mapping operation. For example, it decides at tag creation > time whether any bounce pages might ever be needed for the tag, and if > so it pre-sets a bounce zone in the tag, then at mapping time the bounce > zone is protected with its own lock when it gets modified. To me this > feels like a way to specifically avoid the need to lock or modify the > tag during a mapping operation. > > Assuming that all of the foregoing is moot for some reason I've > overlooked, then on a purely implementation level, could all the > duplicated code to allocate the array when necessary be moved into > bus_dmamap_load_buffer(), triggered by a NULL 'segs' pointer? Nope, bus_dmamap_load() doesn't know which of M_NOWAIT / M_WAITOK is appropriate to use. > And just for the record, looking at the problem from an even more > distant vantage... is there really a problem with stack-allocating the > segments? On a 64-bit arch the struct is like 16 bytes. Typical usage > is to allocate a tag allowing 1 or just a few segments. Is anyone > really going to create a tag specifying hundreds of segments that would > overflow the stack? If they try, wouldn't failing the tag create be > good enough? I/O devices can allocate tags with several S/G elements. An mfi(4) tag on i386 would use a 256 byte segments array (512 on amd64). That's not entirely trivial. It would be worse if you couldn't depend on dmat->nsegments and had to always allocate the full size. Presumably though we require C99 at that point (and it requires that?). -- John Baldwin From owner-freebsd-arm@FreeBSD.ORG Tue Aug 7 21:25:57 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B44D1065670; Tue, 7 Aug 2012 21:25:57 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 743168FC14; Tue, 7 Aug 2012 21:25:55 +0000 (UTC) Received: from server.rulingia.com (c220-239-247-45.belrs5.nsw.optusnet.com.au [220.239.247.45]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q77LPndk049001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Aug 2012 07:25:50 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q77LPcTE011034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Aug 2012 07:25:38 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q77LPbJp011033; Wed, 8 Aug 2012 07:25:37 +1000 (EST) (envelope-from peter) Date: Wed, 8 Aug 2012 07:25:37 +1000 From: Peter Jeremy To: Ian Lepore Message-ID: <20120807212537.GB10572@server.rulingia.com> References: <20120703111753.GB72292@server.rulingia.com> <20120708110516.GA38312@server.rulingia.com> <201207120826.05577.jhb@freebsd.org> <201208061026.06328.jhb@freebsd.org> <1344355782.1128.186.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/NkBOFFp2J2Af1nK" Content-Disposition: inline In-Reply-To: <1344355782.1128.186.camel@revolution.hippie.lan> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arm@freebsd.org, mips@freebsd.org Subject: Re: On-stack allocation of DMA S/G lists X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 21:25:57 -0000 --/NkBOFFp2J2Af1nK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Aug-07 10:09:42 -0600, Ian Lepore w= rote: >And just for the record, looking at the problem from an even more >distant vantage... is there really a problem with stack-allocating the >segments? On a 64-bit arch the struct is like 16 bytes. Typical usage >is to allocate a tag allowing 1 or just a few segments. Is anyone >really going to create a tag specifying hundreds of segments that would >overflow the stack? The example that led me to study the code was drm(4). Video cards typically require fairly large allocations (32MB in my case) but don't require the RAM to be contiguous - ie it created a tag with 8192 segments in my case. This may not be relevant to most arm or mips hosts but drm(4) is MI code that can (theoretically) be built on these architectures and is a real example where a tag can have many segments. > If they try, wouldn't failing the tag create be good enough? No. The caller specifies the hardware limits for the device. They should not need to take into account implementation details that mean the full hardware capabilities are not needed. We don't fail a tag create if it specifies that RAM above 4GB can be used when we don't have any. Why should be fail a tag create that allows the use of up to 8192 tags when we only support 1? --=20 Peter Jeremy --/NkBOFFp2J2Af1nK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlAhh9EACgkQ/opHv/APuIfXtQCgkPCHfBAMkK0mE0tBmKqiwVva qO8AnA6dmeOhECocgwzP3A21OG/gEI/i =OnWm -----END PGP SIGNATURE----- --/NkBOFFp2J2Af1nK-- From owner-freebsd-arm@FreeBSD.ORG Tue Aug 7 21:45:08 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6673106564A for ; Tue, 7 Aug 2012 21:45:08 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id 848558FC0C for ; Tue, 7 Aug 2012 21:45:03 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta10.emeryville.ca.mail.comcast.net with comcast id jxE81j0011eYJf8AAxkxbY; Tue, 07 Aug 2012 21:44:57 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta19.emeryville.ca.mail.comcast.net with comcast id jxkv1j00F4NgCEG01xkwPi; Tue, 07 Aug 2012 21:44:56 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q77LirUP008514; Tue, 7 Aug 2012 15:44:53 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Peter Jeremy In-Reply-To: <20120807212537.GB10572@server.rulingia.com> References: <20120703111753.GB72292@server.rulingia.com> <20120708110516.GA38312@server.rulingia.com> <201207120826.05577.jhb@freebsd.org> <201208061026.06328.jhb@freebsd.org> <1344355782.1128.186.camel@revolution.hippie.lan> <20120807212537.GB10572@server.rulingia.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 07 Aug 2012 15:44:53 -0600 Message-ID: <1344375893.1128.230.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, mips@freebsd.org Subject: Re: On-stack allocation of DMA S/G lists X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 21:45:08 -0000 On Wed, 2012-08-08 at 07:25 +1000, Peter Jeremy wrote: > On 2012-Aug-07 10:09:42 -0600, Ian Lepore wrote: > >And just for the record, looking at the problem from an even more > >distant vantage... is there really a problem with stack-allocating the > >segments? On a 64-bit arch the struct is like 16 bytes. Typical usage > >is to allocate a tag allowing 1 or just a few segments. Is anyone > >really going to create a tag specifying hundreds of segments that would > >overflow the stack? > > The example that led me to study the code was drm(4). Video cards > typically require fairly large allocations (32MB in my case) but don't > require the RAM to be contiguous - ie it created a tag with 8192 > segments in my case. This may not be relevant to most arm or mips > hosts but drm(4) is MI code that can (theoretically) be built on these > architectures and is a real example where a tag can have many > segments. > > > If they try, wouldn't failing the tag create be good enough? > > No. The caller specifies the hardware limits for the device. They > should not need to take into account implementation details that > mean the full hardware capabilities are not needed. We don't fail > a tag create if it specifies that RAM above 4GB can be used when > we don't have any. Why should be fail a tag create that allows the > use of up to 8192 tags when we only support 1? > Oh, good example. I was wondering if there was any realistic need for lots of segments, and a big video buffer is exactly that. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 9 02:06:51 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 46276106566B for ; Thu, 9 Aug 2012 02:06:51 +0000 (UTC) (envelope-from info@minesold.com.au) Received: from node-sl1915.smtp.com (node-sl1915.smtp.com [50.23.172.155]) by mx1.freebsd.org (Postfix) with ESMTP id 1ECAD8FC12 for ; Thu, 9 Aug 2012 02:06:51 +0000 (UTC) Received: from UserHPBelkin (CPE-121-222-183-32.lnse1.woo.bigpond.net.au [121.222.183.32]) by node-sl1915.smtp.com (Postfix) with ESMTPA id DAB813828875 for ; Wed, 8 Aug 2012 22:06:48 -0400 (EDT) X-SMTPCOM-Spam-Policy: SendBlaster SMTP is a paid relay service. We do not tolerate UCE of any kind. Please report it ASAP to abuse@smtp.com X-SMTPCOM-Sender-ID: 444448 X-SMTPCOM-Tracking-Number: 495556075 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smtp.com; s=smtpcomcustomers; t=1344478011; bh=FlI5E/3fH9wPHc96agaTqPAhhXSe7DhRD+MawUUarDg=; h=MIME-Version:From:Reply-To:To:Subject:Content-Type:X-Mailer:Date: Message-ID; b=uPnu+v8lWyJqc7WmmcdZVnOuc+8E6x2sygY2bB15B/9FuZi1X8VtxMp/udxzTRLQJ L5I1h0wNG8pDNH5KykjJnopscbuqPnaYX6UktV4Qp9TfDK/gkf866zH5YfI7O9hk/R pAHgee4z+63ZzEE0Q0t2uWbCGCLACvPennLWKfcY= MIME-Version: 1.0 From: "Mine Sold" To: freebsd-arm@freebsd.org Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_001_4F40_04681483.1AEC5336" X-Mailer: SmartSend.2.0.127 Date: Thu, 9 Aug 2012 12:06:46 +1000 Message-ID: <56963866837681451419041@User-HP> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Showcase Your Business to the Mining Industry X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: info@minesold.com.au List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 02:06:51 -0000 ------=_NextPart_001_4F40_04681483.1AEC5336 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U0hPV0NBU0UgWU9VUiBCVVNJTkVTUyBTRVJWSUNFUyAmIFBST0RVQ1RTIFRPIFRIT1VTQU5EUyAN Cg0KIA0KDQpJZiB5b3UgYXJlIGxvb2tpbmcgdG8gaW5jcmVhc2UgeW91ciBjdXN0b21lciBiYXNl LCB0aGluayCTb3V0c2lkZSB0aGUgc3F1YXJllC4NCg0KIA0KDQpIYXZlIHlvdXIgYnVzaW5lc3Mg U0hPV0NBU0VEIG9uIEVWRVJZIEFJUkxJTkUgU0VBVCwgRVZFUlkgRkxJR0hULCBFVkVSWSBEQVks IEZvciAzMCBEYXlzIG9yIDYwIERheXMuIGluIGZyb250IG9mIGhpZ2ggaW5jb21lIGVhcm5lcnMs IHdpdGggYSBoaWdoIHBlcmNlbnRhZ2UgaW4gdGhlIE1pbmluZyBJbmR1c3RyeS4NCg0KDQpPdXIg SW5mbGlnaHQgbWFnYXppbmVzIGFyZSB0aGUgb25seSBpbmZsaWdodCBlbnRlcnRhaW5tZW50IGFu ZCBhcmUgcmVhZCBhbmQgcmUtcmVhZC4NCg0KSWYgeW91IG5lZWQgdG8gYWR2ZXJ0aXNlIHRvIHBv dGVudGlhbCBjdXN0b21lcnMgd2hvIGhhdmUgdGhlIGRpc3Bvc2FibGUgaW5jb21lLCBkb24ndCBs ZXQgdGhpcyBvcHBvcnR1bml0eSBwYXNzIHlvdSBieS4NCg0KRE9OklQgTUlTUyBZT1VSIEZMSUdI VC4gDQoNCldlIGFyZSBUYWtpbmcgQm9va2luZ3Mgbm93IGZvciB0aGlzIE5leHQgSXNzdWUNCg0K Q2FsbCBub3cgdG8gUmVzZXJ2ZSBZb3VyIFNwb3QuDQoNCkNhbGwgU3R1YXJ0IExvdmVsbCBOT1cg MDQwNyA3MjAgOTMwDQoNCnZpc2l0IG91ciB3ZWJzaXRlIGF0IHd3dy5taW5lc29sZC5jb20uYXUN Cg0KRW1haWwgYSByZXF1ZXN0IGZvciBtb3JlIGluZm9ybWF0aW9uIGluZm9AbWluZXNvbGQuY29t LmF1DQoNCk1pbmVzIFNvbGQuLi4uLi4gSGFzIFlvdXJzID8NCg0KDQpVbnN1YnNjcmliZSBmcm9t IHRoaXMgbWFpbGluZyBsaXN0DQoNCg0KIA0KDQo= ------=_NextPart_001_4F40_04681483.1AEC5336-- From owner-freebsd-arm@FreeBSD.ORG Fri Aug 10 20:01:59 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93E691065672 for ; Fri, 10 Aug 2012 20:01:59 +0000 (UTC) (envelope-from gonzo@hq.bluezbox.com) Received: from hq.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id 5CB458FC0C for ; Fri, 10 Aug 2012 20:01:59 +0000 (UTC) Received: from [127.0.0.1] (helo=[IPv6:::1]) by hq.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Szuy5-0000n3-Ox for freebsd-arm@freebsd.org; Fri, 10 Aug 2012 12:33:59 -0700 Message-ID: <50256231.3030008@bluezbox.com> Date: Fri, 10 Aug 2012 12:34:09 -0700 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@hq.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Any objections to merging projects/armv6 back to HEAD? There is one cache issue I'm aware of that still has to be fixed, but it doesn't affect arm architectures earlier than armv6. And we can work on it in trunk. [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Subject: projects/armv6 merge X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 20:01:59 -0000 Any objections to merging projects/armv6 back to HEAD? There is one cache issue I'm aware of that still has to be fixed, but it doesn't affect arm architectures earlier than armv6. And we can work on it in trunk. If there are no objections - the plan is to split code drop into several patches and perform merge over weekend. -- gonzo From owner-freebsd-arm@FreeBSD.ORG Fri Aug 10 21:04:29 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B963106564A for ; Fri, 10 Aug 2012 21:04:29 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E049B8FC0A for ; Fri, 10 Aug 2012 21:04:28 +0000 (UTC) Received: by obbun3 with SMTP id un3so3677233obb.13 for ; Fri, 10 Aug 2012 14:04:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=XHVKw0WaYHt8OS3SEPeXxb1y1eBKETzPEZCqAgEcFog=; b=ac7JP1AyGSUiLKjfHVBeymFiSEr/QnXvOT91i0+ZL1EvrmWNQvMb26Jo85clTdBB7w h2tEqFdmDchhSgx2eU7Z19/UF4yt6wvdcU1hH1BLn0n5ezVIigE+CqQQkQ+aZc3meMxH +34kpGN8QjmLFgeoka5DdjhUkavWKWFZZlmOF3Hgy9r6SXcrP3cBZoSI28jR93oM+1Jl fXlJScnBod2jgAAxc2Df5z1EAux/pzxQqoXmKn+dLVAKkfutIAGoP2AhjAQLgibiAiXb fVD7/6+ofwC7ahGqB5RxXVYMNH2o530vEbytQ6pRzKqGtgLJeDy3127Y4pAJYAV7pRcn a75Q== Received: by 10.60.12.234 with SMTP id b10mr5865145oec.72.1344632667815; Fri, 10 Aug 2012 14:04:27 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id u5sm4281282obk.2.2012.08.10.14.04.26 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Aug 2012 14:04:26 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <50256231.3030008@bluezbox.com> Date: Fri, 10 Aug 2012 15:04:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50256231.3030008@bluezbox.com> To: Oleksandr Tymoshenko X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkMtOCDkhAXcFSmfinqj9er+4CP7oVhV9MGRtyOzUekIgYxSzCJMBGmZr0zavug14AC7w2t Cc: freebsd-arm@freebsd.org Subject: Re: projects/armv6 merge X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 21:04:29 -0000 Please do. Ideally you'd post patches, but that's a big pita... Warner On Aug 10, 2012, at 1:34 PM, Oleksandr Tymoshenko wrote: > Any objections to merging projects/armv6 back to HEAD? >=20 > There is one cache issue I'm aware of that still has to be fixed, but = it doesn't affect arm architectures earlier than armv6. And we can work = on it in trunk. >=20 > If there are no objections - the plan is to split code drop into = several patches and perform merge over weekend. >=20 > --=20 > gonzo > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sat Aug 11 06:44:35 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1EBB1065673 for ; Sat, 11 Aug 2012 06:44:35 +0000 (UTC) (envelope-from gonzo@hq.bluezbox.com) Received: from hq.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id 61B398FC12 for ; Sat, 11 Aug 2012 06:44:35 +0000 (UTC) Received: from [207.6.240.242] (helo=[192.168.1.64]) by hq.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1T05Qg-0006E6-Rt for freebsd-arm@FreeBSD.org; Fri, 10 Aug 2012 23:44:12 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1463\)) From: Oleksandr Tymoshenko In-Reply-To: Date: Fri, 10 Aug 2012 23:44:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50256231.3030008@bluezbox.com> To: "freebsd-arm@FreeBSD.org" X-Mailer: Apple Mail (2.1463) Sender: gonzo@hq.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2012-08-10, at 2:04 PM, Warner Losh wrote: > Please do. Ideally you'd post patches, but that's a big pita... > Total patch is huge, so although it's PITA indeed here is initial batch of patches. I split diff into several patches. Some of them have known problems but I guess it's enough to get ball rolling: [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Cc: Subject: Re: projects/armv6 merge X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 06:44:35 -0000 On 2012-08-10, at 2:04 PM, Warner Losh wrote: > Please do. Ideally you'd post patches, but that's a big pita... >=20 Total patch is huge, so although it's PITA indeed here is=20 initial batch of patches. I split diff into several patches.=20 Some of them have known problems but I guess it's enough to get ball rolling: http://people.freebsd.org/~gonzo/armv6/clocksource.diff Do not check next scheduled event on APs until smp is started. http://people.freebsd.org/~gonzo/armv6/fdt.diff Bunch of FDT fixes http://people.freebsd.org/~gonzo/armv6/lpc.diff LPC32x0 support http://people.freebsd.org/~gonzo/armv6/mge.diff mge network interface fixes (Marvell-related) http://people.freebsd.org/~gonzo/armv6/mv.diff Marvel support and Armada XP kernel config This one was messed up during the merge. HEAD version and projects/armv6 version contains some conflicting definitions in mvwin.h. I'd prefer if someone who's more comfortable with this device family fixed it but if not - I'll try to do it myself. http://people.freebsd.org/~gonzo/armv6/smsc.diff http://people.freebsd.org/~gonzo/armv6/sys-v6.diff kernel part of ARMv6 port http://people.freebsd.org/~gonzo/armv6/target.diff Support for TARGET_ARCH=3Darmv6 http://people.freebsd.org/~gonzo/armv6/tegra.diff Very early stage Nvidia Tegra2 support http://people.freebsd.org/~gonzo/armv6/ti.diff TI devices support: OMAP3, OMAP4, AM335X Kernel configs for Pandaboard and Beaglebone http://people.freebsd.org/~gonzo/armv6/userland-v6.diff Userland part of projects/armv6=20 > On Aug 10, 2012, at 1:34 PM, Oleksandr Tymoshenko wrote: >=20 >> Any objections to merging projects/armv6 back to HEAD? >>=20 >> There is one cache issue I'm aware of that still has to be fixed, but = it doesn't affect arm architectures earlier than armv6. And we can work = on it in trunk. >>=20 >> If there are no objections - the plan is to split code drop into = several patches and perform merge over weekend. >>=20 >> --=20 >> gonzo >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >=20 >=20 From owner-freebsd-arm@FreeBSD.ORG Sat Aug 11 14:07:01 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42241106564A for ; Sat, 11 Aug 2012 14:07:01 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 006888FC0A for ; Sat, 11 Aug 2012 14:07:00 +0000 (UTC) Received: from pool-96-250-5-62.nycmny.fios.verizon.net ([96.250.5.62]:52024 helo=minion.home) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1T0CL7-0000M6-Pn; Sat, 11 Aug 2012 10:06:53 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: George Neville-Neil In-Reply-To: Date: Sat, 11 Aug 2012 10:06:53 -0400 Content-Transfer-Encoding: 7bit Message-Id: <9030295E-8A7A-4939-A096-DF9238771A92@neville-neil.com> References: <50256231.3030008@bluezbox.com> To: Oleksandr Tymoshenko X-Mailer: Apple Mail (2.1485) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: "freebsd-arm@FreeBSD.org" Subject: Re: projects/armv6 merge X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 14:07:01 -0000 On Aug 11, 2012, at 02:44 , Oleksandr Tymoshenko wrote: > > On 2012-08-10, at 2:04 PM, Warner Losh wrote: > >> Please do. Ideally you'd post patches, but that's a big pita... >> > > Total patch is huge, so although it's PITA indeed here is > initial batch of patches. I split diff into several patches. > Some of them have known problems but I guess it's enough to get > ball rolling: > > http://people.freebsd.org/~gonzo/armv6/clocksource.diff > Do not check next scheduled event on APs until smp is started. > > http://people.freebsd.org/~gonzo/armv6/fdt.diff > Bunch of FDT fixes > > http://people.freebsd.org/~gonzo/armv6/lpc.diff > LPC32x0 support > > http://people.freebsd.org/~gonzo/armv6/mge.diff > mge network interface fixes (Marvell-related) > > http://people.freebsd.org/~gonzo/armv6/mv.diff > Marvel support and Armada XP kernel config > > This one was messed up during the merge. HEAD version > and projects/armv6 version contains some conflicting definitions > in mvwin.h. I'd prefer if someone who's more comfortable > with this device family fixed it but if not - I'll > try to do it myself. > > http://people.freebsd.org/~gonzo/armv6/smsc.diff > > http://people.freebsd.org/~gonzo/armv6/sys-v6.diff > kernel part of ARMv6 port > > http://people.freebsd.org/~gonzo/armv6/target.diff > Support for TARGET_ARCH=armv6 > > http://people.freebsd.org/~gonzo/armv6/tegra.diff > Very early stage Nvidia Tegra2 support > > http://people.freebsd.org/~gonzo/armv6/ti.diff > TI devices support: OMAP3, OMAP4, AM335X > Kernel configs for Pandaboard and Beaglebone I did a quick scan of the stuff for Beaglebone and that looks fine to me. I'll hold off on anymore building until the merge and then retest with HEAD. Best, George From owner-freebsd-arm@FreeBSD.ORG Sat Aug 11 16:33:54 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95130106564A for ; Sat, 11 Aug 2012 16:33:54 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id 715C28FC12 for ; Sat, 11 Aug 2012 16:33:54 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta02.emeryville.ca.mail.comcast.net with comcast id lR111j0091HpZEsA2UZo2v; Sat, 11 Aug 2012 16:33:48 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta14.emeryville.ca.mail.comcast.net with comcast id lUZn1j0024NgCEG8aUZnXx; Sat, 11 Aug 2012 16:33:48 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q7BGXjHx012266; Sat, 11 Aug 2012 10:33:45 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Oleksandr Tymoshenko In-Reply-To: References: <50256231.3030008@bluezbox.com> Content-Type: multipart/mixed; boundary="=-QychZHKrRFqkDfEtxXv2" Date: Sat, 11 Aug 2012 10:33:45 -0600 Message-ID: <1344702825.1186.7.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: "freebsd-arm@FreeBSD.org" Subject: Re: projects/armv6 merge X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 16:33:54 -0000 --=-QychZHKrRFqkDfEtxXv2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, 2012-08-10 at 23:44 -0700, Oleksandr Tymoshenko wrote: > Total patch is huge, so although it's PITA indeed here is > initial batch of patches. I split diff into several patches. > Some of them have known problems but I guess it's enough to get > ball rolling: It looks like some atomic ops got dropped in the arch Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E3B51065676 for ; Sat, 11 Aug 2012 20:41:57 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id 5E6098FC19 for ; Sat, 11 Aug 2012 20:41:57 +0000 (UTC) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta13.emeryville.ca.mail.comcast.net with comcast id lRY51j0030EPchoADYhrqj; Sat, 11 Aug 2012 20:41:51 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta01.emeryville.ca.mail.comcast.net with comcast id lYhq1j0094NgCEG8MYhqj7; Sat, 11 Aug 2012 20:41:51 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q7BKfmAW012368; Sat, 11 Aug 2012 14:41:48 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Oleksandr Tymoshenko In-Reply-To: References: <50256231.3030008@bluezbox.com> Content-Type: multipart/mixed; boundary="=-f/hWeORR/e9y3n0JsxuD" Date: Sat, 11 Aug 2012 14:41:48 -0600 Message-ID: <1344717708.1186.20.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: "freebsd-arm@FreeBSD.org" Subject: Re: projects/armv6 merge X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 20:41:57 -0000 --=-f/hWeORR/e9y3n0JsxuD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, 2012-08-10 at 23:44 -0700, Oleksandr Tymoshenko wrote: > Total patch is huge, so although it's PITA indeed here is > initial batch of patches. I split diff into several patches. > Some of them have known problems but I guess it's enough to get > ball rolling: After applying all your patches to a fresh -current (r239193), I had to make the attached changes to get a DB-88F6XXX kernel to build. Once built, that kernel boots on my dreamplug to the point of loading the mge driver, then it hangs. That doesn't suprise me, that was the exact behavior of -current for me about a week ago. I have a set of local patches that add the dreamplug support, I'll be getting them integrated soon (well, after I'm done watching the baseball game) so I can get the dreamplug all the way up and running with your changes. -- Ian --=-f/hWeORR/e9y3n0JsxuD Content-Disposition: attachment; filename="changeset_11.diff" Content-Type: text/x-patch; name="changeset_11.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit files: Makefile.inc1 description: Quickly work around an installworld glitch caused by the new Heimdal/kerberos makefiles using cmp and cp to install files instead of install -C. diff -r 25742f1019fe -r b784bd72ba93 Makefile.inc1 --- a/Makefile.inc1 Sat Aug 11 10:34:22 2012 -0600 +++ b/Makefile.inc1 Sat Aug 11 13:53:31 2012 -0600 @@ -620,7 +620,7 @@ installcheck_UGID: _zoneinfo= zic tzsetup .endif -ITOOLS= [ awk cap_mkdb cat chflags chmod chown \ +ITOOLS= [ awk cap_mkdb cat chflags chmod chown cmp cp \ date echo egrep find grep ${_install-info} \ ln lockf make mkdir mtree mv pwd_mkdb rm sed sh sysctl \ test true uname wc ${_zoneinfo} --=-f/hWeORR/e9y3n0JsxuD Content-Disposition: attachment; filename="changeset_12.diff" Content-Type: text/x-patch; name="changeset_12.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit files: sys/arm/lpc/lpc_machdep.c sys/arm/mv/mv_machdep.c description: Add missing brace. Comment out definition of proc0_tf, because it's already defined in arm/machdep.c. Maybe it's the definition in arm/machdep.c that has to go, but if so then a whole lot of other _machdep.c files need to have the definition added. diff -r b784bd72ba93 -r e0ef78658faf sys/arm/lpc/lpc_machdep.c --- a/sys/arm/lpc/lpc_machdep.c Sat Aug 11 13:53:31 2012 -0600 +++ b/sys/arm/lpc/lpc_machdep.c Sat Aug 11 13:58:38 2012 -0600 @@ -148,7 +148,7 @@ struct pv_addr undstack; struct pv_addr abtstack; struct pv_addr kernelstack; -static struct trapframe proc0_tf; +//static struct trapframe proc0_tf; static struct mem_region availmem_regions[FDT_MEM_REGIONS]; static int availmem_regions_sz; diff -r b784bd72ba93 -r e0ef78658faf sys/arm/mv/mv_machdep.c --- a/sys/arm/mv/mv_machdep.c Sat Aug 11 13:53:31 2012 -0600 +++ b/sys/arm/mv/mv_machdep.c Sat Aug 11 13:58:38 2012 -0600 @@ -139,7 +139,7 @@ struct pv_addr kernelstack; void set_stackptrs(int cpu); -static struct trapframe proc0_tf; +//static struct trapframe proc0_tf; static struct mem_region availmem_regions[FDT_MEM_REGIONS]; static int availmem_regions_sz; @@ -804,7 +804,7 @@ platform_devmap_init(void) * Check space: each PCI node will consume 2 devmap * entries. */ - if (i + 1 >= FDT_DEVMAP_MAX) + if (i + 1 >= FDT_DEVMAP_MAX) { return (ENOMEM); } --=-f/hWeORR/e9y3n0JsxuD Content-Disposition: attachment; filename="changeset_13.diff" Content-Type: text/x-patch; name="changeset_13.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit files: sys/arm/arm/cpufunc.c description: Remove CPU_ID_ARM926ES, because it's not defined and I can't find the right value for it (the ARM documents website is down). I did find words saying the 926ES has no MMU, so we probably can't support it anyway. diff -r e0ef78658faf -r f1fd43249c62 sys/arm/arm/cpufunc.c --- a/sys/arm/arm/cpufunc.c Sat Aug 11 13:58:38 2012 -0600 +++ b/sys/arm/arm/cpufunc.c Sat Aug 11 14:00:29 2012 -0600 @@ -1297,7 +1297,7 @@ set_cpufuncs() get_cachetype_cp15(); pmap_pte_init_generic(); goto out; - } else if (cputype == CPU_ID_ARM926EJS || cputype == CPU_ID_ARM926ES || + } else if (cputype == CPU_ID_ARM926EJS || cputype == CPU_ID_ARM1026EJS) { cpufuncs = armv5_ec_cpufuncs; get_cachetype_cp15(); --=-f/hWeORR/e9y3n0JsxuD Content-Disposition: attachment; filename="changeset_14.diff" Content-Type: text/x-patch; name="changeset_14.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit files: sys/arm/mv/mv_pci.c description: Follow some macro changes in mvwin.h... It looks like the macros are changing to support multiple PCI devices on a SoC, but it's not clear to me how to come up with a device number from the fdt info, so just to get the code to compile in its current state, hard-code device number 0. diff -r f1fd43249c62 -r f03dd6afe884 sys/arm/mv/mv_pci.c --- a/sys/arm/mv/mv_pci.c Sat Aug 11 14:00:29 2012 -0600 +++ b/sys/arm/mv/mv_pci.c Sat Aug 11 14:02:30 2012 -0600 @@ -240,17 +240,17 @@ mv_pcib_attach(device_t self) parnode = OF_parent(node); if (fdt_is_compatible(node, "mrvl,pcie")) { sc->sc_type = MV_TYPE_PCIE; - sc->sc_mem_win_target = MV_WIN_PCIE_MEM_TARGET; - sc->sc_mem_win_attr = MV_WIN_PCIE_MEM_ATTR; - sc->sc_io_win_target = MV_WIN_PCIE_IO_TARGET; - sc->sc_io_win_attr = MV_WIN_PCIE_IO_ATTR; + sc->sc_mem_win_target = MV_WIN_PCIE_TARGET(0); + sc->sc_mem_win_attr = MV_WIN_PCIE_MEM_ATTR(0); + sc->sc_io_win_target = MV_WIN_PCIE_TARGET(0); + sc->sc_io_win_attr = MV_WIN_PCIE_IO_ATTR(0); #ifdef SOC_MV_ORION } else if (fdt_is_compatible(node, "mrvl,pci")) { sc->sc_type = MV_TYPE_PCI; - sc->sc_mem_win_target = MV_WIN_PCI_MEM_TARGET; - sc->sc_mem_win_attr = MV_WIN_PCI_MEM_ATTR; - sc->sc_io_win_target = MV_WIN_PCI_IO_TARGET; - sc->sc_io_win_attr = MV_WIN_PCI_IO_ATTR; + sc->sc_mem_win_target = MV_WIN_PCI_TARGET(0); + sc->sc_mem_win_attr = MV_WIN_PCI_MEM_ATTR(0); + sc->sc_io_win_target = MV_WIN_PCI_TARGET(0); + sc->sc_io_win_attr = MV_WIN_PCI_IO_ATTR(0); #endif } else return (ENXIO); --=-f/hWeORR/e9y3n0JsxuD Content-Disposition: attachment; filename="changeset_15.diff" Content-Type: text/x-patch; name="changeset_15.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit files: sys/arm/mv/mvwin.h description: Remove duplicate definitions. I'm pretty sure there are other problems in this file, this is just the minimum required to make things compile. diff -r f03dd6afe884 -r 4b9e39d44841 sys/arm/mv/mvwin.h --- a/sys/arm/mv/mvwin.h Sat Aug 11 14:02:30 2012 -0600 +++ b/sys/arm/mv/mvwin.h Sat Aug 11 14:06:39 2012 -0600 @@ -63,12 +63,6 @@ * External devices: 0x80000000, 1 GB (VA == PA) * Includes Device Bus, PCI and PCIE. */ -#define MV_PCIE_IO_PHYS_BASE (MV_PHYS_BASE + MV_SIZE) -#define MV_PCIE_IO_BASE MV_PCIE_IO_PHYS_BASE -#define MV_PCIE_IO_SIZE (1024 * 1024) -#define MV_PCI_IO_PHYS_BASE (MV_PCIE_IO_PHYS_BASE + MV_PCIE_IO_SIZE) -#define MV_PCI_IO_BASE MV_PCI_IO_PHYS_BASE -#define MV_PCI_IO_SIZE (1024 * 1024) #if defined(SOC_MV_ORION) #define MV_PCI_PORTS 2 /* 1x PCI + 1x PCIE */ --=-f/hWeORR/e9y3n0JsxuD Content-Disposition: attachment; filename="changeset_16.diff" Content-Type: text/x-patch; name="changeset_16.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit files: sys/arm/mv/discovery/files.db78xxx sys/arm/mv/kirkwood/files.kirkwood sys/arm/mv/orion/files.db88f5xxx sys/arm/mv/orion/files.ts7800 description: Fix kernel link glitch -- no irq support functions. It looks like the new armada support added an mpic.c file and removed ic.c from arm/mv/files.mv, so now either ic.c or mpic.c has to be in each SoC type's file list. This adds ic.c to all the older SoCs. diff -r 4b9e39d44841 -r e86ec901161b sys/arm/mv/discovery/files.db78xxx --- a/sys/arm/mv/discovery/files.db78xxx Sat Aug 11 14:06:39 2012 -0600 +++ b/sys/arm/mv/discovery/files.db78xxx Sat Aug 11 14:09:23 2012 -0600 @@ -1,3 +1,5 @@ # $FreeBSD: head/sys/arm/mv/discovery/files.db78xxx 209131 2010-06-13 13:28:53Z raj $ arm/mv/discovery/discovery.c standard +arm/mv/ic.c standard + diff -r 4b9e39d44841 -r e86ec901161b sys/arm/mv/kirkwood/files.kirkwood --- a/sys/arm/mv/kirkwood/files.kirkwood Sat Aug 11 14:06:39 2012 -0600 +++ b/sys/arm/mv/kirkwood/files.kirkwood Sat Aug 11 14:09:23 2012 -0600 @@ -1,4 +1,5 @@ # $FreeBSD: head/sys/arm/mv/kirkwood/files.kirkwood 196533 2009-08-25 09:39:11Z raj $ +arm/mv/ic.c standard arm/mv/rtc.c standard arm/mv/kirkwood/kirkwood.c standard diff -r 4b9e39d44841 -r e86ec901161b sys/arm/mv/orion/files.db88f5xxx --- a/sys/arm/mv/orion/files.db88f5xxx Sat Aug 11 14:06:39 2012 -0600 +++ b/sys/arm/mv/orion/files.db88f5xxx Sat Aug 11 14:09:23 2012 -0600 @@ -1,4 +1,5 @@ # $FreeBSD: head/sys/arm/mv/orion/files.db88f5xxx 183840 2008-10-13 20:07:13Z raj $ +arm/mv/ic.c standard arm/mv/orion/orion.c standard arm/mv/orion/db88f5xxx.c standard diff -r 4b9e39d44841 -r e86ec901161b sys/arm/mv/orion/files.ts7800 --- a/sys/arm/mv/orion/files.ts7800 Sat Aug 11 14:06:39 2012 -0600 +++ b/sys/arm/mv/orion/files.ts7800 Sat Aug 11 14:09:23 2012 -0600 @@ -1,4 +1,5 @@ # $FreeBSD: head/sys/arm/mv/orion/files.ts7800 220653 2011-04-15 13:37:43Z philip $ +arm/mv/ic.c standard arm/mv/orion/orion.c standard --=-f/hWeORR/e9y3n0JsxuD-- From owner-freebsd-arm@FreeBSD.ORG Sat Aug 11 22:59:32 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03E94106564A for ; Sat, 11 Aug 2012 22:59:32 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id D3C7E8FC08 for ; Sat, 11 Aug 2012 22:59:31 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta03.emeryville.ca.mail.comcast.net with comcast id lR8w1j0031zF43QA3azRo6; Sat, 11 Aug 2012 22:59:25 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta24.emeryville.ca.mail.comcast.net with comcast id lazQ1j00G4NgCEG8kazQTL; Sat, 11 Aug 2012 22:59:25 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q7BMxMox012430; Sat, 11 Aug 2012 16:59:22 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Oleksandr Tymoshenko In-Reply-To: References: <50256231.3030008@bluezbox.com> Content-Type: multipart/mixed; boundary="=-FCH/zvws8RoAnHH11PYz" Date: Sat, 11 Aug 2012 16:59:22 -0600 Message-ID: <1344725962.1186.26.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: "freebsd-arm@FreeBSD.org" Subject: Re: projects/armv6 merge X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 22:59:32 -0000 --=-FCH/zvws8RoAnHH11PYz Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, 2012-08-10 at 23:44 -0700, Oleksandr Tymoshenko wrote: > Total patch is huge, so although it's PITA indeed here is > initial batch of patches. I split diff into several patches. > Some of them have known problems but I guess it's enough to get > ball rolling: One last patch (attached) to fix a little glitch in mvwin.h, and now my dreamplug boots to multiuser and everything seems to be working that was working a couple days ago (sata, usb, both ethernet ports, a few basic services such as dhcp, nfs client, sshd and ntpd are working fine). -- Ian --=-FCH/zvws8RoAnHH11PYz Content-Description: Content-Disposition: inline; filename="changeset_19.diff" Content-Type: text/x-patch; name="changeset_19.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Fix the macros that access the usb mapping registers. diff -r 947e1072454d -r 5469f4bcf9b4 sys/arm/mv/mvwin.h --- a/sys/arm/mv/mvwin.h Sat Aug 11 15:44:32 2012 -0600 +++ b/sys/arm/mv/mvwin.h Sat Aug 11 16:51:37 2012 -0600 @@ -219,8 +219,8 @@ #define MV_WIN_CESA_ATTR 0 #endif -#define MV_WIN_USB_CTRL(n) (0x320 * (n) + 0x0) -#define MV_WIN_USB_BASE(n) (0x320 * (n) + 0x4) +#define MV_WIN_USB_CTRL(n) (0x10 * (n) + 0x320) +#define MV_WIN_USB_BASE(n) (0x10 * (n) + 0x324) #define MV_WIN_USB_MAX 4 #define MV_WIN_ETH_BASE(n) (0x8 * (n) + 0x200) --=-FCH/zvws8RoAnHH11PYz--