From owner-freebsd-arm@FreeBSD.ORG Mon Jul 20 04:46:19 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 1F747106566B for ; Mon, 20 Jul 2009 04:46:19 +0000 (UTC) (envelope-from xiechao.mail@gmail.com) Received: from mail-qy0-f204.google.com (mail-qy0-f204.google.com [209.85.221.204]) by mx1.freebsd.org (Postfix) with ESMTP id D06338FC0C for ; Mon, 20 Jul 2009 04:46:18 +0000 (UTC) (envelope-from xiechao.mail@gmail.com) Received: by qyk42 with SMTP id 42so1608501qyk.3 for ; Sun, 19 Jul 2009 21:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=52ctLEokbrRwRb126+Ks2YdhPsVIazMbdVa3I69/hPo=; b=o2ysIr5YfqGJ473BWJp/pZXqIxkBN7Fiu7v9PHRCoQgdAlnD0ISspbZBltKjHhWF6Y kKuyd6mvrtU40/BWoDysSplvt7XlQ4sBzjqKM/l4ax/KEN/lxFBFl4ms3Ol4TIdcbRcN BD/K/WIaWhd2j2ZOHDYNuopJjW6KgjzKfaAwk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ZJuGpvG6b6W3kDYrEhKaLNBE6TGamZ544mww6UEmRf1fDb/Q9J0k4Qw0Z1oJmvHnjC JG2XhuRmxeCbPJiM/xjo8cnxJ6VwKzWkv5vNHRdAeJEz2KH43iv6gqMLLGsawCErAo4T MGVkMTVVA3War+rTl+b21Wo+56R8Xlb6uR4h8= MIME-Version: 1.0 Received: by 10.229.96.132 with SMTP id h4mr720596qcn.65.1248061095655; Sun, 19 Jul 2009 20:38:15 -0700 (PDT) Date: Mon, 20 Jul 2009 11:38:15 +0800 Message-ID: From: Chao Xie To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: start_init data abort 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, 20 Jul 2009 04:46:19 -0000 hi I am trying to port Freebsd to pxa310. After I have compiled, and get kernel.bin, i will directly download it to SDRAM, and begin to run it. The SYSINITs are all right, and i get the final init - start_init. At this time, a exception of data abort happens. After i debug it, i find it is caused by subyte at the following code. /* * Move out the boot flag argument. */ options = 0; ucp = (char *)p->p_sysent->sv_usrstack; (void)subyte(--ucp, 0); /* trailing zero */ if (boothowto & RB_SINGLE) { (void)subyte(--ucp, 's'); options = 1; } It seems that subyte will store a byte to user stack of initproc. The user stack of initproc is started at 0xC0000000. i have checked the page mapping, and find the veirtual address 0xC0000000 - PAGESIZE to 0xC0000000 is not mapped. So i get the data abort. I am confuesed. Where should i map the user stack of initproc? I appreciate that someone can help me.Thanks. From owner-freebsd-arm@FreeBSD.ORG Mon Jul 20 11:06:51 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 70A031065670 for ; Mon, 20 Jul 2009 11:06:51 +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 5E6D38FC17 for ; Mon, 20 Jul 2009 11:06:51 +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 n6KB6pOA002203 for ; Mon, 20 Jul 2009 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n6KB6oY0002199 for freebsd-arm@FreeBSD.org; Mon, 20 Jul 2009 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 Jul 2009 11:06:50 GMT Message-Id: <200907201106.n6KB6oY0002199@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, 20 Jul 2009 11:06:51 -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 Tue Jul 21 16:48:03 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 7314F1065678 for ; Tue, 21 Jul 2009 16:48:03 +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 16AEF8FC0C for ; Tue, 21 Jul 2009 16:48:02 +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 n6LGm2Jp076062; Tue, 21 Jul 2009 11:48:02 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1248194882; bh=BsX3OIH3RLvR01H1LrhBlSLlqFYrQlQQRlHqnwWiXzY=; h=Date:From:Message-Id:To:Subject:In-Reply-To; b=MvmlSewMW0TMK3SP8wW9Mo0RNnlO4oKWvBPgMLEVnFIAOWph6AzVFn/LOwadqAadJ ZtnshIxos1kEUuj2ixRrtcFJdFCf1pof8gtOpGg3KP1mdfJo4VVW9tNleH21RFNWal 1Mm0u88YNwzA651BSsFSUZkCQYw0FWZf+r0yYpxs= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id n6LGm2KW076061; Tue, 21 Jul 2009 11:48:02 -0500 (CDT) (envelope-from tinguely) Date: Tue, 21 Jul 2009 11:48:02 -0500 (CDT) From: Mark Tinguely Message-Id: <200907211648.n6LGm2KW076061@casselton.net> To: freebsd-arm@freebsd.org, xiechao.mail@gmail.com In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Tue, 21 Jul 2009 11:48:02 -0500 (CDT) Cc: Subject: Re: start_init data abort 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, 21 Jul 2009 16:48:03 -0000 > > hi > I am trying to port Freebsd to pxa310. After I have compiled, and get > kernel.bin, i will directly download it to SDRAM, and begin to run it. The > SYSINITs are all right, and i get the final init - start_init. At this time, > a exception of data abort happens. > After i debug it, i find it is caused by subyte at the following code. > /* > * Move out the boot flag argument. > */ > options = 0; > ucp = (char *)p->p_sysent->sv_usrstack; > (void)subyte(--ucp, 0); /* trailing zero */ > if (boothowto & RB_SINGLE) { > (void)subyte(--ucp, 's'); > options = 1; > } > > It seems that subyte will store a byte to user stack of initproc. The user > stack of initproc is started at 0xC0000000. i have checked the page mapping, > and find the veirtual address 0xC0000000 - PAGESIZE to 0xC0000000 is not > mapped. So i get the data abort. > I am confuesed. Where should i map the user stack of initproc? I appreciate > that someone can help me.Thanks. In the begining of that routine, the user stack is put into the map backed by a default (NULL) object. A page for the stack should fault a page into that location when accessed. For testing, you can speed it along a bit by setting the MAP_PREFAULT bit: addr = p->p_sysent->sv_usrstack - PAGE_SIZE; if (vm_map_find(&p->p_vmspace->vm_map, NULL, 0, &addr, PAGE_SIZE, - FALSE, VM_PROT_ALL, VM_PROT_ALL, 0) != 0) + FALSE, VM_PROT_ALL, VM_PROT_ALL, MAP_PREFAULT) != 0) panic("init: couldn't allocate argument space"); If there is still no page at that location and you have a console, you can print out the vm_map. From owner-freebsd-arm@FreeBSD.ORG Thu Jul 23 19:53:32 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 0E8EF106564A; Thu, 23 Jul 2009 19:53:31 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id F07AA8FC19; Thu, 23 Jul 2009 19:53:30 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp028.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KN900GM60GISN10@asmtp028.mac.com>; Thu, 23 Jul 2009 11:53:07 -0700 (PDT) From: Marcel Moolenaar Date: Thu, 23 Jul 2009 11:53:06 -0700 Message-id: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> To: arm@freebsd.org, usb@freebsd.org X-Mailer: Apple Mail (2.1071.1) Cc: Subject: 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: Thu, 23 Jul 2009 19:53:32 -0000 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. My $0.02... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arm@FreeBSD.ORG Thu Jul 23 21:10:02 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 888CC1065674 for ; Thu, 23 Jul 2009 21:10:02 +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 1DDA98FC1A for ; Thu, 23 Jul 2009 21:10:01 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=uXAB73GHeBQA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=n8i6e8dZgnT8OozT7QIA:9 a=xrXtKjxkOyuRuyI7wFfghJIjHEMA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 229393225; Thu, 23 Jul 2009 22:10:00 +0200 From: Hans Petter Selasky To: Marcel Moolenaar Date: Thu, 23 Jul 2009 22:09:45 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> In-Reply-To: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907232209.47729.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: Thu, 23 Jul 2009 21:10:02 -0000 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. --HPS From owner-freebsd-arm@FreeBSD.ORG Sat Jul 25 03:36:13 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 6020D106566B; Sat, 25 Jul 2009 03:36:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1F6498FC20; Sat, 25 Jul 2009 03:36:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n6P3XQV2003836; Fri, 24 Jul 2009 21:33:27 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 24 Jul 2009 23:34:04 -0400 (EDT) Message-Id: <20090724.233404.-399282844.imp@bsdimp.com> To: hselasky@c2i.net From: "M. Warner Losh" In-Reply-To: <200907232209.47729.hselasky@c2i.net> References: <3E1658AF-67C6-4E61-B6E7-BEF528C3FF4D@mac.com> <200907232209.47729.hselasky@c2i.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Sat, 25 Jul 2009 03:36:13 -0000 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... Warner