From owner-freebsd-arm@FreeBSD.ORG Tue Dec 11 20:10:06 2007 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 A615A16A4C4 for ; Tue, 11 Dec 2007 20:10:06 +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 6291713C4E5 for ; Tue, 11 Dec 2007 20:10:06 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.13.8/8.13.8) with ESMTP id lBBKA2Q7016943; Tue, 11 Dec 2007 14:10:02 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1197403803; bh=QFQy9WAqdRR4HlrTvwdVvbPVtwpasEhKbRS2HIR iERk=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=Wt73pMjx O/45Fky72n5onzhTHgL0oiSR+hb9CqZW3NZt06WpVWNbtV/0gcG8jxkp9SOZyzM7Vfg 8QCJWYfjJoSCpN2vxpCKOLIDt2nB9E5EcXKO8FI2H53umhHeF/imqOJQbhiXHLBMdDS HBtBnzZpWh8pNf+8e33FXPZ8s7d6w= Received: (from tinguely@localhost) by casselton.net (8.13.8/8.13.8/Submit) id lBBKA2qJ016942; Tue, 11 Dec 2007 14:10:02 -0600 (CST) (envelope-from tinguely) Date: Tue, 11 Dec 2007 14:10:02 -0600 (CST) From: Mark Tinguely Message-Id: <200712112010.lBBKA2qJ016942@casselton.net> To: mlfbsd@ci0.org In-Reply-To: <20071206230417.GA7366@ci0.org> Cc: freebsd-arm@freebsd.org Subject: ARM pmap.c redundant vac_me_harder 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, 11 Dec 2007 20:10:06 -0000 IMO, there is a redundant vac_me_harder() call in pmap_protect(). The vac_me_harder() is already performed as the last step in pmap_modify_pv() when the PVF_WRITE flag is changed. --- on a related topic --- vac_me_kpmap() can cause (2 * n ^ 2) loops of the pv_list. From my rough pen and paper logic and even rougher coding, I think the vac_me_XXXX routines can be combined together and the user scan can be kept at (2 * n) loops and the kernel cache fixup can be done in (3 * n) loops at the cost of adding a couple variables to the pmap structure. Since the variables are in the pmap, only one scan can be done at a time - which would not be a problem on uniprocessors. Okay, I promise to quit digging through the ARM pmap code. --Mark Tinguely. From owner-freebsd-arm@FreeBSD.ORG Tue Dec 11 20:36:11 2007 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 54D5016A421 for ; Tue, 11 Dec 2007 20:36:11 +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 2375D13C474 for ; Tue, 11 Dec 2007 20:36:11 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBBKWp8G055183; Tue, 11 Dec 2007 13:32:51 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 11 Dec 2007 13:33:31 -0700 (MST) Message-Id: <20071211.133331.31318824.imp@bsdimp.com> To: tinguely@casselton.net From: "M. Warner Losh" In-Reply-To: <200712112010.lBBKA2qJ016942@casselton.net> References: <20071206230417.GA7366@ci0.org> <200712112010.lBBKA2qJ016942@casselton.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: freebsd-arm@FreeBSD.org Subject: Re: ARM pmap.c redundant vac_me_harder 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, 11 Dec 2007 20:36:11 -0000 In message: <200712112010.lBBKA2qJ016942@casselton.net> Mark Tinguely writes: : : IMO, there is a redundant vac_me_harder() call in pmap_protect(). : The vac_me_harder() is already performed as the last step in pmap_modify_pv() : when the PVF_WRITE flag is changed. It looks to my eye like the vac_me_harder() in pmap_modify_pv only happens when the write flag is changed, while the call in pmap_protect is always called. I've not looked closely enough to know if this difference matters, but I thought I'd mention it to see if you'd considered it. : --- on a related topic --- : vac_me_kpmap() can cause (2 * n ^ 2) loops of the pv_list. From my rough : pen and paper logic and even rougher coding, I think the vac_me_XXXX routines : can be combined together and the user scan can be kept at (2 * n) loops : and the kernel cache fixup can be done in (3 * n) loops at the cost of : adding a couple variables to the pmap structure. Since the variables are : in the pmap, only one scan can be done at a time - which would not be a : problem on uniprocessors. No, but mutlicore ARM is around the corner, so we don't want to paint ourselves into too much of a corner. : Okay, I promise to quit digging through the ARM pmap code. Please don't :-). We can always use the help there. Warner From owner-freebsd-arm@FreeBSD.ORG Tue Dec 11 20:38:33 2007 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 5749716A417 for ; Tue, 11 Dec 2007 20:38:33 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (dong.ci0.org [IPv6:2001:7a8:2066:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id A5DF413C448 for ; Tue, 11 Dec 2007 20:38:32 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.14.1/8.13.8) with ESMTP id lBBLaeCT001181; Tue, 11 Dec 2007 22:36:40 +0100 (CET) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.14.1/8.13.8/Submit) id lBBLaehK001180; Tue, 11 Dec 2007 22:36:40 +0100 (CET) (envelope-from mlfbsd) Date: Tue, 11 Dec 2007 22:36:39 +0100 From: Olivier Houchard To: Mark Tinguely Message-ID: <20071211213639.GA1115@ci0.org> References: <20071206230417.GA7366@ci0.org> <200712112010.lBBKA2qJ016942@casselton.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200712112010.lBBKA2qJ016942@casselton.net> User-Agent: Mutt/1.4.1i Cc: freebsd-arm@freebsd.org Subject: Re: ARM pmap.c redundant vac_me_harder 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, 11 Dec 2007 20:38:33 -0000 On Tue, Dec 11, 2007 at 02:10:02PM -0600, Mark Tinguely wrote: > > IMO, there is a redundant vac_me_harder() call in pmap_protect(). > The vac_me_harder() is already performed as the last step in pmap_modify_pv() > when the PVF_WRITE flag is changed. > True, I just removed it. Thanks ! > --- on a related topic --- > vac_me_kpmap() can cause (2 * n ^ 2) loops of the pv_list. From my rough > pen and paper logic and even rougher coding, I think the vac_me_XXXX routines > can be combined together and the user scan can be kept at (2 * n) loops > and the kernel cache fixup can be done in (3 * n) loops at the cost of > adding a couple variables to the pmap structure. Since the variables are > in the pmap, only one scan can be done at a time - which would not be a > problem on uniprocessors. > Hmm your probably right. Honestly I've never bothered optimizing those, because the number of mappings for a page is typically so low it wasn't worth the pain. But patches would be welcome ;) > Okay, I promise to quit digging through the ARM pmap code. Please don't, this is really appreciated :) Regards, Olivier From owner-freebsd-arm@FreeBSD.ORG Tue Dec 11 21:48:50 2007 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 1982C16A419 for ; Tue, 11 Dec 2007 21:48:50 +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 B145713C44B for ; Tue, 11 Dec 2007 21:48:49 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.13.8/8.13.8) with ESMTP id lBBLmVOC025141; Tue, 11 Dec 2007 15:48:33 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1197409715; bh=Nq2Gc2oFgu/lRTz6PFI/94SKvBivZc4T/143Dk9 zO74=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=ZnakX4FE jngxRxUL2utrPc8zBQwf2fT6iDColB8t91JPCk0KFdS+euC/WvO0kxo8M/vH4zXFKwo OxOvtYUqHWrats4A2JFBP34a+cxWyg0K+g1411RwbYwsDQ2+qmGReG3exFr6FhcPtCx TjdZw++biLp6g7HiiJhhEjTgWtz7c= Received: (from tinguely@localhost) by casselton.net (8.13.8/8.13.8/Submit) id lBBLmPsV025126; Tue, 11 Dec 2007 15:48:25 -0600 (CST) (envelope-from tinguely) Date: Tue, 11 Dec 2007 15:48:25 -0600 (CST) From: Mark Tinguely Message-Id: <200712112148.lBBLmPsV025126@casselton.net> To: imp@bsdimp.com, tinguely@casselton.net In-Reply-To: <20071211.133331.31318824.imp@bsdimp.com> Cc: freebsd-arm@FreeBSD.org Subject: Re: ARM pmap.c redundant vac_me_harder 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, 11 Dec 2007 21:48:50 -0000 > : IMO, there is a redundant vac_me_harder() call in pmap_protect(). > : The vac_me_harder() is already performed as the last step in pmap_modify_pv() > : when the PVF_WRITE flag is changed. > > It looks to my eye like the vac_me_harder() in pmap_modify_pv only > happens when the write flag is changed, while the call in pmap_protect > is always called. I've not looked closely enough to know if this > difference matters, but I thought I'd mention it to see if you'd > considered it. vac_me_harder (as prefer to call it "fix_caches") only matters when the write status changes, which is the time to see if caches should be turned off or back on. > : --- on a related topic --- > : vac_me_kpmap() can cause (2 * n ^ 2) loops of the pv_list. From my rough > : pen and paper logic and even rougher coding, I think the vac_me_XXXX routines > : can be combined together and the user scan can be kept at (2 * n) loops > : and the kernel cache fixup can be done in (3 * n) loops at the cost of > : adding a couple variables to the pmap structure. Since the variables are > : in the pmap, only one scan can be done at a time - which would not be a > : problem on uniprocessors. > > No, but mutlicore ARM is around the corner, so we don't want to paint > ourselves into too much of a corner. I am exploring the ARM implementation in a hacker/theorist/dreamer mode. Actually, I had thought of multiple ARM per device such as cellphones, but I did not know if they were NUMA. Multiple processors are not that big of a problem, a lock could keep the scan sequential (actually the vm_page_queue lock should already do that), or this is symmetrical enough that per cpu variables could be added instead. IMO, there are some PMAP_LOCKS missing in the vac_me_XXX code; we are clearing changing pte and pv_flags without locks. It was in the inserting those missing locks that I started to say "hmmm, would vm_page_queue_mtx prevent the need to drop the existing lock (for the pmap "pm") if I could not get a pmap lock for the new pmap entry while traversing the pv_list?". That is why I made a safer claim of uniprocessor stable. I respect Olivier's accessment that the pv_lists are shallow enough for this to not matter - I suppected that this was the case; ARM devices are not general computing devices. --Mark Tinguely. From owner-freebsd-arm@FreeBSD.ORG Thu Dec 13 09:58:55 2007 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 0AAB016A417 for ; Thu, 13 Dec 2007 09:58:55 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id EEDCB13C4D1 for ; Thu, 13 Dec 2007 09:58:54 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1J2kYK-0001Ni-15 for freebsd-arm@freebsd.org; Thu, 13 Dec 2007 01:40:24 -0800 Message-ID: <14312707.post@talk.nabble.com> Date: Thu, 13 Dec 2007 01:40:24 -0800 (PST) From: Jacek Wikiera To: freebsd-arm@freebsd.org In-Reply-To: <20071109154712.GA51100@ci0.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jacek@wikiera.net References: <20071109133153.GE899@dracon.ht-systems.ru> <20071109152203.GA50755@ci0.org> <20071109144932.GG899@dracon.ht-systems.ru> <20071109154712.GA51100@ci0.org> Subject: Re: FreeBSD under skyeye 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, 13 Dec 2007 09:58:55 -0000 Olivier Houchard-3 wrote: > > AFAIK qemu won't run FreeBSD, however last time I tried, gxemul would run > a > slightly stripped down IQ31244 kernel. The kernel config I used can be > found > here : > http://people.FreeBSD.org/~cognet/IQGXEMUL > Olivier, How should the FreeBSD kernel be run with gxemul? Can a regular compiled-for-ARM kernel be used? Or shall a disk image be prepared? -- View this message in context: http://www.nabble.com/FreeBSD-under-skyeye-tp13667600p14312707.html Sent from the freebsd-arm mailing list archive at Nabble.com. From owner-freebsd-arm@FreeBSD.ORG Thu Dec 13 20:55:06 2007 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 25B8816A41A for ; Thu, 13 Dec 2007 20:55:06 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id CC83E13C461 for ; Thu, 13 Dec 2007 20:55:05 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from [78.110.49.49] (helo=quasar.ht-systems.ru) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1J2v5D-0006WY-Pc for freebsd-arm@FreeBSD.org; Thu, 13 Dec 2007 23:55:03 +0300 Received: by quasar.ht-systems.ru (Postfix, from userid 1024) id A73AE7D2803; Thu, 13 Dec 2007 23:55:02 +0300 (MSK) Date: Thu, 13 Dec 2007 23:55:02 +0300 From: Stanislav Sedov To: freebsd-arm@FreeBSD.org Message-ID: <20071213205502.GD17356@dracon.ht-systems.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: The FreeBSD Project X-Voice: +7 916 849 20 23 X-XMPP: ssedov@jabber.ru X-Yahoo: stanislav_sedov X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-University: MEPhI X-Mailer: carrier-pigeon X-Operating-System: FreeBSD quasar.ht-systems.ru 7.0-BETA2 FreeBSD 7.0-BETA2 Cc: Subject: MMC cards support 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, 13 Dec 2007 20:55:06 -0000 Hi! Am I currently understand that MMC cards isn't supported now? My board can't detect that:-( I've heard about qdmmc driver, but can't find it either in CVS or in Perforce, where can I get a copy to take a look? Hopefully, I'll be able to add mmc support based on this code... Also, I have a little question about if_ate. I'm receiving the error when initializing it: ate0: No MAC address setdevice_attach: ate0 attach returned 6 Is it u-boot (that I use to boot the FreeBSD kernel) sets up incorrect MAC (though the network works flawlessly in u-boot), or probably there're some other issues that can cause it? Thanks a lot! -- Stanislav Sedov ST4096-RIPE From owner-freebsd-arm@FreeBSD.ORG Thu Dec 13 22:00:17 2007 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 4247616A419; Thu, 13 Dec 2007 22:00:17 +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 F05B713C459; Thu, 13 Dec 2007 22:00:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBDLvLdG003383; Thu, 13 Dec 2007 14:57:22 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 13 Dec 2007 14:58:28 -0700 (MST) Message-Id: <20071213.145828.1650439159.imp@bsdimp.com> To: stas@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20071213205502.GD17356@dracon.ht-systems.ru> References: <20071213205502.GD17356@dracon.ht-systems.ru> 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: freebsd-arm@FreeBSD.org Subject: Re: MMC cards support 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, 13 Dec 2007 22:00:17 -0000 In message: <20071213205502.GD17356@dracon.ht-systems.ru> Stanislav Sedov writes: : Am I currently understand that MMC cards isn't supported now? My board : can't detect that:-( I've heard about qdmmc driver, but can't find it : either in CVS or in Perforce, where can I get a copy to take a look? : Hopefully, I'll be able to add mmc support based on this code... There's no MMC support in the boot loader at the moment. Only SD support. There's some preliminary MMC support in the infrastructure, but I never fleshed it out. : Also, I have a little question about if_ate. I'm receiving the error : when initializing it: : ate0: No MAC address setdevice_attach: ate0 attach returned 6 This means that the MAC address wasn't set by the boot loader. : Is it u-boot (that I use to boot the FreeBSD kernel) sets up incorrect : MAC (though the network works flawlessly in u-boot), or probably there're : some other issues that can cause it? I tought one needed to so something special with uboot to set the MAC address. Is that not right? Warner From owner-freebsd-arm@FreeBSD.ORG Thu Dec 13 22:26:58 2007 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 6470C16A41B for ; Thu, 13 Dec 2007 22:26:58 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id 1A00B13C43E for ; Thu, 13 Dec 2007 22:26:57 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from [78.110.49.49] (helo=quasar.ht-systems.ru) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1J2wW7-0007HI-Pk; Fri, 14 Dec 2007 01:26:55 +0300 Received: by quasar.ht-systems.ru (Postfix, from userid 1024) id B6B8A7D2803; Fri, 14 Dec 2007 01:26:54 +0300 (MSK) Date: Fri, 14 Dec 2007 01:26:54 +0300 From: Stanislav Sedov To: "M. Warner Losh" Message-ID: <20071213222654.GE17356@dracon.ht-systems.ru> References: <20071213205502.GD17356@dracon.ht-systems.ru> <20071213.145828.1650439159.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071213.145828.1650439159.imp@bsdimp.com> Organization: The FreeBSD Project X-Voice: +7 916 849 20 23 X-XMPP: ssedov@jabber.ru X-Yahoo: stanislav_sedov X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-University: MEPhI X-Mailer: carrier-pigeon X-Operating-System: FreeBSD quasar.ht-systems.ru 7.0-BETA2 FreeBSD 7.0-BETA2 Cc: freebsd-arm@FreeBSD.org Subject: Re: MMC cards support 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, 13 Dec 2007 22:26:58 -0000 On Thu, Dec 13, 2007 at 02:58:28PM -0700 M. Warner Losh mentioned: > There's no MMC support in the boot loader at the moment. Only SD > support. There's some preliminary MMC support in the infrastructure, > but I never fleshed it out. Well, I'm not talking about the boot loader's support, but abouth the support in the kernel - I need the this to mount root from. From the older posts I've seens that there was some secret driver - qdmmc, whicn supported mmc cards (if I got this correctly). Can I found this somewhere? > > : Also, I have a little question about if_ate. I'm receiving the error > : when initializing it: > : ate0: No MAC address setdevice_attach: ate0 attach returned 6 > > This means that the MAC address wasn't set by the boot loader. > > : Is it u-boot (that I use to boot the FreeBSD kernel) sets up incorrect > : MAC (though the network works flawlessly in u-boot), or probably there're > : some other issues that can cause it? > > I tought one needed to so something special with uboot to set the MAC > address. Is that not right? > Probably. It seems that FreeBSD is trying to read MAC address from the chip's registers, and I though that if the ethernet works in u-boot then this registers have been set. I'll investigate this further. Thanks for the reply! -- Stanislav Sedov ST4096-RIPE From owner-freebsd-arm@FreeBSD.ORG Fri Dec 14 09:26:15 2007 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 0CBD116A417; Fri, 14 Dec 2007 09:26:15 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 943B113C468; Fri, 14 Dec 2007 09:26:14 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id lBE91ZY6020123; Fri, 14 Dec 2007 10:01:35 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id lBE91TfD004223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Dec 2007 10:01:29 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id lBE91TjQ044603; Fri, 14 Dec 2007 10:01:29 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id lBE91SxQ044602; Fri, 14 Dec 2007 10:01:28 +0100 (CET) (envelope-from ticso) Date: Fri, 14 Dec 2007 10:01:28 +0100 From: Bernd Walter To: Stanislav Sedov Message-ID: <20071214090128.GM31230@cicely12.cicely.de> References: <20071213205502.GD17356@dracon.ht-systems.ru> <20071213.145828.1650439159.imp@bsdimp.com> <20071213222654.GE17356@dracon.ht-systems.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071213222654.GE17356@dracon.ht-systems.ru> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.144, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: MMC cards support X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 09:26:15 -0000 On Fri, Dec 14, 2007 at 01:26:54AM +0300, Stanislav Sedov wrote: > On Thu, Dec 13, 2007 at 02:58:28PM -0700 M. Warner Losh mentioned: > > There's no MMC support in the boot loader at the moment. Only SD > > support. There's some preliminary MMC support in the infrastructure, > > but I never fleshed it out. > > Well, I'm not talking about the boot loader's support, but abouth the > support in the kernel - I need the this to mount root from. From the > older posts I've seens that there was some secret driver - qdmmc, whicn > supported mmc cards (if I got this correctly). Can I found this somewhere? It was comited to perforce tree, but retired long time ago after the new system worked - qd stands for quick'n dirty, which it really was. It was easier for me to implement MMC since I had better documents at that time, but SD cards are cheaper so unless you want to support multiple cards at the same time, which is only supported by MMC, there is no win with MMC, and qdmmc only supported a single card anyway. > > : Also, I have a little question about if_ate. I'm receiving the error > > : when initializing it: > > : ate0: No MAC address setdevice_attach: ate0 attach returned 6 > > > > This means that the MAC address wasn't set by the boot loader. > > > > : Is it u-boot (that I use to boot the FreeBSD kernel) sets up incorrect > > : MAC (though the network works flawlessly in u-boot), or probably there're > > : some other issues that can cause it? > > > > I tought one needed to so something special with uboot to set the MAC > > address. Is that not right? > > > > Probably. It seems that FreeBSD is trying to read MAC address from the chip's > registers, and I though that if the ethernet works in u-boot then this registers > have been set. I'll investigate this further. Sounds logical, but I don't know u-boot and FreeBSD won't complain without a reason. At least there is no standard place to get the system MAC beside the ate registers. Of course you can hack the ate driver and hardcode a MAC into the kernel. Or you can switch to FreeBSDs own bootcode. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-arm@FreeBSD.ORG Fri Dec 14 10:52:29 2007 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 C457016A418 for ; Fri, 14 Dec 2007 10:52:29 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) by mx1.freebsd.org (Postfix) with ESMTP id 617CD13C447 for ; Fri, 14 Dec 2007 10:52:29 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.16] (helo=6.mx.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.68) (envelope-from ) id 1J389b-0000Hl-R4 for freebsd-arm@freebsd.org; Fri, 14 Dec 2007 11:52:27 +0100 Received: from x0f55.x.pppool.de ([89.59.15.85]:57210 helo=peedub.jennejohn.org) by 6.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.68 #1) id 1J389b-0005O2-Ld for freebsd-arm@freebsd.org; Fri, 14 Dec 2007 11:52:27 +0100 Date: Fri, 14 Dec 2007 11:52:26 +0100 From: Gary Jennejohn To: freebsd-arm@freebsd.org Message-ID: <20071214115226.0b2cb7e2@peedub.jennejohn.org> In-Reply-To: <20071214090128.GM31230@cicely12.cicely.de> References: <20071213205502.GD17356@dracon.ht-systems.ru> <20071213.145828.1650439159.imp@bsdimp.com> <20071213222654.GE17356@dracon.ht-systems.ru> <20071214090128.GM31230@cicely12.cicely.de> Organization: DENX Softwre Engineering GmbH X-Mailer: Claws Mail 3.0.2 (GTK+ 2.10.14; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: MMC cards support X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 10:52:29 -0000 On Fri, 14 Dec 2007 10:01:28 +0100 Bernd Walter wrote: > On Fri, Dec 14, 2007 at 01:26:54AM +0300, Stanislav Sedov wrote: > > Probably. It seems that FreeBSD is trying to read MAC address from the chip's > > registers, and I though that if the ethernet works in u-boot then this registers > > have been set. I'll investigate this further. > > Sounds logical, but I don't know u-boot and FreeBSD won't complain > without a reason. > At least there is no standard place to get the system MAC beside the > ate registers. > Of course you can hack the ate driver and hardcode a MAC into the kernel. > Or you can switch to FreeBSDs own bootcode. > u-boot passes this information to Linux in the board info (bd_t) structure at boot time. A lot of Linux ethernet drivers read the MAC out of this structure and then set it in the hardware/software. Very few u-boot ethernet drivers set the MAC in the hardware themselves. With FreeBSD this mechanism is missing. -- Gary Jennejohn From owner-freebsd-arm@FreeBSD.ORG Fri Dec 14 13:27:29 2007 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 3445216A417 for ; Fri, 14 Dec 2007 13:27:29 +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 ED47313C46E for ; Fri, 14 Dec 2007 13:27:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBEDPB3I018152; Fri, 14 Dec 2007 06:25:12 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 14 Dec 2007 06:25:11 -0700 (MST) Message-Id: <20071214.062511.74732956.imp@bsdimp.com> To: gary.jennejohn@freenet.de From: Warner Losh In-Reply-To: <20071214115226.0b2cb7e2@peedub.jennejohn.org> References: <20071213222654.GE17356@dracon.ht-systems.ru> <20071214090128.GM31230@cicely12.cicely.de> <20071214115226.0b2cb7e2@peedub.jennejohn.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: MMC cards support 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, 14 Dec 2007 13:27:29 -0000 From: Gary Jennejohn Subject: Re: MMC cards support Date: Fri, 14 Dec 2007 11:52:26 +0100 > On Fri, 14 Dec 2007 10:01:28 +0100 > Bernd Walter wrote: > > > On Fri, Dec 14, 2007 at 01:26:54AM +0300, Stanislav Sedov wrote: > > > Probably. It seems that FreeBSD is trying to read MAC address from the chip's > > > registers, and I though that if the ethernet works in u-boot then this registers > > > have been set. I'll investigate this further. > > > > Sounds logical, but I don't know u-boot and FreeBSD won't complain > > without a reason. > > At least there is no standard place to get the system MAC beside the > > ate registers. > > Of course you can hack the ate driver and hardcode a MAC into the kernel. > > Or you can switch to FreeBSDs own bootcode. > > > > u-boot passes this information to Linux in the board info (bd_t) > structure at boot time. A lot of Linux ethernet drivers read the MAC > out of this structure and then set it in the hardware/software. > > Very few u-boot ethernet drivers set the MAC in the hardware themselves. > > With FreeBSD this mechanism is missing. I did it this way because the Linux driver for the Atmel driver did it this way. I thought it was the de-facto way things work. Patches to implement this would be welcome. Warner From owner-freebsd-arm@FreeBSD.ORG Fri Dec 14 14:32:03 2007 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 EB57F16A421 for ; Fri, 14 Dec 2007 14:32:03 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) by mx1.freebsd.org (Postfix) with ESMTP id 5A9A913C4EC for ; Fri, 14 Dec 2007 14:32:03 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.12] (helo=2.mx.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.68) (envelope-from ) id 1J3Ba5-0002F7-UO for freebsd-arm@freebsd.org; Fri, 14 Dec 2007 15:32:02 +0100 Received: from x0f55.x.pppool.de ([89.59.15.85]:59112 helo=peedub.jennejohn.org) by 2.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.68 #1) id 1J3Ba5-0001fj-Nc for freebsd-arm@freebsd.org; Fri, 14 Dec 2007 15:32:01 +0100 Date: Fri, 14 Dec 2007 15:32:01 +0100 From: Gary Jennejohn To: freebsd-arm@freebsd.org Message-ID: <20071214153201.18c4c5ea@peedub.jennejohn.org> In-Reply-To: <20071214.062511.74732956.imp@bsdimp.com> References: <20071213222654.GE17356@dracon.ht-systems.ru> <20071214090128.GM31230@cicely12.cicely.de> <20071214115226.0b2cb7e2@peedub.jennejohn.org> <20071214.062511.74732956.imp@bsdimp.com> Organization: DENX Softwre Engineering GmbH X-Mailer: Claws Mail 3.0.2 (GTK+ 2.10.14; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: MMC cards support X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 14:32:04 -0000 On Fri, 14 Dec 2007 06:25:11 -0700 (MST) Warner Losh wrote: > From: Gary Jennejohn > Subject: Re: MMC cards support > Date: Fri, 14 Dec 2007 11:52:26 +0100 > > > On Fri, 14 Dec 2007 10:01:28 +0100 > > Bernd Walter wrote: > > > > > On Fri, Dec 14, 2007 at 01:26:54AM +0300, Stanislav Sedov wrote: > > > > Probably. It seems that FreeBSD is trying to read MAC address from the chip's > > > > registers, and I though that if the ethernet works in u-boot then this registers > > > > have been set. I'll investigate this further. > > > > > > Sounds logical, but I don't know u-boot and FreeBSD won't complain > > > without a reason. > > > At least there is no standard place to get the system MAC beside the > > > ate registers. > > > Of course you can hack the ate driver and hardcode a MAC into the kernel. > > > Or you can switch to FreeBSDs own bootcode. > > > > > > > u-boot passes this information to Linux in the board info (bd_t) > > structure at boot time. A lot of Linux ethernet drivers read the MAC > > out of this structure and then set it in the hardware/software. > > > > Very few u-boot ethernet drivers set the MAC in the hardware themselves. > > > > With FreeBSD this mechanism is missing. > > I did it this way because the Linux driver for the Atmel driver did it > this way. I thought it was the de-facto way things work. Patches to > implement this would be welcome. > It is effectively the de-facto way to do things in the Linux embedded world. Just about every embedded board used with Linux also uses u-boot. It just won't work with FreeBSD because the infrastructure (passing bd_t to the kernel) is missing. This is a weakness of which Wolfgang Denk is well aware and he'd just love for somebody to put together the missing glue for *BSD and send it to him. Of course, this would also require changes to the kernel itself. I know about this stuff because I do embedded Linux for a living and have hacked on u-boot myself. Wolfgang Denk is also a friend of mine. -- Gary Jennejohn From owner-freebsd-arm@FreeBSD.ORG Fri Dec 14 15:16:40 2007 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 23D3516A417 for ; Fri, 14 Dec 2007 15:16:40 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by mx1.freebsd.org (Postfix) with ESMTP id 94B0E13C4FD for ; Fri, 14 Dec 2007 15:16:39 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from localhost (unknown [127.0.0.1]) by mail.semihalf.com (Postfix) with ESMTP id 46D1A143EA; Fri, 14 Dec 2007 16:20:05 +0100 (CET) Received: from mail.semihalf.com ([127.0.0.1]) by localhost (mail.semihalf.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31509-10; Fri, 14 Dec 2007 16:20:03 +0100 (CET) Message-ID: <47629E53.30404@semihalf.com> Date: Fri, 14 Dec 2007 16:16:35 +0100 From: Rafal Jaworowski MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <20071213222654.GE17356@dracon.ht-systems.ru> <20071214090128.GM31230@cicely12.cicely.de> <20071214115226.0b2cb7e2@peedub.jennejohn.org> <20071214.062511.74732956.imp@bsdimp.com> <20071214153201.18c4c5ea@peedub.jennejohn.org> In-Reply-To: <20071214153201.18c4c5ea@peedub.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at semihalf.com Cc: freebsd-arm@freebsd.org Subject: Re: MMC cards support 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, 14 Dec 2007 15:16:40 -0000 Gary Jennejohn wrote: >>> u-boot passes this information to Linux in the board info (bd_t) >>> structure at boot time. A lot of Linux ethernet drivers read the MAC >>> out of this structure and then set it in the hardware/software. >>> >>> Very few u-boot ethernet drivers set the MAC in the hardware themselves. >>> >>> With FreeBSD this mechanism is missing. >> I did it this way because the Linux driver for the Atmel driver did it >> this way. I thought it was the de-facto way things work. Patches to >> implement this would be welcome. >> > > It is effectively the de-facto way to do things in the Linux embedded > world. Just about every embedded board used with Linux also uses > u-boot. It just won't work with FreeBSD because the infrastructure > (passing bd_t to the kernel) is missing. > > This is a weakness of which Wolfgang Denk is well aware and he'd just > love for somebody to put together the missing glue for *BSD and send it > to him. Of course, this would also require changes to the kernel > itself. > Do you know my work on U-Boot-FreeBSD interface in the custodian repo? http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-freebsd.git;a=summary Wolfgang is aware of the above and I'm going to have those merged with mainline, when now the merge window is open again after 1.3.1 has been released. We're probably getting a bit OT here, but just to clarify U-Boot networking model of operation that was mentioned: MAC address is usually programmed by a U-Boot network controller driver into relevant h/w registers upon every network access, so provided a given interface was used at least once in U-Boot (whatever net command), it should have the MAC addresss programmed correctly when running in the kernel. Otherwise it is left untouched, which happens in most of the cases with multiple integrated controllers -- usually only the first one gets ever used, others are left unconfigured... Rafal From owner-freebsd-arm@FreeBSD.ORG Fri Dec 14 19:08:30 2007 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 4BE2116A5F1 for ; Fri, 14 Dec 2007 19:08:30 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id BB1B513C468 for ; Fri, 14 Dec 2007 19:08:29 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from [78.110.49.49] (helo=quasar.ht-systems.ru) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1J3Fta-0000Ym-Vn; Fri, 14 Dec 2007 22:08:27 +0300 Received: by quasar.ht-systems.ru (Postfix, from userid 1024) id DDF9C7D2803; Fri, 14 Dec 2007 22:08:25 +0300 (MSK) Date: Fri, 14 Dec 2007 22:08:25 +0300 From: Stanislav Sedov To: Rafal Jaworowski Message-ID: <20071214190825.GG17356@dracon.ht-systems.ru> References: <20071213222654.GE17356@dracon.ht-systems.ru> <20071214090128.GM31230@cicely12.cicely.de> <20071214115226.0b2cb7e2@peedub.jennejohn.org> <20071214.062511.74732956.imp@bsdimp.com> <20071214153201.18c4c5ea@peedub.jennejohn.org> <47629E53.30404@semihalf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47629E53.30404@semihalf.com> Organization: The FreeBSD Project X-Voice: +7 916 849 20 23 X-XMPP: ssedov@jabber.ru X-Yahoo: stanislav_sedov X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-University: MEPhI X-Mailer: carrier-pigeon X-Operating-System: FreeBSD quasar.ht-systems.ru 7.0-BETA2 FreeBSD 7.0-BETA2 Cc: freebsd-arm@freebsd.org Subject: Re: MMC cards support 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, 14 Dec 2007 19:08:30 -0000 On Fri, Dec 14, 2007 at 04:16:35PM +0100 Rafal Jaworowski mentioned: > > We're probably getting a bit OT here, but just to clarify U-Boot networking > model of operation that was mentioned: MAC address is usually programmed by a > U-Boot network controller driver into relevant h/w registers upon every > network access, so provided a given interface was used at least once in U-Boot > (whatever net command), it should have the MAC addresss programmed correctly > when running in the kernel. Otherwise it is left untouched, which happens in > most of the cases with multiple integrated controllers -- usually only the > first one gets ever used, others are left unconfigured... > Well, I downloaded the entire kernel via tftp, so the controller was probably configured correctly. Probably, u-boot resets it after transfer (have not checked this yet). The idea of bd_t support looks promising anyway, especially if we'll continue our expansion in the embedded world (almost all powerpc and arm embedded boards are moving toward using u-boot exclusively). This way we'll get a good cooperation with another projects. I'll look into this after I get ate0 and usb working. BTW, what is the status of usb for now? Should it work? I'm receiving a 'device problem (IOERROR), disabling port 1' message if device attached. Is it known problem, or something is misconfigured in my board? Thanks for information! -- Stanislav Sedov ST4096-RIPE From owner-freebsd-arm@FreeBSD.ORG Fri Dec 14 19:33:22 2007 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 520C816A41B; Fri, 14 Dec 2007 19:33:22 +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 0905413C4DB; Fri, 14 Dec 2007 19:33:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBEJVJbp022479; Fri, 14 Dec 2007 12:31:19 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 14 Dec 2007 12:32:39 -0700 (MST) Message-Id: <20071214.123239.-494098273.imp@bsdimp.com> To: stas@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20071214190825.GG17356@dracon.ht-systems.ru> References: <20071214153201.18c4c5ea@peedub.jennejohn.org> <47629E53.30404@semihalf.com> <20071214190825.GG17356@dracon.ht-systems.ru> 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: freebsd-arm@FreeBSD.org Subject: Re: MMC cards support 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, 14 Dec 2007 19:33:22 -0000 In message: <20071214190825.GG17356@dracon.ht-systems.ru> Stanislav Sedov writes: : BTW, what is the status of usb for now? Should it work? I'm receiving : a 'device problem (IOERROR), disabling port 1' message if device attached. : Is it known problem, or something is misconfigured in my board? USB works. I've used three different serial parts as well as a flash reader and a flash stick on my KB9202A. The device error for port 1 is because you are using the FQPA packaging of the part. This packaging doesn't bring out the second USB port. However, the internal pullups aren't quit strong enough for the usb hardware to realize there's nothing connected to it. This is an erratum of the part. Warner From owner-freebsd-arm@FreeBSD.ORG Fri Dec 14 20:19:51 2007 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 1121A16A469 for ; Fri, 14 Dec 2007 20:19:51 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id A503F13C45D for ; Fri, 14 Dec 2007 20:19:50 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from [78.110.49.49] (helo=quasar.ht-systems.ru) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1J3H0e-0001X1-CT; Fri, 14 Dec 2007 23:19:48 +0300 Received: by quasar.ht-systems.ru (Postfix, from userid 1024) id 526B87D2803; Fri, 14 Dec 2007 23:19:47 +0300 (MSK) Date: Fri, 14 Dec 2007 23:19:47 +0300 From: Stanislav Sedov To: "M. Warner Losh" Message-ID: <20071214201947.GH17356@dracon.ht-systems.ru> References: <20071214153201.18c4c5ea@peedub.jennejohn.org> <47629E53.30404@semihalf.com> <20071214190825.GG17356@dracon.ht-systems.ru> <20071214.123239.-494098273.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071214.123239.-494098273.imp@bsdimp.com> Organization: The FreeBSD Project X-Voice: +7 916 849 20 23 X-XMPP: ssedov@jabber.ru X-Yahoo: stanislav_sedov X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-University: MEPhI X-Mailer: carrier-pigeon X-Operating-System: FreeBSD quasar.ht-systems.ru 7.0-BETA2 FreeBSD 7.0-BETA2 Cc: freebsd-arm@FreeBSD.org Subject: Re: MMC cards support 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, 14 Dec 2007 20:19:51 -0000 On Fri, Dec 14, 2007 at 12:32:39PM -0700 M. Warner Losh mentioned: > > USB works. I've used three different serial parts as well as a flash > reader and a flash stick on my KB9202A. > > The device error for port 1 is because you are using the FQPA > packaging of the part. This packaging doesn't bring out the second > USB port. However, the internal pullups aren't quit strong enough for > the usb hardware to realize there's nothing connected to it. This is > an erratum of the part. > I receive these messages for both ports: every time for port 2, and for port 1 when device connected to it (USB mass storage in my case). Though you answered to my question (thanks!), usb works, so I'll tinker with the board's configuration (probably it was wired slightly differently, or anything else). -- Stanislav Sedov ST4096-RIPE From owner-freebsd-arm@FreeBSD.ORG Sat Dec 15 10:59:56 2007 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 3135616A417 for ; Sat, 15 Dec 2007 10:59:56 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id B157713C45A for ; Sat, 15 Dec 2007 10:59:55 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from [78.110.49.49] (helo=quasar.ht-systems.ru) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1J3UkL-0001h2-AO; Sat, 15 Dec 2007 13:59:53 +0300 Received: by quasar.ht-systems.ru (Postfix, from userid 1024) id 8FC2D7D2803; Sat, 15 Dec 2007 13:59:51 +0300 (MSK) Date: Sat, 15 Dec 2007 13:59:51 +0300 From: Stanislav Sedov To: Rafal Jaworowski Message-ID: <20071215105951.GN17356@dracon.ht-systems.ru> References: <20071213222654.GE17356@dracon.ht-systems.ru> <20071214090128.GM31230@cicely12.cicely.de> <20071214115226.0b2cb7e2@peedub.jennejohn.org> <20071214.062511.74732956.imp@bsdimp.com> <20071214153201.18c4c5ea@peedub.jennejohn.org> <47629E53.30404@semihalf.com> <20071214190825.GG17356@dracon.ht-systems.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071214190825.GG17356@dracon.ht-systems.ru> Organization: The FreeBSD Project X-Voice: +7 916 849 20 23 X-XMPP: ssedov@jabber.ru X-Yahoo: stanislav_sedov X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-University: MEPhI X-Mailer: carrier-pigeon X-Operating-System: FreeBSD quasar.ht-systems.ru 7.0-BETA2 FreeBSD 7.0-BETA2 Cc: freebsd-arm@freebsd.org Subject: Align exception (was: MMC cards support) 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, 15 Dec 2007 10:59:56 -0000 On Fri, Dec 14, 2007 at 10:08:25PM +0300 Stanislav Sedov mentioned: > > Well, I downloaded the entire kernel via tftp, so the controller was probably > configured correctly. Probably, u-boot resets it after transfer (have not checked > this yet). > Ok, I've solved my problem with if_ate by hardwiring MAC into the driver and by commenting out the lines 1007-1008 in if_ates./c: if (phy != 0) return (0xffff); My phy (rtl8102BL) is on 0x1D address, that forced the mii driver to return 0xffff for all request? What this conditiond was intnded for? Probably we can strip this out? For now I have another problem: i'm receiving the aligning exception when kernel is about to start userland: ====================================================================== Fatal kernel mode data abort: 'Alignment Fault 3' trapframe: 0xc422ebbc FSR=00000003, FAR=42203735, spsr=600000d3 r0 =60000093, r1 =c0878220, r2 =c0878220, r3 =00000001 r4 =c0788b40, r5 =00000000, r6 =42203735, r7 =c0878220 r8 =00000001, r9 =c072a08c, r10=c0878220, r11=c422ec28 r12=c422ec08, ssp=c422ec08, slr=c01d04dc, pc =c0099cf4 [thread pid 24 tid 100035 ] Stopped at _thread_lock_flags+0x24: ldr r4, [r6] ====================================================================== >From the backtrace I can see it faults somewhere in the fork request: ====================================================================== _thread_lock_flags() at _thread_lock_flags+0x10 scp=0xc0099ce0 rlv=0xc008e320 (intr_event_schedule_thread+0x98) rsp=0xc422ec2c rfp=0xc422ec4c r7=0x00100000 r6=0x00000000 r5=0x42203735 r4=0xc0788b40 intr_event_schedule_thread() at intr_event_schedule_thread+0x10 scp=0xc008e298 rlv=0xc008f120 (swi_sched+0x38) rsp=0xc422ec50 rfp=0xc422ec5c r5=0xc07b4000 r4=0x00100000 swi_sched() at swi_sched+0x10 scp=0xc008f0f8 rlv=0xc003729c (uart_bus_detach+0x1a4) rsp=0xc422ec60 rfp=0xc422ec70 uart_bus_detach() at uart_bus_detach+0x15c scp=0xc0037254 rlv=0xc0037a10 (uart_bus_ipend+0x2dc) rsp=0xc422ec74 rfp=0xc422ec90 r4=0xc07b4000 uart_bus_ipend() at uart_bus_ipend+0x68 scp=0xc003779c rlv=0xc01cf8ec (arm_handler_execute+0x98) rsp=0xc422ec94 rfp=0xc422ecb8 r7=0xc422ecbc r6=0xc0781080 r5=0x00000000 r4=0xc07b3640 arm_handler_execute() at arm_handler_execute+0x10 scp=0xc01cf864 rlv=0xc01de2d4 (irq_entry+0x98) rsp=0xc422ecbc rfp=0xc422ed40 r10=0x0000000b r8=0x20300000 r7=0x0000001b r6=0xc0303cd0 r5=0xe0000004 r4=0x2026c000 pmap_protect() at pmap_protect+0x10 scp=0xc01d6134 rlv=0xc01b9e24 (vmspace_fork+0x26c) rsp=0xc422ed44 rfp=0xc422ed74 r10=0xc072a000 r9=0xc072a000 r8=0xc072a4ec r7=0xc072a4ec r6=0xc02d9044 r5=0xc02da770 r4=0x00000000 vmspace_fork() at vmspace_fork+0x10 scp=0xc01b9bc8 rlv=0xc008ca50 (fork1+0x1e4) rsp=0xc422ed78 rfp=0xc422edb8 r10=0xc088d580 r9=0xc0878220 r8=0x00000014 r7=0xc0877580 r6=0x00000000 r5=0x00000004 r4=0x00000010 fork1() at fork1+0x10 scp=0xc008c87c rlv=0xc008dae4 (fork+0x24) rsp=0xc422edbc rfp=0xc422edd4 r10=0xc088d580 r9=0xc422ee30 r8=0x00000002 r7=0xc422eeac r6=0x00000000 r5=0xc0878220 r4=0xc0878220 fork() at fork+0x10 scp=0xc008dad0 rlv=0xc01d93cc (swi_handler+0x2d4) rsp=0xc422edd8 rfp=0xc422eea8 r4=0x00000000 swi_handler() at swi_handler+0x10 scp=0xc01d9108 rlv=0xc01ce928 (swi_entry+0x40) rsp=0xc422eeac rfp=0xbfffe868 r10=0x00000000 r9=0x20204285 r8=0x20204274 r7=0x00000002 r6=0x00000004 r5=0x2020e080 r4=0x0002e52c ====================================================================== Is this problem somehow known? Can it be linked with the fact I'm using NFS as a root filesystem? From kdb's ps it can be seen, that 3 userland processes is already running, all sh. Thanks! -- Stanislav Sedov ST4096-RIPE From owner-freebsd-arm@FreeBSD.ORG Sat Dec 15 12:59:19 2007 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 15C1E16A417 for ; Sat, 15 Dec 2007 12:59:19 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id BCCB213C468 for ; Sat, 15 Dec 2007 12:59:18 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from [78.110.49.49] (helo=quasar.ht-systems.ru) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1J3Wbs-0002rV-1J; Sat, 15 Dec 2007 15:59:16 +0300 Received: by quasar.ht-systems.ru (Postfix, from userid 1024) id D984B7D24FC; Sat, 15 Dec 2007 15:59:14 +0300 (MSK) Date: Sat, 15 Dec 2007 15:59:14 +0300 From: Stanislav Sedov To: Rafal Jaworowski Message-ID: <20071215125914.GO17356@dracon.ht-systems.ru> References: <20071213222654.GE17356@dracon.ht-systems.ru> <20071214090128.GM31230@cicely12.cicely.de> <20071214115226.0b2cb7e2@peedub.jennejohn.org> <20071214.062511.74732956.imp@bsdimp.com> <20071214153201.18c4c5ea@peedub.jennejohn.org> <47629E53.30404@semihalf.com> <20071214190825.GG17356@dracon.ht-systems.ru> <20071215105951.GN17356@dracon.ht-systems.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071215105951.GN17356@dracon.ht-systems.ru> Organization: The FreeBSD Project X-Voice: +7 916 849 20 23 X-XMPP: ssedov@jabber.ru X-Yahoo: stanislav_sedov X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-University: MEPhI X-Mailer: carrier-pigeon X-Operating-System: FreeBSD quasar.ht-systems.ru 7.0-BETA2 FreeBSD 7.0-BETA2 Cc: freebsd-arm@freebsd.org Subject: Re: Align exception (was: MMC cards support) 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, 15 Dec 2007 12:59:19 -0000 On Sat, Dec 15, 2007 at 01:59:51PM +0300 Stanislav Sedov mentioned: > > Ok, I've solved my problem with if_ate by hardwiring MAC into the driver and > by commenting out the lines 1007-1008 in if_ates./c: > if (phy != 0) > return (0xffff); > > My phy (rtl8102BL) is on 0x1D address, that forced the mii driver to return 0xffff > for all request? What this conditiond was intnded for? Probably we can strip this out? > > For now I have another problem: i'm receiving the aligning exception when kernel is about > to start userland: > Enabling INVARIANTS give me a lot of unexpected order panics, e.g. vm_phys_free_pages: page 0xc036a4e8 has unexpected order 0 I've no a deep knowledge of VM subsystems, can anybode comment on this? Probably the memory wasn't configured correctly? -- Stanislav Sedov ST4096-RIPE From owner-freebsd-arm@FreeBSD.ORG Sat Dec 15 15:22:46 2007 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 4FC1E16A468 for ; Sat, 15 Dec 2007 15:22:46 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id 0071B13C4F0 for ; Sat, 15 Dec 2007 15:22:45 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from [78.110.49.49] (helo=quasar.ht-systems.ru) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1J3Yqh-0003ze-Ih; Sat, 15 Dec 2007 18:22:43 +0300 Received: by quasar.ht-systems.ru (Postfix, from userid 1024) id 64B5E7D24FB; Sat, 15 Dec 2007 18:22:42 +0300 (MSK) Date: Sat, 15 Dec 2007 18:22:42 +0300 From: Stanislav Sedov To: Rafal Jaworowski Message-ID: <20071215152242.GP17356@dracon.ht-systems.ru> References: <20071213222654.GE17356@dracon.ht-systems.ru> <20071214090128.GM31230@cicely12.cicely.de> <20071214115226.0b2cb7e2@peedub.jennejohn.org> <20071214.062511.74732956.imp@bsdimp.com> <20071214153201.18c4c5ea@peedub.jennejohn.org> <47629E53.30404@semihalf.com> <20071214190825.GG17356@dracon.ht-systems.ru> <20071215105951.GN17356@dracon.ht-systems.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071215105951.GN17356@dracon.ht-systems.ru> Organization: The FreeBSD Project X-Voice: +7 916 849 20 23 X-XMPP: ssedov@jabber.ru X-Yahoo: stanislav_sedov X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-University: MEPhI X-Mailer: carrier-pigeon X-Operating-System: FreeBSD quasar.ht-systems.ru 7.0-BETA2 FreeBSD 7.0-BETA2 Cc: freebsd-arm@freebsd.org Subject: Re: Align exception (was: MMC cards support) 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, 15 Dec 2007 15:22:46 -0000 On Sat, Dec 15, 2007 at 01:59:51PM +0300 Stanislav Sedov mentioned: > ====================================================================== > > Fatal kernel mode data abort: 'Alignment Fault 3' > trapframe: 0xc422ebbc > FSR=00000003, FAR=42203735, spsr=600000d3 > r0 =60000093, r1 =c0878220, r2 =c0878220, r3 =00000001 > r4 =c0788b40, r5 =00000000, r6 =42203735, r7 =c0878220 > r8 =00000001, r9 =c072a08c, r10=c0878220, r11=c422ec28 > r12=c422ec08, ssp=c422ec08, slr=c01d04dc, pc =c0099cf4 > > [thread pid 24 tid 100035 ] > Stopped at _thread_lock_flags+0x24: ldr r4, [r6] > > ====================================================================== > Also the faults tend to be in different places depending on code layout, but the faulting address always the same: 42203735 (r6). Obviously, it's wrong. -- Stanislav Sedov ST4096-RIPE From owner-freebsd-arm@FreeBSD.ORG Sat Dec 15 16:43:52 2007 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 307FC16A419 for ; Sat, 15 Dec 2007 16:43:52 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id D52BF13C45A for ; Sat, 15 Dec 2007 16:43:51 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from [78.110.49.49] (helo=quasar.ht-systems.ru) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1J3a7B-0004bQ-I2; Sat, 15 Dec 2007 19:43:49 +0300 Received: by quasar.ht-systems.ru (Postfix, from userid 1024) id 5F9557D24FB; Sat, 15 Dec 2007 19:43:48 +0300 (MSK) Date: Sat, 15 Dec 2007 19:43:48 +0300 From: Stanislav Sedov To: Rafal Jaworowski Message-ID: <20071215164348.GQ17356@dracon.ht-systems.ru> References: <20071213222654.GE17356@dracon.ht-systems.ru> <20071214090128.GM31230@cicely12.cicely.de> <20071214115226.0b2cb7e2@peedub.jennejohn.org> <20071214.062511.74732956.imp@bsdimp.com> <20071214153201.18c4c5ea@peedub.jennejohn.org> <47629E53.30404@semihalf.com> <20071214190825.GG17356@dracon.ht-systems.ru> <20071215105951.GN17356@dracon.ht-systems.ru> <20071215152242.GP17356@dracon.ht-systems.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071215152242.GP17356@dracon.ht-systems.ru> Organization: The FreeBSD Project X-Voice: +7 916 849 20 23 X-XMPP: ssedov@jabber.ru X-Yahoo: stanislav_sedov X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-University: MEPhI X-Mailer: carrier-pigeon X-Operating-System: FreeBSD quasar.ht-systems.ru 7.0-BETA2 FreeBSD 7.0-BETA2 Cc: freebsd-arm@freebsd.org Subject: Re: Align exception (was: MMC cards support) 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, 15 Dec 2007 16:43:52 -0000 On Sat, Dec 15, 2007 at 06:22:42PM +0300 Stanislav Sedov mentioned: > > Also the faults tend to be in different places depending on code layout, > but the faulting address always the same: 42203735 (r6). Obviously, it's > wrong. > This address always comes from it->it_thread. and should obviously reflect thread td structure: td = it->it_thread; c00ee064: e51b301c ldr r3, [fp, #-28] c00ee068: e5933004 ldr r3, [r3, #4] c00ee06c: e50b3018 str r3, [fp, #-24] p = td->td_proc; c00ee070: e51b3018 ldr r3, [fp, #-24] c00ee074: e5933004 ldr r3, [r3, #4] However the contents of td (r3) is always 42203735 when it's loaded from it->it_thread. It looks like uart does something awful with the interrupt thread pointer. -- Stanislav Sedov ST4096-RIPE From owner-freebsd-arm@FreeBSD.ORG Sat Dec 15 18:56:41 2007 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 656DE16A419; Sat, 15 Dec 2007 18:56:41 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id E130113C45A; Sat, 15 Dec 2007 18:56:40 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id lBFIuc0r013700; Sat, 15 Dec 2007 19:56:39 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id lBFIuYo9020484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Dec 2007 19:56:34 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id lBFIuXYm049645; Sat, 15 Dec 2007 19:56:33 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id lBFIuXas049644; Sat, 15 Dec 2007 19:56:33 +0100 (CET) (envelope-from ticso) Date: Sat, 15 Dec 2007 19:56:33 +0100 From: Bernd Walter To: Stanislav Sedov Message-ID: <20071215185633.GC48684@cicely12.cicely.de> References: <20071213222654.GE17356@dracon.ht-systems.ru> <20071214090128.GM31230@cicely12.cicely.de> <20071214115226.0b2cb7e2@peedub.jennejohn.org> <20071214.062511.74732956.imp@bsdimp.com> <20071214153201.18c4c5ea@peedub.jennejohn.org> <47629E53.30404@semihalf.com> <20071214190825.GG17356@dracon.ht-systems.ru> <20071215105951.GN17356@dracon.ht-systems.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071215105951.GN17356@dracon.ht-systems.ru> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.136, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: Align exception (was: MMC cards support) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 18:56:41 -0000 On Sat, Dec 15, 2007 at 01:59:51PM +0300, Stanislav Sedov wrote: > On Fri, Dec 14, 2007 at 10:08:25PM +0300 Stanislav Sedov mentioned: > > > > Well, I downloaded the entire kernel via tftp, so the controller was probably > > configured correctly. Probably, u-boot resets it after transfer (have not checked > > this yet). > > > > Ok, I've solved my problem with if_ate by hardwiring MAC into the driver and > by commenting out the lines 1007-1008 in if_ates./c: > if (phy != 0) > return (0xffff); > > My phy (rtl8102BL) is on 0x1D address, that forced the mii driver to return 0xffff > for all request? What this conditiond was intnded for? Probably we can strip this out? I thought it was already out - I needed it myself for the switch I use on my boards, which uses multiple phy addresses for al his registers, but maybe it never went out of perforce. It had historic reasons and Warner already said that it has no reason to be there right now. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-arm@FreeBSD.ORG Sat Dec 15 21:10:19 2007 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 98C3216A418 for ; Sat, 15 Dec 2007 21:10:19 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from smtp.ht-systems.ru (mr0.ht-systems.ru [78.110.50.55]) by mx1.freebsd.org (Postfix) with ESMTP id 280C613C43E for ; Sat, 15 Dec 2007 21:10:18 +0000 (UTC) (envelope-from stas@ht-systems.ru) Received: from [78.110.49.49] (helo=quasar.ht-systems.ru) by smtp.ht-systems.ru with esmtpa (Exim 4.62) (envelope-from ) id 1J3eH1-0006eY-So; Sun, 16 Dec 2007 00:10:15 +0300 Received: by quasar.ht-systems.ru (Postfix, from userid 1024) id CE40A7D24FB; Sun, 16 Dec 2007 00:10:14 +0300 (MSK) Date: Sun, 16 Dec 2007 00:10:14 +0300 From: Stanislav Sedov To: Rafal Jaworowski Message-ID: <20071215211014.GA27843@dracon.ht-systems.ru> References: <20071213222654.GE17356@dracon.ht-systems.ru> <20071214090128.GM31230@cicely12.cicely.de> <20071214115226.0b2cb7e2@peedub.jennejohn.org> <20071214.062511.74732956.imp@bsdimp.com> <20071214153201.18c4c5ea@peedub.jennejohn.org> <47629E53.30404@semihalf.com> <20071214190825.GG17356@dracon.ht-systems.ru> <20071215105951.GN17356@dracon.ht-systems.ru> <20071215152242.GP17356@dracon.ht-systems.ru> <20071215164348.GQ17356@dracon.ht-systems.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071215164348.GQ17356@dracon.ht-systems.ru> Organization: The FreeBSD Project X-Voice: +7 916 849 20 23 X-XMPP: ssedov@jabber.ru X-Yahoo: stanislav_sedov X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-University: MEPhI X-Mailer: carrier-pigeon X-Operating-System: FreeBSD quasar.ht-systems.ru 7.0-BETA2 FreeBSD 7.0-BETA2 Cc: freebsd-arm@freebsd.org Subject: Re: Align exception (was: MMC cards support) 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, 15 Dec 2007 21:10:19 -0000 On Sat, Dec 15, 2007 at 07:43:48PM +0300 Stanislav Sedov mentioned: > This address always comes from it->it_thread. and should obviously > reflect thread td structure: > > td = it->it_thread; > c00ee064: e51b301c ldr r3, [fp, #-28] > c00ee068: e5933004 ldr r3, [r3, #4] > c00ee06c: e50b3018 str r3, [fp, #-24] > p = td->td_proc; > c00ee070: e51b3018 ldr r3, [fp, #-24] > c00ee074: e5933004 ldr r3, [r3, #4] > > However the contents of td (r3) is always 42203735 when > it's loaded from it->it_thread. It looks like uart does > something awful with the interrupt thread pointer. > It's even better, when ithread_create initializes structure for intr_thread, it does this correctly for all interrupts, however when intr_event_schedule_thread began to work on the uart0 interrupt event the intr_thread *it structure contents is entirely broken, though the address itself is correct. Very suspicios... Maybe I'm doing something wrong? What I did - I've build the kernel using usual buildworld/buildkernel sequence, loaded the resulting kernel image (I've tried both kernel and kernel.bin) using u-boot to the KERNPHYSADDR and jumped there. Though it seems to mount NFS correctly, so the memory should be ok in my case. -- Stanislav Sedov ST4096-RIPE From owner-freebsd-arm@FreeBSD.ORG Sat Dec 15 21:40:14 2007 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 2249E16A421; Sat, 15 Dec 2007 21:40:14 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id A7DCE13C442; Sat, 15 Dec 2007 21:40:13 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id lBFLeB1n020205; Sat, 15 Dec 2007 22:40:11 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id lBFLe6jL021725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Dec 2007 22:40:06 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id lBFLe6O9050000; Sat, 15 Dec 2007 22:40:06 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id lBFLe6q9049999; Sat, 15 Dec 2007 22:40:06 +0100 (CET) (envelope-from ticso) Date: Sat, 15 Dec 2007 22:40:05 +0100 From: Bernd Walter To: Stanislav Sedov Message-ID: <20071215214005.GE48684@cicely12.cicely.de> References: <20071214090128.GM31230@cicely12.cicely.de> <20071214115226.0b2cb7e2@peedub.jennejohn.org> <20071214.062511.74732956.imp@bsdimp.com> <20071214153201.18c4c5ea@peedub.jennejohn.org> <47629E53.30404@semihalf.com> <20071214190825.GG17356@dracon.ht-systems.ru> <20071215105951.GN17356@dracon.ht-systems.ru> <20071215152242.GP17356@dracon.ht-systems.ru> <20071215164348.GQ17356@dracon.ht-systems.ru> <20071215211014.GA27843@dracon.ht-systems.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071215211014.GA27843@dracon.ht-systems.ru> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.133, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: Align exception (was: MMC cards support) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 21:40:14 -0000 On Sun, Dec 16, 2007 at 12:10:14AM +0300, Stanislav Sedov wrote: > On Sat, Dec 15, 2007 at 07:43:48PM +0300 Stanislav Sedov mentioned: > > This address always comes from it->it_thread. and should obviously > > reflect thread td structure: > > > > td = it->it_thread; > > c00ee064: e51b301c ldr r3, [fp, #-28] > > c00ee068: e5933004 ldr r3, [r3, #4] > > c00ee06c: e50b3018 str r3, [fp, #-24] > > p = td->td_proc; > > c00ee070: e51b3018 ldr r3, [fp, #-24] > > c00ee074: e5933004 ldr r3, [r3, #4] > > > > However the contents of td (r3) is always 42203735 when > > it's loaded from it->it_thread. It looks like uart does > > something awful with the interrupt thread pointer. > > > > It's even better, when ithread_create initializes > structure for intr_thread, it does this correctly for all > interrupts, however when intr_event_schedule_thread began to > work on the uart0 interrupt event the intr_thread *it > structure contents is entirely broken, though the address > itself is correct. Very suspicios... > > Maybe I'm doing something wrong? What I did - I've build > the kernel using usual buildworld/buildkernel sequence, > loaded the resulting kernel image (I've tried both > kernel and kernel.bin) using u-boot to the KERNPHYSADDR > and jumped there. Though it seems to mount NFS correctly, > so the memory should be ok in my case. I'm not 100% sure if it is the same thing - would have to search in old mails. We've seen a something like this with specific kernel on RM9200 systems. I'm not aware of other ARM systems, so it's likely a problem in an Atmel driver. It comes and goes with adding/removing unrelated options. I personally use spi support, which I don't need, to toggle the symptom if this happens to me. If you can find the real cause of this many people would be very happy. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de