From owner-freebsd-arm@FreeBSD.ORG Wed Jan 1 10:59:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E12D90A for ; Wed, 1 Jan 2014 10:59:52 +0000 (UTC) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AF2971D44 for ; Wed, 1 Jan 2014 10:59:51 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id w61so11822165wes.0 for ; Wed, 01 Jan 2014 02:59:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=A7Q0COQZd1QPIvcu+65Ua+IECKHMaHFfe3KSag26Go0=; b=CWjepmdUiWQtC4FmmKUcXYHJWu4IuA6oALb4UJY3gglBK+YmF0k6+2LqkKCc517b95 bbVc5DAUvyGO5CjJn+m/EQXJxjZi650EjO03uxQHfQ6rmEn9mPtQXrlCZf0ok/xrccxY m/xBjlJmOgs/99a79eYqD7PGrNGAHPVLt7QVrEEZMha7DO44Zx9B9X7t1vETTDzHJk9q WMDSuIzuC+zNBdZ8D04nnzOMyfCsB67AbWSDKseMWNdGgZD0IsHnq6NG7xTxmxw1aVrD sKXQblZAyTGdLoV4EWEJwrELVzm5pZJ/vYz+9U72mov0XDt1uD0nSBEsy4P0r8fL2A44 RE9A== MIME-Version: 1.0 X-Received: by 10.194.63.134 with SMTP id g6mr26819861wjs.46.1388573990063; Wed, 01 Jan 2014 02:59:50 -0800 (PST) Received: by 10.217.114.10 with HTTP; Wed, 1 Jan 2014 02:59:50 -0800 (PST) In-Reply-To: <20131231233712.GR99167@funkthat.com> References: <1504801126410582043@unknownmsgid> <20131231233712.GR99167@funkthat.com> Date: Wed, 1 Jan 2014 11:59:50 +0100 Message-ID: Subject: Re: AVILA NFS problem ? From: Berislav Purgar To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2014 10:59:52 -0000 On Wed, Jan 1, 2014 at 12:37 AM, John-Mark Gurney wrote: > Berislav Purgar wrote this message on Tue, Dec 31, 2013 at 14:18 -0800: > > Yes... Default avila.hints configure phy 0 for npe0 and npe1 phy 1 and > > that work with gw-2348 board (i think). But i have gw-2345-F board > > which have 4 lan and one wan port. Wan port is attached to PHY 5 and > > lan ports are attached to switch chip KS8995. We dont have driver for > > this chip so i figured that if i put 2 for PHY port 2 works on switch. > > So i forget to change these in avila.hints and that reproduce kernel > > panic on nfs boot.. > > Can you post which hints you needed? This will be helpful for others, > plus, we can look at installing, or at least documenting that these > hints are required for that model of board... > > Hello here is hints for GW-2345-F board (port2 and wan port works). For switch to work we need driver for KS8995. http://pastebin.com/wWthdjKc Beri From owner-freebsd-arm@FreeBSD.ORG Wed Jan 1 12:56:13 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F2A4395; Wed, 1 Jan 2014 12:56:13 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0BEAA1395; Wed, 1 Jan 2014 12:56:12 +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 s01CuBYc016798; Wed, 1 Jan 2014 07:56:11 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s01CuBkv016795; Wed, 1 Jan 2014 12:56:11 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 1 Jan 2014 12:56:11 GMT Message-Id: <201401011256.s01CuBkv016795@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2014 12:56:13 -0000 TB --- 2014-01-01 10:20:20 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-01 10:20:20 - 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 --- 2014-01-01 10:20:20 - starting HEAD tinderbox run for arm/arm TB --- 2014-01-01 10:20:20 - cleaning the object tree TB --- 2014-01-01 10:20:20 - /usr/local/bin/svn stat /src TB --- 2014-01-01 10:20:25 - At svn revision 260159 TB --- 2014-01-01 10:20:26 - building world TB --- 2014-01-01 10:20:26 - CROSS_BUILD_TESTING=YES TB --- 2014-01-01 10:20:26 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-01 10:20:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-01 10:20:26 - SRCCONF=/dev/null TB --- 2014-01-01 10:20:26 - TARGET=arm TB --- 2014-01-01 10:20:26 - TARGET_ARCH=arm TB --- 2014-01-01 10:20:26 - TZ=UTC TB --- 2014-01-01 10:20:26 - __MAKE_CONF=/dev/null TB --- 2014-01-01 10:20:26 - cd /src TB --- 2014-01-01 10:20:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Jan 1 10:20:35 UTC 2014 >>> 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 [...] cc -O -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/tools/common/findprime.c cc -O -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -W! no-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -W! no-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -W! no-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -o zinject zinject.o translate.o -lgeom -lm -lnvpair -lumem -luutil -lzfs_core -lzfs -lzpool /obj/arm.arm/src/tmp/usr/lib/libzpool.so: undefined reference to `atomic_swap_64' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. bmake[4]: stopped in /src/cddl/usr.bin/zinject *** Error code 1 Stop. bmake[3]: stopped in /src/cddl/usr.bin *** Error code 1 Stop. bmake[2]: stopped in /src/cddl *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-01-01 12:56:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-01 12:56:11 - ERROR: failed to build world TB --- 2014-01-01 12:56:11 - 7563.76 user 1267.30 system 9350.76 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Jan 1 16:33:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01E9AC2 for ; Wed, 1 Jan 2014 16:33:52 +0000 (UTC) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 88FD9129D for ; Wed, 1 Jan 2014 16:33:51 +0000 (UTC) Received: by mail-ea0-f175.google.com with SMTP id z10so5942028ead.34 for ; Wed, 01 Jan 2014 08:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=yy0QDaARpyFbt73fIGtNKZBAp3EetZkSPVFwYtt+6yo=; b=xIc3n24eEFtxaHWLPeiWesZWdd2575+uJgq2rWaO+UEDe6ORl6GTaQvOyyrR8zIUTv wtvbrlxT0XiHrr0N8MN1kte/acDgJ4keSdcyy3OoAmEJCarzamqZxp9U3ylzOiun0Ljx rxE/iayBHvFoTthfBKR2lMNRsxSi17HJQfokcN+0dub21FjIdkhne08CdJ6Q7XBOdb+V ySVZeRk0oc5963WdO6WfaCVMEu69dNNyCp3yhkPuEl/XIJ2qSkYg4s1P7Rpim+uF7U4l hebd2Zv0ChHxZ5lUYDkZ6R3s9LkcBIr8IISCsTxYa3xO2xEiOnvoO31rHhHl/U620+7f DEug== X-Received: by 10.14.218.69 with SMTP id j45mr65056685eep.22.1388593682960; Wed, 01 Jan 2014 08:28:02 -0800 (PST) Received: from [192.168.0.108] (136-206-ftth.onsbrabantnet.nl. [88.159.206.136]) by mx.google.com with ESMTPSA id z42sm128299638eeo.17.2014.01.01.08.28.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Jan 2014 08:28:02 -0800 (PST) Sender: =?UTF-8?Q?Ren=C3=A9_Ladan?= Message-ID: <52C44211.4050907@freebsd.org> Date: Wed, 01 Jan 2014 17:28:01 +0100 From: =?ISO-8859-1?Q?Ren=E9_Ladan?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: George Mitchell , freebsd-arm@freebsd.org Subject: Re: Raspberry Pi: still getting prefetch aborts References: <52BB73B4.5030000@m5p.com> <52BB7489.2040101@m5p.com> In-Reply-To: <52BB7489.2040101@m5p.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2014 16:33:52 -0000 On 12/26/2013 01:12, George Mitchell wrote: > On 12/25/13 19:09, George Mitchell wrote: >> FreeBSD 10.0-PRERELEASE (RPI-B) #0 r259866M: Wed Dec 25 17:26:28 EST 2013 >> (M because I selected serial output in RPI-B) >> [...] > > /etc/src.conf: > > MALLOC_PRODUCTION=yes > > /etc/make.conf: > > WITH_PKGNG=yes > MALLOC_PRODUCTION=yes > WITH_NEW_XORG=yes > Hmm, I have FreeBSD 10.0-RC2 (RPI-B-RENE) #1 r259413: Sun Dec 15 13:20:27 CET 2013 (GENERIC + ums) with pkg 1.2.4_1 built on December 16th just fine. My image is crossbuilt on i386/amd64 with no /etc/src.conf or /etc/make.conf using these commands: env make __MAKE_CONF=/dev/null ARCH=arm TARGET_ARCH=armv6 TARGET_CPUTYPE=armv6 WITH_FDT=yes buildworld env make __MAKE_CONF=/dev/null ARCH=arm TARGET_ARCH=armv6 TARGET_CPUTYPE=armv6 WITH_FDT=yes KERNCONF=RPI-B buildkernel env make __MAKE_CONF=/dev/null ARCH=arm TARGET_ARCH=armv6 TARGET_CPUTYPE=armv6 WITH_FDT=yes KERNCONF=RPI-B DESTDIR=/media installkernel env make __MAKE_CONF=/dev/null ARCH=arm TARGET_ARCH=armv6 TARGET_CPUTYPE=armv6 WITH_FDT=yes DESTDIR=/media -DDB_FROM_SRC installworld - MALLOC_PRODUCTION removed because on releng/10.0 it seems to be the default and the build breaks otherwise. - instructions might contains redundancy - SD card mounted on /media WITH_NEW_XORG worked just fine some months ago, my Pi is running headless lately. René From owner-freebsd-arm@FreeBSD.ORG Wed Jan 1 16:35:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E245F103; Wed, 1 Jan 2014 16:35:56 +0000 (UTC) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F06C12A4; Wed, 1 Jan 2014 16:35:56 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s01GZnnk074537; Wed, 1 Jan 2014 11:35:54 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <52C443E5.1020800@m5p.com> Date: Wed, 01 Jan 2014 11:35:49 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ren=E9_Ladan?= , freebsd-arm@freebsd.org Subject: Re: Raspberry Pi: still getting prefetch aborts References: <52BB73B4.5030000@m5p.com> <52BB7489.2040101@m5p.com> <52C44211.4050907@freebsd.org> In-Reply-To: <52C44211.4050907@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Wed, 01 Jan 2014 11:35:55 -0500 (EST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2014 16:35:57 -0000 On 01/01/14 11:28, René Ladan wrote: > On 12/26/2013 01:12, George Mitchell wrote: >> On 12/25/13 19:09, George Mitchell wrote: >>> FreeBSD 10.0-PRERELEASE (RPI-B) #0 r259866M: Wed Dec 25 17:26:28 EST 2013 >>> (M because I selected serial output in RPI-B) >>> [...] >> >> /etc/src.conf: >> >> MALLOC_PRODUCTION=yes >> >> /etc/make.conf: >> >> WITH_PKGNG=yes >> MALLOC_PRODUCTION=yes >> WITH_NEW_XORG=yes >> > Hmm, I have > FreeBSD 10.0-RC2 (RPI-B-RENE) #1 r259413: Sun Dec 15 13:20:27 CET 2013 > (GENERIC + ums) > with pkg 1.2.4_1 built on December 16th just fine. > > My image is crossbuilt on i386/amd64 with no /etc/src.conf or > /etc/make.conf using these commands: > > env make __MAKE_CONF=/dev/null ARCH=arm TARGET_ARCH=armv6 > TARGET_CPUTYPE=armv6 WITH_FDT=yes buildworld > env make __MAKE_CONF=/dev/null ARCH=arm TARGET_ARCH=armv6 > TARGET_CPUTYPE=armv6 WITH_FDT=yes KERNCONF=RPI-B buildkernel > env make __MAKE_CONF=/dev/null ARCH=arm TARGET_ARCH=armv6 > TARGET_CPUTYPE=armv6 WITH_FDT=yes KERNCONF=RPI-B DESTDIR=/media > installkernel > env make __MAKE_CONF=/dev/null ARCH=arm TARGET_ARCH=armv6 > TARGET_CPUTYPE=armv6 WITH_FDT=yes DESTDIR=/media -DDB_FROM_SRC installworld > > - MALLOC_PRODUCTION removed because on releng/10.0 it seems to be the > default and the build breaks otherwise. > - instructions might contains redundancy > - SD card mounted on /media > > WITH_NEW_XORG worked just fine some months ago, my Pi is running > headless lately. > > René > Thanks for the data. Can you do any port building on the Pi itself? -- George From owner-freebsd-arm@FreeBSD.ORG Wed Jan 1 16:48:58 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 863AC29B for ; Wed, 1 Jan 2014 16:48:58 +0000 (UTC) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 19D2D1343 for ; Wed, 1 Jan 2014 16:48:57 +0000 (UTC) Received: by mail-ee0-f45.google.com with SMTP id d49so5810201eek.18 for ; Wed, 01 Jan 2014 08:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2H1cCOoTZgYsz9bkR374ikOgVWYdGiE3adsQYQBj/kk=; b=lAwQ3/dPIu6xPBEF74r4zPbpuXq6M9cxpGJl78N5JQC+8L9VKTuGqPFyBnv6fgH6Qz wieiZjzgxKI7tTM3D+/we5x50uJHBDLoL2Cz4q2wWWsa8cG/qVaLR+nnuoRQA3Xh4VzD NdewyTNE5wc2HATyi2VOI63G8o7FDOp+0+MJT9RZUkA1WSSSafHe8G9j4QcpQCzxNQyE Ht977xv/w+HPo6mSH+PRXjnmveglj5a2Dvknt5eUf23yOVV/1pULwePrdWluFouG/9QZ GWQnPAe+d7gsekTvyCyFzG7U+gNy0m5cBpmmVNd9f+oXvNt8/XZTnxbWkQFQ9KAKtqzZ 3shQ== X-Received: by 10.15.31.196 with SMTP id y44mr11846482eeu.96.1388594927013; Wed, 01 Jan 2014 08:48:47 -0800 (PST) Received: from [192.168.0.108] (136-206-ftth.onsbrabantnet.nl. [88.159.206.136]) by mx.google.com with ESMTPSA id l4sm128451748een.13.2014.01.01.08.48.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Jan 2014 08:48:46 -0800 (PST) Sender: =?UTF-8?Q?Ren=C3=A9_Ladan?= Message-ID: <52C446ED.6000806@freebsd.org> Date: Wed, 01 Jan 2014 17:48:45 +0100 From: =?ISO-8859-1?Q?Ren=E9_Ladan?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: George Mitchell , freebsd-arm@freebsd.org Subject: Re: Raspberry Pi: still getting prefetch aborts References: <52BB73B4.5030000@m5p.com> <52BB7489.2040101@m5p.com> <52C44211.4050907@freebsd.org> <52C443E5.1020800@m5p.com> In-Reply-To: <52C443E5.1020800@m5p.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2014 16:48:58 -0000 On 01/01/2014 17:35, George Mitchell wrote: > On 01/01/14 11:28, René Ladan wrote: >> On 12/26/2013 01:12, George Mitchell wrote: >>> On 12/25/13 19:09, George Mitchell wrote: >>>> FreeBSD 10.0-PRERELEASE (RPI-B) #0 r259866M: Wed Dec 25 17:26:28 >>>> EST 2013 >>>> (M because I selected serial output in RPI-B) >>>> [...] >>> >>> /etc/src.conf: >>> >>> MALLOC_PRODUCTION=yes >>> >>> /etc/make.conf: >>> >>> WITH_PKGNG=yes >>> MALLOC_PRODUCTION=yes >>> WITH_NEW_XORG=yes >>> >> Hmm, I have >> FreeBSD 10.0-RC2 (RPI-B-RENE) #1 r259413: Sun Dec 15 13:20:27 CET 2013 >> (GENERIC + ums) >> with pkg 1.2.4_1 built on December 16th just fine. >> >> My image is crossbuilt on i386/amd64 with no /etc/src.conf or >> /etc/make.conf using these commands: >> >> env make __MAKE_CONF=/dev/null ARCH=arm TARGET_ARCH=armv6 >> TARGET_CPUTYPE=armv6 WITH_FDT=yes buildworld >> env make __MAKE_CONF=/dev/null ARCH=arm TARGET_ARCH=armv6 >> TARGET_CPUTYPE=armv6 WITH_FDT=yes KERNCONF=RPI-B buildkernel >> env make __MAKE_CONF=/dev/null ARCH=arm TARGET_ARCH=armv6 >> TARGET_CPUTYPE=armv6 WITH_FDT=yes KERNCONF=RPI-B DESTDIR=/media >> installkernel >> env make __MAKE_CONF=/dev/null ARCH=arm TARGET_ARCH=armv6 >> TARGET_CPUTYPE=armv6 WITH_FDT=yes DESTDIR=/media -DDB_FROM_SRC >> installworld >> >> - MALLOC_PRODUCTION removed because on releng/10.0 it seems to be the >> default and the build breaks otherwise. >> - instructions might contains redundancy >> - SD card mounted on /media >> >> WITH_NEW_XORG worked just fine some months ago, my Pi is running >> headless lately. >> >> René >> > Thanks for the data. Can you do any port building on the Pi itself? Yes, I have natively built some ports. For more natively built packages see e.g. ftp://rene-ladan.nl/pub/freebsd/rpi-pkgs/ (site might be slow on multi-MB downloads currently, config issue...) René From owner-freebsd-arm@FreeBSD.ORG Wed Jan 1 19:49:18 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 170E876; Wed, 1 Jan 2014 19:49:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CF2711FA9; Wed, 1 Jan 2014 19:49:17 +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 s01JnGUO017164; Wed, 1 Jan 2014 14:49:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s01JnGBb017152; Wed, 1 Jan 2014 19:49:16 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 1 Jan 2014 19:49:16 GMT Message-Id: <201401011949.s01JnGBb017152@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2014 19:49:18 -0000 TB --- 2014-01-01 17:10:15 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-01 17:10:15 - 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 --- 2014-01-01 17:10:15 - starting HEAD tinderbox run for arm/arm TB --- 2014-01-01 17:10:15 - cleaning the object tree TB --- 2014-01-01 17:14:20 - /usr/local/bin/svn stat /src TB --- 2014-01-01 17:14:24 - At svn revision 260159 TB --- 2014-01-01 17:14:25 - building world TB --- 2014-01-01 17:14:25 - CROSS_BUILD_TESTING=YES TB --- 2014-01-01 17:14:25 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-01 17:14:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-01 17:14:25 - SRCCONF=/dev/null TB --- 2014-01-01 17:14:25 - TARGET=arm TB --- 2014-01-01 17:14:25 - TARGET_ARCH=arm TB --- 2014-01-01 17:14:25 - TZ=UTC TB --- 2014-01-01 17:14:25 - __MAKE_CONF=/dev/null TB --- 2014-01-01 17:14:25 - cd /src TB --- 2014-01-01 17:14:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Jan 1 17:14:31 UTC 2014 >>> 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 [...] cc -O -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/tools/common/findprime.c cc -O -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -W! no-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -W! no-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -W! no-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -o zinject zinject.o translate.o -lgeom -lm -lnvpair -lumem -luutil -lzfs_core -lzfs -lzpool /obj/arm.arm/src/tmp/usr/lib/libzpool.so: undefined reference to `atomic_swap_64' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. bmake[4]: stopped in /src/cddl/usr.bin/zinject *** Error code 1 Stop. bmake[3]: stopped in /src/cddl/usr.bin *** Error code 1 Stop. bmake[2]: stopped in /src/cddl *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-01-01 19:49:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-01 19:49:16 - ERROR: failed to build world TB --- 2014-01-01 19:49:16 - 7562.28 user 1267.07 system 9540.60 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Jan 1 20:36:33 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A49074A3; Wed, 1 Jan 2014 20:36:33 +0000 (UTC) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4480F1328; Wed, 1 Jan 2014 20:36:33 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id s01KaPvY075630; Wed, 1 Jan 2014 15:36:30 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <52C47C49.5060200@m5p.com> Date: Wed, 01 Jan 2014 15:36:25 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ren=E9_Ladan?= , freebsd-arm@freebsd.org Subject: Re: Raspberry Pi: still getting prefetch aborts References: <52BB73B4.5030000@m5p.com> <52BB7489.2040101@m5p.com> <52C44211.4050907@freebsd.org> <52C443E5.1020800@m5p.com> <52C446ED.6000806@freebsd.org> In-Reply-To: <52C446ED.6000806@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Wed, 01 Jan 2014 15:36:31 -0500 (EST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2014 20:36:33 -0000 On 01/01/14 11:48, René Ladan wrote: > On 01/01/2014 17:35, George Mitchell wrote: >> On 01/01/14 11:28, René Ladan wrote: >>> On 12/26/2013 01:12, George Mitchell wrote: >>>> On 12/25/13 19:09, George Mitchell wrote: >>>>> FreeBSD 10.0-PRERELEASE (RPI-B) #0 r259866M: Wed Dec 25 17:26:28 >>>>> EST 2013 >>>>> (M because I selected serial output in RPI-B) >>>>> [...] >>>> >>>> /etc/src.conf: >>>> >>>> MALLOC_PRODUCTION=yes >>>> >>>> /etc/make.conf: >>>> >>>> WITH_PKGNG=yes >>>> MALLOC_PRODUCTION=yes >>>> WITH_NEW_XORG=yes >>>> >>> Hmm, I have >>> FreeBSD 10.0-RC2 (RPI-B-RENE) #1 r259413: Sun Dec 15 13:20:27 CET 2013 >>> (GENERIC + ums) >>> with pkg 1.2.4_1 built on December 16th just fine. >>> >>> My image is crossbuilt on i386/amd64 with no /etc/src.conf or >>> /etc/make.conf using these commands: >>> >>> env make __MAKE_CONF=/dev/null ARCH=arm TARGET_ARCH=armv6 >>> TARGET_CPUTYPE=armv6 WITH_FDT=yes buildworld >>> env make __MAKE_CONF=/dev/null ARCH=arm TARGET_ARCH=armv6 >>> TARGET_CPUTYPE=armv6 WITH_FDT=yes KERNCONF=RPI-B buildkernel >>> env make __MAKE_CONF=/dev/null ARCH=arm TARGET_ARCH=armv6 >>> TARGET_CPUTYPE=armv6 WITH_FDT=yes KERNCONF=RPI-B DESTDIR=/media >>> installkernel >>> env make __MAKE_CONF=/dev/null ARCH=arm TARGET_ARCH=armv6 >>> TARGET_CPUTYPE=armv6 WITH_FDT=yes DESTDIR=/media -DDB_FROM_SRC >>> installworld >>> >>> - MALLOC_PRODUCTION removed because on releng/10.0 it seems to be the >>> default and the build breaks otherwise. >>> - instructions might contains redundancy >>> - SD card mounted on /media >>> >>> WITH_NEW_XORG worked just fine some months ago, my Pi is running >>> headless lately. >>> >>> René >>> >> Thanks for the data. Can you do any port building on the Pi itself? > Yes, I have natively built some ports. For more natively built packages > see e.g. > ftp://rene-ladan.nl/pub/freebsd/rpi-pkgs/ > > (site might be slow on multi-MB downloads currently, config issue...) > > René > Thanks for the pointer! -- George From owner-freebsd-arm@FreeBSD.ORG Thu Jan 2 02:48:30 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B8CF87C; Thu, 2 Jan 2014 02:48:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C411F1AAC; Thu, 2 Jan 2014 02:48:28 +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 s022mRa5099235; Wed, 1 Jan 2014 21:48:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s022mRBg099210; Thu, 2 Jan 2014 02:48:27 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Jan 2014 02:48:27 GMT Message-Id: <201401020248.s022mRBg099210@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 02:48:30 -0000 TB --- 2014-01-02 00:10:18 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-02 00:10:18 - 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 --- 2014-01-02 00:10:18 - starting HEAD tinderbox run for arm/arm TB --- 2014-01-02 00:10:18 - cleaning the object tree TB --- 2014-01-02 00:13:23 - /usr/local/bin/svn stat /src TB --- 2014-01-02 00:13:27 - At svn revision 260176 TB --- 2014-01-02 00:13:28 - building world TB --- 2014-01-02 00:13:28 - CROSS_BUILD_TESTING=YES TB --- 2014-01-02 00:13:28 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-02 00:13:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-02 00:13:28 - SRCCONF=/dev/null TB --- 2014-01-02 00:13:28 - TARGET=arm TB --- 2014-01-02 00:13:28 - TARGET_ARCH=arm TB --- 2014-01-02 00:13:28 - TZ=UTC TB --- 2014-01-02 00:13:28 - __MAKE_CONF=/dev/null TB --- 2014-01-02 00:13:28 - cd /src TB --- 2014-01-02 00:13:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jan 2 00:13:35 UTC 2014 >>> 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 [...] cc -O -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/tools/common/findprime.c cc -O -pipe -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/sgsmsg/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/include -I/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -o sgsmsg avl.o sgsmsg.o string_table.o findprime.o ===> cddl/usr.bin/zinject (all) cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -W! no-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/zinject.c cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -W! no-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -c /src/cddl/usr.bin/zinject/../../contrib/opensolaris/cmd/zinject/translate.c cc -O -pipe -I/src/cddl/usr.bin/zinject/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/include -I/src/cddl/usr.bin/zinject/../../compat/opensolaris/lib/libumem -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzfs/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libzpool/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/lib/libnvpair -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/src/cddl/usr.bin/zinject/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/usr.bin/zinject/../../contrib/opensolaris/head -I/src/cddl/usr.bin/zinject/../../lib/libumem -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Qunused-arguments -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -W! no-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-unknown-pragmas -o zinject zinject.o translate.o -lgeom -lm -lnvpair -lumem -luutil -lzfs_core -lzfs -lzpool /obj/arm.arm/src/tmp/usr/lib/libzpool.so: undefined reference to `atomic_swap_64' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. bmake[4]: stopped in /src/cddl/usr.bin/zinject *** Error code 1 Stop. bmake[3]: stopped in /src/cddl/usr.bin *** Error code 1 Stop. bmake[2]: stopped in /src/cddl *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-01-02 02:48:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-02 02:48:27 - ERROR: failed to build world TB --- 2014-01-02 02:48:27 - 7563.23 user 1266.97 system 9489.05 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Thu Jan 2 10:31:48 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D9B2BDD; Thu, 2 Jan 2014 10:31:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 53D4819BD; Thu, 2 Jan 2014 10:31:48 +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 s02AVlop099079; Thu, 2 Jan 2014 05:31:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s02AVlG9099078; Thu, 2 Jan 2014 10:31:47 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Jan 2014 10:31:47 GMT Message-Id: <201401021031.s02AVlG9099078@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 10:31:48 -0000 TB --- 2014-01-02 07:20:17 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-02 07:20:17 - 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 --- 2014-01-02 07:20:17 - starting HEAD tinderbox run for arm/arm TB --- 2014-01-02 07:20:17 - cleaning the object tree TB --- 2014-01-02 07:24:53 - /usr/local/bin/svn stat /src TB --- 2014-01-02 07:24:56 - At svn revision 260182 TB --- 2014-01-02 07:24:57 - building world TB --- 2014-01-02 07:24:57 - CROSS_BUILD_TESTING=YES TB --- 2014-01-02 07:24:57 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-02 07:24:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-02 07:24:57 - SRCCONF=/dev/null TB --- 2014-01-02 07:24:57 - TARGET=arm TB --- 2014-01-02 07:24:57 - TARGET_ARCH=arm TB --- 2014-01-02 07:24:57 - TZ=UTC TB --- 2014-01-02 07:24:57 - __MAKE_CONF=/dev/null TB --- 2014-01-02 07:24:57 - cd /src TB --- 2014-01-02 07:24:57 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jan 2 07:25:05 UTC 2014 >>> 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 Thu Jan 2 10:31:12 UTC 2014 TB --- 2014-01-02 10:31:12 - generating LINT kernel config TB --- 2014-01-02 10:31:12 - cd /src/sys/arm/conf TB --- 2014-01-02 10:31:12 - /usr/bin/make -B LINT TB --- 2014-01-02 10:31:12 - cd /src/sys/arm/conf TB --- 2014-01-02 10:31:12 - /usr/sbin/config -m LINT TB --- 2014-01-02 10:31:12 - building LINT kernel TB --- 2014-01-02 10:31:12 - CROSS_BUILD_TESTING=YES TB --- 2014-01-02 10:31:12 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-02 10:31:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-02 10:31:12 - SRCCONF=/dev/null TB --- 2014-01-02 10:31:12 - TARGET=arm TB --- 2014-01-02 10:31:12 - TARGET_ARCH=arm TB --- 2014-01-02 10:31:12 - TZ=UTC TB --- 2014-01-02 10:31:12 - __MAKE_CONF=/dev/null TB --- 2014-01-02 10:31:12 - cd /src TB --- 2014-01-02 10:31:12 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 2 10:31:12 UTC 2014 >>> 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 [...] machine -> /src/sys/arm/include cc -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -ffreestanding /src/sys/arm/arm/genassym.c In file included from /src/sys/arm/arm/genassym.c:48: In file included from ./machine/intr.h:71: /src/sys/sys/bus.h:585:10: fatal error: 'device_if.h' file not found #include "device_if.h" ^ 1 error generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-01-02 10:31:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-02 10:31:47 - ERROR: failed to build LINT kernel TB --- 2014-01-02 10:31:47 - 8700.84 user 1663.12 system 11489.74 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Thu Jan 2 21:01:28 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D048DD1C; Thu, 2 Jan 2014 21:01:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9445312C2; Thu, 2 Jan 2014 21:01:28 +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 s02L1Rfq022527; Thu, 2 Jan 2014 16:01:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s02L1RSv022526; Thu, 2 Jan 2014 21:01:27 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 2 Jan 2014 21:01:27 GMT Message-Id: <201401022101.s02L1RSv022526@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 21:01:29 -0000 TB --- 2014-01-02 17:50:19 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-02 17:50:19 - 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 --- 2014-01-02 17:50:19 - starting HEAD tinderbox run for arm/arm TB --- 2014-01-02 17:50:19 - cleaning the object tree TB --- 2014-01-02 17:56:25 - /usr/local/bin/svn stat /src TB --- 2014-01-02 17:56:28 - At svn revision 260202 TB --- 2014-01-02 17:56:29 - building world TB --- 2014-01-02 17:56:29 - CROSS_BUILD_TESTING=YES TB --- 2014-01-02 17:56:29 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-02 17:56:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-02 17:56:29 - SRCCONF=/dev/null TB --- 2014-01-02 17:56:29 - TARGET=arm TB --- 2014-01-02 17:56:29 - TARGET_ARCH=arm TB --- 2014-01-02 17:56:29 - TZ=UTC TB --- 2014-01-02 17:56:29 - __MAKE_CONF=/dev/null TB --- 2014-01-02 17:56:29 - cd /src TB --- 2014-01-02 17:56:29 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jan 2 17:56:36 UTC 2014 >>> 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 Thu Jan 2 21:00:53 UTC 2014 TB --- 2014-01-02 21:00:53 - generating LINT kernel config TB --- 2014-01-02 21:00:53 - cd /src/sys/arm/conf TB --- 2014-01-02 21:00:53 - /usr/bin/make -B LINT TB --- 2014-01-02 21:00:53 - cd /src/sys/arm/conf TB --- 2014-01-02 21:00:53 - /usr/sbin/config -m LINT TB --- 2014-01-02 21:00:53 - building LINT kernel TB --- 2014-01-02 21:00:53 - CROSS_BUILD_TESTING=YES TB --- 2014-01-02 21:00:53 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-02 21:00:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-02 21:00:53 - SRCCONF=/dev/null TB --- 2014-01-02 21:00:53 - TARGET=arm TB --- 2014-01-02 21:00:53 - TARGET_ARCH=arm TB --- 2014-01-02 21:00:53 - TZ=UTC TB --- 2014-01-02 21:00:53 - __MAKE_CONF=/dev/null TB --- 2014-01-02 21:00:53 - cd /src TB --- 2014-01-02 21:00:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 2 21:00:53 UTC 2014 >>> 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 [...] machine -> /src/sys/arm/include cc -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -ffreestanding /src/sys/arm/arm/genassym.c In file included from /src/sys/arm/arm/genassym.c:48: In file included from ./machine/intr.h:71: /src/sys/sys/bus.h:585:10: fatal error: 'device_if.h' file not found #include "device_if.h" ^ 1 error generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-01-02 21:01:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-02 21:01:27 - ERROR: failed to build LINT kernel TB --- 2014-01-02 21:01:27 - 8689.23 user 1649.62 system 11467.94 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 01:38:09 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1AD72F52; Fri, 3 Jan 2014 01:38:09 +0000 (UTC) Received: from worker01.tb.des.no (worker01.tb.des.no [41.154.2.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4FB5C17A9; Fri, 3 Jan 2014 01:38:07 +0000 (UTC) Received: from worker01.tb.des.no (localhost [127.0.0.1]) by worker01.tb.des.no (8.14.5/8.14.5) with ESMTP id s031buqA065998; Fri, 3 Jan 2014 03:37:56 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s031bue3065979; Fri, 3 Jan 2014 01:37:56 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 3 Jan 2014 01:37:56 GMT Message-Id: <201401030137.s031bue3065979@worker01.tb.des.no> X-Authentication-Warning: worker01.tb.des.no: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_10 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 01:38:09 -0000 TB --- 2014-01-03 01:10:32 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-01-03 01:10:32 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-01-03 01:10:32 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-01-03 01:10:32 - cleaning the object tree TB --- 2014-01-03 01:10:32 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-01-03 01:11:24 - At svn revision 260215 TB --- 2014-01-03 01:11:25 - building world TB --- 2014-01-03 01:11:25 - CROSS_BUILD_TESTING=YES TB --- 2014-01-03 01:11:25 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-03 01:11:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-03 01:11:25 - SRCCONF=/dev/null TB --- 2014-01-03 01:11:25 - TARGET=arm TB --- 2014-01-03 01:11:25 - TARGET_ARCH=arm TB --- 2014-01-03 01:11:25 - TZ=UTC TB --- 2014-01-03 01:11:25 - __MAKE_CONF=/dev/null TB --- 2014-01-03 01:11:25 - cd /src TB --- 2014-01-03 01:11:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jan 3 01:11:35 UTC 2014 >>> 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 [...] c++ -O2 -pipe -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen -I. -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGObjC.cpp -o CGObjC.o c++ -O2 -pipe -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen -I. -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGObjCGNU.cpp -o CGObjCGNU.o c++ -O2 -pipe -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen -I. -I/src/lib/clang/libclangcodegen/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-gnueabi-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGObjCMac.cpp -o CGObjCMac.o /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGObjCMac.cpp: In member function 'virtual llvm::Constant*::CGObjCMac::GetOrEmitProtocol(const clang::ObjCProtocolDecl*)': /src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/lib/CodeGen/CGObjCMac.cpp:2576: internal compiler error: in var_ann, at tree-flow-inline.h:127 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop. bmake[3]: stopped in /src/lib/clang/libclangcodegen *** Error code 1 Stop. bmake[2]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** [buildworld] Error code 1 Stop in /src. TB --- 2014-01-03 01:37:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-03 01:37:56 - ERROR: failed to build world TB --- 2014-01-03 01:37:56 - 1220.27 user 427.39 system 1644.34 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 05:10:34 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6C1522A; Fri, 3 Jan 2014 05:10:34 +0000 (UTC) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 84301173A; Fri, 3 Jan 2014 05:10:34 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id s035AWDd043981; Fri, 3 Jan 2014 05:10:32 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id s035AWc9043980; Fri, 3 Jan 2014 05:10:32 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 3 Jan 2014 05:10:32 GMT Message-Id: <201401030510.s035AWc9043980@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 05:10:34 -0000 TB --- 2014-01-03 04:00:21 - tinderbox 2.20 running on freebsd-stable.sentex.ca TB --- 2014-01-03 04:00:21 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2014-01-03 04:00:21 - starting RELENG_9 tinderbox run for arm/arm TB --- 2014-01-03 04:00:21 - cleaning the object tree TB --- 2014-01-03 04:00:21 - /usr/local/bin/svn stat /src TB --- 2014-01-03 04:00:27 - At svn revision 260218 TB --- 2014-01-03 04:00:28 - building world TB --- 2014-01-03 04:00:28 - CROSS_BUILD_TESTING=YES TB --- 2014-01-03 04:00:28 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-03 04:00:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-03 04:00:28 - SRCCONF=/dev/null TB --- 2014-01-03 04:00:28 - TARGET=arm TB --- 2014-01-03 04:00:28 - TARGET_ARCH=arm TB --- 2014-01-03 04:00:28 - TZ=UTC TB --- 2014-01-03 04:00:28 - __MAKE_CONF=/dev/null TB --- 2014-01-03 04:00:28 - cd /src TB --- 2014-01-03 04:00:28 - /usr/bin/make -B buildworld >>> World build started on Fri Jan 3 04:00:28 UTC 2014 >>> 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 [...] /src/usr.bin/kdump/kdump.c:1034: error: (Each undeclared identifier is reported only once /src/usr.bin/kdump/kdump.c:1034: error: for each function it appears in.) /src/usr.bin/kdump/kdump.c: In function 'ktruser_rtld': /src/usr.bin/kdump/kdump.c:1290: warning: cast increases required alignment of target type /src/usr.bin/kdump/kdump.c: In function 'ktruser_malloc': /src/usr.bin/kdump/kdump.c:1376: warning: cast increases required alignment of target type /src/usr.bin/kdump/kdump.c: In function 'ktrfault': /src/usr.bin/kdump/kdump.c:1632: warning: format '%jx' expects type 'uintmax_t', but argument 2 has type 'vm_offset_t' *** Error code 1 Stop in /src/usr.bin/kdump. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2014-01-03 05:10:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-03 05:10:32 - ERROR: failed to build world TB --- 2014-01-03 05:10:32 - 2650.31 user 522.79 system 4210.60 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 05:22:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 462094FF for ; Fri, 3 Jan 2014 05:22:03 +0000 (UTC) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2C1A81818 for ; Fri, 3 Jan 2014 05:22:02 +0000 (UTC) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by smtp2.hushmail.com (Postfix) with SMTP id 0C330A00BB for ; Fri, 3 Jan 2014 05:22:02 +0000 (UTC) Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) by smtp2.hushmail.com (Postfix) with ESMTP for ; Fri, 3 Jan 2014 05:22:01 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id E9397200F5; Fri, 3 Jan 2014 05:22:01 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 03 Jan 2014 00:22:01 -0500 To: freebsd-arm@freebsd.org Subject: Beagle recommendations From: chump1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20140103052201.E9397200F5@smtp.hushmail.com> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 05:22:03 -0000 I have a fairly simple task that involves processing something in a 2D array, MxN times. I took a naive approach, 1x process 1x thread, and it took a little longer than desired. Well now, I could do better with some multi processing, especially on a multi core box, right? Well, I have not had much luck. At first I spawned M threads and had each iterate over each N in turn, with M between 25-35. It took much, much longer than the single thread. I figured contention and overhead were costing me big, and gave it a shot with a scaled down version of the problem, M=10. Still, much slower than the single thread. A little confused, I went back to the big problem set (25-35), and made a new program that spawned only two threads, and each is limited to processing only even or only odd data sets. Even that still takes twice as long as the single thread version! What is up with that? More important asides, I am barely doing any real processing at all. It is basically a no-op, barely doing more than incrementing the counter. Should I expect to see performance gains once I am doing real work in the processing portion of my program? Should I expect to see much different behavior on a different OS? Also I have one physical processor, two cores. Would I see better gains with more cores? How do you find processes and threads scale against hardware overall? Thanks! Sent using Hushmail From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 05:53:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD062CDA for ; Fri, 3 Jan 2014 05:53:48 +0000 (UTC) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B37571A0D for ; Fri, 3 Jan 2014 05:53:48 +0000 (UTC) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id EEAD560119 for ; Fri, 3 Jan 2014 05:23:27 +0000 (UTC) Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) by smtp5.hushmail.com (Postfix) with ESMTP for ; Fri, 3 Jan 2014 05:23:27 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id D526D200F5; Fri, 3 Jan 2014 05:23:27 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 03 Jan 2014 00:23:27 -0500 To: freebsd-arm@freebsd.org Subject: Beagle recommendations for real From: chump1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20140103052327.D526D200F5@smtp.hushmail.com> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 05:53:48 -0000 I have been toying with my Raspberry Pi for a while now, stuck with Linux thus far. I need to make another pass at FreeBSD on the Pi but between reports of NetBSD bugs and struggles, I cannot help but wonder, perhaps the Beagle products are a little more solid for BSD use. Certainly they have a lot more I/O options than the Pi as well. Could someone with some experience please share? Also I am a little confused by the Beagle product line, it looks like the Bone and Bone Black are both superior to the original, yet the original continues to be sold at a higher price. Is that correct or am I missing something? Thanks! Sent using Hushmail From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 06:07:19 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C47444BA for ; Fri, 3 Jan 2014 06:07:19 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9E2F21AD4 for ; Fri, 3 Jan 2014 06:07:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=YEInKPeXyFm/K39F1/akU6ImmnTvtwD8rIGGwjKh0a4=; b=dKHB7oQg8zuCalFcqxljCthvXh1g5edyhhGAetFogeIlkS2kpaMNl1tPGXGG4Hx4NttKTEYiWm/zMpvmpwZD+91BAjqARKLT5IXuBhT8DlbRJlfj6TMloTrZujyAYQ/5Abp0DWxY9MlyJu7R5nDaZW591AQYO7KNWMU6JcfzKpY=; Received: from [120.174.102.146] (port=49819 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Vyxua-0014QJ-E0; Thu, 02 Jan 2014 23:07:13 -0700 Date: Fri, 3 Jan 2014 14:06:58 +0800 From: Erich Dollansky To: chump1@hushmail.com Subject: Re: Beagle recommendations Message-ID: <20140103140658.071f970d@X220.alogt.com> In-Reply-To: <20140103052201.E9397200F5@smtp.hushmail.com> References: <20140103052201.E9397200F5@smtp.hushmail.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 06:07:19 -0000 Hi, On Fri, 03 Jan 2014 00:22:01 -0500 chump1@hushmail.com wrote: I have to say that my experience is not related to ARM CPUs but PA-RISC, SPARC and x86 CPUs. > > I have a fairly simple task that involves processing something in a > 2D array, MxN times. I took a naive approach, 1x process 1x thread, > and it took a little longer than desired. Well now, I could do better > with some multi processing, especially on a multi core box, right? > One process and one thread? You should not gain much as I understand your writing. > > Well, I have not had much luck. At first I spawned M threads and had > each iterate over each N in turn, with M between 25-35. It took much, > much longer than the single thread. I figured contention and overhead > were costing me big, and gave it a shot with a scaled down version of > the problem, M=10. Still, much slower than the single thread. A > little confused, I went back to the big problem set (25-35), and made > a new program that spawned only two threads, and each is limited to > processing only even or only odd data sets. Even that still takes > twice as long as the single thread version! What is up with that? > Did you try one process per row having one thread per column? Do the processes and threads have to interact or can each element processed independent of the other elements? > > More important asides, I am barely doing any real processing at all. > It is basically a no-op, barely doing more than incrementing the > counter. Should I expect to see performance gains once I am doing > real work in the processing portion of my program? Should I expect to You will not see the performance drop if you do more processing as the context switches cost at the moment more time than anything else. > see much different behavior on a different OS? Also I have one If you would use a real-time OS, it could be possible but I see it unlikely as your problem has nothing to do with reaction time. > physical processor, two cores. Would I see better gains with more > cores? How do you find processes and threads scale against hardware > overall? Your main problem seems to be that you keep the OS busy with context switches. Use more loops. You could try one process with one thread per row and then loop through the columns. Again, if your problem will allow this. And never forget, if this is all in a single array, you could use a single process and then try to find the proper mix between number of threads and loops. This would take some load of the CPU cache. Erich From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 06:14:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56F73625 for ; Fri, 3 Jan 2014 06:14:50 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 30E291B68 for ; Fri, 3 Jan 2014 06:14:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=5ZE0LuVHOhQspqnY5ED7a7ORjzyY+HJeD5+7DiMYANk=; b=NidSmIb5xXjAI+BWhp0Oph3IwUYqlBYlzGUlsxpYZzblyT1pdgy7p3X5v/Y+8+LZKcbdIbxFIPxRLMbzjGAOcqYYHZhd5EJ2vF2ssZHniV1UEpWa67bLTdjMCbRtSlz75YZS9dAxjJL866Xf0PH0xjroYViGOU4px8tH9tPibYE=; Received: from [120.174.102.146] (port=14259 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Vyy1w-0016Gr-Qv; Thu, 02 Jan 2014 23:14:49 -0700 Date: Fri, 3 Jan 2014 14:14:23 +0800 From: Erich Dollansky To: chump1@hushmail.com Subject: Re: Beagle recommendations for real Message-ID: <20140103141423.500d0212@X220.alogt.com> In-Reply-To: <20140103052327.D526D200F5@smtp.hushmail.com> References: <20140103052327.D526D200F5@smtp.hushmail.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 06:14:50 -0000 Hi, On Fri, 03 Jan 2014 00:23:27 -0500 chump1@hushmail.com wrote: > > I have been toying with my Raspberry Pi for a while now, stuck with > Linux thus far. I need to make another pass at FreeBSD on the Pi but > between reports of NetBSD bugs and struggles, I cannot help but > wonder, perhaps the Beagle products are a little more solid for BSD > use. Certainly they have a lot more I/O options than the Pi as well. > > > > > Could someone with some experience please share? Also I am a little > confused by the Beagle product line, it looks like the Bone and Bone > Black are both superior to the original, yet the original continues > to be sold at a higher price. Is that correct or am I missing > something? > I just have another question. I would need an extension card with at least two relays able to switch 250V AC but a low load of less than 100W. Do you of any card which could do the job? Erich From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 06:19:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B12B719 for ; Fri, 3 Jan 2014 06:19:50 +0000 (UTC) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C90FB1C8B for ; Fri, 3 Jan 2014 06:19:49 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id tp5so15002869ieb.25 for ; Thu, 02 Jan 2014 22:19:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=H5ymLTyG2GUT8Lymz9NfaOkXpCC8r2b6ysxcHSrRZ50=; b=fHcGNc4DrEIksWIXldPwMehagE9tFpqwob9K+GGNxBbVhB/c5mFVx5uDlR4h+xG7q+ bUcdTgzsjkaN/X5MPC5h8BhxF23CPE8fU0ij9nHRPR0v8dZf2A4huY1abYHhy4HsOYIZ FkIoVjbB4161WNEfoI88PV3KuAnllmH4Zodj7C+hyrXt7UR5K3tj1nQ4trrwXWfSKMbA XWTMsyaAnAsM4KahaJDcqKLlfeHy9YrFw++aA7pdxyFvAFNU7f8t1iI+FOXlapdETNm7 tq3t/h/V8Kh/zUCKXpHwvnwaqXR2UV0KHdR/TzZhhd94SMSPw7zRfKISxixhUAB0stAI n1fw== X-Gm-Message-State: ALoCoQnH4bqJaLRG2o5ieUQ+2I0uHgBPpmU1cpkgfhxBjfWGsm4HuEeaDoBhY8fQOAURn0CJcyyw X-Received: by 10.43.49.132 with SMTP id va4mr3007icb.79.1388729615921; Thu, 02 Jan 2014 22:13:35 -0800 (PST) Received: from [10.0.0.23] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id da14sm887442igc.1.2014.01.02.22.13.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Jan 2014 22:13:35 -0800 (PST) Sender: Warner Losh Subject: Re: Beagle recommendations Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20140103052201.E9397200F5@smtp.hushmail.com> Date: Thu, 2 Jan 2014 23:13:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140103052201.E9397200F5@smtp.hushmail.com> To: chump1@hushmail.com X-Mailer: Apple Mail (2.1085) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 06:19:50 -0000 Do you have options SMP in your kernel? Warner On Jan 2, 2014, at 10:22 PM, chump1@hushmail.com wrote: >=20 > I have a fairly simple task that involves processing something in a 2D = array, MxN times. I took a naive approach, 1x process 1x thread, and it = took a little longer than desired. Well now, I could do better with some = multi processing, especially on a multi core box, right? >=20 >=20 >=20 >=20 > Well, I have not had much luck. At first I spawned M threads and had = each iterate over each N in turn, with M between 25-35. It took much, = much longer than the single thread. I figured contention and overhead = were costing me big, and gave it a shot with a scaled down version of = the problem, M=3D10. Still, much slower than the single thread. A little = confused, I went back to the big problem set (25-35), and made a new = program that spawned only two threads, and each is limited to processing = only even or only odd data sets. Even that still takes twice as long as = the single thread version! What is up with that? >=20 >=20 >=20 >=20 > More important asides, I am barely doing any real processing at all. = It is basically a no-op, barely doing more than incrementing the = counter. Should I expect to see performance gains once I am doing real = work in the processing portion of my program? Should I expect to see = much different behavior on a different OS? Also I have one physical = processor, two cores. Would I see better gains with more cores? How do = you find processes and threads scale against hardware overall? >=20 >=20 >=20 >=20 > Thanks! >=20 >=20 > Sent using Hushmail >=20 > _______________________________________________ > 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" From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 06:28:28 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB3BD819 for ; Fri, 3 Jan 2014 06:28:28 +0000 (UTC) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 972E71D01 for ; Fri, 3 Jan 2014 06:28:28 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id k19so424002igc.2 for ; Thu, 02 Jan 2014 22:28:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=88hRM0bUND6N7AtDL2lcT3YR4HDh5zNiMutkUIa/FVY=; b=WmDJ/SGaxK4avvwc+rx+OLmLNyMTSOlqPOKjtbNkVM5z2NxIzhPQzQfkRuRuwByfeg K0/SFHzXAHk3QTHZE1rJm/tnzhv7Qlv+S1S9J+9NTs7+tJtWrJCi8Qpoti3wf0tFhQI+ lj9VnSUL96f4vQb6pKzxtoJahiB+PxpjcWIvOi8nb1K20rmJpvnuiPDcMF1cm0LuI22F xBL6BnBp4kuvoa+QhJqPh8Ub07w2Ompi8XOzfdMEAMZGnEZKWDBwm8zBamrcOdbNM5sv OOdaatUsfJ499L8w4zIMLr4uC4oYlNecI15ONhPvABRFpcnIpqmMhC9wg6MXisqlujQE fzVw== X-Gm-Message-State: ALoCoQm7osnMQMBhf6UZc/9PE6fkcR2GPLWiTtzmmq5mPT933f56SFZb8oOA+QS4Q2eXCF1nD45pU0ajwE0DHpgGUUj83mziJaopBOtIh+cvRxWJnZMLUdA= X-Received: by 10.43.161.2 with SMTP id me2mr63650575icc.20.1388730501572; Thu, 02 Jan 2014 22:28:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.128.200 with HTTP; Thu, 2 Jan 2014 22:28:06 -0800 (PST) In-Reply-To: <20140103052327.D526D200F5@smtp.hushmail.com> References: <20140103052327.D526D200F5@smtp.hushmail.com> From: "Lundberg, Johannes" Date: Fri, 3 Jan 2014 15:28:06 +0900 Message-ID: Subject: Re: Beagle recommendations for real To: chump1@hushmail.com Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 06:28:28 -0000 Hi I'm currently doing some experimenting with BeagleBone Black and FreeBSD 10-releng. Using crochet-freebsd script works great for creating an image to burn onto a sdmicro card. It's also very easy to customize and add your own overlay files. The default kernel config and settings creates a bootable image for me. The base system seems to be very stable and runs fine. I can play with the 4 LED's using gpioctl. However, I had some crashes when building ports. Not sure if it is related or not but it has not happened since I added swap memory file. I have a ports directory which I share over NFS, there I am now building ports and creating packages. However, many ports seems to be broken on arm. I want to run GNUstep environment but am missing some libraries. What I am (currently) missing is: HDMI driver libffi (builds but hangs during test) libgcrypt (does not build) libicu (builds but reports many errors in numeric test section) There seem to be a LCD driver so I considering buying a LCD display and then try get X running. I also have FreeBSD 10 running on a Raspberry Pi but it is painfully slow and you can get the BBB for almost the same price. However, Raspberry Pi supports HDMI so you can connect a monitor and maybe run X. As a follow up question to any one reading, what are the possibilities of seeing a graphics driver for TI's arm chips any time soon? And as a side note, I have been trying to get FreeBSD running on Pandaboard but I can't even get it through the boot sequence. Possibly mmc driver problem?.. I recommend BBB. -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Fri, Jan 3, 2014 at 2:23 PM, wrote: > > I have been toying with my Raspberry Pi for a while now, stuck with Linux > thus far. I need to make another pass at FreeBSD on the Pi but between > reports of NetBSD bugs and struggles, I cannot help but wonder, perhaps the > Beagle products are a little more solid for BSD use. Certainly they have a > lot more I/O options than the Pi as well. > > > > > Could someone with some experience please share? Also I am a little > confused by the Beagle product line, it looks like the Bone and Bone Black > are both superior to the original, yet the original continues to be sold at > a higher price. Is that correct or am I missing something? > > > > > Thanks! > > > Sent using Hushmail > > _______________________________________________ > 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" > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- $BHkL)J];}$K$D$$$F!'$3$NEE;R%a!<%k$O!"L>08?M$KAw?.$7$?$b$N$G$"$j!"HkF?FC8"$NBP>]$H$J$k>pJs$r4^$s$G$$$^$9!#(B $B$b$7!"L>08?M0J30$NJ}$,l9g!"$3$N%a!<%k$NGK4~!"$*$h$S$3$N%a!<%k$K4X$9$k0l@Z$N3+<(!"(B $BJ#$NMxMQ!"$^$?$O5-:\FbMF$K4p$E$/$$$+$J$k9TF0$b$5$l$J$$$h$&$*4j$$?=$7>e$2$^$9!#(B --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 07:56:18 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88F42F74; Fri, 3 Jan 2014 07:56:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4E02A12F3; Fri, 3 Jan 2014 07:56:18 +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 s037uHX2022832; Fri, 3 Jan 2014 02:56:17 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s037uHjl022829; Fri, 3 Jan 2014 07:56:17 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 3 Jan 2014 07:56:17 GMT Message-Id: <201401030756.s037uHjl022829@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 07:56:18 -0000 TB --- 2014-01-03 04:50:21 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-03 04:50:21 - 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 --- 2014-01-03 04:50:21 - starting HEAD tinderbox run for arm/arm TB --- 2014-01-03 04:50:21 - cleaning the object tree TB --- 2014-01-03 04:53:08 - /usr/local/bin/svn stat /src TB --- 2014-01-03 04:53:11 - At svn revision 260218 TB --- 2014-01-03 04:53:12 - building world TB --- 2014-01-03 04:53:12 - CROSS_BUILD_TESTING=YES TB --- 2014-01-03 04:53:12 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-03 04:53:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-03 04:53:12 - SRCCONF=/dev/null TB --- 2014-01-03 04:53:12 - TARGET=arm TB --- 2014-01-03 04:53:12 - TARGET_ARCH=arm TB --- 2014-01-03 04:53:12 - TZ=UTC TB --- 2014-01-03 04:53:12 - __MAKE_CONF=/dev/null TB --- 2014-01-03 04:53:12 - cd /src TB --- 2014-01-03 04:53:12 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jan 3 04:53:19 UTC 2014 >>> 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 Fri Jan 3 07:55:46 UTC 2014 TB --- 2014-01-03 07:55:46 - generating LINT kernel config TB --- 2014-01-03 07:55:46 - cd /src/sys/arm/conf TB --- 2014-01-03 07:55:46 - /usr/bin/make -B LINT TB --- 2014-01-03 07:55:46 - cd /src/sys/arm/conf TB --- 2014-01-03 07:55:46 - /usr/sbin/config -m LINT TB --- 2014-01-03 07:55:46 - building LINT kernel TB --- 2014-01-03 07:55:46 - CROSS_BUILD_TESTING=YES TB --- 2014-01-03 07:55:46 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-03 07:55:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-03 07:55:46 - SRCCONF=/dev/null TB --- 2014-01-03 07:55:46 - TARGET=arm TB --- 2014-01-03 07:55:46 - TARGET_ARCH=arm TB --- 2014-01-03 07:55:46 - TZ=UTC TB --- 2014-01-03 07:55:46 - __MAKE_CONF=/dev/null TB --- 2014-01-03 07:55:46 - cd /src TB --- 2014-01-03 07:55:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jan 3 07:55:46 UTC 2014 >>> 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 [...] machine -> /src/sys/arm/include cc -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -ffreestanding /src/sys/arm/arm/genassym.c In file included from /src/sys/arm/arm/genassym.c:48: In file included from ./machine/intr.h:71: /src/sys/sys/bus.h:585:10: fatal error: 'device_if.h' file not found #include "device_if.h" ^ 1 error generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-01-03 07:56:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-03 07:56:17 - ERROR: failed to build LINT kernel TB --- 2014-01-03 07:56:17 - 8690.95 user 1636.95 system 11155.65 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 10:13:45 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BBF4788; Fri, 3 Jan 2014 10:13:45 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4EBCE1DE4; Fri, 3 Jan 2014 10:13:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s03ADj1h070914; Fri, 3 Jan 2014 10:13:45 GMT (envelope-from rene@freefall.freebsd.org) Received: (from rene@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s03ADjVZ070913; Fri, 3 Jan 2014 10:13:45 GMT (envelope-from rene) Date: Fri, 3 Jan 2014 10:13:45 GMT Message-Id: <201401031013.s03ADjVZ070913@freefall.freebsd.org> To: rene@FreeBSD.org, freebsd-arm@FreeBSD.org, rene@FreeBSD.org From: rene@FreeBSD.org Subject: Re: ports/175605: please fix build binutils-2.23.1 in raspberry pi X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 10:13:45 -0000 Synopsis: please fix build binutils-2.23.1 in raspberry pi Responsible-Changed-From-To: freebsd-arm->rene Responsible-Changed-By: rene Responsible-Changed-When: Fri Jan 3 10:13:34 UTC 2014 Responsible-Changed-Why: Take http://www.freebsd.org/cgi/query-pr.cgi?pr=175605 From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 13:29:44 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64A62328 for ; Fri, 3 Jan 2014 13:29:44 +0000 (UTC) Received: from smtp3.hushmail.com (smtp3a.hushmail.com [65.39.178.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 45A041B17 for ; Fri, 3 Jan 2014 13:29:43 +0000 (UTC) Received: from smtp3.hushmail.com (smtp3a.hushmail.com [65.39.178.201]) by smtp3.hushmail.com (Postfix) with SMTP id 8D911E01AB for ; Fri, 3 Jan 2014 12:59:17 +0000 (UTC) Received: from smtp.hushmail.com (w4.hushmail.com [65.39.178.50]) by smtp3.hushmail.com (Postfix) with ESMTP; Fri, 3 Jan 2014 12:59:17 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 2540CC0288; Fri, 3 Jan 2014 12:59:17 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 03 Jan 2014 04:59:16 -0800 To: "Erich Dollansky" , imp@bsdimp.com Subject: Re: Beagle recommendations From: "Dave Ng" In-Reply-To: <20140103140658.071f970d@X220.alogt.com> References: <20140103052201.E9397200F5@smtp.hushmail.com> <20140103140658.071f970d@X220.alogt.com> Message-Id: <20140103125917.2540CC0288@smtp.hushmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 13:29:44 -0000 Thanks Erich and Warner for the help! Sorry for cluttering up -arm, this was intended for -hackers and I got a little paste-happy without enough sleep. Moving back to -hackers when I give this another shot. Sent using Hushmail On January 2, 2014 at 10:07 PM, "Erich Dollansky" wrote:Hi, On Fri, 03 Jan 2014 00:22:01 -0500 chump1@hushmail.com wrote: I have to say that my experience is not related to ARM CPUs but PA-RISC, SPARC and x86 CPUs. > > I have a fairly simple task that involves processing something in a > 2D array, MxN times. I took a naive approach, 1x process 1x thread, > and it took a little longer than desired. Well now, I could do better > with some multi processing, especially on a multi core box, right? > One process and one thread? You should not gain much as I understand your writing. > > Well, I have not had much luck. At first I spawned M threads and had > each iterate over each N in turn, with M between 25-35. It took much, > much longer than the single thread. I figured contention and overhead > were costing me big, and gave it a shot with a scaled down version of > the problem, M=10. Still, much slower than the single thread. A > little confused, I went back to the big problem set (25-35), and made > a new program that spawned only two threads, and each is limited to > processing only even or only odd data sets. Even that still takes > twice as long as the single thread version! What is up with that? > Did you try one process per row having one thread per column? Do the processes and threads have to interact or can each element processed independent of the other elements? > > More important asides, I am barely doing any real processing at all. > It is basically a no-op, barely doing more than incrementing the > counter. Should I expect to see performance gains once I am doing > real work in the processing portion of my program? Should I expect to You will not see the performance drop if you do more processing as the context switches cost at the moment more time than anything else. > see much different behavior on a different OS? Also I have one If you would use a real-time OS, it could be possible but I see it unlikely as your problem has nothing to do with reaction time. > physical processor, two cores. Would I see better gains with more > cores? How do you find processes and threads scale against hardware > overall? Your main problem seems to be that you keep the OS busy with context switches. Use more loops. You could try one process with one thread per row and then loop through the columns. Again, if your problem will allow this. And never forget, if this is all in a single array, you could use a single process and then try to find the proper mix between number of threads and loops. This would take some load of the CPU cache. Erich From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 15:26:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 326FC915 for ; Fri, 3 Jan 2014 15:26:12 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BC147168A for ; Fri, 3 Jan 2014 15:26:11 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id q59so13392184wes.41 for ; Fri, 03 Jan 2014 07:26:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=19z3ygDX38gJBB3FcJ6XV1obV+J19i8DUKynTZHRY0I=; b=zqzRWo1bXj57GL5MAlX18k3vTdNUcN3NTmQjJPBfw8HQzUtTD2PhCMKtBDbSyjdfiN XKES0+cujz/DbBeQL/p3AD+RHQiC90o02ttzsdHP/TB9FYzii+2NgRaXgX6qlq0H4u4u AooFgKWFAbBcbLvS+6mbTsHknc6tdZ7/L8NUpxe+PzMlqioAEoSJy5LE2ZhkmLObaeY6 cCejLGgkZmbvSnmqkNULzMrdUxljZT7BLRSSUj7cRWFa+whPmYXXRnpkMNMpoRv61VoA YVrtfoiddkTURGuaUtTPq2sUbgMezZDbmhHGlZa/OmC9+fYefVMfS6pvEfratAWXs93A TmCg== X-Received: by 10.194.60.103 with SMTP id g7mr60927965wjr.37.1388762770126; Fri, 03 Jan 2014 07:26:10 -0800 (PST) Received: from [192.168.113.40] (43.Red-2-139-192.staticIP.rima-tde.net. [2.139.192.43]) by mx.google.com with ESMTPSA id v7sm3024214wix.5.2014.01.03.07.26.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Jan 2014 07:26:09 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Beagle recommendations for real From: fabiodive In-Reply-To: <20140103141423.500d0212@X220.alogt.com> Date: Fri, 3 Jan 2014 15:26:04 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <108B8A9D-00F3-4F59-9C17-6C7004C7C0E4@gmail.com> References: <20140103052327.D526D200F5@smtp.hushmail.com> <20140103141423.500d0212@X220.alogt.com> To: Erich Dollansky X-Mailer: Apple Mail (2.1510) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 15:26:12 -0000 Hello all, I really like BBB and for computation works I prefer it over RPI, also the ethernet stack of BBB is more solid and faster than RPI, RPI appear to me best suited for video processing, To produce a shield for BBB consider using a HEXFET MOSFET with a optocoupler connected to a GPIO. I can design a schematic and assembly a custom board if you like. I deploy FreeBSD on BBB using crochet script and some overlay files I inject in the root during install. For GPIO under FreeBSD try to give = a=20 look to this: http://zewaren.net/site/?q=3Dnode/114 you could use a python script to drive the outputs shield. I can also write some code in C or python to manage the MOSFET shield. Thank you all F. =20 On Jan 3, 2014, at 6:14 AM, Erich Dollansky = wrote: > Hi, >=20 > On Fri, 03 Jan 2014 00:23:27 -0500 > chump1@hushmail.com wrote: >=20 >>=20 >> I have been toying with my Raspberry Pi for a while now, stuck with >> Linux thus far. I need to make another pass at FreeBSD on the Pi but >> between reports of NetBSD bugs and struggles, I cannot help but >> wonder, perhaps the Beagle products are a little more solid for BSD >> use. Certainly they have a lot more I/O options than the Pi as well. >>=20 >>=20 >>=20 >>=20 >> Could someone with some experience please share? Also I am a little >> confused by the Beagle product line, it looks like the Bone and Bone >> Black are both superior to the original, yet the original continues >> to be sold at a higher price. Is that correct or am I missing >> something? >>=20 > I just have another question. I would need an extension card with at > least two relays able to switch 250V AC but a low load of less than > 100W. Do you of any card which could do the job? >=20 > Erich > _______________________________________________ > 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" From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 17:13:03 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C66BA5D; Fri, 3 Jan 2014 17:13:03 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1FAB51FCE; Fri, 3 Jan 2014 17:13:02 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vz8Iq-000LNe-De; Fri, 03 Jan 2014 17:12:56 +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 s03HCsxA024096; Fri, 3 Jan 2014 10:12:54 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+0qgZjObqQudJIe2fpSeom Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) From: Ian Lepore To: Nathan Whitehorn In-Reply-To: <52C35398.2090502@freebsd.org> References: <20131231211054.GA90299@moore.morphism.de> <52C35398.2090502@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Fri, 03 Jan 2014 10:12:54 -0700 Message-ID: <1388769174.1158.269.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 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 17:13:03 -0000 On Tue, 2013-12-31 at 18:30 -0500, Nathan Whitehorn wrote: > On 12/31/13 16:10, Markus Pfeiffer wrote: > > Hi all, > > > > I managed "fixing" it by editing the dockstar.dts file and putting for ranges: > > > > ranges = <0x0 0x2f 0xf9300000 0x00100000> > > > > Now I just have to figure out why this "fixes" it, and what damage that patch > > does. > > I also have some pathces for the LED on the dockstar which will tip up in my > > github soon. > > > > Cheers, > > markus > > Which node did you add this to? I'm trying to make our FDT code more > standards-compliant. This seems like something where we missed a spot. > -Nathan The surrounding context looks like this: localbus@f1000000 { #address-cells = <2>; #size-cells = <1>; compatible = "mrvl,lbc"; /* This reflects CPU decode windows setup. */ ranges = <0x0 0x0f 0xf9300000 0x00100000 0x1 0x1e 0xfa000000 0x00100000 0x2 0x1d 0xfa100000 0x02000000 0x3 0x1b 0xfc100000 0x00000400>; nor@0,0 { #address-cells = <1>; Specifying ranges here is a Marvel-SoC-specific thing, other arm socs don't require it. The Marvell code uses these values to set up hardware memory mapping; on the Marvell chips it's possible to map DRAM, NAND, PCIe, etc into physical address ranges of your choosing. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 17:15:38 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58249B85; Fri, 3 Jan 2014 17:15:38 +0000 (UTC) Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 250EA1FED; Fri, 3 Jan 2014 17:15:37 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MYU003004Y5LB00@smtpauth4.wiscmail.wisc.edu>; Fri, 03 Jan 2014 11:15:36 -0600 (CST) X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.3.170617, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (pool-72-66-107-173.washdc.fios.verizon.net [72.66.107.173]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MYU0047759ZKO00@smtpauth4.wiscmail.wisc.edu>; Fri, 03 Jan 2014 11:15:36 -0600 (CST) Message-id: <52C6F037.1050300@freebsd.org> Date: Fri, 03 Jan 2014 12:15:35 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: Ian Lepore Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) References: <20131231211054.GA90299@moore.morphism.de> <52C35398.2090502@freebsd.org> <1388769174.1158.269.camel@revolution.hippie.lan> In-reply-to: <1388769174.1158.269.camel@revolution.hippie.lan> X-Enigmail-Version: 1.6 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 17:15:38 -0000 On 01/03/14 12:12, Ian Lepore wrote: > On Tue, 2013-12-31 at 18:30 -0500, Nathan Whitehorn wrote: >> On 12/31/13 16:10, Markus Pfeiffer wrote: >>> Hi all, >>> >>> I managed "fixing" it by editing the dockstar.dts file and putting for ranges: >>> >>> ranges = <0x0 0x2f 0xf9300000 0x00100000> >>> >>> Now I just have to figure out why this "fixes" it, and what damage that patch >>> does. >>> I also have some pathces for the LED on the dockstar which will tip up in my >>> github soon. >>> >>> Cheers, >>> markus >> Which node did you add this to? I'm trying to make our FDT code more >> standards-compliant. This seems like something where we missed a spot. >> -Nathan > The surrounding context looks like this: > > localbus@f1000000 { > #address-cells = <2>; > #size-cells = <1>; > compatible = "mrvl,lbc"; > > /* This reflects CPU decode windows setup. */ > ranges = <0x0 0x0f 0xf9300000 0x00100000 > 0x1 0x1e 0xfa000000 0x00100000 > 0x2 0x1d 0xfa100000 0x02000000 > 0x3 0x1b 0xfc100000 0x00000400>; > > nor@0,0 { > #address-cells = <1>; > > Specifying ranges here is a Marvel-SoC-specific thing, other arm socs > don't require it. The Marvell code uses these values to set up hardware > memory mapping; on the Marvell chips it's possible to map DRAM, NAND, > PCIe, etc into physical address ranges of your choosing. > > -- Ian > > Ah, it's this horrible broken fdt_immr() stuff. I've killed that on PPC now. I'll see what I can do for ARM. -Nathan From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 17:36:49 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B21112D for ; Fri, 3 Jan 2014 17:36:49 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4931199 for ; Fri, 3 Jan 2014 17:36:48 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vz8fv-000Apr-Tl; Fri, 03 Jan 2014 17:36:48 +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 s03HahxN024110; Fri, 3 Jan 2014 10:36:45 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19ROvydtcB3Wp0mo8LS/PqJ Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) From: Ian Lepore To: Markus Pfeiffer In-Reply-To: <20131231211054.GA90299@moore.morphism.de> References: <20131231211054.GA90299@moore.morphism.de> Content-Type: multipart/mixed; boundary="=-jckgBP4nfFzA4kCid71J" Date: Fri, 03 Jan 2014 10:36:43 -0700 Message-ID: <1388770603.1158.273.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 17:36:49 -0000 --=-jckgBP4nfFzA4kCid71J Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tue, 2013-12-31 at 21:10 +0000, Markus Pfeiffer wrote: > Hi all, > > I managed "fixing" it by editing the dockstar.dts file and putting for ranges: > > ranges = <0x0 0x2f 0xf9300000 0x00100000> > > Now I just have to figure out why this "fixes" it, and what damage that patch > does. > I also have some pathces for the LED on the dockstar which will tip up in my > github soon. > > Cheers, > markus After looking at the marvell code and docs, and some info I found about the dockstar at OpenWRT.org, I think the attached patch is the right fix for a dockstar (it maps the nand flash, and removes mappings for NOR flash and an LED; the dockstar doesn't seem to have NOR flash, and the LED thing seems to be out of place). Markus, could you please test this; if it works, I'll commit it. The only marvell hardware I have for testing is DreamPlug. -- Ian --=-jckgBP4nfFzA4kCid71J Content-Disposition: inline; filename="dockstar_dts.diff" Content-Type: text/x-patch; name="dockstar_dts.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/boot/fdt/dts/dockstar.dts =================================================================== --- sys/boot/fdt/dts/dockstar.dts (revision 259730) +++ sys/boot/fdt/dts/dockstar.dts (working copy) @@ -76,44 +76,17 @@ #size-cells = <1>; compatible = "mrvl,lbc"; - /* This reflects CPU decode windows setup. */ - ranges = <0x0 0x0f 0xf9300000 0x00100000 - 0x1 0x1e 0xfa000000 0x00100000 - 0x2 0x1d 0xfa100000 0x02000000 - 0x3 0x1b 0xfc100000 0x00000400>; + /* This reflects CPU decode windows setup for NAND access. */ + ranges = <0x0 0x2f 0xf9300000 0x00100000>; - nor@0,0 { + nand@0,0 { #address-cells = <1>; #size-cells = <1>; - compatible = "cfi-flash"; + compatible = "mrvl,nfc"; reg = <0x0 0x0 0x00100000>; bank-width = <2>; device-width = <1>; }; - - led@1,0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "led"; - reg = <0x1 0x0 0x00100000>; - }; - - nor@2,0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "cfi-flash"; - reg = <0x2 0x0 0x02000000>; - bank-width = <2>; - device-width = <1>; - }; - - nand@3,0 { - #address-cells = <1>; - #size-cells = <1>; - reg = <0x3 0x0 0x00100000>; - bank-width = <2>; - device-width = <1>; - }; }; SOC: soc88f6281@f1000000 { --=-jckgBP4nfFzA4kCid71J-- From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 17:59:26 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1238089D; Fri, 3 Jan 2014 17:59:26 +0000 (UTC) Received: from turing.morphism.de (turing.morphism.de [62.116.177.133]) by mx1.freebsd.org (Postfix) with ESMTP id C2AE51341; Fri, 3 Jan 2014 17:59:25 +0000 (UTC) Received: from localhost (moore.morphism.de [IPv6:2001:4178:4:202::136]) by turing.morphism.de (Postfix) with ESMTP id 50CD62F696; Fri, 3 Jan 2014 17:59:17 +0000 (UTC) Date: Fri, 3 Jan 2014 17:59:14 +0000 From: Markus Pfeiffer To: Ian Lepore Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) Message-ID: <20140103175914.GC98342@moore.morphism.de> References: <20131231211054.GA90299@moore.morphism.de> <1388770603.1158.273.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nmemrqcdn5VTmUEE" Content-Disposition: inline In-Reply-To: <1388770603.1158.273.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Markus Pfeiffer List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 17:59:26 -0000 --nmemrqcdn5VTmUEE Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Ian, On Fri, Jan 03, 2014 at 10:36:43AM -0700, Ian Lepore wrote: > On Tue, 2013-12-31 at 21:10 +0000, Markus Pfeiffer wrote: > > Hi all, > >=20 > > I managed "fixing" it by editing the dockstar.dts file and putting for = ranges: > >=20 > > ranges =3D <0x0 0x2f 0xf9300000 0x00100000> > >=20 > > Now I just have to figure out why this "fixes" it, and what damage that= patch > > does. > > I also have some pathces for the LED on the dockstar which will tip up = in my > > github soon. > >=20 > > Cheers, > > markus >=20 > After looking at the marvell code and docs, and some info I found about > the dockstar at OpenWRT.org, I think the attached patch is the right fix > for a dockstar (it maps the nand flash, and removes mappings for NOR > flash and an LED; the dockstar doesn't seem to have NOR flash, and the > LED thing seems to be out of place). >=20 Can I find information anywhere as to what this ranges command actually mea= ns? I was assuming it has something to do with memory mappings, but I didn't fi= nd any info as to what in particular the 0x2f _means_. > Markus, could you please test this; if it works, I'll commit it. The > only marvell hardware I have for testing is DreamPlug. It does indeed work. I am a bit surprised that noone seems to be running FreeBSD on a dockstar seriously enough to run into these problems. Some ugly problem in connection with USB seems to rear it's head atm: if I fsck a filesystem, it finds a lot of DUPs and starts deleting perfectly fine files. I changed to using sync as well as disabling clustered reads and writes. Maybe I'll find the time to investigate this issue as well. I hacked a bit on the gpio/led driver to make the LED work with gpioled, I'= ll post a patch to the mailing list when it's cleaned up if that's ok. markus --nmemrqcdn5VTmUEE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (DragonFly) iQIcBAEBAgAGBQJSxvpyAAoJEBRHBRYBD4mPI+sQAID5vge/l4iD0RuqTALk/m3R zKfoJ2IxCmOrhtm3kYlD4O5yHmTLgg4kXRjo1AxF2oOEH75adM/wvNdTFGgikVUg VolOax0UcT4EpprrQfbqc2soUxALc2wlEvlEGwcFeWpGAG76UF8VT0UTl5LG97uv umrHI5k9emlw/+1ebvydVjrGcVqBbt+wvm3dyLJDJZSYhmMGqAjk5V+ODBhCbIMo gzGwQsOcKqnlF36ibbhU9dzcoAqP9lHg7Hci/WredIwWUUYkYjOdwsTWPMi8Kheq LPSwauIU97DRLBIQ6csO8XF7xqr9xCEPly/9/OpxCb6iGWha/1ocznCkwWgzZlV0 281Ae1lWM6s1ApwCBcTpJhe/jcvrNCICHmXAitp79GY6bJ9n5VKf15Pz9sb3w7U6 tXO7VLMHSQkzb3lYnAAQ4vP4jNZlUpzK63e8IfBFzysF7HyYSojF/UXsSS3Cx95N v3Lmuxls8BOSN7LcthBHP5NksNIQwQxO8S69qYPAu1EagJNmKYmhlcxpfxCeahO7 d7H37/eWxhSHX1P7w5Sw1Gx6rhMQM/M8US54b/AHgLkVL5dvbHVcSNjGS16SrOpk yGoYnt6pQUCONI/Q/HJTuVh+aTXN6PlMNNt1CLg9tZyPqfxQDGEuCqvd2HxK4RJC hDbiI2SnmF18skGqHaOL =uMpn -----END PGP SIGNATURE----- --nmemrqcdn5VTmUEE-- From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 18:00:16 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A53D28FE for ; Fri, 3 Jan 2014 18:00:16 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7913C13A2 for ; Fri, 3 Jan 2014 18:00:16 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vz92c-000JRd-Nj; Fri, 03 Jan 2014 18:00:14 +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 s03I0BCe024139; Fri, 3 Jan 2014 11:00:12 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+KxCS5cil6YNOSHvt7LlfS Subject: Re: Boot failure for CURRENT on From: Ian Lepore To: Iain Young In-Reply-To: <52C1CDAC.2070002@g7iii.net> References: <52C13E6B.4070006@g7iii.net> <1388419719.1158.192.camel@revolution.hippie.lan> <52C1CDAC.2070002@g7iii.net> Content-Type: text/plain; charset="us-ascii" Date: Fri, 03 Jan 2014 11:00:11 -0700 Message-ID: <1388772011.1158.280.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 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 18:00:16 -0000 On Mon, 2013-12-30 at 19:46 +0000, Iain Young wrote: > On 30/12/13 16:08, Ian Lepore wrote: > > > Given that it appears to be dying in the dmtimer code I recently > > touched, I'd say my changes (r259739, 43, 44, 50) are a good candidate > > (except, of course, it works when I run it on my BBW). > > > > Do you have option PPS and do you have one of the timer trigger pins > > configured for capture? On my BBW, the next line of output I'd see is: > > Ah, that was the problem. I had assumed that your timer patch twiddled > with the dts, since your original patch did. That will teach me :) > > However, although I now get further, it seems it can't find my SD card: > > > Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... > mountroot: waiting for device /dev/mmcsd0s2a ... > usb_alloc_device: setting up USB template failed maybe the USB template > module has not been loaded > ugen0.2: at usbus0 (disconnected) > uhub_reattach_port: could not allocate new device > Mounting from ufs:/dev/mmcsd0s2a failed with error 19. > Trying to mount root from ufs:mmcsd0s2 []... > mountroot: waiting for device mmcsd0s2 ... > Mounting from ufs:mmcsd0s2 failed with error 19. > > Loader variables: > vfs.root.mountfrom=ufs:/dev/mmcsd0s2a > vfs.root.mountfrom.options=rw,noatime > > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. > > eg. ufs:/dev/da0s1a > zfs:tank > cd9660:/dev/acd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) > > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input > > mountroot> ? > > List of GEOM managed disk devices: > > > mountroot> > > > Did something change ? Is UFS now compiled as a module or something ? > I'm a bit concerned that "?" showed no managed disk devices. Any ideas ? Sorry for the delay, I got busy with a deadline at $work. So you're saying if you compile with OPTION_PPS and don't flag any timer pin as a capture input, it dies? That would be a bug in my PPS code, I'll look into that. Are you still having trouble with the sdcard? If so, please post your entire dmesg output, and the dts file you're using, and the kernel config you're using. (Or put them on like pastebin.ca and post the link). There was a change to the beaglebone sd stuff a few months back, maybe your kernel config or dts needs tweaking if you've customized them. Now instead of using the ti_mmchs driver, it uses a newer ti_sdhci driver. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 18:11:41 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A245EE2 for ; Fri, 3 Jan 2014 18:11:41 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F126314EE for ; Fri, 3 Jan 2014 18:11:40 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vz9Dg-0002nG-3M; Fri, 03 Jan 2014 18:11: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 s03IBa4W024148; Fri, 3 Jan 2014 11:11:36 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/iHvqRYkQLwvk7HNRwnwTU Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) From: Ian Lepore To: Markus Pfeiffer In-Reply-To: <20140103175914.GC98342@moore.morphism.de> References: <20131231211054.GA90299@moore.morphism.de> <1388770603.1158.273.camel@revolution.hippie.lan> <20140103175914.GC98342@moore.morphism.de> Content-Type: text/plain; charset="us-ascii" Date: Fri, 03 Jan 2014 11:11:35 -0700 Message-ID: <1388772695.1158.288.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 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 18:11:41 -0000 On Fri, 2014-01-03 at 17:59 +0000, Markus Pfeiffer wrote: > Hi Ian, > > On Fri, Jan 03, 2014 at 10:36:43AM -0700, Ian Lepore wrote: > > On Tue, 2013-12-31 at 21:10 +0000, Markus Pfeiffer wrote: > > > Hi all, > > > > > > I managed "fixing" it by editing the dockstar.dts file and putting for ranges: > > > > > > ranges = <0x0 0x2f 0xf9300000 0x00100000> > > > > > > Now I just have to figure out why this "fixes" it, and what damage that patch > > > does. > > > I also have some pathces for the LED on the dockstar which will tip up in my > > > github soon. > > > > > > Cheers, > > > markus > > > > After looking at the marvell code and docs, and some info I found about > > the dockstar at OpenWRT.org, I think the attached patch is the right fix > > for a dockstar (it maps the nand flash, and removes mappings for NOR > > flash and an LED; the dockstar doesn't seem to have NOR flash, and the > > LED thing seems to be out of place). > > > > Can I find information anywhere as to what this ranges command actually means? > I was assuming it has something to do with memory mappings, but I didn't find > any info as to what in particular the 0x2f _means_. > The information is in a PDF document from Marvell: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf The info is a little hard to puzzle out. The 0x2f is the attribute for mapping NAND flash; it's found near the end of Table 4. Because the attribute value was wrong in that dts you were using (it's a value not even listed in the table) I suspect it was making some kind of crazy dram or other device mapping that was interfering with normal memory access. > > Markus, could you please test this; if it works, I'll commit it. The > > only marvell hardware I have for testing is DreamPlug. > > It does indeed work. I am a bit surprised that noone seems to be running > FreeBSD on a dockstar seriously enough to run into these problems. > > Some ugly problem in connection with USB seems to rear it's head atm: if I > fsck a filesystem, it finds a lot of DUPs and starts deleting perfectly fine > files. I changed to using sync as well as disabling clustered reads and > writes. Maybe I'll find the time to investigate this issue as well. > This sounds a bit similar to a problem posted some weeks (hmmm, at this point maybe some months) ago relating to data corruption on USB disk IO on a SheevaPlug (same kirkwood chip). I wasn't able to recreate it then with a quick minimal effort. I need to put better effort into it soon, I think. > I hacked a bit on the gpio/led driver to make the LED work with gpioled, I'll > post a patch to the mailing list when it's cleaned up if that's ok. By all means. That might even be something I can use; my DreamPlugs have LEDs, and the green one is crazy-bright, I'd love to turn it off. Either way, I can get it committed for you. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 18:47:38 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 349C6284; Fri, 3 Jan 2014 18:47:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EEDCD1795; Fri, 3 Jan 2014 18:47:37 +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 s03IlWCe018356; Fri, 3 Jan 2014 13:47:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s03IlWM4018355; Fri, 3 Jan 2014 18:47:32 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 3 Jan 2014 18:47:32 GMT Message-Id: <201401031847.s03IlWM4018355@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 18:47:38 -0000 TB --- 2014-01-03 15:40:18 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-03 15:40:18 - 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 --- 2014-01-03 15:40:18 - starting HEAD tinderbox run for arm/arm TB --- 2014-01-03 15:40:18 - cleaning the object tree TB --- 2014-01-03 15:43:01 - /usr/local/bin/svn stat /src TB --- 2014-01-03 15:43:05 - At svn revision 260229 TB --- 2014-01-03 15:43:06 - building world TB --- 2014-01-03 15:43:06 - CROSS_BUILD_TESTING=YES TB --- 2014-01-03 15:43:06 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-03 15:43:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-03 15:43:06 - SRCCONF=/dev/null TB --- 2014-01-03 15:43:06 - TARGET=arm TB --- 2014-01-03 15:43:06 - TARGET_ARCH=arm TB --- 2014-01-03 15:43:06 - TZ=UTC TB --- 2014-01-03 15:43:06 - __MAKE_CONF=/dev/null TB --- 2014-01-03 15:43:06 - cd /src TB --- 2014-01-03 15:43:06 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Jan 3 15:43:12 UTC 2014 >>> 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 Fri Jan 3 18:46:55 UTC 2014 TB --- 2014-01-03 18:46:55 - generating LINT kernel config TB --- 2014-01-03 18:46:55 - cd /src/sys/arm/conf TB --- 2014-01-03 18:46:55 - /usr/bin/make -B LINT TB --- 2014-01-03 18:46:55 - cd /src/sys/arm/conf TB --- 2014-01-03 18:46:55 - /usr/sbin/config -m LINT TB --- 2014-01-03 18:46:55 - building LINT kernel TB --- 2014-01-03 18:46:55 - CROSS_BUILD_TESTING=YES TB --- 2014-01-03 18:46:55 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-03 18:46:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-03 18:46:55 - SRCCONF=/dev/null TB --- 2014-01-03 18:46:55 - TARGET=arm TB --- 2014-01-03 18:46:55 - TARGET_ARCH=arm TB --- 2014-01-03 18:46:55 - TZ=UTC TB --- 2014-01-03 18:46:55 - __MAKE_CONF=/dev/null TB --- 2014-01-03 18:46:55 - cd /src TB --- 2014-01-03 18:46:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jan 3 18:46:55 UTC 2014 >>> 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 [...] machine -> /src/sys/arm/include cc -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -ffreestanding /src/sys/arm/arm/genassym.c In file included from /src/sys/arm/arm/genassym.c:48: In file included from ./machine/intr.h:71: /src/sys/sys/bus.h:585:10: fatal error: 'device_if.h' file not found #include "device_if.h" ^ 1 error generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-01-03 18:47:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-03 18:47:32 - ERROR: failed to build LINT kernel TB --- 2014-01-03 18:47:32 - 8693.23 user 1638.08 system 11233.36 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 19:12:37 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FFCDB78; Fri, 3 Jan 2014 19:12:37 +0000 (UTC) Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F16C719D4; Fri, 3 Jan 2014 19:12:36 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MYU000009MGTM00@smtpauth3.wiscmail.wisc.edu>; Fri, 03 Jan 2014 13:12:35 -0600 (CST) X-Spam-PmxInfo: Server=avs-3, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.3.190314, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (pool-72-66-107-173.washdc.fios.verizon.net [72.66.107.173]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MYU00G5KAOSDJ20@smtpauth3.wiscmail.wisc.edu>; Fri, 03 Jan 2014 13:12:30 -0600 (CST) Message-id: <52C70B9B.9090205@freebsd.org> Date: Fri, 03 Jan 2014 14:12:27 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: Markus Pfeiffer , Ian Lepore Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) References: <20131231211054.GA90299@moore.morphism.de> <1388770603.1158.273.camel@revolution.hippie.lan> <20140103175914.GC98342@moore.morphism.de> In-reply-to: <20140103175914.GC98342@moore.morphism.de> X-Enigmail-Version: 1.6 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 19:12:37 -0000 On 01/03/14 12:59, Markus Pfeiffer wrote: > Hi Ian, > > On Fri, Jan 03, 2014 at 10:36:43AM -0700, Ian Lepore wrote: >> On Tue, 2013-12-31 at 21:10 +0000, Markus Pfeiffer wrote: >>> Hi all, >>> >>> I managed "fixing" it by editing the dockstar.dts file and putting for ranges: >>> >>> ranges = <0x0 0x2f 0xf9300000 0x00100000> >>> >>> Now I just have to figure out why this "fixes" it, and what damage that patch >>> does. >>> I also have some pathces for the LED on the dockstar which will tip up in my >>> github soon. >>> >>> Cheers, >>> markus >> After looking at the marvell code and docs, and some info I found about >> the dockstar at OpenWRT.org, I think the attached patch is the right fix >> for a dockstar (it maps the nand flash, and removes mappings for NOR >> flash and an LED; the dockstar doesn't seem to have NOR flash, and the >> LED thing seems to be out of place). >> > Can I find information anywhere as to what this ranges command actually means? > I was assuming it has something to do with memory mappings, but I didn't find > any info as to what in particular the 0x2f _means_. > > The ranges field, as per IEEE 1275 (page 175), provides a mapping from addresses in a child address space to the parent. It is a set of tuples of (child base address, parent base address, size), with the field widths being (#address-cells on this node [2], #address-cells of parent bus [1], #size-cells on this node [1]). This mapping table is used for resource allocation of children, to map bus-local requests for addresses to addresses on the parent bus (in this case, physical memory addresses). In this case, the following: ranges = <0x0 0x2f 0xf9300000 0x00100000> means that addresses 0x2f-0x0010002f in "localbus" should map linearly to physical addresses 0xf9300000-0xf9310000. This is used for drivers on the attached sub-bus so that their resources (in the "reg" properties, or in "ranges" if there are further sub-buses) can be specified in bus-local address units. The kernel code probably misinterprets it badly if changing this affects anything, which in turn implies that our kernel code is horribly bug-riddled. Note also that this replacement is not equivalent to the old mappings, since it shifts all the mappings downward by 0x20 bytes. -Nathan From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 19:42:51 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AC2FC2A; Fri, 3 Jan 2014 19:42:51 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0B16B1D8F; Fri, 3 Jan 2014 19:42:50 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VzAdt-000NA5-C8; Fri, 03 Jan 2014 19:42:49 +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 s03JgjHS024247; Fri, 3 Jan 2014 12:42:45 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX182TfNAcyS8FJx5fcXPMdFA Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) From: Ian Lepore To: Nathan Whitehorn In-Reply-To: <52C70B9B.9090205@freebsd.org> References: <20131231211054.GA90299@moore.morphism.de> <1388770603.1158.273.camel@revolution.hippie.lan> <20140103175914.GC98342@moore.morphism.de> <52C70B9B.9090205@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Fri, 03 Jan 2014 12:42:45 -0700 Message-ID: <1388778165.1158.302.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, Markus Pfeiffer X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 19:42:51 -0000 On Fri, 2014-01-03 at 14:12 -0500, Nathan Whitehorn wrote: > On 01/03/14 12:59, Markus Pfeiffer wrote: > > Hi Ian, > > > > On Fri, Jan 03, 2014 at 10:36:43AM -0700, Ian Lepore wrote: > >> On Tue, 2013-12-31 at 21:10 +0000, Markus Pfeiffer wrote: > >>> Hi all, > >>> > >>> I managed "fixing" it by editing the dockstar.dts file and putting for ranges: > >>> > >>> ranges = <0x0 0x2f 0xf9300000 0x00100000> > >>> > >>> Now I just have to figure out why this "fixes" it, and what damage that patch > >>> does. > >>> I also have some pathces for the LED on the dockstar which will tip up in my > >>> github soon. > >>> > >>> Cheers, > >>> markus > >> After looking at the marvell code and docs, and some info I found about > >> the dockstar at OpenWRT.org, I think the attached patch is the right fix > >> for a dockstar (it maps the nand flash, and removes mappings for NOR > >> flash and an LED; the dockstar doesn't seem to have NOR flash, and the > >> LED thing seems to be out of place). > >> > > Can I find information anywhere as to what this ranges command actually means? > > I was assuming it has something to do with memory mappings, but I didn't find > > any info as to what in particular the 0x2f _means_. > > > > > > The ranges field, as per IEEE 1275 (page 175), provides a mapping from > addresses in a child address space to the parent. It is a set of tuples > of (child base address, parent base address, size), with the field > widths being (#address-cells on this node [2], #address-cells of parent > bus [1], #size-cells on this node [1]). This mapping table is used for > resource allocation of children, to map bus-local requests for addresses > to addresses on the parent bus (in this case, physical memory > addresses). In this case, the following: > > ranges = <0x0 0x2f 0xf9300000 0x00100000> > > means that addresses 0x2f-0x0010002f in "localbus" should map linearly to physical addresses 0xf9300000-0xf9310000. This is used for drivers on the attached sub-bus so that their resources (in the "reg" properties, or in "ranges" if there are further sub-buses) can be specified in bus-local address units. The kernel code probably misinterprets it badly if changing this affects anything, which in turn implies that our kernel code is horribly bug-riddled. > > Note also that this replacement is not equivalent to the old mappings, since it shifts all the mappings downward by 0x20 bytes. > -Nathan So now we're back to the usual question... do we adhere to published or defacto standards? The defacto standards for arm dts files are basically "whatever linux does is right by definition" (::sigh::), and what we've got in the marvell dts files right now is basically similar to what linux uses (I think linux has evolved a bit since our dts files were created; they were probably compatible at some point). Here's what linux is doing these days. I notice they've moved the mapping info from "mrvl,lbc" to "marvell,kirkwood-mbus", "simple-bus"; https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood.dtsi -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 19:48:48 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0A909DF5; Fri, 3 Jan 2014 19:48:48 +0000 (UTC) Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C9CB61DCC; Fri, 3 Jan 2014 19:48:47 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MYU00A00CCX5A00@smtpauth3.wiscmail.wisc.edu>; Fri, 03 Jan 2014 13:48:46 -0600 (CST) X-Spam-PmxInfo: Server=avs-3, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.3.193914, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (pool-72-66-107-173.washdc.fios.verizon.net [72.66.107.173]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MYU008BVCD8S300@smtpauth3.wiscmail.wisc.edu>; Fri, 03 Jan 2014 13:48:45 -0600 (CST) Message-id: <52C7141C.2040801@freebsd.org> Date: Fri, 03 Jan 2014 14:48:44 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: Ian Lepore Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) References: <20131231211054.GA90299@moore.morphism.de> <1388770603.1158.273.camel@revolution.hippie.lan> <20140103175914.GC98342@moore.morphism.de> <52C70B9B.9090205@freebsd.org> <1388778165.1158.302.camel@revolution.hippie.lan> In-reply-to: <1388778165.1158.302.camel@revolution.hippie.lan> X-Enigmail-Version: 1.6 Cc: freebsd-arm@FreeBSD.org, Markus Pfeiffer X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 19:48:48 -0000 On 01/03/14 14:42, Ian Lepore wrote: > On Fri, 2014-01-03 at 14:12 -0500, Nathan Whitehorn wrote: >> On 01/03/14 12:59, Markus Pfeiffer wrote: >>> Hi Ian, >>> >>> On Fri, Jan 03, 2014 at 10:36:43AM -0700, Ian Lepore wrote: >>>> On Tue, 2013-12-31 at 21:10 +0000, Markus Pfeiffer wrote: >>>>> Hi all, >>>>> >>>>> I managed "fixing" it by editing the dockstar.dts file and putting for ranges: >>>>> >>>>> ranges = <0x0 0x2f 0xf9300000 0x00100000> >>>>> >>>>> Now I just have to figure out why this "fixes" it, and what damage that patch >>>>> does. >>>>> I also have some pathces for the LED on the dockstar which will tip up in my >>>>> github soon. >>>>> >>>>> Cheers, >>>>> markus >>>> After looking at the marvell code and docs, and some info I found about >>>> the dockstar at OpenWRT.org, I think the attached patch is the right fix >>>> for a dockstar (it maps the nand flash, and removes mappings for NOR >>>> flash and an LED; the dockstar doesn't seem to have NOR flash, and the >>>> LED thing seems to be out of place). >>>> >>> Can I find information anywhere as to what this ranges command actually means? >>> I was assuming it has something to do with memory mappings, but I didn't find >>> any info as to what in particular the 0x2f _means_. >>> >>> >> The ranges field, as per IEEE 1275 (page 175), provides a mapping from >> addresses in a child address space to the parent. It is a set of tuples >> of (child base address, parent base address, size), with the field >> widths being (#address-cells on this node [2], #address-cells of parent >> bus [1], #size-cells on this node [1]). This mapping table is used for >> resource allocation of children, to map bus-local requests for addresses >> to addresses on the parent bus (in this case, physical memory >> addresses). In this case, the following: >> >> ranges = <0x0 0x2f 0xf9300000 0x00100000> >> >> means that addresses 0x2f-0x0010002f in "localbus" should map linearly to physical addresses 0xf9300000-0xf9310000. This is used for drivers on the attached sub-bus so that their resources (in the "reg" properties, or in "ranges" if there are further sub-buses) can be specified in bus-local address units. The kernel code probably misinterprets it badly if changing this affects anything, which in turn implies that our kernel code is horribly bug-riddled. >> >> Note also that this replacement is not equivalent to the old mappings, since it shifts all the mappings downward by 0x20 bytes. >> -Nathan > So now we're back to the usual question... do we adhere to published or > defacto standards? The defacto standards for arm dts files are > basically "whatever linux does is right by definition" (::sigh::), and > what we've got in the marvell dts files right now is basically similar > to what linux uses (I think linux has evolved a bit since our dts files > were created; they were probably compatible at some point). > > Here's what linux is doing these days. I notice they've moved the > mapping info from "mrvl,lbc" to "marvell,kirkwood-mbus", "simple-bus"; > > https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood.dtsi > > -- Ian > > > I don't see any particular way in which these files violate the standards. Did I miss something? In this case, so long as a 1:1 linear mapping can be made, it's perfectly alright for "child bus addresses" to be basically arbitrary codes, as here. IEEE 1275 PCI does this, for example, with 96-bit "child address" ranges that are a combination of the bus, slot, and function for the card along with actual 64-bit memory locations. In general, Linux's device tree support seems to be much more standards-compliant than ours. It's FreeBSD that seems to take the more fragile and ad-hoc approach, which is what usually creates this "I have to go patch my DTS now" problem. -Nathan From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 20:02:55 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35CF621A; Fri, 3 Jan 2014 20:02:55 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E814A1EE0; Fri, 3 Jan 2014 20:02:54 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VzAxJ-000FiG-V9; Fri, 03 Jan 2014 20:02:54 +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 s03K2o4J024270; Fri, 3 Jan 2014 13:02:50 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/HLsZa8ssTLPR3GaEy79XA Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) From: Ian Lepore To: Nathan Whitehorn In-Reply-To: <52C7141C.2040801@freebsd.org> References: <20131231211054.GA90299@moore.morphism.de> <1388770603.1158.273.camel@revolution.hippie.lan> <20140103175914.GC98342@moore.morphism.de> <52C70B9B.9090205@freebsd.org> <1388778165.1158.302.camel@revolution.hippie.lan> <52C7141C.2040801@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Fri, 03 Jan 2014 13:02:49 -0700 Message-ID: <1388779369.1158.303.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, Markus Pfeiffer X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 20:02:55 -0000 On Fri, 2014-01-03 at 14:48 -0500, Nathan Whitehorn wrote: > On 01/03/14 14:42, Ian Lepore wrote: > > On Fri, 2014-01-03 at 14:12 -0500, Nathan Whitehorn wrote: > >> On 01/03/14 12:59, Markus Pfeiffer wrote: > >>> Hi Ian, > >>> > >>> On Fri, Jan 03, 2014 at 10:36:43AM -0700, Ian Lepore wrote: > >>>> On Tue, 2013-12-31 at 21:10 +0000, Markus Pfeiffer wrote: > >>>>> Hi all, > >>>>> > >>>>> I managed "fixing" it by editing the dockstar.dts file and putting for ranges: > >>>>> > >>>>> ranges = <0x0 0x2f 0xf9300000 0x00100000> > >>>>> > >>>>> Now I just have to figure out why this "fixes" it, and what damage that patch > >>>>> does. > >>>>> I also have some pathces for the LED on the dockstar which will tip up in my > >>>>> github soon. > >>>>> > >>>>> Cheers, > >>>>> markus > >>>> After looking at the marvell code and docs, and some info I found about > >>>> the dockstar at OpenWRT.org, I think the attached patch is the right fix > >>>> for a dockstar (it maps the nand flash, and removes mappings for NOR > >>>> flash and an LED; the dockstar doesn't seem to have NOR flash, and the > >>>> LED thing seems to be out of place). > >>>> > >>> Can I find information anywhere as to what this ranges command actually means? > >>> I was assuming it has something to do with memory mappings, but I didn't find > >>> any info as to what in particular the 0x2f _means_. > >>> > >>> > >> The ranges field, as per IEEE 1275 (page 175), provides a mapping from > >> addresses in a child address space to the parent. It is a set of tuples > >> of (child base address, parent base address, size), with the field > >> widths being (#address-cells on this node [2], #address-cells of parent > >> bus [1], #size-cells on this node [1]). This mapping table is used for > >> resource allocation of children, to map bus-local requests for addresses > >> to addresses on the parent bus (in this case, physical memory > >> addresses). In this case, the following: > >> > >> ranges = <0x0 0x2f 0xf9300000 0x00100000> > >> > >> means that addresses 0x2f-0x0010002f in "localbus" should map linearly to physical addresses 0xf9300000-0xf9310000. This is used for drivers on the attached sub-bus so that their resources (in the "reg" properties, or in "ranges" if there are further sub-buses) can be specified in bus-local address units. The kernel code probably misinterprets it badly if changing this affects anything, which in turn implies that our kernel code is horribly bug-riddled. > >> > >> Note also that this replacement is not equivalent to the old mappings, since it shifts all the mappings downward by 0x20 bytes. > >> -Nathan > > So now we're back to the usual question... do we adhere to published or > > defacto standards? The defacto standards for arm dts files are > > basically "whatever linux does is right by definition" (::sigh::), and > > what we've got in the marvell dts files right now is basically similar > > to what linux uses (I think linux has evolved a bit since our dts files > > were created; they were probably compatible at some point). > > > > Here's what linux is doing these days. I notice they've moved the > > mapping info from "mrvl,lbc" to "marvell,kirkwood-mbus", "simple-bus"; > > > > https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood.dtsi > > > > -- Ian > > > > > > > > I don't see any particular way in which these files violate the > standards. Did I miss something? In this case, so long as a 1:1 linear > mapping can be made, it's perfectly alright for "child bus addresses" to > be basically arbitrary codes, as here. IEEE 1275 PCI does this, for > example, with 96-bit "child address" ranges that are a combination of > the bus, slot, and function for the card along with actual 64-bit memory > locations. In general, Linux's device tree support seems to be much more > standards-compliant than ours. It's FreeBSD that seems to take the more > fragile and ad-hoc approach, which is what usually creates this "I have > to go patch my DTS now" problem. > -Nathan Well then I'm confused. You described a 3-tuple, and our dts and linux use a 4-tuple. I actually don't know what the first number in ours is even there for, it doesn't seem to be used in the code. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Jan 3 20:05:26 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C04A3D3; Fri, 3 Jan 2014 20:05:26 +0000 (UTC) Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DA0BB1F03; Fri, 3 Jan 2014 20:05:25 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MYU00A00CKKV000@smtpauth3.wiscmail.wisc.edu>; Fri, 03 Jan 2014 14:05:24 -0600 (CST) X-Spam-PmxInfo: Server=avs-3, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.3.195714, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (pool-72-66-107-173.washdc.fios.verizon.net [72.66.107.173]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MYU008TLD4YS300@smtpauth3.wiscmail.wisc.edu>; Fri, 03 Jan 2014 14:05:23 -0600 (CST) Message-id: <52C71802.9040304@freebsd.org> Date: Fri, 03 Jan 2014 15:05:22 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: Ian Lepore Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) References: <20131231211054.GA90299@moore.morphism.de> <1388770603.1158.273.camel@revolution.hippie.lan> <20140103175914.GC98342@moore.morphism.de> <52C70B9B.9090205@freebsd.org> <1388778165.1158.302.camel@revolution.hippie.lan> <52C7141C.2040801@freebsd.org> <1388779369.1158.303.camel@revolution.hippie.lan> In-reply-to: <1388779369.1158.303.camel@revolution.hippie.lan> X-Enigmail-Version: 1.6 Cc: freebsd-arm@FreeBSD.org, Markus Pfeiffer X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 20:05:26 -0000 On 01/03/14 15:02, Ian Lepore wrote: > On Fri, 2014-01-03 at 14:48 -0500, Nathan Whitehorn wrote: >> On 01/03/14 14:42, Ian Lepore wrote: >>> On Fri, 2014-01-03 at 14:12 -0500, Nathan Whitehorn wrote: >>>> On 01/03/14 12:59, Markus Pfeiffer wrote: >>>>> Hi Ian, >>>>> >>>>> On Fri, Jan 03, 2014 at 10:36:43AM -0700, Ian Lepore wrote: >>>>>> On Tue, 2013-12-31 at 21:10 +0000, Markus Pfeiffer wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I managed "fixing" it by editing the dockstar.dts file and putting for ranges: >>>>>>> >>>>>>> ranges = <0x0 0x2f 0xf9300000 0x00100000> >>>>>>> >>>>>>> Now I just have to figure out why this "fixes" it, and what damage that patch >>>>>>> does. >>>>>>> I also have some pathces for the LED on the dockstar which will tip up in my >>>>>>> github soon. >>>>>>> >>>>>>> Cheers, >>>>>>> markus >>>>>> After looking at the marvell code and docs, and some info I found about >>>>>> the dockstar at OpenWRT.org, I think the attached patch is the right fix >>>>>> for a dockstar (it maps the nand flash, and removes mappings for NOR >>>>>> flash and an LED; the dockstar doesn't seem to have NOR flash, and the >>>>>> LED thing seems to be out of place). >>>>>> >>>>> Can I find information anywhere as to what this ranges command actually means? >>>>> I was assuming it has something to do with memory mappings, but I didn't find >>>>> any info as to what in particular the 0x2f _means_. >>>>> >>>>> >>>> The ranges field, as per IEEE 1275 (page 175), provides a mapping from >>>> addresses in a child address space to the parent. It is a set of tuples >>>> of (child base address, parent base address, size), with the field >>>> widths being (#address-cells on this node [2], #address-cells of parent >>>> bus [1], #size-cells on this node [1]). This mapping table is used for >>>> resource allocation of children, to map bus-local requests for addresses >>>> to addresses on the parent bus (in this case, physical memory >>>> addresses). In this case, the following: >>>> >>>> ranges = <0x0 0x2f 0xf9300000 0x00100000> >>>> >>>> means that addresses 0x2f-0x0010002f in "localbus" should map linearly to physical addresses 0xf9300000-0xf9310000. This is used for drivers on the attached sub-bus so that their resources (in the "reg" properties, or in "ranges" if there are further sub-buses) can be specified in bus-local address units. The kernel code probably misinterprets it badly if changing this affects anything, which in turn implies that our kernel code is horribly bug-riddled. >>>> >>>> Note also that this replacement is not equivalent to the old mappings, since it shifts all the mappings downward by 0x20 bytes. >>>> -Nathan >>> So now we're back to the usual question... do we adhere to published or >>> defacto standards? The defacto standards for arm dts files are >>> basically "whatever linux does is right by definition" (::sigh::), and >>> what we've got in the marvell dts files right now is basically similar >>> to what linux uses (I think linux has evolved a bit since our dts files >>> were created; they were probably compatible at some point). >>> >>> Here's what linux is doing these days. I notice they've moved the >>> mapping info from "mrvl,lbc" to "marvell,kirkwood-mbus", "simple-bus"; >>> >>> https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood.dtsi >>> >>> -- Ian >>> >>> >>> >> I don't see any particular way in which these files violate the >> standards. Did I miss something? In this case, so long as a 1:1 linear >> mapping can be made, it's perfectly alright for "child bus addresses" to >> be basically arbitrary codes, as here. IEEE 1275 PCI does this, for >> example, with 96-bit "child address" ranges that are a combination of >> the bus, slot, and function for the card along with actual 64-bit memory >> locations. In general, Linux's device tree support seems to be much more >> standards-compliant than ours. It's FreeBSD that seems to take the more >> fragile and ad-hoc approach, which is what usually creates this "I have >> to go patch my DTS now" problem. >> -Nathan > Well then I'm confused. You described a 3-tuple, and our dts and linux > use a 4-tuple. I actually don't know what the first number in ours is > even there for, it doesn't seem to be used in the code. > > -- Ian > > It's a 3-tuple, but each element is not necessarily one cell. The element width is described by the #address-cells and #size-cells properties. For localbus, child addresses are defined to be two cells wide (64 bits) by the localbus node's #address-cells property. The parent's addresses are one cell (parent node #address-cells), as is the size property (localhost #size-cells). So a single 3-element table entry is 2+1+1=4 cells wide. -Nathan From owner-freebsd-arm@FreeBSD.ORG Sat Jan 4 05:47:12 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA4E82D0; Sat, 4 Jan 2014 05:47:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F6B5149B; Sat, 4 Jan 2014 05:47:12 +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 s045lBjq011892; Sat, 4 Jan 2014 00:47:11 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s045lBta011891; Sat, 4 Jan 2014 05:47:11 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 4 Jan 2014 05:47:11 GMT Message-Id: <201401040547.s045lBta011891@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 05:47:12 -0000 TB --- 2014-01-04 02:40:18 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-04 02:40:18 - 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 --- 2014-01-04 02:40:18 - starting HEAD tinderbox run for arm/arm TB --- 2014-01-04 02:40:18 - cleaning the object tree TB --- 2014-01-04 02:43:15 - /usr/local/bin/svn stat /src TB --- 2014-01-04 02:43:19 - At svn revision 260251 TB --- 2014-01-04 02:43:20 - building world TB --- 2014-01-04 02:43:20 - CROSS_BUILD_TESTING=YES TB --- 2014-01-04 02:43:20 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-04 02:43:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-04 02:43:20 - SRCCONF=/dev/null TB --- 2014-01-04 02:43:20 - TARGET=arm TB --- 2014-01-04 02:43:20 - TARGET_ARCH=arm TB --- 2014-01-04 02:43:20 - TZ=UTC TB --- 2014-01-04 02:43:20 - __MAKE_CONF=/dev/null TB --- 2014-01-04 02:43:20 - cd /src TB --- 2014-01-04 02:43:20 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Jan 4 02:43:27 UTC 2014 >>> 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 Sat Jan 4 05:46:38 UTC 2014 TB --- 2014-01-04 05:46:38 - generating LINT kernel config TB --- 2014-01-04 05:46:38 - cd /src/sys/arm/conf TB --- 2014-01-04 05:46:38 - /usr/bin/make -B LINT TB --- 2014-01-04 05:46:39 - cd /src/sys/arm/conf TB --- 2014-01-04 05:46:39 - /usr/sbin/config -m LINT TB --- 2014-01-04 05:46:39 - building LINT kernel TB --- 2014-01-04 05:46:39 - CROSS_BUILD_TESTING=YES TB --- 2014-01-04 05:46:39 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-04 05:46:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-04 05:46:39 - SRCCONF=/dev/null TB --- 2014-01-04 05:46:39 - TARGET=arm TB --- 2014-01-04 05:46:39 - TARGET_ARCH=arm TB --- 2014-01-04 05:46:39 - TZ=UTC TB --- 2014-01-04 05:46:39 - __MAKE_CONF=/dev/null TB --- 2014-01-04 05:46:39 - cd /src TB --- 2014-01-04 05:46:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 4 05:46:39 UTC 2014 >>> 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 [...] machine -> /src/sys/arm/include cc -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -ffreestanding /src/sys/arm/arm/genassym.c In file included from /src/sys/arm/arm/genassym.c:48: In file included from ./machine/intr.h:71: /src/sys/sys/bus.h:585:10: fatal error: 'device_if.h' file not found #include "device_if.h" ^ 1 error generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-01-04 05:47:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-04 05:47:11 - ERROR: failed to build LINT kernel TB --- 2014-01-04 05:47:11 - 8695.18 user 1622.10 system 11212.85 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Jan 4 13:06:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73E36BFE; Sat, 4 Jan 2014 13:06:03 +0000 (UTC) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3338E1069; Sat, 4 Jan 2014 13:06:03 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id uy5so16646478obc.40 for ; Sat, 04 Jan 2014 05:06:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sbl4FXQ3qDnbB4XkgGp1rgq2KMw1ystdVO9eawOfOYk=; b=pPgvzReqS3kV9pcSekWiBaftACpKOnBpRSLwpgxwH4/qWQueOF0iyHVa7iW0YPUtUa lyNA2AVzlAFa5L2Por3sM4BN8NH63z6nut1TOmou8lYH0fWyCU1cxfUcr81Lj4n/iNza tFzn7IVKQkiCqxZICKJKHjy55VLUaEZWdo1bng2Zy1rtpzY9AJdJHxolvUwrk0a2MVTp UEkJOwO/RRzC3VUgSxXKoR2XlTuhUDuxTnRt0H20ATMqwloPlkjjUqUe9DcOp+Xzift2 bjAgS4Wm6dOviOcJ2O0q57QY1pM/hcjWGT8xMsaVZtttbHi+vnT9CY51A71XRgav1lN5 52lQ== MIME-Version: 1.0 X-Received: by 10.60.161.229 with SMTP id xv5mr44024492oeb.20.1388840762437; Sat, 04 Jan 2014 05:06:02 -0800 (PST) Received: by 10.76.20.82 with HTTP; Sat, 4 Jan 2014 05:06:02 -0800 (PST) Date: Sat, 4 Jan 2014 15:06:02 +0200 Message-ID: Subject: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access From: Guy Yur To: freebsd-net@freebsd.org, freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 13:06:03 -0000 Hi, I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. The "pfctl -s state" command is crashing when trying to print the second entry. struct pfsync_state has a size that is not divisiable by 4 or 8 leading to the second entry in the returned state array not being aligned and pfctl core dumps on Bus error when trying to access a uint32_t field. (gdb) bt #0 print_host (addr=0x2085a11a, port=7660, af=2 '\002', opts=1024) at /usr/src/sbin/pfctl/pf_print_state.c:178 #1 0x00021c4c in print_state (s=0x2085a0f2, opts=1024) at /usr/src/sbin/pfctl/pf_print_state.c:236 #2 0x0000c664 in pfctl_show_states (dev=, iface=0x0, opts=1024) at /usr/src/sbin/pfctl/pfctl.c:1095 sizeof(struct pfsync_state_key) is 36 sizeof(struct pfsync_state_peer) is 32 sizeof(struct pf_addr) is 16 sizeof(struct pfsync_state) is 242 Removing the __spare[2] field will allow the struct to be aligned on 8 bytes for the u_int64_t id field and also cover the uint32_t fields alignment but this will break KBI. I am currently using an inefficient workaround in pfctl_show_states that memcpy each entry to a struct pfsync_state on the stack ensuring each call to print_state receives an aligned struct. 10.0-RC1 World and kernel were compiled in a VirtualBox VM running 9.2-RELEASE-p2 i386. clang and ARM_EABI used as the default make options. Regards, Guy From owner-freebsd-arm@FreeBSD.ORG Sat Jan 4 16:38:20 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBF2BF1D; Sat, 4 Jan 2014 16:38:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A1A731E35; Sat, 4 Jan 2014 16:38:19 +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 s04GcIP7095056; Sat, 4 Jan 2014 11:38:18 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s04GcIAY095053; Sat, 4 Jan 2014 16:38:18 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 4 Jan 2014 16:38:18 GMT Message-Id: <201401041638.s04GcIAY095053@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 16:38:20 -0000 TB --- 2014-01-04 13:30:18 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-04 13:30:18 - 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 --- 2014-01-04 13:30:18 - starting HEAD tinderbox run for arm/arm TB --- 2014-01-04 13:30:18 - cleaning the object tree TB --- 2014-01-04 13:33:26 - /usr/local/bin/svn stat /src TB --- 2014-01-04 13:33:29 - At svn revision 260257 TB --- 2014-01-04 13:33:30 - building world TB --- 2014-01-04 13:33:30 - CROSS_BUILD_TESTING=YES TB --- 2014-01-04 13:33:30 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-04 13:33:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-04 13:33:30 - SRCCONF=/dev/null TB --- 2014-01-04 13:33:30 - TARGET=arm TB --- 2014-01-04 13:33:30 - TARGET_ARCH=arm TB --- 2014-01-04 13:33:30 - TZ=UTC TB --- 2014-01-04 13:33:30 - __MAKE_CONF=/dev/null TB --- 2014-01-04 13:33:30 - cd /src TB --- 2014-01-04 13:33:30 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Jan 4 13:33:37 UTC 2014 >>> 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 Sat Jan 4 16:37:47 UTC 2014 TB --- 2014-01-04 16:37:47 - generating LINT kernel config TB --- 2014-01-04 16:37:47 - cd /src/sys/arm/conf TB --- 2014-01-04 16:37:47 - /usr/bin/make -B LINT TB --- 2014-01-04 16:37:47 - cd /src/sys/arm/conf TB --- 2014-01-04 16:37:47 - /usr/sbin/config -m LINT TB --- 2014-01-04 16:37:47 - building LINT kernel TB --- 2014-01-04 16:37:47 - CROSS_BUILD_TESTING=YES TB --- 2014-01-04 16:37:47 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-04 16:37:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-04 16:37:47 - SRCCONF=/dev/null TB --- 2014-01-04 16:37:47 - TARGET=arm TB --- 2014-01-04 16:37:47 - TARGET_ARCH=arm TB --- 2014-01-04 16:37:47 - TZ=UTC TB --- 2014-01-04 16:37:47 - __MAKE_CONF=/dev/null TB --- 2014-01-04 16:37:47 - cd /src TB --- 2014-01-04 16:37:47 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 4 16:37:48 UTC 2014 >>> 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 [...] machine -> /src/sys/arm/include cc -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -ffreestanding /src/sys/arm/arm/genassym.c In file included from /src/sys/arm/arm/genassym.c:48: In file included from ./machine/intr.h:71: /src/sys/sys/bus.h:585:10: fatal error: 'device_if.h' file not found #include "device_if.h" ^ 1 error generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-01-04 16:38:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-04 16:38:18 - ERROR: failed to build LINT kernel TB --- 2014-01-04 16:38:18 - 8693.80 user 1650.76 system 11279.98 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Jan 4 16:52:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E19384D4 for ; Sat, 4 Jan 2014 16:52:36 +0000 (UTC) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A96E81F56 for ; Sat, 4 Jan 2014 16:52:36 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id e14so17263366iej.0 for ; Sat, 04 Jan 2014 08:52:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Nhzav3bT7kO+Y+zllB/G5+kL3WTDX86fAmsZ4By94Sc=; b=KQA00lTWgqXffN4vRBBkOAhRDPU5TDDt6luP/j2JtNwmlsojv3CEKfDtiLvObBn8pn 2QPyMqzkUEITRiWmWTo/1S5PGY9LkqPnqswrwJP/YGuTXQAcfchMjtALX0K/+/lHIS3a KaQt97NQqtxu6XN9xgopbpynL3CXI/0fX8Kux0sV5aH9g6nYUNqje2leXWS9YXFCY2uY ajx2FjReW92+eVGu8lUv88s0ydGRfJ294tJI4H9rRESgkFA1r+1M/gJt8vRA2jDkJlKS FGDVFw2G7cuSBBc/dfT9QdAw+A3he/TRr42oQg9bzpCZLX5/93NxvYF2E6Hk9IGUOjw4 cH6g== X-Gm-Message-State: ALoCoQnxBf+fY63WkGIzzNIea8oevptxkf8ExrMPuU8QuwKW6umt26VbtsY2IHhI3hjdHYE4alVO X-Received: by 10.50.136.201 with SMTP id qc9mr9860121igb.11.1388854348952; Sat, 04 Jan 2014 08:52:28 -0800 (PST) Received: from [10.0.0.23] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id s4sm7149549ige.0.2014.01.04.08.52.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 Jan 2014 08:52:26 -0800 (PST) Sender: Warner Losh Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 4 Jan 2014 09:50:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Guy Yur X-Mailer: Apple Mail (2.1085) Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 16:52:37 -0000 I think this was changed in later RC versions. Warner On Jan 4, 2014, at 6:06 AM, Guy Yur wrote: > Hi, >=20 > I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. > The "pfctl -s state" command is crashing when trying to print the > second entry. >=20 > struct pfsync_state has a size that is not divisiable by 4 or 8 = leading to the > second entry in the returned state array not being aligned and pfctl > core dumps on Bus error when trying to access a uint32_t field. >=20 > (gdb) bt > #0 print_host (addr=3D0x2085a11a, port=3D7660, af=3D2 '\002', = opts=3D1024) at > /usr/src/sbin/pfctl/pf_print_state.c:178 > #1 0x00021c4c in print_state (s=3D0x2085a0f2, opts=3D1024) at > /usr/src/sbin/pfctl/pf_print_state.c:236 > #2 0x0000c664 in pfctl_show_states (dev=3D, > iface=3D0x0, opts=3D1024) at /usr/src/sbin/pfctl/pfctl.c:1095 >=20 > sizeof(struct pfsync_state_key) is 36 > sizeof(struct pfsync_state_peer) is 32 > sizeof(struct pf_addr) is 16 > sizeof(struct pfsync_state) is 242 >=20 > Removing the __spare[2] field will allow the struct to be aligned on 8 = bytes > for the u_int64_t id field and also cover the uint32_t fields = alignment > but this will break KBI. >=20 > I am currently using an inefficient workaround in pfctl_show_states > that memcpy each entry to a struct pfsync_state on the stack > ensuring each call to print_state receives an aligned struct. >=20 >=20 > 10.0-RC1 World and kernel were compiled in a VirtualBox VM running > 9.2-RELEASE-p2 i386. > clang and ARM_EABI used as the default make options. >=20 >=20 > Regards, > Guy > _______________________________________________ > 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" From owner-freebsd-arm@FreeBSD.ORG Sat Jan 4 19:52:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75BBFE40; Sat, 4 Jan 2014 19:52:12 +0000 (UTC) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 322491CC6; Sat, 4 Jan 2014 19:52:12 +0000 (UTC) Received: by mail-oa0-f45.google.com with SMTP id g12so1926379oah.18 for ; Sat, 04 Jan 2014 11:52:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=P+YoAydWULmrHNSiBA5rfifJoy9rFKlDcB2tFv/MQQE=; b=uOj/DMpiCJik7Ck/5QzeMABC4D5xlRAfU68tx/YCUhfZp6w55z7lXZb6jDnxz8+IXn 5Tw6o78isdK3CpSC43BzzkPdiEy7bb2gzCnDF1fux2YqowlO4C/DCHycYP8m5KdpoiLm VgQggoShzjYV8nEOHILMrb8v9pIZrqMrheXFR6egrG1Rt9OY/BX40wDkPbYVl/GnjVyI b67alroGoYN0huiJ8Vt+GQ6yMrSZ1YBj942b1hU74iioIziZqIpxCHJKQfUzmLgBe65p 4jAXy1RkxW9EC+/S5VGyJUFJdgENwb/bVAKyD7Aq3quRrCH+sZw7GINmxKPQoG4VmzJT KIRw== MIME-Version: 1.0 X-Received: by 10.60.54.168 with SMTP id k8mr1881834oep.56.1388865131471; Sat, 04 Jan 2014 11:52:11 -0800 (PST) Received: by 10.76.20.82 with HTTP; Sat, 4 Jan 2014 11:52:11 -0800 (PST) In-Reply-To: References: Date: Sat, 4 Jan 2014 21:52:11 +0200 Message-ID: Subject: Re: 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access From: Guy Yur To: freebsd-net@freebsd.org, freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 19:52:12 -0000 On Sat, Jan 4, 2014 at 6:50 PM, Warner Losh wrote: > I think this was changed in later RC versions. > > Warner > Do you mean r259308 in 10-STABLE? I compiled a new kernel with the change applied and still get SIGBUS on unaligned access. >From my reading of the ARM manual for Cortex-A it looks like setting CPU_CONTROL_AFLT_ENABLE to 1 means you want to get a trap on unaligned access. "1 = Strict alignment fault checking enabled." I see that dab_align delivers a SIGBUS on user-mode alignment fault. > On Jan 4, 2014, at 6:06 AM, Guy Yur wrote: > >> Hi, >> >> I am running 10.0-RC1 arm.armv6 on the BeagleBone Black. >> The "pfctl -s state" command is crashing when trying to print the >> second entry. >> >> struct pfsync_state has a size that is not divisiable by 4 or 8 leading to the >> second entry in the returned state array not being aligned and pfctl >> core dumps on Bus error when trying to access a uint32_t field. >> Regards, Guy From owner-freebsd-arm@FreeBSD.ORG Sat Jan 4 21:23:17 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF78040D; Sat, 4 Jan 2014 21:23:16 +0000 (UTC) Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B9CBE1254; Sat, 4 Jan 2014 21:23:16 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MYW00D00BB6PC00@smtpauth4.wiscmail.wisc.edu>; Sat, 04 Jan 2014 15:23:14 -0600 (CST) X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.4.211218, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (pool-72-66-107-173.washdc.fios.verizon.net [72.66.107.173]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MYW00DMJBEO4U20@smtpauth4.wiscmail.wisc.edu>; Sat, 04 Jan 2014 15:23:14 -0600 (CST) Message-id: <52C87BC0.2060304@freebsd.org> Date: Sat, 04 Jan 2014 16:23:12 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: Zbigniew Bodek , "freebsd-arm@freebsd.org" Subject: Re: RFC: ARM related fixes - GIC, cache line size, PCI FDT & AHCI References: <52AF3D06.2000004@semihalf.com> <52AF760A.2030500@freebsd.org> <52B0900B.7020905@freebsd.org> <52B2D0F3.50100@semihalf.com> In-reply-to: <52B2D0F3.50100@semihalf.com> X-Enigmail-Version: 1.6 Cc: br@freebsd.org, Olivier Houchard X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 21:23:17 -0000 On 12/19/13 05:56, Zbigniew Bodek wrote: > On 17.12.2013 18:55, Nathan Whitehorn wrote: >> On 12/16/13 15:52, Nathan Whitehorn wrote: >>> On 12/16/13 11:48, Zbigniew Bodek wrote: >>>> Hello Everyone. >>>> >>>> We would like to submit some new patches recently developed by Semihalf. >>>> >>>> You can find them here: >>>> http://people.freebsd.org/~zbb/Semihalf/12.2013/ >>>> >>>> Detailed description is available in the commit logs but in general: >>>> >>>> -- 0001-Resolve-cache-line-size-using-CP15.patch >>>> - use cache line size acquired in runtime >>>> >>>> -- 0002-GIC-polarity-and-level-support.patch >>>> - suport for setting trigger level and polarity in GIC >>>> >>>> -- 0003-Add-PCI-FDT-interrupt-trigger-polarity-parsing.patch >>>> - trigger and polarity parsing for PCI FDT interrupts >>>> >>>> -- 0004-Do-not-attach-to-bridges-in-AHCI-driver.patch >>>> -- 0005-Use-only-mapped-BIOs-on-ARM.patch >>>> - Two patches enabling the AHCI driver on ARM chips >>>> >>>> >>>> We will appreciate if you could post your comments and/or remarks by the >>>> end of this week when we plan to commit the changes. >>>> >>>> Best regards >>>> zbb >>>> _______________________________________________ >>>> 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" >>> Can you hold off on >>> 0003-Add-PCI-FDT-interrupt-trigger-polarity-parsing.patch for the time >>> being? I'm restructuring this code at the moment. >>> -Nathan >>> _______________________________________________ >>> 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" >> This is done now. I have not updated the ARM code, because I don't know >> how it is supposed to work, but you can take a look at r259513 to >> powerpc/ofw/ofw_pci.c to see how the new stuff works. It relies on some >> device (nexus, for example) implementing OFW_BUS_CONFIG_INTR(), which >> takes an IRQ and a sense code, but that seems to be wrapped up in a lot >> of ARM-specific stuff. >> >> If you like, I can just write a piece of bridge code, but I don't want >> to interfere with in-flight things on your end. > > Hello Nathan. > > We will wait for your refactoring to finish so no worries. We can skip > this patch for now, the more that there were some comments to this one. > > Thanks and best regards > zbb > My restructuring is now done. I suspect ARM may want something like PowerPC's pic_if.m in the future, but the interfaces are now in place (ofw_bus_map_intr(), ofw_bus_config_intr()) to make that transition fairly painless later on. -Nathan From owner-freebsd-arm@FreeBSD.ORG Sat Jan 4 21:28:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC2C087D; Sat, 4 Jan 2014 21:28:34 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 13A66127A; Sat, 4 Jan 2014 21:28:33 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id x13so14686188wgg.7 for ; Sat, 04 Jan 2014 13:28:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=x9mzlOeVXXssQjThyFil+tZK+DLsKBxsK/jN4u4vCP0=; b=usmiPzmwMkRydLAX2ANlaG992ZL4bol9k5ho/lNVbTud2FaA7F8OuMUWz53EfxoF0e j4yQD2KpDBWuiMjzzHD/okqXosYFXzIO4TmvzTAaOgCs9i84zWUBMdOhGeNzX1WSBnS0 eGVUMz9tjsIMTG7tLj/KARFHE95ooTF+0A9Umuz0T0h7S3IHlQA5tq8zgUEwVD7j0HB5 4KQXGICIBC2gT9AL4SjgxlVZ8sIzQsVvbSKXunVkSXqL9ZFef1pvvylEFBqIlvnz+mkg r8dYHV988dFYdJGGGR6yDZ8lHeI/JbMAi+PbTQX+woDEzOBaCfEBkQf2OZVl2PdATY1H M+mQ== MIME-Version: 1.0 X-Received: by 10.180.74.230 with SMTP id x6mr6583450wiv.29.1388870912438; Sat, 04 Jan 2014 13:28:32 -0800 (PST) Sender: zbodek@gmail.com Received: by 10.217.112.65 with HTTP; Sat, 4 Jan 2014 13:28:32 -0800 (PST) In-Reply-To: <52C87BC0.2060304@freebsd.org> References: <52AF3D06.2000004@semihalf.com> <52AF760A.2030500@freebsd.org> <52B0900B.7020905@freebsd.org> <52B2D0F3.50100@semihalf.com> <52C87BC0.2060304@freebsd.org> Date: Sat, 4 Jan 2014 22:28:32 +0100 X-Google-Sender-Auth: z1A27uD3Y9Sp4YODNJ1y0xGHq5k Message-ID: Subject: Re: RFC: ARM related fixes - GIC, cache line size, PCI FDT & AHCI From: Zbigniew Bodek To: Nathan Whitehorn Content-Type: text/plain; charset=ISO-8859-1 Cc: Ruslan Bukin , "freebsd-arm@freebsd.org" , Olivier Houchard X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 21:28:35 -0000 2014/1/4 Nathan Whitehorn : > On 12/19/13 05:56, Zbigniew Bodek wrote: >> On 17.12.2013 18:55, Nathan Whitehorn wrote: >>> On 12/16/13 15:52, Nathan Whitehorn wrote: >>>> On 12/16/13 11:48, Zbigniew Bodek wrote: >>>>> Hello Everyone. >>>>> >>>>> We would like to submit some new patches recently developed by Semihalf. >>>>> >>>>> You can find them here: >>>>> http://people.freebsd.org/~zbb/Semihalf/12.2013/ >>>>> >>>>> Detailed description is available in the commit logs but in general: >>>>> >>>>> -- 0001-Resolve-cache-line-size-using-CP15.patch >>>>> - use cache line size acquired in runtime >>>>> >>>>> -- 0002-GIC-polarity-and-level-support.patch >>>>> - suport for setting trigger level and polarity in GIC >>>>> >>>>> -- 0003-Add-PCI-FDT-interrupt-trigger-polarity-parsing.patch >>>>> - trigger and polarity parsing for PCI FDT interrupts >>>>> >>>>> -- 0004-Do-not-attach-to-bridges-in-AHCI-driver.patch >>>>> -- 0005-Use-only-mapped-BIOs-on-ARM.patch >>>>> - Two patches enabling the AHCI driver on ARM chips >>>>> >>>>> >>>>> We will appreciate if you could post your comments and/or remarks by the >>>>> end of this week when we plan to commit the changes. >>>>> >>>>> Best regards >>>>> zbb >>>>> _______________________________________________ >>>>> 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" >>>> Can you hold off on >>>> 0003-Add-PCI-FDT-interrupt-trigger-polarity-parsing.patch for the time >>>> being? I'm restructuring this code at the moment. >>>> -Nathan >>>> _______________________________________________ >>>> 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" >>> This is done now. I have not updated the ARM code, because I don't know >>> how it is supposed to work, but you can take a look at r259513 to >>> powerpc/ofw/ofw_pci.c to see how the new stuff works. It relies on some >>> device (nexus, for example) implementing OFW_BUS_CONFIG_INTR(), which >>> takes an IRQ and a sense code, but that seems to be wrapped up in a lot >>> of ARM-specific stuff. >>> >>> If you like, I can just write a piece of bridge code, but I don't want >>> to interfere with in-flight things on your end. >> >> Hello Nathan. >> >> We will wait for your refactoring to finish so no worries. We can skip >> this patch for now, the more that there were some comments to this one. >> >> Thanks and best regards >> zbb >> > > My restructuring is now done. I suspect ARM may want something like > PowerPC's pic_if.m in the future, but the interfaces are now in place > (ofw_bus_map_intr(), ofw_bus_config_intr()) to make that transition > fairly painless later on. > -Nathan Thank you very much Nathan. Best regards zbb