From owner-freebsd-arm@FreeBSD.ORG Sun Aug 12 00:18:32 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 39F5F106564A for ; Sun, 12 Aug 2012 00:18:32 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp5.clear.net.nz (smtp5.clear.net.nz [203.97.33.68]) by mx1.freebsd.org (Postfix) with ESMTP id F2D658FC08 for ; Sun, 12 Aug 2012 00:18:31 +0000 (UTC) Received: from mxin2-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp5.clear.net.nz (CLEAR Net Mail) with ESMTP id <0M8M0039O8UO7E40@smtp5.clear.net.nz> for freebsd-arm@freebsd.org; Sun, 12 Aug 2012 12:18:24 +1200 (NZST) Received: from 202-0-48-19.paradise.net.nz (HELO localhost) ([202.0.48.19]) by smtpin2.paradise.net.nz with ESMTP; Sun, 12 Aug 2012 12:18:24 +1200 Date: Sun, 12 Aug 2012 12:18:10 +1200 From: Andrew Turner In-reply-to: <1344717708.1186.20.camel@revolution.hippie.lan> To: Ian Lepore Message-id: <20120812121810.0f8e301a@fubar.geek.nz> MIME-version: 1.0 X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; i386-portbld-freebsd8.1) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Pirate: Arrrr References: <50256231.3030008@bluezbox.com> <1344717708.1186.20.camel@revolution.hippie.lan> Cc: "freebsd-arm@FreeBSD.org" Subject: Re: projects/armv6 merge X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 00:18:32 -0000 On Sat, 11 Aug 2012 14:41:48 -0600 Ian Lepore wrote: > files: sys/arm/lpc/lpc_machdep.c sys/arm/mv/mv_machdep.c > description: > Add missing brace. Comment out definition of proc0_tf, because it's > already defined in arm/machdep.c. > > Maybe it's the definition in arm/machdep.c that has to go, but if so > then a whole lot of other _machdep.c files need to have the > definition added. They were moved from _machdep.c to arm/marchdep.c as part of cleaning up duplicate code in initarm. You can remove them from _machdep.c. initarm() should then call init_proc0(). The mv version appears correct, however neither the lpc and tegra versions call init_proc0() and should be fixed. Andrew From owner-freebsd-arm@FreeBSD.ORG Mon Aug 13 02:36:27 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BCC0106564A for ; Mon, 13 Aug 2012 02:36:27 +0000 (UTC) (envelope-from gonzo@hq.bluezbox.com) Received: from hq.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id BDBA28FC0A for ; Mon, 13 Aug 2012 02:36:26 +0000 (UTC) Received: from [127.0.0.1] (helo=[IPv6:::1]) by hq.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1T0kVb-000O6Z-4C; Sun, 12 Aug 2012 19:35:59 -0700 Message-ID: <50286823.4090702@bluezbox.com> Date: Sun, 12 Aug 2012 19:36:19 -0700 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Ian Lepore References: <50256231.3030008@bluezbox.com> <1344725962.1186.26.camel@revolution.hippie.lan> In-Reply-To: <1344725962.1186.26.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@hq.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 8/11/2012 3:59 PM, Ian Lepore wrote: > On Fri, 2012-08-10 at 23:44 -0700, Oleksandr Tymoshenko wrote: >> Total patch is huge, so although it's PITA indeed here is >> initial batch of patches. I split diff into several patches. >> Some of them have known problems but I guess it's enough to get >> ball rolling: > One last patch (attached) to fix a little glitch in mvwin.h, and now my > dreamplug boots to multiuser and everything seems to be working that was > working a couple days ago (sata, usb, both ethernet ports, a few basic > services such as dhcp, nfs client, sshd and ntpd are working fine). > [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Cc: "freebsd-arm@FreeBSD.org" Subject: Re: projects/armv6 merge X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 02:36:27 -0000 On 8/11/2012 3:59 PM, Ian Lepore wrote: > On Fri, 2012-08-10 at 23:44 -0700, Oleksandr Tymoshenko wrote: >> Total patch is huge, so although it's PITA indeed here is >> initial batch of patches. I split diff into several patches. >> Some of them have known problems but I guess it's enough to get >> ball rolling: > One last patch (attached) to fix a little glitch in mvwin.h, and now my > dreamplug boots to multiuser and everything seems to be working that was > working a couple days ago (sata, usb, both ethernet ports, a few basic > services such as dhcp, nfs client, sshd and ntpd are working fine). > Thanks for testing, Ian. I incorporated your changes to projects/armv6 and regenerated patches. Here is regenerated version: http://people.freebsd.org/~gonzo/armv6/v2/ From owner-freebsd-arm@FreeBSD.ORG Mon Aug 13 11:07:03 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBD5D1065672 for ; Mon, 13 Aug 2012 11:07:03 +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 D63378FC1B for ; Mon, 13 Aug 2012 11:07:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7DB73xX007044 for ; Mon, 13 Aug 2012 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7DB734Q007042 for freebsd-arm@FreeBSD.org; Mon, 13 Aug 2012 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 13 Aug 2012 11:07:03 GMT Message-Id: <201208131107.q7DB734Q007042@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, 13 Aug 2012 11:07:04 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/166256 arm build fail in pmap.c o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) o arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 p arm/134338 arm [patch] Lock GPIO accesses on ixp425 13 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Aug 13 20:15:10 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE78E106566C for ; Mon, 13 Aug 2012 20:15:10 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id 8D5CC8FC14 for ; Mon, 13 Aug 2012 20:15:10 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta13.emeryville.ca.mail.comcast.net with comcast id mF3v1j0011u4NiLADLF4Aw; Mon, 13 Aug 2012 20:15:04 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta21.emeryville.ca.mail.comcast.net with comcast id mLF31j00P4NgCEG8hLF31e; Mon, 13 Aug 2012 20:15:04 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q7DKF1XZ014155; Mon, 13 Aug 2012 14:15:01 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Oleksandr Tymoshenko In-Reply-To: <50286823.4090702@bluezbox.com> References: <50256231.3030008@bluezbox.com> <1344725962.1186.26.camel@revolution.hippie.lan> <50286823.4090702@bluezbox.com> Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Aug 2012 14:15:01 -0600 Message-ID: <1344888901.1186.47.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@FreeBSD.org" Subject: Re: projects/armv6 merge X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 20:15:10 -0000 On Sun, 2012-08-12 at 19:36 -0700, Oleksandr Tymoshenko wrote: > On 8/11/2012 3:59 PM, Ian Lepore wrote: > > On Fri, 2012-08-10 at 23:44 -0700, Oleksandr Tymoshenko wrote: > >> Total patch is huge, so although it's PITA indeed here is > >> initial batch of patches. I split diff into several patches. > >> Some of them have known problems but I guess it's enough to get > >> ball rolling: > > One last patch (attached) to fix a little glitch in mvwin.h, and now my > > dreamplug boots to multiuser and everything seems to be working that was > > working a couple days ago (sata, usb, both ethernet ports, a few basic > > services such as dhcp, nfs client, sshd and ntpd are working fine). > > > > Thanks for testing, Ian. I incorporated your changes to projects/armv6 and > regenerated patches. Here is regenerated version: > http://people.freebsd.org/~gonzo/armv6/v2/ > > Looking good... I applied the patches to a fresh checkout, everything built fine. I then re-applied my local dreamplug support patch, rebuilt the kernel, and the dreamplug booted right up with everything working. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Aug 15 00:29:59 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB8D91065673 for ; Wed, 15 Aug 2012 00:29:59 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from nahkohe.jetcafe.org (nahkohe.jetcafe.org [205.147.26.32]) by mx1.freebsd.org (Postfix) with ESMTP id A92998FC12 for ; Wed, 15 Aug 2012 00:29:59 +0000 (UTC) X-Envelope-To: freebsd-arm@freebsd.org Received: from [205.147.26.5] (hokkshideh4.jetcafe.org [205.147.26.5]) by nahkohe.jetcafe.org (8.14.2/8.14.2) with ESMTP id q7F0Q1Gu026171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2012 17:26:01 -0700 (PDT) Message-ID: <502AEC99.70708@jetcafe.org> Date: Tue, 14 Aug 2012 17:26:01 -0700 From: Dave Hayes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120612 Thunderbird/13.0 MIME-Version: 1.0 To: Ian Lepore References: <5008728C.5040100@jetcafe.org> <1343846511.1128.34.camel@revolution.hippie.lan> <501B0E04.5040901@jetcafe.org> <1343951251.1128.53.camel@revolution.hippie.lan> In-Reply-To: <1343951251.1128.53.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Building ARM ports (was Re: Globalscale Dreamplug and 8.3 RELEASE) 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, 15 Aug 2012 00:29:59 -0000 On 08/02/12 16:47, Ian Lepore wrote: > I haven't yet tried to build ports using stock freebsd. At work we have > an arcane and complex and fragile system for cross-building ports, which > I only partially understand. That's the entire problem with cross-building. Ports are very complex systems and I think it's cleaner to just build them in an ARM emulator. There are far too many dependencies to keep track of otherwise, at least for me. When I find time to struggle with QEMU again, I'll try to post a summary here...presuming I can get this to work. -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< Most anything that annoys you is a mirror. From owner-freebsd-arm@FreeBSD.ORG Wed Aug 15 00:35:52 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CDC6F106566B for ; Wed, 15 Aug 2012 00:35:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7D0C38FC12 for ; Wed, 15 Aug 2012 00:35:52 +0000 (UTC) Received: by yhfs35 with SMTP id s35so1439888yhf.13 for ; Tue, 14 Aug 2012 17:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kWkqvxEBR0WhAYGemCyXytgLTxMRbF60a79Tj9F66zE=; b=n+VgkRk+ul4wMBTM5PqErDD+F8OHikeIZ4gysJqdKR3rldSI0ePSaOakLH0+T7IYhR bxr97MzQrnW8X5B7INUwTnTLbhvdSHSBdZMo4YyeWGseJjVCg3Z63LHGfKTNZYEcArP6 GsnvBzhFqepT63+478t3MrthvBLk72kncdA8tw0JOnAgcxYeWx1EWPTev+6QI39SJ7Em jrTW9C25yGRqNygQJZ4g/iV7110tQNNzamCuS27t3pS8SIf9FzS1rl7nbDdI9CIXY5sf d4WS/Cq/m2SnMiAkH2ExosNO00W119ucxDTpZGSfYYV/K8BjsUXjQqbaTKLVlxsX1Oop hK7Q== MIME-Version: 1.0 Received: by 10.68.236.102 with SMTP id ut6mr38888750pbc.113.1344990951410; Tue, 14 Aug 2012 17:35:51 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.43.169 with HTTP; Tue, 14 Aug 2012 17:35:51 -0700 (PDT) In-Reply-To: <502AEC99.70708@jetcafe.org> References: <5008728C.5040100@jetcafe.org> <1343846511.1128.34.camel@revolution.hippie.lan> <501B0E04.5040901@jetcafe.org> <1343951251.1128.53.camel@revolution.hippie.lan> <502AEC99.70708@jetcafe.org> Date: Tue, 14 Aug 2012 17:35:51 -0700 X-Google-Sender-Auth: M3WMrUx_diYBcYzg2U8CcDkLbwg Message-ID: From: Adrian Chadd To: Dave Hayes Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org Subject: Re: Building ARM ports (was Re: Globalscale Dreamplug and 8.3 RELEASE) 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, 15 Aug 2012 00:35:52 -0000 Guys/girls/etc, OpenWRT manages it. They started from the ground up with having to cross-build. Just because the problem is hard to tackle doesn't mean we shouldn't try. There's like a dozen half-done attempts at this. I realise you can't address _all_ the ports at once, but surely starting with a small subset and working outward is doable. I'll put up a bounty for anyone who actually comes up with a basic framework for supporting cross-building ports, documents how it does/doesn't work (eg if things like build vs run dependencies) and has a basic design for how to slowly fix ports to support it. Adrian From owner-freebsd-arm@FreeBSD.ORG Wed Aug 15 02:42:59 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A93481065672 for ; Wed, 15 Aug 2012 02:42:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 640948FC12 for ; Wed, 15 Aug 2012 02:42:59 +0000 (UTC) Received: by obbun3 with SMTP id un3so1926991obb.13 for ; Tue, 14 Aug 2012 19:42:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=MyUCHAOnisXJtwNYw5pR5QDG1on7B3xERYUAtjYhuBA=; b=UsYseX60MGf9invWNQdRdMGh8mGTEWhg1d69lOPY8rEV1wgsSGJdP7Ffstr0zZdm1E sZGKcMjyTvOhKBhK1lwO7D8sKB0G7VmAs9Kw3NlGMT7n8INe+0I5yHSSZCUOK/YY3Xkk R5XnRqgzwp7q6YzTnvIfC3mwJVDu2td4Aqb8pfflhUtr2O3gtgN0S2hVJcSfY491INUz ASbctQx/J+NAySdHaxXaCAgc53dWq7/E68Sigyoh07Bb62IacOY+Yqio5oBLK61EkAxJ 4jx2qqbvEHVdVQWsjsjD51KLyj8XbePa9CPlCuG+m0QHyDxCVFwiX4tsgFDEADkk2WNY 0hTQ== Received: by 10.60.29.72 with SMTP id i8mr191414oeh.26.1344998578450; Tue, 14 Aug 2012 19:42:58 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ac8sm229223obc.11.2012.08.14.19.42.57 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Aug 2012 19:42:57 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <502AEC99.70708@jetcafe.org> Date: Tue, 14 Aug 2012 20:42:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <55EAC835-9838-4802-8B2C-73B32FC6513F@bsdimp.com> References: <5008728C.5040100@jetcafe.org> <1343846511.1128.34.camel@revolution.hippie.lan> <501B0E04.5040901@jetcafe.org> <1343951251.1128.53.camel@revolution.hippie.lan> <502AEC99.70708@jetcafe.org> To: Dave Hayes X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmsrjb4aSAnX/AOfBH55R66i95tRz/ABpvcN9foHVyW/LaoqkKBNVGD/x5KvsfijcX+OJIp Cc: freebsd-arm@freebsd.org Subject: Re: Building ARM ports (was Re: Globalscale Dreamplug and 8.3 RELEASE) 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, 15 Aug 2012 02:42:59 -0000 On Aug 14, 2012, at 6:26 PM, Dave Hayes wrote: > On 08/02/12 16:47, Ian Lepore wrote: >> I haven't yet tried to build ports using stock freebsd. At work we = have >> an arcane and complex and fragile system for cross-building ports, = which >> I only partially understand. >=20 > That's the entire problem with cross-building. Ports are very complex = systems and I think it's cleaner to just build them in an ARM emulator. > There are far too many dependencies to keep track of otherwise, at = least > for me. Yet the Linux folks are able to do it. If we want to be competitive, = we'll need to have a viable solution. > When I find time to struggle with QEMU again, I'll try to post a = summary here...presuming I can get this to work. This may or may not ultimately work. I hope that the complexity of this = is actually less than getting it right in the cross building world. Warner From owner-freebsd-arm@FreeBSD.ORG Wed Aug 15 02:44:57 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8FE581065673 for ; Wed, 15 Aug 2012 02:44:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4AEB28FC12 for ; Wed, 15 Aug 2012 02:44:56 +0000 (UTC) Received: by obbun3 with SMTP id un3so1929821obb.13 for ; Tue, 14 Aug 2012 19:44:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=7daI6h+6gg9M5FrXPZunC0PmQrM46TSL/If9rYz2VVE=; b=Em0bHCRl2xGnquteVZEux3DCwxwRSKyT9Tgeyu/G5MPgYWE9pDPiyxboTmXwtmncuP 5WDEpgnr+z398kCbCKdaOFpeAagGMQpAa89chyTkPz17o8/cmo2pFrs365uQa13DoEDe bQEvgxtqEXfBgnr6RSiBUQxYos82toKKk4qYLZi/iuAVl+L3R8q6ozCxYdYSKKmdlNAY IXB0Ff8k0Mav4BwXG26T/n5s4xX7JLJ8lEmcOpVCb7cJs+/RxXvCQWTh4EFbHzB9BGda wxkcBynmXTFzEKti5iN4b1zhg8TnCiHACyE+N1zQKwED6FVyc1zMVMzJ2PPC20GY2+bB cTeg== Received: by 10.182.110.40 with SMTP id hx8mr21839416obb.47.1344998696605; Tue, 14 Aug 2012 19:44:56 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id y6sm205430oed.2.2012.08.14.19.44.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Aug 2012 19:44:55 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 14 Aug 2012 20:44:41 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <48664E9B-0BBB-4C78-B720-9920083E661A@bsdimp.com> References: <5008728C.5040100@jetcafe.org> <1343846511.1128.34.camel@revolution.hippie.lan> <501B0E04.5040901@jetcafe.org> <1343951251.1128.53.camel@revolution.hippie.lan> <502AEC99.70708@jetcafe.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmL/5n5jmnUlr9LixpOO9haf2j8OMtQhz+3L+1zTK0/rmFxqMUBi60uLgMtV2wK0+K3b6Fz Cc: freebsd-arm@freebsd.org Subject: Re: Building ARM ports (was Re: Globalscale Dreamplug and 8.3 RELEASE) 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, 15 Aug 2012 02:44:57 -0000 On Aug 14, 2012, at 6:35 PM, Adrian Chadd wrote: > Guys/girls/etc, >=20 > OpenWRT manages it. They started from the ground up with having to = cross-build. >=20 > Just because the problem is hard to tackle doesn't mean we shouldn't = try. Agreed. I worry the qemu solution sounds simple, but really will be = harder. Prove me wrong :) > There's like a dozen half-done attempts at this. I realise you can't > address _all_ the ports at once, but surely starting with a small > subset and working outward is doable. >=20 > I'll put up a bounty for anyone who actually comes up with a basic > framework for supporting cross-building ports, documents how it > does/doesn't work (eg if things like build vs run dependencies) and > has a basic design for how to slowly fix ports to support it. I have the basics, and have for years. I've posted them several times. = The trouble is that they are very very basic and need more work. I = think you'll need to define the problem a little better before progress = can be made. Warners From owner-freebsd-arm@FreeBSD.ORG Wed Aug 15 08:04:33 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B121C1065672; Wed, 15 Aug 2012 08:04:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 720C68FC12; Wed, 15 Aug 2012 08:04:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q7F7pjII067834; Wed, 15 Aug 2012 03:51:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q7F7piwa067833; Wed, 15 Aug 2012 07:51:44 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 15 Aug 2012 07:51:44 GMT Message-Id: <201208150751.q7F7piwa067833@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 08:04:33 -0000 TB --- 2012-08-15 06:30:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-08-15 06:30:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-08-15 06:30:01 - starting HEAD tinderbox run for arm/arm TB --- 2012-08-15 06:30:01 - cleaning the object tree TB --- 2012-08-15 06:30:01 - cvsupping the source tree TB --- 2012-08-15 06:30:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-08-15 06:31:17 - building world TB --- 2012-08-15 06:31:17 - CROSS_BUILD_TESTING=YES TB --- 2012-08-15 06:31:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-15 06:31:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-15 06:31:17 - SRCCONF=/dev/null TB --- 2012-08-15 06:31:17 - TARGET=arm TB --- 2012-08-15 06:31:17 - TARGET_ARCH=arm TB --- 2012-08-15 06:31:17 - TZ=UTC TB --- 2012-08-15 06:31:17 - __MAKE_CONF=/dev/null TB --- 2012-08-15 06:31:17 - cd /src TB --- 2012-08-15 06:31:17 - /usr/bin/make -B buildworld >>> World build started on Wed Aug 15 06:31:18 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Aug 15 07:48:12 UTC 2012 TB --- 2012-08-15 07:48:12 - cd /src/sys/arm/conf TB --- 2012-08-15 07:48:12 - /usr/sbin/config -m ATMEL TB --- 2012-08-15 07:48:12 - building ATMEL kernel TB --- 2012-08-15 07:48:12 - CROSS_BUILD_TESTING=YES TB --- 2012-08-15 07:48:12 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-15 07:48:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-15 07:48:12 - SRCCONF=/dev/null TB --- 2012-08-15 07:48:12 - TARGET=arm TB --- 2012-08-15 07:48:12 - TARGET_ARCH=arm TB --- 2012-08-15 07:48:12 - TZ=UTC TB --- 2012-08-15 07:48:12 - __MAKE_CONF=/dev/null TB --- 2012-08-15 07:48:12 - cd /src TB --- 2012-08-15 07:48:12 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Wed Aug 15 07:48:13 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] rm -f hack.c cat /src/sys/conf/ldscript.arm|sed s/KERNPHYSADDR/0x20000000/g| sed s/KERNVIRTADDR/0xc0000000/g > ldscript.arm MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh ATMEL cc -mlittle-endian -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror vers.c linking kernel machdep.o: In function `cpu_idle': machdep.c:(.text+0xa3c): undefined reference to `cpu_idleclock' machdep.c:(.text+0xa50): undefined reference to `cpu_activeclock' *** Error code 1 Stop in /obj/arm.arm/src/sys/ATMEL. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-08-15 07:51:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-08-15 07:51:44 - ERROR: failed to build ATMEL kernel TB --- 2012-08-15 07:51:44 - 2647.95 user 595.47 system 4903.87 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Aug 15 14:10:47 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 258F9106566B for ; Wed, 15 Aug 2012 14:10:47 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id 00CAC8FC15 for ; Wed, 15 Aug 2012 14:10:46 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta10.emeryville.ca.mail.comcast.net with comcast id n0wa1j0061wfjNsAA2Agi2; Wed, 15 Aug 2012 14:10:40 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta23.emeryville.ca.mail.comcast.net with comcast id n2Ae1j00M4NgCEG8j2AfeY; Wed, 15 Aug 2012 14:10:40 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q7FEAbns016068; Wed, 15 Aug 2012 08:10:37 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Warner Losh In-Reply-To: <48664E9B-0BBB-4C78-B720-9920083E661A@bsdimp.com> References: <5008728C.5040100@jetcafe.org> <1343846511.1128.34.camel@revolution.hippie.lan> <501B0E04.5040901@jetcafe.org> <1343951251.1128.53.camel@revolution.hippie.lan> <502AEC99.70708@jetcafe.org> <48664E9B-0BBB-4C78-B720-9920083E661A@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Aug 2012 08:10:37 -0600 Message-ID: <1345039837.27688.14.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Building ARM ports (was Re: Globalscale Dreamplug and 8.3 RELEASE) 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, 15 Aug 2012 14:10:47 -0000 On Tue, 2012-08-14 at 20:44 -0600, Warner Losh wrote: > On Aug 14, 2012, at 6:35 PM, Adrian Chadd wrote: > > > Guys/girls/etc, > > > > OpenWRT manages it. They started from the ground up with having to cross-build. > > > > Just because the problem is hard to tackle doesn't mean we shouldn't try. > > Agreed. I worry the qemu solution sounds simple, but really will be harder. Prove me wrong :) > > > There's like a dozen half-done attempts at this. I realise you can't > > address _all_ the ports at once, but surely starting with a small > > subset and working outward is doable. > > > > I'll put up a bounty for anyone who actually comes up with a basic > > framework for supporting cross-building ports, documents how it > > does/doesn't work (eg if things like build vs run dependencies) and > > has a basic design for how to slowly fix ports to support it. > > I have the basics, and have for years. I've posted them several times. The trouble is that they are very very basic and need more work. I think you'll need to define the problem a little better before progress can be made. > > Warner The system we use at work is basically Warner's (at least I think he put the bulk of it in place years ago). It involves defining a bunch of environment variables that change how ports are built (I want to say "fools" or "tricks" the ports into using cross-tools, but the negative implications of those words may just reflect my ignorance of the details). The biggest problem we have is build versus run dependencies. When crossbuilding port foo to run on arm, that port decides it needs the compile_a_foo port to build the code, so it goes off and cross-builds compile_a_foo, then wants to run the resulting arm binaries on the x86 host. The only way I know of to fix that is to tediously identify and pre-build all the build-time requirements needed by any port you intend to cross-build. Ports that have their own build systems and custom tools are essentially impossible to work with. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Aug 15 16:27:04 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18D631065672; Wed, 15 Aug 2012 16:27:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BF16A8FC08; Wed, 15 Aug 2012 16:27:03 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q7FGR2u1037547; Wed, 15 Aug 2012 12:27:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q7FGR2DS037543; Wed, 15 Aug 2012 16:27:02 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 15 Aug 2012 16:27:02 GMT Message-Id: <201208151627.q7FGR2DS037543@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 16:27:04 -0000 TB --- 2012-08-15 14:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-08-15 14:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-08-15 14:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-08-15 14:40:00 - cleaning the object tree TB --- 2012-08-15 14:44:08 - cvsupping the source tree TB --- 2012-08-15 14:44:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-08-15 14:45:00 - building world TB --- 2012-08-15 14:45:00 - CROSS_BUILD_TESTING=YES TB --- 2012-08-15 14:45:00 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-15 14:45:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-15 14:45:00 - SRCCONF=/dev/null TB --- 2012-08-15 14:45:00 - TARGET=arm TB --- 2012-08-15 14:45:00 - TARGET_ARCH=arm TB --- 2012-08-15 14:45:00 - TZ=UTC TB --- 2012-08-15 14:45:00 - __MAKE_CONF=/dev/null TB --- 2012-08-15 14:45:00 - cd /src TB --- 2012-08-15 14:45:00 - /usr/bin/make -B buildworld >>> World build started on Wed Aug 15 14:45:00 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Aug 15 15:50:19 UTC 2012 TB --- 2012-08-15 15:50:19 - cd /src/sys/arm/conf TB --- 2012-08-15 15:50:19 - /usr/sbin/config -m ARMADAXP TB --- 2012-08-15 15:50:19 - building ARMADAXP kernel TB --- 2012-08-15 15:50:19 - CROSS_BUILD_TESTING=YES TB --- 2012-08-15 15:50:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-15 15:50:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-15 15:50:19 - SRCCONF=/dev/null TB --- 2012-08-15 15:50:19 - TARGET=arm TB --- 2012-08-15 15:50:19 - TARGET_ARCH=arm TB --- 2012-08-15 15:50:19 - TZ=UTC TB --- 2012-08-15 15:50:19 - __MAKE_CONF=/dev/null TB --- 2012-08-15 15:50:19 - cd /src TB --- 2012-08-15 15:50:19 - /usr/bin/make -B buildkernel KERNCONF=ARMADAXP >>> Kernel build for ARMADAXP started on Wed Aug 15 15:50:19 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ARMADAXP completed on Wed Aug 15 15:52:54 UTC 2012 TB --- 2012-08-15 15:52:54 - cd /src/sys/arm/conf TB --- 2012-08-15 15:52:54 - /usr/sbin/config -m ATMEL TB --- 2012-08-15 15:52:54 - building ATMEL kernel TB --- 2012-08-15 15:52:54 - CROSS_BUILD_TESTING=YES TB --- 2012-08-15 15:52:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-15 15:52:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-15 15:52:54 - SRCCONF=/dev/null TB --- 2012-08-15 15:52:54 - TARGET=arm TB --- 2012-08-15 15:52:54 - TARGET_ARCH=arm TB --- 2012-08-15 15:52:54 - TZ=UTC TB --- 2012-08-15 15:52:54 - __MAKE_CONF=/dev/null TB --- 2012-08-15 15:52:54 - cd /src TB --- 2012-08-15 15:52:54 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Wed Aug 15 15:52:54 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Wed Aug 15 15:56:33 UTC 2012 TB --- 2012-08-15 15:56:33 - cd /src/sys/arm/conf TB --- 2012-08-15 15:56:33 - /usr/sbin/config -m AVILA TB --- 2012-08-15 15:56:33 - building AVILA kernel TB --- 2012-08-15 15:56:33 - CROSS_BUILD_TESTING=YES TB --- 2012-08-15 15:56:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-15 15:56:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-15 15:56:33 - SRCCONF=/dev/null TB --- 2012-08-15 15:56:33 - TARGET=arm TB --- 2012-08-15 15:56:33 - TARGET_ARCH=arm TB --- 2012-08-15 15:56:33 - TZ=UTC TB --- 2012-08-15 15:56:33 - __MAKE_CONF=/dev/null TB --- 2012-08-15 15:56:33 - cd /src TB --- 2012-08-15 15:56:33 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Wed Aug 15 15:56:33 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for AVILA completed on Wed Aug 15 15:59:43 UTC 2012 TB --- 2012-08-15 15:59:43 - cd /src/sys/arm/conf TB --- 2012-08-15 15:59:43 - /usr/sbin/config -m BEAGLEBONE TB --- 2012-08-15 15:59:43 - building BEAGLEBONE kernel TB --- 2012-08-15 15:59:43 - CROSS_BUILD_TESTING=YES TB --- 2012-08-15 15:59:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-15 15:59:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-15 15:59:43 - SRCCONF=/dev/null TB --- 2012-08-15 15:59:43 - TARGET=arm TB --- 2012-08-15 15:59:43 - TARGET_ARCH=arm TB --- 2012-08-15 15:59:43 - TZ=UTC TB --- 2012-08-15 15:59:43 - __MAKE_CONF=/dev/null TB --- 2012-08-15 15:59:43 - cd /src TB --- 2012-08-15 15:59:43 - /usr/bin/make -B buildkernel KERNCONF=BEAGLEBONE >>> Kernel build for BEAGLEBONE started on Wed Aug 15 15:59:43 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BEAGLEBONE completed on Wed Aug 15 16:02:16 UTC 2012 TB --- 2012-08-15 16:02:16 - cd /src/sys/arm/conf TB --- 2012-08-15 16:02:16 - /usr/sbin/config -m BWCT TB --- 2012-08-15 16:02:16 - building BWCT kernel TB --- 2012-08-15 16:02:16 - CROSS_BUILD_TESTING=YES TB --- 2012-08-15 16:02:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-15 16:02:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-15 16:02:16 - SRCCONF=/dev/null TB --- 2012-08-15 16:02:16 - TARGET=arm TB --- 2012-08-15 16:02:16 - TARGET_ARCH=arm TB --- 2012-08-15 16:02:16 - TZ=UTC TB --- 2012-08-15 16:02:16 - __MAKE_CONF=/dev/null TB --- 2012-08-15 16:02:16 - cd /src TB --- 2012-08-15 16:02:16 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Wed Aug 15 16:02:16 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Wed Aug 15 16:04:28 UTC 2012 TB --- 2012-08-15 16:04:28 - cd /src/sys/arm/conf TB --- 2012-08-15 16:04:28 - /usr/sbin/config -m CAMBRIA TB --- 2012-08-15 16:04:28 - building CAMBRIA kernel TB --- 2012-08-15 16:04:28 - CROSS_BUILD_TESTING=YES TB --- 2012-08-15 16:04:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-15 16:04:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-15 16:04:28 - SRCCONF=/dev/null TB --- 2012-08-15 16:04:28 - TARGET=arm TB --- 2012-08-15 16:04:28 - TARGET_ARCH=arm TB --- 2012-08-15 16:04:28 - TZ=UTC TB --- 2012-08-15 16:04:28 - __MAKE_CONF=/dev/null TB --- 2012-08-15 16:04:28 - cd /src TB --- 2012-08-15 16:04:28 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Wed Aug 15 16:04:28 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CAMBRIA completed on Wed Aug 15 16:07:32 UTC 2012 TB --- 2012-08-15 16:07:32 - cd /src/sys/arm/conf TB --- 2012-08-15 16:07:32 - /usr/sbin/config -m CNS11XXNAS TB --- 2012-08-15 16:07:33 - building CNS11XXNAS kernel TB --- 2012-08-15 16:07:33 - CROSS_BUILD_TESTING=YES TB --- 2012-08-15 16:07:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-15 16:07:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-15 16:07:33 - SRCCONF=/dev/null TB --- 2012-08-15 16:07:33 - TARGET=arm TB --- 2012-08-15 16:07:33 - TARGET_ARCH=arm TB --- 2012-08-15 16:07:33 - TZ=UTC TB --- 2012-08-15 16:07:33 - __MAKE_CONF=/dev/null TB --- 2012-08-15 16:07:33 - cd /src TB --- 2012-08-15 16:07:33 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Wed Aug 15 16:07:33 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Wed Aug 15 16:10:02 UTC 2012 TB --- 2012-08-15 16:10:02 - cd /src/sys/arm/conf TB --- 2012-08-15 16:10:02 - /usr/sbin/config -m CRB TB --- 2012-08-15 16:10:02 - building CRB kernel TB --- 2012-08-15 16:10:02 - CROSS_BUILD_TESTING=YES TB --- 2012-08-15 16:10:02 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-15 16:10:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-15 16:10:02 - SRCCONF=/dev/null TB --- 2012-08-15 16:10:02 - TARGET=arm TB --- 2012-08-15 16:10:02 - TARGET_ARCH=arm TB --- 2012-08-15 16:10:02 - TZ=UTC TB --- 2012-08-15 16:10:02 - __MAKE_CONF=/dev/null TB --- 2012-08-15 16:10:02 - cd /src TB --- 2012-08-15 16:10:02 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Wed Aug 15 16:10:02 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CRB completed on Wed Aug 15 16:13:28 UTC 2012 TB --- 2012-08-15 16:13:28 - cd /src/sys/arm/conf TB --- 2012-08-15 16:13:28 - /usr/sbin/config -m DB-78XXX TB --- 2012-08-15 16:13:28 - building DB-78XXX kernel TB --- 2012-08-15 16:13:28 - CROSS_BUILD_TESTING=YES TB --- 2012-08-15 16:13:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-15 16:13:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-15 16:13:28 - SRCCONF=/dev/null TB --- 2012-08-15 16:13:28 - TARGET=arm TB --- 2012-08-15 16:13:28 - TARGET_ARCH=arm TB --- 2012-08-15 16:13:28 - TZ=UTC TB --- 2012-08-15 16:13:28 - __MAKE_CONF=/dev/null TB --- 2012-08-15 16:13:28 - cd /src TB --- 2012-08-15 16:13:28 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Wed Aug 15 16:13:28 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Wed Aug 15 16:16:15 UTC 2012 TB --- 2012-08-15 16:16:15 - cd /src/sys/arm/conf TB --- 2012-08-15 16:16:15 - /usr/sbin/config -m DB-88F5XXX TB --- 2012-08-15 16:16:15 - building DB-88F5XXX kernel TB --- 2012-08-15 16:16:15 - CROSS_BUILD_TESTING=YES TB --- 2012-08-15 16:16:15 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-15 16:16:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-15 16:16:15 - SRCCONF=/dev/null TB --- 2012-08-15 16:16:15 - TARGET=arm TB --- 2012-08-15 16:16:15 - TARGET_ARCH=arm TB --- 2012-08-15 16:16:15 - TZ=UTC TB --- 2012-08-15 16:16:15 - __MAKE_CONF=/dev/null TB --- 2012-08-15 16:16:15 - cd /src TB --- 2012-08-15 16:16:15 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Wed Aug 15 16:16:15 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Wed Aug 15 16:18:56 UTC 2012 TB --- 2012-08-15 16:18:56 - cd /src/sys/arm/conf TB --- 2012-08-15 16:18:56 - /usr/sbin/config -m DB-88F6XXX TB --- 2012-08-15 16:18:56 - building DB-88F6XXX kernel TB --- 2012-08-15 16:18:56 - CROSS_BUILD_TESTING=YES TB --- 2012-08-15 16:18:56 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-15 16:18:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-15 16:18:56 - SRCCONF=/dev/null TB --- 2012-08-15 16:18:56 - TARGET=arm TB --- 2012-08-15 16:18:56 - TARGET_ARCH=arm TB --- 2012-08-15 16:18:56 - TZ=UTC TB --- 2012-08-15 16:18:56 - __MAKE_CONF=/dev/null TB --- 2012-08-15 16:18:56 - cd /src TB --- 2012-08-15 16:18:56 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Wed Aug 15 16:18:56 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Wed Aug 15 16:21:49 UTC 2012 TB --- 2012-08-15 16:21:49 - cd /src/sys/arm/conf TB --- 2012-08-15 16:21:49 - /usr/sbin/config -m DOCKSTAR TB --- 2012-08-15 16:21:49 - building DOCKSTAR kernel TB --- 2012-08-15 16:21:49 - CROSS_BUILD_TESTING=YES TB --- 2012-08-15 16:21:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-15 16:21:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-15 16:21:49 - SRCCONF=/dev/null TB --- 2012-08-15 16:21:49 - TARGET=arm TB --- 2012-08-15 16:21:49 - TARGET_ARCH=arm TB --- 2012-08-15 16:21:49 - TZ=UTC TB --- 2012-08-15 16:21:49 - __MAKE_CONF=/dev/null TB --- 2012-08-15 16:21:49 - cd /src TB --- 2012-08-15 16:21:49 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Wed Aug 15 16:21:50 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Wed Aug 15 16:24:25 UTC 2012 TB --- 2012-08-15 16:24:25 - cd /src/sys/arm/conf TB --- 2012-08-15 16:24:25 - /usr/sbin/config -m EA3250 TB --- 2012-08-15 16:24:25 - building EA3250 kernel TB --- 2012-08-15 16:24:25 - CROSS_BUILD_TESTING=YES TB --- 2012-08-15 16:24:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-15 16:24:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-15 16:24:25 - SRCCONF=/dev/null TB --- 2012-08-15 16:24:25 - TARGET=arm TB --- 2012-08-15 16:24:25 - TARGET_ARCH=arm TB --- 2012-08-15 16:24:25 - TZ=UTC TB --- 2012-08-15 16:24:25 - __MAKE_CONF=/dev/null TB --- 2012-08-15 16:24:25 - cd /src TB --- 2012-08-15 16:24:25 - /usr/bin/make -B buildkernel KERNCONF=EA3250 >>> Kernel build for EA3250 started on Wed Aug 15 16:24:26 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -mlittle-endian -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -march=armv5te -ffreestanding -Werror /src/sys/arm/arm/irq_dispatch.S cc -mlittle-endian -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -march=armv5te -ffreestanding -Werror /src/sys/arm/arm/cpufunc_asm_arm9.S cc -mlittle-endian -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -march=armv5te -ffreestanding -Werror /src/sys/arm/arm/cpufunc_asm_armv5.S cc -mlittle-endian -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -march=armv5te -ffreestanding -Werror /src/sys/arm/lpc/lpc_machdep.c /src/sys/arm/lpc/lpc_machdep.c:300: error: conflicting types for 'initarm' ./machine/cpu.h:48: error: previous declaration of 'initarm' was here /src/sys/arm/lpc/lpc_machdep.c: In function 'initarm': /src/sys/arm/lpc/lpc_machdep.c:342: error: too few arguments to function 'fake_preload_metadata' *** Error code 1 Stop in /obj/arm.arm/src/sys/EA3250. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-08-15 16:27:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-08-15 16:27:02 - ERROR: failed to build EA3250 kernel TB --- 2012-08-15 16:27:02 - 4254.95 user 846.45 system 6421.64 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Aug 15 18:30:10 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4BF5106564A for ; Wed, 15 Aug 2012 18:30:10 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 420EF8FC14 for ; Wed, 15 Aug 2012 18:30:08 +0000 (UTC) Received: by bkcje9 with SMTP id je9so734450bkc.13 for ; Wed, 15 Aug 2012 11:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=wnydzDeD7GxV9zS2XzCx3G6ivWHXWmbrSskzsmcO850=; b=YrE5fPcaUhD8gkrrL9I2HtCQey27K+bAPO3NDhQr3yBonDZxZ9JIUxpCW+9m/VmY9v iJtqKBK29MerooRytahY58/pDfZDU6edPBZ2uODA8Jwre9vF/23ZmooYnX4DbAonFs6Q Un9P7FCvf/8gA7yMnnREY4IeW0bSi5cdfgDqusFftZvVhpex+gPoSGAkidRGLtMyGpRd rwkDxqZjKTDUWeYt8uZlIA9VxwRlCmaF8jn+shpeyCvQcSXjhYM86o0I92d7LgUammZ/ NvwRo8CJ+2EqSL+KVo7cDKDVPpo+lSye3hQOcGkCRs815aRIG80MzsTlL+uJ5vHAbQHV EDog== Received: by 10.204.154.141 with SMTP id o13mr8072822bkw.72.1345055407409; Wed, 15 Aug 2012 11:30:07 -0700 (PDT) Received: from [192.168.1.252] (host68-104-dynamic.50-79-r.retail.telecomitalia.it. [79.50.104.68]) by mx.google.com with ESMTPS id g6sm1179505bkg.2.2012.08.15.11.30.05 (version=SSLv3 cipher=OTHER); Wed, 15 Aug 2012 11:30:06 -0700 (PDT) Message-ID: <502BEAA9.9080802@gmail.com> Date: Wed, 15 Aug 2012 20:30:01 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <5008728C.5040100@jetcafe.org> <1343846511.1128.34.camel@revolution.hippie.lan> <501B0E04.5040901@jetcafe.org> <1343951251.1128.53.camel@revolution.hippie.lan> <502AEC99.70708@jetcafe.org> <48664E9B-0BBB-4C78-B720-9920083E661A@bsdimp.com> <1345039837.27688.14.camel@revolution.hippie.lan> In-Reply-To: <1345039837.27688.14.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Building ARM ports (was Re: Globalscale Dreamplug and 8.3 RELEASE) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mattia.rossi.mate@gmail.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 18:30:10 -0000 > The biggest problem we have is build versus run dependencies. When > crossbuilding port foo to run on arm, that port decides it needs the > compile_a_foo port to build the code, so it goes off and cross-builds > compile_a_foo, then wants to run the resulting arm binaries on the x86 > host. The only way I know of to fix that is to tediously identify and > pre-build all the build-time requirements needed by any port you > intend to cross-build. Ports that have their own build systems and > custom tools are essentially impossible to work with. Those are exactly the issues I've run into when attempting to cross build. See my story here: http://matrossi.blogspot.it/2011/08/cross-compiling-ports-for-arm-under.html My Qemu experience: http://matrossi.blogspot.it/2011/09/freebsd-arm-on-qemu-in-virtualbox.html but it didn't prove useful for building ports as there wasn't enough virtual memory to build them, because it fully emulates the 32M of RAM of a gumstix board as well.. Just in case you're interested. Mat From owner-freebsd-arm@FreeBSD.ORG Wed Aug 15 18:56:08 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 667A7106564A for ; Wed, 15 Aug 2012 18:56:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 356818FC0C for ; Wed, 15 Aug 2012 18:56:08 +0000 (UTC) Received: by dadr6 with SMTP id r6so250307dad.13 for ; Wed, 15 Aug 2012 11:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FNXVsRuI9h3Dh2HXLjNKadP0Nn14aP+Tll7rIzPhNnQ=; b=XS2Y5Na0FKGBIiO5veJfpFk8deULUKej4A1UIJfmLGueh668flLKAhdYKYwpLO2zly 7H+dZf8HTHkSILahM1MovQmH+VwK1NugOJ6VrRKTokcBrED7jY3rphdGL6JJFlAT4i5x 3Q9VAA5lMmaHeVVD5P1MMcTNYdnFQGgmoYLo4buXx/Fd782gYuoCwhrrJih6ziRtOPso izMqvHdzQDg/TtEJZMxkZ7VSOyk64zWGb16hJUP6jH62QHm66woxnLcvqPuv830fLaYv TjZXl8+4ghbzZbi/msUAyE/SHPeOyFP2fkoj6NrS+1qo0ueCM6nastOqN/VxtA0ku0cq OyaQ== MIME-Version: 1.0 Received: by 10.68.192.40 with SMTP id hd8mr25099113pbc.125.1345056967394; Wed, 15 Aug 2012 11:56:07 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.43.169 with HTTP; Wed, 15 Aug 2012 11:56:07 -0700 (PDT) In-Reply-To: <1345039837.27688.14.camel@revolution.hippie.lan> References: <5008728C.5040100@jetcafe.org> <1343846511.1128.34.camel@revolution.hippie.lan> <501B0E04.5040901@jetcafe.org> <1343951251.1128.53.camel@revolution.hippie.lan> <502AEC99.70708@jetcafe.org> <48664E9B-0BBB-4C78-B720-9920083E661A@bsdimp.com> <1345039837.27688.14.camel@revolution.hippie.lan> Date: Wed, 15 Aug 2012 11:56:07 -0700 X-Google-Sender-Auth: u8gNjPl2ki2I_btM5-GFtr70sNs Message-ID: From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org Subject: Re: Building ARM ports (was Re: Globalscale Dreamplug and 8.3 RELEASE) 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, 15 Aug 2012 18:56:08 -0000 On 15 August 2012 07:10, Ian Lepore wrote: >> I have the basics, and have for years. I've posted them several times. The trouble is that they are very very basic and need more work. I think you'll need to define the problem a little better before progress can be made. Right. > The system we use at work is basically Warner's (at least I think he put > the bulk of it in place years ago). It involves defining a bunch of > environment variables that change how ports are built (I want to say > "fools" or "tricks" the ports into using cross-tools, but the negative > implications of those words may just reflect my ignorance of the > details). Right. > The biggest problem we have is build versus run dependencies. When > crossbuilding port foo to run on arm, that port decides it needs the > compile_a_foo port to build the code, so it goes off and cross-builds > compile_a_foo, then wants to run the resulting arm binaries on the x86 > host. The only way I know of to fix that is to tediously identify and > pre-build all the build-time requirements needed by any port you intend > to cross-build. Ports that have their own build systems and custom > tools are essentially impossible to work with. Well we have build tools as a make stage in building things in /usr/src. I know, I keep adding things to it when adding stuff for cross-building things. So if we know _how_ to mark something as a build time versus run time dependency, wouldn't that be good to add to the ports infrastructure? Yes, we can't cross-build _all_ports. But a bunch of basic ones to begin with would be nice (eg things like thttpd, dropbear.) Ports with their own build systems and custom tools can stay out of it for this pass. I was hoping that others with a little more build experience could be coaxed into hacking on the problem. I find it really disenheartening that the OpenWRT peeps figured this out years ago and yet we can't even make a _start_ on it in /usr/ports. Adrian From owner-freebsd-arm@FreeBSD.ORG Wed Aug 15 19:27:20 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E15E106564A for ; Wed, 15 Aug 2012 19:27:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1D0AF8FC12 for ; Wed, 15 Aug 2012 19:27:19 +0000 (UTC) Received: by yenl7 with SMTP id l7so2655292yen.13 for ; Wed, 15 Aug 2012 12:27:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=MzYPPWziBV4IEY8kc4SlUpTmIKZR+UkdKvBKAZROMN8=; b=Tsp2po9gjFx5A4okpgwWZ+cp7eeOQNLIT+Za6Pl/eFbcxRWjtta0LkE4DqYCDaPQgO IQBX/8oi2I8sKomTDLeBTZ1D1nCN82TddHYIyZnL+o0AyssVsA/dVUo+jWpyp2Yqam4A 8yxyxaWxRtEcZhfSY2KVy/BTX5WM/TfHV5H3pJEFqVNg+spzqphnf6vqYtGsUWyB0mA0 DWD2TymoVJSuNQpxiFaxojQ5W46LzlWadymrDckK+gUte5PgodWpfJuJtAB6GN2nLh4W IhlmifTJG1umurbaAqaj8HeDUGrVGLVagDuJ9r/LG+y9tfCvWUxMz1BcUIhUiNWTWQiG XJYw== Received: by 10.236.117.97 with SMTP id i61mr21184235yhh.73.1345058839024; Wed, 15 Aug 2012 12:27:19 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id t16sm2189857anj.21.2012.08.15.12.27.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Aug 2012 12:27:18 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <502BEAA9.9080802@gmail.com> Date: Wed, 15 Aug 2012 13:27:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1EB213FA-1B3D-467E-B733-064938E7D96F@bsdimp.com> References: <5008728C.5040100@jetcafe.org> <1343846511.1128.34.camel@revolution.hippie.lan> <501B0E04.5040901@jetcafe.org> <1343951251.1128.53.camel@revolution.hippie.lan> <502AEC99.70708@jetcafe.org> <48664E9B-0BBB-4C78-B720-9920083E661A@bsdimp.com> <1345039837.27688.14.camel@revolution.hippie.lan> <502BEAA9.9080802@gmail.com> To: mattia.rossi.mate@gmail.com X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlRrDAXMq284pGdUrBdC8d0kqQ3qX/82aN8+NufkDEoQl0xYrgQT3LhfpdjXJXwfNptWRFo Cc: freebsd-arm@freebsd.org Subject: Re: Building ARM ports (was Re: Globalscale Dreamplug and 8.3 RELEASE) 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, 15 Aug 2012 19:27:20 -0000 On Aug 15, 2012, at 12:30 PM, Mattia Rossi wrote: >=20 >> The biggest problem we have is build versus run dependencies. When = crossbuilding port foo to run on arm, that port decides it needs the = compile_a_foo port to build the code, so it goes off and cross-builds = compile_a_foo, then wants to run the resulting arm binaries on the x86 = host. The only way I know of to fix that is to tediously identify and = pre-build all the build-time requirements needed by any port you intend = to cross-build. Ports that have their own build systems and custom tools = are essentially impossible to work with. >=20 > Those are exactly the issues I've run into when attempting to cross = build. See my story here: >=20 > = http://matrossi.blogspot.it/2011/08/cross-compiling-ports-for-arm-under.ht= ml Yes. That's why you need something more than the hackish thing that I = did that groks BUILD vs RUN depends and builds the BUILD depends native = and the RUN depends cross. I looked at this back in the day and found = it was easier to do the following hackish thing: (1) Create a chroot for building (we were doing this anyway) (2) Create a port that described all the build depends. Build and = install it in the chroot. (3) Then build the runtime ports with the cross compilers in the same = chroot, but I needed hacks to install the packages into a different = place, that was groked for chained dependencies and such. A bit of a PITA, and I never filed the rough edges off of this enough to = even commit it to the TSC tree. It is a very time-intensive = investigation to look into this stuff too, but maybe machines are fast = enough that it isn't too horrible for the general case. > My Qemu experience: >=20 > = http://matrossi.blogspot.it/2011/09/freebsd-arm-on-qemu-in-virtualbox.html= >=20 > but it didn't prove useful for building ports as there wasn't enough = virtual memory to build them, because it fully emulates the 32M of RAM = of a gumstix board as well.. There's hacks that make qemu emulate the boards with 2GB of RAM floating = about... Warner From owner-freebsd-arm@FreeBSD.ORG Wed Aug 15 19:29:54 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABA09106564A for ; Wed, 15 Aug 2012 19:29:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 58B188FC08 for ; Wed, 15 Aug 2012 19:29:54 +0000 (UTC) Received: by yhfs35 with SMTP id s35so2644088yhf.13 for ; Wed, 15 Aug 2012 12:29:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=gcFMsEjeN9gCo8A62sZP35UxRXVcVlElEbetaxlcOJM=; b=BUtHK9vK0PJMwS55CtfqTaF8UXOwdPm+CL4hK5vqjaHXc2VFZ7r/bc3m+FmuV5ux27 fEmGOYEKMHhS4Q6+lHFnFCivfENJW/eQzolmQaICBmkULlDXc86iqwBDdT+i09b6W8on HF8cxc/QTBLnIcxibaqayd2uw5AqjX/czwuqjNQO5AziPRCPRoMOTrMkbOUhodrlE1/G 5UzIZ9Dc0hoMvXdW7/utipv7+1ix0rfhePN+YGrkoIlR+G8FTZOQecdEzo5o0z8ClwaK WIofczMybU3EbWhepJO0lC2EUEHsaKJefpLHAaSVQccxjuE9Mi7Y/Dylmaic5RUW4J5N bL9w== Received: by 10.236.173.164 with SMTP id v24mr20899638yhl.60.1345058993565; Wed, 15 Aug 2012 12:29:53 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id x3sm4333369yhd.9.2012.08.15.12.29.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Aug 2012 12:29:52 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 15 Aug 2012 13:29:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5008728C.5040100@jetcafe.org> <1343846511.1128.34.camel@revolution.hippie.lan> <501B0E04.5040901@jetcafe.org> <1343951251.1128.53.camel@revolution.hippie.lan> <502AEC99.70708@jetcafe.org> <48664E9B-0BBB-4C78-B720-9920083E661A@bsdimp.com> <1345039837.27688.14.camel@revolution.hippie.lan> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQn6Mj0AoXuWClSCvWlDpdVYCpbtdUFmicy4drn7srpGK2jtzxEs72B73ELW6U9h9DZAtXRd Cc: freebsd-arm@freebsd.org Subject: Re: Building ARM ports (was Re: Globalscale Dreamplug and 8.3 RELEASE) 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, 15 Aug 2012 19:29:54 -0000 On Aug 15, 2012, at 12:56 PM, Adrian Chadd wrote: > On 15 August 2012 07:10, Ian Lepore = wrote: >=20 >>> I have the basics, and have for years. I've posted them several = times. The trouble is that they are very very basic and need more work. = I think you'll need to define the problem a little better before = progress can be made. >=20 > Right. >=20 >> The system we use at work is basically Warner's (at least I think he = put >> the bulk of it in place years ago). It involves defining a bunch of >> environment variables that change how ports are built (I want to say >> "fools" or "tricks" the ports into using cross-tools, but the = negative >> implications of those words may just reflect my ignorance of the >> details). >=20 > Right. >=20 >> The biggest problem we have is build versus run dependencies. When >> crossbuilding port foo to run on arm, that port decides it needs the >> compile_a_foo port to build the code, so it goes off and cross-builds >> compile_a_foo, then wants to run the resulting arm binaries on the = x86 >> host. The only way I know of to fix that is to tediously identify = and >> pre-build all the build-time requirements needed by any port you = intend >> to cross-build. Ports that have their own build systems and custom >> tools are essentially impossible to work with. >=20 > Well we have build tools as a make stage in building things in > /usr/src. I know, I keep adding things to it when adding stuff for > cross-building things. >=20 > So if we know _how_ to mark something as a build time versus run time > dependency, wouldn't that be good to add to the ports infrastructure? >=20 > Yes, we can't cross-build _all_ports. But a bunch of basic ones to > begin with would be nice (eg things like thttpd, dropbear.) Ports with > their own build systems and custom tools can stay out of it for this > pass. >=20 > I was hoping that others with a little more build experience could be > coaxed into hacking on the problem. I find it really disenheartening > that the OpenWRT peeps figured this out years ago and yet we can't > even make a _start_ on it in /usr/ports. Now that ports is in svn, maybe we need a projects/xports to get = started. We could dump my crap there, and then start to work out the = build vs run issues and go from there. This is a very time-intensive project, but with enough hands, and a = place to save the work so we don't start from scratch each time, I think = we can make progress. Lots of the nay-sayers will STFU if we get to the = point of building some useful number of ports this way (say 100). And = if it fails, we can delete the branch :) Warner= From owner-freebsd-arm@FreeBSD.ORG Thu Aug 16 14:28:35 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 09D77106566C for ; Thu, 16 Aug 2012 14:28:35 +0000 (UTC) (envelope-from noreply+6hobyw@twoomail.com) Received: from cmx6.massivemedia.eu (cmx6.massivemedia.eu [77.73.180.53]) by mx1.freebsd.org (Postfix) with ESMTP id 269BB8FC1C for ; Thu, 16 Aug 2012 14:28:33 +0000 (UTC) DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws; s=twoo; d=twoomail.com; h=DKIM-Signature:Received:Message-ID:From:To:Reply-To:Sender:Subject:List-Unsubscribe:Date:X-MM-ID:X-rpcampaign:MIME-Version:Content-Type; b=mHJza153qYAiL+lyQf9tlS1FkIyqJOUIb9Bu0KgBYe7DXNQNHEPP80z+QzAYpUlL nONrrFgcSt3D9bGxijSyWkUXNYXRzhOhVLr3/QK5jXsWf9gpCzIk6temffwtIZjX c/J4LJYFwq6NB4N5ObaJmeee74AvbwjNkq3xEmaGd14= DKIM-Signature: v=1; a=rsa-sha1; d=twoomail.com; s=twoo; c=relaxed/simple; q=dns/txt; i=@twoomail.com; t=1345126103; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=kYW6gqodkbGXIaUWMSbPOnUhi8Q=; b=KWkvws+BHeYVFF/M6GsgGhXv8DzHiHq8EYH/Bga5+DLXVWk1lEZKSp45RCivw+WM INKwHTjQlLH0MRCkPr4o7lgP2/NU74lxcv80ovdvdPgr0qkL/BT9oFA6K3+tVDco XgynXRJqFCTf//kbGLgB4AdJaWc7rWIueG4aiJa1kJo=; Received: from [192.168.10.32] ([192.168.10.32:46540] helo=web) by mx19.netlogmail.com (envelope-from ) (ecelerity 3.0.26.37820 r(37820)) with ESMTP id 3A/36-11137-7DEFC205; Thu, 16 Aug 2012 16:08:23 +0200 Message-ID: <3A.36.11137.7DEFC205@mail04> From: "Nataraj via Twoo" To: "freebsd-arm@freebsd.org" Sender: noreply+6hobyw@twoomail.com Date: Thu, 16 Aug 2012 14:08:23 +0000 X-MM-ID: -6aWQ9NmhvYnl3LG1taWQ9NzktNmhvYnl3LTZodWp6bnJ0LWMzMixhcHBpZD0yLHQ9NDYscz0yLHY9MjgsdT0sZj0xMzc5OTA3MCxpdD1iJm09cA== X-rpcampaign: Twoo0460020280 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Reminder: Nataraj you as a contact on Twoo and wants to connect X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "noreply+6hobyw@twoomail.com" List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 14:28:35 -0000 I found an exclusive and fun way to meet new people online: Twoo.com. ---------------------------------------------------------------- Hi there, Just a heads-up that your friend Nataraj is having a great time meeting new people on Twoo. Join in! Copy/paste the following link into your web browser: http://twoo.com/m/bxvtMJH37 ---------------------------------------------------------------- Don't want to receive these mails? Follow this link: http://twoo.com/m/PcUE_C3V TWOO NV/SA, Grainsborough House, 81 Oxford Street, W1D 2EU London, United Kingdom info-en@twoo.com BE0834322338. From owner-freebsd-arm@FreeBSD.ORG Thu Aug 16 22:17:34 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3895F1065680; Thu, 16 Aug 2012 22:17:34 +0000 (UTC) (envelope-from gonzo@hq.bluezbox.com) Received: from hq.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id EDC788FC08; Thu, 16 Aug 2012 22:17:33 +0000 (UTC) Received: from [140.242.210.2] (helo=vanmgmt02.vancouver.polycom.com) by hq.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1T28NG-0000EE-6m; Thu, 16 Aug 2012 15:17:06 -0700 From: Oleksandr Tymoshenko Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 16 Aug 2012 15:17:26 -0700 Message-Id: <8B16B6D3-A9C1-487E-9C42-6EDD07D689D4@freebsd.org> To: "arm@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1463\)) X-Mailer: Apple Mail (2.1463) Sender: gonzo@hq.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Hello, projects/armv6 branch was merged to HEAD and should be considered dead now. This patch is a result of a joint effort by many people. Including but not limited to: Grzegorz Bernacki (gber@) Aleksander Dutkowski Ben R. Gray (bgray@) Olivier Houchard (cognet@) Rafal Jaworowski (raj@) and Semihalf team Tim Kientzle (kientzle@) Jakub Wojciech Klama (jceel@) Ian Lepore Warner Losh (imp@) Damjan Marion (dmarion@) Lukasz Plachno Stanislav Sedov (stas@) Mark Tinguely Andrew Turner (andrew@) [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Cc: arch@freebsd.org, hackers@freebsd.org Subject: projects/armv6 merged to HEAD 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, 16 Aug 2012 22:17:34 -0000 Hello, projects/armv6 branch was merged to HEAD and should be considered dead now. This patch is a result of a joint effort by many people. Including but not limited to: Grzegorz Bernacki (gber@) Aleksander Dutkowski Ben R. Gray (bgray@) Olivier Houchard (cognet@) Rafal Jaworowski (raj@) and Semihalf team Tim Kientzle (kientzle@) Jakub Wojciech Klama (jceel@) Ian Lepore Warner Losh (imp@) Damjan Marion (dmarion@) Lukasz Plachno Stanislav Sedov (stas@) Mark Tinguely Andrew Turner (andrew@) Thanks to all, who contributed by submitting code, testing and giving valuable advices. Code drop includes following parts: - General ARMv6/ARMv7 kernel bits (pmap, cache, assembler routines, etc...) - ARM SMP support - VFP/Neon support - ARM Generic Interrupt Controller driver - Improved thread-local storage for cpus >=ARMv6 - Two new values for TARGET_ARCH: armv6 and armv6eb - Driver for SMSC LAN95XX and LAN8710A ethernet controllers - Marvell MV78x60 support (multiuser, ARMADA XP kernel config) - TI OMAP4 and AM335x support (multiuser, no GPU or graphics support, kernel configs for Pandaboard and Beaglebone) - LPC32x0 support (multiuser, frame buffer works with SSD1289 LCD controller.Embedded Artists EA3250 kernel config) - Barebone Nvidia Tegra2 support (timers, interrupts and UART. No kernel config) Hope now that the code is in trunk it will get more attention and love from developers. Happy hacking -- gonzo From owner-freebsd-arm@FreeBSD.ORG Fri Aug 17 09:24:24 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C7AF106564A; Fri, 17 Aug 2012 09:24:24 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F36C28FC15; Fri, 17 Aug 2012 09:24:23 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 8D5A746B20; Fri, 17 Aug 2012 05:24:23 -0400 (EDT) Date: Fri, 17 Aug 2012 10:24:23 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Oleksandr Tymoshenko In-Reply-To: <8B16B6D3-A9C1-487E-9C42-6EDD07D689D4@freebsd.org> Message-ID: References: <8B16B6D3-A9C1-487E-9C42-6EDD07D689D4@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "arm@freebsd.org" , arch@freebsd.org, hackers@freebsd.org Subject: Re: projects/armv6 merged to HEAD 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, 17 Aug 2012 09:24:24 -0000 On Thu, 16 Aug 2012, Oleksandr Tymoshenko wrote: > projects/armv6 branch was merged to HEAD and should be considered dead now. > This patch is a result of a joint effort by many people. Including but not > limited to: Amazing work -- many thanks are due to to everyone who was involved! Robert > > Grzegorz Bernacki (gber@) > Aleksander Dutkowski > Ben R. Gray (bgray@) > Olivier Houchard (cognet@) > Rafal Jaworowski (raj@) and Semihalf team > Tim Kientzle (kientzle@) > Jakub Wojciech Klama (jceel@) > Ian Lepore > Warner Losh (imp@) > Damjan Marion (dmarion@) > Lukasz Plachno > Stanislav Sedov (stas@) > Mark Tinguely > Andrew Turner (andrew@) > > Thanks to all, who contributed by submitting code, > testing and giving valuable advices. > > Code drop includes following parts: > > - General ARMv6/ARMv7 kernel bits (pmap, cache, > assembler routines, etc...) > - ARM SMP support > - VFP/Neon support > - ARM Generic Interrupt Controller driver > - Improved thread-local storage for cpus >=ARMv6 > - Two new values for TARGET_ARCH: armv6 and armv6eb > - Driver for SMSC LAN95XX and LAN8710A ethernet controllers > - Marvell MV78x60 support (multiuser, ARMADA XP kernel config) > - TI OMAP4 and AM335x support (multiuser, no GPU or graphics > support, kernel configs for Pandaboard and Beaglebone) > - LPC32x0 support (multiuser, frame buffer works with SSD1289 > LCD controller.Embedded Artists EA3250 kernel config) > - Barebone Nvidia Tegra2 support (timers, interrupts and UART. > No kernel config) > > Hope now that the code is in trunk it will get more attention > and love from developers. > > Happy hacking > > -- > gonzo > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Fri Aug 17 22:10:21 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0487106566C for ; Fri, 17 Aug 2012 22:10:20 +0000 (UTC) (envelope-from dave@jetcafe.org) Received: from nahkohe.jetcafe.org (nahkohe.jetcafe.org [205.147.26.32]) by mx1.freebsd.org (Postfix) with ESMTP id B105C8FC12 for ; Fri, 17 Aug 2012 22:10:20 +0000 (UTC) X-Envelope-To: freebsd-arm@freebsd.org Received: from [205.147.26.5] (hokkshideh4.jetcafe.org [205.147.26.5]) by nahkohe.jetcafe.org (8.14.2/8.14.2) with ESMTP id q7HMA4rq096330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2012 15:10:06 -0700 (PDT) Message-ID: <502EC13C.2080402@jetcafe.org> Date: Fri, 17 Aug 2012 15:10:04 -0700 From: Dave Hayes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120612 Thunderbird/13.0 MIME-Version: 1.0 To: Warner Losh References: <5008728C.5040100@jetcafe.org> <1343846511.1128.34.camel@revolution.hippie.lan> <501B0E04.5040901@jetcafe.org> <1343951251.1128.53.camel@revolution.hippie.lan> <502AEC99.70708@jetcafe.org> <55EAC835-9838-4802-8B2C-73B32FC6513F@bsdimp.com> In-Reply-To: <55EAC835-9838-4802-8B2C-73B32FC6513F@bsdimp.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Building ARM ports (was Re: Globalscale Dreamplug and 8.3 RELEASE) 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, 17 Aug 2012 22:10:21 -0000 On 08/14/12 19:42, Warner Losh wrote: > > On Aug 14, 2012, at 6:26 PM, Dave Hayes wrote: > >> On 08/02/12 16:47, Ian Lepore wrote: >>> I haven't yet tried to build ports using stock freebsd. At work we have >>> an arcane and complex and fragile system for cross-building ports, which >>> I only partially understand. >> >> That's the entire problem with cross-building. Ports are very complex systems and I think it's cleaner to just build them in an ARM emulator. >> There are far too many dependencies to keep track of otherwise, at least >> for me. > > Yet the Linux folks are able to do it. If we want to be competitive, we'll need to have a viable solution. To be clear, I wasn't referencing ability when I wrote that, it was more of a time efficiency comment. Obviously it's possible. :) As I understand the ports system, ports are not generally created with the idea of cross-compilation. Thus, I posit that it's best (lacking fancier hardware) in terms of time spent and port build integrity to run an emulator and do my port builds in a clean environment. I could be very wrong here. QEMU may accomplish the goal of a compiled ARM port, but what other requirement am I missing? >> When I find time to struggle with QEMU again, I'll try to post a summary here...presuming I can get this to work. > This may or may not ultimately work. I hope that the complexity of this is actually less than getting it right in the cross building world. It is certainly appearing to be a struggle. I'm using virtualbox to run a machine which runs QEMU, that might actually be my problem. However, I'm under the impression that *this* struggle is much more likely to not affect the integrity of a ports build. -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< Advice is priceless --- when it becomes interference it is preposterous. From owner-freebsd-arm@FreeBSD.ORG Sat Aug 18 17:53:04 2012 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 28486106566C for ; Sat, 18 Aug 2012 17:53:04 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh10.mail.rice.edu (mh10.mail.rice.edu [128.42.201.30]) by mx1.freebsd.org (Postfix) with ESMTP id EC7CE8FC08 for ; Sat, 18 Aug 2012 17:53:00 +0000 (UTC) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id 33970604F6 for ; Sat, 18 Aug 2012 12:53:00 -0500 (CDT) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id 3205D604ED; Sat, 18 Aug 2012 12:53:00 -0500 (CDT) X-Virus-Scanned: by amavis-2.7.0 at mh10.mail.rice.edu, auth channel Received: from mh10.mail.rice.edu ([127.0.0.1]) by mh10.mail.rice.edu (mh10.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id kOplWS-OGjGz; Sat, 18 Aug 2012 12:53:00 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh10.mail.rice.edu (Postfix) with ESMTPSA id 9A540603D3; Sat, 18 Aug 2012 12:52:59 -0500 (CDT) Message-ID: <502FD67A.7030003@rice.edu> Date: Sat, 18 Aug 2012 12:52:58 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: "arm@freebsd.org" Content-Type: multipart/mixed; boundary="------------020600000709070506010501" Cc: Alan Cox Subject: arm pmap locking 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, 18 Aug 2012 17:53:04 -0000 This is a multi-part message in MIME format. --------------020600000709070506010501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Can someone here please test the attached patch? I'm currently working my way through the various pmap implementations eliminating the use of the page queues lock. Arm is next on my list. Alan --------------020600000709070506010501 Content-Type: text/plain; name="arm_pmap2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arm_pmap2.patch" Index: arm/arm/pmap.c =================================================================== --- arm/arm/pmap.c (revision 239352) +++ arm/arm/pmap.c (working copy) @@ -150,6 +150,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include @@ -408,6 +409,7 @@ static vm_offset_t pmap_kernel_l2ptp_kva; static vm_paddr_t pmap_kernel_l2ptp_phys; static struct vm_object pvzone_obj; static int pv_entry_count=0, pv_entry_max=0, pv_entry_high_water=0; +static struct rwlock pvh_global_lock; /* * This list exists for the benefit of pmap_map_chunk(). It keeps track @@ -866,7 +868,7 @@ pmap_alloc_l2_bucket(pmap_t pm, vm_offset_t va) l1idx = L1_IDX(va); PMAP_ASSERT_LOCKED(pm); - mtx_assert(&vm_page_queue_mtx, MA_OWNED); + rw_assert(&pvh_global_lock, RA_WLOCKED); if ((l2 = pm->pm_l2[L2_IDX(l1idx)]) == NULL) { /* * No mapping at this address, as there is @@ -875,19 +877,19 @@ pmap_alloc_l2_bucket(pmap_t pm, vm_offset_t va) */ again_l2table: PMAP_UNLOCK(pm); - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); if ((l2 = pmap_alloc_l2_dtable()) == NULL) { - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); PMAP_LOCK(pm); return (NULL); } - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); PMAP_LOCK(pm); if (pm->pm_l2[L2_IDX(l1idx)] != NULL) { PMAP_UNLOCK(pm); - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); uma_zfree(l2table_zone, l2); - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); PMAP_LOCK(pm); l2 = pm->pm_l2[L2_IDX(l1idx)]; if (l2 == NULL) @@ -919,16 +921,16 @@ again_l2table: */ again_ptep: PMAP_UNLOCK(pm); - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); ptep = (void*)uma_zalloc(l2zone, M_NOWAIT|M_USE_RESERVE); - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); PMAP_LOCK(pm); if (l2b->l2b_kva != 0) { /* We lost the race. */ PMAP_UNLOCK(pm); - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); uma_zfree(l2zone, ptep); - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); PMAP_LOCK(pm); if (l2b->l2b_kva == 0) goto again_ptep; @@ -1314,7 +1316,7 @@ pmap_fix_cache(struct vm_page *pg, pmap_t pm, vm_o int entries = 0, kentries = 0, uentries = 0; struct pv_entry *pv; - mtx_assert(&vm_page_queue_mtx, MA_OWNED); + rw_assert(&pvh_global_lock, RA_WLOCKED); /* the cache gets written back/invalidated on context switch. * therefore, if a user page shares an entry in the same page or @@ -1426,7 +1428,7 @@ pmap_clearbit(struct vm_page *pg, u_int maskbits) u_int oflags; int count = 0; - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); if (maskbits & PVF_WRITE) maskbits |= PVF_MOD; @@ -1436,7 +1438,7 @@ pmap_clearbit(struct vm_page *pg, u_int maskbits) pg->md.pvh_attrs &= ~(maskbits & (PVF_MOD | PVF_REF)); if (TAILQ_EMPTY(&pg->md.pv_list)) { - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); return (0); } @@ -1572,7 +1574,7 @@ pmap_clearbit(struct vm_page *pg, u_int maskbits) if (maskbits & PVF_WRITE) vm_page_aflag_clear(pg, PGA_WRITEABLE); - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); return (count); } @@ -1601,7 +1603,7 @@ pmap_enter_pv(struct vm_page *pg, struct pv_entry int km; - mtx_assert(&vm_page_queue_mtx, MA_OWNED); + rw_assert(&pvh_global_lock, RA_WLOCKED); if (pg->md.pv_kva) { /* PMAP_ASSERT_LOCKED(pmap_kernel()); */ @@ -1615,10 +1617,10 @@ pmap_enter_pv(struct vm_page *pg, struct pv_entry TAILQ_INSERT_HEAD(&pg->md.pv_list, pve, pv_list); TAILQ_INSERT_HEAD(&pve->pv_pmap->pm_pvlist, pve, pv_plist); PMAP_UNLOCK(pmap_kernel()); - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); if ((pve = pmap_get_pv_entry()) == NULL) panic("pmap_kenter_internal: no pv entries"); - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); if (km) PMAP_LOCK(pmap_kernel()); } @@ -1647,7 +1649,7 @@ pmap_find_pv(struct vm_page *pg, pmap_t pm, vm_off { struct pv_entry *pv; - mtx_assert(&vm_page_queue_mtx, MA_OWNED); + rw_assert(&pvh_global_lock, RA_WLOCKED); TAILQ_FOREACH(pv, &pg->md.pv_list, pv_list) if (pm == pv->pv_pmap && va == pv->pv_va) break; @@ -1691,7 +1693,7 @@ pmap_nuke_pv(struct vm_page *pg, pmap_t pm, struct { struct pv_entry *pv; - mtx_assert(&vm_page_queue_mtx, MA_OWNED); + rw_assert(&pvh_global_lock, RA_WLOCKED); PMAP_ASSERT_LOCKED(pm); TAILQ_REMOVE(&pg->md.pv_list, pve, pv_list); TAILQ_REMOVE(&pm->pm_pvlist, pve, pv_plist); @@ -1737,7 +1739,7 @@ pmap_remove_pv(struct vm_page *pg, pmap_t pm, vm_o { struct pv_entry *pve; - mtx_assert(&vm_page_queue_mtx, MA_OWNED); + rw_assert(&pvh_global_lock, RA_WLOCKED); pve = TAILQ_FIRST(&pg->md.pv_list); while (pve) { @@ -1771,7 +1773,7 @@ pmap_modify_pv(struct vm_page *pg, pmap_t pm, vm_o u_int flags, oflags; PMAP_ASSERT_LOCKED(pm); - mtx_assert(&vm_page_queue_mtx, MA_OWNED); + rw_assert(&pvh_global_lock, RA_WLOCKED); if ((npv = pmap_find_pv(pg, pm, va)) == NULL) return (0); @@ -1878,7 +1880,7 @@ pmap_fault_fixup(pmap_t pm, vm_offset_t va, vm_pro int rv = 0; l1idx = L1_IDX(va); - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); PMAP_LOCK(pm); /* @@ -2075,7 +2077,7 @@ pmap_fault_fixup(pmap_t pm, vm_offset_t va, vm_pro rv = 1; out: - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); PMAP_UNLOCK(pm); return (rv); } @@ -2400,6 +2402,11 @@ pmap_bootstrap(vm_offset_t firstaddr, vm_offset_t CPU_FILL(&kernel_pmap->pm_active); kernel_pmap->pm_domain = PMAP_DOMAIN_KERNEL; TAILQ_INIT(&kernel_pmap->pm_pvlist); + + /* + * Initialize the global pv list lock. + */ + rw_init(&pvh_global_lock, "pmap pv global"); /* * Reserve some special page table entries/VA space for temporary @@ -2672,7 +2679,7 @@ pmap_remove_pages(pmap_t pmap) vm_page_t m; pt_entry_t *pt; - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); PMAP_LOCK(pmap); cpu_idcache_wbinv_all(); cpu_l2cache_wbinv_all(); @@ -2701,7 +2708,7 @@ pmap_remove_pages(pmap_t pmap) pmap_free_pv_entry(pv); pmap_free_l2_bucket(pmap, l2b, 1); } - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); cpu_tlb_flushID(); cpu_cpwait(); PMAP_UNLOCK(pmap); @@ -2826,13 +2833,13 @@ pmap_kenter_internal(vm_offset_t va, vm_offset_t p * This expects the physical memory to have vm_page_array entry. */ if (pvzone != NULL && (m = vm_phys_paddr_to_vm_page(pa))) { - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); if (!TAILQ_EMPTY(&m->md.pv_list) || m->md.pv_kva) { /* release vm_page lock for pv_entry UMA */ - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); if ((pve = pmap_get_pv_entry()) == NULL) panic("pmap_kenter_internal: no pv entries"); - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); PMAP_LOCK(pmap_kernel()); pmap_enter_pv(m, pve, pmap_kernel(), va, PVF_WRITE | PVF_UNMAN); @@ -2841,7 +2848,7 @@ pmap_kenter_internal(vm_offset_t va, vm_offset_t p } else { m->md.pv_kva = va; } - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); } } @@ -2902,13 +2909,13 @@ pmap_kremove(vm_offset_t va) /* note: should never have to remove an allocation * before the pvzone is initialized. */ - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); PMAP_LOCK(pmap_kernel()); if (pvzone != NULL && (m = vm_phys_paddr_to_vm_page(pa)) && (pve = pmap_remove_pv(m, pmap_kernel(), va))) pmap_free_pv_entry(pve); PMAP_UNLOCK(pmap_kernel()); - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); va = va & ~PAGE_MASK; cpu_dcache_wbinv_range(va, PAGE_SIZE); cpu_l2cache_wbinv_range(va, PAGE_SIZE); @@ -3126,7 +3133,7 @@ pmap_remove_all(vm_page_t m) ("pmap_remove_all: page %p is not managed", m)); if (TAILQ_EMPTY(&m->md.pv_list)) return; - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); pmap_remove_write(m); curpm = vmspace_pmap(curproc->p_vmspace); while ((pv = TAILQ_FIRST(&m->md.pv_list)) != NULL) { @@ -3175,7 +3182,7 @@ pmap_remove_all(vm_page_t m) pmap_tlb_flushD(curpm); } vm_page_aflag_clear(m, PGA_WRITEABLE); - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); } @@ -3208,7 +3215,7 @@ pmap_protect(pmap_t pm, vm_offset_t sva, vm_offset return; } - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); PMAP_LOCK(pm); /* @@ -3275,7 +3282,7 @@ pmap_protect(pmap_t pm, vm_offset_t sva, vm_offset if (PV_BEEN_REFD(flags)) pmap_tlb_flushD(pm); } - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); PMAP_UNLOCK(pm); } @@ -3299,10 +3306,10 @@ pmap_enter(pmap_t pmap, vm_offset_t va, vm_prot_t vm_prot_t prot, boolean_t wired) { - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); PMAP_LOCK(pmap); pmap_enter_locked(pmap, va, m, prot, wired, M_WAITOK); - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); PMAP_UNLOCK(pmap); } @@ -3322,7 +3329,7 @@ pmap_enter_locked(pmap_t pmap, vm_offset_t va, vm_ vm_paddr_t pa; PMAP_ASSERT_LOCKED(pmap); - mtx_assert(&vm_page_queue_mtx, MA_OWNED); + rw_assert(&pvh_global_lock, RA_WLOCKED); if (va == vector_page) { pa = systempage.pv_pa; m = NULL; @@ -3352,9 +3359,9 @@ do_l2b_alloc: if (l2b == NULL) { if (flags & M_WAITOK) { PMAP_UNLOCK(pmap); - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); VM_WAIT; - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); PMAP_LOCK(pmap); goto do_l2b_alloc; } @@ -3594,14 +3601,14 @@ pmap_enter_object(pmap_t pmap, vm_offset_t start, psize = atop(end - start); m = m_start; - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); PMAP_LOCK(pmap); while (m != NULL && (diff = m->pindex - m_start->pindex) < psize) { pmap_enter_locked(pmap, start + ptoa(diff), m, prot & (VM_PROT_READ | VM_PROT_EXECUTE), FALSE, M_NOWAIT); m = TAILQ_NEXT(m, listq); } - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); PMAP_UNLOCK(pmap); } @@ -3618,11 +3625,11 @@ void pmap_enter_quick(pmap_t pmap, vm_offset_t va, vm_page_t m, vm_prot_t prot) { - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); PMAP_LOCK(pmap); pmap_enter_locked(pmap, va, m, prot & (VM_PROT_READ | VM_PROT_EXECUTE), FALSE, M_NOWAIT); - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); PMAP_UNLOCK(pmap); } @@ -3640,7 +3647,7 @@ pmap_change_wiring(pmap_t pmap, vm_offset_t va, bo pt_entry_t *ptep, pte; vm_page_t pg; - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); PMAP_LOCK(pmap); l2b = pmap_get_l2_bucket(pmap, va); KASSERT(l2b, ("No l2b bucket in pmap_change_wiring")); @@ -3649,7 +3656,7 @@ pmap_change_wiring(pmap_t pmap, vm_offset_t va, bo pg = PHYS_TO_VM_PAGE(l2pte_pa(pte)); if (pg) pmap_modify_pv(pg, pmap, va, PVF_WIRED, wired ? PVF_WIRED : 0); - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); PMAP_UNLOCK(pmap); } @@ -3895,7 +3902,7 @@ pmap_remove(pmap_t pm, vm_offset_t sva, vm_offset_ * we lock in the pmap => pv_head direction */ - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); PMAP_LOCK(pm); total = 0; while (sva < eva) { @@ -3989,7 +3996,7 @@ pmap_remove(pmap_t pm, vm_offset_t sva, vm_offset_ pmap_free_l2_bucket(pm, l2b, mappings); } - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); if (flushall) cpu_tlb_flushID(); PMAP_UNLOCK(pm); @@ -4405,7 +4412,7 @@ pmap_page_exists_quick(pmap_t pmap, vm_page_t m) KASSERT((m->oflags & VPO_UNMANAGED) == 0, ("pmap_page_exists_quick: page %p is not managed", m)); rv = FALSE; - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); TAILQ_FOREACH(pv, &m->md.pv_list, pv_list) { if (pv->pv_pmap == pmap) { rv = TRUE; @@ -4415,7 +4422,7 @@ pmap_page_exists_quick(pmap_t pmap, vm_page_t m) if (loops >= 16) break; } - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); return (rv); } @@ -4434,11 +4441,11 @@ pmap_page_wired_mappings(vm_page_t m) count = 0; if ((m->oflags & VPO_UNMANAGED) != 0) return (count); - vm_page_lock_queues(); + rw_wlock(&pvh_global_lock); TAILQ_FOREACH(pv, &m->md.pv_list, pv_list) if ((pv->pv_flags & PVF_WIRED) != 0) count++; - vm_page_unlock_queues(); + rw_wunlock(&pvh_global_lock); return (count); } --------------020600000709070506010501-- From owner-freebsd-arm@FreeBSD.ORG Sat Aug 18 18:45:18 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1157106564A for ; Sat, 18 Aug 2012 18:45:17 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id CF6D78FC12 for ; Sat, 18 Aug 2012 18:45:17 +0000 (UTC) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta11.emeryville.ca.mail.comcast.net with comcast id oJPF1j00317UAYkABJlBRv; Sat, 18 Aug 2012 18:45:11 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta13.emeryville.ca.mail.comcast.net with comcast id oJlA1j00L4NgCEG8ZJlANF; Sat, 18 Aug 2012 18:45:11 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q7IIj9K8019273; Sat, 18 Aug 2012 12:45:09 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Alan Cox In-Reply-To: <502FD67A.7030003@rice.edu> References: <502FD67A.7030003@rice.edu> Content-Type: multipart/mixed; boundary="=-zJM3S0EIs7z7F5IYigI9" Date: Sat, 18 Aug 2012 12:45:08 -0600 Message-ID: <1345315508.27688.260.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: "arm@freebsd.org" Subject: Re: arm pmap locking 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, 18 Aug 2012 18:45:18 -0000 --=-zJM3S0EIs7z7F5IYigI9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sat, 2012-08-18 at 12:52 -0500, Alan Cox wrote: > Can someone here please test the attached patch? I'm currently working > my way through the various pmap implementations eliminating the use of > the page queues lock. Arm is next on my list. > > Alan I get a panic for recursion on my dreamplug, see attached. I applied the patches over this: FreeBSD dpcur 10.0-CURRENT FreeBSD 10.0-CURRENT #4 r239193M: Sat Aug 18 12:37:24 MDT 2012 The 'M' is some dreamplug-specific changes (dts files, etc). I had a quick look and it didn't seem like any of the checkins since r239193 were related to arm pmap. I can try a fresher checkout when I have more time if you think it's important. I tried adding WITNESS to see if it would get you more info, but it panics for a LOR before getting to the panic in the attached output. That's not new, it's been there for a while and I haven't had any time to chase it down. -- Ian --=-zJM3S0EIs7z7F5IYigI9 Content-Disposition: attachment; filename="dp_pmap_panic1.txt" Content-Type: text/plain; name="dp_pmap_panic1.txt"; charset="us-ascii" Content-Transfer-Encoding: 7bit U-Boot 2010.03 (Feb 28 2012 - 15:15:53) Marvell-DreamPlug SoC: Kirkwood 88F6281_A0 DRAM: 512 MB NAND: 512 MiB In: serial Out: serial Err: serial Net: egiga0, egiga1 88E1121 Initialized on egiga0 88E1121 Initialized on egiga1 Hit any key to stop autoboot: 0 Marvell>> run fb Using egiga0 device TFTP from server 172.22.42.240; our IP address is 172.22.42.100 Filename 'boot/kernel/kernel.bin'. Load address: 0x900000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ## done Bytes transferred = 3839160 (3a94b8 hex) ## Starting application at 0x00900000 ... KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #3 r239193M: Sat Aug 18 12:31:22 MDT 2012 ilepore@revolution.hippie.lan:/local/build/staging/freebsd/dp10/obj/arm.arm/local/build/staging/freebsd/dp10/src/sys/DP arm WARNING: DIAGNOSTIC option enabled, expect reduced performance. CPU: Feroceon 88FR131 rev 1 (Marvell core) Little-endian DC enabled IC enabled WA disabled DC streaming enabled BTB disabled L2 enabled L2 prefetch enabled WB enabled EABT branch prediction enabled 16KB/32B 4-way instruction cache 16KB/32B 4-way write-back-locking-C data cache real memory = 536870912 (512 MB) avail memory = 519340032 (495 MB) SOC: Marvell 88F6281 rev A1, TClock 200MHz Instruction cache prefetch disabled, data cache prefetch disabled 256KB 4-way set-associative write-through unified L2 cache random device not loaded; using insecure entropy localbus0: on fdtbus0 nand0: mem 0xf9300000-0xf93fffff on localbus0 nandbus0: on nand0 lnand0: on nandbus0 lnand0: Found BBT table for chip simplebus0: on fdtbus0 ic0: mem 0xf1020200-0xf102023b on simplebus0 timer0: mem 0xf1020300-0xf102032f irq 1 on simplebus0 Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 gpio0: mem 0xf1010100-0xf101011f irq 35,36,37,38,39,40,41 on simplebus0 gpio1: on simplebus0 simplebus0: no default resources for rid = 0, type = 3 gpio1: could not allocate resources device_attach: gpio1 attach returned 6 rtc0: mem 0xf1010300-0xf1010307 on simplebus0 twsi0: mem 0xf1011000-0xf101101f irq 43 on simplebus0 iicbus0: on twsi0 iic0: on iicbus0 mge0: mem 0xf1072000-0xf1073fff irq 12,13,14,11,46 on simplebus0 mge0: Ethernet address: f0:ad:4e:01:16:62 miibus0: on mge0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto mge1: mem 0xf1076000-0xf1077fff irq 16,17,18,15,47 on simplebus0 mge1: Ethernet address: f0:ad:4e:01:16:63 miibus1: on mge1 e1000phy1: PHY 1 on miibus1 e1000phy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto uart0: <16550 or compatible> mem 0xf1012000-0xf101201f irq 33 on simplebus0 uart0: console (1056,n,8,1) uart1: <16550 or compatible> mem 0xf1012100-0xf101211f irq 34 on simplebus0 ehci0: mem 0xf1050000-0xf1050fff irq 48,19 on simplebus0 usbus0: EHCI version 1.0 usbus0: stop timeout usbus0: set host controller mode usbus0 on ehci0 mvs0: mem 0xf1080000-0xf1085fff irq 21 on simplebus0 mvs0: Gen-IIe, 2 3Gbps ports, Port Multiplier supported with FBS mvsch0: at channel 0 on mvs0 mvsch1: at channel 1 on mvs0 Timecounters tick every 10.000 msec usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 bootpc_init: wired to interface 'mge0' Sending DHCP Discover packet from interface mge0 (f0:ad:4e:01:16:62) Received DHCP Offer packet on mge0 from 0.0.0.0 (accepted) (no root path) uhub0: 1 port with 1 removable, self powered mge0: link state changed to UP ugen0.2: at usbus0 uhub1: on usbus0 uhub1: 4 ports with 4 removable, self powered Sending DHCP Request packet from interface mge0 (f0:ad:4e:01:16:62) Received DHCP Ack packet on mge0 from 0.0.0.0 (accepted) (got root path) ugen0.3: at usbus0 umass0: on usbus0 da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3781MB (7744512 512 byte sectors: 255H 63S/T 482C) da1 at umass-sim0 bus 0 scbus2 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present ugen0.4: at usbus0 uaudio0: on usbus0 uaudio0: Play: 48000 Hz, 2 ch, 16-bit S-LE PCM format. uaudio0: Record: 48000 Hz, 1 ch, 16-bit S-LE PCM format. uaudio0: No midi sequencer. pcm0: on uaudio0 uhid0: on usbus0 mge0 at 172.22.42.100 server 0.0.0.0 subnet mask 255.255.255.0 router 172.22.42.254 rootfs 172.22.42.240:/dreamplug Adjusted interface mge0 WARNING: DIAGNOSTIC option enabled, expect reduced performance. Trying to mount root from nfs: []... ifaddr cache = 0xc3f54400 is deleted NFS ROOT: 172.22.42.240:/dreamplug panic: _rw_wlock_hard: recursing but non-recursive rw pmap pv global @ /local/build/staging/freebsd/dp10/src/sys/arm/arm/pmap.c:2836 KDB: enter: panic [ thread pid 1 tid 100001 ] Stopped at kdb_enter+0x48: ldrb r15, [r15, r15, ror r15]! db> bt Tracing pid 1 tid 100001 td 0xc350f000 db_md_set_watchpoint() at db_md_set_watchpoint+0x18 scp=0xc0babd98 rlv=0xc0babfcc (db_trace_thread+0x40) rsp=0xcf70b43c rfp=0xcf70b448 r10=0x00000001 r9=0x600000d3 r8=0xc0cac948 r7=0xc0cac11c r6=0x00000010 r5=0x00000000 r4=0xc350f000 db_trace_thread() at db_trace_thread+0x14 scp=0xc0babfa0 rlv=0xc092ad90 (db_command_init+0x5f4) rsp=0xcf70b44c rfp=0xcf70b46c db_command_init() at db_command_init+0x574 scp=0xc092ad10 rlv=0xc092a41c (db_skip_to_eol+0x38c) rsp=0xcf70b470 rfp=0xcf70b514 r6=0x00000002 r5=0x00000000 r4=0xc0c7b334 db_skip_to_eol() at db_skip_to_eol+0x1d0 scp=0xc092a260 rlv=0xc092a638 (db_command_loop+0x50) rsp=0xcf70b518 rfp=0xcf70b528 r10=0xc0cc03e4 r8=0xc0cc03e0 r7=0x00000001 r6=0x00000000 r5=0xcf70b6f4 r4=0xc0cac118 db_command_loop() at db_command_loop+0x18 scp=0xc092a600 rlv=0xc092ca0c (X_db_sym_numargs+0xa0) rsp=0xcf70b52c rfp=0xcf70b648 r4=0xcf70b530 X_db_sym_numargs() at X_db_sym_numargs+0x18 scp=0xc092c984 rlv=0xc0a83478 (kdb_trap+0xd4) rsp=0xcf70b64c rfp=0xcf70b674 r4=0xc0c7b5fc kdb_trap() at kdb_trap+0x10 scp=0xc0a833b4 rlv=0xc0bbd6b0 (undefinedinstruction+0x12c) rsp=0xcf70b678 rfp=0xcf70b6f0 r10=0xc350f000 r9=0xc0ca6624 r8=0xc0a82f7c r7=0xe7ffffff r6=0xcf70b6f4 r5=0x00000000 r4=0x00000000 undefinedinstruction() at undefinedinstruction+0x10 scp=0xc0bbd594 rlv=0xc0bad868 (address_exception_entry+0x50) rsp=0xcf70b6f4 rfp=0xcf70b754 r10=0x00000070 r9=0xc17b7000 r8=0xc0c98198 r7=0xc350f000 r6=0xc0c0bf78 r5=0xffff1004 r4=0xffffffff kdb_enter() at kdb_enter+0x14 scp=0xc0a82f48 rlv=0xc0a5556c (panic+0x12c) rsp=0xcf70b758 rfp=0xcf70b76c r5=0xc0cb29f8 r4=0x00000100 panic() at panic+0x18 scp=0xc0a55458 rlv=0xc0a53794 (_rw_wlock_hard+0x180) rsp=0xcf70b780 rfp=0xcf70b7a4 _rw_wlock_hard() at _rw_wlock_hard+0x10 scp=0xc0a53624 rlv=0xc0a53830 (_rw_wlock+0x90) rsp=0xcf70b7a8 rfp=0xcf70b7c0 r8=0x0000001c r7=0xc0ccf318 r6=0xc0ca6624 r5=0xc0c2f544 r4=0x00000b14 _rw_wlock() at _rw_wlock+0x10 scp=0xc0a537b0 rlv=0xc0bb8fd8 (pmap_qenter+0x204) rsp=0xcf70b7c4 rfp=0xcf70b814 r6=0x00000304 r5=0x00000c17 r4=0xc0ecbf58 pmap_qenter() at pmap_qenter+0x10 scp=0xc0bb8de4 rlv=0xc0b83fe4 (uma_print_zone+0x2fc) rsp=0xcf70b818 rfp=0xcf70b854 r10=0x00000000 r9=0x00000000 r8=0x00000017 r7=0xc17b7000 r6=0x00000000 r5=0x00000017 r4=0x00000001 uma_print_zone() at uma_print_zone+0x274 scp=0xc0b83f5c rlv=0xc0b85c4c (uma_zcreate+0xec) rsp=0xcf70b858 rfp=0xcf70b890 r10=0xc0b83f4c r9=0xc0e096e0 r8=0x00000101 r7=0x00000000 r6=0x00000001 r5=0xc0e0a600 r4=0x00000001 uma_zcreate() at uma_zcreate+0x70 scp=0xc0b85bd0 rlv=0xc0b861f4 (uma_prealloc+0x22c) rsp=0xcf70b894 rfp=0xcf70b8bc r10=0xc0e0a608 r9=0x00000080 r8=0x00000000 r7=0xc0e096e0 r6=0x00000001 r5=0xc0e0a600 r4=0xc0e0a600 uma_prealloc() at uma_prealloc+0x134 scp=0xc0b860fc rlv=0xc0b8638c (uma_prealloc+0x3c4) rsp=0xcf70b8c0 rfp=0xcf70b8d8 r10=0xc0df5a3c r8=0xc0e096e0 r7=0x00000068 r6=0xc0e096e0 r5=0x00000001 r4=0xc0e0a600 uma_prealloc() at uma_prealloc+0x398 scp=0xc0b86360 rlv=0xc0b87940 (uma_zalloc_arg+0x400) rsp=0xcf70b8dc rfp=0xcf70b920 r6=0xc17b6de8 r5=0x00000068 r4=0x00000069 uma_zalloc_arg() at uma_zalloc_arg+0x10 scp=0xc0b87550 rlv=0xc0bb6ed0 (pmap_release+0xd54) rsp=0xcf70b924 rfp=0xcf70b998 r10=0x00000000 r9=0x0279200e r8=0xc35110b0 r7=0xc3f80e90 r6=0x00000000 r5=0xc3f80e90 r4=0x02792002 pmap_release() at pmap_release+0x320 scp=0xc0bb649c rlv=0xc0bb75ac (pmap_enter_quick+0x6c) rsp=0xcf70b99c rfp=0xcf70b9c8 r10=0xc0ccffac r9=0x00000000 r8=0x000b6000 r7=0xc0ecbf0c r6=0x00000000 r5=0xc35110b0 r4=0xc0c2f544 pmap_enter_quick() at pmap_enter_quick+0x10 scp=0xc0bb7550 rlv=0xc0b8a764 (vm_fault_hold+0x1a80) rsp=0xcf70b9cc rfp=0xcf70bb4c r10=0xc0df9940 r8=0x000000ae r7=0x00000000 r6=0x00000000 r5=0xc0dfdd80 r4=0x000ae000 vm_fault_hold() at vm_fault_hold+0x10 scp=0xc0b88cf4 rlv=0xc0b8a974 (vm_fault+0x48) rsp=0xcf70bb50 rfp=0xcf70bb64 r10=0x00000001 r9=0xcf70bef8 r8=0xcf70bc0c r7=0xc350f000 r6=0x000b7000 r5=0x00000000 r4=0x000b7000 vm_fault() at vm_fault+0x10 scp=0xc0b8a93c rlv=0xc0bbc8d8 (data_abort_handler+0x1ec) rsp=0xcf70bb68 rfp=0xcf70bc08 r4=0xc350d088 data_abort_handler() at data_abort_handler+0x10 scp=0xc0bbc6fc rlv=0xc0bad868 (address_exception_entry+0x50) rsp=0xcf70bc0c rfp=0xcf70bcd8 r10=0xcf70bcdc r9=0x00000000 r8=0xc0cc2424 r7=0x05000104 r6=0x00000000 r5=0xffff1004 r4=0xffffffff namei() at namei+0x10 scp=0xc0ad3390 rlv=0xc0ae4768 (kern_readlinkat+0x80) rsp=0xcf70bcdc rfp=0xcf70bda4 r10=0xcf70bcdc r9=0x00000000 r8=0xcf70be30 r7=0xc350f000 r6=0x00000000 r5=0x00000000 r4=0x00000000 kern_readlinkat() at kern_readlinkat+0x10 scp=0xc0ae46f8 rlv=0xc0ae48a8 (kern_readlink+0x38) rsp=0xcf70bda8 rfp=0xcf70bdc4 r10=0x00000000 r9=0x00000000 r8=0xcf70be30 r7=0xc350f000 r6=0x00000000 r5=0xc350d000 r4=0x00000400 kern_readlink() at kern_readlink+0x10 scp=0xc0ae4880 rlv=0xc0ae48dc (sys_readlink+0x2c) rsp=0xcf70bdc8 rfp=0xcf70bddc r4=0xbfffe9ff sys_readlink() at sys_readlink+0x10 scp=0xc0ae48c0 rlv=0xc0bbcf70 (swi_handler+0x370) rsp=0xcf70bde0 rfp=0xcf70bea4 swi_handler() at swi_handler+0x10 scp=0xc0bbcc10 rlv=0xc0bad644 (swi_entry+0x44) rsp=0xcf70bea8 rfp=0xbfffee30 r10=0x00000001 r8=0x000e1118 r7=0x00000000 r6=0xcf70beac r5=0xfffffbf7 r4=0xbfffe9ff fiqvector() at 0x24d30 scp=0x00024d30 rlv=0x00025b1c (0x25b1c) rsp=0xbfffee34 rfp=0xbfffee48 r10=0x00000000 r9=0x00000000 r8=0x000e1118 r7=0x00000000 r6=0x00000002 r5=0x00000001 r4=0x00000040 fiqvector() at 0x25b14 scp=0x00025b14 rlv=0x00025b94 (0x25b94) rsp=0xbfffee4c rfp=0xbfffee58 r5=0x00000000 r4=0x00000008 fiqvector() at 0x25b8c scp=0x00025b8c rlv=0x0001f48c (0x1f48c) rsp=0xbfffee5c rfp=0xbfffee80 fiqvector() at 0x1f454 scp=0x0001f454 rlv=0x0001f404 (0x1f404) rsp=0xbfffee84 rfp=0xbfffee98 r10=0x00000000 r8=0x00000000 r7=0x00000000 r6=0x00000002 r5=0x00000038 r4=0x00000004 fiqvector() at 0x1f300 scp=0x0001f300 rlv=0x000081cc (0x81cc) rsp=0xbfffee9c rfp=0xbfffeebc r5=0xbfffeed0 r4=0xbfffeedc fiqvector() at 0x8150 scp=0x00008150 rlv=0x00008110 (0x8110) rsp=0xbfffeec0 rfp=0x00000000 r8=0x00000000 r7=0x00000000 r6=0x00000000 r5=0x00000000 r4=0x00000000 db> --=-zJM3S0EIs7z7F5IYigI9-- From owner-freebsd-arm@FreeBSD.ORG Sat Aug 18 19:48:06 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 370A1106566C for ; Sat, 18 Aug 2012 19:48:06 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh10.mail.rice.edu (mh10.mail.rice.edu [128.42.201.30]) by mx1.freebsd.org (Postfix) with ESMTP id 092C18FC12 for ; Sat, 18 Aug 2012 19:48:05 +0000 (UTC) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id 4D576604ED; Sat, 18 Aug 2012 14:48:05 -0500 (CDT) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id 4BFB1603D3; Sat, 18 Aug 2012 14:48:05 -0500 (CDT) X-Virus-Scanned: by amavis-2.7.0 at mh10.mail.rice.edu, auth channel Received: from mh10.mail.rice.edu ([127.0.0.1]) by mh10.mail.rice.edu (mh10.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 7HqgJQ9Uw_Ip; Sat, 18 Aug 2012 14:48:05 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh10.mail.rice.edu (Postfix) with ESMTPSA id ED8D360392; Sat, 18 Aug 2012 14:48:04 -0500 (CDT) Message-ID: <502FF174.8070102@rice.edu> Date: Sat, 18 Aug 2012 14:48:04 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Ian Lepore References: <502FD67A.7030003@rice.edu> <1345315508.27688.260.camel@revolution.hippie.lan> In-Reply-To: <1345315508.27688.260.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "arm@freebsd.org" Subject: Re: arm pmap locking 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, 18 Aug 2012 19:48:06 -0000 On 08/18/2012 13:45, Ian Lepore wrote: > On Sat, 2012-08-18 at 12:52 -0500, Alan Cox wrote: >> Can someone here please test the attached patch? I'm currently working >> my way through the various pmap implementations eliminating the use of >> the page queues lock. Arm is next on my list. >> >> Alan > I get a panic for recursion on my dreamplug, see attached. I applied > the patches over this: > > FreeBSD dpcur 10.0-CURRENT FreeBSD 10.0-CURRENT #4 r239193M: Sat Aug 18 > 12:37:24 MDT 2012 > > The 'M' is some dreamplug-specific changes (dts files, etc). I had a > quick look and it didn't seem like any of the checkins since r239193 > were related to arm pmap. I can try a fresher checkout when I have more > time if you think it's important. > > I tried adding WITNESS to see if it would get you more info, but it > panics for a LOR before getting to the panic in the attached output. > That's not new, it's been there for a while and I haven't had any time > to chase it down. Thanks, I don't need any more info. The problem is obvious. The existing arm pmap relies on the fact that lock recursion is allowed on the page queues lock that I'm eliminating, but not on the pvh lock that I'm introducing. However, this reliance on recursion is implicit not explicit. Look at the code surrounding the line were the lock acquire panics. It is explicitly releasing the page queues lock in the pre-patch version of the code, so as not to hold the page queues lock when pmap_get_pv_entry() is called. However, this unlocking and relocking is utterly pointless, because the caller to pmap_kenter_internal holds the page queues lock. So, in fact, pmap_get_pv_entry() will be called with the page queues lock held. Moreover, pmap_enter_locked() will call pmap_get_pv_entry() with the page queues lock held. So, I really don't understand why other places like pmap_kenter_internal() and pmap_enter_pv() are releasing and reacquiring the page queues lock. I suspect that it's based on the incorrect belief that you can't call uma_zalloc() with the page queues lock held. Let me look a little deeper at the arm pmap and I'll get back to you. Alan From owner-freebsd-arm@FreeBSD.ORG Sat Aug 18 21:22:35 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBA09106564A for ; Sat, 18 Aug 2012 21:22:34 +0000 (UTC) (envelope-from r.neese@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id A238E8FC08 for ; Sat, 18 Aug 2012 21:22:34 +0000 (UTC) Received: by yenl7 with SMTP id l7so5695628yen.13 for ; Sat, 18 Aug 2012 14:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qtf5K8Oez6fC3Z+MaPPHSgiYjeknM3iTb79o0V24518=; b=g751Djr1wpnTLnN+zchIj7zda08vU6w8Uu0Ky7159Bp3c1NDPNfY8IlhMZIMaFwdUX zgQrXwI7qbMXZEqBAhbPF4DhdFyaRcPs2nB/WG8Mr5/xRGF3UPFEFOQIv9ynau1lyKRN aXCOC84biQCyyDzGVtmO5XQXoQY1aeHrm2rd6Dh8VhjuJ5uhZ/5VM6P+Weq1W2LtKvYP PCsUwXUVCISb2CihM4zkRVlQ5V5+RlreML7BoPozj1/Vwq/bAD7mTgvoFXkEbEkZhXfs rZ+SGi+1YwIqJJrraEmZ05+jnP39agvat6F4kU8oEPsByoJDJCy0al1/ea8KQkkXDB7N sJbA== Received: by 10.236.179.98 with SMTP id g62mr14572163yhm.44.1345324948583; Sat, 18 Aug 2012 14:22:28 -0700 (PDT) Received: from [127.0.0.1] ([97.100.95.108]) by mx.google.com with ESMTPS id e24sm20922767yhh.4.2012.08.18.14.22.27 (version=SSLv3 cipher=OTHER); Sat, 18 Aug 2012 14:22:28 -0700 (PDT) Message-ID: <50300790.5080104@gmail.com> Date: Sat, 18 Aug 2012 17:22:24 -0400 From: Richard E Neese User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Alan Cox References: <502FD67A.7030003@rice.edu> <1345315508.27688.260.camel@revolution.hippie.lan> <502FF174.8070102@rice.edu> In-Reply-To: <502FF174.8070102@rice.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "arm@freebsd.org" Subject: Re: arm pmap locking 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, 18 Aug 2012 21:22:35 -0000 On 8/18/2012 3:48 PM, Alan Cox wrote: > On 08/18/2012 13:45, Ian Lepore wrote: >> On Sat, 2012-08-18 at 12:52 -0500, Alan Cox wrote: >>> Can someone here please test the attached patch? I'm currently working >>> my way through the various pmap implementations eliminating the use of >>> the page queues lock. Arm is next on my list. >>> >>> Alan >> I get a panic for recursion on my dreamplug, see attached. I applied >> the patches over this: >> >> FreeBSD dpcur 10.0-CURRENT FreeBSD 10.0-CURRENT #4 r239193M: Sat Aug 18 >> 12:37:24 MDT 2012 >> >> The 'M' is some dreamplug-specific changes (dts files, etc). I had a >> quick look and it didn't seem like any of the checkins since r239193 >> were related to arm pmap. I can try a fresher checkout when I have more >> time if you think it's important. >> >> I tried adding WITNESS to see if it would get you more info, but it >> panics for a LOR before getting to the panic in the attached output. >> That's not new, it's been there for a while and I haven't had any time >> to chase it down. > > Thanks, I don't need any more info. The problem is obvious. The > existing arm pmap relies on the fact that lock recursion is allowed on > the page queues lock that I'm eliminating, but not on the pvh lock > that I'm introducing. However, this reliance on recursion is implicit > not explicit. Look at the code surrounding the line were the lock > acquire panics. It is explicitly releasing the page queues lock in > the pre-patch version of the code, so as not to hold the page queues > lock when pmap_get_pv_entry() is called. However, this unlocking and > relocking is utterly pointless, because the caller to > pmap_kenter_internal holds the page queues lock. So, in fact, > pmap_get_pv_entry() will be called with the page queues lock held. > Moreover, pmap_enter_locked() will call pmap_get_pv_entry() with the > page queues lock held. So, I really don't understand why other places > like pmap_kenter_internal() and pmap_enter_pv() are releasing and > reacquiring the page queues lock. I suspect that it's based on the > incorrect belief that you can't call uma_zalloc() with the page queues > lock held. > > Let me look a little deeper at the arm pmap and I'll get back to you. > > Alan > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" Alan what dream plug do you have what ver ? we are working on a patch now for dreamplug we have the dreamplug 1001 and 1001n and a 0801 so far