From owner-freebsd-arm@FreeBSD.ORG Sun Aug 2 18:45:08 2009 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 0B90A1065674 for ; Sun, 2 Aug 2009 18:45:08 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id BEC978FC16 for ; Sun, 2 Aug 2009 18:45:07 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id n72Ij6pt094850 for ; Sun, 2 Aug 2009 13:45:06 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1249238707; bh=Q4ITBWZIlSdfLg8g8k9/a9qWUXcW60l2uUHurQDLnDk=; h=Date:From:Message-Id:To:Subject; b=gOWVh8TZ+KRphIV7lgNRSfoYVJUQgewLDZvs96v0ESTD9lECENxocdcVX7tNIcTon 3jimZLHwrQlPjv16+2yuCYkhcJCHIITGrbMbr3sK2/DGUE0NyWQC9mVP0FouxF7W2K ZKg4g1HU5k7EWij8Oa65xSVwgLlVmnwsGl5qEeqo= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id n72Ij6Nn094849 for freebsd-arm@freebsd.org; Sun, 2 Aug 2009 13:45:06 -0500 (CDT) (envelope-from tinguely) Date: Sun, 2 Aug 2009 13:45:06 -0500 (CDT) From: Mark Tinguely Message-Id: <200908021845.n72Ij6Nn094849@casselton.net> To: freebsd-arm@freebsd.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Sun, 02 Aug 2009 13:45:07 -0500 (CDT) Subject: FYI: elf_trampoline.c rev 194609 breaks PXA gcc 4.5/binutils 2.19 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: Sun, 02 Aug 2009 18:45:08 -0000 I have a copy of the GCC 4.5 compilers (ARM/i386) and binutils 2.19 (ARM only) that have been ported to gnu/usr.bin/ (BSD makefiles). I have been using the compiler for several weeks and the binutils is realitively new. The source that I have been testing are my local mods to an old code base. Thinking it is time to move the mods to the newest kernel code, last week I tried the current head GUMSTIX kernel sources and found the compiled kernel would no longer boot under the QEMU. It took me a long time to isolate, I even build new versions of qemu, gcc 4.5, and binutiils 2.19, but I finally isolated the problem to the file sys/arm/arm/elf_trampoline.c revision 94609. I suspect, the lack MMU enable in the __start routine. This code still works with the built-in gcc 4.2.1/binutils 2.15, so this is just a FYI. --Mark Tinguely. From owner-freebsd-arm@FreeBSD.ORG Mon Aug 3 11:06:53 2009 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 55C6E106566C for ; Mon, 3 Aug 2009 11:06:53 +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 42AA48FC18 for ; Mon, 3 Aug 2009 11:06:53 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n73B6r3N088529 for ; Mon, 3 Aug 2009 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n73B6qrv088525 for freebsd-arm@FreeBSD.org; Mon, 3 Aug 2009 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Aug 2009 11:06:52 GMT Message-Id: <200908031106.n73B6qrv088525@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, 03 Aug 2009 11:06:53 -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/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Aug 3 15:21:18 2009 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 9E2BE106567B; Mon, 3 Aug 2009 15:21:18 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id EC76D8FC24; Mon, 3 Aug 2009 15:21:17 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from [10.0.0.34] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 0DFECC426C; Mon, 3 Aug 2009 16:59:09 +0200 (CEST) Message-Id: <8DC8C704-F84D-4A60-A11B-2F877EB903C9@semihalf.com> From: Rafal Jaworowski To: Hans Petter Selasky In-Reply-To: <20090724.233404.-399282844.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 3 Aug 2009 17:01:37 +0200 References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <200907232209.47729.hselasky@c2i.net> <20090724.233404.-399282844.imp@bsdimp.com> X-Mailer: Apple Mail (2.935.3) Cc: arm@freebsd.org, usb@freebsd.org Subject: Re: About the "USB Cache and busdma usage in USB" thread 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, 03 Aug 2009 15:21:29 -0000 On 2009-07-25, at 05:34, M. Warner Losh wrote: > In message: <200907232209.47729.hselasky@c2i.net> > Hans Petter Selasky writes: > : On Thursday 23 July 2009 20:53:06 Marcel Moolenaar wrote: > : > All, > : > > : > I went over the thread and this is what I have to say about it: > : > > : > Using busdma to manage/control CPU caches is wrong for the > : > following simple reason: bus_dmamap_sync() has the side-effect > : > of copying to and from the bounce buffer (if applicable). > : > > : > CPU caches should be kept coherent by using an appropriate API. > : > We already have cpu_flush_dcache(). All we have to do is add > : > cpu_inval_dcache() and let the MD code determine how best to > : > do this -- even if they decide to use busdma. > : > > : > In general: D-cache and I-cache control/handling should not be > : > hidden from MI code. It should not be treated as an artifact of > : > some platform. It should not be implemented by banking on some > : > side-effect of other function(s). We only achieve efficient > : > cache control if MI code calls appropriate APIs so that we can > : > precisely express what we need to achieve at that point. > : > > : > For example: when we write a breakpoint into the text segment > : > of some process by using ptrace(2), the ptrace(2) code must > : > call an appropriate API to make sure that the I-cache is made > : > coherent with memory. This may require a previous D-cache > : > flush! We should not kluge uiomove(9) like we did on PowerPC > : > to deal with this. Note ARM and ia64 are still broken in this > : > respect. > : > : Hi, > : > : I would be fine with a solution where cpufunctions are used > directly in USB. > : The only problem is that if bounce pages are used, which happens > in the case > : of loading kernel virtual data into DMA, then busdma sync calls > would still be > : required. > > They are needed on i386 kernels with more than 4GB of ram... Or ram > located above 4GB... Hans, So how do you want to proceed with these cache sync issues? We need to fix this before 8.0. Rafal From owner-freebsd-arm@FreeBSD.ORG Mon Aug 3 15:59:51 2009 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 02EDD106566C; Mon, 3 Aug 2009 15:59:51 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 363E28FC18; Mon, 3 Aug 2009 15:59:49 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=uXAB73GHeBQA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=k65giglMNd4q9o-90-0A:9 a=zhoo1XdpDPRzsePuYthE4ubsKKAA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 234908221; Mon, 03 Aug 2009 17:59:48 +0200 From: Hans Petter Selasky To: Rafal Jaworowski , freebsd-current@freebsd.org Date: Mon, 3 Aug 2009 17:59:43 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <20090724.233404.-399282844.imp@bsdimp.com> <8DC8C704-F84D-4A60-A11B-2F877EB903C9@semihalf.com> In-Reply-To: <8DC8C704-F84D-4A60-A11B-2F877EB903C9@semihalf.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908031759.46491.hselasky@c2i.net> Cc: arm@freebsd.org, usb@freebsd.org Subject: Re: About the "USB Cache and busdma usage in USB" thread 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, 03 Aug 2009 15:59:51 -0000 On Monday 03 August 2009 17:01:37 Rafal Jaworowski wrote: > Hans, > So how do you want to proceed with these cache sync issues? We need to > fix this before 8.0. Hi, CC'ed current: We have a case on ARM where bus_dmamap_sync() is not suffient to update the CPU cache. One reason for this is that USB needs to invalidate the same memory area multiple times. Busdma sync expects paired operation when using the PRE and POST flags, from what I understand. I do not consider this an USB issue, hence Semihalf has got the USB stack working by manually inserting CPU flush/invalidate calls into usb_pc_cpu_invalidate() and usb_pc_cpu_flush(). Their other solution however which modifies the bus_dmamap_sync() flags will break on platforms with more than 4 GByte of memory. Maybe Rafal can give a quick summar to new people at the -current list, or see previous thread on the ARM mailing list. USB needs a solution where it can call a function given a busdma mapping, preferably with an offset and length, which handles the cache sync issue and works with bounce pages on +4GB systems. --HPS From owner-freebsd-arm@FreeBSD.ORG Mon Aug 3 16:52:50 2009 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 71774106566B; Mon, 3 Aug 2009 16:52:50 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 15A0D8FC18; Mon, 3 Aug 2009 16:52:49 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from [10.0.0.34] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 886A9C426C; Mon, 3 Aug 2009 18:50:19 +0200 (CEST) Message-Id: From: Rafal Jaworowski To: Hans Petter Selasky In-Reply-To: <200908031759.46491.hselasky@c2i.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 3 Aug 2009 18:52:48 +0200 References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <20090724.233404.-399282844.imp@bsdimp.com> <8DC8C704-F84D-4A60-A11B-2F877EB903C9@semihalf.com> <200908031759.46491.hselasky@c2i.net> X-Mailer: Apple Mail (2.935.3) Cc: arm@freebsd.org, usb@freebsd.org, freebsd-current@freebsd.org Subject: Re: About the "USB Cache and busdma usage in USB" thread 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, 03 Aug 2009 16:52:51 -0000 On 2009-08-03, at 17:59, Hans Petter Selasky wrote: > On Monday 03 August 2009 17:01:37 Rafal Jaworowski wrote: >> Hans, >> So how do you want to proceed with these cache sync issues? We need >> to >> fix this before 8.0. > > Hi, > > CC'ed current: We have a case on ARM where bus_dmamap_sync() is not > suffient > to update the CPU cache. One reason for this is that USB needs to > invalidate It's not only ARM, but some MIPS and PowerPC observe this as well; actually I'd expect any system with non-coherent DMA will suffer from this with current USB stack. > the same memory area multiple times. Busdma sync expects paired > operation when > using the PRE and POST flags, from what I understand. I do not > consider this > an USB issue, hence Semihalf has got the USB stack working by manually > inserting CPU flush/invalidate calls into usb_pc_cpu_invalidate() and > usb_pc_cpu_flush(). Their other solution however which modifies the > bus_dmamap_sync() flags will break on platforms with more than 4 > GByte of > memory. > > Maybe Rafal can give a quick summar to new people at the -current > list, or see > previous thread on the ARM mailing list. This issue was discussed already: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=50307+0+archive/2009/freebsd-usb/20090628.freebsd-usb See also the beginning of this thread: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=10461+0+archive/2009/freebsd-arm/20090726.freebsd-arm Rafal From owner-freebsd-arm@FreeBSD.ORG Tue Aug 4 15:01:16 2009 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 CB730106566C; Tue, 4 Aug 2009 15:01:16 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 3AD378FC15; Tue, 4 Aug 2009 15:01:16 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from [10.0.0.75] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPA id 97A9DC426C; Tue, 4 Aug 2009 16:39:08 +0200 (CEST) Message-ID: <4A7848A0.4080905@semihalf.com> Date: Tue, 04 Aug 2009 16:41:36 +0200 From: Grzegorz Bernacki User-Agent: Thunderbird 2.0.0.16 (X11/20090618) MIME-Version: 1.0 To: Hans Petter Selasky References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <20090724.233404.-399282844.imp@bsdimp.com> <8DC8C704-F84D-4A60-A11B-2F877EB903C9@semihalf.com> <200908031759.46491.hselasky@c2i.net> In-Reply-To: <200908031759.46491.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, freebsd-current@freebsd.org, usb@freebsd.org Subject: Re: About the "USB Cache and busdma usage in USB" thread 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, 04 Aug 2009 15:01:17 -0000 Hans Petter Selasky wrote: > > CC'ed current: We have a case on ARM where bus_dmamap_sync() is not suffient > to update the CPU cache. One reason for this is that USB needs to invalidate > the same memory area multiple times. Busdma sync expects paired operation when > using the PRE and POST flags, from what I understand. I do not consider this > an USB issue, hence Semihalf has got the USB stack working by manually > inserting CPU flush/invalidate calls into usb_pc_cpu_invalidate() and > usb_pc_cpu_flush(). Their other solution however which modifies the > bus_dmamap_sync() flags will break on platforms with more than 4 GByte of > memory. > > Maybe Rafal can give a quick summar to new people at the -current list, or see > previous thread on the ARM mailing list. > > USB needs a solution where it can call a function given a busdma mapping, > preferably with an offset and length, which handles the cache sync issue and > works with bounce pages on +4GB systems. > Hi Hans, New USB stack uses busdma in a little unconventional way. As you mentioned in one of previous mails your assumptions are: XXX_PREXXX functions should be used prior to read/write device access. In other words, PRE has to be a flush operation. XXX_POSTXXX functions should be used after read/write device access. In other words, POST has to be an invalidate operation. Generally it is true, but if you look at ARM code you will find out that it is not that simple. You assumed that after bus_dmamap_sync(..,BUS_DMASYNC_POSTWRITE | BUS_DMASYNC_POSTREAD) there will be no data in cache, but it that's not true. Cache operation are performed on cache lines (32 bytes on our ARM device). Let's say you want to invalidate buffer with size 10 bytes. In this case first whole cache line is invalidated ( and now all requirements related to busdma synchronization are fulfilled, old contents of cache is gone). The second step is to restore back into cache 22 bytes of data which were not a part of buffer. After this second step data are loaded into cache line (it is because our device uses write allocate feature). So busdma on ARM "Perform any synchronization required after an update of host memory by the device", but we still end up with not invalidated flush. It is hard to fix it. We cannot just invalidate whole cache line. We cannot also use cpu_dcache_wbinv, because this function is called after buffer was used by device so we dont want to overwrite those data with old cache contents. One possible solution is to call first bus_dmamap_sync(..,BUS_DMASYNC_POSTREAD) and then bus_dmamap_sync(..,BUS_DMASYNC_PREREAD) in usb_pc_cpu_invalidate(), but this is ugly workaround which applies probably only to ARM case. The second problem is that you cannot use cpu_dcache_wb(inv) function directly because you need to handle bounce pages in USB code. I think that duplication of busdma code makes no sense. Probably it takes less work to add bus_dmamap_sync() before/after each transaction. Could you give us a quick overview of buffer handling in USB stack? I want to understand what is the relation between usb_pc_cpu_invalidate/flush() functions and reading/writing to USB device? From yours previous mail I understand that invalidate is called *before* reading and flush *before* writing. Is that true? Can we add a functions which will be called *after* reading/writing? If you have any questions regarding cache operation on ARM. please let me know, I will try to answer them. regards, Grzesiek From owner-freebsd-arm@FreeBSD.ORG Tue Aug 4 16:54:54 2009 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 72D39106564A for ; Tue, 4 Aug 2009 16:54:54 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.tele2.se [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id D1B118FC14 for ; Tue, 4 Aug 2009 16:54:53 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=uXAB73GHeBQA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=dU7kav3A9PnrunaxqCUA:9 a=nVf9qWreKgvzqu-H-KsA:7 a=gJU65N-bE7egE_QUlsV8oVjiRrwA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe14.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 549127578; Tue, 04 Aug 2009 17:54:50 +0200 From: Hans Petter Selasky To: Grzegorz Bernacki Date: Tue, 4 Aug 2009 17:54:48 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <200908031759.46491.hselasky@c2i.net> <4A7848A0.4080905@semihalf.com> In-Reply-To: <4A7848A0.4080905@semihalf.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908041754.50244.hselasky@c2i.net> Cc: arm@freebsd.org, freebsd-current@freebsd.org, usb@freebsd.org Subject: Re: About the "USB Cache and busdma usage in USB" thread 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, 04 Aug 2009 16:54:54 -0000 On Tuesday 04 August 2009 16:41:36 Grzegorz Bernacki wrote: > Hans Petter Selasky wrote: > > CC'ed current: We have a case on ARM where bus_dmamap_sync() is not > > suffient to update the CPU cache. One reason for this is that USB needs > > to invalidate the same memory area multiple times. Busdma sync expects > > paired operation when using the PRE and POST flags, from what I > > understand. I do not consider this an USB issue, hence Semihalf has got > > the USB stack working by manually inserting CPU flush/invalidate calls > > into usb_pc_cpu_invalidate() and usb_pc_cpu_flush(). Their other solution > > however which modifies the bus_dmamap_sync() flags will break on > > platforms with more than 4 GByte of memory. > > > > Maybe Rafal can give a quick summar to new people at the -current list, > > or see previous thread on the ARM mailing list. > > > > USB needs a solution where it can call a function given a busdma mapping, > > preferably with an offset and length, which handles the cache sync issue > > and works with bounce pages on +4GB systems. > > Hi Hans, > > New USB stack uses busdma in a little unconventional way. As you > mentioned in one of previous mails your assumptions are: > > XXX_PREXXX functions should be used prior to read/write device access. > In other words, PRE has to be a flush operation. > > XXX_POSTXXX functions should be used after read/write device access. > In other words, POST has to be an invalidate operation. > > Generally it is true, but if you look at ARM code you will find out that > it is not that simple. You assumed that after > bus_dmamap_sync(..,BUS_DMASYNC_POSTWRITE | BUS_DMASYNC_POSTREAD) there > will be no data in cache, but it that's not true. > > Cache operation are performed on cache lines (32 bytes on our ARM > device). Let's say you want to invalidate buffer with size 10 bytes. In > this case first whole cache line is invalidated ( and now all > requirements related to busdma synchronization are fulfilled, old > contents of cache is gone). The second step is to restore back into > cache 22 bytes of data which were not a part of buffer. After this > second step data are loaded into cache line (it is because our device > uses write allocate feature). > So busdma on ARM "Perform any synchronization required after an update > of host memory by the device", but we still end up with not invalidated > flush. > It is hard to fix it. We cannot just invalidate whole cache line. We > cannot also use cpu_dcache_wbinv, because this function is called after > buffer was used by device so we dont want to overwrite those data with > old cache contents. > > One possible solution is to call first > bus_dmamap_sync(..,BUS_DMASYNC_POSTREAD) and then > bus_dmamap_sync(..,BUS_DMASYNC_PREREAD) in usb_pc_cpu_invalidate(), but > this is ugly workaround which applies probably only to ARM case. > > The second problem is that you cannot use cpu_dcache_wb(inv) function > directly because you need to handle bounce pages in USB code. I think > that duplication of busdma code makes no sense. Probably it takes less > work to add bus_dmamap_sync() before/after each transaction. > > Could you give us a quick overview of buffer handling in USB stack? I > want to understand what is the relation between > usb_pc_cpu_invalidate/flush() functions and reading/writing to USB > device? From yours previous mail I understand that invalidate is called > *before* reading and flush *before* writing. Is that true? Can we add a > functions which will be called *after* reading/writing? Hi, There are two kinds of DMA memory in USB regard: 1) Transfer descriptors are allocated in coherent DMA memory. Operation logic: 1.a) Write to descriptor. 1.b.0) Call usb_pc_cpu_flush() to write data to RAM. 1.b.1) Write more fields to descriptor. 1.b.2) Call usb_pc_cpu_flush() to write data to RAM. 1.c) Call usb_pc_cpu_invalidate() to clear cache. 1.d) Read status field. If not complete goto 1.c) 2) Any kernel virtual memory (which might not be coherent) 2.a.0) CPU read case: 2.a.1) Before transfer start usb_pc_cpu_invalidate() is called to clear any data in cache for this buffer. 2.a.2) After transfer completion usb_pc_cpu_invalidate() is called again. 2.b.0) CPU write case: 2.b.1) Before transfer start usb_pc_cpu_flush() is called to to flush any data in cache to RAM for this buffer. 2.b.2) After transfer completion there is no cache operation. Anything unclear? --HPS > > If you have any questions regarding cache operation on ARM. please let > me know, I will try to answer them. > > regards, > Grzesiek From owner-freebsd-arm@FreeBSD.ORG Wed Aug 5 13:17:20 2009 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 BB2A1106566C; Wed, 5 Aug 2009 13:17:20 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 6559F8FC17; Wed, 5 Aug 2009 13:17:20 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from [10.0.0.75] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPA id 1A0FFC426C; Wed, 5 Aug 2009 15:14:53 +0200 (CEST) Message-ID: <4A79865E.3060206@semihalf.com> Date: Wed, 05 Aug 2009 15:17:18 +0200 From: Grzegorz Bernacki User-Agent: Thunderbird 2.0.0.16 (X11/20090618) MIME-Version: 1.0 To: Hans Petter Selasky References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <200908031759.46491.hselasky@c2i.net> <4A7848A0.4080905@semihalf.com> <200908041754.50244.hselasky@c2i.net> In-Reply-To: <200908041754.50244.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, freebsd-current@freebsd.org, usb@freebsd.org Subject: Re: About the "USB Cache and busdma usage in USB" thread 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: Wed, 05 Aug 2009 13:17:21 -0000 Hans Petter Selasky wrote: > There are two kinds of DMA memory in USB regard: > 1) Transfer descriptors are allocated in coherent DMA memory. > Operation logic: > > 1.a) Write to descriptor. > 1.b.0) Call usb_pc_cpu_flush() to write data to RAM. > 1.b.1) Write more fields to descriptor. > 1.b.2) Call usb_pc_cpu_flush() to write data to RAM. > 1.c) Call usb_pc_cpu_invalidate() to clear cache. > 1.d) Read status field. If not complete goto 1.c) > > 2) Any kernel virtual memory (which might not be coherent) > > 2.a.0) CPU read case: > 2.a.1) Before transfer start usb_pc_cpu_invalidate() is called to clear any > data in cache for this buffer. > 2.a.2) After transfer completion usb_pc_cpu_invalidate() is called again. > > 2.b.0) CPU write case: > 2.b.1) Before transfer start usb_pc_cpu_flush() is called to to flush any data > in cache to RAM for this buffer. > 2.b.2) After transfer completion there is no cache operation. > The best solution is to use bus_dmamap_sync() in in conventional way. I mean call bus_dmamap_sync(..., BUS_DMASYNC_PREREAD) in case 2.a.1 and bus_dmamap_sync(..., BUS_DMASYNC_POSTREAD) in cases 2.a.2 and 1.c. But this is quite a big change and it's risky to put in into -current now, so below is another solution which I believe is simple and safe. I understand that usb_pc_cpu_flush() is called *before* write transfer. So I think that we can just call bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE) there. usb_pc_cpu_invalidate() is called before and after each read transfer and to invalidate cache before reading status field. So I think that simplest fix is to call following sequence of functions in it: bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_POSTREAD); bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREREAD); Below is the patch with that solution. I tested it on ARM and PowerPC and it fixes the problem. Please test it on other platforms you have to see if there is no regression. diff --git a/sys/dev/usb/usb_busdma.c b/sys/dev/usb/usb_busdma.c index 82d18a1..c57f51d 100644 --- a/sys/dev/usb/usb_busdma.c +++ b/sys/dev/usb/usb_busdma.c @@ -678,8 +678,8 @@ usb_pc_cpu_invalidate(struct usb_page_cache *pc) /* nothing has been loaded into this page cache! */ return; } - bus_dmamap_sync(pc->tag, pc->map, - BUS_DMASYNC_POSTWRITE | BUS_DMASYNC_POSTREAD); + bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_POSTREAD); + bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREREAD); } /*------------------------------------------------------------------------* @@ -692,8 +692,7 @@ usb_pc_cpu_flush(struct usb_page_cache *pc) /* nothing has been loaded into this page cache! */ return; } - bus_dmamap_sync(pc->tag, pc->map, - BUS_DMASYNC_PREWRITE | BUS_DMASYNC_PREREAD); + bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); } /*------------------------------------------------------------------------* From owner-freebsd-arm@FreeBSD.ORG Wed Aug 5 13:49:47 2009 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 21A7E1065688; Wed, 5 Aug 2009 13:49:47 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 5667B8FC25; Wed, 5 Aug 2009 13:49:45 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=uXAB73GHeBQA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=MUhiJNgwuVPsYk42_IQA:9 a=sYYSPOwCoMhsDfu2O5IRAWEdHa8A:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1290310211; Wed, 05 Aug 2009 15:49:43 +0200 From: Hans Petter Selasky To: Grzegorz Bernacki Date: Wed, 5 Aug 2009 15:49:42 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <200908041754.50244.hselasky@c2i.net> <4A79865E.3060206@semihalf.com> In-Reply-To: <4A79865E.3060206@semihalf.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908051549.43890.hselasky@c2i.net> Cc: arm@freebsd.org, freebsd-current@freebsd.org, usb@freebsd.org Subject: Re: About the "USB Cache and busdma usage in USB" thread 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: Wed, 05 Aug 2009 13:49:48 -0000 On Wednesday 05 August 2009 15:17:18 Grzegorz Bernacki wrote: > Below is the patch with that solution. I tested it on ARM and PowerPC > and it fixes the problem. Please test it on other platforms you have to > see if there is no regression. Hi, Your patch look Ok. I will do some more testing and then commit it to USB P4. Thank you! --HPS From owner-freebsd-arm@FreeBSD.ORG Fri Aug 7 11:15:24 2009 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 A2BBA106564A; Fri, 7 Aug 2009 11:15:24 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 583138FC16; Fri, 7 Aug 2009 11:15:24 +0000 (UTC) Received: from [192.168.1.13] (aekg190.neoplus.adsl.tpnet.pl [79.191.6.190]) by smtp.semihalf.com (Postfix) with ESMTPA id E0027C4275; Fri, 7 Aug 2009 13:12:59 +0200 (CEST) Message-ID: <4A7C0CC9.3080701@semihalf.com> Date: Fri, 07 Aug 2009 13:15:21 +0200 From: Grzegorz Bernacki User-Agent: Thunderbird 2.0.0.16 (X11/20090618) MIME-Version: 1.0 To: Hans Petter Selasky References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <200908041754.50244.hselasky@c2i.net> <4A79865E.3060206@semihalf.com> <200908051549.43890.hselasky@c2i.net> In-Reply-To: <200908051549.43890.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, freebsd-current@freebsd.org, usb@freebsd.org Subject: Re: About the "USB Cache and busdma usage in USB" thread 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, 07 Aug 2009 11:15:25 -0000 Hans Petter Selasky wrote: > On Wednesday 05 August 2009 15:17:18 Grzegorz Bernacki wrote: > > I will do some more testing and then commit it to USB P4. > Hi Hans, Have you had a chance to perform your tests? Do you see any problems on your machine after applying the patch? regards, Grzesiek From owner-freebsd-arm@FreeBSD.ORG Fri Aug 7 12:33:16 2009 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 E42FE1065673; Fri, 7 Aug 2009 12:33:16 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe13.swip.net [212.247.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id 20D268FC16; Fri, 7 Aug 2009 12:33:15 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=Qa35spukGxu/rmuNTmr4yg==:17 a=6I5d2MoRAAAA:8 a=1XwNwSwitz25EByeM9YA:9 a=gTk_gjysuApDULSJLYqHuN2tkx8A:4 Received: from [85.19.72.137] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe13.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 903192453; Fri, 07 Aug 2009 14:33:14 +0200 From: Hans Petter Selasky To: Grzegorz Bernacki , freebsd-current@freebsd.org, freebsd-usb@freebsd.org, arm@freebsd.org Date: Fri, 7 Aug 2009 14:33:15 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908071433.16484.hselasky@c2i.net> Cc: Subject: USB busdma sync flag fix 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, 07 Aug 2009 12:33:17 -0000 Hi, Can people with AMD64 + USB and more than 4GBytes of RAM give the following patch a shot? http://perforce.freebsd.org/chv.cgi?CH=167088 Thanks to "Grzegorz Bernacki" and his friends at Semihalf for fixing USB on ARM and PowerPC ++ --HPS From owner-freebsd-arm@FreeBSD.ORG Fri Aug 7 13:09:31 2009 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 05523106566C for ; Fri, 7 Aug 2009 13:09:31 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id AC6868FC21 for ; Fri, 7 Aug 2009 13:09:30 +0000 (UTC) Received: from [10.0.0.34] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id E86E5C4275; Fri, 7 Aug 2009 15:07:06 +0200 (CEST) Message-Id: <1F9EB6AF-F5E0-4DA4-A227-8313C1205C46@semihalf.com> From: Rafal Jaworowski To: Donald T Hayford In-Reply-To: <4A7C1937.3060000@donhayford.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 7 Aug 2009 15:09:28 +0200 References: <49FA5B75.9090008@donhayford.com> <49FADE9B.1080806@donhayford.com> <494D378B-B243-4D97-8554-AC3E74A30B8C@semihalf.com> <49FB8696.8020907@donhayford.com> <72D23F68-EE62-4297-88F4-6CA0132F0293@semihalf.com> <49FF8461.6020406@donhayford.com> <4A7B826B.4040604@donhayford.com> <8DCDD569-1672-4EC9-9E3C-EB08E039EEA6@semihalf.com> <4A7C1937.3060000@donhayford.com> X-Mailer: Apple Mail (2.935.3) Cc: arm@FreeBSD.org Subject: Re: Help with Marvel kernel for 88F6281 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, 07 Aug 2009 13:09:31 -0000 Don, Support for SheevaPlug as a diff against recent HEAD is here http://people.freebsd.org/~raj/patches/arm/sheevaplug.diff Note there's a separate kernel config named SHEEVAPLUG, so use this for building your kernel. Let me know if this worked for you. Rafal From owner-freebsd-arm@FreeBSD.ORG Fri Aug 7 13:19:28 2009 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 AEAA31065672 for ; Fri, 7 Aug 2009 13:19:28 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 5F2D88FC23 for ; Fri, 7 Aug 2009 13:19:28 +0000 (UTC) Received: from [10.0.0.34] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 7478CC426C; Fri, 7 Aug 2009 15:17:04 +0200 (CEST) Message-Id: <88FC923E-4DFE-4F11-9596-DAE543816AB9@semihalf.com> From: Rafal Jaworowski To: Donald T Hayford In-Reply-To: <1F9EB6AF-F5E0-4DA4-A227-8313C1205C46@semihalf.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 7 Aug 2009 15:19:26 +0200 References: <49FA5B75.9090008@donhayford.com> <49FADE9B.1080806@donhayford.com> <494D378B-B243-4D97-8554-AC3E74A30B8C@semihalf.com> <49FB8696.8020907@donhayford.com> <72D23F68-EE62-4297-88F4-6CA0132F0293@semihalf.com> <49FF8461.6020406@donhayford.com> <4A7B826B.4040604@donhayford.com> <8DCDD569-1672-4EC9-9E3C-EB08E039EEA6@semihalf.com> <4A7C1937.3060000@donhayford.com> <1F9EB6AF-F5E0-4DA4-A227-8313C1205C46@semihalf.com> X-Mailer: Apple Mail (2.935.3) Cc: arm@FreeBSD.org Subject: Re: Help with Marvel kernel for 88F6281 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, 07 Aug 2009 13:19:28 -0000 On 2009-08-07, at 15:09, Rafal Jaworowski wrote: > Don, > Support for SheevaPlug as a diff against recent HEAD is here http://people.freebsd.org/~raj/patches/arm/sheevaplug.diff > > Note there's a separate kernel config named SHEEVAPLUG, so use this > for building your kernel. Let me know if this worked for you. Grr, I put a wrong version of the patch, so if you were quick enough you took a broken diff :-) Download the patch again (it's now ok). Rafal From owner-freebsd-arm@FreeBSD.ORG Sat Aug 8 20:46:26 2009 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 7344B106566B; Sat, 8 Aug 2009 20:46:26 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2608C8FC19; Sat, 8 Aug 2009 20:46:26 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n78KRpoV018525; Sat, 8 Aug 2009 16:27:51 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200908082027.n78KRpoV018525@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 08 Aug 2009 16:30:54 -0400 To: Hans Petter Selasky , Grzegorz Bernacki , freebsd-current@freebsd.org, freebsd-usb@freebsd.org, arm@freebsd.org From: Mike Tancsa In-Reply-To: <200908071433.16484.hselasky@c2i.net> References: <200908071433.16484.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: USB busdma sync flag fix 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, 08 Aug 2009 20:46:26 -0000 At 08:33 AM 8/7/2009, Hans Petter Selasky wrote: >Hi, > >Can people with AMD64 + USB and more than 4GBytes of RAM give the following >patch a shot? > >http://perforce.freebsd.org/chv.cgi?CH=167088 I tried an eToken key, a USB thumb drive and an uplcom device and it seems to work. Latest HEAD with above patch on a box with CPU: AMD Phenom(tm) 9950 Quad-Core Processor (2608.82-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f23 Stepping = 3 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x7ff TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 8001216512 (7630 MB) ACPI APIC Table: <051209 APIC1231> 0(freebsd-current2)# usbconfig ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.1: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen4.1: at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen6.1: at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen5.1: at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.2: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON 0(freebsd-current2)# ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike