From owner-freebsd-arm@FreeBSD.ORG Sun Feb 2 11:15:02 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 8455B5B4 for ; Sun, 2 Feb 2014 11:15:02 +0000 (UTC) Received: from sdf.lonestar.org (mx.sdf.org [192.94.73.18]) (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 6054813DF for ; Sun, 2 Feb 2014 11:15:01 +0000 (UTC) Received: from sdf.org (IDENT:hhh@sdf.lonestar.org [192.94.73.15]) by sdf.lonestar.org (8.14.7/8.14.5) with ESMTP id s12BEsSc028273 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO) for ; Sun, 2 Feb 2014 11:14:54 GMT Received: (from hhh@localhost) by sdf.org (8.14.7/8.12.8/Submit) id s12BEsrU020990 for freebsd-arm@freebsd.org; Sun, 2 Feb 2014 11:14:54 GMT X-Hashcash: 1:20:140202:freebsd-arm@freebsd.org::hYvwJOnsP+KJl8Ot:000000000000000000000000000000000000002edu From: hhh@sdf.org To: freebsd-arm@freebsd.org Subject: ZFS on ARM (Beaglebone Black) Date: Sun, 02 Feb 2014 12:14:50 +0100 Message-ID: <87k3dd7olx.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain 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: Sun, 02 Feb 2014 11:15:02 -0000 Hi all, I would like to know what is the status of the ZFS on ARM. My goal is to connect ZFS formatted hard drive to the Beaglebone Black running FreeBSD 10 (RELEASE or STABLE). I tried both the recent pre-compiled (ftp server) and self-compiled (crochet) images, but neither contained zfs.ko module. I tried to compile the module on the board, but got error while compiling the opensolaris module. In file included from /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/os/fm.c:59: /usr/src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/cpuvar.h:53:9: error: 'cpu_id' macro redefined [-Werror] #define cpu_id cpuid ^ ./machine/cpufunc.h:170:9: note: previous definition is here #define cpu_id() cpufuncs.cf_id() ^ 1 error generated. *** Error code 1 Stop. make: stopped in /usr/src/sys/modules/zfs Why did it go wrong? Thanks for help! -- hhh From owner-freebsd-arm@FreeBSD.ORG Sun Feb 2 12:05:24 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 92E34D01; Sun, 2 Feb 2014 12:05:24 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 7658016E5; Sun, 2 Feb 2014 12:05:24 +0000 (UTC) Received: from bender.Home (97e07ba1.skybroadband.com [151.224.123.161]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 29F025C682; Sun, 2 Feb 2014 12:05:17 +0000 (UTC) Date: Sun, 2 Feb 2014 12:05:09 +0000 From: Andrew Turner To: Michael Tuexen Subject: Re: panic Message-ID: <20140202120509.5d1e0f64@bender.Home> In-Reply-To: <14E59004-FC13-48DD-B789-AA78767C6871@freebsd.org> References: <14E59004-FC13-48DD-B789-AA78767C6871@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Sun, 02 Feb 2014 12:05:24 -0000 On Fri, 31 Jan 2014 06:36:43 +0100 Michael Tuexen wrote: > Dear all, > > while building the or xcb-util-renderutil-0.3.8 port I got > panic: Undefined instruction in kernel. > when running r261186 on a RPI-B. I could successfully build > ports for cvs, subversion, git... Can you get the opcodes in your kernel around 0xc048ec60. There are two instructions that may be the problem and depending on which one you are hitting it would indicate a different problem. Also if possible can you get more of the kernel output from around the panic. There are a few kernel printf calls that would narrow down what is happening. Andrew From owner-freebsd-arm@FreeBSD.ORG Sun Feb 2 12:11: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 10A0FF1F for ; Sun, 2 Feb 2014 12:11:44 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9A87E1760 for ; Sun, 2 Feb 2014 12:11:43 +0000 (UTC) Received: from [192.168.1.102] (p54819D5A.dip0.t-ipconnect.de [84.129.157.90]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 84A911C0E9796; Sun, 2 Feb 2014 13:11:40 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: panic From: Michael Tuexen In-Reply-To: <20140202120509.5d1e0f64@bender.Home> Date: Sun, 2 Feb 2014 13:11:40 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <14E59004-FC13-48DD-B789-AA78767C6871@freebsd.org> <20140202120509.5d1e0f64@bender.Home> To: Andrew Turner 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: Sun, 02 Feb 2014 12:11:44 -0000 On Feb 2, 2014, at 1:05 PM, Andrew Turner wrote: > On Fri, 31 Jan 2014 06:36:43 +0100 > Michael Tuexen wrote: > >> Dear all, >> >> while building the or xcb-util-renderutil-0.3.8 port I got >> panic: Undefined instruction in kernel. >> when running r261186 on a RPI-B. I could successfully build >> ports for cvs, subversion, git... > > Can you get the opcodes in your kernel around 0xc048ec60. There are two > instructions that may be the problem and depending on which one you are > hitting it would indicate a different problem. > > Also if possible can you get more of the kernel output from around the > panic. There are a few kernel printf calls that would narrow down what > is happening. Hi Andrew, I'm sorry, I rebooted the pi in the meantime... Best regards Michael > > Andrew > From owner-freebsd-arm@FreeBSD.ORG Sun Feb 2 12:19:16 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 E56C8111; Sun, 2 Feb 2014 12:19:16 +0000 (UTC) Received: from turing.morphism.de (smtp.morphism.de [IPv6:2001:4178:4:204::25]) by mx1.freebsd.org (Postfix) with ESMTP id A3F721786; Sun, 2 Feb 2014 12:19:16 +0000 (UTC) Received: from localhost (moore.morphism.de [IPv6:2001:4178:4:202::136]) by turing.morphism.de (Postfix) with ESMTP id EDAC83DCC2; Sun, 2 Feb 2014 12:19:15 +0000 (UTC) Date: Sun, 2 Feb 2014 12:19:15 +0000 From: Markus Pfeiffer To: Ian Lepore Subject: Re: FreeBSD 10 on Dockstar (Marvell Kirkwood) Message-ID: <20140202121915.GC40214@moore.morphism.de> References: <20131231211054.GA90299@moore.morphism.de> <52C8DCCA.9050908@googlemail.com> <1388954952.1158.324.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/e2eDi0V/xtL+Mc8" Content-Disposition: inline In-Reply-To: <1388954952.1158.324.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-arm@FreeBSD.org, ssl.qlt@gmail.com, "army.of.root" 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: Sun, 02 Feb 2014 12:19:17 -0000 --/e2eDi0V/xtL+Mc8 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Dear all, (and Ian in particular) maybe also as a followup to "Dreamplug stable/10 usb - sd file transfer corruption error - cache related?", I tried to find out why my fsck produced so many bogus DUPS and did the same test, i.e. I dump/restored the entire filesystem from one USB device to another. And lo and behold I get blocks of 32 zeros in some files. My kernel is the 11-current DOCKSTAR kernel, and it contains the USB_ALIGN=32 line. I build using make -j 12 buildkernel TARGET_ARCH=ARM KERNCONF=DOCKSTAR I read things about clang-eabi, but I assume that is all the default configuration. If anyone has any hint as to where to even start debugging this I'd be more than happy. I gather it should be a cache coherency issue. Is it maybe a USB problem? I am at least vaguely familiar with the USB stack. Cheers, Markus P.S. if possible CC me, as I am not on the list. --/e2eDi0V/xtL+Mc8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (DragonFly) iQIcBAEBAgAGBQJS7jfDAAoJEBRHBRYBD4mPxgYP/0bLz5TObX6UVfifexsXTBiq PHHUyyeP22D4kpWLMMxwC5VXmvJ1Cnp1F0zvTtFNlWS/VypAjDs+UXXIiO+7zG2y zauVm8vgcdX7X8O/aqi6EhQPSMFBT4w9n7RpkdFStNySZYOVz2pAlePgw/yRm/zq mkrFixzv9bHSCsiLsFCcwlQSrRGtP++jGHy53euuNsnMm1DYBwrCZbrQoSm6bfsC hM2YF2HoQTaxdBqQFxDpBIzuqeQFW70hEaHFFiPhgUYv2HK4BJQNN6+Poznh5h9w 0VOg18KAW3YFRjbqfD/bC1dUzSm1cHWXCat/fXzSEPAbzBv64NADOmBOoqCJsm1W nIEUv2KtYdOVTkgdI3NGDTwKpVnMWH8B3IHSDvTI8l2eheNEQvF7jDRbRCEEIJwW jG5OoPrxlqpWeHIeRNoPZ5TWjbbpnuO4lnCVuAaYntRqCghiiq1dUatdYzEDgYwi HRL41jLSZfcmQD/oZk6vkm5jFXGH880szA35JPzm86kf1/ubslmYXeOzpBuH7v8O i7nph8VN/Vuln8Ux1fClSoIVZGW3umi8IjZEKDh8octMbkE2AB1FWdCmK58anLpg 09ChOy/icCw4G7/seEoKzmlRRKsl/D259Hee6g2hVnu6OA2WoUOUQVFxMbVW0KJp MaeTCJ3vbgx01fqu0F/V =A56X -----END PGP SIGNATURE----- --/e2eDi0V/xtL+Mc8-- From owner-freebsd-arm@FreeBSD.ORG Sun Feb 2 15:59: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 3BE4DE24; Sun, 2 Feb 2014 15:59:48 +0000 (UTC) Received: from mailgate-01.zdv.uni-mainz.de (mailgate-01.zdv.Uni-Mainz.DE [IPv6:2001:4c80:40:62d:203:ffff:fe5d:b2f1]) by mx1.freebsd.org (Postfix) with ESMTP id 9292F1685; Sun, 2 Feb 2014 15:59:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-mainz.de; i=@uni-mainz.de; q=dns/txt; s=ironport; t=1391356788; x=1422892788; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=cc5Eb3OGHPBC+dugUnfnv1ySVz8uW0UZbH4uN0yzp9o=; b=TK6bWYYAo2M6cRf7mhX6kv4mDsDhZ/CoiQaH+d0UNSvjLpIgcGzH16Xi oBJZBOtIRORyIBJ+Ssw+2ke8ngcUwKdF01y3tIw+l7lB5CW25k86hG3K2 WPDg/UAUB1LC0T1Mpk9CZAH2tDkBC+ovPR2tnYI2SZVXHA4+drIzX30Up c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAJ1q7lIKXgZQ/2dsb2JhbABYgmtZV71hgRd0giUBAQWBBQQCAQgOAwQBAQEnBzIUCQgCBAESCId9AcwWF48QBoQyBIkRlVyLXoMtgWgkHg X-IPAS-Result: AqIEAJ1q7lIKXgZQ/2dsb2JhbABYgmtZV71hgRd0giUBAQWBBQQCAQgOAwQBAQEnBzIUCQgCBAESCId9AcwWF48QBoQyBIkRlVyLXoMtgWgkHg Received: from e14hub-01.zdv.uni-mainz.de ([10.94.6.80]) by mailgate-01.zdv.uni-mainz.de with ESMTP; 02 Feb 2014 16:59:46 +0100 Received: from e15be-03.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9238) by E14HUB-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:21d:d8ff:feb7:1c5f) with Microsoft SMTP Server (TLS) id 14.3.174.1; Sun, 2 Feb 2014 16:59:14 +0100 Received: from e15be-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9090) by e15be-03.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9238) with Microsoft SMTP Server (TLS) id 15.0.775.38; Sun, 2 Feb 2014 16:59:14 +0100 Received: from e15be-01.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9090]) by e15be-01.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9090%15]) with mapi id 15.00.0775.031; Sun, 2 Feb 2014 16:59:14 +0100 From: =?iso-8859-1?B?V2Vp3ywgSvxyZ2Vu?= To: 'Nathan Whitehorn' , "'freebsd-arm@freebsd.org'" Subject: RE: status = "disabled" Thread-Topic: status = "disabled" Thread-Index: AQHPICo00Yasfoxum0+wDUsHjXn/qZqiGXMg Date: Sun, 2 Feb 2014 15:59:14 +0000 Message-ID: <06235e983f8142fcb7f6f6c329a84b90@e15be-01.zdv.Uni-Mainz.DE> References: <726dc97ccd1f44b3ba9d7bee3eeff08a@e15be-01.zdv.Uni-Mainz.DE> <52EE622C.9010004@freebsd.org> In-Reply-To: <52EE622C.9010004@freebsd.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.93.178.81] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Sun, 02 Feb 2014 15:59:48 -0000 > -----Original Message----- > From: Nathan Whitehorn [mailto:nwhitehorn@freebsd.org] > Sent: Sunday, February 02, 2014 4:20 PM > To: Wei=DF, J=FCrgen; freebsd-arm@freebsd.org > Subject: Re: status =3D "disabled" >=20 > On 02/02/14 05:55, Wei=DF, J=FCrgen wrote: > > Hi, > > > > it seems your recent changes (261351) discarded a call to fdt_is_enable= d > > for devices on simplebus. So 'status =3D "disabled" ' does not work > > anymore in arm dts. > > > > Regards > > > > Juergen Weiss > > > > Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, > > weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)= 39-26407 > > > > >=20 > That's actually required to make some hardware work ("disabled" may just > mean the clock is turned off and needs to be turned back on, which means > you absolutely do want that device probed). The device drivers > themselves, not the bus, should be checking this property and > interpreting it. If this has actually broken hardware, we could add a > temporary #ifdef __arm__ check to the simplebus tree-walker while the > relevant drivers get fixed up. > -Nathan Thanks for the quick answer. Right know there seem to be zero device driver= s doing this. And there are quite a few fdts going from general (all devices = on SOC)=20 to specific (devices usable on specific board), which use the status field to disable a device (for example i.mx in general and wandboard specifically= ). At least with the i.mx6 the unconnected sdhci devices lead to hangs during boot. Regards Juergen Weiss Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-2= 6407 From owner-freebsd-arm@FreeBSD.ORG Sun Feb 2 16:09:47 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 E5F22843 for ; Sun, 2 Feb 2014 16:09:46 +0000 (UTC) Received: from cora.hrz.tu-chemnitz.de (cora.hrz.tu-chemnitz.de [134.109.228.40]) (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 672BA1756 for ; Sun, 2 Feb 2014 16:09:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-chemnitz.de; s=dkim2010; h=MIME-Version:Content-Type:In-Reply-To:References:Subject:To:From:Message-ID:Date; bh=hPAv05YhWc67R/A5VxsLTNbMDFThB02auhhrvlTs/Tc=; b=h8mKWMA3chpJx/lhX1smB1gff5C21K+TbKgkgsYSJdOAyp5GfTCn/y1ZOcpRXaNrExucG7bRpX2PtLhfclrOpFbYlLr8RhvGvlMMqPu1cX6ELCrvyFG8T06Z1QrqvaRmGdEyJCe0aOwBO8m/HgK0S3T6C8EHrSH7oqp87xro8bY=; Received: from postman.hrz.tu-chemnitz.de ([134.109.133.5] helo=mailbox.hrz.tu-chemnitz.de) by cora.hrz.tu-chemnitz.de with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1W9zGL-000130-BC for freebsd-arm@freebsd.org; Sun, 02 Feb 2014 16:47:13 +0100 Received: from boogie.hrz.tu-chemnitz.de ([134.109.133.10] helo=localhost) by mailbox.hrz.tu-chemnitz.de with esmtp (Exim 4.80.1) (envelope-from ) id 1W9zGL-0007PY-92 for freebsd-arm@freebsd.org; Sun, 02 Feb 2014 16:47:13 +0100 Received: from 77-64-136-114.dynamic.primacom.net (77-64-136-114.dynamic.primacom.net [77.64.136.114]) by mail.tu-chemnitz.de (Horde Framework) with HTTP; Sun, 02 Feb 2014 16:47:13 +0100 Date: Sun, 02 Feb 2014 16:47:13 +0100 Message-ID: <20140202164713.Horde.1jHdcd2ZR4JymDKUnSaCmA2@mail.tu-chemnitz.de> From: Matthieu Kraus To: freebsd-arm@freebsd.org Subject: Re: ZFS on ARM (Beaglebone Black) References: <87k3dd7olx.fsf@gmail.com> In-Reply-To: <87k3dd7olx.fsf@gmail.com> User-Agent: Internet Messaging Program (IMP) H5 (6.1.2) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-Scan-AV: mailbox.hrz.tu-chemnitz.de; 2014-02-02 16:47:13; b4a57b50b19a6935f3eaaf086cf96b83 X-purgate: clean X-purgate-type: clean X-purgate-ID: 154106::1391356033-00000517-5A52B565/0-0/0-0 X-Scan-SA: cora.hrz.tu-chemnitz.de; 2014-02-02 16:47:13; 59755db6c53d7eb1b2857de7f02ec883 X-Spam-Score: -1.5 (-) X-Spam-Report: --- Textanalyse SpamAssassin 3.3.1 (-1.5 Punkte) Fragen an/questions to: Postmaster TU Chemnitz * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain --- Ende Textanalyse 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: Sun, 02 Feb 2014 16:09:47 -0000 I'm using the following since a few years which seems to work fine - it's a rather hacky approach, though, I guess: Index: sys/cddl/compat/opensolaris/sys/cpuvar.h =================================================================== --- sys/cddl/compat/opensolaris/sys/cpuvar.h (revision 227813) +++ sys/cddl/compat/opensolaris/sys/cpuvar.h (working copy) @@ -50,6 +50,9 @@ /* Some code may choose to redefine this if pcpu_t would be more useful. */ #define cpu_t solaris_cpu_t +#ifdef cpu_id +#undef cpu_id +#endif #define cpu_id cpuid extern solaris_cpu_t solaris_cpu[]; Quoting hhh@sdf.org: > Hi all, > > I would like to know what is the status of the ZFS on ARM. My goal is > to connect ZFS formatted hard drive to the Beaglebone Black running > FreeBSD 10 (RELEASE or STABLE). > > I tried both the recent pre-compiled (ftp server) and self-compiled > (crochet) images, but neither contained zfs.ko module. I tried to > compile the module on the board, but got error while compiling the > opensolaris module. > > > In file included from > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/os/fm.c:59: > /usr/src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/cpuvar.h:53:9: > error: 'cpu_id' macro redefined [-Werror] > #define cpu_id cpuid > ^ > ./machine/cpufunc.h:170:9: note: previous definition is here > #define cpu_id() cpufuncs.cf_id() > ^ > 1 error generated. > *** Error code 1 > > Stop. > make: stopped in /usr/src/sys/modules/zfs > > > > Why did it go wrong? > > Thanks for help! > > -- hhh > _______________________________________________ > 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 Sun Feb 2 16:20:21 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 1754BA5F for ; Sun, 2 Feb 2014 16:20:21 +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 D932F1879 for ; Sun, 2 Feb 2014 16:20:20 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed 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 <0N0D00H00JRFTD00@smtpauth4.wiscmail.wisc.edu> for freebsd-arm@FreeBSD.org; Sun, 02 Feb 2014 09:20:13 -0600 (CST) X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.2.151515, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from comporellon.tachypleus.net (adsl-76-208-68-77.dsl.mdsnwi.sbcglobal.net [76.208.68.77]) 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 <0N0D005ADJXO6510@smtpauth4.wiscmail.wisc.edu>; Sun, 02 Feb 2014 09:20:13 -0600 (CST) Message-id: <52EE622C.9010004@freebsd.org> Date: Sun, 02 Feb 2014 09:20:12 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: =?ISO-8859-1?Q?=22Wei=DF=2C_J=FCrgen=22?= , "freebsd-arm@freebsd.org" Subject: Re: status = "disabled" References: <726dc97ccd1f44b3ba9d7bee3eeff08a@e15be-01.zdv.Uni-Mainz.DE> In-reply-to: <726dc97ccd1f44b3ba9d7bee3eeff08a@e15be-01.zdv.Uni-Mainz.DE> 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: Sun, 02 Feb 2014 16:20:21 -0000 On 02/02/14 05:55, Weiß, Jürgen wrote: > Hi, > > it seems your recent changes (261351) discarded a call to fdt_is_enabled > for devices on simplebus. So 'status = "disabled" ' does not work > anymore in arm dts. > > Regards > > Juergen Weiss > > Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, > weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407 > > That's actually required to make some hardware work ("disabled" may just mean the clock is turned off and needs to be turned back on, which means you absolutely do want that device probed). The device drivers themselves, not the bus, should be checking this property and interpreting it. If this has actually broken hardware, we could add a temporary #ifdef __arm__ check to the simplebus tree-walker while the relevant drivers get fixed up. -Nathan From owner-freebsd-arm@FreeBSD.ORG Sun Feb 2 16:39:53 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 7F32EFB9; Sun, 2 Feb 2014 16:39:53 +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 379DF199F; Sun, 2 Feb 2014 16:39:52 +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 1WA05B-0007sU-7s; Sun, 02 Feb 2014 16:39:46 +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 s12GdfFN062216; Sun, 2 Feb 2014 09:39:41 -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/llpwo26jNhEDPfhFj+6Gd Subject: RE: status = "disabled" From: Ian Lepore To: =?ISO-8859-1?Q?Wei=DF=2C_J=FCrgen?= In-Reply-To: <06235e983f8142fcb7f6f6c329a84b90@e15be-01.zdv.Uni-Mainz.DE> References: <726dc97ccd1f44b3ba9d7bee3eeff08a@e15be-01.zdv.Uni-Mainz.DE> <52EE622C.9010004@freebsd.org> <06235e983f8142fcb7f6f6c329a84b90@e15be-01.zdv.Uni-Mainz.DE> Content-Type: multipart/mixed; boundary="=-n7hzc6+iGE5ZRe14CnS4" Date: Sun, 02 Feb 2014 09:39:41 -0700 Message-ID: <1391359181.13026.18.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: Sun, 02 Feb 2014 16:39:53 -0000 --=-n7hzc6+iGE5ZRe14CnS4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s12GdfFN062216 On Sun, 2014-02-02 at 15:59 +0000, Wei=DF, J=FCrgen wrote: >=20 > > -----Original Message----- > > From: Nathan Whitehorn [mailto:nwhitehorn@freebsd.org] > > Sent: Sunday, February 02, 2014 4:20 PM > > To: Wei=DF, J=FCrgen; freebsd-arm@freebsd.org > > Subject: Re: status =3D "disabled" > >=20 > > On 02/02/14 05:55, Wei=DF, J=FCrgen wrote: > > > Hi, > > > > > > it seems your recent changes (261351) discarded a call to fdt_is_en= abled > > > for devices on simplebus. So 'status =3D "disabled" ' does not work > > > anymore in arm dts. > > > > > > Regards > > > > > > Juergen Weiss > > > > > > Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeit= ung, > > > weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6= 131)39-26407 > > > > > > > >=20 > > That's actually required to make some hardware work ("disabled" may j= ust > > mean the clock is turned off and needs to be turned back on, which me= ans > > you absolutely do want that device probed). The device drivers > > themselves, not the bus, should be checking this property and > > interpreting it. If this has actually broken hardware, we could add a > > temporary #ifdef __arm__ check to the simplebus tree-walker while the > > relevant drivers get fixed up. > > -Nathan >=20 >=20 > Thanks for the quick answer. Right know there seem to be zero device dr= ivers > doing this. And there are quite a few fdts going from general (all devi= ces on SOC)=20 > to specific (devices usable on specific board), which use the status fi= eld > to disable a device (for example i.mx in general and wandboard specific= ally). > At least with the i.mx6 the unconnected sdhci devices lead to hangs dur= ing > boot. Here is a little patch to get you running again in the short term. I'm going to see if I can make a pass through all our drivers and fix things the right way. If I can't get that done in a hurry (today, basically), we'll commit something like this patch for the short term. -- Ian --=-n7hzc6+iGE5ZRe14CnS4 Content-Disposition: inline; filename="aicasm_stab8.diff" Content-Type: text/x-patch; name="aicasm_stab8.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: Makefile.inc1 =================================================================== --- Makefile.inc1 (revision 261326) +++ Makefile.inc1 (working copy) @@ -250,6 +250,21 @@ XMAKE= TOOLS_PREFIX=${WORLDTMP} ${BMAKE} \ TARGET=${TARGET} TARGET_ARCH=${TARGET_ARCH} \ -DWITHOUT_GDB +# kernel-tools stage +KTMAKEENV= INSTALL="sh ${.CURDIR}/tools/install.sh" \ + PATH=${BPATH}:${PATH} \ + WORLDTMP=${WORLDTMP} \ + VERSION="${VERSION}" \ + COMPILER_TYPE=${COMPILER_TYPE} +KTMAKE= TOOLS_PREFIX=${WORLDTMP} MAKEOBJDIRPREFIX=${WORLDTMP} \ + ${KTMAKEENV} ${MAKE} ${WORLD_FLAGS} -f Makefile.inc1 \ + DESTDIR= \ + BOOTSTRAPPING=${OSRELDATE} \ + SSP_CFLAGS= \ + -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN \ + -DNO_PIC -DNO_PROFILE -DNO_SHARED \ + -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF -DEARLY_BUILD + # world stage WMAKEENV= ${CROSSENV} \ _SHLIBDIRPREFIX=${WORLDTMP} \ @@ -403,6 +418,7 @@ _cross-tools: @echo ">>> stage 3: cross tools" @echo "--------------------------------------------------------------" ${_+_}cd ${.CURDIR}; ${XMAKE} cross-tools + ${_+_}cd ${.CURDIR}; ${XMAKE} kernel-tools _includes: @echo @echo "--------------------------------------------------------------" @@ -776,20 +792,7 @@ buildkernel: @echo "--------------------------------------------------------------" @echo ">>> stage 2.3: build tools" @echo "--------------------------------------------------------------" - cd ${KRNLOBJDIR}/${_kernel}; \ - PATH=${BPATH}:${PATH} \ - MAKESRCPATH=${KERNSRCDIR}/dev/aic7xxx/aicasm \ - ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF \ - -f ${KERNSRCDIR}/dev/aic7xxx/aicasm/Makefile -# XXX - Gratuitously builds aicasm in the ``makeoptions NO_MODULES'' case. -.if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) && exists(${KERNSRCDIR}/modules) -.for target in obj depend all - cd ${KERNSRCDIR}/modules/aic7xxx/aicasm; \ - PATH=${BPATH}:${PATH} \ - MAKEOBJDIRPREFIX=${KRNLOBJDIR}/${_kernel}/modules \ - ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF ${target} -.endfor -.endif + ${_+_}cd ${.CURDIR}; ${KTMAKE} kernel-tools .if !defined(NO_KERNELDEPEND) @echo @echo "--------------------------------------------------------------" @@ -1003,10 +1006,6 @@ bootstrap-tools: # # build-tools: Build special purpose build tools # -.if defined(MODULES_WITH_WORLD) && exists(${KERNSRCDIR}/modules) -_aicasm= sys/modules/aic7xxx/aicasm -.endif - .if !defined(NO_SHARE) _share= share/syscons/scrnmaps .endif @@ -1027,7 +1026,6 @@ build-tools: lib/ncurses/ncurses \ lib/ncurses/ncursesw \ ${_share} \ - ${_aicasm} \ usr.bin/awk \ lib/libmagic \ usr.sbin/sysinstall @@ -1047,6 +1045,23 @@ build-tools: .endfor # +# kernel-tools: Build kernel-building tools +# +kernel-tools: .MAKE + mkdir -p ${MAKEOBJDIRPREFIX}/usr + mtree -deU -f ${.CURDIR}/etc/mtree/BSD.usr.dist \ + -p ${MAKEOBJDIRPREFIX}/usr >/dev/null +.for _tool in \ + sys/dev/aic7xxx/aicasm + ${_+_}@${ECHODIR} "===> ${_tool} (obj,depend,all,install)"; \ + cd ${.CURDIR}/${_tool} && \ + ${MAKE} DIRPRFX=${_tool}/ obj && \ + ${MAKE} DIRPRFX=${_tool}/ depend && \ + ${MAKE} DIRPRFX=${_tool}/ all && \ + ${MAKE} DIRPRFX=${_tool}/ DESTDIR=${MAKEOBJDIRPREFIX} install +.endfor + +# # cross-tools: Build cross-building tools # .if ${TARGET_ARCH} != ${MACHINE_ARCH} || ${BOOTSTRAPPING} < 800035 Index: sys/modules/aic7xxx/ahc/Makefile =================================================================== --- sys/modules/aic7xxx/ahc/Makefile (revision 261326) +++ sys/modules/aic7xxx/ahc/Makefile (working copy) @@ -15,13 +15,10 @@ REG_PRINT_OPT= -p aic7xxx_reg_print.c .endif BEFORE_DEPEND = ${GENSRCS} -../aicasm/aicasm: ${.CURDIR}/../../../dev/aci7xxx/aicasm/*.[chyl] - ( cd ${.CURDIR}/../aicasm; ${MAKE} aicasm; ) - ${GENSRCS}: \ ${.CURDIR}/../../../dev/aic7xxx/aic7xxx.{reg,seq} \ - ${.CURDIR}/../../../cam/scsi/scsi_message.h ../aicasm/aicasm - ../aicasm/aicasm ${INCLUDES} -I${.CURDIR}/../../../cam/scsi \ + ${.CURDIR}/../../../cam/scsi/scsi_message.h + aicasm ${INCLUDES} -I${.CURDIR}/../../../cam/scsi \ -I${.CURDIR}/../../../dev/aic7xxx \ -o aic7xxx_seq.h -r aic7xxx_reg.h \ ${REG_PRINT_OPT} \ Index: sys/modules/aic7xxx/ahd/Makefile =================================================================== --- sys/modules/aic7xxx/ahd/Makefile (revision 261326) +++ sys/modules/aic7xxx/ahd/Makefile (working copy) @@ -15,13 +15,10 @@ REG_PRINT_OPT= -p aic79xx_reg_print.c .endif BEFORE_DEPEND= ${GENSRCS} -../aicasm/aicasm: ${.CURDIR}/../../../dev/aic7xxx/aicasm/*.[chyl] - ( cd ${.CURDIR}/../aicasm; ${MAKE} aicasm; ) - ${GENSRCS}: \ ${.CURDIR}/../../../dev/aic7xxx/aic79xx.{reg,seq} \ - ${.CURDIR}/../../../cam/scsi/scsi_message.h ../aicasm/aicasm - ../aicasm/aicasm ${INCLUDES} -I${.CURDIR}/../../../cam/scsi \ + ${.CURDIR}/../../../cam/scsi/scsi_message.h + aicasm ${INCLUDES} -I${.CURDIR}/../../../cam/scsi \ -I${.CURDIR}/../../../dev/aic7xxx \ -o aic79xx_seq.h -r aic79xx_reg.h \ ${REG_PRINT_OPT} \ Index: sys/modules/aic7xxx/Makefile =================================================================== --- sys/modules/aic7xxx/Makefile (revision 261326) +++ sys/modules/aic7xxx/Makefile (working copy) @@ -1,6 +1,6 @@ # $FreeBSD$ -SUBDIR= aicasm ahc ahd +SUBDIR= ahc ahd .include Index: sys/conf/files =================================================================== --- sys/conf/files (revision 261326) +++ sys/conf/files (working copy) @@ -9,44 +9,39 @@ acpi_quirks.h optional acpi \ compile-with "${AWK} -f $S/tools/acpi_quirks2h.awk $S/dev/acpica/acpi_quirks" \ no-obj no-implicit-rule before-depend \ clean "acpi_quirks.h" -aicasm optional ahc | ahd \ - dependency "$S/dev/aic7xxx/aicasm/*.[chyl]" \ - compile-with "CC='${CC}' ${MAKE} -f $S/dev/aic7xxx/aicasm/Makefile MAKESRCPATH=$S/dev/aic7xxx/aicasm" \ - no-obj no-implicit-rule \ - clean "aicasm* y.tab.h" aic7xxx_seq.h optional ahc \ - compile-with "./aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i $S/dev/aic7xxx/aic7xxx_osm.h $S/dev/aic7xxx/aic7xxx.seq" \ + compile-with "aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i $S/dev/aic7xxx/aic7xxx_osm.h $S/dev/aic7xxx/aic7xxx.seq" \ no-obj no-implicit-rule before-depend local \ clean "aic7xxx_seq.h" \ - dependency "$S/dev/aic7xxx/aic7xxx.{reg,seq} $S/cam/scsi/scsi_message.h aicasm" + dependency "$S/dev/aic7xxx/aic7xxx.{reg,seq} $S/cam/scsi/scsi_message.h" aic7xxx_reg.h optional ahc \ - compile-with "./aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i $S/dev/aic7xxx/aic7xxx_osm.h $S/dev/aic7xxx/aic7xxx.seq" \ + compile-with "aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i $S/dev/aic7xxx/aic7xxx_osm.h $S/dev/aic7xxx/aic7xxx.seq" \ no-obj no-implicit-rule before-depend local \ clean "aic7xxx_reg.h" \ - dependency "$S/dev/aic7xxx/aic7xxx.{reg,seq} $S/cam/scsi/scsi_message.h aicasm" + dependency "$S/dev/aic7xxx/aic7xxx.{reg,seq} $S/cam/scsi/scsi_message.h" aic7xxx_reg_print.c optional ahc \ - compile-with "./aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i $S/dev/aic7xxx/aic7xxx_osm.h $S/dev/aic7xxx/aic7xxx.seq" \ + compile-with "aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i $S/dev/aic7xxx/aic7xxx_osm.h $S/dev/aic7xxx/aic7xxx.seq" \ no-obj no-implicit-rule local \ clean "aic7xxx_reg_print.c" \ - dependency "$S/dev/aic7xxx/aic7xxx.{reg,seq} $S/cam/scsi/scsi_message.h aicasm" + dependency "$S/dev/aic7xxx/aic7xxx.{reg,seq} $S/cam/scsi/scsi_message.h" aic7xxx_reg_print.o optional ahc ahc_reg_pretty_print \ compile-with "${NORMAL_C}" \ no-implicit-rule local aic79xx_seq.h optional ahd pci \ - compile-with "./aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic79xx_seq.h -r aic79xx_reg.h -p aic79xx_reg_print.c -i $S/dev/aic7xxx/aic79xx_osm.h $S/dev/aic7xxx/aic79xx.seq" \ + compile-with "aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic79xx_seq.h -r aic79xx_reg.h -p aic79xx_reg_print.c -i $S/dev/aic7xxx/aic79xx_osm.h $S/dev/aic7xxx/aic79xx.seq" \ no-obj no-implicit-rule before-depend local \ clean "aic79xx_seq.h" \ - dependency "$S/dev/aic7xxx/aic79xx.{reg,seq} $S/cam/scsi/scsi_message.h aicasm" + dependency "$S/dev/aic7xxx/aic79xx.{reg,seq} $S/cam/scsi/scsi_message.h" aic79xx_reg.h optional ahd pci \ - compile-with "./aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic79xx_seq.h -r aic79xx_reg.h -p aic79xx_reg_print.c -i $S/dev/aic7xxx/aic79xx_osm.h $S/dev/aic7xxx/aic79xx.seq" \ + compile-with "aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic79xx_seq.h -r aic79xx_reg.h -p aic79xx_reg_print.c -i $S/dev/aic7xxx/aic79xx_osm.h $S/dev/aic7xxx/aic79xx.seq" \ no-obj no-implicit-rule before-depend local \ clean "aic79xx_reg.h" \ - dependency "$S/dev/aic7xxx/aic79xx.{reg,seq} $S/cam/scsi/scsi_message.h aicasm" + dependency "$S/dev/aic7xxx/aic79xx.{reg,seq} $S/cam/scsi/scsi_message.h" aic79xx_reg_print.c optional ahd pci \ - compile-with "./aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic79xx_seq.h -r aic79xx_reg.h -p aic79xx_reg_print.c -i $S/dev/aic7xxx/aic79xx_osm.h $S/dev/aic7xxx/aic79xx.seq" \ + compile-with "aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic79xx_seq.h -r aic79xx_reg.h -p aic79xx_reg_print.c -i $S/dev/aic7xxx/aic79xx_osm.h $S/dev/aic7xxx/aic79xx.seq" \ no-obj no-implicit-rule local \ clean "aic79xx_reg_print.c" \ - dependency "$S/dev/aic7xxx/aic79xx.{reg,seq} $S/cam/scsi/scsi_message.h aicasm" + dependency "$S/dev/aic7xxx/aic79xx.{reg,seq} $S/cam/scsi/scsi_message.h" aic79xx_reg_print.o optional ahd pci ahd_reg_pretty_print \ compile-with "${NORMAL_C}" \ no-implicit-rule local Index: sys/dev/aic7xxx/aicasm/Makefile =================================================================== --- sys/dev/aic7xxx/aicasm/Makefile (revision 261326) +++ sys/dev/aic7xxx/aicasm/Makefile (working copy) @@ -15,7 +15,7 @@ SRCS= ${GENHDRS} ${CSRCS} ${YSRCS} ${LSRCS} CLEANFILES+= ${GENHDRS} ${YSRCS:R:C/(.*)/\1.output/g} DPADD= ${LIBL} LDADD= -ll -WARNS?= 6 +WARNS?= 0 # Correct path for kernel builds # Don't rely on the kernel's .depend file @@ -24,13 +24,7 @@ LDADD= -ll DEPENDFILE= .depend_aicasm .endif -.if ${CC} == "icc" -CFLAGS+= -restrict -NOSTDINC= -X -.else -NOSTDINC= -nostdinc -.endif -CFLAGS+= ${NOSTDINC} -I/usr/include -I. +CFLAGS+= -I${.CURDIR} .ifdef MAKESRCPATH CFLAGS+= -I${MAKESRCPATH} .endif @@ -44,4 +38,8 @@ YFLAGS+= -t -v LFLAGS+= -d .endif +BINDIR=/usr/bin + +build-tools: ${PROG} + .include --=-n7hzc6+iGE5ZRe14CnS4-- From owner-freebsd-arm@FreeBSD.ORG Sun Feb 2 16:43: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 44A2E403; Sun, 2 Feb 2014 16:43:17 +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 102F31A1F; Sun, 2 Feb 2014 16:43:16 +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 1WA08Z-0006pa-90; Sun, 02 Feb 2014 16:43:15 +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 s12GhBLv062228; Sun, 2 Feb 2014 09:43:11 -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: U2FsdGVkX19VluXQ9VMTn5VVDsScB+S6 Subject: RE: status = "disabled" (with the right patch this time) From: Ian Lepore To: =?ISO-8859-1?Q?Wei=DF=2C_J=FCrgen?= In-Reply-To: <06235e983f8142fcb7f6f6c329a84b90@e15be-01.zdv.Uni-Mainz.DE> References: <726dc97ccd1f44b3ba9d7bee3eeff08a@e15be-01.zdv.Uni-Mainz.DE> <52EE622C.9010004@freebsd.org> <06235e983f8142fcb7f6f6c329a84b90@e15be-01.zdv.Uni-Mainz.DE> Content-Type: multipart/mixed; boundary="=-GKdBpTLDRqI0exn7tErc" Date: Sun, 02 Feb 2014 09:43:11 -0700 Message-ID: <1391359391.13026.20.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: Sun, 02 Feb 2014 16:43:17 -0000 --=-GKdBpTLDRqI0exn7tErc Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s12GhBLv062228 On Sun, 2014-02-02 at 15:59 +0000, Wei=DF, J=FCrgen wrote: >=20 > > -----Original Message----- > > From: Nathan Whitehorn [mailto:nwhitehorn@freebsd.org] > > Sent: Sunday, February 02, 2014 4:20 PM > > To: Wei=DF, J=FCrgen; freebsd-arm@freebsd.org > > Subject: Re: status =3D "disabled" > >=20 > > On 02/02/14 05:55, Wei=DF, J=FCrgen wrote: > > > Hi, > > > > > > it seems your recent changes (261351) discarded a call to fdt_is_en= abled > > > for devices on simplebus. So 'status =3D "disabled" ' does not work > > > anymore in arm dts. > > > > > > Regards > > > > > > Juergen Weiss > > > > > > Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeit= ung, > > > weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6= 131)39-26407 > > > > > > > >=20 > > That's actually required to make some hardware work ("disabled" may j= ust > > mean the clock is turned off and needs to be turned back on, which me= ans > > you absolutely do want that device probed). The device drivers > > themselves, not the bus, should be checking this property and > > interpreting it. If this has actually broken hardware, we could add a > > temporary #ifdef __arm__ check to the simplebus tree-walker while the > > relevant drivers get fixed up. > > -Nathan >=20 >=20 > Thanks for the quick answer. Right know there seem to be zero device dr= ivers > doing this. And there are quite a few fdts going from general (all devi= ces on SOC)=20 > to specific (devices usable on specific board), which use the status fi= eld > to disable a device (for example i.mx in general and wandboard specific= ally). > At least with the i.mx6 the unconnected sdhci devices lead to hangs dur= ing > boot. >=20 Ooops, I attached the wrong patch to my previous reply, here's the right one. -- Ian --=-GKdBpTLDRqI0exn7tErc Content-Disposition: inline; filename="status.diff" Content-Type: text/x-patch; name="status.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: simplebus.c =================================================================== --- simplebus.c (revision 261397) +++ simplebus.c (working copy) @@ -242,6 +242,7 @@ { struct simplebus_softc *sc; struct simplebus_devinfo *ndi; + char status[64]; uint32_t *reg, *intr, icells; uint64_t phys, size; phandle_t iparent; @@ -251,6 +252,14 @@ sc = device_get_softc(dev); +#ifdef __arm__ + /* XXX: THIS IS TOTALLY BOGUS AND NEEDS TO BE MOVED TO THE DRIVERS */ + status[0] = 0; + OF_getprop(node, "status", status, sizeof(status)); + if (strcmp(status, "disabled") == 0) + return NULL; +#endif + ndi = malloc(sizeof(*ndi), M_DEVBUF, M_WAITOK | M_ZERO); if (ofw_bus_gen_setup_devinfo(&ndi->obdinfo, node) != 0) { free(ndi, M_DEVBUF); --=-GKdBpTLDRqI0exn7tErc-- From owner-freebsd-arm@FreeBSD.ORG Sun Feb 2 17:13:32 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 2BDB9F17 for ; Sun, 2 Feb 2014 17:13:32 +0000 (UTC) Received: from smtpauth2.wiscmail.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC6451D3F for ; Sun, 2 Feb 2014 17:13:31 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0N0D00B00M8GPI00@smtpauth2.wiscmail.wisc.edu> for freebsd-arm@FreeBSD.org; Sun, 02 Feb 2014 10:13:23 -0600 (CST) X-Spam-PmxInfo: Server=avs-2, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.2.160615, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from comporellon.tachypleus.net (adsl-76-208-68-77.dsl.mdsnwi.sbcglobal.net [76.208.68.77]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0N0D00A5OME9PC20@smtpauth2.wiscmail.wisc.edu>; Sun, 02 Feb 2014 10:13:22 -0600 (CST) Message-id: <52EE6EA1.90707@freebsd.org> Date: Sun, 02 Feb 2014 10:13:21 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: =?ISO-8859-1?Q?=22Wei=DF=2C_J=FCrgen=22?= , "'freebsd-arm@freebsd.org'" Subject: Re: status = "disabled" References: <726dc97ccd1f44b3ba9d7bee3eeff08a@e15be-01.zdv.Uni-Mainz.DE> <52EE622C.9010004@freebsd.org> <06235e983f8142fcb7f6f6c329a84b90@e15be-01.zdv.Uni-Mainz.DE> In-reply-to: <06235e983f8142fcb7f6f6c329a84b90@e15be-01.zdv.Uni-Mainz.DE> 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: Sun, 02 Feb 2014 17:13:32 -0000 On 02/02/14 09:59, Weiß, Jürgen wrote: > >> -----Original Message----- >> From: Nathan Whitehorn [mailto:nwhitehorn@freebsd.org] >> Sent: Sunday, February 02, 2014 4:20 PM >> To: Weiß, Jürgen; freebsd-arm@freebsd.org >> Subject: Re: status = "disabled" >> >> On 02/02/14 05:55, Weiß, Jürgen wrote: >>> Hi, >>> >>> it seems your recent changes (261351) discarded a call to fdt_is_enabled >>> for devices on simplebus. So 'status = "disabled" ' does not work >>> anymore in arm dts. >>> >>> Regards >>> >>> Juergen Weiss >>> >>> Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, >>> weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407 >>> >>> >> That's actually required to make some hardware work ("disabled" may just >> mean the clock is turned off and needs to be turned back on, which means >> you absolutely do want that device probed). The device drivers >> themselves, not the bus, should be checking this property and >> interpreting it. If this has actually broken hardware, we could add a >> temporary #ifdef __arm__ check to the simplebus tree-walker while the >> relevant drivers get fixed up. >> -Nathan > > Thanks for the quick answer. Right know there seem to be zero device drivers > doing this. And there are quite a few fdts going from general (all devices on SOC) > to specific (devices usable on specific board), which use the status field > to disable a device (for example i.mx in general and wandboard specifically). > At least with the i.mx6 the unconnected sdhci devices lead to hangs during > boot. > That's disappointing. I think I'll probably add a hack while we repair any drivers like this. For the (near) future, according to the spec (ePAPR section 2.3.4), "disabled" means: "Indicates that the device is not presently operational, but it might become operational in the future (for example, something is not plugged in, or is switched off). Refer to the device binding for details on what 'disabled' means for a given device." So dropping them at probe time in the bus layer was clearly wrong and indeed breaks some hardware. It would be nice to have some survey of which drivers encounter this issue... -Nathan From owner-freebsd-arm@FreeBSD.ORG Sun Feb 2 18:14: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 AAFC2203; Sun, 2 Feb 2014 18:14:28 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 698121155; Sun, 2 Feb 2014 18:14:27 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s12IEKV1080773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Feb 2014 10:14:20 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s12IEKZi080772; Sun, 2 Feb 2014 10:14:20 -0800 (PST) (envelope-from jmg) Date: Sun, 2 Feb 2014 10:14:20 -0800 From: John-Mark Gurney To: Michael Tuexen Subject: Re: panic Message-ID: <20140202181420.GC93141@funkthat.com> Mail-Followup-To: Michael Tuexen , Andrew Turner , "freebsd-arm@freebsd.org" References: <14E59004-FC13-48DD-B789-AA78767C6871@freebsd.org> <20140202120509.5d1e0f64@bender.Home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 02 Feb 2014 10:14:20 -0800 (PST) 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: Sun, 02 Feb 2014 18:14:28 -0000 Michael Tuexen wrote this message on Sun, Feb 02, 2014 at 13:11 +0100: > On Feb 2, 2014, at 1:05 PM, Andrew Turner wrote: > > > On Fri, 31 Jan 2014 06:36:43 +0100 > > Michael Tuexen wrote: > > > >> Dear all, > >> > >> while building the or xcb-util-renderutil-0.3.8 port I got > >> panic: Undefined instruction in kernel. > >> when running r261186 on a RPI-B. I could successfully build > >> ports for cvs, subversion, git... > > > > Can you get the opcodes in your kernel around 0xc048ec60. There are two > > instructions that may be the problem and depending on which one you are > > hitting it would indicate a different problem. > > > > Also if possible can you get more of the kernel output from around the > > panic. There are a few kernel printf calls that would narrow down what > > is happening. > Hi Andrew, > > I'm sorry, I rebooted the pi in the meantime... As long as you didn't compile a new kernel, just do: objdump -d --start-address=0xc048ec50 /boot/kernel/kernel And send us the lines between 0xc048ec50 and 0xc048ec70... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sun Feb 2 18:26:56 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 627F438A for ; Sun, 2 Feb 2014 18:26:56 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC5EF11E4 for ; Sun, 2 Feb 2014 18:26:55 +0000 (UTC) Received: from [192.168.1.102] (p54819546.dip0.t-ipconnect.de [84.129.149.70]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 25BAB1C0E969C; Sun, 2 Feb 2014 19:26:53 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: panic From: Michael Tuexen In-Reply-To: <20140202181420.GC93141@funkthat.com> Date: Sun, 2 Feb 2014 19:26:52 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <14E59004-FC13-48DD-B789-AA78767C6871@freebsd.org> <20140202120509.5d1e0f64@bender.Home> <20140202181420.GC93141@funkthat.com> To: John-Mark Gurney 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: Sun, 02 Feb 2014 18:26:56 -0000 On Feb 2, 2014, at 7:14 PM, John-Mark Gurney wrote: > Michael Tuexen wrote this message on Sun, Feb 02, 2014 at 13:11 +0100: >> On Feb 2, 2014, at 1:05 PM, Andrew Turner wrote: >> >>> On Fri, 31 Jan 2014 06:36:43 +0100 >>> Michael Tuexen wrote: >>> >>>> Dear all, >>>> >>>> while building the or xcb-util-renderutil-0.3.8 port I got >>>> panic: Undefined instruction in kernel. >>>> when running r261186 on a RPI-B. I could successfully build >>>> ports for cvs, subversion, git... >>> >>> Can you get the opcodes in your kernel around 0xc048ec60. There are two >>> instructions that may be the problem and depending on which one you are >>> hitting it would indicate a different problem. >>> >>> Also if possible can you get more of the kernel output from around the >>> panic. There are a few kernel printf calls that would narrow down what >>> is happening. >> Hi Andrew, >> >> I'm sorry, I rebooted the pi in the meantime... > > As long as you didn't compile a new kernel, just do: > objdump -d --start-address=0xc048ec50 /boot/kernel/kernel > > And send us the lines between 0xc048ec50 and 0xc048ec70... Sure: /boot/kernel/kernel: file format elf32-littlearm Disassembly of section .text: c048ec50 : c048ec50: e1a01007 mov r1, r7 c048ec54: e1a02009 mov r2, r9 c048ec58: e1a03004 mov r3, r4 c048ec5c: e12fff35 blx r5 c048ec60: e3a01000 mov r1, #0 ; 0x0 c048ec64: e3500000 cmp r0, #0 ; 0x0 c048ec68: 0a000005 beq c048ec84 c048ec6c: e5966000 ldr r6, [r6] c048ec70: e3560000 cmp r6, #0 ; 0x0 Please let me know if you need any other information. Best regards Michael > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > From owner-freebsd-arm@FreeBSD.ORG Sun Feb 2 19:29:21 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 89FE4961; Sun, 2 Feb 2014 19:29:21 +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 58BAC1683; Sun, 2 Feb 2014 19:29:20 +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 1WA2jH-0008L8-JI; Sun, 02 Feb 2014 19:29:19 +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 s12JTG9C062297; Sun, 2 Feb 2014 12:29:16 -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: U2FsdGVkX19SMwrQh3XDvmZsHafXJrBb Subject: Re: status = "disabled" From: Ian Lepore To: Nathan Whitehorn In-Reply-To: <52EE6EA1.90707@freebsd.org> References: <726dc97ccd1f44b3ba9d7bee3eeff08a@e15be-01.zdv.Uni-Mainz.DE> <52EE622C.9010004@freebsd.org> <06235e983f8142fcb7f6f6c329a84b90@e15be-01.zdv.Uni-Mainz.DE> <52EE6EA1.90707@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" Date: Sun, 02 Feb 2014 12:29:16 -0700 Message-ID: <1391369356.13026.27.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s12JTG9C062297 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: Sun, 02 Feb 2014 19:29:21 -0000 On Sun, 2014-02-02 at 10:13 -0600, Nathan Whitehorn wrote: > On 02/02/14 09:59, Wei=DF, J=FCrgen wrote: > > > >> -----Original Message----- > >> From: Nathan Whitehorn [mailto:nwhitehorn@freebsd.org] > >> Sent: Sunday, February 02, 2014 4:20 PM > >> To: Wei=DF, J=FCrgen; freebsd-arm@freebsd.org > >> Subject: Re: status =3D "disabled" > >> > >> On 02/02/14 05:55, Wei=DF, J=FCrgen wrote: > >>> Hi, > >>> > >>> it seems your recent changes (261351) discarded a call to fdt_is_en= abled > >>> for devices on simplebus. So 'status =3D "disabled" ' does not work > >>> anymore in arm dts. > >>> > >>> Regards > >>> > >>> Juergen Weiss > >>> > >>> Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeit= ung, > >>> weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6= 131)39-26407 > >>> > >>> > >> That's actually required to make some hardware work ("disabled" may = just > >> mean the clock is turned off and needs to be turned back on, which m= eans > >> you absolutely do want that device probed). The device drivers > >> themselves, not the bus, should be checking this property and > >> interpreting it. If this has actually broken hardware, we could add = a > >> temporary #ifdef __arm__ check to the simplebus tree-walker while th= e > >> relevant drivers get fixed up. > >> -Nathan > > > > Thanks for the quick answer. Right know there seem to be zero device = drivers > > doing this. And there are quite a few fdts going from general (all de= vices on SOC) > > to specific (devices usable on specific board), which use the status = field > > to disable a device (for example i.mx in general and wandboard specif= ically). > > At least with the i.mx6 the unconnected sdhci devices lead to hangs d= uring > > boot. > > >=20 > That's disappointing. I think I'll probably add a hack while we repair=20 > any drivers like this. > For the (near) future, according to the spec (ePAPR section 2.3.4),=20 > "disabled" means: > "Indicates that the device is not presently operational, but it might=20 > become operational in the future (for example, something is not plugged= =20 > in, or is switched off). Refer to the device binding for details on wha= t=20 > 'disabled' means for a given device." > So dropping them at probe time in the bus layer was clearly wrong and=20 > indeed breaks some hardware. It would be nice to have some survey of=20 > which drivers encounter this issue... > -Nathan As of r261410 all the drivers that are children of simplebus now check their status properties for themselves. I've tested on wandboard, rpi, beaglebone white, and dreamplug and everything seems to be working. One side effect of all this is that you may see some new messages at boot, such as: simplebus1: mem 0x21e8000-0x21ebfff irq 59 type unknown= (no driver attached) simplebus1: mem 0x21ec000-0x21effff irq 60 type unknown= (no driver attached) These are not errors, that's just what a disabled device looks like now. I think they'll only show up if bootverbose is set. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Feb 2 19:31:53 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 DA0ACA01 for ; Sun, 2 Feb 2014 19:31:53 +0000 (UTC) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A240C16FF for ; Sun, 2 Feb 2014 19:31:53 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id j1so2890961iga.3 for ; Sun, 02 Feb 2014 11:31:46 -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=b/fLLpZbnCqFk7lDbqovYscDeTgrZOWazSUGKD+ITwU=; b=Tewi3IUWQCHVM59lfUE4h9DwBFn3MNd0h12Qh0+oJz4+PWneGC30T3sY6mSyOg0Szf dn6J8zZQZDcAa/e4eBSza8Ppkkx6MS8rhpwzA5NgK4XZYCtUJADtC5MdF6W0Vec2Bh4i yHw4/FYbkUsTbd0ryhkfRXSAor4PDiHbgYQ0Er+10yeUPNdbXjK+XZxejzH/b9Qfv4yR wfETa+qxrIEuUhF6l6FzsbtqY6hOXokjW3eA4vk7j1V7wuY2h+HVAJiF9fFrc8MhWaU2 uPxa1fsZ2JGl6f3eDYlw5rjBrXRKLQt+fXyMadRIGdfnCi3fl7cyFOMXYc0elmg1aVVC dWzw== X-Gm-Message-State: ALoCoQm6d88l5JSVj8+gFMO/bcgStr/Ax/4G0g1/V0YfZVf/uJ8kc1ky2lHSscDOk8PpxixakrNg X-Received: by 10.50.73.136 with SMTP id l8mr8817620igv.7.1391369506080; Sun, 02 Feb 2014 11:31:46 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ft2sm22263041igb.5.2014.02.02.11.31.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Feb 2014 11:31:45 -0800 (PST) Sender: Warner Losh Subject: Re: status = "disabled" Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Warner Losh In-Reply-To: <52EE622C.9010004@freebsd.org> Date: Sun, 2 Feb 2014 12:31:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <726dc97ccd1f44b3ba9d7bee3eeff08a@e15be-01.zdv.Uni-Mainz.DE> <52EE622C.9010004@freebsd.org> To: Nathan Whitehorn 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: Sun, 02 Feb 2014 19:31:53 -0000 On Feb 2, 2014, at 8:20 AM, Nathan Whitehorn wrote: > On 02/02/14 05:55, Wei=DF, J=FCrgen wrote: >>=20 >> it seems your recent changes (261351) discarded a call to = fdt_is_enabled >> for devices on simplebus. So 'status =3D "disabled" ' does not work >> anymore in arm dts. >>=20 > That's actually required to make some hardware work ("disabled" may = just mean the clock is turned off and needs to be turned back on, which = means you absolutely do want that device probed). The device drivers = themselves, not the bus, should be checking this property and = interpreting it. If this has actually broken hardware, we could add a = temporary #ifdef __arm__ check to the simplebus tree-walker while the = relevant drivers get fixed up. I suspect that it is going to be a cooperation between the bus and the = driver. Eg, we want them probed, and their resources allocated, but we = otherwise don't want the driver to interact with the hardware. So a = serial driver wouldn't create /dev/ttyUx nodes, a network driver = wouldn't try to attach an if_net, etc. Also, we need an interface, = eventually, that will allow us to turn them back on, but that can be = problematic since one of the resources the drivers use is hardware pins, = which are multiplexed with other drivers... Warner From owner-freebsd-arm@FreeBSD.ORG Sun Feb 2 19:35:47 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 E1770BAF for ; Sun, 2 Feb 2014 19:35:46 +0000 (UTC) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A813E1726 for ; Sun, 2 Feb 2014 19:35:46 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id m12so2928886iga.1 for ; Sun, 02 Feb 2014 11:35:40 -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=A1qUTgR2XStletTjMQNf1q8VyX4hhsJotnUeWex2EP4=; b=Ni+xww04c8BkxA8EJClQo8ur7x0EU7FJX3trNayyjbHI+SrefE3JMalfd//gdos2Ex Q6qNPa3aXB2HasJSj0dAeXkgdcyIrx5O3IO/PFnvhNrshHIK1OAyZeJQshhdjE7q8KZA lCzpNsFW9Ih4CIlLkwGWX2qcnM8oWHEdiro3/WdfTbQI/kkiQlKjPF1m8vad8pHumAd0 VIn8dGtocnk3OgDEKetoVCV03zMOlDSpXmhtwRTlk2zVM7A7PGZnGFgZY1dySLUtFnQQ c8WiO0nNySVqVuEG2NoO5XLr7dqguICdFay5gVpruOwwbNWle1jme7PprFuLdZsKoTNq RqXg== X-Gm-Message-State: ALoCoQlqoLN0H0IanvhoqvzlIvx8B18rUnTgk6RZQLlDz8gdBsuEaUuf3JIG5kX038OXE8h+t9fA X-Received: by 10.50.138.98 with SMTP id qp2mr8831554igb.27.1391369740099; Sun, 02 Feb 2014 11:35:40 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id y9sm22316649igl.0.2014.02.02.11.35.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Feb 2014 11:35:39 -0800 (PST) Sender: Warner Losh Subject: Re: status = "disabled" Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Warner Losh In-Reply-To: <52EE6EA1.90707@freebsd.org> Date: Sun, 2 Feb 2014 12:35:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4F893AE1-6B64-469D-AF3C-8AB2EB9D0ED9@bsdimp.com> References: <726dc97ccd1f44b3ba9d7bee3eeff08a@e15be-01.zdv.Uni-Mainz.DE> <52EE622C.9010004@freebsd.org> <06235e983f8142fcb7f6f6c329a84b90@e15be-01.zdv.Uni-Mainz.DE> <52EE6EA1.90707@freebsd.org> To: Nathan Whitehorn 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: Sun, 02 Feb 2014 19:35:47 -0000 On Feb 2, 2014, at 9:13 AM, Nathan Whitehorn wrote: > On 02/02/14 09:59, Wei=DF, J=FCrgen wrote: >>=20 >>> -----Original Message----- >>> From: Nathan Whitehorn [mailto:nwhitehorn@freebsd.org] >>> Sent: Sunday, February 02, 2014 4:20 PM >>> To: Wei=DF, J=FCrgen; freebsd-arm@freebsd.org >>> Subject: Re: status =3D "disabled" >>>=20 >>> On 02/02/14 05:55, Wei=DF, J=FCrgen wrote: >>>> Hi, >>>>=20 >>>> it seems your recent changes (261351) discarded a call to = fdt_is_enabled >>>> for devices on simplebus. So 'status =3D "disabled" ' does not work >>>> anymore in arm dts. >>>>=20 >>>> Regards >>>>=20 >>>> Juergen Weiss >>>>=20 >>>> Juergen Weiss |Universitaet Mainz, Zentrum fuer = Datenverarbeitung, >>>> weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: = +49(6131)39-26407 >>>>=20 >>>>=20 >>> That's actually required to make some hardware work ("disabled" may = just >>> mean the clock is turned off and needs to be turned back on, which = means >>> you absolutely do want that device probed). The device drivers >>> themselves, not the bus, should be checking this property and >>> interpreting it. If this has actually broken hardware, we could add = a >>> temporary #ifdef __arm__ check to the simplebus tree-walker while = the >>> relevant drivers get fixed up. >>> -Nathan >>=20 >> Thanks for the quick answer. Right know there seem to be zero device = drivers >> doing this. And there are quite a few fdts going from general (all = devices on SOC) >> to specific (devices usable on specific board), which use the status = field >> to disable a device (for example i.mx in general and wandboard = specifically). >> At least with the i.mx6 the unconnected sdhci devices lead to hangs = during >> boot. >>=20 >=20 > That's disappointing. I think I'll probably add a hack while we repair = any drivers like this. >=20 > For the (near) future, according to the spec (ePAPR section 2.3.4), = "disabled" means: > "Indicates that the device is not presently operational, but it might = become operational in the future (for example, something is not plugged = in, or is switched off). Refer to the device binding for details on what = 'disabled' means for a given device." > So dropping them at probe time in the bus layer was clearly wrong and = indeed breaks some hardware. It would be nice to have some survey of = which drivers encounter this issue... In the yet-to-be-committed Atmel code, disabled is used to mark those = devices that can't work because their pins are not brought out to = headers, or they are, but they are internally multiplexed to something = else... The reason no drivers do this is because of the check to see if they = were enabled in the bus layer, which is now gone... That check was = wrong, but this isn't a surprising turn of events... Warner From owner-freebsd-arm@FreeBSD.ORG Sun Feb 2 20:00: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 460821E8 for ; Sun, 2 Feb 2014 20:00:12 +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 999D718E9 for ; Sun, 2 Feb 2014 20:00:11 +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 1WA3D6-00048R-Po; Sun, 02 Feb 2014 20:00:09 +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 s12K047r062327; Sun, 2 Feb 2014 13:00:04 -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: U2FsdGVkX18OIrQGJ1nbdEBMFS8lyUcy Subject: wandboard / imx6 / exynos4 / cortex-a9 "wrong-endian bug" fixed From: Ian Lepore To: freebsd-arm Content-Type: text/plain; charset="us-ascii" Date: Sun, 02 Feb 2014 13:00:04 -0700 Message-ID: <1391371204.13026.43.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Bernd Walter 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: Sun, 02 Feb 2014 20:00:12 -0000 As some of you know from previous email or irc conversations, I've been chasing a strange bug for months that affects some cortex-a9 chips, which I've been calling the "wrong-endian bug", where some registers get restored with wrong-endian values on return from an interrupt, leading to a panic or crash during boot. I finally tracked the cause down to our gnu assembler (gas), which apparently thinks that when you say "msr spsr_all, r0" what you meant by "_all" was "only restore 16 of the 32 bits". It's not a bug per se, it's just how the gas authors think the assembler should behave. So, when the chip powers on there may be some garbage bits in the spsr register, and they would never get cleared out because only some of the bits would get restored, and if the big-endian bit was among them Bad Things Happened. I'm not sure why this only affected some cortex-a9 chips such as imx6, but maybe some chips set those registers to zero and some don't at power-on. I fixed the problem by updating our source code to use the newer arm instruction syntax for msr and msr instructions, which ensures all 32 bits get restored. That change happened in r261393, but because of other changes and churn in the tree the first really stable revision that includes the fix is r261410. So if you're working with wandboard or another imx6-based system, please make sure to update to this rev. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Feb 2 20:55:55 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 54A0EFC2 for ; Sun, 2 Feb 2014 20:55:55 +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 28C3D1DAA for ; Sun, 2 Feb 2014 20:55:54 +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 1WA453-0004JD-ON; Sun, 02 Feb 2014 20:55: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 s12Kto92062347; Sun, 2 Feb 2014 13:55: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+5wYLUtgAixtHt/UryjHUd Subject: Re: Utilite Freescale i.MX6 support From: Ian Lepore To: Pete Wright In-Reply-To: <52E94AE3.5080404@nomadlogic.org> References: <52E94AE3.5080404@nomadlogic.org> Content-Type: text/plain; charset="us-ascii" Date: Sun, 02 Feb 2014 13:55:50 -0700 Message-ID: <1391374550.13026.60.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: Sun, 02 Feb 2014 20:55:55 -0000 On Wed, 2014-01-29 at 10:39 -0800, Pete Wright wrote: > Hello, > I have recently purchase this device and am interested in trying to get > FreeBSD running on it: > > http://utilite-computer.com/web/utilite-models > > I currently have the system booting fine with the provided Debian image > they ship with these system. At the end of this message is the output > of dmesg from linux-land. > > Helpful documentation is also available here: > http://utilite-computer.com/download/documentation//utilite/utilite-technical-reference-manual.pdf > > From what I can tell Utilite has done a good job at being open about > their spec's and components. Hopefully this will help get it ported. I > am personally excited about the dual Intel GBE NIC's on this system and > would love to test this box out as an embedded router/firewall/nat device. > > Is there a good reference I can start from for this chipset? I am not > %100 clear on which guide I should be following. > > Thanks in advance! > -pete > > > > [snipped] > I'm sorry it has taken me so long to reply to this. Until today my reply would have had to been basically "freebsd will only kinda-sorta run on that box," and every day I've been hoping to fix the show-stopping bug and have something better to report. As of today (r261410) the infamous wrong-endian bug is fixed and I think you won't have too much trouble getting freebsd running on that unit. There is, however, still some work to do. Right now we have i.MX6 drivers for uart, sdcard, usb, and the on-chip ethernet. We do not yet have imx6 drivers for AHCI/SATA, PCIe, or any audio/video hardware. I'm not sure about the wifi. The AHCI and PCIe shouldn't be too hard, since both are standards and we have standard drivers that probably just need some glue code written. Our current AHCI driver needs to be refactored a bit to strip out the assumption that the AHCI controller lives on a PCI bus. While the Intel NIC won't work until we have a PCIe driver, the onboard GbE will work right now. We don't have SMP working yet; it's probably the next major area I'm going to work on for imx6. Freebsd will boot on a dual or quad core imx6 chip, but only one core will run right now. It shouldn't take too long, others have got it working with some degree of success, I just haven't caught up yet. To get started, you should probably start with the Wandboard dts files and kernel config. One thing that jumps out at me is that the Utilite uses uart ports 2 and 4, so to have a serial console for debugging you'll need to change the dts source to enable uart2 and select it as the console in the choosen {...} block. Unfortunately, because it's Compulab, you'll probably have to buy their overpriced serial cable with the weird connector on it (they do the same thing on the FitPc2). -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Feb 2 22:05:53 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 3F6E0F6C for ; Sun, 2 Feb 2014 22:05:53 +0000 (UTC) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 043B4143B for ; Sun, 2 Feb 2014 22:05:52 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id vb8so7204379obc.32 for ; Sun, 02 Feb 2014 14:05:46 -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:date :message-id:subject:from:to:cc:content-type; bh=8YHzVAi+2NbqlgEF+8EnS6Yr+yhSxdZ+dVxyTA8LbCk=; b=L/5Qi/1Mh9q6rMtbCnfMoVpKiNz2IlPRxSVyCaR2AlWPLn1qoYaAp9ajMHaGs7+/l0 fzgTlbdtbkrPL8QTC50L5ebvnuh37pg9yGpb+as/n/QiBrJznXPOEcbR/6IWWOmJjy/t LBdUdshM/DGypDtoq8x7RadKf03GnPqSD1733B0iC1CHBtwSUAWRs1EBfnelbgJnL2vq cJmWz9lIp1s/Q4BJKYIyHJZuTvBe7ZFFax6l2liMYMQljBL7/gZgY+2WL9+KvDYX66V7 e0qrlK1a5jeEKMoL3D9Y4O49Kw4h6mY7/ncyTsXp+yUskyPSmUwx2pPb7W0p1H9Yajr4 LhQA== X-Gm-Message-State: ALoCoQnZCbIpIREoglTQQ/W/AbExa3e8ViiDeZ1xnwJrKRL+ZJSBfVUlsAodx+BqQMFCWRckzDi9 MIME-Version: 1.0 X-Received: by 10.60.150.134 with SMTP id ui6mr85280oeb.62.1391377300604; Sun, 02 Feb 2014 13:41:40 -0800 (PST) Received: by 10.182.104.169 with HTTP; Sun, 2 Feb 2014 13:41:40 -0800 (PST) In-Reply-To: <1391371204.13026.43.camel@revolution.hippie.lan> References: <1391371204.13026.43.camel@revolution.hippie.lan> Date: Sun, 2 Feb 2014 14:41:40 -0700 Message-ID: Subject: Re: wandboard / imx6 / exynos4 / cortex-a9 "wrong-endian bug" fixed From: Tom Everett To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm , Bernd Walter 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: Sun, 02 Feb 2014 22:05:53 -0000 This has been a problem on Wandboard for a long time. Congrats on the fix! On Sun, Feb 2, 2014 at 1:00 PM, Ian Lepore wrote: > As some of you know from previous email or irc conversations, I've been > chasing a strange bug for months that affects some cortex-a9 chips, > which I've been calling the "wrong-endian bug", where some registers get > restored with wrong-endian values on return from an interrupt, leading > to a panic or crash during boot. > > I finally tracked the cause down to our gnu assembler (gas), which > apparently thinks that when you say "msr spsr_all, r0" what you meant by > "_all" was "only restore 16 of the 32 bits". It's not a bug per se, > it's just how the gas authors think the assembler should behave. So, > when the chip powers on there may be some garbage bits in the spsr > register, and they would never get cleared out because only some of the > bits would get restored, and if the big-endian bit was among them Bad > Things Happened. I'm not sure why this only affected some cortex-a9 > chips such as imx6, but maybe some chips set those registers to zero and > some don't at power-on. > > I fixed the problem by updating our source code to use the newer arm > instruction syntax for msr and msr instructions, which ensures all 32 > bits get restored. That change happened in r261393, but because of > other changes and churn in the tree the first really stable revision > that includes the fix is r261410. So if you're working with wandboard > or another imx6-based system, please make sure to update to this rev. > > -- Ian > > > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Sun Feb 2 23:30:53 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 6BC4BBE; Sun, 2 Feb 2014 23:30:53 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E8A471107; Sun, 2 Feb 2014 23:30:52 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s12N52Y7020540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Feb 2014 00:05:03 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id s12N4o3F078106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Feb 2014 00:04:50 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id s12N4o4A042392; Mon, 3 Feb 2014 00:04:50 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s12N4o2j042391; Mon, 3 Feb 2014 00:04:50 +0100 (CET) (envelope-from ticso) Date: Mon, 3 Feb 2014 00:04:50 +0100 From: Bernd Walter To: Ian Lepore Subject: Re: wandboard / imx6 / exynos4 / cortex-a9 "wrong-endian bug" fixed Message-ID: <20140202230450.GA42331@cicely7.cicely.de> References: <1391371204.13026.43.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1391371204.13026.43.camel@revolution.hippie.lan> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm , Bernd Walter X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 23:30:53 -0000 On Sun, Feb 02, 2014 at 01:00:04PM -0700, Ian Lepore wrote: > As some of you know from previous email or irc conversations, I've been > chasing a strange bug for months that affects some cortex-a9 chips, > which I've been calling the "wrong-endian bug", where some registers get > restored with wrong-endian values on return from an interrupt, leading > to a panic or crash during boot. This is very great news and a pretty amazing job to find this. Thank you very much! In the end it also exaplains the tempeerature dependency on the Wandboards and why it always happened on my MarSboard. Unfortunately I'm still time contrained, but likely I will at least find enough time to do some tests on my iMX6 board collection next weekend. I'm especially curious about the MarSboard, which never booted without the panic. > I finally tracked the cause down to our gnu assembler (gas), which > apparently thinks that when you say "msr spsr_all, r0" what you meant by > "_all" was "only restore 16 of the 32 bits". It's not a bug per se, > it's just how the gas authors think the assembler should behave. So, > when the chip powers on there may be some garbage bits in the spsr > register, and they would never get cleared out because only some of the > bits would get restored, and if the big-endian bit was among them Bad > Things Happened. I'm not sure why this only affected some cortex-a9 > chips such as imx6, but maybe some chips set those registers to zero and > some don't at power-on. > > I fixed the problem by updating our source code to use the newer arm > instruction syntax for msr and msr instructions, which ensures all 32 > bits get restored. That change happened in r261393, but because of > other changes and churn in the tree the first really stable revision > that includes the fix is r261410. So if you're working with wandboard > or another imx6-based system, please make sure to update to this rev. > > -- Ian > > -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon Feb 3 01:25:44 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 3C54B80D for ; Mon, 3 Feb 2014 01:25:44 +0000 (UTC) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F419819CC for ; Mon, 3 Feb 2014 01:25:43 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id i7so7471970oag.36 for ; Sun, 02 Feb 2014 17:25:36 -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:date :message-id:subject:from:to:cc:content-type; bh=qhahAY0YgwD/aOTT7w6e9mr4zSFjg7c0vV4VYWGDPMI=; b=nBe+D04ZvQOtUZ37adtqtnC3aljohhM1b7rpB6QfdX4hlAdJheST/TMqAFn5hDOeMr 1kWTqIZN/eaQF2mXwUqR2Rmfzly3x2vyV6VyUpWTJPPKlPVYjnE/iKwlG42qTMEBEl2u tRr3IfBe4Dp/3Z6aBmFcFHhkgVEUVC0YExeg/4BKzZV6uwBgu3OuajXTtAEUe4owuZQU Ni4u+/KoCSiXApsnJl4VPNGcHPhriWeKJ5i9fRh2P3tAvuARB8fLggB8svLecFNn+NmP ay6RmXQld3x3YRRyMyzhw1M/KJ2QHAJglDlZzaea9/ManjEU929ovzWbvCcT9BqX6cnP NClw== X-Gm-Message-State: ALoCoQl10nikudSPF5NDVvTBvPX0G48w6K3VUxCyYnayYBqx/aIbkjxRJyqOCtwFQQI7ELiA+4zA MIME-Version: 1.0 X-Received: by 10.183.3.102 with SMTP id bv6mr28063143obd.18.1391390736110; Sun, 02 Feb 2014 17:25:36 -0800 (PST) Received: by 10.182.104.169 with HTTP; Sun, 2 Feb 2014 17:25:36 -0800 (PST) In-Reply-To: <20140202230450.GA42331@cicely7.cicely.de> References: <1391371204.13026.43.camel@revolution.hippie.lan> <20140202230450.GA42331@cicely7.cicely.de> Date: Sun, 2 Feb 2014 18:25:36 -0700 Message-ID: Subject: Re: wandboard / imx6 / exynos4 / cortex-a9 "wrong-endian bug" fixed From: Tom Everett To: ticso@cicely.de Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm , Bernd Walter , Ian Lepore 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: Mon, 03 Feb 2014 01:25:44 -0000 I can confirm that a crochet image for Wandboard no longer crashes after this fix. It doesn't mount the FS yet, but that's a known issue, noted here: https://github.com/kientzle/crochet-freebsd/issues/29 Boot log is here: http://files.khubla.com/freebsd-wandboard/wandboard.txt On Sun, Feb 2, 2014 at 4:04 PM, Bernd Walter wrote: > On Sun, Feb 02, 2014 at 01:00:04PM -0700, Ian Lepore wrote: > > As some of you know from previous email or irc conversations, I've been > > chasing a strange bug for months that affects some cortex-a9 chips, > > which I've been calling the "wrong-endian bug", where some registers get > > restored with wrong-endian values on return from an interrupt, leading > > to a panic or crash during boot. > > This is very great news and a pretty amazing job to find this. > Thank you very much! > In the end it also exaplains the tempeerature dependency on the > Wandboards and why it always happened on my MarSboard. > Unfortunately I'm still time contrained, but likely I will at least > find enough time to do some tests on my iMX6 board collection next > weekend. > I'm especially curious about the MarSboard, which never booted without > the panic. > > > I finally tracked the cause down to our gnu assembler (gas), which > > apparently thinks that when you say "msr spsr_all, r0" what you meant by > > "_all" was "only restore 16 of the 32 bits". It's not a bug per se, > > it's just how the gas authors think the assembler should behave. So, > > when the chip powers on there may be some garbage bits in the spsr > > register, and they would never get cleared out because only some of the > > bits would get restored, and if the big-endian bit was among them Bad > > Things Happened. I'm not sure why this only affected some cortex-a9 > > chips such as imx6, but maybe some chips set those registers to zero and > > some don't at power-on. > > > > I fixed the problem by updating our source code to use the newer arm > > instruction syntax for msr and msr instructions, which ensures all 32 > > bits get restored. That change happened in r261393, but because of > > other changes and churn in the tree the first really stable revision > > that includes the fix is r261410. So if you're working with wandboard > > or another imx6-based system, please make sure to update to this rev. > > > > -- Ian > > > > > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Mon Feb 3 02:30:55 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 7F4663B2; Mon, 3 Feb 2014 02:30:55 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 24ED11F3B; Mon, 3 Feb 2014 02:30:54 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s132Ukof022272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Feb 2014 03:30:46 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id s132UZce084695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Feb 2014 03:30:35 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id s132UZjG043775; Mon, 3 Feb 2014 03:30:35 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s132UY9V043774; Mon, 3 Feb 2014 03:30:34 +0100 (CET) (envelope-from ticso) Date: Mon, 3 Feb 2014 03:30:34 +0100 From: Bernd Walter To: Ian Lepore Subject: Re: Utilite Freescale i.MX6 support Message-ID: <20140203023034.GA43721@cicely7.cicely.de> References: <52E94AE3.5080404@nomadlogic.org> <1391374550.13026.60.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1391374550.13026.60.camel@revolution.hippie.lan> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 02:30:55 -0000 On Sun, Feb 02, 2014 at 01:55:50PM -0700, Ian Lepore wrote: > On Wed, 2014-01-29 at 10:39 -0800, Pete Wright wrote: > > Hello, > > I have recently purchase this device and am interested in trying to get > > FreeBSD running on it: > > > > http://utilite-computer.com/web/utilite-models > > > > I currently have the system booting fine with the provided Debian image > > they ship with these system. At the end of this message is the output > > of dmesg from linux-land. > > > > Helpful documentation is also available here: > > http://utilite-computer.com/download/documentation//utilite/utilite-technical-reference-manual.pdf > > > > From what I can tell Utilite has done a good job at being open about > > their spec's and components. Hopefully this will help get it ported. I > > am personally excited about the dual Intel GBE NIC's on this system and > > would love to test this box out as an embedded router/firewall/nat device. > > > > Is there a good reference I can start from for this chipset? I am not > > %100 clear on which guide I should be following. > > > > Thanks in advance! > > -pete > > > > > > > > [snipped] > > > > I'm sorry it has taken me so long to reply to this. Until today my > reply would have had to been basically "freebsd will only kinda-sorta > run on that box," and every day I've been hoping to fix the > show-stopping bug and have something better to report. As of today > (r261410) the infamous wrong-endian bug is fixed and I think you won't > have too much trouble getting freebsd running on that unit. > > There is, however, still some work to do. Right now we have i.MX6 > drivers for uart, sdcard, usb, and the on-chip ethernet. We do not yet > have imx6 drivers for AHCI/SATA, PCIe, or any audio/video hardware. I'm > not sure about the wifi. The AHCI and PCIe shouldn't be too hard, since > both are standards and we have standard drivers that probably just need > some glue code written. Our current AHCI driver needs to be refactored > a bit to strip out the assumption that the AHCI controller lives on a > PCI bus. While the Intel NIC won't work until we have a PCIe driver, > the onboard GbE will work right now. According to the block diagram it is same as with the wandboard in that the wifi is connected via SDIO to one of the SDMMC controllers, of which the iMX6 has 4 alltogether. AFAIK there is some SDIO support in progress or even exists, but don't know about SDIO-wifi so far. > We don't have SMP working yet; it's probably the next major area I'm > going to work on for imx6. Freebsd will boot on a dual or quad core > imx6 chip, but only one core will run right now. It shouldn't take too > long, others have got it working with some degree of success, I just > haven't caught up yet. > > To get started, you should probably start with the Wandboard dts files > and kernel config. One thing that jumps out at me is that the Utilite > uses uart ports 2 and 4, so to have a serial console for debugging > you'll need to change the dts source to enable uart2 and select it as > the console in the choosen {...} block. Unfortunately, because it's > Compulab, you'll probably have to buy their overpriced serial cable with > the weird connector on it (they do the same thing on the FitPc2). -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Mon Feb 3 02:37:54 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 B8391540 for ; Mon, 3 Feb 2014 02:37:54 +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 729F81FCE for ; Mon, 3 Feb 2014 02:37:53 +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 1WA9Pu-000CKb-35; Mon, 03 Feb 2014 02:37:46 +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 s132bgqR062512; Sun, 2 Feb 2014 19:37:42 -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/rZd+ZpmhHM19JAiS/6T0g Subject: Re: wandboard / imx6 / exynos4 / cortex-a9 "wrong-endian bug" fixed From: Ian Lepore To: Tom Everett In-Reply-To: References: <1391371204.13026.43.camel@revolution.hippie.lan> <20140202230450.GA42331@cicely7.cicely.de> Content-Type: multipart/mixed; boundary="=-N6KpUAYlO/lXDkjp/owK" Date: Sun, 02 Feb 2014 19:37:42 -0700 Message-ID: <1391395062.13026.69.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arm , Bernd Walter , ticso@cicely.de 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: Mon, 03 Feb 2014 02:37:54 -0000 --=-N6KpUAYlO/lXDkjp/owK Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sun, 2014-02-02 at 18:25 -0700, Tom Everett wrote: > I can confirm that a crochet image for Wandboard no longer crashes after > this fix. It doesn't mount the FS yet, but that's a known issue, noted > here: > > https://github.com/kientzle/crochet-freebsd/issues/29 That thread mentions needing to build a u-boot for wandboard. Here's a patchset for doing that. Apply this in your ports/sysutils dir, using: patch -p0 diff --recursive -Nu u-boot-wandboard.orig/distinfo u-boot-wandboard/distinfo --- u-boot-wandboard.orig/distinfo 1969-12-31 17:00:00.000000000 -0700 +++ u-boot-wandboard/distinfo 2013-08-01 11:06:33.000000000 -0600 @@ -0,0 +1,2 @@ +SHA256 (u-boot-2013.04.tar.bz2) = 4150e5a4480707c55a8d5b4570262e43af68d8ed3bdc0a433d8e7df47989a69e +SIZE (u-boot-2013.04.tar.bz2) = 9837387 diff --recursive -Nu u-boot-wandboard.orig/files/patch-api_Makefile u-boot-wandboard/files/patch-api_Makefile --- u-boot-wandboard.orig/files/patch-api_Makefile 1969-12-31 17:00:00.000000000 -0700 +++ u-boot-wandboard/files/patch-api_Makefile 2013-08-01 11:06:49.000000000 -0600 @@ -0,0 +1,11 @@ +--- api/Makefile.orig 2013-04-19 09:25:43.000000000 -0500 ++++ api/Makefile 2013-05-16 17:14:54.000000000 -0500 +@@ -24,7 +24,7 @@ + + LIB = $(obj)libapi.o + +-COBJS-$(CONFIG_API) += api.o api_display.o api_net.o api_storage.o \ ++COBJS-$(CONFIG_API) += api.o api_display.o api_storage.o \ + api_platform-$(ARCH).o + + COBJS := $(COBJS-y) diff --recursive -Nu u-boot-wandboard.orig/files/patch-examples_api_Makefile u-boot-wandboard/files/patch-examples_api_Makefile --- u-boot-wandboard.orig/files/patch-examples_api_Makefile 1969-12-31 17:00:00.000000000 -0700 +++ u-boot-wandboard/files/patch-examples_api_Makefile 2013-08-01 11:06:49.000000000 -0600 @@ -0,0 +1,11 @@ +--- examples/api/Makefile.orig 2013-04-19 09:25:43.000000000 -0500 ++++ examples/api/Makefile 2013-05-16 17:05:38.000000000 -0500 +@@ -69,7 +69,7 @@ + ######################################################################### + + $(OUTPUT): $(OBJS) +- $(LD) -Ttext $(LOAD_ADDR) -o $@ $^ $(PLATFORM_LIBS) ++ $(LD) -static -Ttext $(LOAD_ADDR) -o $@ $^ $(PLATFORM_LIBS) + $(OBJCOPY) -O binary $@ $(OUTPUT).bin 2>/dev/null + + # Rule to build generic library C files diff --recursive -Nu u-boot-wandboard.orig/files/patch-include_configs_wandboard.h u-boot-wandboard/files/patch-include_configs_wandboard.h --- u-boot-wandboard.orig/files/patch-include_configs_wandboard.h 1969-12-31 17:00:00.000000000 -0700 +++ u-boot-wandboard/files/patch-include_configs_wandboard.h 2013-09-19 11:20:36.000000000 -0600 @@ -0,0 +1,30 @@ +--- include/configs/wandboard.h.orig 2013-08-01 12:41:56.000000000 -0600 ++++ include/configs/wandboard.h 2013-08-01 12:56:25.000000000 -0600 +@@ -47,6 +47,9 @@ + + #undef CONFIG_CMD_IMLS + ++#define CONFIG_CMD_ELF ++#define CONFIG_SYS_MMC_MAX_DEVICE 2 ++ + #define CONFIG_BOOTDELAY 5 + + #define CONFIG_SYS_MEMTEST_START 0x10000000 +@@ -54,6 +56,16 @@ + #define CONFIG_LOADADDR 0x12000000 + #define CONFIG_SYS_TEXT_BASE 0x17800000 + ++/* USB Configs */ ++#define CONFIG_CMD_USB ++#define CONFIG_CMD_FAT ++#define CONFIG_USB_EHCI ++#define CONFIG_USB_EHCI_MX6 ++#define CONFIG_USB_STORAGE ++#define CONFIG_MXC_USB_PORT 1 ++#define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW) ++#define CONFIG_MXC_USB_FLAGS 0 ++ + /* MMC Configuration */ + #define CONFIG_FSL_ESDHC + #define CONFIG_FSL_USDHC + diff --recursive -Nu u-boot-wandboard.orig/pkg-descr u-boot-wandboard/pkg-descr --- u-boot-wandboard.orig/pkg-descr 1969-12-31 17:00:00.000000000 -0700 +++ u-boot-wandboard/pkg-descr 2013-08-01 11:06:33.000000000 -0600 @@ -0,0 +1,18 @@ +U-Boot loader for BeagleBone and BeagleBone Black. + +This version is patched so that: + * ELF and API features are enabled + * U-Boot binary is called BB-UBOOT.IMG + * It loads env from BB-UENV.TXT (an empty file suffices) + * It loads BBONE.DTB if running on an older (white) BeagleBone, + or BBONEBLK.DTB if running on a BeagleBone Black + * By default, it loads ELF ubldr from file BBUBLDR to address 0x88000000 + +Note: prefixing the boot files with 'BB' allows building +images with boot bits for more than one board. + +For information about running FreeBSD on BeagleBone or BeagleBone Black, see + https://wiki.freebsd.org/FreeBSD/arm/BeagleBone + +For general information about U-Boot, see +WWW: http://www.denx.de/wiki/U-Boot --=-N6KpUAYlO/lXDkjp/owK-- From owner-freebsd-arm@FreeBSD.ORG Mon Feb 3 02:41:29 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 1F2D0597 for ; Mon, 3 Feb 2014 02:41:29 +0000 (UTC) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D65D61067 for ; Mon, 3 Feb 2014 02:41:28 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id g12so7604205oah.31 for ; Sun, 02 Feb 2014 18:41:27 -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:date :message-id:subject:from:to:cc:content-type; bh=lXSF7sFcVq8ZSMy11ZHI5r7SZHXqaYOnOBsUZxBcHzc=; b=F48GkXgKauApMzYFVp8ZXMrWDnWKiqG/ny66T7kCSH0LzLxVcuVTUxc8qUEk5rP5fw cciax9MsGb81qbFSbleQ+sLH4TSTEjmaEN9zBhw69K0aUi5evoPkA5zOl6GMLpXrXU6s f4ddHWVJQVpeBiD3/qBIxjhwPEKOUBziOE4Q6COYnBnab8sqNBRoJzJpjVbuK/Jg9ak8 C5Q8v28UuHmnKSpuTNgV/EnVp38SeJB8cY4qAzXItg7NjIFLtrro1aA7/GkIAX4dZ1xz DUPLNuMHbJgpoKRs36eKK6K8ygDGKLcbbsh4e0MBFDpowtfx5YjGUYeMeaD6frfnxhnb XZMA== X-Gm-Message-State: ALoCoQn82Vh7QUT0vap5fwifqQDN/FYJWdHdFbh3PTLu3FfTDJtUTQV0CilvNghv9DyumlzFIiP1 MIME-Version: 1.0 X-Received: by 10.60.246.104 with SMTP id xv8mr28292616oec.18.1391395287509; Sun, 02 Feb 2014 18:41:27 -0800 (PST) Received: by 10.182.104.169 with HTTP; Sun, 2 Feb 2014 18:41:27 -0800 (PST) In-Reply-To: <1391395062.13026.69.camel@revolution.hippie.lan> References: <1391371204.13026.43.camel@revolution.hippie.lan> <20140202230450.GA42331@cicely7.cicely.de> <1391395062.13026.69.camel@revolution.hippie.lan> Date: Sun, 2 Feb 2014 19:41:27 -0700 Message-ID: Subject: Re: wandboard / imx6 / exynos4 / cortex-a9 "wrong-endian bug" fixed From: Tom Everett To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm , Bernd Walter , ticso@cicely.de 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: Mon, 03 Feb 2014 02:41:29 -0000 I've got u-boot working for Wandboard using these patches: https://github.com/kientzle/crochet-freebsd/tree/master/board/WandboardQuad/files On Sun, Feb 2, 2014 at 7:37 PM, Ian Lepore wrote: > On Sun, 2014-02-02 at 18:25 -0700, Tom Everett wrote: > > I can confirm that a crochet image for Wandboard no longer crashes after > > this fix. It doesn't mount the FS yet, but that's a known issue, noted > > here: > > > > https://github.com/kientzle/crochet-freebsd/issues/29 > > That thread mentions needing to build a u-boot for wandboard. Here's a > patchset for doing that. Apply this in your ports/sysutils dir, using: > > patch -p0 > This was copied from Tim's beaglebone work and changed a bit for > wandboard. > > I've been meaning to ask about how we should handle this. Do we want a > u-boot port for every board, or is there some way to parameterize a > single port so that it applies the right set of patches, or what? I'm > not very savvy about ports. > > -- Ian > > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Mon Feb 3 02:54:43 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 C0CFE841 for ; Mon, 3 Feb 2014 02:54:43 +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 9082510F6 for ; Mon, 3 Feb 2014 02:54:43 +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 1WA9gH-000Jpt-Jm; Mon, 03 Feb 2014 02:54:41 +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 s132sb2N062527; Sun, 2 Feb 2014 19:54:37 -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/4zDIbkPBwRv2Rly6Y7GTb Subject: Re: wandboard / imx6 / exynos4 / cortex-a9 "wrong-endian bug" fixed From: Ian Lepore To: Tom Everett In-Reply-To: References: <1391371204.13026.43.camel@revolution.hippie.lan> <20140202230450.GA42331@cicely7.cicely.de> Content-Type: text/plain; charset="us-ascii" Date: Sun, 02 Feb 2014 19:54:37 -0700 Message-ID: <1391396077.13026.72.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 , Bernd Walter , ticso@cicely.de 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: Mon, 03 Feb 2014 02:54:43 -0000 On Sun, 2014-02-02 at 18:25 -0700, Tom Everett wrote: > I can confirm that a crochet image for Wandboard no longer crashes after > this fix. It doesn't mount the FS yet, but that's a known issue, noted > here: > > https://github.com/kientzle/crochet-freebsd/issues/29 > > Boot log is here: > > http://files.khubla.com/freebsd-wandboard/wandboard.txt The sdcard rootfs problem is my bad. I use an NFS root and I've been so focused on the wrong-endian bug that I haven't tested with an sdcard for months. It turns out I forgot a checkin when I added the basic imx6 support; I just commited it as r261423. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Feb 3 02:59:39 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 29F40A8A for ; Mon, 3 Feb 2014 02:59:39 +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 E38761113 for ; Mon, 3 Feb 2014 02:59:38 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id j1so3395192iga.2 for ; Sun, 02 Feb 2014 18:59:37 -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=+yk9YzY1ekJBWfJ/P9hPpnJYmQA43GWyfdZpUzE8Exg=; b=Nn31Uvans1Q1qIuvg/epdasEMV7UWrOG0wqGi5CTycKHnB+Hgw6/vo0Xt4dQ8P53hE rMopn1+iQ5IELkeq9UyD9K39w0t7wD8mnAsRnoALTKWt5I2p/Oot1bso5sz3raFqWi/c BMXIe2QTObGGyGHKVVN3n+kkn7XlXhNdo4Tcung0E+ciaWjJEF/yorA2qG2IdWaAJ3/i 3UrtoZDGQwIwlbVGPQfAPYYpfxplTBc8o8BdarL3AEtZcC0KCXhb0EvlwHZl9bfAVyJe xyOzLrroPBWQIyOQnkl3LYv57CK39WDff7wNY7dBckVnnxFIkfwvv/qDvYQhLHvmfexw r3LA== X-Gm-Message-State: ALoCoQnXA+p3+1M3Bab3sDFp2+9Ii3j7fmn3+kQO1L8GywNOvVG5Qn2UIvVUtSH8UUmCqvRQ3+oS X-Received: by 10.42.227.195 with SMTP id jb3mr24925029icb.27.1391396377796; Sun, 02 Feb 2014 18:59:37 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id x13sm25932716igp.2.2014.02.02.18.59.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Feb 2014 18:59:37 -0800 (PST) Sender: Warner Losh Subject: Re: wandboard / imx6 / exynos4 / cortex-a9 "wrong-endian bug" fixed Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1391395062.13026.69.camel@revolution.hippie.lan> Date: Sun, 2 Feb 2014 19:59:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1584FD9C-581F-4BCF-8153-E381693887DB@bsdimp.com> References: <1391371204.13026.43.camel@revolution.hippie.lan> <20140202230450.GA42331@cicely7.cicely.de> <1391395062.13026.69.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) Cc: Bernd Walter , freebsd-arm , ticso@cicely.de 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: Mon, 03 Feb 2014 02:59:39 -0000 On Feb 2, 2014, at 7:37 PM, Ian Lepore wrote: > On Sun, 2014-02-02 at 18:25 -0700, Tom Everett wrote: >> I can confirm that a crochet image for Wandboard no longer crashes = after >> this fix. It doesn't mount the FS yet, but that's a known issue, = noted >> here: >>=20 >> https://github.com/kientzle/crochet-freebsd/issues/29 >=20 > That thread mentions needing to build a u-boot for wandboard. Here's = a > patchset for doing that. Apply this in your ports/sysutils dir, = using: >=20 > patch -p0 =20 > This was copied from Tim's beaglebone work and changed a bit for > wandboard. =20 >=20 > I've been meaning to ask about how we should handle this. Do we want = a > u-boot port for every board, or is there some way to parameterize a > single port so that it applies the right set of patches, or what? I'm > not very savvy about ports. Usually there's a master port, and slave ports that parameterize. When = we talked about this at BSDcan, I believe that was the model that was = suggested for this problem.. Warner From owner-freebsd-arm@FreeBSD.ORG Mon Feb 3 03:10: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 DE364F12 for ; Mon, 3 Feb 2014 03:10:50 +0000 (UTC) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9CEDB13AB for ; Mon, 3 Feb 2014 03:10:50 +0000 (UTC) Received: by mail-oa0-f47.google.com with SMTP id m1so7579599oag.34 for ; Sun, 02 Feb 2014 19:10:49 -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:date :message-id:subject:from:to:cc:content-type; bh=Rhzcbp7/AuHswgsPN6/r1AidC8sNWPSvGO+bfEJmb68=; b=RoLlQVKd4q2PBnjJcayRGTrbIYfMahjgFVDodv5lM2mZm09qhe7BI2u8aEJ0whSmKh owAjgObyGF2amvAaFlf+VLHETxwCDldz8QCVueFyGBZ0LN3wMdUo6TAa/02o93Odua89 XUFR0CfeNWgBP3oyFIz6DnCoufFmWHs5v/YRb3gYIrwMITpQCuCWSmStTuddKSLb5y2q zH0rkDyW+qAN6kVQuIy4cznTjcafN6fvBcTx9q0Rz6mSeL10sazvTePEsCt/g4ZgRqeW umC2JK+BNJX0IaC1KCPuoxVXAVVvn076IeSMS+Wop0tv207HvXwnmeX8JXNxz3H0v9WH 9rHw== X-Gm-Message-State: ALoCoQnNr1tW+OXUm8kgyMG5fj7O5MTME1EirwB+BFWnP7U2Zo9/LewPguIFs4j2UhXdXVjdeDkG MIME-Version: 1.0 X-Received: by 10.60.44.8 with SMTP id a8mr7978103oem.19.1391397049508; Sun, 02 Feb 2014 19:10:49 -0800 (PST) Received: by 10.182.104.169 with HTTP; Sun, 2 Feb 2014 19:10:49 -0800 (PST) In-Reply-To: <1391396077.13026.72.camel@revolution.hippie.lan> References: <1391371204.13026.43.camel@revolution.hippie.lan> <20140202230450.GA42331@cicely7.cicely.de> <1391396077.13026.72.camel@revolution.hippie.lan> Date: Sun, 2 Feb 2014 20:10:49 -0700 Message-ID: Subject: Re: wandboard / imx6 / exynos4 / cortex-a9 "wrong-endian bug" fixed From: Tom Everett To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm , Bernd Walter , ticso@cicely.de 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: Mon, 03 Feb 2014 03:10:51 -0000 Stuff happens. ;) I'll update & build On Sun, Feb 2, 2014 at 7:54 PM, Ian Lepore wrote: > On Sun, 2014-02-02 at 18:25 -0700, Tom Everett wrote: > > I can confirm that a crochet image for Wandboard no longer crashes after > > this fix. It doesn't mount the FS yet, but that's a known issue, noted > > here: > > > > https://github.com/kientzle/crochet-freebsd/issues/29 > > > > Boot log is here: > > > > http://files.khubla.com/freebsd-wandboard/wandboard.txt > > The sdcard rootfs problem is my bad. I use an NFS root and I've been so > focused on the wrong-endian bug that I haven't tested with an sdcard for > months. It turns out I forgot a checkin when I added the basic imx6 > support; I just commited it as r261423. > > -- Ian > > > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Mon Feb 3 04:41:55 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 372CE5CD; Mon, 3 Feb 2014 04:41:55 +0000 (UTC) Received: from mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::4]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1DF651A73; Mon, 3 Feb 2014 04:41:55 +0000 (UTC) Received: from mail.nomadlogic.org (localhost [127.0.0.1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.nomadlogic.org (Postfix) with ESMTPS id 99331125ECB; Sun, 2 Feb 2014 20:41:54 -0800 (PST) Received: by mail.nomadlogic.org (Postfix, from userid 1001) id 8DD28125ECA; Sun, 2 Feb 2014 20:41:54 -0800 (PST) Date: Sun, 2 Feb 2014 20:41:54 -0800 To: Ian Lepore Subject: Re: Utilite Freescale i.MX6 support Message-ID: <20140203044149.GA56291@mail.nomadlogic.org> References: <52E94AE3.5080404@nomadlogic.org> <1391374550.13026.60.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1391374550.13026.60.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.22 (2013-10-16) From: pete@nomadlogic.org (Pete Wright) 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: Mon, 03 Feb 2014 04:41:55 -0000 On Sun, Feb 02, 2014 at 01:55:50PM -0700, Ian Lepore wrote: > On Wed, 2014-01-29 at 10:39 -0800, Pete Wright wrote: > > Hello, > > I have recently purchase this device and am interested in trying to get > > FreeBSD running on it: > > > > http://utilite-computer.com/web/utilite-models > > > > I currently have the system booting fine with the provided Debian image > > they ship with these system. At the end of this message is the output > > of dmesg from linux-land. > > > > Helpful documentation is also available here: > > http://utilite-computer.com/download/documentation//utilite/utilite-technical-reference-manual.pdf > > > > From what I can tell Utilite has done a good job at being open about > > their spec's and components. Hopefully this will help get it ported. I > > am personally excited about the dual Intel GBE NIC's on this system and > > would love to test this box out as an embedded router/firewall/nat device. > > > > Is there a good reference I can start from for this chipset? I am not > > %100 clear on which guide I should be following. > > > > Thanks in advance! > > -pete > > > > > > > > [snipped] > > > > I'm sorry it has taken me so long to reply to this. Until today my > reply would have had to been basically "freebsd will only kinda-sorta > run on that box," and every day I've been hoping to fix the > show-stopping bug and have something better to report. As of today > (r261410) the infamous wrong-endian bug is fixed and I think you won't > have too much trouble getting freebsd running on that unit. > no worries thanks for the reply! > To get started, you should probably start with the Wandboard dts files > and kernel config. One thing that jumps out at me is that the Utilite > uses uart ports 2 and 4, so to have a serial console for debugging > you'll need to change the dts source to enable uart2 and select it as > the console in the choosen {...} block. Unfortunately, because it's > Compulab, you'll probably have to buy their overpriced serial cable with > the weird connector on it (they do the same thing on the FitPc2). > thanks for the pointers! i was lucky enough to have them include the serial console cable with the box at no additional cost so no worries there. i did create an image using crochet-freebsd using the wanboard-quad config. it was failing trying to load uboot it looked like (no output on console) so i have some testing to do on that end (and bug reports too as well). i will re-build the images tonight to grab the latest patches as well as including the change for dts source as well. since the box already has uboot installed on it i was assuming i could just copy over the kernel image via nfs or tftp...so i will try that as well. cheers! -pete -- Pete Wright pete@nomadlogic.org twitter => @nomadlogicLA From owner-freebsd-arm@FreeBSD.ORG Mon Feb 3 08:34:13 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 0B75F2B8; Mon, 3 Feb 2014 08:34:13 +0000 (UTC) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C10821BC4; Mon, 3 Feb 2014 08:34:12 +0000 (UTC) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1WAEyl-008sxO-SC; Mon, 03 Feb 2014 09:34:07 +0100 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Ralf Wenk To: Ian Lepore Subject: Re: RaspberryPi panic with CURRENT r261183 (was: r260558) In-reply-to: <1390920783.1230.153.camel@revolution.hippie.lan> References: <20140125113854.083d5f30@bender.Home> <1390920783.1230.153.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 03 Feb 2014 09:34:06 +0100 Message-Id: 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: Mon, 03 Feb 2014 08:34:13 -0000 Ian Lepore wrote: > On Tue, 2014-01-28 at 14:55 +0100, Ralf Wenk wrote: > > [Report of system panic some hours after /usr/ports updating because > > of mmcsd0 timeout snipped] > > The panic here is just a symptom. The actual problem appears to be that > the sd controller or card locked up -- just stopped responding to > commands so that everything after that point timed out. The filesystem > code is not very forgiving about IO which does not complete, eventually > you end up with a panic. Just for your information about the current state: After updating world and system to r261284 the panic is gone. I have repeated the whole cycle of NFS-mount, rsync(1)-ing, fetching the INDEX-file and calling portversion several times and the system is still running after 2 days 20 hours. The hardware (RPi, sd card, power supply) is unchanged. Ralf From owner-freebsd-arm@FreeBSD.ORG Mon Feb 3 11:06:43 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 3E5389E for ; Mon, 3 Feb 2014 11:06:43 +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 0A6D61A38 for ; Mon, 3 Feb 2014 11:06:43 +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 s13B6g2A022558 for ; Mon, 3 Feb 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s13B6gfn022556 for freebsd-arm@FreeBSD.org; Mon, 3 Feb 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Feb 2014 11:06:42 GMT Message-Id: <201402031106.s13B6gfn022556@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Subject: Current problem reports assigned to 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: Mon, 03 Feb 2014 11:06:43 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/185617 arm 10.0-RC1, armv6: "pfctl -s state" crashes on BeagleBon o arm/185046 arm [armv6] issues with dhclient/sshd and jemalloc on rasp o arm/184078 arm cross installworld missing include files o arm/183926 arm Crash when ctrl-c while process is enter o arm/183740 arm mutex on some arm hardware requires dcache enabled o arm/183668 arm Panic when read unalign in ddb o arm/182544 arm [patch] ARM busdma_machdep-v6.c o arm/182060 arm make buildworld fails on Raspberry PI o arm/181722 arm gdb on ARM unable to sensibly debug core file from ass o arm/181718 arm threads caused hung on ARM/RPI o arm/181601 arm Sporadic failure of root mount on ARM/Raspberry o arm/180080 arm Unmapped buffers on ARMv7 big-RAM boards o arm/179688 arm [patch] [rpi] serial console eats some characters at m o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177685 arm [kernel] [patch] Correct return type and usage of at91 o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o arm/175803 arm building xdev for arm failing o arm/173617 arm Dreamplug exhibits eSATA file corruption using network o kern/171096 arm [arm][xscale][ixp]Allow 16bit access on PCI bus o arm/166256 arm build fail in pmap.c o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o ports/161044 arm devel/icu does not build on arm o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) p arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on 33 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Feb 3 13:54:22 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 48927B66 for ; Mon, 3 Feb 2014 13:54:22 +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 189231AA0 for ; Mon, 3 Feb 2014 13:54:21 +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 1WAJye-000Lub-GI; Mon, 03 Feb 2014 13:54:20 +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 s13DsHLh063161; Mon, 3 Feb 2014 06:54:17 -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: U2FsdGVkX19h5uD75SQt+H9R/3cC6USy Subject: Re: Utilite Freescale i.MX6 support From: Ian Lepore To: Pete Wright In-Reply-To: <20140203044149.GA56291@mail.nomadlogic.org> References: <52E94AE3.5080404@nomadlogic.org> <1391374550.13026.60.camel@revolution.hippie.lan> <20140203044149.GA56291@mail.nomadlogic.org> Content-Type: text/plain; charset="us-ascii" Date: Mon, 03 Feb 2014 06:54:16 -0700 Message-ID: <1391435656.13026.78.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: Mon, 03 Feb 2014 13:54:22 -0000 On Sun, 2014-02-02 at 20:41 -0800, Pete Wright wrote: > On Sun, Feb 02, 2014 at 01:55:50PM -0700, Ian Lepore wrote: > > On Wed, 2014-01-29 at 10:39 -0800, Pete Wright wrote: > > > Hello, > > > I have recently purchase this device and am interested in trying to get > > > FreeBSD running on it: > > > > > > http://utilite-computer.com/web/utilite-models > > > > > > I currently have the system booting fine with the provided Debian image > > > they ship with these system. At the end of this message is the output > > > of dmesg from linux-land. > > > > > > Helpful documentation is also available here: > > > http://utilite-computer.com/download/documentation//utilite/utilite-technical-reference-manual.pdf > > > > > > From what I can tell Utilite has done a good job at being open about > > > their spec's and components. Hopefully this will help get it ported. I > > > am personally excited about the dual Intel GBE NIC's on this system and > > > would love to test this box out as an embedded router/firewall/nat device. > > > > > > Is there a good reference I can start from for this chipset? I am not > > > %100 clear on which guide I should be following. > > > > > > Thanks in advance! > > > -pete > > > > > > > > > > > > [snipped] > > > > > > > I'm sorry it has taken me so long to reply to this. Until today my > > reply would have had to been basically "freebsd will only kinda-sorta > > run on that box," and every day I've been hoping to fix the > > show-stopping bug and have something better to report. As of today > > (r261410) the infamous wrong-endian bug is fixed and I think you won't > > have too much trouble getting freebsd running on that unit. > > > no worries thanks for the reply! > > > > > > To get started, you should probably start with the Wandboard dts files > > and kernel config. One thing that jumps out at me is that the Utilite > > uses uart ports 2 and 4, so to have a serial console for debugging > > you'll need to change the dts source to enable uart2 and select it as > > the console in the choosen {...} block. Unfortunately, because it's > > Compulab, you'll probably have to buy their overpriced serial cable with > > the weird connector on it (they do the same thing on the FitPc2). > > > > thanks for the pointers! i was lucky enough to have them include the > serial console cable with the box at no additional cost so no worries there. > > i did create an image using crochet-freebsd using the wanboard-quad > config. it was failing trying to load uboot it looked like (no output > on console) so i have some testing to do on that end (and bug reports > too as well). > > i will re-build the images tonight to grab the latest patches as well as > including the change for dts source as well. > > since the box already has uboot installed on it i was assuming i could > just copy over the kernel image via nfs or tftp...so i will try that as > well. > > cheers! > -pete > I haven't gotten ubldr to work yet, I'm going to look into that this week. To net-load and launch the kernel directly, something like this should work: tftp 12000000 172.22.42.240:/wand/boot/kernel/kernel go 12000100 When rebuilding u-boot for the Utilite, some config may need to be changed to use uart2 or 4 for the console. In theory, Compulab should make the config and any other u-boot source changes available, since it's GPL. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Feb 3 17:41:20 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 D14BAEAA; Mon, 3 Feb 2014 17:41:20 +0000 (UTC) Received: from mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::4]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AB4811081; Mon, 3 Feb 2014 17:41:20 +0000 (UTC) Received: from mail.nomadlogic.org (localhost [127.0.0.1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.nomadlogic.org (Postfix) with ESMTPS id C7B4E125ECA; Mon, 3 Feb 2014 09:41:19 -0800 (PST) Received: from pop.rubicorp.com (unknown [72.34.113.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.nomadlogic.org (Postfix) with ESMTPSA id B88DF125EC6; Mon, 3 Feb 2014 09:41:19 -0800 (PST) Message-ID: <52EFD4BF.9060704@nomadlogic.org> Date: Mon, 03 Feb 2014 09:41:19 -0800 From: Pete Wright User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Utilite Freescale i.MX6 support References: <52E94AE3.5080404@nomadlogic.org> <1391374550.13026.60.camel@revolution.hippie.lan> <20140203044149.GA56291@mail.nomadlogic.org> <1391435656.13026.78.camel@revolution.hippie.lan> In-Reply-To: <1391435656.13026.78.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1 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: Mon, 03 Feb 2014 17:41:21 -0000 On 02/03/14 05:54, Ian Lepore wrote: > On Sun, 2014-02-02 at 20:41 -0800, Pete Wright wrote: >> On Sun, Feb 02, 2014 at 01:55:50PM -0700, Ian Lepore wrote: >>> On Wed, 2014-01-29 at 10:39 -0800, Pete Wright wrote: >>>> Hello, >>>> I have recently purchase this device and am interested in trying to get >>>> FreeBSD running on it: >>>> >>>> http://utilite-computer.com/web/utilite-models >>>> >>>> I currently have the system booting fine with the provided Debian image >>>> they ship with these system. At the end of this message is the output >>>> of dmesg from linux-land. >>>> >>>> Helpful documentation is also available here: >>>> http://utilite-computer.com/download/documentation//utilite/utilite-technical-reference-manual.pdf >>>> >>>> From what I can tell Utilite has done a good job at being open about >>>> their spec's and components. Hopefully this will help get it ported. I >>>> am personally excited about the dual Intel GBE NIC's on this system and >>>> would love to test this box out as an embedded router/firewall/nat device. >>>> >>>> Is there a good reference I can start from for this chipset? I am not >>>> %100 clear on which guide I should be following. >>>> >>>> Thanks in advance! >>>> -pete >>>> >>>> >>>> >>>> [snipped] >>>> >>> >>> I'm sorry it has taken me so long to reply to this. Until today my >>> reply would have had to been basically "freebsd will only kinda-sorta >>> run on that box," and every day I've been hoping to fix the >>> show-stopping bug and have something better to report. As of today >>> (r261410) the infamous wrong-endian bug is fixed and I think you won't >>> have too much trouble getting freebsd running on that unit. >>> >> no worries thanks for the reply! >> >> >> >> >>> To get started, you should probably start with the Wandboard dts files >>> and kernel config. One thing that jumps out at me is that the Utilite >>> uses uart ports 2 and 4, so to have a serial console for debugging >>> you'll need to change the dts source to enable uart2 and select it as >>> the console in the choosen {...} block. Unfortunately, because it's >>> Compulab, you'll probably have to buy their overpriced serial cable with >>> the weird connector on it (they do the same thing on the FitPc2). >>> >> >> thanks for the pointers! i was lucky enough to have them include the >> serial console cable with the box at no additional cost so no worries there. >> >> i did create an image using crochet-freebsd using the wanboard-quad >> config. it was failing trying to load uboot it looked like (no output >> on console) so i have some testing to do on that end (and bug reports >> too as well). >> >> i will re-build the images tonight to grab the latest patches as well as >> including the change for dts source as well. >> >> since the box already has uboot installed on it i was assuming i could >> just copy over the kernel image via nfs or tftp...so i will try that as >> well. >> >> cheers! >> -pete >> > > I haven't gotten ubldr to work yet, I'm going to look into that this > week. To net-load and launch the kernel directly, something like this > should work: > > tftp 12000000 172.22.42.240:/wand/boot/kernel/kernel > go 12000100 fantastic thanks for the pointer there. > > When rebuilding u-boot for the Utilite, some config may need to be > changed to use uart2 or 4 for the console. In theory, Compulab should > make the config and any other u-boot source changes available, since > it's GPL. for now i'm going to try to piggy-back on their uboot build so i can get the mechanics of building and running a freebsd kernel sorted out. once i get that done i am hoping to spend more cycles on the uboot stuff. cheers, -pete -- Pete Wright pete@nomadlogic.org twitter => @nomadlogicLA From owner-freebsd-arm@FreeBSD.ORG Mon Feb 3 19:21:14 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 B1AB46CD; Mon, 3 Feb 2014 19:21:14 +0000 (UTC) Received: from mailgate-02.zdv.uni-mainz.de (mailgate-02.zdv.Uni-Mainz.DE [IPv6:2001:4c80:40:62d:203:ffff:fe5d:b2f6]) by mx1.freebsd.org (Postfix) with ESMTP id DBB1F1AC4; Mon, 3 Feb 2014 19:21:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-mainz.de; i=@uni-mainz.de; q=dns/txt; s=ironport; t=1391455274; x=1422991274; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=LltBvWHgV7eL7gx7xXci/res41vFZ+U33l1BVtyQaN4=; b=kySUifcEzmcguwTCsD8zNQt9nty9jo5Rzzws90FHBjfTM5xeYJ7WsitX KPI4+qHJgMS6hUxSquHzb86RVxSYn7lt6cGI5GZkjHMa7EPs4Wz7Iy009 BSZGSoT6xD1fMcbNPG4o0+wt+0yd6hQn/Fj8eUc5gTr8UGrcN4sKAp/08 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAMHq71IKXgZQ/2dsb2JhbABZgmtZV706T4EkdIIlAQEBBAEBAUsgFwQCAQgRBAEBKAcnAQkBFAkIAgQBBwcEAQcVBIdkAQzNOheOOAEBVgaCKQ+BegSJEYxGhAWFEYtegy1tgQQ5 X-IPAS-Result: AqQEAMHq71IKXgZQ/2dsb2JhbABZgmtZV706T4EkdIIlAQEBBAEBAUsgFwQCAQgRBAEBKAcnAQkBFAkIAgQBBwcEAQcVBIdkAQzNOheOOAEBVgaCKQ+BegSJEYxGhAWFEYtegy1tgQQ5 Received: from e14hub-01.zdv.uni-mainz.de ([10.94.6.80]) by mailgate-02.zdv.uni-mainz.de with ESMTP; 03 Feb 2014 20:21:11 +0100 Received: from e15be-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9090) by E14HUB-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:21d:d8ff:feb7:1c5f) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 3 Feb 2014 20:20:38 +0100 Received: from e15be-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9090) by e15be-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9090) with Microsoft SMTP Server (TLS) id 15.0.775.38; Mon, 3 Feb 2014 20:20:38 +0100 Received: from e15be-01.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9090]) by e15be-01.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:9090%15]) with mapi id 15.00.0775.031; Mon, 3 Feb 2014 20:20:38 +0100 From: =?iso-8859-1?B?V2Vp3ywgSvxyZ2Vu?= To: 'Michael Tuexen' , "'freebsd-arm@freebsd.org'" Subject: RE: panic Thread-Topic: panic Thread-Index: AQHPHkaIU5H4PlBheUCOb22h38kSJZqj7FPg Date: Mon, 3 Feb 2014 19:20:37 +0000 Message-ID: <77e6463987b1438b8de70b7e426092ff@e15be-01.zdv.Uni-Mainz.DE> References: <14E59004-FC13-48DD-B789-AA78767C6871@freebsd.org> In-Reply-To: <14E59004-FC13-48DD-B789-AA78767C6871@freebsd.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.93.178.81] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Mon, 03 Feb 2014 19:21:14 -0000 Hi, I would suggest to try a kernel which contains the changes and fixes that have been committed to FreeBSD current yesterday. Specifically there are fixes to vfp_bounce. Regards Juergen Weiss Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-2= 6407 > -----Original Message----- > From: owner-freebsd-arm@freebsd.org [mailto:owner-freebsd-arm@freebsd.org= ] On Behalf Of > Michael Tuexen > Sent: Friday, January 31, 2014 6:37 AM > To: freebsd-arm@freebsd.org > Subject: panic >=20 > Dear all, >=20 > while building the or xcb-util-renderutil-0.3.8 port I got > panic: Undefined instruction in kernel. > when running r261186 on a RPI-B. I could successfully build > ports for cvs, subversion, git... >=20 > db> where > Tracing pid 32937 tid 100103 td 0xc2b4ac80 > db_trace_self() at db_trace_self > pc =3D 0xc047bfa0 lr =3D 0xc012f010 (db_stack_trace+0xf4) > sp =3D 0xdd7389b8 fp =3D 0xdd7389d0 > r10 =3D 0xc0571a90 > db_stack_trace() at db_stack_trace+0xf4 > pc =3D 0xc012f010 lr =3D 0xc012e97c (db_command+0x264) > sp =3D 0xdd7389d8 fp =3D 0xdd738a78 > r4 =3D 0x00000000 r5 =3D 0x00000000 > r6 =3D 0xc04e48ef > db_command() at db_command+0x264 > pc =3D 0xc012e97c lr =3D 0xc012e6ec (db_command_loop+0x60) > sp =3D 0xdd738a80 fp =3D 0xdd738a90 > r4 =3D 0xc04bb2e6 r5 =3D 0xc04d4cb4 > r6 =3D 0xc05c6ddc r7 =3D 0xdd738c60 > r8 =3D 0xc2b4ac80 r9 =3D 0xc05bd7b4 > r10 =3D 0xc0571d00 > db_command_loop() at db_command_loop+0x60 > pc =3D 0xc012e6ec lr =3D 0xc01310ec (db_trap+0xdc) > sp =3D 0xdd738a98 fp =3D 0xdd738bb8 > r4 =3D 0x00000000 r5 =3D 0xdd738aa0 > r6 =3D 0xc05bd7e0 > db_trap() at db_trap+0xdc > pc =3D 0xc01310ec lr =3D 0xc027c284 (kdb_trap+0xd4) > sp =3D 0xdd738bc0 fp =3D 0xdd738be0 > r4 =3D 0x00000000 r5 =3D 0x00000001 > r6 =3D 0xc05bd7e0 r7 =3D 0xdd738c60 > kdb_trap() at kdb_trap+0xd4 > pc =3D 0xc027c284 lr =3D 0xc048ee0c (undefinedinstruction+0x2b0= ) > sp =3D 0xdd738be8 fp =3D 0xdd738c58 > r4 =3D 0x00000000 r5 =3D 0xc048eab8 > r6 =3D 0x00000000 r7 =3D 0xe7ffffff > r8 =3D 0xc2b4ac80 r9 =3D 0xdd738c60 > r10 =3D 0xc027bb34 > undefinedinstruction() at undefinedinstruction+0x2b0 > pc =3D 0xc048ee0c lr =3D 0xc047ddb0 (exception_exit) > sp =3D 0xdd738c60 fp =3D 0xdd738cb8 > r4 =3D 0xc04d4d0e r5 =3D 0xdd738cfc > r6 =3D 0xc0501af1 r7 =3D 0xc05afcf0 > r8 =3D 0xc2b4ac80 r9 =3D 0xc05afb50 > r10 =3D 0xc05c8840 > exception_exit() at exception_exit > pc =3D 0xc047ddb0 lr =3D 0xc027bb28 (kdb_enter+0x40) > sp =3D 0xdd738cb0 fp =3D 0xdd738cb8 > r0 =3D 0xc05bd7c4 r1 =3D 0x00000000 > r2 =3D 0xc04d86a8 r3 =3D 0x000000ab > r4 =3D 0xc04d4d0e r5 =3D 0xdd738cfc > r6 =3D 0xc0501af1 r7 =3D 0xc05afcf0 > r8 =3D 0xc2b4ac80 r9 =3D 0xc05afb50 > r10 =3D 0xc05c8840 r12 =3D 0x00000000 > $a() at $a > pc =3D 0xc027bb38 lr =3D 0xc0245b2c (vpanic+0xb8) > sp =3D 0xdd738cc0 fp =3D 0xdd738ce0 > r4 =3D 0x00000100 > vpanic() at vpanic+0xb8 > pc =3D 0xc0245b2c lr =3D 0xc0245b90 (kproc_shutdown) > sp =3D 0xdd738ce8 fp =3D 0xdd738cf0 > r4 =3D 0x00000000 r5 =3D 0xc048f93c > r6 =3D 0xc05c6c64 r7 =3D 0xecb10a20 > r8 =3D 0xc2b4ac80 r9 =3D 0xdd738d80 > r10 =3D 0xc048fa08 > kproc_shutdown() at kproc_shutdown > pc =3D 0xc0245b90 lr =3D 0xc048ee8c ($d) > sp =3D 0xdd738cf8 fp =3D 0xdd738d78 > r4 =3D 0xdd738cfc r5 =3D 0xc026b7b4 > $d() at $d > pc =3D 0xc048ee8c lr =3D 0xc047ddb0 (exception_exit) > sp =3D 0xdd738d80 fp =3D 0xdd738de0 > r4 =3D 0x00000010 r5 =3D 0x00000000 > r6 =3D 0x00000000 r7 =3D 0xec828b10 > r8 =3D 0xc2b4ac80 r9 =3D 0xdd738e60 > r10 =3D 0x2011eb20 > exception_exit() at exception_exit > pc =3D 0xc047ddb0 lr =3D 0xc048ec60 (undefinedinstruction+0x104= ) > sp =3D 0xdd738dd0 fp =3D 0xdd738de0 > r0 =3D 0x00000000 r1 =3D 0xdd738ef0 > r2 =3D 0xdd738e60 r3 =3D 0x00000010 > r4 =3D 0x00000010 r5 =3D 0x00000000 > r6 =3D 0x00000000 r7 =3D 0xec828b10 > r8 =3D 0xc2b4ac80 r9 =3D 0xdd738e60 > r10 =3D 0x2011eb20 r12 =3D 0x0002eb68 > vfp_bounce() at vfp_bounce+0xcc > pc =3D 0xc048fa08 lr =3D 0xc048ec60 (undefinedinstruction+0x104= ) > sp =3D 0xdd738de8 fp =3D 0xdd738e58 > r4 =3D 0x00000010 r5 =3D 0xc048f93c > r6 =3D 0xc05c6c70 > undefinedinstruction() at undefinedinstruction+0x104 > pc =3D 0xc048ec60 lr =3D 0xc047ddb0 (exception_exit) > sp =3D 0xdd738e60 fp =3D 0xbfffdf30 > r4 =3D 0x00000001 r5 =3D 0xbfffdde0 > r6 =3D 0xbfffe038 r7 =3D 0x208ac970 > r8 =3D 0x00000000 r9 =3D 0x00000000 > r10 =3D 0x00000000 > exception_exit() at exception_exit > pc =3D 0xc047ddb0 lr =3D 0x2014e27c (0x2014e27c) > sp =3D 0xdd738eb0 fp =3D 0xbfffdf30 > r0 =3D 0xbfffdde0 r1 =3D 0x4278f502 > r2 =3D 0xbfffde60 r3 =3D 0x20227120 > r4 =3D 0x00000001 r5 =3D 0xbfffdde0 > r6 =3D 0xbfffe038 r7 =3D 0x208ac970 > r8 =3D 0x00000000 r9 =3D 0x00000000 > r10 =3D 0x00000000 r12 =3D 0x0002eb68 > Unable to unwind into user mode > db> >=20 > Any idea? >=20 > Best regards > Michael > _______________________________________________ > 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 Mon Feb 3 19:32: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 5E4AE939 for ; Mon, 3 Feb 2014 19:32:50 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8958A1BCA for ; Mon, 3 Feb 2014 19:32:49 +0000 (UTC) Received: from [192.168.1.102] (p5481A288.dip0.t-ipconnect.de [84.129.162.136]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 730221C0B4054; Mon, 3 Feb 2014 20:32:45 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: panic From: Michael Tuexen In-Reply-To: <77e6463987b1438b8de70b7e426092ff@e15be-01.zdv.Uni-Mainz.DE> Date: Mon, 3 Feb 2014 20:32:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <14E59004-FC13-48DD-B789-AA78767C6871@freebsd.org> <77e6463987b1438b8de70b7e426092ff@e15be-01.zdv.Uni-Mainz.DE> To: =?iso-8859-1?Q?=22Wei=DF=2C_J=FCrgen=22?= 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: Mon, 03 Feb 2014 19:32:50 -0000 On Feb 3, 2014, at 8:20 PM, "Wei=DF, J=FCrgen" = wrote: > Hi, >=20 > I would suggest to try a kernel which contains the changes and > fixes that have been committed to FreeBSD current yesterday. > Specifically there are fixes to vfp_bounce. Thanks. I'll try. Best regards Michael >=20 > Regards >=20 > Juergen Weiss >=20 > Juergen Weiss |Universitaet Mainz, Zentrum fuer = Datenverarbeitung, > weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: = +49(6131)39-26407 >=20 >=20 >> -----Original Message----- >> From: owner-freebsd-arm@freebsd.org = [mailto:owner-freebsd-arm@freebsd.org] On Behalf Of >> Michael Tuexen >> Sent: Friday, January 31, 2014 6:37 AM >> To: freebsd-arm@freebsd.org >> Subject: panic >>=20 >> Dear all, >>=20 >> while building the or xcb-util-renderutil-0.3.8 port I got >> panic: Undefined instruction in kernel. >> when running r261186 on a RPI-B. I could successfully build >> ports for cvs, subversion, git... >>=20 >> db> where >> Tracing pid 32937 tid 100103 td 0xc2b4ac80 >> db_trace_self() at db_trace_self >> pc =3D 0xc047bfa0 lr =3D 0xc012f010 (db_stack_trace+0xf4) >> sp =3D 0xdd7389b8 fp =3D 0xdd7389d0 >> r10 =3D 0xc0571a90 >> db_stack_trace() at db_stack_trace+0xf4 >> pc =3D 0xc012f010 lr =3D 0xc012e97c (db_command+0x264) >> sp =3D 0xdd7389d8 fp =3D 0xdd738a78 >> r4 =3D 0x00000000 r5 =3D 0x00000000 >> r6 =3D 0xc04e48ef >> db_command() at db_command+0x264 >> pc =3D 0xc012e97c lr =3D 0xc012e6ec (db_command_loop+0x60) >> sp =3D 0xdd738a80 fp =3D 0xdd738a90 >> r4 =3D 0xc04bb2e6 r5 =3D 0xc04d4cb4 >> r6 =3D 0xc05c6ddc r7 =3D 0xdd738c60 >> r8 =3D 0xc2b4ac80 r9 =3D 0xc05bd7b4 >> r10 =3D 0xc0571d00 >> db_command_loop() at db_command_loop+0x60 >> pc =3D 0xc012e6ec lr =3D 0xc01310ec (db_trap+0xdc) >> sp =3D 0xdd738a98 fp =3D 0xdd738bb8 >> r4 =3D 0x00000000 r5 =3D 0xdd738aa0 >> r6 =3D 0xc05bd7e0 >> db_trap() at db_trap+0xdc >> pc =3D 0xc01310ec lr =3D 0xc027c284 (kdb_trap+0xd4) >> sp =3D 0xdd738bc0 fp =3D 0xdd738be0 >> r4 =3D 0x00000000 r5 =3D 0x00000001 >> r6 =3D 0xc05bd7e0 r7 =3D 0xdd738c60 >> kdb_trap() at kdb_trap+0xd4 >> pc =3D 0xc027c284 lr =3D 0xc048ee0c = (undefinedinstruction+0x2b0) >> sp =3D 0xdd738be8 fp =3D 0xdd738c58 >> r4 =3D 0x00000000 r5 =3D 0xc048eab8 >> r6 =3D 0x00000000 r7 =3D 0xe7ffffff >> r8 =3D 0xc2b4ac80 r9 =3D 0xdd738c60 >> r10 =3D 0xc027bb34 >> undefinedinstruction() at undefinedinstruction+0x2b0 >> pc =3D 0xc048ee0c lr =3D 0xc047ddb0 (exception_exit) >> sp =3D 0xdd738c60 fp =3D 0xdd738cb8 >> r4 =3D 0xc04d4d0e r5 =3D 0xdd738cfc >> r6 =3D 0xc0501af1 r7 =3D 0xc05afcf0 >> r8 =3D 0xc2b4ac80 r9 =3D 0xc05afb50 >> r10 =3D 0xc05c8840 >> exception_exit() at exception_exit >> pc =3D 0xc047ddb0 lr =3D 0xc027bb28 (kdb_enter+0x40) >> sp =3D 0xdd738cb0 fp =3D 0xdd738cb8 >> r0 =3D 0xc05bd7c4 r1 =3D 0x00000000 >> r2 =3D 0xc04d86a8 r3 =3D 0x000000ab >> r4 =3D 0xc04d4d0e r5 =3D 0xdd738cfc >> r6 =3D 0xc0501af1 r7 =3D 0xc05afcf0 >> r8 =3D 0xc2b4ac80 r9 =3D 0xc05afb50 >> r10 =3D 0xc05c8840 r12 =3D 0x00000000 >> $a() at $a >> pc =3D 0xc027bb38 lr =3D 0xc0245b2c (vpanic+0xb8) >> sp =3D 0xdd738cc0 fp =3D 0xdd738ce0 >> r4 =3D 0x00000100 >> vpanic() at vpanic+0xb8 >> pc =3D 0xc0245b2c lr =3D 0xc0245b90 (kproc_shutdown) >> sp =3D 0xdd738ce8 fp =3D 0xdd738cf0 >> r4 =3D 0x00000000 r5 =3D 0xc048f93c >> r6 =3D 0xc05c6c64 r7 =3D 0xecb10a20 >> r8 =3D 0xc2b4ac80 r9 =3D 0xdd738d80 >> r10 =3D 0xc048fa08 >> kproc_shutdown() at kproc_shutdown >> pc =3D 0xc0245b90 lr =3D 0xc048ee8c ($d) >> sp =3D 0xdd738cf8 fp =3D 0xdd738d78 >> r4 =3D 0xdd738cfc r5 =3D 0xc026b7b4 >> $d() at $d >> pc =3D 0xc048ee8c lr =3D 0xc047ddb0 (exception_exit) >> sp =3D 0xdd738d80 fp =3D 0xdd738de0 >> r4 =3D 0x00000010 r5 =3D 0x00000000 >> r6 =3D 0x00000000 r7 =3D 0xec828b10 >> r8 =3D 0xc2b4ac80 r9 =3D 0xdd738e60 >> r10 =3D 0x2011eb20 >> exception_exit() at exception_exit >> pc =3D 0xc047ddb0 lr =3D 0xc048ec60 = (undefinedinstruction+0x104) >> sp =3D 0xdd738dd0 fp =3D 0xdd738de0 >> r0 =3D 0x00000000 r1 =3D 0xdd738ef0 >> r2 =3D 0xdd738e60 r3 =3D 0x00000010 >> r4 =3D 0x00000010 r5 =3D 0x00000000 >> r6 =3D 0x00000000 r7 =3D 0xec828b10 >> r8 =3D 0xc2b4ac80 r9 =3D 0xdd738e60 >> r10 =3D 0x2011eb20 r12 =3D 0x0002eb68 >> vfp_bounce() at vfp_bounce+0xcc >> pc =3D 0xc048fa08 lr =3D 0xc048ec60 = (undefinedinstruction+0x104) >> sp =3D 0xdd738de8 fp =3D 0xdd738e58 >> r4 =3D 0x00000010 r5 =3D 0xc048f93c >> r6 =3D 0xc05c6c70 >> undefinedinstruction() at undefinedinstruction+0x104 >> pc =3D 0xc048ec60 lr =3D 0xc047ddb0 (exception_exit) >> sp =3D 0xdd738e60 fp =3D 0xbfffdf30 >> r4 =3D 0x00000001 r5 =3D 0xbfffdde0 >> r6 =3D 0xbfffe038 r7 =3D 0x208ac970 >> r8 =3D 0x00000000 r9 =3D 0x00000000 >> r10 =3D 0x00000000 >> exception_exit() at exception_exit >> pc =3D 0xc047ddb0 lr =3D 0x2014e27c (0x2014e27c) >> sp =3D 0xdd738eb0 fp =3D 0xbfffdf30 >> r0 =3D 0xbfffdde0 r1 =3D 0x4278f502 >> r2 =3D 0xbfffde60 r3 =3D 0x20227120 >> r4 =3D 0x00000001 r5 =3D 0xbfffdde0 >> r6 =3D 0xbfffe038 r7 =3D 0x208ac970 >> r8 =3D 0x00000000 r9 =3D 0x00000000 >> r10 =3D 0x00000000 r12 =3D 0x0002eb68 >> Unable to unwind into user mode >> db> >>=20 >> Any idea? >>=20 >> Best regards >> Michael >> _______________________________________________ >> 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" >=20 From owner-freebsd-arm@FreeBSD.ORG Mon Feb 3 21:06:51 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 736CF5A1; Mon, 3 Feb 2014 21:06:51 +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 457A014CB; Mon, 3 Feb 2014 21:06:51 +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 s13L6pAt070138; Mon, 3 Feb 2014 21:06:51 GMT (envelope-from rene@freefall.freebsd.org) Received: (from rene@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s13L6pp2070137; Mon, 3 Feb 2014 21:06:51 GMT (envelope-from rene) Date: Mon, 3 Feb 2014 21:06:51 GMT Message-Id: <201402032106.s13L6pp2070137@freefall.freebsd.org> To: rene@FreeBSD.org, rene@FreeBSD.org, freebsd-arm@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: Mon, 03 Feb 2014 21:06:51 -0000 Synopsis: please fix build binutils-2.23.1 in raspberry pi Responsible-Changed-From-To: rene->freebsd-arm Responsible-Changed-By: rene Responsible-Changed-When: Mon Feb 3 21:05:16 UTC 2014 Responsible-Changed-Why: Back to freebsd-arm, my patch produces a broken ld as can be seen in http://people.freebsd.org/~rene/patches/binutils-rpi-bug.txt http://www.freebsd.org/cgi/query-pr.cgi?pr=175605 From owner-freebsd-arm@FreeBSD.ORG Tue Feb 4 02:25:17 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 9F009F99 for ; Tue, 4 Feb 2014 02:25:17 +0000 (UTC) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 68765121D for ; Tue, 4 Feb 2014 02:25:17 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id i7so9206690oag.1 for ; Mon, 03 Feb 2014 18:25:16 -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:date:message-id:subject:from:to :content-type; bh=KdzOOxQ7LJbCgqenBfq4QLagJwLZ6kT74tEPivWoaT8=; b=jnMT3l4Kx0uksbASI89n+QEjA7dFTEkewp7Aa7GzxaYMR0h0fgWF55igMoGKMu4W9/ FF09C81ouh6SUKvkTTqw4WzyCT8npMmTo7fXTIj4tKWibo7N5fBCdSzfovDQfbhAXQ3G wBQ59oZwVC4OZE01AZ889KkXA1wBX2MznqJQNVMMsXuhdSqhVyA495vgBsu25SdSlYQE rgFKY/Gskh1afQf2uJB+NYIOnEUOUocG4+klYulluKUHtYEIh4/e6SEtYQ4h9JRmbS++ P86Y3NIL6luKiakAv0CimUAhKINqdls8gMVm8NiThZ8tcohcuoieqDwJfGlC5UIrn5QE DPKw== X-Gm-Message-State: ALoCoQmNpe/n0QW5t7JTBlMoxylMfpnOLb1X9K9mesWEuJdyOhw93Hhq1PZGmSkpQIEhjloY4v4J MIME-Version: 1.0 X-Received: by 10.60.103.239 with SMTP id fz15mr33323228oeb.22.1391480318757; Mon, 03 Feb 2014 18:18:38 -0800 (PST) Received: by 10.182.104.169 with HTTP; Mon, 3 Feb 2014 18:18:38 -0800 (PST) Date: Mon, 3 Feb 2014 19:18:38 -0700 Message-ID: Subject: Successful boot of crochet on Wandboard From: Tom Everett 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: Tue, 04 Feb 2014 02:25:17 -0000 Hello ARM list. After the endianness fix by Ian, the crochet build of Wandboard now boots. There are a couple things that need to be fixed in the overlay, however, the kernel does start and it does mount the root file system. The boot log is here: http://files.khubla.com/freebsd-wandboard/wandboard.txt And the gzipped image is here: http://files.khubla.com/freebsd-wandboard/FreeBSD-armv6-11.0-WANDBOARD-QUAD-r261446.img.gz This image doesn't use ubldr, so that will be on the list of things to fix. -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Tue Feb 4 05:00: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 EF4337BD for ; Tue, 4 Feb 2014 05:00:25 +0000 (UTC) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B9F3F11AD for ; Tue, 4 Feb 2014 05:00:25 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id ld10so8052001pab.10 for ; Mon, 03 Feb 2014 21:00:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=fzfKvoF2PVqD2NIOoi3uN9kzjzFnVqYkfhgIYNV6R1I=; b=V+uCPMQv8ScNOiE/p1MCb7ZEp2fQ35xW0UTBsgEVtPrJt+4kA4vRt16KcJPKYO5FpZ f3NSWSuwcFRuPTKApoM3O6fOow2PZkyvkWgxec+5v6UN98YvEJBEGsY8v0o2pac0XCaH 2SQzvUBhk212spd3IvxBkvLo9BvHmmy8OC9xaTK3klJn3Ch1eEMxZOgxFi6ck5i5mf8K gJUq6Gtqcx2cw0tDQanphW7qd/7dij0RBmjJycEo78aqRhCbG/wZnuM9Zd2XQvLGZSSj 3xtaTja5cswRMlCsH+rtMrVHqU8mNTEUozgx5VgtH89y+YkfHAJY6Qj3qa6a9XKtom3D /qBw== X-Gm-Message-State: ALoCoQnPwWLeHUDhX/XfqlkR365K3rtE0iilwvjByT5lCizVW2oV4/LQKZlMJupxhS3C+LdEPfox X-Received: by 10.68.171.193 with SMTP id aw1mr41476725pbc.117.1391490019667; Mon, 03 Feb 2014 21:00:19 -0800 (PST) Received: from [192.168.1.2] (c-24-6-182-22.hsd1.ca.comcast.net. [24.6.182.22]) by mx.google.com with ESMTPSA id vg1sm61783927pbc.44.2014.02.03.21.00.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Feb 2014 21:00:18 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: wandboard / imx6 / exynos4 / cortex-a9 "wrong-endian bug" fixed From: Tim Kientzle In-Reply-To: <1584FD9C-581F-4BCF-8153-E381693887DB@bsdimp.com> Date: Mon, 3 Feb 2014 20:59:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2BDF104B-16DE-4488-9870-148843D8CC2F@kientzle.com> References: <1391371204.13026.43.camel@revolution.hippie.lan> <20140202230450.GA42331@cicely7.cicely.de> <1391395062.13026.69.camel@revolution.hippie.lan> <1584FD9C-581F-4BCF-8153-E381693887DB@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1827) Cc: freebsd-arm , Bernd Walter , ticso@cicely.de, Ian Lepore 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: Tue, 04 Feb 2014 05:00:26 -0000 On Feb 2, 2014, at 6:59 PM, Warner Losh wrote: >=20 > On Feb 2, 2014, at 7:37 PM, Ian Lepore wrote: >=20 >> On Sun, 2014-02-02 at 18:25 -0700, Tom Everett wrote: >>> I can confirm that a crochet image for Wandboard no longer crashes = after >>> this fix. It doesn't mount the FS yet, but that's a known issue, = noted >>> here: >>>=20 >>> https://github.com/kientzle/crochet-freebsd/issues/29 >>=20 >> That thread mentions needing to build a u-boot for wandboard. Here's = a >> patchset for doing that. Apply this in your ports/sysutils dir, = using: >>=20 >> patch -p0 >=20 >> This was copied from Tim's beaglebone work and changed a bit for >> wandboard. =20 >>=20 >> I've been meaning to ask about how we should handle this. Do we want = a >> u-boot port for every board, or is there some way to parameterize a >> single port so that it applies the right set of patches, or what? = I'm >> not very savvy about ports. >=20 > Usually there's a master port, and slave ports that parameterize. When = we talked about this at BSDcan, I believe that was the model that was = suggested for this problem.. Does that work when there=92s a different source distro for many of the ports? (Not to mention different patches for each one.) Tim P.S. I started a U-Boot port for BeagleBone but my time has evaporated. If anyone wants to take that over and extend it for other boards, step right up=85 From owner-freebsd-arm@FreeBSD.ORG Tue Feb 4 05:13:19 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 65A7F9F5; Tue, 4 Feb 2014 05:13: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 33C3412AD; Tue, 4 Feb 2014 05:13: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 s145DCnP058611; Tue, 4 Feb 2014 00:13:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s145DC4l058592; Tue, 4 Feb 2014 05:13:12 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 4 Feb 2014 05:13:12 GMT Message-Id: <201402040513.s145DC4l058592@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: Tue, 04 Feb 2014 05:13:19 -0000 TB --- 2014-02-04 02:10:23 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-02-04 02:10:23 - 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-02-04 02:10:23 - starting HEAD tinderbox run for arm/arm TB --- 2014-02-04 02:10:23 - cleaning the object tree TB --- 2014-02-04 02:10:23 - /usr/local/bin/svn stat /src TB --- 2014-02-04 02:10:28 - At svn revision 261451 TB --- 2014-02-04 02:10:29 - building world TB --- 2014-02-04 02:10:29 - CROSS_BUILD_TESTING=YES TB --- 2014-02-04 02:10:29 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-04 02:10:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-04 02:10:29 - SRCCONF=/dev/null TB --- 2014-02-04 02:10:29 - TARGET=arm TB --- 2014-02-04 02:10:29 - TARGET_ARCH=arm TB --- 2014-02-04 02:10:29 - TZ=UTC TB --- 2014-02-04 02:10:29 - __MAKE_CONF=/dev/null TB --- 2014-02-04 02:10:29 - cd /src TB --- 2014-02-04 02:10:29 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Feb 4 02:10:38 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 Tue Feb 4 05:13:11 UTC 2014 TB --- 2014-02-04 05:13:11 - generating LINT kernel config TB --- 2014-02-04 05:13:11 - cd /src/sys/arm/conf TB --- 2014-02-04 05:13:11 - /usr/bin/make -B LINT TB --- 2014-02-04 05:13:11 - cd /src/sys/arm/conf TB --- 2014-02-04 05:13:11 - /usr/sbin/config -m LINT TB --- 2014-02-04 05:13:11 - building LINT kernel TB --- 2014-02-04 05:13:11 - CROSS_BUILD_TESTING=YES TB --- 2014-02-04 05:13:11 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-04 05:13:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-04 05:13:11 - SRCCONF=/dev/null TB --- 2014-02-04 05:13:11 - TARGET=arm TB --- 2014-02-04 05:13:11 - TARGET_ARCH=arm TB --- 2014-02-04 05:13:11 - TZ=UTC TB --- 2014-02-04 05:13:11 - __MAKE_CONF=/dev/null TB --- 2014-02-04 05:13:11 - cd /src TB --- 2014-02-04 05:13:11 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Feb 4 05:13:11 UTC 2014 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /src/sys/arm/conf; PATH=/obj/arm.arm/src/tmp/legacy/usr/sbin:/obj/arm.arm/src/tmp/legacy/usr/bin:/obj/arm.arm/src/tmp/legacy/usr/games:/obj/arm.arm/src/tmp/legacy/bin:/obj/arm.arm/src/tmp/usr/sbin:/obj/arm.arm/src/tmp/usr/bin:/obj/arm.arm/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /obj/arm.arm/src/sys/LINT /src/sys/arm/conf/LINT WARNING: duplicate option `GEOM_PART_BSD' encountered. WARNING: duplicate option `GEOM_PART_MBR' encountered. WARNING: duplicate option `DEV_MEM' encountered. WARNING: duplicate device `mem' encountered. WARNING: duplicate option `CAM_DEBUG_DELAY' encountered. standard entry arm/econa/ehci_ebus.c has optional inclusion specifier ehci! *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-02-04 05:13:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-04 05:13:12 - ERROR: failed to build LINT kernel TB --- 2014-02-04 05:13:12 - 8746.76 user 1635.26 system 10968.73 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Feb 4 05:23:05 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 26B05CF7 for ; Tue, 4 Feb 2014 05:23:05 +0000 (UTC) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DBBA51355 for ; Tue, 4 Feb 2014 05:23:04 +0000 (UTC) Received: by mail-ig0-f172.google.com with SMTP id k19so6389258igc.5 for ; Mon, 03 Feb 2014 21:22:57 -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=2kaWvgKG10ImwY7mkC+lYOsdye09YcvlZelee2aj6Fs=; b=BZZJFgTv9JX2blzveDYaohiekDq0DuWk9cbS/BLoN9RSQ5IkKNj4LWC1athWNTB4X4 J4d6I9DbVNyGgHgRmwf3eIBbypw4UC7X0F4kvhY7w2d0xVb13CC3UpjXh7sTrk8A/sIy kUQ3XlwdNdKiGZPmqI62fwLNa9hDBVs9yDFq+81KYS2qy99C8cG1blWESWDPGAkGzmlX k7EWx8RlhkfN0BklNZ7UAzRwCFREmec2NAkKC9OBksSo2OnnRULsMBQAbLL7+nlOEPUW bv6qPgt/+GqMgNBupok+H1iVSHKsgetlaL6gM3lf4ib/ibEn76Vz+GthIqr6DNcAtwiP /6nA== X-Gm-Message-State: ALoCoQnmyZSVyfku3DdhZ1k9kBLwO+c+1KFrEhR8TFgk5CqoFqzFXqINuYz2BbiHYOZ+wC8A8sbX X-Received: by 10.50.117.5 with SMTP id ka5mr15408902igb.3.1391491377806; Mon, 03 Feb 2014 21:22:57 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id kt2sm45345980igb.1.2014.02.03.21.22.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Feb 2014 21:22:57 -0800 (PST) Sender: Warner Losh Subject: Re: wandboard / imx6 / exynos4 / cortex-a9 "wrong-endian bug" fixed Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: <2BDF104B-16DE-4488-9870-148843D8CC2F@kientzle.com> Date: Mon, 3 Feb 2014 22:22:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1391371204.13026.43.camel@revolution.hippie.lan> <20140202230450.GA42331@cicely7.cicely.de> <1391395062.13026.69.camel@revolution.hippie.lan> <1584FD9C-581F-4BCF-8153-E381693887DB@bsdimp.com> <2BDF104B-16DE-4488-9870-148843D8CC2F@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) Cc: freebsd-arm , Bernd Walter , ticso@cicely.de, Ian Lepore 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: Tue, 04 Feb 2014 05:23:05 -0000 On Feb 3, 2014, at 9:59 PM, Tim Kientzle wrote: >=20 > On Feb 2, 2014, at 6:59 PM, Warner Losh wrote: >=20 >>=20 >> On Feb 2, 2014, at 7:37 PM, Ian Lepore wrote: >>=20 >>> On Sun, 2014-02-02 at 18:25 -0700, Tom Everett wrote: >>>> I can confirm that a crochet image for Wandboard no longer crashes = after >>>> this fix. It doesn't mount the FS yet, but that's a known issue, = noted >>>> here: >>>>=20 >>>> https://github.com/kientzle/crochet-freebsd/issues/29 >>>=20 >>> That thread mentions needing to build a u-boot for wandboard. = Here's a >>> patchset for doing that. Apply this in your ports/sysutils dir, = using: >>>=20 >>> patch -p0 >>=20 >>> This was copied from Tim's beaglebone work and changed a bit for >>> wandboard. =20 >>>=20 >>> I've been meaning to ask about how we should handle this. Do we = want a >>> u-boot port for every board, or is there some way to parameterize a >>> single port so that it applies the right set of patches, or what? = I'm >>> not very savvy about ports. >>=20 >> Usually there's a master port, and slave ports that parameterize. = When we talked about this at BSDcan, I believe that was the model that = was suggested for this problem.. >=20 > Does that work when there=92s a different source distro for > many of the ports? (Not to mention different patches for > each one.) Yes, but there may be complications... > P.S. I started a U-Boot port for BeagleBone but my > time has evaporated. If anyone wants to take that > over and extend it for other boards, step right up=85 ENOTIME... Warner= From owner-freebsd-arm@FreeBSD.ORG Tue Feb 4 07:35:29 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 33AD39C6 for ; Tue, 4 Feb 2014 07:35:29 +0000 (UTC) Received: from hal.g7iii.net (unknown [IPv6:2600:3c02::f03c:91ff:feae:1cbe]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F16411C06 for ; Tue, 4 Feb 2014 07:35:28 +0000 (UTC) Received: from [192.168.39.76] (157.17.187.81.in-addr.arpa [81.187.17.157]) by hal.g7iii.net (Postfix) with ESMTP id A0AD920A70 for ; Tue, 4 Feb 2014 07:35:19 +0000 (UTC) Message-ID: <52F09836.5070505@g7iii.net> Date: Tue, 04 Feb 2014 07:35:18 +0000 From: Iain Young User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: Turning WITNESS off on Beaglebone Black Content-Type: multipart/mixed; boundary="------------090600090001030802010901" 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: Tue, 04 Feb 2014 07:35:29 -0000 This is a multi-part message in MIME format. --------------090600090001030802010901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Folks, Anyone else having issues on the Beaglebone Black when disabling WITNESS ? This is on 11.0-CURRENT, r261200. I saw it a few weeks ago, as well, but got busy and decided to wait for the snapshots and try again. On mine, it gets as far as this line, and waits a few tens of seconds: ustorage_fs0: on usbus0 And then prints this: random: unblocking device. Followed by absolutely nothing until I reboot. On a WITNESS enabled kernel, it then proceeds to warn me about WITNESS and performance, before going on to mount the root file system, and bring up user space: WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... Curiously, it looks like the non-WITNESS kernel is also not finding the onboard MMC, so that might be relevant. In my case, I don't actually use it, so if it doesn't see it, it's not an issue for me Anyone know what I'm not doing right ? I -thought- all I had to do to turn WITNESS off was comment out the options line in my conf file, and I'm sure it worked on the BBW a year or so back. I've attached the two dmesg outputs as well as the conf used, but as I say, it's stock, with the exception of WITNESS being turned off. Iain PS, About a year ago, we mentioned IEEE1588 and the cpsw driver, a quick grep through /usr/src/sys showed the following drivers had the "IEEE1588" string in them: e1000 (/dev/e1000/*.h) IXGBE (/dev/ixgbe/*) NLM (/dev/mipd/nlm/board.[cv] No idea how functional each one is, but if anyone was thinking about adding 1588 support to the cpsw, might be useful - Unfortunately it's a little beyond my skillset --------------090600090001030802010901 Content-Type: text/plain; charset=UTF-8; name="BEAGLEBONE-TARDIS.kernconf.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="BEAGLEBONE-TARDIS.kernconf.txt" # BEAGLEBONE -- Custom configuration for the BeagleBone ARM development # platforms, check out http://www.beagleboard.org/bone and # http://www.beagleboard.org/black. This kernel config file is used for the # original BeagleBone and the BeagleBone Black. # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: head/sys/arm/conf/BEAGLEBONE 258393 2013-11-20 16:42:01Z ian $ ident BEAGLEBONE include "../ti/am335x/std.beaglebone" makeoptions WITHOUT_MODULES="ahc" options HZ=100 options SCHED_4BSD #4BSD scheduler options INET #InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework options TMPFS #Efficient memory filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options PREEMPTION options FREEBSD_BOOT_LOADER options VFP # vfp/neon # Debugging makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options BREAK_TO_DEBUGGER #options VERBOSE_SYSINIT #Enable verbose sysinit messages options KDB options DDB #Enable the kernel debugger options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS #Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN #Don't run witness on spinlocks for speed #options DIAGNOSTIC # NFS support options NFSCL #options NFSD options NFSLOCKD # Uncomment this for NFS root #options NFS_ROOT #NFS usable as /, requires NFSCL #options BOOTP_NFSROOT #options BOOTP_COMPAT #options BOOTP #options BOOTP_NFSV3 #options BOOTP_WIRED_TO=cpsw0 # MMC/SD/SDIO card slot support device mmc # mmc/sd bus device mmcsd # mmc/sd flash cards device sdhci # mmc/sd host controller # Boot device is 2nd slice on MMC/SD card options ROOTDEVNAME=\"ufs:mmcsd0s2\" # Console and misc device uart device uart_ns8250 device pty device snp device md device random # Entropy device # I2C support device iicbus device iic device ti_i2c device am335x_pmic # AM335x Power Management IC (TPC65217) # GPIO device gpio # USB support device usb options USB_HOST_ALIGN=64 # Cacheline size is 64 on AM335x. options USB_DEBUG #options USB_REQ_DEBUG #options USB_VERBOSE device musb device umass device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) # Ethernet device loop device ether device mii device smscphy device cpsw device bpf # USB ethernet support, requires miibus device miibus device axe # ASIX Electronics USB Ethernet # Device mode support and USFS template device usb_template # Control of the gadget device usfs # Flattened Device Tree options FDT options FDT_DTB_STATIC makeoptions FDT_DTS_FILE=beaglebone.dts --------------090600090001030802010901-- From owner-freebsd-arm@FreeBSD.ORG Tue Feb 4 12:25:11 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 7ED3C1D6; Tue, 4 Feb 2014 12:25:11 +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 B0D84168F; Tue, 4 Feb 2014 12:25:10 +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 s14CP6me067408; Tue, 4 Feb 2014 14:25:06 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s14CP62U067407; Tue, 4 Feb 2014 12:25:06 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 4 Feb 2014 12:25:06 GMT Message-Id: <201402041225.s14CP62U067407@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: Tue, 04 Feb 2014 12:25:11 -0000 TB --- 2014-02-04 08:40:44 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-02-04 08:40:44 - 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-02-04 08:40:44 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-02-04 08:40:44 - cleaning the object tree TB --- 2014-02-04 08:40:44 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-02-04 08:41:35 - At svn revision 261464 TB --- 2014-02-04 08:41:36 - building world TB --- 2014-02-04 08:41:36 - CROSS_BUILD_TESTING=YES TB --- 2014-02-04 08:41:36 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-04 08:41:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-04 08:41:36 - SRCCONF=/dev/null TB --- 2014-02-04 08:41:36 - TARGET=arm TB --- 2014-02-04 08:41:36 - TARGET_ARCH=arm TB --- 2014-02-04 08:41:36 - TZ=UTC TB --- 2014-02-04 08:41:36 - __MAKE_CONF=/dev/null TB --- 2014-02-04 08:41:36 - cd /src TB --- 2014-02-04 08:41:36 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Feb 4 08:41:47 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 Tue Feb 4 12:08:31 UTC 2014 TB --- 2014-02-04 12:08:31 - generating LINT kernel config TB --- 2014-02-04 12:08:31 - cd /src/sys/arm/conf TB --- 2014-02-04 12:08:31 - /usr/bin/make -B LINT TB --- 2014-02-04 12:08:31 - cd /src/sys/arm/conf TB --- 2014-02-04 12:08:31 - /usr/sbin/config -m LINT TB --- 2014-02-04 12:08:31 - building LINT kernel TB --- 2014-02-04 12:08:31 - CROSS_BUILD_TESTING=YES TB --- 2014-02-04 12:08:31 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-04 12:08:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-04 12:08:31 - SRCCONF=/dev/null TB --- 2014-02-04 12:08:31 - TARGET=arm TB --- 2014-02-04 12:08:31 - TARGET_ARCH=arm TB --- 2014-02-04 12:08:31 - TZ=UTC TB --- 2014-02-04 12:08:31 - __MAKE_CONF=/dev/null TB --- 2014-02-04 12:08:31 - cd /src TB --- 2014-02-04 12:08:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Feb 4 12:08:31 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 >>> stage 3.2: building everything [...] cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/arm/cpufunc_asm_armv5_ec.S cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/arm/cpufunc_asm_armv7.S cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/arm/cpufunc_asm_sheeva.S cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/arm/cpufunc_asm_pj4b.S /src/sys/arm/arm/cpufunc_asm_pj4b.S: Assembler messages: /src/sys/arm/arm/cpufunc_asm_pj4b.S:240: Error: missing ')' /src/sys/arm/arm/cpufunc_asm_pj4b.S:240: Error: garbage following instruction -- `orr r0,r0,#(1U<<31)' cc: error: assembler command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-02-04 12:25:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-04 12:25:06 - ERROR: failed to build LINT kernel TB --- 2014-02-04 12:25:06 - 10016.48 user 3379.86 system 13462.64 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Feb 4 17:53: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 639EA8BA for ; Tue, 4 Feb 2014 17:53:37 +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 374E31769 for ; Tue, 4 Feb 2014 17:53:37 +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 1WAkBj-000IZI-Vs; Tue, 04 Feb 2014 17:53:36 +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 s14HrWNt064996; Tue, 4 Feb 2014 10:53:33 -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/wbZjENn+yhE5qXQaJgPkI Subject: Re: Turning WITNESS off on Beaglebone Black From: Ian Lepore To: Iain Young In-Reply-To: <52F09836.5070505@g7iii.net> References: <52F09836.5070505@g7iii.net> Content-Type: text/plain; charset="us-ascii" Date: Tue, 04 Feb 2014 10:53:32 -0700 Message-ID: <1391536412.1196.4.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: Tue, 04 Feb 2014 17:53:37 -0000 On Tue, 2014-02-04 at 07:35 +0000, Iain Young wrote: > Hi Folks, > > Anyone else having issues on the Beaglebone Black when disabling > WITNESS ? This is on 11.0-CURRENT, r261200. I saw it a few weeks > ago, as well, but got busy and decided to wait for the snapshots > and try again. > > On mine, it gets as far as this line, and waits a few tens of seconds: > > ustorage_fs0: on usbus0 > > And then prints this: > > random: unblocking device. > > > Followed by absolutely nothing until I reboot. On a WITNESS > enabled kernel, it then proceeds to warn me about WITNESS and > performance, before going on to mount the root file system, and > bring up user space: > > WARNING: WITNESS option enabled, expect reduced performance. > Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... > > > Curiously, it looks like the non-WITNESS kernel is also not > finding the onboard MMC, so that might be relevant. In my > case, I don't actually use it, so if it doesn't see it, it's > not an issue for me > > Anyone know what I'm not doing right ? I -thought- all I had > to do to turn WITNESS off was comment out the options line > in my conf file, and I'm sure it worked on the BBW a year or > so back. > > I've attached the two dmesg outputs as well as the conf > used, but as I say, it's stock, with the exception of > WITNESS being turned off. > > > Iain > > PS, About a year ago, we mentioned IEEE1588 and the cpsw driver, > a quick grep through /usr/src/sys showed the following drivers > had the "IEEE1588" string in them: > > e1000 (/dev/e1000/*.h) > IXGBE (/dev/ixgbe/*) > NLM (/dev/mipd/nlm/board.[cv] > > No idea how functional each one is, but if anyone was thinking > about adding 1588 support to the cpsw, might be useful - Unfortunately > it's a little beyond my skillset I can't reproduce this on a BBW at the same os rev, but I use an nfs root, which is probably a significant difference. The fact that yours is failing to find the eMMC in the fail case may be significant too... if the sdhci controller is hung up somehow you'd fail to mount root (but then why doesn't that time out and give an error?) -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Feb 4 18:20:31 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 639) id C36F8F9E; Tue, 4 Feb 2014 18:20:31 +0000 (UTC) Date: Tue, 4 Feb 2014 18:20:31 +0000 From: Olivier Houchard To: Iain Young Subject: Re: Turning WITNESS off on Beaglebone Black Message-ID: <20140204182031.GA65637@freebsd.org> References: <52F09836.5070505@g7iii.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52F09836.5070505@g7iii.net> 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 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 18:20:31 -0000 On Tue, Feb 04, 2014 at 07:35:18AM +0000, Iain Young wrote: > Hi Folks, > Hi Iain, > Anyone else having issues on the Beaglebone Black when disabling > WITNESS ? This is on 11.0-CURRENT, r261200. I saw it a few weeks > ago, as well, but got busy and decided to wait for the snapshots > and try again. > Can you upgrade your sources and try again ? r261414 may fix this. Thanks ! Olivier From owner-freebsd-arm@FreeBSD.ORG Tue Feb 4 19:12:01 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 297E6A01; Tue, 4 Feb 2014 19:12:01 +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 EFFAA1FB5; Tue, 4 Feb 2014 19:12:00 +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 1WAlPb-0001go-MN; Tue, 04 Feb 2014 19:11:59 +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 s14JBu1G065053; Tue, 4 Feb 2014 12:11:56 -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/ULsHhPM9fEha1hVAXLZhE Subject: Re: Turning WITNESS off on Beaglebone Black From: Ian Lepore To: Olivier Houchard In-Reply-To: <20140204182031.GA65637@freebsd.org> References: <52F09836.5070505@g7iii.net> <20140204182031.GA65637@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Tue, 04 Feb 2014 12:11:56 -0700 Message-ID: <1391541116.1196.7.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: Tue, 04 Feb 2014 19:12:01 -0000 On Tue, 2014-02-04 at 18:20 +0000, Olivier Houchard wrote: > On Tue, Feb 04, 2014 at 07:35:18AM +0000, Iain Young wrote: > > Hi Folks, > > > > Hi Iain, > > > Anyone else having issues on the Beaglebone Black when disabling > > WITNESS ? This is on 11.0-CURRENT, r261200. I saw it a few weeks > > ago, as well, but got busy and decided to wait for the snapshots > > and try again. > > > > Can you upgrade your sources and try again ? r261414 may fix this. > > Thanks ! > > Olivier I don't think it'll help, beaglebone doesn't use ti_mmchs, it uses ti_sdhci. But updating to the latest is never a bad idea when looking into this sort of problem. Hmm, it's also possible to switch beaglebone to ti_mmchs just to see if that changes things, which you can do like this: Index: sys/arm/ti/am335x/files.am335x =================================================================== --- sys/arm/ti/am335x/files.am335x (revision 261491) +++ sys/arm/ti/am335x/files.am335x (working copy) @@ -9,6 +9,6 @@ arm/ti/am335x/am335x_lcd_syscons.c optional sc arm/ti/am335x/am335x_pwm.c standard arm/ti/am335x/am335x_usbss.c optional musb fdt arm/ti/ti_edma3.c standard -arm/ti/ti_sdhci.c optional sdhci -#arm/ti/ti_mmchs.c optional mmc +#arm/ti/ti_sdhci.c optional sdhci +arm/ti/ti_mmchs.c optional mmc arm/ti/cpsw/if_cpsw.c optional cpsw -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Feb 4 19:54:58 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 31FF9D70; Tue, 4 Feb 2014 19:54:58 +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 654B713AB; Tue, 4 Feb 2014 19:54:56 +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 s14JssQx064142; Tue, 4 Feb 2014 21:54:54 +0200 (SAST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by worker01.tb.des.no (8.14.5/8.14.5/Submit) id s14Jsskr064140; Tue, 4 Feb 2014 19:54:54 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 4 Feb 2014 19:54:54 GMT Message-Id: <201402041954.s14Jsskr064140@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: Tue, 04 Feb 2014 19:54:58 -0000 TB --- 2014-02-04 16:10:43 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2014-02-04 16:10:43 - 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-02-04 16:10:43 - starting RELENG_10 tinderbox run for arm/arm TB --- 2014-02-04 16:10:43 - cleaning the object tree TB --- 2014-02-04 16:11:35 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-02-04 16:11:43 - At svn revision 261488 TB --- 2014-02-04 16:11:44 - building world TB --- 2014-02-04 16:11:44 - CROSS_BUILD_TESTING=YES TB --- 2014-02-04 16:11:44 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-04 16:11:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-04 16:11:44 - SRCCONF=/dev/null TB --- 2014-02-04 16:11:44 - TARGET=arm TB --- 2014-02-04 16:11:44 - TARGET_ARCH=arm TB --- 2014-02-04 16:11:44 - TZ=UTC TB --- 2014-02-04 16:11:44 - __MAKE_CONF=/dev/null TB --- 2014-02-04 16:11:44 - cd /src TB --- 2014-02-04 16:11:44 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Feb 4 16:11:54 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 Tue Feb 4 19:38:14 UTC 2014 TB --- 2014-02-04 19:38:14 - generating LINT kernel config TB --- 2014-02-04 19:38:14 - cd /src/sys/arm/conf TB --- 2014-02-04 19:38:14 - /usr/bin/make -B LINT TB --- 2014-02-04 19:38:14 - cd /src/sys/arm/conf TB --- 2014-02-04 19:38:14 - /usr/sbin/config -m LINT TB --- 2014-02-04 19:38:14 - building LINT kernel TB --- 2014-02-04 19:38:14 - CROSS_BUILD_TESTING=YES TB --- 2014-02-04 19:38:14 - MAKEOBJDIRPREFIX=/obj TB --- 2014-02-04 19:38:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-02-04 19:38:14 - SRCCONF=/dev/null TB --- 2014-02-04 19:38:14 - TARGET=arm TB --- 2014-02-04 19:38:14 - TARGET_ARCH=arm TB --- 2014-02-04 19:38:14 - TZ=UTC TB --- 2014-02-04 19:38:14 - __MAKE_CONF=/dev/null TB --- 2014-02-04 19:38:14 - cd /src TB --- 2014-02-04 19:38:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Feb 4 19:38:14 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 >>> stage 3.2: building everything [...] cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/arm/cpufunc_asm_armv5_ec.S cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/arm/cpufunc_asm_armv7.S cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/arm/cpufunc_asm_sheeva.S cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -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/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/arm/arm/cpufunc_asm_pj4b.S /src/sys/arm/arm/cpufunc_asm_pj4b.S: Assembler messages: /src/sys/arm/arm/cpufunc_asm_pj4b.S:240: Error: missing ')' /src/sys/arm/arm/cpufunc_asm_pj4b.S:240: Error: garbage following instruction -- `orr r0,r0,#(1U<<31)' cc: error: assembler command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** [buildkernel] Error code 1 Stop in /src. TB --- 2014-02-04 19:54:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-02-04 19:54:54 - ERROR: failed to build LINT kernel TB --- 2014-02-04 19:54:54 - 10009.32 user 3389.44 system 13450.56 real http://tinderbox.des.no/tinderbox-freebsd10-build-RELENG_10-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Feb 5 16:20:00 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 950394B3 for ; Wed, 5 Feb 2014 16:20:00 +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 6FA181AC9 for ; Wed, 5 Feb 2014 16:20:00 +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 s15GK0Sk036939 for ; Wed, 5 Feb 2014 16:20:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s15GK031036938; Wed, 5 Feb 2014 16:20:00 GMT (envelope-from gnats) Resent-Date: Wed, 5 Feb 2014 16:20:00 GMT Resent-Message-Id: <201402051620.s15GK031036938@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-arm@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, pavan kumar 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 C6A51C7E for ; Wed, 5 Feb 2014 16:12:25 +0000 (UTC) Received: from newred.freebsd.org (oldred.freebsd.org [IPv6:2001:1900:2254:206a::50:4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B100C1A3E for ; Wed, 5 Feb 2014 16:12:25 +0000 (UTC) Received: from newred.freebsd.org ([127.0.1.6]) by newred.freebsd.org (8.14.7/8.14.7) with ESMTP id s15GCPpR046882 for ; Wed, 5 Feb 2014 16:12:25 GMT (envelope-from nobody@newred.freebsd.org) Received: (from nobody@localhost) by newred.freebsd.org (8.14.7/8.14.7/Submit) id s15GCPnM046875; Wed, 5 Feb 2014 16:12:25 GMT (envelope-from nobody) Message-Id: <201402051612.s15GCPnM046875@newred.freebsd.org> Date: Wed, 5 Feb 2014 16:12:25 GMT From: pavan kumar To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: arm/186486: WPS authentication is failing 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, 05 Feb 2014 16:20:00 -0000 >Number: 186486 >Category: arm >Synopsis: WPS authentication is failing >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Feb 05 16:20:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: pavan kumar >Release: >Organization: infosolutions >Environment: >Description: wlan0: Selecting BSS from priority group 0 wlan0: 0: 00:18:e7:de:af:6c ssid='PAVAN_2_4G' wpa_ie_len=0 rsn_ie_len=20 caps=0x11 level=-32 wps selected based on WPS IE (Active PBC) wlan0: selected BSS 00:18:e7:de:af:6c ssid='PAVAN_2_4G' WPS: Check whether PBC session overlap is present in scan results; selected BSSID 00:18:e7:de:af:6c WPS: UUID of the selected BSS - hexdump(len=16): b1 4e 00 3a ce 92 3d 50 9d 95 f9 dd 69 ce ed ab wlan0: Request association: reassociate: 1 selected: 00:18:e7:de:af:6c bssid: 00:00:00:00:00:00 pending: 00:00:00:00:00:00 wpa_state: SCANNING wlan0: Trying to associate with 00:18:e7:de:af:6c (SSID='PAVAN_2_4G' freq=2447 MHz) CTRL_IFACE monitor send - hexdump(len=20): 2f 74 6d 70 2f 77 70 61 5f 63 74 72 6c 5f 39 35 39 2d 32 00 CTRL_IFACE monitor send - hexdump(len=20): 2f 74 6d 70 2f 77 70 61 5f 63 74 72 6c 5f 38 33 30 2d 32 00 wlan0: Cancelling scan request wlan0: WPA: clearing own WPA/RSN IE wlan0: Automatic auth_alg selection: 0x1 WPA: Set WPS IE Device PWD 1 WPS: Building WPS IE for (Re)Association Request WPS: * Version (hardcoded 0x10) WPS: * Request Type WPS: * Device Password ID (4) wlan0: WPA: clearing AP WPA IE wlan0: WPA: clearing AP RSN IE wlan0: WPA: clearing own WPA/RSN IE wlan0: No keys have been configured - skip key clearing wlan0: State: SCANNING -> ASSOCIATING wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT) netlink: Operstate: linkmode=-1, operstate=5 Limit connection to BSSID 00:18:e7:de:af:6c freq=2447 MHz based on scan results (bssid_set=0) wpa_driver_wext_associate wpa_driver_wext_set_drop_unencrypted wpa_driver_wext_set_psk wlan0: Setting authentication timeout: 10 sec 0 usec EAPOL: External notification - EAP success=0 EAPOL: Supplicant port status: Unauthorized EAPOL: External notification - EAP fail=0 EAPOL: Supplicant port status: Unauthorized EAPOL: External notification - portControl=Auto EAPOL: Supplicant port status: Unauthorized RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) Wireless event: cmd=0x8b1a len=8 RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) Wireless event: cmd=0x8b06 len=8 RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) 122918978-------> >-- 228*10 sec --< Wireless event: cmd=0x8b04 len=12 RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) Wireless event: cmd=0x8b1a len=18 RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) Wireless event: cmd=0x8c02 len=22 RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) Wireless event: cmd=0x8c02 len=22 wlan0: Authentication with 00:18:e7:de:af:6c timed out. CTRL_IFACE monitor send - hexdump(len=20): 2f 74 6d 70 2f 77 70 61 5f 63 74 72 6c 5f 39 35 39 2d 32 00 CTRL_IFACE monitor send - hexdump(len=20): 2f 74 6d 70 2f 77 70 61 5f 63 74 72 6c 5f 38 33 30 2d 32 00 Added BSSID 00:18:e7:de:af:6c into blacklist wlan0: No keys have been configured - skip key clearing wlan0: State: ASSOCIATING -> DISCONNECTED wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT) netlink: Operstate: linkmode=-1, operstate=5 EAPOL: External notification - portEnabled=0 EAPOL: Supplicant port status: Unauthorized EAPOL: External notification - portValid=0 EAPOL: Supplicant port status: Unauthorized wlan0: Setting scan request: 1 sec 0 usec 122929018-------> >-- 229*10 sec --< wlan0: State: DISCONNECTED -> SCANNING wlan0: Starting AP scan for wildcard SSID WPS: Building WPS IE for Probe Request WPS: * Version (hardcoded 0x10) WPS: * Request Type WPS: * Config Methods (108) WPS: * UUID-E WPS: * Primary Device Type WPS: * RF Bands (3) WPS: * Association State WPS: * Configuration Error (0) WPS: * Device Password ID (4) Scan requested (ret=0) - scan timeout 30 seconds >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Thu Feb 6 18:53:46 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 292AFCEE; Thu, 6 Feb 2014 18:53:46 +0000 (UTC) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002: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 C03F31899; Thu, 6 Feb 2014 18:53:45 +0000 (UTC) Received: by mail-yh0-f53.google.com with SMTP id v1so2201331yhn.12 for ; Thu, 06 Feb 2014 10:53:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=DCEdCim3VhC8GO1P2Idv7sb4jXpdtnFbkmoLQm4VvSk=; b=u71oNAfkmVzNKKN4uFI3dApYNNn/YWHT+CFau6ntFc40kiM0VAy9TPMyjfvaCSbz8V stc5FH/uRTEBikXtTY35Fnm6D1ZKn0CPEftWeJhSQZBCDqZqgiB5yJsReNDP+ef12DQT bjobZlyWzVSHXYK3gsYPHjXEfm+fc4EalqRzh/wipFrILlG4AynEnBb8jZrx94UxLtdL XpGlNhcjwRTBqDqEl97OgWsbMidlO8WRUENHZ1So23RyK5OxH6rKxafQ5ji94/AKPCEQ i/wosN5uAVwMifpoNvltVOxIkWmXtxwJ2xDzbtg4DAhkWbd7lFks7EYjE2hmrbL1kXAX GCjg== X-Received: by 10.236.77.231 with SMTP id d67mr1456644yhe.113.1391712818052; Thu, 06 Feb 2014 10:53:38 -0800 (PST) Received: from [192.168.1.13] ([187.120.137.162]) by mx.google.com with ESMTPSA id h66sm4970600yhb.7.2014.02.06.10.53.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Feb 2014 10:53:36 -0800 (PST) From: Luiz Otavio O Souza Content-Type: multipart/mixed; boundary="Apple-Mail=_23B096DF-2D6A-4DAD-91F4-17F5ECEED328" Subject: FDT/OFW GPIO bus Message-Id: <2D5F2707-FD55-46BB-A44F-8870B48E2BB1@gmail.com> Date: Thu, 6 Feb 2014 16:53:27 -0200 To: freebsd-embedded@freebsd.org, freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) 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: Thu, 06 Feb 2014 18:53:46 -0000 --Apple-Mail=_23B096DF-2D6A-4DAD-91F4-17F5ECEED328 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello guys, Last call for alcohol^Wtest and reviews. I=92ve finally managed to test these changes on a some FDT and non FDT = systems, so now it is all cleared to commit. I plan to commit these changes on the weekend unless someone objects. They add support to describe GPIO connections on the DTS files. It also = add the support to the in tree GPIO devices (gpioiic(4), gpioled(4)). The last patch (005-bbb-gpioled.diff) sets the gpioled(4) for the 4 on = board LEDs on BBB (beaglebone-black). The RPi led is already set and = just need the first patch (001-ofw-gpiobus.diff) to work. The tests were done on RPi and BBB using I2C devices (two lm75 on the = same bus), LEDs (for gpioled(4)) and even with some non committed = ethernet over SPI. The I2C tests are conducted using the hardware I2C = controller (when available) and also the software big bang controller - = gpioiic(4). I used the RSPRO (MIPS/ar71xx) to check for regressions without any = visible problem. gpioiic(4) devices can be described in DTS as follow: gpio { gpioiic { compatible =3D "gpioiic"; gpios =3D <&gpio 17 2 0 &gpio 21 2 0>; scl =3D <0>; sda =3D <1>; lm750 { compatible =3D "lm75"; i2c-address =3D <0x4b>; }; lm751 { compatible =3D "lm75"; i2c-address =3D <0x4f>; }; }; }; gpioled(4) devices can be described in two ways: - directly under the GPIO controller node: gpio { led0 { compatible =3D "gpioled"; gpios =3D <&gpio 16 2 0>; label =3D "ok"; }; led1 { compatible =3D "gpioled"; gpios =3D <&gpio 17 2 0>; name =3D "user-led1"; }; }; - Or under a single =93gpio-leds=94 node: leds { compatible =3D "gpio-leds"; led1 { gpios =3D <&GPIO 53 2 0>; name =3D "led1"; }; led2 { gpios =3D <&GPIO 54 2 0>; name =3D "led2"; }; }; gpioiic(4) and gpioled(4) man pages were updated to cover FDT/OFW based = systems. =46rom the latest patchset (published on freebsd-arch@ and freebsd-arm@) = i removed the check for disabled devices on DTS as this seems to = indicate that the device needs special attention but should not be = skipped at attach time. Please let me know if there are problems or concerns with the following = changes. Thanks, Luiz --Apple-Mail=_23B096DF-2D6A-4DAD-91F4-17F5ECEED328 Content-Disposition: attachment; filename=001-ofw-gpiobus.diff Content-Type: application/octet-stream; name="001-ofw-gpiobus.diff" Content-Transfer-Encoding: 7bit Index: sys/conf/files =================================================================== --- sys/conf/files (revision 261556) +++ sys/conf/files (working copy) @@ -1400,6 +1400,7 @@ dev/gpio/gpioled.c optional gpioled dev/gpio/gpio_if.m optional gpio dev/gpio/gpiobus_if.m optional gpio +dev/gpio/ofw_gpiobus.c optional fdt gpio dev/hatm/if_hatm.c optional hatm pci dev/hatm/if_hatm_intr.c optional hatm pci dev/hatm/if_hatm_ioctl.c optional hatm pci Index: sys/dev/gpio/gpiobus.c =================================================================== --- sys/dev/gpio/gpiobus.c (revision 261556) +++ sys/dev/gpio/gpiobus.c (working copy) @@ -46,7 +46,6 @@ #include "gpio_if.h" #include "gpiobus_if.h" -static void gpiobus_print_pins(struct gpiobus_ivar *); static int gpiobus_parse_pins(struct gpiobus_softc *, device_t, int); static int gpiobus_probe(device_t); static int gpiobus_attach(device_t); @@ -73,17 +72,7 @@ static int gpiobus_pin_get(device_t, device_t, uint32_t, unsigned int*); static int gpiobus_pin_toggle(device_t, device_t, uint32_t); -#define GPIOBUS_LOCK(_sc) mtx_lock(&(_sc)->sc_mtx) -#define GPIOBUS_UNLOCK(_sc) mtx_unlock(&(_sc)->sc_mtx) -#define GPIOBUS_LOCK_INIT(_sc) \ - mtx_init(&_sc->sc_mtx, device_get_nameunit(_sc->sc_dev), \ - "gpiobus", MTX_DEF) -#define GPIOBUS_LOCK_DESTROY(_sc) mtx_destroy(&_sc->sc_mtx); -#define GPIOBUS_ASSERT_LOCKED(_sc) mtx_assert(&_sc->sc_mtx, MA_OWNED); -#define GPIOBUS_ASSERT_UNLOCKED(_sc) mtx_assert(&_sc->sc_mtx, MA_NOTOWNED); - - -static void +void gpiobus_print_pins(struct gpiobus_ivar *devi) { int range_start, range_stop, need_coma; Index: sys/dev/gpio/gpiobusvar.h =================================================================== --- sys/dev/gpio/gpiobusvar.h (revision 261556) +++ sys/dev/gpio/gpiobusvar.h (working copy) @@ -30,13 +30,26 @@ #ifndef __GPIOBUS_H__ #define __GPIOBUS_H__ +#include "opt_platform.h" + #include #include #include -#define GPIOBUS_IVAR(d) (struct gpiobus_ivar *) device_get_ivars(d) -#define GPIOBUS_SOFTC(d) (struct gpiobus_softc *) device_get_softc(d) +#ifdef FDT +#include +#endif +#define GPIOBUS_IVAR(d) (struct gpiobus_ivar *) device_get_ivars(d) +#define GPIOBUS_SOFTC(d) (struct gpiobus_softc *) device_get_softc(d) +#define GPIOBUS_LOCK(_sc) mtx_lock(&(_sc)->sc_mtx) +#define GPIOBUS_UNLOCK(_sc) mtx_unlock(&(_sc)->sc_mtx) +#define GPIOBUS_LOCK_INIT(_sc) mtx_init(&_sc->sc_mtx, \ + device_get_nameunit(_sc->sc_dev), "gpiobus", MTX_DEF) +#define GPIOBUS_LOCK_DESTROY(_sc) mtx_destroy(&_sc->sc_mtx) +#define GPIOBUS_ASSERT_LOCKED(_sc) mtx_assert(&_sc->sc_mtx, MA_OWNED) +#define GPIOBUS_ASSERT_UNLOCKED(_sc) mtx_assert(&_sc->sc_mtx, MA_NOTOWNED) + struct gpiobus_softc { struct mtx sc_mtx; /* bus mutex */ @@ -54,4 +67,11 @@ uint32_t *pins; /* pins map */ }; +void gpiobus_print_pins(struct gpiobus_ivar *); +#ifdef FDT +device_t ofw_gpiobus_add_fdt_child(device_t, phandle_t); +#endif + +extern driver_t gpiobus_driver; + #endif /* __GPIOBUS_H__ */ Index: sys/dev/gpio/gpioiic.c =================================================================== --- sys/dev/gpio/gpioiic.c (revision 261556) +++ sys/dev/gpio/gpioiic.c (working copy) @@ -28,6 +28,8 @@ #include __FBSDID("$FreeBSD$"); +#include "opt_platform.h" + #include #include #include @@ -38,6 +40,12 @@ #include #include "gpiobus_if.h" +#ifdef FDT +#include +#include +#include +#endif + #include #include @@ -71,6 +79,10 @@ gpioiic_probe(device_t dev) { +#ifdef FDT + if (!ofw_bus_is_compatible(dev, "gpioiic")) + return (ENXIO); +#endif device_set_desc(dev, "GPIO I2C bit-banging driver"); return (0); @@ -81,6 +93,10 @@ { struct gpioiic_softc *sc = device_get_softc(dev); device_t bitbang; +#ifdef FDT + phandle_t node; + pcell_t pin; +#endif sc->sc_dev = dev; sc->sc_busdev = device_get_parent(dev); @@ -91,6 +107,15 @@ device_get_unit(dev), "sda", &sc->sda_pin)) sc->sda_pin = SDA_PIN_DEFAULT; +#ifdef FDT + if ((node = ofw_bus_get_node(dev)) == -1) + return (ENXIO); + if (OF_getencprop(node, "scl", &pin, sizeof(pin)) > 0) + sc->scl_pin = (int)pin; + if (OF_getencprop(node, "sda", &pin, sizeof(pin)) > 0) + sc->sda_pin = (int)pin; +#endif + /* add generic bit-banging code */ bitbang = device_add_child(dev, "iicbb", -1); device_probe_and_attach(bitbang); @@ -209,6 +234,16 @@ return (IIC_ENOADDR); } +#ifdef FDT +static phandle_t +gpioiic_get_node(device_t bus, device_t dev) +{ + + /* We only have one child, the iicbb, which needs our own node. */ + return (ofw_bus_get_node(bus)); +} +#endif + static devclass_t gpioiic_devclass; static device_method_t gpioiic_methods[] = { @@ -225,6 +260,11 @@ DEVMETHOD(iicbb_getscl, gpioiic_getscl), DEVMETHOD(iicbb_reset, gpioiic_reset), +#ifdef FDT + /* OFW bus interface */ + DEVMETHOD(ofw_bus_get_node, gpioiic_get_node), +#endif + { 0, 0 } }; Index: sys/dev/gpio/gpioled.c =================================================================== --- sys/dev/gpio/gpioled.c (revision 261556) +++ sys/dev/gpio/gpioled.c (working copy) @@ -27,6 +27,8 @@ #include __FBSDID("$FreeBSD$"); +#include "opt_platform.h" + #include #include #include @@ -39,6 +41,12 @@ #include #include +#ifdef FDT +#include +#include +#include +#endif + #include #include #include "gpiobus_if.h" @@ -84,10 +92,65 @@ GPIOLED_UNLOCK(sc); } +#ifdef FDT +static void +gpioled_identify(driver_t *driver, device_t bus) +{ + phandle_t child, leds, root; + + root = OF_finddevice("/"); + if (root == 0) + return; + leds = fdt_find_compatible(root, "gpio-leds", 1); + if (leds == 0) + return; + + /* Traverse the 'gpio-leds' node and add its children. */ + for (child = OF_child(leds); child != 0; child = OF_peer(child)) + if (ofw_gpiobus_add_fdt_child(bus, child) == NULL) + continue; +} +#endif + static int gpioled_probe(device_t dev) { +#ifdef FDT + int match; + phandle_t node; + char *compat; + + /* + * We can match against our own node compatible string and also against + * our parent node compatible string. The first is normally used to + * describe leds on a gpiobus and the later when there is a common node + * compatible with 'gpio-leds' which is used to concentrate all the + * leds nodes on the dts. + */ + match = 0; + if (ofw_bus_is_compatible(dev, "gpioled")) + match = 1; + + if (match == 0) { + if ((node = ofw_bus_get_node(dev)) == -1) + return (ENXIO); + if ((node = OF_parent(node)) == -1) + return (ENXIO); + if (OF_getprop_alloc(node, "compatible", 1, + (void **)&compat) == -1) + return (ENXIO); + + if (strcasecmp(compat, "gpio-leds") == 0) + match = 1; + + free(compat, M_OFWPROP); + } + + if (match == 0) + return (ENXIO); +#endif device_set_desc(dev, "GPIO led"); + return (0); } @@ -95,18 +158,35 @@ gpioled_attach(device_t dev) { struct gpioled_softc *sc; +#ifdef FDT + phandle_t node; + char *name; +#else const char *name; +#endif sc = device_get_softc(dev); sc->sc_dev = dev; sc->sc_busdev = device_get_parent(dev); GPIOLED_LOCK_INIT(sc); +#ifdef FDT + name = NULL; + if ((node = ofw_bus_get_node(dev)) == -1) + return (ENXIO); + if (OF_getprop_alloc(node, "label", 1, (void **)&name) == -1) + OF_getprop_alloc(node, "name", 1, (void **)&name); +#else if (resource_string_value(device_get_name(dev), device_get_unit(dev), "name", &name)) name = NULL; +#endif sc->sc_leddev = led_create(gpioled_control, sc, name ? name : device_get_nameunit(dev)); +#ifdef FDT + if (name != NULL) + free(name, M_OFWPROP); +#endif return (0); } @@ -129,6 +209,9 @@ static device_method_t gpioled_methods[] = { /* Device interface */ +#ifdef FDT + DEVMETHOD(device_identify, gpioled_identify), +#endif DEVMETHOD(device_probe, gpioled_probe), DEVMETHOD(device_attach, gpioled_attach), DEVMETHOD(device_detach, gpioled_detach), Index: sys/dev/gpio/ofw_gpiobus.c =================================================================== --- sys/dev/gpio/ofw_gpiobus.c (revision 0) +++ sys/dev/gpio/ofw_gpiobus.c (working copy) @@ -0,0 +1,338 @@ +/*- + * Copyright (c) 2009, Nathan Whitehorn + * Copyright (c) 2013, Luiz Otavio O Souza + * Copyright (c) 2013 The FreeBSD Foundation + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice unmodified, this list of conditions, and the following + * disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include + +#include "gpio_if.h" +#include "gpiobus_if.h" + +struct ofw_gpiobus_devinfo { + struct gpiobus_ivar opd_dinfo; + struct ofw_bus_devinfo opd_obdinfo; +}; + +static int ofw_gpiobus_parse_gpios(struct gpiobus_softc *, + struct gpiobus_ivar *, phandle_t); +static struct ofw_gpiobus_devinfo *ofw_gpiobus_setup_devinfo(device_t, + phandle_t); +static void ofw_gpiobus_destroy_devinfo(struct ofw_gpiobus_devinfo *); + +device_t +ofw_gpiobus_add_fdt_child(device_t bus, phandle_t child) +{ + struct ofw_gpiobus_devinfo *dinfo; + device_t childdev; + + /* + * Set up the GPIO child and OFW bus layer devinfo and add it to bus. + */ + dinfo = ofw_gpiobus_setup_devinfo(bus, child); + if (dinfo == NULL) + return (NULL); + childdev = device_add_child(bus, NULL, -1); + if (childdev == NULL) { + device_printf(bus, "could not add child: %s\n", + dinfo->opd_obdinfo.obd_name); + ofw_gpiobus_destroy_devinfo(dinfo); + return (NULL); + } + device_set_ivars(childdev, dinfo); + + return (childdev); +} + +static int +ofw_gpiobus_parse_gpios(struct gpiobus_softc *sc, struct gpiobus_ivar *dinfo, + phandle_t child) +{ + int i, len; + pcell_t *gpios; + phandle_t gpio; + + /* Retrieve the gpios property. */ + if ((len = OF_getproplen(child, "gpios")) < 0) + return (EINVAL); + gpios = malloc(len, M_DEVBUF, M_NOWAIT | M_ZERO); + if (gpios == NULL) + return (ENOMEM); + if (OF_getencprop(child, "gpios", gpios, len) < 0) { + free(gpios, M_DEVBUF); + return (EINVAL); + } + + /* + * Each 'gpios' entry must contain 4 pcells. + * The first one is the GPIO controller phandler. + * Then the last three are the GPIO pin, the GPIO pin direction and + * the GPIO pin flags. + */ + if ((len / sizeof(pcell_t)) % 4) { + free(gpios, M_DEVBUF); + return (EINVAL); + } + dinfo->npins = len / (sizeof(pcell_t) * 4); + dinfo->pins = malloc(sizeof(uint32_t) * dinfo->npins, M_DEVBUF, + M_NOWAIT | M_ZERO); + if (dinfo->pins == NULL) { + free(gpios, M_DEVBUF); + return (ENOMEM); + } + + for (i = 0; i < dinfo->npins; i++) { + + /* Verify if we're attaching to the correct gpio controller. */ + gpio = OF_xref_phandle(gpios[i * 4 + 0]); + if (!OF_hasprop(gpio, "gpio-controller") || + gpio != ofw_bus_get_node(sc->sc_dev)) { + free(dinfo->pins, M_DEVBUF); + free(gpios, M_DEVBUF); + return (EINVAL); + } + + /* Get the GPIO pin number. */ + dinfo->pins[i] = gpios[i * 4 + 1]; + /* gpios[i * 4 + 2] - GPIO pin direction */ + /* gpios[i * 4 + 3] - GPIO pin flags */ + + if (dinfo->pins[i] > sc->sc_npins) { + device_printf(sc->sc_busdev, + "invalid pin %d, max: %d\n", + dinfo->pins[i], sc->sc_npins - 1); + free(dinfo->pins, M_DEVBUF); + free(gpios, M_DEVBUF); + return (EINVAL); + } + + /* + * Mark pin as mapped and give warning if it's already mapped. + */ + if (sc->sc_pins_mapped[dinfo->pins[i]]) { + device_printf(sc->sc_busdev, + "warning: pin %d is already mapped\n", + dinfo->pins[i]); + free(dinfo->pins, M_DEVBUF); + free(gpios, M_DEVBUF); + return (EINVAL); + } + sc->sc_pins_mapped[dinfo->pins[i]] = 1; + } + + free(gpios, M_DEVBUF); + + return (0); +} + +static struct ofw_gpiobus_devinfo * +ofw_gpiobus_setup_devinfo(device_t dev, phandle_t node) +{ + struct gpiobus_softc *sc; + struct ofw_gpiobus_devinfo *dinfo; + + sc = device_get_softc(dev); + dinfo = malloc(sizeof(*dinfo), M_DEVBUF, M_NOWAIT | M_ZERO); + if (dinfo == NULL) + return (NULL); + if (ofw_bus_gen_setup_devinfo(&dinfo->opd_obdinfo, node) != 0) { + free(dinfo, M_DEVBUF); + return (NULL); + } + + /* Parse the gpios property for the child. */ + if (ofw_gpiobus_parse_gpios(sc, &dinfo->opd_dinfo, node) != 0) { + ofw_bus_gen_destroy_devinfo(&dinfo->opd_obdinfo); + free(dinfo, M_DEVBUF); + return (NULL); + } + + return (dinfo); +} + +static void +ofw_gpiobus_destroy_devinfo(struct ofw_gpiobus_devinfo *dinfo) +{ + + ofw_bus_gen_destroy_devinfo(&dinfo->opd_obdinfo); + free(dinfo, M_DEVBUF); +} + +static int +ofw_gpiobus_probe(device_t dev) +{ + + if (ofw_bus_get_node(dev) == -1) + return (ENXIO); + device_set_desc(dev, "OFW GPIO bus"); + + return (0); +} + +static int +ofw_gpiobus_attach(device_t dev) +{ + struct gpiobus_softc *sc; + phandle_t child; + + sc = GPIOBUS_SOFTC(dev); + sc->sc_busdev = dev; + sc->sc_dev = device_get_parent(dev); + + /* Read the pin max. value */ + if (GPIO_PIN_MAX(sc->sc_dev, &sc->sc_npins) != 0) + return (ENXIO); + + KASSERT(sc->sc_npins != 0, ("GPIO device with no pins")); + + /* + * Increase to get number of pins. + */ + sc->sc_npins++; + + sc->sc_pins_mapped = malloc(sizeof(int) * sc->sc_npins, M_DEVBUF, + M_NOWAIT | M_ZERO); + + if (!sc->sc_pins_mapped) + return (ENOMEM); + + /* Init the bus lock. */ + GPIOBUS_LOCK_INIT(sc); + + bus_generic_probe(dev); + bus_enumerate_hinted_children(dev); + + /* + * Attach the children represented in the device tree. + */ + for (child = OF_child(ofw_bus_get_node(dev)); child != 0; + child = OF_peer(child)) + if (ofw_gpiobus_add_fdt_child(dev, child) == NULL) + continue; + + return (bus_generic_attach(dev)); +} + +static device_t +ofw_gpiobus_add_child(device_t dev, u_int order, const char *name, int unit) +{ + device_t child; + struct ofw_gpiobus_devinfo *devi; + + child = device_add_child_ordered(dev, order, name, unit); + if (child == NULL) + return (child); + devi = malloc(sizeof(struct ofw_gpiobus_devinfo), M_DEVBUF, + M_NOWAIT | M_ZERO); + if (devi == NULL) { + device_delete_child(dev, child); + return (0); + } + + /* + * NULL all the OFW-related parts of the ivars for non-OFW + * children. + */ + devi->opd_obdinfo.obd_node = -1; + devi->opd_obdinfo.obd_name = NULL; + devi->opd_obdinfo.obd_compat = NULL; + devi->opd_obdinfo.obd_type = NULL; + devi->opd_obdinfo.obd_model = NULL; + + device_set_ivars(child, devi); + + return (child); +} + +static int +ofw_gpiobus_print_child(device_t dev, device_t child) +{ + struct ofw_gpiobus_devinfo *devi; + int retval = 0; + + devi = device_get_ivars(child); + retval += bus_print_child_header(dev, child); + retval += printf(" at pin(s) "); + gpiobus_print_pins(&devi->opd_dinfo); + retval += bus_print_child_footer(dev, child); + + return (retval); +} + +static const struct ofw_bus_devinfo * +ofw_gpiobus_get_devinfo(device_t bus, device_t dev) +{ + struct ofw_gpiobus_devinfo *dinfo; + + dinfo = device_get_ivars(dev); + + return (&dinfo->opd_obdinfo); +} + +static device_method_t ofw_gpiobus_methods[] = { + /* Device interface */ + DEVMETHOD(device_probe, ofw_gpiobus_probe), + DEVMETHOD(device_attach, ofw_gpiobus_attach), + + /* Bus interface */ + DEVMETHOD(bus_child_pnpinfo_str, ofw_bus_gen_child_pnpinfo_str), + DEVMETHOD(bus_print_child, ofw_gpiobus_print_child), + DEVMETHOD(bus_add_child, ofw_gpiobus_add_child), + + /* ofw_bus interface */ + DEVMETHOD(ofw_bus_get_devinfo, ofw_gpiobus_get_devinfo), + DEVMETHOD(ofw_bus_get_compat, ofw_bus_gen_get_compat), + DEVMETHOD(ofw_bus_get_model, ofw_bus_gen_get_model), + DEVMETHOD(ofw_bus_get_name, ofw_bus_gen_get_name), + DEVMETHOD(ofw_bus_get_node, ofw_bus_gen_get_node), + DEVMETHOD(ofw_bus_get_type, ofw_bus_gen_get_type), + + DEVMETHOD_END +}; + +static devclass_t ofwgpiobus_devclass; + +DEFINE_CLASS_1(gpiobus, ofw_gpiobus_driver, ofw_gpiobus_methods, + sizeof(struct gpiobus_softc), gpiobus_driver); +DRIVER_MODULE(ofw_gpiobus, gpio, ofw_gpiobus_driver, ofwgpiobus_devclass, 0, 0); +MODULE_VERSION(ofw_gpiobus, 1); +MODULE_DEPEND(ofw_gpiobus, gpiobus, 1, 1, 1); Property changes on: sys/dev/gpio/ofw_gpiobus.c ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property --Apple-Mail=_23B096DF-2D6A-4DAD-91F4-17F5ECEED328 Content-Disposition: attachment; filename=002-iicbb-ofw-iicbus.diff Content-Type: application/octet-stream; name="002-iicbb-ofw-iicbus.diff" Content-Transfer-Encoding: 7bit Index: sys/dev/iicbus/iicbb.c =================================================================== --- sys/dev/iicbus/iicbb.c (revision 258138) +++ sys/dev/iicbus/iicbb.c (working copy) @@ -43,6 +43,8 @@ * */ +#include "opt_platform.h" + #include #include #include @@ -50,6 +52,11 @@ #include #include +#ifdef FDT +#include +#include +#include +#endif #include #include @@ -77,6 +84,9 @@ static int iicbb_read(device_t, char *, int, int *, int, int); static int iicbb_reset(device_t, u_char, u_char, u_char *); static int iicbb_transfer(device_t dev, struct iic_msg *msgs, uint32_t nmsgs); +#ifdef FDT +static phandle_t iicbb_get_node(device_t, device_t); +#endif static device_method_t iicbb_methods[] = { /* device interface */ @@ -98,6 +108,11 @@ DEVMETHOD(iicbus_reset, iicbb_reset), DEVMETHOD(iicbus_transfer, iicbb_transfer), +#ifdef FDT + /* ofw_bus interface */ + DEVMETHOD(ofw_bus_get_node, iicbb_get_node), +#endif + { 0, 0 } }; @@ -154,6 +169,16 @@ return (0); } +#ifdef FDT +static phandle_t +iicbb_get_node(device_t bus, device_t dev) +{ + + /* We only have one child, the I2C bus, which needs our own node. */ + return (ofw_bus_get_node(bus)); +} +#endif + static void iicbb_child_detached( device_t dev, device_t child ) { Index: sys/dev/ofw/ofw_iicbus.c =================================================================== --- sys/dev/ofw/ofw_iicbus.c (revision 258138) +++ sys/dev/ofw/ofw_iicbus.c (working copy) @@ -80,6 +80,7 @@ DEFINE_CLASS_1(iicbus, ofw_iicbus_driver, ofw_iicbus_methods, sizeof(struct iicbus_softc), iicbus_driver); +DRIVER_MODULE(ofw_iicbus, iicbb, ofw_iicbus_driver, ofwiicbus_devclass, 0, 0); DRIVER_MODULE(ofw_iicbus, iichb, ofw_iicbus_driver, ofwiicbus_devclass, 0, 0); MODULE_VERSION(ofw_iicbus, 1); MODULE_DEPEND(ofw_iicbus, iicbus, 1, 1, 1); --Apple-Mail=_23B096DF-2D6A-4DAD-91F4-17F5ECEED328 Content-Disposition: attachment; filename=003-ofw-gpio-man.diff Content-Type: application/octet-stream; name="003-ofw-gpio-man.diff" Content-Transfer-Encoding: 7bit Index: share/man/man4/gpioiic.4 =================================================================== --- share/man/man4/gpioiic.4 (revision 258550) +++ share/man/man4/gpioiic.4 (working copy) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd November 5, 2013 +.Dd November 26, 2013 .Dt GPIOIIC 4 .Os .Sh NAME @@ -73,12 +73,75 @@ .Va hint.gpioiic.%d.pins should be used as the SCLOCK source. +Optional, defaults to 0. .It Va hint.gpioiic.%d.sda Indicates which bit in the .Va hint.gpioiic.%d.pins should be used as the SDATA source. +Optional, defaults to 1. .El +.Pp +On a +.Xr FDT 4 +based system, like +.Li ARM , the dts part for a +.Nm gpioiic +device usually looks like: +.Bd -literal +gpio: gpio { + + gpio-controller; + ... + + gpioiic0 { + compatible = "gpioiic"; + /* + * Attach to GPIO pins 21 and 22. Set them + * initially as inputs. + */ + gpios = <&gpio 21 1 0 + &gpio 22 1 0>; + scl = <0>; /* GPIO pin 21 */ + sda = <1>; /* GPIO pin 22 */ + + /* This is an example of a gpioiic child. */ + gpioiic-child0 { + compatible = "lm75"; + i2c-address = <0x9e>; + }; + }; +}; +.Ed +.Pp +Where: +.Bl -tag -width ".Va compatible" +.It Va compatible +Should always be set to "gpioiic". +.It Va gpios +The +.Va gpios +property indicates which GPIO pins should be used for SCLOCK and SDATA +on the GPIO IIC bit-banging bus. +For more details about the +.Va gpios +property, please consult +.Pa /usr/src/sys/boot/fdt/dts/bindings-gpio.txt . +.It Va scl +The +.Va scl +option indicates which bit in the +.Va gpios +should be used as the SCLOCK source. +Optional, defaults to 0. +.It Va sda +The +.Va sda +option indicates which bit in the +.Va gpios +should be used as the SDATA source. +Optional, defaults to 1. +.El .Sh SEE ALSO .Xr gpio 4 , .Xr gpioled 4 , Index: share/man/man4/gpioled.4 =================================================================== --- share/man/man4/gpioled.4 (revision 258550) +++ share/man/man4/gpioled.4 (working copy) @@ -24,7 +24,7 @@ .\" .\" $FreeBSD$ .\" -.Dd November 5, 2013 +.Dd November 26, 2013 .Dt GPIOLED 4 .Os .Sh NAME @@ -68,6 +68,73 @@ Please note that this mask should only ever have one bit set (any others bits - i.e., pins - will be ignored). .El +.Pp +On a +.Xr FDT 4 +based system, like +.Li ARM , the dts part for a +.Nm gpioled +device usually looks like: +.Bd -literal +gpio: gpio { + + gpio-controller; + ... + + led0 { + compatible = "gpioled"; + gpios = <&gpio 16 2 0>; /* GPIO pin 16. */ + name = "ok"; + }; + + led1 { + compatible = "gpioled"; + gpios = <&gpio 17 2 0>; /* GPIO pin 17. */ + name = "user-led1"; + }; +}; +.Ed +.Pp +And optionally, you can choose combine all the leds under a single +.Dq gpio-leds +compatible node: +.Bd -literal +simplebus0 { + + ... + + leds { + compatible = "gpio-leds"; + + led0 { + gpios = <&gpio 16 2 0>; + name = "ok" + }; + + led1 { + gpios = <&gpio 17 2 0>; + name = "user-led1" + }; + }; +}; +.Ed +.Pp +Both methods are equally supported and it is possible to have the leds +defined with any sort of mix between the methods. +The only restriction is that a GPIO pin cannot be mapped by two different +(gpio)leds. +.Pp +For more details about the +.Va gpios +property, please consult +.Pa /usr/src/sys/boot/fdt/dts/bindings-gpio.txt . +.Pp +The property +.Va name +is the arbitrary name of device in +.Pa /dev/led/ +to create for +.Xr led 4 . .Sh SEE ALSO .Xr gpio 4 , .Xr led 4 , --Apple-Mail=_23B096DF-2D6A-4DAD-91F4-17F5ECEED328 Content-Disposition: attachment; filename=004-gpio-node.diff Content-Type: application/octet-stream; name="004-gpio-node.diff" Content-Transfer-Encoding: 7bit Index: sys/arm/ti/ti_gpio.c =================================================================== --- sys/arm/ti/ti_gpio.c (revision 258855) +++ sys/arm/ti/ti_gpio.c (working copy) @@ -788,6 +788,14 @@ return(0); } +static phandle_t +ti_gpio_get_node(device_t bus, device_t dev) +{ + + /* We only have one child, the GPIO bus, which needs our own node. */ + return (ofw_bus_get_node(bus)); +} + static device_method_t ti_gpio_methods[] = { DEVMETHOD(device_probe, ti_gpio_probe), DEVMETHOD(device_attach, ti_gpio_attach), @@ -802,6 +810,10 @@ DEVMETHOD(gpio_pin_get, ti_gpio_pin_get), DEVMETHOD(gpio_pin_set, ti_gpio_pin_set), DEVMETHOD(gpio_pin_toggle, ti_gpio_pin_toggle), + + /* ofw_bus interface */ + DEVMETHOD(ofw_bus_get_node, ti_gpio_get_node), + {0, 0}, }; Index: sys/arm/broadcom/bcm2835/bcm2835_gpio.c =================================================================== --- sys/arm/broadcom/bcm2835/bcm2835_gpio.c (revision 258855) +++ sys/arm/broadcom/bcm2835/bcm2835_gpio.c (working copy) @@ -762,6 +762,14 @@ return (EBUSY); } +static phandle_t +bcm_gpio_get_node(device_t bus, device_t dev) +{ + + /* We only have one child, the GPIO bus, which needs our own node. */ + return (ofw_bus_get_node(bus)); +} + static device_method_t bcm_gpio_methods[] = { /* Device interface */ DEVMETHOD(device_probe, bcm_gpio_probe), @@ -778,6 +786,9 @@ DEVMETHOD(gpio_pin_set, bcm_gpio_pin_set), DEVMETHOD(gpio_pin_toggle, bcm_gpio_pin_toggle), + /* ofw_bus interface */ + DEVMETHOD(ofw_bus_get_node, bcm_gpio_get_node), + DEVMETHOD_END }; --Apple-Mail=_23B096DF-2D6A-4DAD-91F4-17F5ECEED328 Content-Disposition: attachment; filename=005-bbb-gpioled.diff Content-Type: application/octet-stream; name="005-bbb-gpioled.diff" Content-Transfer-Encoding: 7bit Index: sys/arm/conf/BEAGLEBONE =================================================================== --- sys/arm/conf/BEAGLEBONE (revision 258798) +++ sys/arm/conf/BEAGLEBONE (working copy) @@ -101,6 +101,7 @@ # GPIO device gpio +device gpioled # USB support device usb Index: sys/boot/fdt/dts/beaglebone-black.dts =================================================================== --- sys/boot/fdt/dts/beaglebone-black.dts (revision 258798) +++ sys/boot/fdt/dts/beaglebone-black.dts (working copy) @@ -147,6 +147,30 @@ } }; + leds { + compatible = "gpio-leds"; + + led1 { + gpios = <&GPIO 53 2 0>; + name = "led1"; + }; + + led2 { + gpios = <&GPIO 54 2 0>; + name = "led2"; + }; + + led3 { + gpios = <&GPIO 55 2 0>; + name = "led3"; + }; + + led4 { + gpios = <&GPIO 56 2 0>; + name = "led4"; + }; + }; + chosen { stdin = "uart0"; stdout = "uart0"; --Apple-Mail=_23B096DF-2D6A-4DAD-91F4-17F5ECEED328-- From owner-freebsd-arm@FreeBSD.ORG Fri Feb 7 03:22:01 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 22F3419E for ; Fri, 7 Feb 2014 03:22:01 +0000 (UTC) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E06491849 for ; Fri, 7 Feb 2014 03:22:00 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id to1so1343804ieb.12 for ; Thu, 06 Feb 2014 19:21:54 -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=FA6LVvja+mGRIJew+zWFZeuCAxA/CGbSL8vftDRh3JI=; b=QcuzBcgRZFXcZYC+29/08yk6f24ygVEhamR6dTTTcwpgTTLaa6JEO504H0V0Sqxdc/ ufWBVF6r3rKOxQQaQ+pp5bn2o89ofHGhchuv5lVFb+BLS5GxcuvTfJUhknHTex1/jJoZ LRNMLX/RS0Ca57xb5CxAcG43n8qEUxxlFOp+d+2r8jOat+nyJ3xb9nNXjx3SwosvOs15 LSulnOvTwKbk3oV0kFDfrcj0xt1jd4u/PMkBxGFFp4mz7mwHYowo4s9V17AJAdtj8niP qrvmxucXcVK5RHbzgG8znuGs+bNCn1U7ri/W+5+kaZ8Y3WiYA7oQwScfoo/3L265axBE IfCg== X-Gm-Message-State: ALoCoQl1mPrgVE+UCcHi+NXvj2XuRl3/2edwYin21tHMICQ/SdpJd6oZSIzAUGzZ3L0IXAnhMRq4 X-Received: by 10.50.159.194 with SMTP id xe2mr3141407igb.13.1391743313950; Thu, 06 Feb 2014 19:21:53 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id z5sm5381297igw.0.2014.02.06.19.21.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Feb 2014 19:21:53 -0800 (PST) Sender: Warner Losh Subject: Re: FDT/OFW GPIO bus Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: <2D5F2707-FD55-46BB-A44F-8870B48E2BB1@gmail.com> Date: Thu, 6 Feb 2014 20:21:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D5F2707-FD55-46BB-A44F-8870B48E2BB1@gmail.com> To: Luiz Otavio O Souza X-Mailer: Apple Mail (2.1085) Cc: freebsd-arm@freebsd.org, freebsd-embedded@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, 07 Feb 2014 03:22:01 -0000 On Feb 6, 2014, at 11:53 AM, Luiz Otavio O Souza wrote: > Hello guys, >=20 > Last call for alcohol^Wtest and reviews. >=20 > I=92ve finally managed to test these changes on a some FDT and non FDT = systems, so now it is all cleared to commit. >=20 > I plan to commit these changes on the weekend unless someone objects. This is cool. > They add support to describe GPIO connections on the DTS files. It = also add the support to the in tree GPIO devices (gpioiic(4), = gpioled(4)). >=20 > The last patch (005-bbb-gpioled.diff) sets the gpioled(4) for the 4 on = board LEDs on BBB (beaglebone-black). The RPi led is already set and = just need the first patch (001-ofw-gpiobus.diff) to work. >=20 > The tests were done on RPi and BBB using I2C devices (two lm75 on the = same bus), LEDs (for gpioled(4)) and even with some non committed = ethernet over SPI. The I2C tests are conducted using the hardware I2C = controller (when available) and also the software big bang controller - = gpioiic(4). >=20 > I used the RSPRO (MIPS/ar71xx) to check for regressions without any = visible problem. >=20 > gpioiic(4) devices can be described in DTS as follow: >=20 > gpio { >=20 > gpioiic { > compatible =3D "gpioiic"; Linux uses 'i2c-gpio' here. Can we follow that standard rather than = invent our own? Or at least support both? > gpios =3D <&gpio 17 2 0 > &gpio 21 2 0>; > scl =3D <0>; > sda =3D <1>; Linux doesn't have these at all, it seems, since they are implicit in = the gpios property. It would be ideal if the scl and sda properties were = optional... In addition, you'll often see things like: i2c-gpio,sda-open-drain; i2c-gpio,scl-open-drain; i2c-gpio,delay-us =3D <2>; as well. These should be easy enough to add and shouldn't gate things. There's also many DTS files that don't have this as a direct child of = gpio... But that's not strictly required. I'll cope with adding support = for that when I get the Atmel stuff working... > lm750 { > compatible =3D "lm75"; > i2c-address =3D <0x4b>; > }; > lm751 { > compatible =3D "lm75"; > i2c-address =3D <0x4f>; > }; > }; > }; >=20 > gpioled(4) devices can be described in two ways: >=20 > - directly under the GPIO controller node: >=20 > gpio { >=20 > led0 { > compatible =3D "gpioled"; cool. > gpios =3D <&gpio 16 2 0>; > label =3D "ok"; > }; >=20 > led1 { > compatible =3D "gpioled"; > gpios =3D <&gpio 17 2 0>; > name =3D "user-led1"; > }; > }; >=20 > - Or under a single =93gpio-leds=94 node: This follows Linux convention, which is cool... > leds { > compatible =3D "gpio-leds"; >=20 > led1 { > gpios =3D <&GPIO 53 2 0>; > name =3D "led1"; > }; >=20 > led2 { > gpios =3D <&GPIO 54 2 0>; > name =3D "led2"; > }; > }; >=20 >=20 > gpioiic(4) and gpioled(4) man pages were updated to cover FDT/OFW = based systems. Cool. > =46rom the latest patchset (published on freebsd-arch@ and = freebsd-arm@) i removed the check for disabled devices on DTS as this = seems to indicate that the device needs special attention but should not = be skipped at attach time. >=20 > Please let me know if there are problems or concerns with the = following changes. I'll have to look at these in detail > Thanks, > Luiz >=20 > = <001-ofw-gpiobus.diff><002-iicbb-ofw-iicbus.diff><003-ofw-gpio-man.diff><0= 04-gpio-node.diff><005-bbb-gpioled.diff>__________________________________= _____________ > freebsd-embedded@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to = "freebsd-embedded-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Fri Feb 7 22:27: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 A4EDCE43; Fri, 7 Feb 2014 22:27:33 +0000 (UTC) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1D44B106B; Fri, 7 Feb 2014 22:27:32 +0000 (UTC) Received: from server.rulingia.com (c220-239-241-144.belrs5.nsw.optusnet.com.au [220.239.241.144]) by vps.rulingia.com (8.14.7/8.14.7) with ESMTP id s17MRL5c083477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Feb 2014 09:27:21 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.7/8.14.7) with ESMTP id s17MRFql085622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 8 Feb 2014 09:27:15 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.7/8.14.7/Submit) id s17MRF5S085621; Sat, 8 Feb 2014 09:27:15 +1100 (EST) (envelope-from peter) Date: Sat, 8 Feb 2014 09:27:15 +1100 From: Peter Jeremy To: Ian Lepore Subject: Re: arm/181601: Sporadic failure of root mount on ARM/Raspberry Message-ID: <20140207222715.GA84344@server.rulingia.com> References: <201308281230.r7SCU0k5093956@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: <201308281230.r7SCU0k5093956@freefall.freebsd.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-arm@freebsd.org, freebsd-gnats-submit@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, 07 Feb 2014 22:27:33 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-Aug-28 12:30:00 +0000, Ian Lepore wrote: > On Wed, 2013-08-28 at 05:35 +0000, Martin Laabs wrote: > > Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... > > mountroot: waiting for device /dev/mmcsd0s2a ... > > smsc0: chip 0xec00, rev. 0002 > > miibus0: on smsc0 > > ukphy0: PHY 1 on miibus0 > > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > ue0: on smsc0 > > ue0: Ethernet address: b8:27:eb:1d:b7:5a > > Mounting from ufs:/dev/mmcsd0s2a failed with error 19. > >=20 > > Loader variables: > > vfs.root.mountfrom=3Dufs:/dev/mmcsd0s2a > > vfs.root.mountfrom.options=3Drw,noatime > We have long had a problem with mysterious sdcard timeout errors on RPi > that doesn't happen on other hardware with sdhci controllers. Until > now, it was thought that these timeouts always occurred shortly after > the controller was initialized by the OS. The timeouts would affect the > early card-detection sequences; we worked around them by adding > automatic retries to the mmc code that identifies and initializes cards. >=20 > This error appears to be a timeout that occurs after the card init > sequences are done (the errors are reported by mmcsd0, not mmc0). I am seeing this fairly consistently on every second boot - which is rather annoying because I would like that RPi to reliably boot unattended. Does anyone have any suggestions for a workaround? --=20 Peter Jeremy --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iKYEARECAGYFAlL1XcNfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDBCRjc3QTcyNTg5NEVCRTY0RjREN0VFRUZF OEE0N0JGRjAwRkI4ODcACgkQ/opHv/APuIfsgACgrjubepqhBbphlk5FMaE/Zs8u dpAAoMEGJmwHGBTzDqREdu8NDVGAr1an =8SxC -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- From owner-freebsd-arm@FreeBSD.ORG Fri Feb 7 22:30:02 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 DDE84E9F for ; Fri, 7 Feb 2014 22:30:02 +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 AEC081085 for ; Fri, 7 Feb 2014 22:30:02 +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 s17MU2oa070049 for ; Fri, 7 Feb 2014 22:30:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s17MU2lL070048; Fri, 7 Feb 2014 22:30:02 GMT (envelope-from gnats) Date: Fri, 7 Feb 2014 22:30:02 GMT Message-Id: <201402072230.s17MU2lL070048@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: Peter Jeremy Subject: Re: arm/181601: Sporadic failure of root mount on ARM/Raspberry X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Peter Jeremy List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 22:30:02 -0000 The following reply was made to PR arm/181601; it has been noted by GNATS. From: Peter Jeremy To: Ian Lepore Cc: freebsd-arm@freebsd.org, freebsd-gnats-submit@freebsd.org Subject: Re: arm/181601: Sporadic failure of root mount on ARM/Raspberry Date: Sat, 8 Feb 2014 09:27:15 +1100 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-Aug-28 12:30:00 +0000, Ian Lepore wrote: > On Wed, 2013-08-28 at 05:35 +0000, Martin Laabs wrote: > > Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... > > mountroot: waiting for device /dev/mmcsd0s2a ... > > smsc0: chip 0xec00, rev. 0002 > > miibus0: on smsc0 > > ukphy0: PHY 1 on miibus0 > > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > ue0: on smsc0 > > ue0: Ethernet address: b8:27:eb:1d:b7:5a > > Mounting from ufs:/dev/mmcsd0s2a failed with error 19. > >=20 > > Loader variables: > > vfs.root.mountfrom=3Dufs:/dev/mmcsd0s2a > > vfs.root.mountfrom.options=3Drw,noatime > We have long had a problem with mysterious sdcard timeout errors on RPi > that doesn't happen on other hardware with sdhci controllers. Until > now, it was thought that these timeouts always occurred shortly after > the controller was initialized by the OS. The timeouts would affect the > early card-detection sequences; we worked around them by adding > automatic retries to the mmc code that identifies and initializes cards. >=20 > This error appears to be a timeout that occurs after the card init > sequences are done (the errors are reported by mmcsd0, not mmc0). I am seeing this fairly consistently on every second boot - which is rather annoying because I would like that RPi to reliably boot unattended. Does anyone have any suggestions for a workaround? --=20 Peter Jeremy --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iKYEARECAGYFAlL1XcNfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDBCRjc3QTcyNTg5NEVCRTY0RjREN0VFRUZF OEE0N0JGRjAwRkI4ODcACgkQ/opHv/APuIfsgACgrjubepqhBbphlk5FMaE/Zs8u dpAAoMEGJmwHGBTzDqREdu8NDVGAr1an =8SxC -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- From owner-freebsd-arm@FreeBSD.ORG Sat Feb 8 04:39: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 71D96D3D for ; Sat, 8 Feb 2014 04:39:33 +0000 (UTC) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 316B11675 for ; Sat, 8 Feb 2014 04:39:32 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id c9so7495080qcz.13 for ; Fri, 07 Feb 2014 20:39:26 -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:date:message-id:subject:from:to :content-type; bh=SpU9wuizB9190ZZV2O/A5RBaLX97SLxgSfxXYzq4pvQ=; b=iFXVmN7bF71Kgl4+rH9nXWAlqdBPfi7DzpsaN2M7fPua3YOgCwuuJj4YoV8yc6RUkE QrGPjea9PS94ZFS+KWTPdETtXOoVX8CuNHs/fv6UUo8bed8DF/9lxy+kZQoMTDKG8MRH 0arCLmr+LENHoHXDZP3IGXtCk67LfGxvxUiSOxi/ppxNYyFOzIRXXE/z2Fss6s22q64E 9EDjSLxsJA9Lp64I0nwdCQnqpE1qnUkgId6ddKYaiPlC7LeaIjy+MxIK3JVicJ1DEkLz u3ghgD4cBrS8cYmd8Fg8BfG3yPrwz60+tO0DNFmcGTjJXbG8utp4xIqgfVFxEiZtT968 F42w== X-Gm-Message-State: ALoCoQmSOb2vo1WHPQDlmkdqJMnzTVSjMwKEptaq/xFBqgkbYK42XDZnrL1KdRXIhHwBtsHiu3QA MIME-Version: 1.0 X-Received: by 10.224.11.196 with SMTP id u4mr28829321qau.4.1391833978264; Fri, 07 Feb 2014 20:32:58 -0800 (PST) Received: by 10.140.92.97 with HTTP; Fri, 7 Feb 2014 20:32:58 -0800 (PST) Date: Sat, 8 Feb 2014 11:32:58 +0700 Message-ID: Subject: Segmentation Fault From: Alie Tan 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: Sat, 08 Feb 2014 04:39:33 -0000 Hi, I am getting below issue while compiling kernel for RPI-B with FreeBSD 11-CURRENT: --- config --- cc -O2 -pipe -I. -I/usr/src/usr.sbin/config -O2 -fno-strict-aliasing -funroll-loops -pipe -std=gnu99 -I/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/include -static -L/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/lib -o config config.o main.o lang.o mkmakefile.o mkheaders.o mkoptions.o kernconf.o -ll -lsbuf -legacy --- _proginstall --- sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 config /usr/obj/arm.armv6/usr/src/tmp/legacy/usr/sbin/config Segmentation fault (core dumped) *** [_proginstall] Error code 139 make[3]: stopped in /usr/src/usr.sbin/config 1 error make[3]: stopped in /usr/src/usr.sbin/config *** [bootstrap-tools] Error code 2 make[2]: stopped in /usr/src 1 error make[2]: stopped in /usr/src *** [_bootstrap-tools] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [kernel-toolchain] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src root@fbsd-11:~ # root@fbsd-11:~ # uname -a FreeBSD fbsd-11 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r261419: Mon Feb 3 08:59:07 UTC 2014 root@grind.freebsd.org:/usr/obj/usr/src/sys/VT i386 From owner-freebsd-arm@FreeBSD.ORG Sat Feb 8 05:10:08 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 C68ACFE for ; Sat, 8 Feb 2014 05:10:08 +0000 (UTC) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 83EBB185D for ; Sat, 8 Feb 2014 05:10:08 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id j15so6531400qaq.25 for ; Fri, 07 Feb 2014 21:10:07 -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:date :message-id:subject:from:to:content-type; bh=eLwx+vNSR+lMBLoP4XF31IcBRJKTUvDUP94bC0a7SNc=; b=FzqERM0DNA6gWhjOR/G4+qk9dTImUYIqKemZDwByjQ1CsydJco1Ebii/kEKOZCzkTo SLErySomFv7eNT3VYZlVADPtcAA420KqMGAv6n5Ue/dzEzC876R4Q28acntaw6DtRyRP SjPgrCCP6yQsjIXBFogTFtN78pcD3ob6IXHD0rQeD2DVs7NjTAtRy7G6BvGlAZukR3cl jZKoGWNHuXNh74ces61Jnt3nQZEZp37sNX7n1N0ZAzGz4c5KkBG+ql7c6x3m4/clj/uq sDlyq9tc8ZXB8pb7cXtNnpd73YjKzUO3KIwG/T6ciYLqvn3DuiFVXwvlXr4PAfM7PscE 9+yg== X-Gm-Message-State: ALoCoQnkBfJ6K8LXXkfQ+iC6sZRUu0qUfA0SHQ2Zakd1kQd8VBQwZk7mJ8ooH2X3HtJBTXNxivuf MIME-Version: 1.0 X-Received: by 10.140.39.212 with SMTP id v78mr26506617qgv.77.1391836207460; Fri, 07 Feb 2014 21:10:07 -0800 (PST) Received: by 10.140.92.97 with HTTP; Fri, 7 Feb 2014 21:10:07 -0800 (PST) In-Reply-To: References: Date: Sat, 8 Feb 2014 12:10:07 +0700 Message-ID: Subject: Re: Segmentation Fault From: Alie Tan 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: Sat, 08 Feb 2014 05:10:08 -0000 On Sat, Feb 8, 2014 at 11:32 AM, Alie Tan wrote: > Hi, > > I am getting below issue while compiling kernel for RPI-B with FreeBSD > 11-CURRENT: > Sorry false alarm, I mean building toolchain > > --- config --- > cc -O2 -pipe -I. -I/usr/src/usr.sbin/config -O2 -fno-strict-aliasing > -funroll-loops -pipe -std=gnu99 > -I/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/include -static > -L/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/lib -o config config.o main.o > lang.o mkmakefile.o mkheaders.o mkoptions.o kernconf.o -ll -lsbuf -legacy > --- _proginstall --- > sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 config > /usr/obj/arm.armv6/usr/src/tmp/legacy/usr/sbin/config > Segmentation fault (core dumped) > *** [_proginstall] Error code 139 > > make[3]: stopped in /usr/src/usr.sbin/config > 1 error > > make[3]: stopped in /usr/src/usr.sbin/config > *** [bootstrap-tools] Error code 2 > > make[2]: stopped in /usr/src > 1 error > > make[2]: stopped in /usr/src > *** [_bootstrap-tools] Error code 2 > > make[1]: stopped in /usr/src > 1 error > > make[1]: stopped in /usr/src > *** [kernel-toolchain] Error code 2 > > make: stopped in /usr/src > 1 error > > make: stopped in /usr/src > root@fbsd-11:~ # > > root@fbsd-11:~ # uname -a > FreeBSD fbsd-11 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r261419: Mon Feb 3 > 08:59:07 UTC 2014 root@grind.freebsd.org:/usr/obj/usr/src/sys/VT i386 > > From owner-freebsd-arm@FreeBSD.ORG Sat Feb 8 21:33:46 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 4A15A36B for ; Sat, 8 Feb 2014 21:33:46 +0000 (UTC) Received: from homiemail-a7.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by mx1.freebsd.org (Postfix) with ESMTP id 167BA1168 for ; Sat, 8 Feb 2014 21:33:45 +0000 (UTC) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 165C025C063 for ; Sat, 8 Feb 2014 13:33:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=koffein.net; h=from:to :subject:date:message-id:mime-version:content-type: content-transfer-encoding; s=koffein.net; bh=KLIDz2cYACuXHZZxVNK rAzSWxno=; b=i0NW9igd+s8kni5XxAGwLbVEd8ZpWL0Vvnud3GZxeAw0XBjEqug TM07OTwkY9emvFbOpb23fIE5ydZSiJ/8zmTQj05nDbS+jGkbLDqqLh2KC/1vdJik +8hhg9Za2qrKHpVvzh4/W5AtJ5fAnEVJEh+FsU78FwzRG7QU+aCmNrLE= Received: from localhost (unknown [77.109.124.99]) (Authenticated sender: stl@koffein.net) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPA id 22FC025C062 for ; Sat, 8 Feb 2014 13:33:37 -0800 (PST) From: Steven Lawrance To: freebsd-arm Subject: i.MX6 on-die temperature sensor Date: Sat, 08 Feb 2014 22:32:31 +0100 Message-Id: <1391893231-sup-6174@luwak.koffein.net> User-Agent: Sup/git MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline 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: Sat, 08 Feb 2014 21:33:46 -0000 Hi all, a Wandboard turned up on my desk yesterday and I thought I'd get started with something simple -- the on-chip temperature sensor. A patch is attached, but I've got a few questions, mostly about FDTs: The driver doesn't need to reserve any resources for itself but rather refer to two others, anatop and ocotp. How can that relationship be represented in the FDT? How is the sequence of device attachments determined? Just by the order in the FDT? The current scenario seems quite fragile if that's the case. For the OCOTP (on-chip one-time-programmable memory) side of things, I just followed the pattern in imx6_anatop.c, which is to provide public methods for accessing its memory space. But it feels a bit dirty -- I imagine there could be cases where you would have two similar blocks and things would fall apart. cheers, -- Steven Lawrance stl@koffein.net From owner-freebsd-arm@FreeBSD.ORG Sat Feb 8 21:50:54 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 C51A89FB for ; Sat, 8 Feb 2014 21:50:54 +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 928C6122D for ; Sat, 8 Feb 2014 21:50:54 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed 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 <0N0P008005RJXC00@smtpauth3.wiscmail.wisc.edu> for freebsd-arm@freebsd.org; Sat, 08 Feb 2014 15:50:45 -0600 (CST) X-Spam-PmxInfo: Server=avs-3, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.8.213915, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from comporellon.tachypleus.net (adsl-76-208-68-77.dsl.mdsnwi.sbcglobal.net [76.208.68.77]) 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 <0N0P00JEQ60KA820@smtpauth3.wiscmail.wisc.edu>; Sat, 08 Feb 2014 15:50:45 -0600 (CST) Message-id: <52F6A6B4.2050806@freebsd.org> Date: Sat, 08 Feb 2014 15:50:44 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: Steven Lawrance , freebsd-arm Subject: Re: i.MX6 on-die temperature sensor References: <1391893231-sup-6174@luwak.koffein.net> In-reply-to: <1391893231-sup-6174@luwak.koffein.net> 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, 08 Feb 2014 21:50:54 -0000 On 02/08/14 15:32, Steven Lawrance wrote: > Hi all, > > a Wandboard turned up on my desk yesterday and I thought I'd get > started with something simple -- the on-chip temperature sensor. > > A patch is attached, but I've got a few questions, mostly about FDTs: > > The driver doesn't need to reserve any resources for itself but rather > refer to two others, anatop and ocotp. How can that relationship be > represented in the FDT? > > How is the sequence of device attachments determined? Just by the > order in the FDT? The current scenario seems quite fragile if that's > the case. > > For the OCOTP (on-chip one-time-programmable memory) side of things, I > just followed the pattern in imx6_anatop.c, which is to provide public > methods for accessing its memory space. But it feels a bit dirty -- I > imagine there could be cases where you would have two similar blocks > and things would fall apart. > > cheers, > This is a really interesting issue. Bus probe order is based first on the pass of the driver (see EARLY_DRIVER_MODULE) and then on the order in the device tree. If you can mark anatop and ocotp as "early", then your immediate issue should go away. More generally, newbus basically doesn't support relationships between devices that don't follow the bus hierarchy. On embedded systems, these are common and tricky to handle. For simple cases, we can get away with multiple passes -- maybe with simple extensions such as being able to return an EAGAIN code for "please come back later once other devices are attached". A simple way to register a device_t (or kobj in general) to a particular handle (probably a phandle_t for OF systems) would also help. More generally, the problem becomes exceedingly complex. The really problematic case is interrupts: it is easy to have situations where the interrupt controller itself is attached via a bus that needs interrupts itself. This is not a hypothetical: PPC macs using Open Firmware have exactly this topology, where the primary interrupt controller is a subunit of a PCI device underneath a few PCI<->PCI bridges. No bus ordering fixes the situation there since a circular dependency exists (to attach, the interrupt controller driver needs to allocate memory from its bus parent, but, to attach, that parent, and its parent, have to allocate interrupts!). For PowerPC, we handle this by having a virtual interrupt configuration layer that allocates interrupts at any time but defers actual configuration until after bus probing. A generalization of that approach might be valuable for other such situations. -Nathan From owner-freebsd-arm@FreeBSD.ORG Sat Feb 8 21:58:27 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 32E57AED for ; Sat, 8 Feb 2014 21:58:27 +0000 (UTC) Received: from homiemail-a1.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by mx1.freebsd.org (Postfix) with ESMTP id 0F03512AD for ; Sat, 8 Feb 2014 21:58:26 +0000 (UTC) Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id 81A7E34806C for ; Sat, 8 Feb 2014 13:58:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=koffein.net; h=from:to :subject:in-reply-to:references:date:message-id:mime-version :content-type:content-transfer-encoding; s=koffein.net; bh=b7CvZ ZmNURC1189K4+E+A3YOwVg=; b=uD0b67bN4V9dSEoXKHgjjNRxuSVFTNdfQbywE N7EAlMxt3JWHiauDVc9Sp+PlCTm4bRr8mMJ6mVbVexHnt5ch9ldIoCrDDxF03nAh 4oGdkU2pZpRmoVtCacGI5H2YTsjrDZRzBS6tQDobDe9YViGrhyR48w7ChV3S5UFd +14cf8= Received: from localhost (unknown [77.109.124.99]) (Authenticated sender: stl@koffein.net) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPA id C53EA34806A for ; Sat, 8 Feb 2014 13:58:25 -0800 (PST) From: Steven Lawrance To: freebsd-arm Subject: Re: i.MX6 on-die temperature sensor In-reply-to: <1391893231-sup-6174@luwak.koffein.net> References: <1391893231-sup-6174@luwak.koffein.net> Date: Sat, 08 Feb 2014 22:57:20 +0100 Message-Id: <1391896463-sup-1007@luwak.koffein.net> User-Agent: Sup/git MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-1391896640-307870-43411-8607-2-=" Content-Transfer-Encoding: 7bit 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, 08 Feb 2014 21:58:27 -0000 --=-1391896640-307870-43411-8607-2-= Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Excerpts from Steven Lawrance's message of 2014-02-08 22:32:31 +0100: > A patch is attached, but I've got a few questions, mostly about FDTs: > order in the FDT? The current scenario seems quite fragile if that's Another attempt at sending the patch -- it appears to have been stripped the first time around. -- Steven Lawrance stl@koffein.net --=-1391896640-307870-43411-8607-2-= Content-Disposition: attachment; filename="imx6_tempmon.txt" Content-Type: text/plain; name="imx6_tempmon.txt" Content-Transfer-Encoding: quoted-printable Index: sys/arm/freescale/imx/files.imx6 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/arm/freescale/imx/files.imx6 (revision 261623) +++ sys/arm/freescale/imx/files.imx6 (working copy) @@ -22,6 +22,8 @@ arm/freescale/imx/imx6_ccm.c standard arm/freescale/imx/imx6_machdep.c standard arm/freescale/imx/imx6_pl310.c standard +arm/freescale/imx/imx6_ocotp.c standard +arm/freescale/imx/imx6_tempmon.c standard arm/freescale/imx/imx_machdep.c standard arm/freescale/imx/imx_gpt.c standard = Index: sys/arm/freescale/imx/imx6_anatopreg.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/arm/freescale/imx/imx6_anatopreg.h (revision 261623) +++ sys/arm/freescale/imx/imx6_anatopreg.h (working copy) @@ -101,6 +101,23 @@ #define IMX6_ANALOG_CCM_MISC2_CLR 0x178 #define IMX6_ANALOG_CCM_MISC2_TOG 0x17C = +#define IMX6_ANALOG_TEMPMON_TEMPSENSE0 0x180 +#define IMX6_ANALOG_TEMPMON_TEMPSENSE0_SET 0x184 +#define IMX6_ANALOG_TEMPMON_TEMPSENSE0_CLR 0x188 +#define IMX6_ANALOG_TEMPMON_TEMPSENSE0_TOG 0x18C +#define IMX6_ANALOG_TEMPMON_TEMPSENSE0_TOG 0x18C +#define IMX6_ANALOG_TEMPMON_TEMPSENSE0_TEMP_CNT_SHIFT 8 +#define IMX6_ANALOG_TEMPMON_TEMPSENSE0_TEMP_CNT_MASK \ + (0xfff << IMX6_ANALOG_TEMPMON_TEMPSENSE0_TEMP_CNT_SHIFT) +#define IMX6_ANALOG_TEMPMON_TEMPSENSE0_VALID 0x4 +#define IMX6_ANALOG_TEMPMON_TEMPSENSE0_MEASURE 0x2 +#define IMX6_ANALOG_TEMPMON_TEMPSENSE0_POWER_DOWN 0x1 + +#define IMX6_ANALOG_TEMPMON_TEMPSENSE1 0x190 +#define IMX6_ANALOG_TEMPMON_TEMPSENSE1_SET 0x194 +#define IMX6_ANALOG_TEMPMON_TEMPSENSE1_CLR 0x198 +#define IMX6_ANALOG_TEMPMON_TEMPSENSE1_TOG 0x19C + #define IMX6_ANALOG_USB1_VBUS_DETECT 0x1A0 #define IMX6_ANALOG_USB1_VBUS_DETECT_SET 0x1A4 #define IMX6_ANALOG_USB1_VBUS_DETECT_CLR 0x1A8 Index: sys/arm/freescale/imx/imx6_ocotp.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/arm/freescale/imx/imx6_ocotp.c (revision 0) +++ sys/arm/freescale/imx/imx6_ocotp.c (working copy) @@ -0,0 +1,150 @@ +/*- + * Copyright (c) 2014 Steven Lawrance + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in th= e + * documentation and/or other materials provided with the distributio= n. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AN= D + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE= + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PU= RPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIAB= LE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUE= NTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOO= DS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)= + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, S= TRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY= WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY O= F + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +/* + * Access to the Freescale i.MX6 On-Chip One-Time-Programmable Memory + */ + +#include +#include +#include +#include +#include +#include + +#include +#include + +#include + +#include +#include +#include + +struct ocotp_softc { + device_t dev; + struct resource *mem_res; +}; + +static struct ocotp_softc *ocotp_sc; + +static inline uint32_t +RD4(struct ocotp_softc *sc, bus_size_t off) +{ + return (bus_read_4(sc->mem_res, off)); +} + + +static int +ocotp_detach(device_t dev) +{ + struct ocotp_softc *sc; + + sc =3D device_get_softc(dev); + + if (sc->mem_res !=3D NULL) + bus_release_resource(dev, SYS_RES_MEMORY, 0, sc->mem_res); + + ocotp_sc =3D NULL; + + return (0); +} + +static int +ocotp_attach(device_t dev) +{ + struct ocotp_softc *sc; + int err, rid; + + sc =3D device_get_softc(dev); + err =3D 0; + + /* Allocate bus_space resources. */ + rid =3D 0; + sc->mem_res =3D bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, + RF_ACTIVE); + if (sc->mem_res =3D=3D NULL) { + device_printf(dev, "Cannot allocate memory resources\n"); + err =3D ENXIO; + goto out; + } + + ocotp_sc =3D sc; + +out: + if (err !=3D 0) + ocotp_detach(dev); + + return (err); +} + +static int +ocotp_probe(device_t dev) +{ + + if (!ofw_bus_status_okay(dev)) + return (ENXIO); + + if (ofw_bus_is_compatible(dev, "fsl,imx6q-ocotp") =3D=3D 0) + return (ENXIO); + + device_set_desc(dev, "Freescale i.MX6 On-Chip One-Time-Programmable Mem= ory"); + + return (BUS_PROBE_DEFAULT); +} + +int +imx6_ocotp_read_4(bus_size_t off, uint32_t *val) +{ + if (!ocotp_sc) + return (ENXIO); + + *val =3D RD4(ocotp_sc, off); + return (0); +} + +static device_method_t ocotp_methods[] =3D { + /* Device interface */ + DEVMETHOD(device_probe, ocotp_probe), + DEVMETHOD(device_attach, ocotp_attach), + DEVMETHOD(device_detach, ocotp_detach), + + DEVMETHOD_END +}; + +static driver_t ocotp_driver =3D { + "ocotp", + ocotp_methods, + sizeof(struct ocotp_softc) +}; + +static devclass_t ocotp_devclass; + +DRIVER_MODULE(ocotp, simplebus, ocotp_driver, ocotp_devclass, 0, 0); + Property changes on: sys/arm/freescale/imx/imx6_ocotp.c ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=3D%H \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: sys/arm/freescale/imx/imx6_ocotpreg.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/arm/freescale/imx/imx6_ocotpreg.h (revision 0) +++ sys/arm/freescale/imx/imx6_ocotpreg.h (working copy) @@ -0,0 +1,79 @@ +/*- + * Copyright (c) 2014 Steven Lawrance + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in th= e + * documentation and/or other materials provided with the distributio= n. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AN= D + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE= + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PU= RPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIAB= LE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUE= NTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOO= DS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)= + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, S= TRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY= WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY O= F + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef IMX6_OCOTPREG_H +#define IMX6_OCOTPREG_H + +#define IMX6_OCOTP_CTRL 0x000 +#define IMX6_OCOTP_CTRL_SET 0x004 +#define IMX6_OCOTP_CTRL_CLR 0x008 +#define IMX6_OCOTP_CTRL_TOG 0x00C +#define IMX6_OCOTP_TIMING 0x010 +#define IMX6_OCOTP_DATA 0x020 +#define IMX6_OCOTP_READ_CTRL 0x030 +#define IMX6_OCOTP_READ_FUSE_DATA 0x040 +#define IMX6_OCOTP_SW_STICKY 0x050 +#define IMX6_OCOTP_SCS 0x060 +#define IMX6_OCOTP_SCS_SET 0x064 +#define IMX6_OCOTP_SCS_CLR 0x068 +#define IMX6_OCOTP_SCS_TOG 0x06C +#define IMX6_OCOTP_VERSION 0x090 +#define IMX6_OCOTP_LOCK 0x400 +#define IMX6_OCOTP_CFG0 0x410 +#define IMX6_OCOTP_CFG1 0x420 +#define IMX6_OCOTP_CFG2 0x430 +#define IMX6_OCOTP_CFG3 0x440 +#define IMX6_OCOTP_CFG4 0x450 +#define IMX6_OCOTP_CFG5 0x460 +#define IMX6_OCOTP_CFG6 0x470 +#define IMX6_OCOTP_MEM0 0x480 +#define IMX6_OCOTP_MEM1 0x490 +#define IMX6_OCOTP_MEM2 0x4A0 +#define IMX6_OCOTP_MEM3 0x4B0 +#define IMX6_OCOTP_ANA0 0x4D0 +#define IMX6_OCOTP_ANA1 0x4E0 +#define IMX6_OCOTP_ANA2 0x4F0 +#define IMX6_OCOTP_SRK0 0x580 +#define IMX6_OCOTP_SRK1 0x590 +#define IMX6_OCOTP_SRK2 0x5A0 +#define IMX6_OCOTP_SRK3 0x5B0 +#define IMX6_OCOTP_SRK4 0x5C0 +#define IMX6_OCOTP_SRK5 0x5D0 +#define IMX6_OCOTP_SRK6 0x5E0 +#define IMX6_OCOTP_SRK7 0x5F0 +#define IMX6_OCOTP_HSJC_RESP0 0x600 +#define IMX6_OCOTP_HSJC_RESP1 0x610 +#define IMX6_OCOTP_MAC0 0x620 +#define IMX6_OCOTP_MAC1 0x630 +#define IMX6_OCOTP_GP1 0x660 +#define IMX6_OCOTP_GP2 0x670 +#define IMX6_OCOTP_MISC_CONF 0x6D0 +#define IMX6_OCOTP_FIELD_RETURN 0x6E0 +#define IMX6_OCOTP_SRK_REVOKE 0x6F0 + +#endif Property changes on: sys/arm/freescale/imx/imx6_ocotpreg.h ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=3D%H \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: sys/arm/freescale/imx/imx6_ocotpvar.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/arm/freescale/imx/imx6_ocotpvar.h (revision 0) +++ sys/arm/freescale/imx/imx6_ocotpvar.h (working copy) @@ -0,0 +1,34 @@ +/*- + * Copyright (c) 2014 Steven Lawrance + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in th= e + * documentation and/or other materials provided with the distributio= n. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AN= D + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE= + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PU= RPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIAB= LE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUE= NTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOO= DS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)= + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, S= TRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY= WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY O= F + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef IMX6_OCOTPVAR_H +#define IMX6_OCOTPVAR_H + +int imx6_ocotp_read_4(bus_size_t _offset, uint32_t *_value); + +#endif Property changes on: sys/arm/freescale/imx/imx6_ocotpvar.h ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=3D%H \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: sys/arm/freescale/imx/imx6_tempmon.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/arm/freescale/imx/imx6_tempmon.c (revision 0) +++ sys/arm/freescale/imx/imx6_tempmon.c (working copy) @@ -0,0 +1,203 @@ +/*- + * Copyright (c) 2014 Steven Lawrance + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in th= e + * documentation and/or other materials provided with the distributio= n. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AN= D + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE= + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PU= RPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIAB= LE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUE= NTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOO= DS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)= + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, S= TRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY= WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY O= F + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +/* + * Freescale i.MX6 Temperature Monitor (TEMPMON) + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include + +#include +#include +#include +#include +#include + +#define TZ_ZEROC 2732 + +struct tempmon_softc { + device_t dev; + uint32_t room_cnt; + uint32_t high_cnt; + uint32_t high_temp; + uint32_t last; +}; + +static struct tempmon_softc *tempmon_sc; + +static void +update_count(void) +{ + uint32_t val; + = + val =3D imx6_anatop_read_4(IMX6_ANALOG_TEMPMON_TEMPSENSE0); + if (!(val & IMX6_ANALOG_TEMPMON_TEMPSENSE0_VALID)) + return; + tempmon_sc->last =3D + (val & IMX6_ANALOG_TEMPMON_TEMPSENSE0_TEMP_CNT_MASK) + >> IMX6_ANALOG_TEMPMON_TEMPSENSE0_TEMP_CNT_SHIFT; +} + +static int +temperature_sysctl_handler(SYSCTL_HANDLER_ARGS) +{ + uint32_t t; + = + update_count(); + + t =3D tempmon_sc->high_temp * 1000 + - (tempmon_sc->last - tempmon_sc->high_cnt) + * (tempmon_sc->high_temp * 1000 - 25000) + / (tempmon_sc->room_cnt - tempmon_sc->high_cnt); + t =3D t/100 + TZ_ZEROC; + + return (sysctl_handle_int(oidp, &t, 0, req)); +} + +static int +count_sysctl_handler(SYSCTL_HANDLER_ARGS) +{ + update_count(); + + return (sysctl_handle_int(oidp, &tempmon_sc->last, 0, req)); +} + +static int +tempmon_detach(device_t dev) +{ + struct tempmon_softc *sc; + + sc =3D device_get_softc(dev); + + return (0); +} + +static int +tempmon_attach(device_t dev) +{ + struct tempmon_softc *sc; + uint32_t cal; + int err; + struct sysctl_ctx_list *ctx; + + sc =3D device_get_softc(dev); + + /* + * Fetch calibration data: a sensor count at room temperature (25C), + * a sensor count at a high temperature, and that temperature + */ + err =3D imx6_ocotp_read_4(IMX6_OCOTP_ANA1, &cal); + if (err !=3D 0) + goto out; + sc->room_cnt =3D (cal & 0xFFF00000) >> 20; + sc->high_cnt =3D (cal & 0x000FFF00) >> 8; + sc->high_temp =3D cal & 0x000000FF; + + /* + * Set the sensor to sample automatically every ~1 second + * and power it on. + */ + imx6_anatop_write_4(IMX6_ANALOG_TEMPMON_TEMPSENSE1_SET, 0x8000); + imx6_anatop_write_4(IMX6_ANALOG_TEMPMON_TEMPSENSE0_SET, + IMX6_ANALOG_TEMPMON_TEMPSENSE0_MEASURE); + imx6_anatop_write_4(IMX6_ANALOG_TEMPMON_TEMPSENSE0_CLR, + IMX6_ANALOG_TEMPMON_TEMPSENSE0_POWER_DOWN); + + ctx =3D device_get_sysctl_ctx(dev); + SYSCTL_ADD_PROC(ctx, SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), + OID_AUTO, "temperature", CTLTYPE_INT | CTLFLAG_RD, dev, 0, + temperature_sysctl_handler, "IK", "Current die temperature"); + SYSCTL_ADD_PROC(ctx, SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), + OID_AUTO, "current_count", CTLTYPE_INT | CTLFLAG_RD, dev, 0, + count_sysctl_handler, "I", "Current sensor count"); + SYSCTL_ADD_UINT(ctx, SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), + OID_AUTO, "room_temp_count", CTLTYPE_INT | CTLFLAG_RD, + &sc->room_cnt, 0, "Counter value at 25 degrees C"); + SYSCTL_ADD_UINT(ctx, SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), + OID_AUTO, "high_temp_count", CTLTYPE_INT | CTLFLAG_RD, + &sc->high_cnt, 0, "Counter value at high calibration temperature");= + SYSCTL_ADD_UINT(ctx, SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), + OID_AUTO, "high_temp_value", CTLTYPE_INT | CTLFLAG_RD, + &sc->high_temp, 0, "Temperature at high value calibration"); + + tempmon_sc =3D sc; + err =3D 0; + +out: + if (err !=3D 0) + tempmon_detach(dev); + + return (err); +} + +static int +tempmon_probe(device_t dev) +{ + + if (!ofw_bus_status_okay(dev)) + return (ENXIO); + + if (ofw_bus_is_compatible(dev, "fsl,imx6q-tempmon") =3D=3D 0) + return (ENXIO); + + device_set_desc(dev, "Freescale i.MX6 Temperature Monitor"); + + return (BUS_PROBE_DEFAULT); +} + +static device_method_t tempmon_methods[] =3D { + /* Device interface */ + DEVMETHOD(device_probe, tempmon_probe), + DEVMETHOD(device_attach, tempmon_attach), + DEVMETHOD(device_detach, tempmon_detach), + + DEVMETHOD_END +}; + +static driver_t tempmon_driver =3D { + "tempmon", + tempmon_methods, + sizeof(struct tempmon_softc) +}; + +static devclass_t tempmon_devclass; + +DRIVER_MODULE(tempmon, simplebus, tempmon_driver, tempmon_devclass, 0, 0= ); + Property changes on: sys/arm/freescale/imx/imx6_tempmon.c ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=3D%H \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: sys/boot/fdt/dts/imx6.dtsi =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/fdt/dts/imx6.dtsi (revision 261623) +++ sys/boot/fdt/dts/imx6.dtsi (working copy) @@ -223,7 +223,7 @@ interrupts =3D <45>; status =3D "disabled"; }; - = + }; = aips@02100000 { /* AIPS2 */ @@ -317,6 +317,17 @@ bus-width =3D <0x4>; status =3D"disabled"; }; + + ocotp0: ocotp@021bc000 { + compatible =3D "fsl,imx6q-ocotp"; + reg =3D <0x021bc000 0x4000>; + status =3D"disabled"; + } }; + + tempmon: tempmon { + compatible =3D "fsl,imx6q-tempmon"; + status =3D"disabled"; + }; }; }; Index: sys/boot/fdt/dts/wandboard-quad.dts =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/fdt/dts/wandboard-quad.dts (revision 261623) +++ sys/boot/fdt/dts/wandboard-quad.dts (working copy) @@ -71,7 +71,9 @@ usdhc@02194000 { status =3D "okay"; }; usdhc@02198000 { status =3D "okay"; }; usdhc@0219c000 { status =3D "disabled"; }; + ocotp@021bc000 { status =3D "okay"; }; }; + tempmon { status =3D "okay"; }; }; = chosen { --=-1391896640-307870-43411-8607-2-=-- From owner-freebsd-arm@FreeBSD.ORG Sat Feb 8 22:11:40 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 83490ECC for ; Sat, 8 Feb 2014 22:11:40 +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 51B6913B0 for ; Sat, 8 Feb 2014 22:11:39 +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 1WCG7Y-00051g-LO; Sat, 08 Feb 2014 22:11:32 +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 s18MBTgx069840; Sat, 8 Feb 2014 15:11:29 -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: U2FsdGVkX18228w4e86AcAy9vahBgrc3 Subject: Re: i.MX6 on-die temperature sensor From: Ian Lepore To: Steven Lawrance In-Reply-To: <1391893231-sup-6174@luwak.koffein.net> References: <1391893231-sup-6174@luwak.koffein.net> Content-Type: text/plain; charset="us-ascii" Date: Sat, 08 Feb 2014 15:11:29 -0700 Message-ID: <1391897489.1196.60.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 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, 08 Feb 2014 22:11:40 -0000 On Sat, 2014-02-08 at 22:32 +0100, Steven Lawrance wrote: > Hi all, > > a Wandboard turned up on my desk yesterday and I thought I'd get > started with something simple -- the on-chip temperature sensor. > > A patch is attached, but I've got a few questions, mostly about FDTs: > > The driver doesn't need to reserve any resources for itself but rather > refer to two others, anatop and ocotp. How can that relationship be > represented in the FDT? > > How is the sequence of device attachments determined? Just by the > order in the FDT? The current scenario seems quite fragile if that's > the case. > > For the OCOTP (on-chip one-time-programmable memory) side of things, I > just followed the pattern in imx6_anatop.c, which is to provide public > methods for accessing its memory space. But it feels a bit dirty -- I > imagine there could be cases where you would have two similar blocks > and things would fall apart. > > cheers, > Yeah, the devices are attached in the order listed in the fdt, which is pretty horrible and affects us we get fdt data mostly from linux (the source of standard fdt data for boards), and it isn't driven by the order of things in the data. The thing I did with anatop was a quick hack to get things going because I have no idea what services that conglomeration of hardware needs to provide to other entities (yet). ocotp is another thing I haven't looked at much, but it might be easier to come up with a clean API it can provide for other imx drivers. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Feb 8 23:06:18 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 31C25CD1 for ; Sat, 8 Feb 2014 23:06:18 +0000 (UTC) Received: from smtpauth2.wiscmail.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F2245172C for ; Sat, 8 Feb 2014 23:06:17 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0N0P009008LC7500@smtpauth2.wiscmail.wisc.edu> for freebsd-arm@freebsd.org; Sat, 08 Feb 2014 17:06:10 -0600 (CST) X-Spam-PmxInfo: Server=avs-2, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.8.225715, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from comporellon.tachypleus.net (adsl-76-208-68-77.dsl.mdsnwi.sbcglobal.net [76.208.68.77]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0N0P00D669I90S00@smtpauth2.wiscmail.wisc.edu> for freebsd-arm@freebsd.org; Sat, 08 Feb 2014 17:06:10 -0600 (CST) Message-id: <52F6B861.8010908@freebsd.org> Date: Sat, 08 Feb 2014 17:06:09 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: freebsd-arm@freebsd.org Subject: Re: i.MX6 on-die temperature sensor References: <1391893231-sup-6174@luwak.koffein.net> <1391897489.1196.60.camel@revolution.hippie.lan> In-reply-to: <1391897489.1196.60.camel@revolution.hippie.lan> 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, 08 Feb 2014 23:06:18 -0000 On 02/08/14 16:11, Ian Lepore wrote: > On Sat, 2014-02-08 at 22:32 +0100, Steven Lawrance wrote: >> Hi all, >> >> a Wandboard turned up on my desk yesterday and I thought I'd get >> started with something simple -- the on-chip temperature sensor. >> >> A patch is attached, but I've got a few questions, mostly about FDTs: >> >> The driver doesn't need to reserve any resources for itself but rather >> refer to two others, anatop and ocotp. How can that relationship be >> represented in the FDT? >> >> How is the sequence of device attachments determined? Just by the >> order in the FDT? The current scenario seems quite fragile if that's >> the case. >> >> For the OCOTP (on-chip one-time-programmable memory) side of things, I >> just followed the pattern in imx6_anatop.c, which is to provide public >> methods for accessing its memory space. But it feels a bit dirty -- I >> imagine there could be cases where you would have two similar blocks >> and things would fall apart. >> >> cheers, >> > Yeah, the devices are attached in the order listed in the fdt, which is > pretty horrible and affects us we get fdt data mostly from linux (the > source of standard fdt data for boards), and it isn't driven by the > order of things in the data. > This isn't true. They are only attached in FDT order if your driver does not specify an alternative. -Nathan From owner-freebsd-arm@FreeBSD.ORG Sat Feb 8 23:19:35 2014 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.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 1E62ADCF; Sat, 8 Feb 2014 23:19:35 +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 E42A017DD; Sat, 8 Feb 2014 23:19:34 +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 s18NJY62052884; Sat, 8 Feb 2014 23:19:34 GMT (envelope-from brueffer@freefall.freebsd.org) Received: (from brueffer@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s18NJYt2052883; Sun, 9 Feb 2014 00:19:34 +0100 (CET) (envelope-from brueffer) Date: Sun, 9 Feb 2014 00:19:34 +0100 (CET) Message-Id: <201402082319.s18NJYt2052883@freefall.freebsd.org> To: ian@FreeBSD.org, christoph.mallon@gmx.de, brueffer@FreeBSD.org, freebsd-arm@FreeBSD.org From: brueffer@FreeBSD.org Subject: Re: arm/177685: [kernel] [patch] Correct return type and usage of at91_pio_gpio_get() 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, 08 Feb 2014 23:19:35 -0000 Synopsis: [kernel] [patch] Correct return type and usage of at91_pio_gpio_get() State-Changed-From-To: open->closed State-Changed-By: brueffer State-Changed-When: Sun Feb 9 00:18:38 CET 2014 State-Changed-Why: The changes were committed by hps in r249232 (April 2013). Thanks for the submission! http://www.freebsd.org/cgi/query-pr.cgi?pr=177685