From owner-freebsd-arm@FreeBSD.ORG Mon Aug 9 11:06:51 2010 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 AAD681065678 for ; Mon, 9 Aug 2010 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 993048FC1F for ; Mon, 9 Aug 2010 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o79B6paP048945 for ; Mon, 9 Aug 2010 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o79B6pU6048943 for freebsd-arm@FreeBSD.org; Mon, 9 Aug 2010 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Aug 2010 11:06:51 GMT Message-Id: <201008091106.o79B6pU6048943@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, 09 Aug 2010 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/148474 arm MMC timeout too short durring enumeration of cards. o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 3 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Aug 9 12:54:31 2010 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CB251065674; Mon, 9 Aug 2010 12:54:31 +0000 (UTC) (envelope-from arved@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 325B68FC1D; Mon, 9 Aug 2010 12:54:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o79CsVOK062395; Mon, 9 Aug 2010 12:54:31 GMT (envelope-from arved@freefall.freebsd.org) Received: (from arved@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o79CsUTx062391; Mon, 9 Aug 2010 12:54:30 GMT (envelope-from arved) Date: Mon, 9 Aug 2010 12:54:30 GMT Message-Id: <201008091254.o79CsUTx062391@freefall.freebsd.org> To: yds@CoolRat.org, root@cooltrainer.org, arved@FreeBSD.org, freebsd-ports-bugs@FreeBSD.org, freebsd-arm@FreeBSD.org From: arved@FreeBSD.org Cc: Subject: Re: kern/149288: mail/dovecot causes panic during configure on Sheevaplug (ARM) 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, 09 Aug 2010 12:54:31 -0000 Synopsis: mail/dovecot causes panic during configure on Sheevaplug (ARM) State-Changed-From-To: feedback->open State-Changed-By: arved State-Changed-When: Mon Aug 9 12:53:23 UTC 2010 State-Changed-Why: A Kernel panic sounds more like a kernel bug, over to freebsd-arm for evaluation. Responsible-Changed-From-To: freebsd-ports-bugs->freebsd-arm Responsible-Changed-By: arved Responsible-Changed-When: Mon Aug 9 12:53:23 UTC 2010 Responsible-Changed-Why: A Kernel panic sounds more like a kernel bug, over to freebsd-arm for evaluation. http://www.freebsd.org/cgi/query-pr.cgi?pr=149288 From owner-freebsd-arm@FreeBSD.ORG Mon Aug 9 22:10:07 2010 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 368951065672 for ; Mon, 9 Aug 2010 22:10:07 +0000 (UTC) (envelope-from ben.r.gray@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id BE0F78FC16 for ; Mon, 9 Aug 2010 22:10:06 +0000 (UTC) Received: by wyj26 with SMTP id 26so13155574wyj.13 for ; Mon, 09 Aug 2010 15:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=eKbCQS7GMBqjABnD06jqATNUjqiZNO5WjA9AG8eTCT8=; b=X0OYfCx1OASZE9RmsnohqroZQvs+Zz7gHFj5p493i1HUzwB2F53pHjQo98Syd8VLx6 P60zzUdlZwE5eRoXxqvGgSWt89dlB0SkPwQApBpLTDRw0cDw6pyY/gCqoARw0+yszlnn jrIKBom8O6+EqjyHGscFF1fsCOrBpKHgY5rYI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=tk/sJ8nSk/2B4jnt7K/zENu/yIHaV1wH//jlaGSe/LnnoVwI7AVtd2GGyx5vF86346 j34lFzYiSjRRvREcbtQeV/KVfWJ9ggkXpwDJPparhilV7WI6tW99XW0Gx3GZfgG9l0M1 PYb9AcdSqzv1GinVdxc00lZpOM63kc5PbjJTo= Received: by 10.227.134.18 with SMTP id h18mr14213306wbt.94.1281390139996; Mon, 09 Aug 2010 14:42:19 -0700 (PDT) Received: from bens-mbp.config (78-86-169-240.dsl.cnl.uk.net [78.86.169.240]) by mx.google.com with ESMTPS id h3sm4781881wbb.3.2010.08.09.14.42.18 (version=SSLv3 cipher=RC4-MD5); Mon, 09 Aug 2010 14:42:19 -0700 (PDT) Message-ID: <4C607639.9050506@gmail.com> Date: Mon, 09 Aug 2010 22:42:17 +0100 From: Ben Gray User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: OMAP3530 - Beagleboard and I2C problems 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, 09 Aug 2010 22:10:07 -0000 Hi, I've been working on a port of FreeBSD to Texas Instruments OMAP3530 for a while now. I have the basic drivers, Clocks, MMC, DMA, GPIO's, etc. The kernel is coming up, however it crashes with a seg fault when starting the init process, this is probably caused by the hacks I had to put in the pmap code to get it to work with ARMv7 MMU's, but that's an email for another day. The problem I'm currently having is with the I2C code and it is perhaps highlighting a more fundamental problem with my port so far. Currently I have an 'omap3' bus device, which is the parent for all the other peripheral drivers (I2C, MMC, DMA, etc). These child bus drivers are added during the attach call of the parent, but at that time IRQ's are not enabled and nor is the system clocking code. So the problem I have is that during the attach phase of the I2C device driver I want to be able to send messages over the I2C bus, but my bus driver doesn't work because IRQ's are still disabled. So what is the correct solution for this? How do I delay device initialisation to after this? Is there documentation anyone can point me at that describes the startup phases? or alternatively examples in the existing code base? I've looked at the current ARM ports, and on the face of it they seem to suffer the same problem. In case anyone is interested some of my work to date is available on googlecode here . At the moment it can't just be pulled into the tree, partially because it's missing the patches needed for the pmap code, but mostly because large parts of it don't work properly :-) And thanks to to the author of the freebsd-bgb googlecode project, without that I probably wouldn't have got started. Cheers, Ben Gray From owner-freebsd-arm@FreeBSD.ORG Tue Aug 10 09:05:06 2010 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 732C71065675 for ; Tue, 10 Aug 2010 09:05:06 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:50:40:63ff:feea:93a]) by mx1.freebsd.org (Postfix) with ESMTP id 1328D8FC1D for ; Tue, 10 Aug 2010 09:05:05 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.2/8.14.3) with ESMTP id o7A95XqL056986; Tue, 10 Aug 2010 11:05:33 +0200 (CEST) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.2/8.14.3/Submit) id o7A95Xop056985; Tue, 10 Aug 2010 11:05:33 +0200 (CEST) (envelope-from mlfbsd) Date: Tue, 10 Aug 2010 11:05:33 +0200 From: Olivier Houchard To: Ben Gray Message-ID: <20100810090533.GA56784@ci0.org> References: <4C607639.9050506@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C607639.9050506@gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arm@freebsd.org Subject: Re: OMAP3530 - Beagleboard and I2C problems 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, 10 Aug 2010 09:05:06 -0000 On Mon, Aug 09, 2010 at 10:42:17PM +0100, Ben Gray wrote: > Hi, > Hi Ben, > I've been working on a port of FreeBSD to Texas Instruments OMAP3530 > for a while now. I have the basic drivers, Clocks, MMC, DMA, GPIO's, > etc. The kernel is coming up, however it crashes with a seg fault when > starting the init process, this is probably caused by the hacks I had to > put in the pmap code to get it to work with ARMv7 MMU's, but that's an > email for another day. > That's great to hear ! How hackish is your work ? There's an ongoing work to support armv6/armv7, so maybe it's best to avoid duplicating efforts ? > The problem I'm currently having is with the I2C code and it is > perhaps highlighting a more fundamental problem with my port so far. > Currently I have an 'omap3' bus device, which is the parent for all the > other peripheral drivers (I2C, MMC, DMA, etc). These child bus drivers > are added during the attach call of the parent, but at that time IRQ's > are not enabled and nor is the system clocking code. So the problem I > have is that during the attach phase of the I2C device driver I want to > be able to send messages over the I2C bus, but my bus driver doesn't > work because IRQ's are still disabled. So what is the correct solution > for this? How do I delay device initialisation to after this? > If you need to do stuff once IRQ are enabled, you may try to use config_intrhook_establish(), that should do exactly what you need. Regards, Olivier From owner-freebsd-arm@FreeBSD.ORG Tue Aug 10 13:00:53 2010 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 37DE11065670 for ; Tue, 10 Aug 2010 13:00:53 +0000 (UTC) (envelope-from gballet@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id E3D468FC2B for ; Tue, 10 Aug 2010 13:00:52 +0000 (UTC) Received: by vws7 with SMTP id 7so9101990vws.13 for ; Tue, 10 Aug 2010 06:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=/+0+wP9bzitpLF1wTD5V2b25TO7klSAgkJrFRoO5xXQ=; b=rj3p8N4eKuSt3uAs/vSEV8GUVvkue26nDeoneKdsWGQI7ngv0rWUQJbdIRUk/GuHaj TpfZ8Ah6DQOoiUaauiHUy3aS+xG+TowAdghdx82hHZjS4rYLQ3L32gaGXYaDYLhunZSB A2VvdD5XTB7I0xCeh0bGyU3nxWi9faR24T/5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=XEMvFvHP64L3QucsDUP+DMQP2AbvMOXByA+ByQA/fA8Spxw4ofOmYVUJRi05e9XImB uVik+EQYTSpS4pMo7xjFEoiFHIE83CeitE49+80W7wjnhXgzMSYwszRfGSTTLpWrmwHp MR9bz5tyxOr42DguramolE4W/zQ3igTJbcx5s= MIME-Version: 1.0 Received: by 10.220.61.140 with SMTP id t12mr10446584vch.194.1281443817126; Tue, 10 Aug 2010 05:36:57 -0700 (PDT) Received: by 10.220.108.69 with HTTP; Tue, 10 Aug 2010 05:36:57 -0700 (PDT) Date: Tue, 10 Aug 2010 14:36:57 +0200 Message-ID: From: Guillaume Ballet To: freebsd-arm@freebsd.org, ben.r.gray@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: OMAP3530 - Beagleboard and I2C problems 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, 10 Aug 2010 13:00:53 -0000 Hey Ben, I have been working for a port myself, at http://code.google.com/p/beagleboard-freebsd/ Haven't had the time to work on it lately, though. > Message: 2 > Date: Mon, 09 Aug 2010 22:42:17 +0100 > From: Ben Gray > Subject: OMAP3530 - Beagleboard and I2C problems > To: freebsd-arm@freebsd.org > Message-ID: <4C607639.9050506@gmail.com> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > Hi, > > =A0 =A0I've been working on a port of FreeBSD to Texas Instruments OMAP35= 30 > for a while now. I have the basic drivers, Clocks, MMC, DMA, GPIO's, > etc. The kernel is coming up, however it crashes with a seg fault when > starting the init process, this is probably caused by the hacks I had to > put in the pmap code to get it to work with ARMv7 MMU's, but that's an > email for another day. > > =A0 =A0The problem I'm currently having is with the I2C code and it is > perhaps highlighting a more fundamental problem with my port so far. > Currently I have an 'omap3' bus device, which is the parent for all the > other peripheral drivers (I2C, MMC, DMA, etc). =A0These child bus drivers > are added during the attach call of the parent, but at that time IRQ's > are not enabled and nor is the system clocking code. So the problem I > have is that during the attach phase of the I2C device driver I want to > be able to send messages over the I2C bus, but my bus driver doesn't > work because IRQ's are still disabled. =A0So what is the correct solution > for this? =A0How do I delay device initialisation to after this? I had some basic intc controller that I tested with the timer. I also have an even more basic interrupt allocation support in the form of a bus. I also have some changes for the pmap you might be interested in. I can check at what I have tonight that you don't have and send it to you. I will help you with the merge of what you don't already have. > > =A0 =A0Is there documentation anyone can point me at that describes the > startup phases? or alternatively examples in the existing code base? > I've looked at the current ARM ports, and on the face of it they seem to > suffer the same problem. > I only took a quick look at your code (once again, will take a closer look at it tonight), and I didn't find the part where you are inserting the devices. As far as I recall (possibly incorrectly), you can specify in which order you insert devices. What I did was to insert the intc device first, so that it would be ready when inserting other drivers. > > =A0 =A0In case anyone is interested some of my work to date is available = on > googlecode here . At the > moment it can't just be pulled into the tree, partially because it's > missing the patches needed for the pmap code, but mostly because large > parts of it don't work properly :-) I'll try it with my own pmap changes :) > > =A0 =A0And thanks to to the author of the freebsd-bgb googlecode project, > without that I probably wouldn't have got started. You are welcome. I'm still interested in the port even if I have less time to work on it for the moment - still I'm available for doing some work, though :) Guillaume From owner-freebsd-arm@FreeBSD.ORG Wed Aug 11 09:40:00 2010 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 7A0691065672 for ; Wed, 11 Aug 2010 09:40:00 +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 224558FC19 for ; Wed, 11 Aug 2010 09:39:59 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id B9072C3BB5; Wed, 11 Aug 2010 11:39:58 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id tDpL0CerHJTA; Wed, 11 Aug 2010 11:39:58 +0200 (CEST) Received: from [10.0.0.79] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 14304C3BAF; Wed, 11 Aug 2010 11:39:58 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <20100810090533.GA56784@ci0.org> Date: Wed, 11 Aug 2010 11:39:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <82A49B7C-23F2-400C-B726-2FF13FD6D282@semihalf.com> References: <4C607639.9050506@gmail.com> <20100810090533.GA56784@ci0.org> To: Olivier Houchard X-Mailer: Apple Mail (2.1081) Cc: "freebsd-arm@FreeBSD.org" Subject: ARMv6 support -- was: OMAP3530 - Beagleboard and I2C problems 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, 11 Aug 2010 09:40:00 -0000 On 2010-08-10, at 11:05, Olivier Houchard wrote: > On Mon, Aug 09, 2010 at 10:42:17PM +0100, Ben Gray wrote: >> Hi, >>=20 >=20 > Hi Ben, >=20 >> I've been working on a port of FreeBSD to Texas Instruments = OMAP3530=20 >> for a while now. I have the basic drivers, Clocks, MMC, DMA, GPIO's,=20= >> etc. The kernel is coming up, however it crashes with a seg fault = when=20 >> starting the init process, this is probably caused by the hacks I had = to=20 >> put in the pmap code to get it to work with ARMv7 MMU's, but that's = an=20 >> email for another day. >>=20 >=20 > That's great to hear ! > How hackish is your work ? There's an ongoing work to support = armv6/armv7, so > maybe it's best to avoid duplicating efforts ? Olivier, As we spoke, I've put a diff of our ARMv6 work to freefall, see: = http://people.freebsd.org/~raj/patches/arm/dove_v6.diff This is against HEAD 2009.08.03, and is part of support for the = following hardware: - CPU core: Marvell Sheeva2 (88SV581x), ARMv6 - SOC: 88F6781 (Armada 500 alias Dove) The DB-88F6781 kernel won't rather build, as there are a couple of = platform-specific bits missing (GPIO rework, PM etc.), but the common = ARM code should apply to the above baseline and give you an idea what = kind of changes and adaptations were introduced in order to get this = working. It's an initial attempt, but working stable. The main areas are = pmap / busdma rework for v6; in order to have a clear situation during = development we have decided to cut off from the legacy v5 files (and = come up with separate -v6 derivatives), although we could converge back = to a single file approach if this proves better eventually. Rafal From owner-freebsd-arm@FreeBSD.ORG Wed Aug 11 10:17:31 2010 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 5C8581065679 for ; Wed, 11 Aug 2010 10:17: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 E1A0C8FC0A for ; Wed, 11 Aug 2010 10:17:30 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 9DE04C3BB5; Wed, 11 Aug 2010 12:17:29 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id 2DcVc3KT7lEB; Wed, 11 Aug 2010 12:17:29 +0200 (CEST) Received: from [10.0.0.79] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 07B75C3BAF; Wed, 11 Aug 2010 12:17:28 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <201008072144.00002.hselasky@c2i.net> Date: Wed, 11 Aug 2010 12:17:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <114332B9-A38B-471A-B4FE-F6E210F58233@semihalf.com> References: <201008072144.00002.hselasky@c2i.net> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1081) Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [BETA testing] USB 3.0 Super Speed support in FreeBSD 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, 11 Aug 2010 10:17:31 -0000 On 2010-08-07, at 21:43, Hans Petter Selasky wrote: > During the last two weeks I've been working hard to get USB 3.0 = support added=20 > to the FreeBSD 8+ USB stack. There are a couple of issues left, but = right now=20 > the code is in a state were enumeration of USB devices is possible and = there=20 > are no dirty hacks :-) >=20 > The XHCI chip, which is the PCI interface for USB 3.0, is a = replacement for=20 > OHCI/UHCI/EHCI and can also drive USB Super Speed (4.8 Gbps). I expect = there=20 > to be a througput and performance increase when switching over to the = XHCI=20 > interface also for 2.0 compatible devices, because it has a better = data=20 > queuing mechanism. Nice work! What exactly is the USB3 controller chip you're working with? Rafal From owner-freebsd-arm@FreeBSD.ORG Wed Aug 11 10:18:34 2010 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 8BFC01065670 for ; Wed, 11 Aug 2010 10:18:34 +0000 (UTC) (envelope-from ben.r.gray@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1B9628FC14 for ; Wed, 11 Aug 2010 10:18:33 +0000 (UTC) Received: by wyj26 with SMTP id 26so15195713wyj.13 for ; Wed, 11 Aug 2010 03:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=HgHM2dCWaXmvyC8kxEvXCyXPkyiszk06Wri14qzbAUI=; b=sNkAM/sbUNigG+OgyOXvkj9Au2cxcEemPmR2e3dQQfD4cwXFX1maW+4SrEF6wihFEq 1a/Rp6x2IapkeI8bGWrMJDj1/gJSlrQBijRc5zxwomF4bqMFDXF5cpiVe8CWu5Rl1YyV qvKXdWNyQcOpCBhsrNmjIZCLH8bJo4djW4QRc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=BpUYeIbEwbOQ1wZm7MbzmfpnAsawHaFVunGNi3hKoxf0TygSvyX2pbAOdYz5Rpbg7Y EfkcAiYPu9gKWJQrIGOwyJhSOfd6fH0rm2vHwa7NjB1ugXwU009D3mSaeK2uU8yCJDjf VdYRuj6kRruCWn7V6QCIp6HBmOEQnvPaQYLgs= Received: by 10.227.141.136 with SMTP id m8mr16031110wbu.227.1281521913019; Wed, 11 Aug 2010 03:18:33 -0700 (PDT) Received: from Bens-MBP.local (ip-80-238-8-128.bskyb.com [80.238.8.128]) by mx.google.com with ESMTPS id h37sm3963366wej.23.2010.08.11.03.18.31 (version=SSLv3 cipher=RC4-MD5); Wed, 11 Aug 2010 03:18:32 -0700 (PDT) Message-ID: <4C6278F7.3020208@gmail.com> Date: Wed, 11 Aug 2010 11:18:31 +0100 From: Ben Gray User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Guillaume Ballet References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Some of my files for the FreeBSD port 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, 11 Aug 2010 10:18:34 -0000 Hi Guillaume, Thanks very for much for your pmap changes, mine were very much hacks that I patched in as I came across problems. Also the code on google project page is a couple of weeks out of date, so I'll sync that up with my local copy tonight. Not too much has changed but I've written the following addition drivers which are untested: - I2C bus driver - The outlines of a TPS65950 I2C device driver - System control module (SCM) driver for pad configuration - USB EHCI driver I'll endeavour also to add some stuff to the wiki about how I boot via uboot. Lastly I'm mounting the rootfs from the MMC card, the mount seems to work fine and it can find the init file in the path. So the MMC driver looks like it's working ok, but it's certainly possible that the seg fault I'm seeing in init could be caused by some bug in reading the actual init file binary. I'll drop you another email when I think everything is up on googlecode. Cheers, Ben. > Hello, > > I have looked a bit more at the code you published on google code. I > didn't have much time tonight, so I looked at your bus code, and your > interrupt code. I see you're not creating a device for the interrupt > controller, although I don't think it's the cause for your ordering > problem anymore. Still, I enclosed the file I had written - it's a bit > different from yours and maybe you'll find something interesting in > it. I'm also sending you the pmap.c that I used, maybe you'll find > some difference that could explain why you can't get past init. > > I have more files, but you seem to be much more ahead in the support > than I am. I'll compare it to your files and see if I can bring > something. > > Also, could you please send me what I need to test your code on my > side? I'd like to see if I can help more with the init bug. I was > using the rescue init/shell in a ramdisk, but if you managed to get > MMC then it might be possible to run gdb from the init prompt! I'm > really happy that you work on it too, so that support for the board > can come up faster! I'm also working with other omap3530 boards at > work, like the Gumstix overo, so I can test it on different platforms. > > Cheers, > Guillaume > From owner-freebsd-arm@FreeBSD.ORG Wed Aug 11 10:33:20 2010 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 6279C106566C; Wed, 11 Aug 2010 10:33:20 +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 68B6D8FC16; Wed, 11 Aug 2010 10:33:19 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=yOygpZNQNLwA:10 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=QyXUC8HyAAAA:8 a=d772FYgZOPOSp99LnUYA:9 a=E3rtEOixA4WkBN5fiAWaCR6cSoYA:4 a=wPNLvfGTeEIA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe13.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 1032377939; Wed, 11 Aug 2010 12:33:17 +0200 From: Hans Petter Selasky To: Rafal Jaworowski Date: Wed, 11 Aug 2010 12:29:41 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <201008072144.00002.hselasky@c2i.net> <114332B9-A38B-471A-B4FE-F6E210F58233@semihalf.com> In-Reply-To: <114332B9-A38B-471A-B4FE-F6E210F58233@semihalf.com> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008111229.41469.hselasky@c2i.net> Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [BETA testing] USB 3.0 Super Speed support in FreeBSD 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, 11 Aug 2010 10:33:20 -0000 On Wednesday 11 August 2010 12:17:28 Rafal Jaworowski wrote: > On 2010-08-07, at 21:43, Hans Petter Selasky wrote: > > During the last two weeks I've been working hard to get USB 3.0 support > > added to the FreeBSD 8+ USB stack. There are a couple of issues left, > > but right now the code is in a state were enumeration of USB devices is > > possible and there are no dirty hacks :-) > > > > The XHCI chip, which is the PCI interface for USB 3.0, is a replacement > > for OHCI/UHCI/EHCI and can also drive USB Super Speed (4.8 Gbps). I > > expect there to be a througput and performance increase when switching > > over to the XHCI interface also for 2.0 compatible devices, because it > > has a better data queuing mechanism. > > Nice work! What exactly is the USB3 controller chip you're working with? > Hi, It is this one: http://www.intel.com/technology/usb/download/xHCI_Specification_for_USB.pdf I currently have a PCI express card from some vendor, which implements support for the XHCI spec. and I've seen good results so far. I would very much like to test the XHCI driver on ARM, if any chips exist yet which has the XHCI included in the ASIC. --HPS From owner-freebsd-arm@FreeBSD.ORG Wed Aug 11 10:49:54 2010 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 AE2791065670 for ; Wed, 11 Aug 2010 10:49:54 +0000 (UTC) (envelope-from ben.r.gray@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 413E88FC0C for ; Wed, 11 Aug 2010 10:49:53 +0000 (UTC) Received: by wwf26 with SMTP id 26so4867365wwf.1 for ; Wed, 11 Aug 2010 03:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=I5vfXin7z4aYglij5sKcA7ArwKjcBV8ulkAtTDTmKew=; b=O5bNNt9fzbKyr8lRSuYufhjhnpw3UhYYqx2N2QexnY4bEgjj4x1vg4xu0gTpiwR/wo 6d5LHwDrWlEMxWTbN3aJUYOx93Ik4CbjUP8kEkVlrpUXqTKVoc/lOpkTfzemUs9U5UEi 8SdZxYe3ZZWlRz2l5b964hVXiNHLsb7w2rrkY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=TvWTB3VZ9jTkUvnSTtCuZ+YtWDEwiTUzHTP+EftnFM0WHgN4NZAoI3VseD3LSpZNiK s9JhmkSMDKokPXBL1vKVpMeJd2GwjqRJy4Q20KbSCvBxK0XA6hZK+kaFRuG1EAo2I4Ia 0izpM4IfHQX1MFGDOH34E1gu5nP8lfeFlTSPY= Received: by 10.216.48.146 with SMTP id v18mr16541293web.56.1281523793130; Wed, 11 Aug 2010 03:49:53 -0700 (PDT) Received: from Bens-MBP.local (ip-80-238-8-128.bskyb.com [80.238.8.128]) by mx.google.com with ESMTPS id n40sm3982069weq.29.2010.08.11.03.49.51 (version=SSLv3 cipher=RC4-MD5); Wed, 11 Aug 2010 03:49:52 -0700 (PDT) Message-ID: <4C62804F.5080007@gmail.com> Date: Wed, 11 Aug 2010 11:49:51 +0100 From: Ben Gray User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Olivier Houchard References: <4C607639.9050506@gmail.com> <20100810090533.GA56784@ci0.org> In-Reply-To: <20100810090533.GA56784@ci0.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: OMAP3530 - Beagleboard and I2C problems 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, 11 Aug 2010 10:49:54 -0000 Thanks Olivier, PSB > On Mon, Aug 09, 2010 at 10:42:17PM +0100, Ben Gray wrote: > >> Hi, >> >> > > Hi Ben, > > >> I've been working on a port of FreeBSD to Texas Instruments OMAP3530 >> for a while now. I have the basic drivers, Clocks, MMC, DMA, GPIO's, >> etc. The kernel is coming up, however it crashes with a seg fault when >> starting the init process, this is probably caused by the hacks I had to >> put in the pmap code to get it to work with ARMv7 MMU's, but that's an >> email for another day. >> >> > > That's great to hear ! > How hackish is your work ? There's an ongoing work to support armv6/armv7, so > maybe it's best to avoid duplicating efforts ? > Well it might not be to much of a hack, but I'm reasonably new to ARMv7 and very new to FreeBSD so some of my assumptions might not be correct. I noticed Rafal Jaworowski has posted a link to some ARMv6 code so I'll take a look at that as well. I'll post my changes on googlecode shortly, once I tidy it up and remove the extra verbose debugging. > >> The problem I'm currently having is with the I2C code and it is >> perhaps highlighting a more fundamental problem with my port so far. >> Currently I have an 'omap3' bus device, which is the parent for all the >> other peripheral drivers (I2C, MMC, DMA, etc). These child bus drivers >> are added during the attach call of the parent, but at that time IRQ's >> are not enabled and nor is the system clocking code. So the problem I >> have is that during the attach phase of the I2C device driver I want to >> be able to send messages over the I2C bus, but my bus driver doesn't >> work because IRQ's are still disabled. So what is the correct solution >> for this? How do I delay device initialisation to after this? >> >> > > If you need to do stuff once IRQ are enabled, you may try to use > config_intrhook_establish(), that should do exactly what you need. > Thanks for this, it looks exactly like what I want :-) > Regards, > > Olivier > From owner-freebsd-arm@FreeBSD.ORG Wed Aug 11 11:40:18 2010 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 5AE50106567A for ; Wed, 11 Aug 2010 11:40:18 +0000 (UTC) (envelope-from Matthias.Reyelt@brunel.de) Received: from mailgate2.arcor-ip.de (mailgate2.arcor-ip.de [145.253.2.48]) by mx1.freebsd.org (Postfix) with ESMTP id 58B4E8FC0A for ; Wed, 11 Aug 2010 11:40:17 +0000 (UTC) Received: from mailer.brunellocal.de (ffmcospub2ffmbrunelfw2lo-cs-nat-mail-server.adm.arcor.net [145.254.28.157]) by mailgate1.cs.arcor.net (Arcor-CN-MailRelay-l-B) with ESMTP id F2EC8F9F559 for ; Wed, 11 Aug 2010 13:24:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 370884B75C for ; Wed, 11 Aug 2010 13:23:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at brunellocal.de Received: from mailer.brunellocal.de ([127.0.0.1]) by localhost (mailer.brunellocal.de [127.0.0.1]) (amavisd-new, port 10024) with SMTP id rpFqeXRcpuq2 for ; Wed, 11 Aug 2010 13:23:42 +0200 (CEST) Received: from mail-hv.brunel.de (mail-hv.brunellocal.de [192.168.1.234]) by mailer.brunellocal.de (Postfix) with ESMTP id 8ABB34B759 for ; Wed, 11 Aug 2010 13:23:41 +0200 (CEST) Received: from bcslx10.bcs.brunel.local ([172.16.101.231]) by 935s02su.brunellocal.de (Lotus Domino Release 7.0.4FP1) with ESMTP id 2010081113233837-26301 ; Wed, 11 Aug 2010 13:23:38 +0200 Received: from bcspc139.bcs.brunel.local (bcspc139.bcs.brunel.local [172.16.101.98]) by bcslx10.bcs.brunel.local (Postfix) with ESMTP id 71148FD858; Wed, 11 Aug 2010 13:23:38 +0200 (CEST) From: Matthias Reyelt Organization: Brunel Communications To: freebsd-arm@freebsd.org Date: Wed, 11 Aug 2010 13:23:34 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) MIME-Version: 1.0 Message-Id: <201008111323.36267.Matthias.Reyelt@brunel.de> X-MIMETrack: Itemize by SMTP Server on HUB93501/Brunel/De(Release 7.0.4FP1|July 20, 2009) at 11.08.2010 01:23:38 PM, Serialize by Router on HUB10149/Brunel/De(Release 7.0.4FP1|July 20, 2009) at 11.08.2010 01:23:41 PM, Serialize complete at 11.08.2010 01:23:41 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Subject: Cross compiling for FreeBSD/ARM on cygwin? 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, 11 Aug 2010 11:40:18 -0000 Hi, I have tried to build a cross-compiler environment for FreeBSD/ARM on cygwin. I have built a gcc toolchain for cygwin and I can compile a test program: ------------------------------------------------------------------------------------------ ./arm-unknown-freebsd8.0-gcc -c -v -Wa,-mfloat-abi=softfp,-mfpu=vfp -Wl,--eh-frame-hdr,-X main.c ---> test.o ------------------------------------------------------------------------------------------ I can link this object file on the ARM (Marvell db-78xxx) and the resulting binary runs fine: ------------------------------------------------------------------------------------------ ld --eh-frame-hdr -V -dynamic-linker /libexec/ld-elf.so.1 -X /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib -L/usr/lib -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o test.o ------------------------------------------------------------------------------------------ I haven't yet managed to do the linking under cygwin: ------------------------------------------------------------------------------------- /usr/local/bin/arm-unknown-freebsd8.0-ld.exe --eh-frame-hdr -V -dynamic-linker /usr/local/arm-unknown-freebsd8.0/libexec/ld-elf.so.1 -X /usr/local/arm-unknown-freebsd8.0/lib/crt1.o /usr/local/arm-unknown-freebsd8.0/lib/crti.o /usr/local/arm-unknown-freebsd8.0/lib/crtbegin.o -L/usr/local/arm-unknown-freebsd8.0/lib -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/local/arm-unknown-freebsd8.0/lib/crtend.o /usr/local/arm-unknown-freebsd8.0/lib/crtn.o test.o ------------------------------------------------------------------------------------------ When I try to run the resulting binary, I get the message: "Exec format error. Binary not executable" I have copied the crt1.o and the other files from the ARM target. Any idea what is missing? Matthias readelf on the binary looks like this: ------------------------------------------------------------------------------------------- ELF Header: Magic: 7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: ARM ABI Version: 0 Type: EXEC (Executable file) Machine: ARM Version: 0x1 Entry point address: 0x8234 Start of program headers: 52 (bytes into file) Start of section headers: 35128 (bytes into file) Flags: 0x602, has entry point, GNU EABI, software FP, Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 5 Size of section headers: 40 (bytes) Number of section headers: 28 Section header string table index: 25 Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .interp PROGBITS 00008000 008000 000036 00 A 0 0 1 [ 2] .note.ABI-tag NOTE 00008038 008038 000018 00 A 0 0 4 [ 3] .hash HASH 00008050 008050 000038 04 A 4 0 4 [ 4] .dynsym DYNSYM 00008088 008088 000090 10 A 5 1 4 [ 5] .dynstr STRTAB 00008118 008118 000058 00 A 0 0 1 [ 6] .gnu.version VERSYM 00008170 008170 000012 02 A 4 0 2 [ 7] .gnu.version_r VERNEED 00008184 008184 000020 00 A 5 1 4 [ 8] .rel.plt REL 000081a4 0081a4 000020 08 A 4 a 4 [ 9] .init PROGBITS 000081d0 0081d0 000020 00 AX 0 0 16 [10] .plt PROGBITS 000081f0 0081f0 000044 04 AX 0 0 4 [11] .text PROGBITS 00008234 008234 000254 00 AX 0 0 4 [12] .fini PROGBITS 00008490 008490 00001c 00 AX 0 0 16 [13] .rodata PROGBITS 000084ac 0084ac 000018 00 A 0 0 4 [14] .data PROGBITS 000085c4 0085c4 000014 00 WA 0 0 4 [15] .eh_frame PROGBITS 000085d8 0085d8 000004 00 A 0 0 4 [16] .dynamic DYNAMIC 000085dc 0085dc 0000b0 08 WA 5 0 4 [17] .ctors PROGBITS 0000868c 00868c 000008 00 WA 0 0 4 [18] .dtors PROGBITS 00008694 008694 000008 00 WA 0 0 4 [19] .jcr PROGBITS 0000869c 00869c 000004 00 WA 0 0 4 [20] .got PROGBITS 000086a0 0086a0 00001c 04 WA 0 0 4 [21] .bss NOBITS 000086bc 0086bc 00000c 00 WA 0 0 4 [22] .comment PROGBITS 00000000 0086bc 0001a2 00 0 0 1 [23] .stack PROGBITS 00080000 00885e 000000 00 W 0 0 1 [24] .arm.atpcs PROGBITS 00000000 00885e 000000 00 0 0 1 [25] .shstrtab STRTAB 00000000 00885e 0000d7 00 0 0 1 [26] .symtab SYMTAB 00000000 008d98 000740 10 27 5b 4 [27] .strtab STRTAB 00000000 0094d8 000313 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x00008034 0x00000000 0x000a0 0x000a0 R E 0x4 INTERP 0x008000 0x00008000 0x00008000 0x00036 0x00036 R 0x1 [Requesting program interpreter: /usr/local/arm-unknown-freebsd8.0/libexec/ld-elf.so.1] LOAD 0x008000 0x00008000 0x00008000 0x006bc 0x006c8 RWE 0x8000 DYNAMIC 0x0085dc 0x000085dc 0x000085dc 0x000b0 0x000b0 RW 0x4 NOTE 0x008038 0x00008038 0x00008038 0x00018 0x00018 R 0x4 Section to Segment mapping: Segment Sections... 00 .note.ABI-tag .hash 01 .interp 02 .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.plt .init .plt .text .fini .rodata .data .eh_frame .dynamic .ctors .dtors .jcr .got .bss 03 .dynamic 04 .note.ABI-tag Dynamic segment at offset 0x85dc contains 17 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libc.so.7] 0x0000000c (INIT) 0x81d0 0x0000000d (FINI) 0x8490 0x00000004 (HASH) 0x8050 0x00000005 (STRTAB) 0x8118 0x00000006 (SYMTAB) 0x8088 0x0000000a (STRSZ) 88 (bytes) 0x0000000b (SYMENT) 16 (bytes) 0x00000015 (DEBUG) 0x0 0x00000003 (PLTGOT) 0x86a0 0x00000002 (PLTRELSZ) 32 (bytes) 0x00000014 (PLTREL) REL 0x00000017 (JMPREL) 0x81a4 0x6ffffffe (VERNEED) 0x8184 0x6fffffff (VERNEEDNUM) 1 0x6ffffff0 (VERSYM) 0x8170 0x00000000 (NULL) 0x0 Relocation section '.rel.plt' at offset 0x81a4 contains 4 entries: Offset Info Type Sym.Value Sym. Name 000086ac 00000116 R_ARM_JUMP_SLOT 00008204 _init_tls 000086b0 00000416 R_ARM_JUMP_SLOT 00008210 printf 000086b4 00000516 R_ARM_JUMP_SLOT 0000821c exit 000086b8 00000716 R_ARM_JUMP_SLOT 00008228 atexit There are no unwind sections in this file. Symbol table '.dynsym' contains 9 entries: Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND 1: 00008204 4 FUNC GLOBAL DEFAULT UND _init_tls@FBSD_1.0 (2) 2: 000086c0 4 OBJECT GLOBAL DEFAULT 21 environ 3: 000085c4 4 OBJECT GLOBAL DEFAULT 14 __progname 4: 00008210 72 FUNC GLOBAL DEFAULT UND printf@FBSD_1.0 (2) 5: 0000821c 92 FUNC GLOBAL DEFAULT UND exit@FBSD_1.0 (2) 6: 000086c8 0 NOTYPE GLOBAL DEFAULT ABS _end 7: 00008228 56 FUNC GLOBAL DEFAULT UND atexit@FBSD_1.0 (2) 8: 00000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses Symbol table '.symtab' contains 116 entries: Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND 1: 00008000 0 SECTION LOCAL DEFAULT 1 2: 00008038 0 SECTION LOCAL DEFAULT 2 3: 00008050 0 SECTION LOCAL DEFAULT 3 4: 00008088 0 SECTION LOCAL DEFAULT 4 5: 00008118 0 SECTION LOCAL DEFAULT 5 6: 00008170 0 SECTION LOCAL DEFAULT 6 7: 00008184 0 SECTION LOCAL DEFAULT 7 8: 000081a4 0 SECTION LOCAL DEFAULT 8 9: 000081d0 0 SECTION LOCAL DEFAULT 9 10: 000081f0 0 SECTION LOCAL DEFAULT 10 11: 00008234 0 SECTION LOCAL DEFAULT 11 12: 00008490 0 SECTION LOCAL DEFAULT 12 13: 000084ac 0 SECTION LOCAL DEFAULT 13 14: 000085c4 0 SECTION LOCAL DEFAULT 14 15: 000085d8 0 SECTION LOCAL DEFAULT 15 16: 000085dc 0 SECTION LOCAL DEFAULT 16 17: 0000868c 0 SECTION LOCAL DEFAULT 17 18: 00008694 0 SECTION LOCAL DEFAULT 18 19: 0000869c 0 SECTION LOCAL DEFAULT 19 20: 000086a0 0 SECTION LOCAL DEFAULT 20 21: 000086bc 0 SECTION LOCAL DEFAULT 21 22: 00000000 0 SECTION LOCAL DEFAULT 22 23: 00080000 0 SECTION LOCAL DEFAULT 23 24: 00000000 0 SECTION LOCAL DEFAULT 24 25: 00000000 0 SECTION LOCAL DEFAULT 25 26: 00000000 0 SECTION LOCAL DEFAULT 26 27: 00000000 0 SECTION LOCAL DEFAULT 27 28: 00000000 0 FILE LOCAL DEFAULT ABS crt1.c 29: 00008234 0 FUNC LOCAL DEFAULT 11 $a 30: 00008310 0 OBJECT LOCAL DEFAULT 11 $d 31: 000085c4 0 OBJECT LOCAL DEFAULT 14 $d 32: 00008038 24 OBJECT LOCAL DEFAULT 2 abitag 33: 00008038 0 OBJECT LOCAL DEFAULT 2 $d 34: 00000000 0 FILE LOCAL DEFAULT ABS /root/ARM/head/lib/csu/ar 35: 00000000 0 FILE LOCAL DEFAULT ABS /usr/obj/arm/root/ARM/hea 36: 00000000 0 FILE LOCAL DEFAULT ABS /usr/obj/arm/root/ARM/hea 37: 00000000 0 FILE LOCAL DEFAULT ABS /usr/obj/arm/root/ARM/hea 38: 00000000 0 FILE LOCAL DEFAULT ABS /root/ARM/head/lib/csu/ar 39: 00000000 0 FILE LOCAL DEFAULT ABS 40: 00000000 0 FILE LOCAL DEFAULT ABS 41: 00000000 0 FILE LOCAL DEFAULT ABS /root/ARM/head/lib/csu/ar 42: 000081d0 0 FUNC LOCAL DEFAULT 9 $a 43: 00008490 0 FUNC LOCAL DEFAULT 12 $a 44: 00000000 0 FILE LOCAL DEFAULT ABS crtstuff.c 45: 000085c8 0 OBJECT LOCAL DEFAULT 14 force_to_data 46: 0000868c 0 OBJECT LOCAL DEFAULT 17 __CTOR_LIST__ 47: 0000868c 0 OBJECT LOCAL DEFAULT 17 $d 48: 00008694 0 OBJECT LOCAL DEFAULT 18 __DTOR_LIST__ 49: 00008694 0 OBJECT LOCAL DEFAULT 18 $d 50: 0000869c 0 OBJECT LOCAL DEFAULT 19 __JCR_LIST__ 51: 00008324 0 FUNC LOCAL DEFAULT 11 __do_global_dtors_aux 52: 00008324 0 FUNC LOCAL DEFAULT 11 $a 53: 00008388 0 OBJECT LOCAL DEFAULT 11 $d 54: 000086bc 1 OBJECT LOCAL DEFAULT 21 completed.4826 55: 000085d0 0 OBJECT LOCAL DEFAULT 14 p.4824 56: 00008390 0 FUNC LOCAL DEFAULT 11 call___do_global_dtors_au 57: 00008390 0 FUNC LOCAL DEFAULT 11 $a 58: 000084a0 0 FUNC LOCAL DEFAULT 12 $a 59: 000083a0 0 FUNC LOCAL DEFAULT 11 frame_dummy 60: 000083d0 0 OBJECT LOCAL DEFAULT 11 $d 61: 000083d8 0 FUNC LOCAL DEFAULT 11 call_frame_dummy 62: 000083d8 0 FUNC LOCAL DEFAULT 11 $a 63: 000081e0 0 FUNC LOCAL DEFAULT 9 $a 64: 000085d0 0 OBJECT LOCAL DEFAULT 14 $d 65: 00000000 0 FILE LOCAL DEFAULT ABS crtstuff.c 66: 000085d4 0 OBJECT LOCAL DEFAULT 14 force_to_data 67: 00008690 0 OBJECT LOCAL DEFAULT 17 __CTOR_END__ 68: 00008698 0 OBJECT LOCAL DEFAULT 18 __DTOR_END__ 69: 000085d8 0 OBJECT LOCAL DEFAULT 15 __FRAME_END__ 70: 0000869c 0 OBJECT LOCAL DEFAULT 19 __JCR_END__ 71: 000083e8 0 FUNC LOCAL DEFAULT 11 __do_global_ctors_aux 72: 000083e8 0 FUNC LOCAL DEFAULT 11 $a 73: 00008424 0 OBJECT LOCAL DEFAULT 11 $d 74: 00008428 0 FUNC LOCAL DEFAULT 11 call___do_global_ctors_au 75: 00008428 0 FUNC LOCAL DEFAULT 11 $a 76: 000081e4 0 FUNC LOCAL DEFAULT 9 $a 77: 00000000 0 FILE LOCAL DEFAULT ABS /root/ARM/head/lib/csu/ar 78: 00000000 0 FILE LOCAL DEFAULT ABS /usr/obj/arm/root/ARM/hea 79: 00000000 0 FILE LOCAL DEFAULT ABS /usr/obj/arm/root/ARM/hea 80: 00000000 0 FILE LOCAL DEFAULT ABS /usr/obj/arm/root/ARM/hea 81: 00000000 0 FILE LOCAL DEFAULT ABS /root/ARM/head/lib/csu/ar 82: 00000000 0 FILE LOCAL DEFAULT ABS 83: 00000000 0 FILE LOCAL DEFAULT ABS 84: 00000000 0 FILE LOCAL DEFAULT ABS /root/ARM/head/lib/csu/ar 85: 000081e8 0 FUNC LOCAL DEFAULT 9 $a 86: 000084a4 0 FUNC LOCAL DEFAULT 12 $a 87: 00000000 0 FILE LOCAL DEFAULT ABS test.c 88: 000084b0 0 NOTYPE LOCAL DEFAULT 13 $d 89: 00008438 0 NOTYPE LOCAL DEFAULT 11 $a 90: 00008484 0 NOTYPE LOCAL DEFAULT 11 $d 91: 000085dc 0 OBJECT GLOBAL DEFAULT 16 _DYNAMIC 92: 000086c8 0 NOTYPE GLOBAL DEFAULT ABS _bss_end__ 93: 000086bc 0 NOTYPE GLOBAL DEFAULT ABS __bss_start__ 94: 000085cc 0 OBJECT GLOBAL HIDDEN 14 __dso_handle 95: 00008204 4 FUNC GLOBAL DEFAULT UND _init_tls@@FBSD_1.0 96: 000081d0 0 FUNC GLOBAL DEFAULT 9 _init 97: 000086c0 4 OBJECT GLOBAL DEFAULT 21 environ 98: 00008264 192 FUNC GLOBAL DEFAULT 11 __start 99: 000086c8 0 NOTYPE GLOBAL DEFAULT ABS __bss_end__ 100: 000085c4 4 OBJECT GLOBAL DEFAULT 14 __progname 101: 00008234 0 NOTYPE GLOBAL DEFAULT 11 _start 102: 00008210 72 FUNC GLOBAL DEFAULT UND printf@@FBSD_1.0 103: 000086bc 0 NOTYPE GLOBAL DEFAULT ABS __bss_start 104: 00008438 80 FUNC GLOBAL DEFAULT 11 main 105: 000086c8 0 NOTYPE GLOBAL DEFAULT ABS __end__ 106: 00008490 0 FUNC GLOBAL DEFAULT 12 _fini 107: 0000821c 92 FUNC GLOBAL DEFAULT UND exit@@FBSD_1.0 108: 000086bc 0 NOTYPE GLOBAL DEFAULT ABS _edata 109: 000086a0 0 OBJECT GLOBAL DEFAULT 20 _GLOBAL_OFFSET_TABLE_ 110: 000086c8 0 NOTYPE GLOBAL DEFAULT ABS _end 111: 000086c4 4 OBJECT GLOBAL DEFAULT 21 __ps_strings 112: 00008228 56 FUNC GLOBAL DEFAULT UND atexit@@FBSD_1.0 113: 00080000 0 NOTYPE GLOBAL DEFAULT 23 _stack 114: 000085c4 0 NOTYPE GLOBAL DEFAULT 14 __data_start 115: 00000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses Histogram for bucket list length (total of 3 buckets): Length Number % of total Coverage 0 0 ( 0.0%) 1 1 ( 33.3%) 12.5% 2 0 ( 0.0%) 12.5% 3 1 ( 33.3%) 50.0% 4 1 ( 33.3%) 100.0% Version symbols section '.gnu.version' contains 9 entries: Addr: 0000000000008170 Offset: 0x008170 Link: 4 (.dynsym) 000: 0 (*local*) 2 (FBSD_1.0) 1 (*global*) 1 (*global*) 004: 2 (FBSD_1.0) 2 (FBSD_1.0) 1 (*global*) 2 (FBSD_1.0) 008: 0 (*local*) Version needs section '.gnu.version_r' contains 1 entries: Addr: 0x0000000000008184 Offset: 0x008184 Link to section: 5 (.dynstr) 000000: Version: 1 File: libc.so.7 Cnt: 1 0x0010: Name: FBSD_1.0 Flags: none Version: 2 From owner-freebsd-arm@FreeBSD.ORG Wed Aug 11 12:09:52 2010 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 807AB106566C for ; Wed, 11 Aug 2010 12:09:52 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:50:40:63ff:feea:93a]) by mx1.freebsd.org (Postfix) with ESMTP id 1F8F38FC12 for ; Wed, 11 Aug 2010 12:09:51 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.2/8.14.3) with ESMTP id o7BC9nuI001457; Wed, 11 Aug 2010 14:09:49 +0200 (CEST) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.2/8.14.3/Submit) id o7BC9n7S001456; Wed, 11 Aug 2010 14:09:49 +0200 (CEST) (envelope-from mlfbsd) Date: Wed, 11 Aug 2010 14:09:49 +0200 From: Olivier Houchard To: Matthias Reyelt Message-ID: <20100811120949.GA983@ci0.org> References: <201008111323.36267.Matthias.Reyelt@brunel.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201008111323.36267.Matthias.Reyelt@brunel.de> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arm@freebsd.org Subject: Re: Cross compiling for FreeBSD/ARM on cygwin? 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, 11 Aug 2010 12:09:52 -0000 On Wed, Aug 11, 2010 at 01:23:34PM +0200, Matthias Reyelt wrote: > Hi, > Hi Matthias, > I have tried to build a cross-compiler environment for FreeBSD/ARM on cygwin. > [skip] > "Exec format error. Binary not executable" > Try to brandelf -t FreeBSD yourbinary The branding is done automatically by our toolchain, but not by the stock one. Regards, Olivier From owner-freebsd-arm@FreeBSD.ORG Wed Aug 11 13:12:31 2010 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 024CD1065675 for ; Wed, 11 Aug 2010 13:12:31 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id AA82A8FC1B for ; Wed, 11 Aug 2010 13:12:30 +0000 (UTC) Received: by gwj23 with SMTP id 23so38352gwj.13 for ; Wed, 11 Aug 2010 06:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=qiHDIV8yR3CMGHpLGrin//d+Zbq+07i77jbVgSzt+WM=; b=ZrhJwc5NfduNTGTUo++XZNxKoFAlby7A6tHOP6IN9UK0X5ktNgLqqYylFH/9XBJHzs gdk0F1jQfVYDBbsu1cTKWFEm0r6HcEMYXdYV40LvNS5eCXZQCCztP1Z6wAzVpMaLywg/ eO/Y+o6HJbdHdLrTFRK0RADf6qnTcOTQk6qbw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Rm9rIon3VObp5oG0hPVEVLaiP51wmOpiMLWEV7yfHLWEJfr28mNuDoQtma5lQWJIWB lUgkAALms4hLN9Qh0dvo1UY/KMq3ZU71Mv1m/h1ZMMmIA26USfXD7Z0Nfo1mIYnP85tg tiOyTWNPnFq8nRJbCjkqzZIS6RdWoyd3mAfo0= Received: by 10.101.167.5 with SMTP id u5mr21701416ano.6.1281532349794; Wed, 11 Aug 2010 06:12:29 -0700 (PDT) Received: from [192.168.0.100] (71-38-48-15.frgo.qwest.net [71.38.48.15]) by mx.google.com with ESMTPS id x33sm151629ana.33.2010.08.11.06.12.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Aug 2010 06:12:29 -0700 (PDT) Message-ID: <4C62A1B7.5050601@gmail.com> Date: Wed, 11 Aug 2010 08:12:23 -0500 From: Mark Tinguely User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Rafal Jaworowski References: <4C607639.9050506@gmail.com> <20100810090533.GA56784@ci0.org> <82A49B7C-23F2-400C-B726-2FF13FD6D282@semihalf.com> In-Reply-To: <82A49B7C-23F2-400C-B726-2FF13FD6D282@semihalf.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@FreeBSD.org" Subject: Re: ARMv6 support -- was: OMAP3530 - Beagleboard and I2C problems 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, 11 Aug 2010 13:12:31 -0000 Rafal Jaworowski wrote: > On 2010-08-10, at 11:05, Olivier Houchard wrote: > >> On Mon, Aug 09, 2010 at 10:42:17PM +0100, Ben Gray wrote: >>> I've been working on a port of FreeBSD to Texas Instruments OMAP3530 >>> for a while now. I have the basic drivers, Clocks, MMC, DMA, GPIO's, >>> etc. The kernel is coming up, however it crashes with a seg fault when >>> starting the init process, this is probably caused by the hacks I had to >>> put in the pmap code to get it to work with ARMv7 MMU's, but that's an >>> email for another day. >>> >> That's great to hear ! >> How hackish is your work ? There's an ongoing work to support armv6/armv7, so >> maybe it's best to avoid duplicating efforts ? >> > > Olivier, > As we spoke, I've put a diff of our ARMv6 work to freefall, see: http://people.freebsd.org/~raj/patches/arm/dove_v6.diff > > This is against HEAD 2009.08.03, and is part of support for the following hardware: > - CPU core: Marvell Sheeva2 (88SV581x), ARMv6 > - SOC: 88F6781 (Armada 500 alias Dove) > > The DB-88F6781 kernel won't rather build, as there are a couple of platform-specific bits missing (GPIO rework, PM etc.), but the common ARM code should apply to the above baseline and give you an idea what kind of changes and adaptations were introduced in order to get this working. It's an initial attempt, but working stable. The main areas are pmap / busdma rework for v6; in order to have a clear situation during development we have decided to cut off from the legacy v5 files (and come up with separate -v6 derivatives), although we could converge back to a single file approach if this proves better eventually. > > Rafal > Rafal, I just quickly scrolled through the new ARMv6 pmap code. I am biased in favor of branching the new ARMv6/ARMv7 to new files; they are in many ways new breeds of processors. I also have a ARMv5 busdma file with sync lists which I have been using here for a long time. ARMv7 also has features that is not found in ARMv6. 1) using the (hardware/software) access flag, we do not have to emulate an access fault clearing the access flag will generate a new fault (section or page). The write emulation is still needed. a) There are a few changes to the ARMv6 and ARMv7 faults. Note: when the user page is read-only, so is the kernel mapping. 2) Bit 11 of the fault status register denotes read or write fault. Do not have to check the instruction in trap.c -- is implemented in Cortex A8. 3) If we use the simple access mode (1 above) and remap TEX, we can get rid of the pv_entry flag. Chunk pv_entrys (from i386/amd64 pmap) may also help save space. I think ARMv6 also supports the split TTB. One for kernel and one for user. If we are willing to split the UVA/KVA to 2GB each it would simplify KVA additions and uses smaller level one page tables. We should be thinking SMP with the new code. The ARMv6/ARMv7 have 3 special internal registers. One can be for the thread pointer, one can hold the percpu pointer, and one can be for the user. I have a ARMv5 and ARMv6/7 version of switch that combines the backend of cpu_throw() and cpu_switch(). On the ARMv6/7, it also maintains the special registers. The OMAP 3530 has a nice hardware interrupt priority facility (INTCPS_SIR_IRQ_ADDR).The priority can be calculated by the interrupt priority number when registering the interrupt. The GPIO interrupts would all have to be the same interrupt priority. (not specific to ARMv6 or ARMv7, but implementing page cache mode properties (similar to pat_mode in i386/amd64) is easy and makes mapping the cache mode of the new page mapping easier). Rafal, and Oliver: I am certain I have the Sheeva cache corruption problem during cluster i/o identified and a fix. It is exciting to see all this work on the ARM architecture. --Mark Tinguely From owner-freebsd-arm@FreeBSD.ORG Wed Aug 11 14:16:18 2010 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 1832C106567B for ; Wed, 11 Aug 2010 14:16:18 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:50:40:63ff:feea:93a]) by mx1.freebsd.org (Postfix) with ESMTP id A7C038FC29 for ; Wed, 11 Aug 2010 14:16:17 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.2/8.14.3) with ESMTP id o7BEGJZK003313; Wed, 11 Aug 2010 16:16:19 +0200 (CEST) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.2/8.14.3/Submit) id o7BEGJGQ003312; Wed, 11 Aug 2010 16:16:19 +0200 (CEST) (envelope-from mlfbsd) Date: Wed, 11 Aug 2010 16:16:19 +0200 From: Olivier Houchard To: Mark Tinguely Message-ID: <20100811141619.GA2927@ci0.org> References: <4C607639.9050506@gmail.com> <20100810090533.GA56784@ci0.org> <82A49B7C-23F2-400C-B726-2FF13FD6D282@semihalf.com> <4C62A1B7.5050601@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C62A1B7.5050601@gmail.com> User-Agent: Mutt/1.4.2.1i Cc: "freebsd-arm@FreeBSD.org" Subject: Re: ARMv6 support -- was: OMAP3530 - Beagleboard and I2C problems 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, 11 Aug 2010 14:16:18 -0000 On Wed, Aug 11, 2010 at 08:12:23AM -0500, Mark Tinguely wrote: > >The DB-88F6781 kernel won't rather build, as there are a couple of > >platform-specific bits missing (GPIO rework, PM etc.), but the common ARM > >code should apply to the above baseline and give you an idea what kind of > >changes and adaptations were introduced in order to get this working. It's > >an initial attempt, but working stable. The main areas are pmap / busdma > >rework for v6; in order to have a clear situation during development we > >have decided to cut off from the legacy v5 files (and come up with > >separate -v6 derivatives), although we could converge back to a single > >file approach if this proves better eventually. > > > >Rafal > > > Rafal, I just quickly scrolled through the new ARMv6 pmap code. > > I am biased in favor of branching the new ARMv6/ARMv7 to new files; they > are in many ways new breeds of processors. I also have a ARMv5 busdma > file with sync lists which I have been using here for a long time. > Me too, sort of. The NetBSD way of doing things adds a lot of #ifdef, but it avoids code duplication. > ARMv7 also has features that is not found in ARMv6. > > 1) using the (hardware/software) access flag, we do not have to emulate > an access fault clearing the access flag will generate a new fault > (section or page). The write emulation is still needed. > > a) There are a few changes to the ARMv6 and ARMv7 faults. Note: when > the user page is read-only, so is the kernel mapping. > > 2) Bit 11 of the fault status register denotes read or write fault. Do > not have to check the instruction in trap.c -- is implemented in Cortex A8. > > 3) If we use the simple access mode (1 above) and remap TEX, we can get > rid of the pv_entry flag. Chunk pv_entrys (from i386/amd64 pmap) may > also help save space. > > I think ARMv6 also supports the split TTB. One for kernel and one for > user. If we are willing to split the UVA/KVA to 2GB each it would > simplify KVA additions and uses smaller level one page tables. > > We should be thinking SMP with the new code. The ARMv6/ARMv7 have 3 > special internal registers. One can be for the thread pointer, one can > hold the percpu pointer, and one can be for the user. I have a ARMv5 and > ARMv6/7 version of switch that combines the backend of cpu_throw() and > cpu_switch(). On the ARMv6/7, it also maintains the special registers. > > The OMAP 3530 has a nice hardware interrupt priority facility > (INTCPS_SIR_IRQ_ADDR).The priority can be calculated by the interrupt > priority number when registering the interrupt. The GPIO interrupts > would all have to be the same interrupt priority. > > (not specific to ARMv6 or ARMv7, but implementing page cache mode > properties (similar to pat_mode in i386/amd64) is easy and makes mapping > the cache mode of the new page mapping easier). > > Rafal, and Oliver: I am certain I have the Sheeva cache corruption > problem during cluster i/o identified and a fix. > So what's going on ? > It is exciting to see all this work on the ARM architecture. > I'm quite excited by the armv6/v7 features, and finally supporting SMP. Is your work available somewhere ? We should definitively create an armv6/v7 branch in P4 or svn. Regards, Olivier From owner-freebsd-arm@FreeBSD.ORG Wed Aug 11 17:08:51 2010 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 AFBDB1065696 for ; Wed, 11 Aug 2010 17:08:51 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5A0608FC27 for ; Wed, 11 Aug 2010 17:08:51 +0000 (UTC) Received: by qwg5 with SMTP id 5so407234qwg.13 for ; Wed, 11 Aug 2010 10:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=atpJnKu7nLFEi44jzMENds+FSRo/FF90QhX+3OxHNFM=; b=c8x8usmUYpn2Pz8ncspF67+FjR0DovtefyA46xf2Grr1pBngB/HIG9fGSFmJ+SIkP1 gh3aE2pSqa4K+FDH+AsIPy6R+LolhKXfwsttt+XJNJUxRBG8znU4iZtFGu3KCMJkskeI asKvEEoaTs7EKiWFUzl0R1tF9wcZRol3u6pcU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=YDYQxGoqW7JRDkQAUDzWFMarXQ5HaYa3kbMIewTf4T5H5Va2KnIEbwJdnvxefJx7TY wDsAXOmPlrzSgoCSN4WqJrN4Afs0sdkNAphGY8tAPKomXdCTtsWS5XrU622O05Ug+3B0 c8GHlqf1JBvT0rh2U9YSELHlEBRjaVHf3JwCQ= Received: by 10.224.122.196 with SMTP id m4mr3536804qar.105.1281546530216; Wed, 11 Aug 2010 10:08:50 -0700 (PDT) Received: from [192.168.0.100] (71-38-48-15.frgo.qwest.net [71.38.48.15]) by mx.google.com with ESMTPS id t24sm412811qcs.23.2010.08.11.10.08.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Aug 2010 10:08:49 -0700 (PDT) Message-ID: <4C62D91B.6060201@gmail.com> Date: Wed, 11 Aug 2010 12:08:43 -0500 From: Mark Tinguely User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Olivier Houchard References: <4C607639.9050506@gmail.com> <20100810090533.GA56784@ci0.org> <82A49B7C-23F2-400C-B726-2FF13FD6D282@semihalf.com> <4C62A1B7.5050601@gmail.com> <20100811141619.GA2927@ci0.org> In-Reply-To: <20100811141619.GA2927@ci0.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@FreeBSD.org" Subject: Re: ARMv6 support -- was: OMAP3530 - Beagleboard and I2C problems 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, 11 Aug 2010 17:08:51 -0000 Olivier Houchard wrote: >> Rafal, and Oliver: I am certain I have the Sheeva cache corruption >> problem during cluster i/o identified and a fix. >> >> > > So what's going on ? > > sent off-list. >> It is exciting to see all this work on the ARM architecture. >> >> > > I'm quite excited by the armv6/v7 features, and finally supporting SMP. > Is your work available somewhere ? We should definitively create an armv6/v7 > branch in P4 or svn. > > Regards, > > Olivier > > I have full files of some rough ARMv7 cpufuncs, busdma_machdep.c for version 5 and one for version 6/7 (used by semihalf), switch.s, and vector floating point routines. Besides the mentioned changes to the switch.s file, there are also calls to keep track of the active processors for the current process; this is needed for SMP support. There are also very dated "diff" files that implement atomic routines using the new load-exclusive operation and hooks to support the new switch - for example the process active flag. These will have to be redone to patch cleanly and to remove the experimental VIPT level one support in the pmap_fix_cache() which, IMO, is code bloat with little advantages. These are different changes from the VIPT level TWO changes that may be needed if the Sheeva's level 2 cache is VIPT. I also have some readme files that remind me how the ARMv7 pde/ptes could be mapped to eliminate the pv_flags fields, save some pages on booting, nuances of the OMAP processor, etc. These files are unlinked but are on my public_html folder on the casselton dot net (which will be going away) web server. I am pretty sure I have sent the links or files to most of the active individuals in the past. I realize that I am a bit more theoretical and more revolutionary in my ideas. --Mark.