From owner-freebsd-arm@FreeBSD.ORG Sun Nov 16 04:16:02 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3398DA97 for ; Sun, 16 Nov 2014 04:16:02 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1A32F1D0 for ; Sun, 16 Nov 2014 04:16:02 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sAG4G1p8097514 for ; Sun, 16 Nov 2014 04:16:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 195009] [patch]: [arm] Use 400 kHz as the default OMAP4 I2C bus speed Date: Sun, 16 Nov 2014 04:16:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 04:16:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195009 Ian Lepore changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |In Discussion CC| |ian@FreeBSD.org --- Comment #1 from Ian Lepore --- This isn't a great fix since the bus can actually run faster than 400KHz. The real problem is that we've long lacked a way of configuring the speed of each i2c bus in a system, so I attacked the problem from that angle. The patchset is available for review or download here at https://reviews.freebsd.org/D1174 This will allow you to set the bus speed from device hints, from the FDT data, or from a loader.conf file using for example dev.iicbus.0.frequency=400000, or it can be changed on the fly using a sysctl with the same oid/path. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sun Nov 16 07:30:13 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 681647F1 for ; Sun, 16 Nov 2014 07:30:13 +0000 (UTC) Received: from smtp.kn-bremen.de (gruenbaer.kn-bremen.de [148.251.8.79]) by mx1.freebsd.org (Postfix) with ESMTP id 29263611 for ; Sun, 16 Nov 2014 07:30:12 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 830683DE0E68; Sun, 16 Nov 2014 08:30:05 +0100 (CET) Received: from enceladus10.kn-bremen.de (noident@localhost [127.0.0.1]) by enceladus10.kn-bremen.de (8.14.5/8.14.5) with ESMTP id sAG7SNWY078229; Sun, 16 Nov 2014 08:28:23 +0100 (CET) (envelope-from nox@enceladus10.kn-bremen.de) Received: (from nox@localhost) by enceladus10.kn-bremen.de (8.14.5/8.14.5/Submit) id sAG7SNIg078228; Sun, 16 Nov 2014 08:28:23 +0100 (CET) (envelope-from nox) Date: Sun, 16 Nov 2014 08:28:23 +0100 (CET) From: Juergen Lock Message-Id: <201411160728.sAG7SNIg078228@enceladus10.kn-bremen.de> To: wilbury@gmail.com Subject: Re: VERSATILEPB image under qemu-system-arm X-Newsgroups: gmane.os.freebsd.devel.arm In-Reply-To: <546542ED.4020805@gmail.com> Organization: home Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 07:30:13 -0000 In article <546542ED.4020805@gmail.com> you write: >Hi, Hi! > >I want totest ARMemulator before I buy Raspberry PI and I ran into >following situation: > >- qemu 2.0.0 or 2.1.2 >- FreeBSD 11-CURRENT (r274409) >- Kernel VERSATILEPB (as per quickgoogling.) > >After I fire up a command: > >qemu-system-arm -M versatilepb -m 256M -cpu arm1176 -kernel >FreeBSD-VERSATILEPB.flash -hda FreeBSD-armv6-11.0-VERSATILEPB-r274409.img > >I got only result which you can see at the picturehere >(http://www.wilbury.sk/private/pics/qemu-fbsd11-rpi-hang.png) > >Is there anything that I've missed or am I doing it wrong "from >scratch"? It is supposed to work, at least there have been some success >stories :-) > I haven't tried this lately but I found this: http://kernelnomicon.org/?p=395 i.e. you probably need -global versatile_pci.broken-irq-mapping=1 passed to qemu. HTH, :) Juergen From owner-freebsd-arm@FreeBSD.ORG Sun Nov 16 10:30:53 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8661E740 for ; Sun, 16 Nov 2014 10:30:53 +0000 (UTC) Received: from ns2.wilbury.net (cmar.ltc.sk [62.176.169.19]) by mx1.freebsd.org (Postfix) with ESMTP id 42D4D6EE for ; Sun, 16 Nov 2014 10:30:52 +0000 (UTC) Received: from smtp.nic.sk (smtp.nic.sk [193.105.142.17]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smtp.nic.sk", Issuer "Starfield Secure Certification Authority" (not verified)) by ns2.wilbury.net (Postfix) with ESMTPS id 8C0893AABF5; Sun, 16 Nov 2014 11:30:44 +0100 (CET) Received: from [127.0.0.1] (remedy.wilbury.sk [IPv6:2a01:390:4::47]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "janitor", Issuer "Wilbury Consulting CA" (verified OK)) by smtp.ltc.sk (Postfix) with ESMTPS id BEDD0125E95; Sun, 16 Nov 2014 11:30:26 +0100 (CET) Message-ID: <54687CD4.8010009@gmail.com> Date: Sun, 16 Nov 2014 11:30:44 +0100 From: Juraj Lutter User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.24) Gecko/20100411 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Juergen Lock Subject: Re: VERSATILEPB image under qemu-system-arm References: <201411160728.sAG7SNIg078228@enceladus10.kn-bremen.de> In-Reply-To: <201411160728.sAG7SNIg078228@enceladus10.kn-bremen.de> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 10:30:53 -0000 On 11/16/14 08:28, Juergen Lock wrote: > I haven't tried this lately but I found this: > > http://kernelnomicon.org/?p=395 > > i.e. you probably need -global versatile_pci.broken-irq-mapping=1 > passed to qemu. > Works perectly, thanks. Interesting that I haven't found it by my self. Thanks once more /otis From owner-freebsd-arm@FreeBSD.ORG Sun Nov 16 22:46:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D6302C7 for ; Sun, 16 Nov 2014 22:46:11 +0000 (UTC) Received: from orange.myspectrum.nl (unknown [IPv6:2a01:7c8:aab2:19e:5054:ff:fe1e:7dad]) by mx1.freebsd.org (Postfix) with ESMTP id 5E8083D5 for ; Sun, 16 Nov 2014 22:46:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by orange.myspectrum.nl (Postfix) with ESMTP id DACDE85CCD for ; Sun, 16 Nov 2014 23:46:07 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at myspectrum.nl Received: from orange.myspectrum.nl ([127.0.0.1]) by localhost (orange.myspectrum.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vu8V4YxaEsdY for ; Sun, 16 Nov 2014 23:46:06 +0100 (CET) Received: from [10.0.0.105] (ip136-5-208-87.adsl2.static.versatel.nl [87.208.5.136]) (Authenticated sender: jeroen@myspectrum.nl) by orange.myspectrum.nl (Postfix) with ESMTPSA id 4171185A31 for ; Sun, 16 Nov 2014 23:46:06 +0100 (CET) Message-ID: <5469292E.7010601@myspectrum.nl> Date: Sun, 16 Nov 2014 23:46:06 +0100 From: Jeroen Hofstee User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: EEND errors Content-Type: multipart/mixed; boundary="------------040102070303000108060705" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 22:46:11 -0000 This is a multi-part message in MIME format. --------------040102070303000108060705 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, When compiling FreeBSD with a linux ARM compiler, it complains about a couple of END/EEND macro's. Attached patch should fix this. Regards, Jeroen --------------040102070303000108060705 Content-Type: text/x-patch; name="0001-arm-fix-some-EEND-END-mismatches.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-arm-fix-some-EEND-END-mismatches.patch" >From 12fc31ba2c81decb93a20ee9e878ee914837b4d1 Mon Sep 17 00:00:00 2001 From: Jeroen Hofstee Date: Sun, 16 Nov 2014 23:37:20 +0100 Subject: [PATCH] arm: fix some EEND/END mismatches --- sys/arm/arm/fusu.S | 4 ++-- sys/arm/arm/support.S | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/sys/arm/arm/fusu.S b/sys/arm/arm/fusu.S index c70215c..b55f443 100644 --- a/sys/arm/arm/fusu.S +++ b/sys/arm/arm/fusu.S @@ -129,7 +129,7 @@ EENTRY_NP(fuword32) str r1, [r2, #PCB_ONFAULT] mov r0, r3 RET -END(fuword32) +EEND(fuword32) END(fuword) /* @@ -295,7 +295,7 @@ EENTRY_NP(suword32) mov r0, #0x00000000 str r0, [r2, #PCB_ONFAULT] RET -END(suword32) +EEND(suword32) END(suword) /* diff --git a/sys/arm/arm/support.S b/sys/arm/arm/support.S index 2a6eec9..1714b0f 100644 --- a/sys/arm/arm/support.S +++ b/sys/arm/arm/support.S @@ -130,7 +130,7 @@ ENTRY(bzero) .Lnormal0: mov r3, #0x00 b do_memset -EEND(bzero) +END(bzero) /* LINTSTUB: Func: void *memset(void *, int, size_t) */ ENTRY(memset) and r3, r1, #0xff /* We deal with bytes */ -- 2.1.0 --------------040102070303000108060705-- From owner-freebsd-arm@FreeBSD.ORG Mon Nov 17 13:47:45 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3FE233C for ; Mon, 17 Nov 2014 13:47:45 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB5EF80F for ; Mon, 17 Nov 2014 13:47:45 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sAHDljan095542 for ; Mon, 17 Nov 2014 13:47:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 195009] [patch]: [arm] Use 400 kHz as the default OMAP4 I2C bus speed Date: Mon, 17 Nov 2014 13:47:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: loos@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 13:47:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195009 Luiz Otavio O Souza,+55 (14) 99772-1255 changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |loos@FreeBSD.org --- Comment #2 from Luiz Otavio O Souza,+55 (14) 99772-1255 --- (In reply to Scott Ellis from comment #0) > The I2C bus speed for OMAP4 boards defaults to 842 kHz. > > The formula for calculating this comes from the TRM table 23-8 > > scl = i2c_fclk / ( ( psc + 1) * ( (scll + 7) + (sclh + 5) ) ) > > The code says it's attempting 1 MHz, but it's using the wrong values. Yes, that is right. These values comes from TRM table 23-9 in "Fast Mode+". The TRM doesn't take into account the '+ 1' for the prescaler value (psc), but only for Fast Mode+, all the other values seems correct. For a internal clock frequency of 19.2 MHz we need to set the prescaler to 4: 96 MHz / (4 + 1) = 19.2 MHz And then the bus frequency is: 19.2 MHz / (3 + 7) + (4 + 5) = 1.010 MHz Good catch! Thanks! -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Mon Nov 17 21:53:33 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 763D5541 for ; Mon, 17 Nov 2014 21:53:33 +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]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "IronPort Appliance Demo Certificate", Issuer "IronPort Appliance Demo Certificate" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D559C0F for ; Mon, 17 Nov 2014 21:53:32 +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=1416261213; x=1447797213; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=mBck/tLY8+KulUmcVmwEkJMPAs9/5WDwPFR5fofTdpA=; b=FecDcnaBAmQrJGlgz9o8wy7cAGXo7+r5rRLCKzHDFA2rNLErw6fEwKyg AqFD8tzo3azwBErS1L8qSlAR2nIYNevNGe0DJVxElIWQ81JFPmi93Zz/c GecR8ehfuKN0zDnCVi++lbjdJE8xld9/5Io96eOhw1p0jo44kTxM5/9bE c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0EANNtalQKXgZQ/2dsb2JhbABbgmt4WQTMJAqGeVUCgScBAQEBAX2EAgEBAQQBAQFLIBcEAgEIEQQBASgHJwEJARQJCAIEAQcHBAEHFQSIIAEM0m8BAQEBBgEBAQEBAQEBAQEBF5BLBgEBJDIGgjBTgUIFi1OETIF+hQWEH4Q/PYMXgnaOfIN8bQeBAAgXIoEDAQEB X-IPAS-Result: Aq0EANNtalQKXgZQ/2dsb2JhbABbgmt4WQTMJAqGeVUCgScBAQEBAX2EAgEBAQQBAQFLIBcEAgEIEQQBASgHJwEJARQJCAIEAQcHBAEHFQSIIAEM0m8BAQEBBgEBAQEBAQEBAQEBF5BLBgEBJDIGgjBTgUIFi1OETIF+hQWEH4Q/PYMXgnaOfIN8bQeBAAgXIoEDAQEB Received: from e14hub-01.zdv.uni-mainz.de ([10.94.6.80]) by mailgate-01.zdv.uni-mainz.de with ESMTP/TLS/AES256-SHA; 17 Nov 2014 22:53:29 +0100 Received: from e15be-03.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9239) by E14HUB-01.zdv.Uni-Mainz.DE (2001:4c80:40:606:21d:d8ff:feb7:1c5f) with Microsoft SMTP Server (TLS) id 14.3.210.2; Mon, 17 Nov 2014 22:53:28 +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:9239) with Microsoft SMTP Server (TLS) id 15.0.1044.22; Mon, 17 Nov 2014 22:53:27 +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.1044.021; Mon, 17 Nov 2014 22:53:27 +0100 From: =?iso-8859-1?Q?Wei=DF=2C__Dr=2E_J=FCrgen?= To: "'ticso@cicely.de'" , "freebsd-arm@freebsd.org" Subject: RE: buildworld selfbuild failure Thread-Topic: buildworld selfbuild failure Thread-Index: AQHPzOjIkajFC1068UuZd498PKuEIJxlw8zA Date: Mon, 17 Nov 2014 21:53:27 +0000 Message-ID: References: <20140910111616.GA31990@cicely7.cicely.de> In-Reply-To: <20140910111616.GA31990@cicely7.cicely.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted 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.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 21:53:33 -0000 Same problem with freebsd current of 2 days ago on a Jetson TK1. After unmounting /usr/src and /usr/obj and mounting again, compilation with= out -j x=20 succeeds. Without unmounting /usr/src and /usr/obj calling cc directly from the shell= gives the=20 same error. using ktrace gives 59705 cc CALL open(0x22019050,0,0xa5a50063) 59705 cc NAMI "/usr/src/kerberos5/lib/libheimsqlite/../../../crypto= /heimdal/lib/sqlite/sqlite3.c" 59705 cc RET open 4 59705 cc CALL fstat(0x4,0xbfffe450) 59705 cc STRU struct stat {dev=3D973143810, ino=3D32026, mode=3D010= 0644, nlink=3D1, uid=3D0, gid=3D0, rdev=3D20792, atime=3D1416131826.7517608= 29, stime=3D1403290613, ctime=3D1413735753.593422297, birthtim e=3D-1, size=3D4623536, blksize=3D4096, blocks=3D9225, flags=3D0x0 } 59705 cc RET fstat 0 59705 cc CALL fstat(0x4,0xbfffe220) 59705 cc STRU struct stat {dev=3D973143810, ino=3D32026, mode=3D010= 0644, nlink=3D1, uid=3D0, gid=3D0, rdev=3D20792, atime=3D1416131826.7517608= 29, stime=3D1403290613, ctime=3D1413735753.593422297, birthtim e=3D-1, size=3D4623536, blksize=3D4096, blocks=3D9225, flags=3D0x0 } 59705 cc RET fstat 0 59705 cc CALL mmap(0,0x468cb0,0x1,0x2,0x4,0= xbfffe580,0,0) 59705 cc RET mmap 574619648/0x22400000 59705 cc CALL close(0x4) 59705 cc RET close 0 59705 cc PSIG SIGBUS caught handler=3D0x152de90 mask=3D0x0 code=3DS= I_NOINFO running cc in gdb and doing=20 x/x 0x22400000 after the bus error occurred, gives the following kernel panic: panic: pmap_demote_section: No l2_bucket for wired mapping cpuid =3D 0 KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc052b8d8 lr =3D 0xc023498c (db_trace_self_wrapper+0x30) sp =3D 0xf0502738 fp =3D 0xf0502850 r10 =3D 0xc563a000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc023498c lr =3D 0xc03dc920 (kdb_backtrace+0x38) sp =3D 0xf0502858 fp =3D 0xf0502860 r4 =3D 0xc0679a64 r5 =3D 0x00000001 r6 =3D 0xc05b6429 r7 =3D 0xc066a6f8 kdb_backtrace() at kdb_backtrace+0x38 pc =3D 0xc03dc920 lr =3D 0xc03a1798 (vpanic+0x114) sp =3D 0xf0502868 fp =3D 0xf0502888 r4 =3D 0x00000100 vpanic() at vpanic+0x114 pc =3D 0xc03a1798 lr =3D 0xc03a166c ($d) sp =3D 0xf0502890 fp =3D 0xf05028c0 r4 =3D 0xc066a5f8 r5 =3D 0xc05b6429 r6 =3D 0xf05028cc r7 =3D 0xc066a560 r8 =3D 0xc27012c0 r9 =3D 0x00000224 r10 =3D 0x22400000 $d() at $d pc =3D 0xc03a166c lr =3D 0xc0534e58 (pmap_demote_section+0x848) sp =3D 0xf05028d8 fp =3D 0xf0502938 r4 =3D 0x22400000 r5 =3D 0x22400000 r6 =3D 0xc5641a9c r7 =3D 0xe001983e pmap_demote_section() at pmap_demote_section+0x848 pc =3D 0xc0534e58 lr =3D 0xc0539a40 (pmap_enter_locked+0xfc) sp =3D 0xf0502940 fp =3D 0xf05029b0 r4 =3D 0xc05b59ef r5 =3D 0x22400000 r6 =3D 0xc5641a9c r7 =3D 0xc27012c0 r8 =3D 0xc06a1b80 r9 =3D 0x00000001 r10 =3D 0xc5641aac pmap_enter_locked() at pmap_enter_locked+0xfc pc =3D 0xc0539a40 lr =3D 0xc0539090 (pmap_enter+0x74) sp =3D 0xf05029b8 fp =3D 0xf0502a18 r4 =3D 0x22400000 r5 =3D 0xc27012c0 r6 =3D 0x00000001 r7 =3D 0xc05b59ef r8 =3D 0xc5641a9c r9 =3D 0x22400000 r10 =3D 0xc5641aac pmap_enter() at pmap_enter+0x74 pc =3D 0xc0539090 lr =3D 0xc04fe714 (vm_fault_hold+0x2b0) sp =3D 0xf0502a20 fp =3D 0xf0502b98 r4 =3D 0xf0502b28 r5 =3D 0xc56419e0 r6 =3D 0xc27012c0 r7 =3D 0xc05af0a4 r8 =3D 0x00000001 r9 =3D 0x22400000 r10 =3D 0xc56419e0 vm_fault_hold() at vm_fault_hold+0x2b0 pc =3D 0xc04fe714 lr =3D 0xc03fdf84 (proc_rwmem+0xa4) sp =3D 0xf0502ba0 fp =3D 0xf0502be0 r4 =3D 0xc069ae00 r5 =3D 0x00000000 r6 =3D 0xc0596ab1 r7 =3D 0x22400000 r8 =3D 0xc0596ab1 r9 =3D 0x22400000 r10 =3D 0x00000004 proc_rwmem() at proc_rwmem+0xa4 pc =3D 0xc03fdf84 lr =3D 0xc03feea4 ($a+0x624) sp =3D 0xf0502be8 fp =3D 0xf0502cf8 r4 =3D 0xc65c5c80 r5 =3D 0xf0502d08 r6 =3D 0x00000016 r7 =3D 0xc65c5d2c r8 =3D 0xc0596ab1 r9 =3D 0xc65c8a20 r10 =3D 0xc65c5e70 $a() at $a+0x624 pc =3D 0xc03feea4 lr =3D 0xc03fe190 ($a+0x38) sp =3D 0xf0502d00 fp =3D 0xf0502d98 r4 =3D 0xf0502e10 r5 =3D 0xc563a000 r6 =3D 0xf0502d08 r7 =3D 0xbffff0f8 r8 =3D 0xf0502e10 r9 =3D 0xf0502e08 r10 =3D 0x00000000 $a() at $a+0x38 pc =3D 0xc03fe190 lr =3D 0xc0541f18 (swi_handler+0x2cc) sp =3D 0xf0502da0 fp =3D 0xf0502e58 r4 =3D 0xc563a000 r5 =3D 0xc562f000 r6 =3D 0x00000000 swi_handler() at swi_handler+0x2cc pc =3D 0xc0541f18 lr =3D 0xc052d628 (swi_exit) sp =3D 0xf0502e60 fp =3D 0xbffff128 r4 =3D 0xbffff1de r5 =3D 0x002ad930 r6 =3D 0x00000000 r7 =3D 0x0000001a r8 =3D 0x00000000 r9 =3D 0x00000000 r10 =3D 0x22400000 swi_exit() at swi_exit pc =3D 0xc052d628 lr =3D 0xc052d628 (swi_exit) sp =3D 0xf0502e60 fp =3D 0xbffff128 KDB: enter: panic After disabling superpages by vm.pmap.sp_enabled=3D0 the error is gone. Regards Juergen 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 > Bernd Walter > Sent: Wednesday, September 10, 2014 1:16 PM > To: freebsd-arm@freebsd.org > Cc: Bernd Walter > Subject: buildworld selfbuild failure >=20 > The same source code was used to build with crochet and is running on > the system. > It's a Wandboard Quad with a -j8 buildworld run. > Source tree is on NFS /usr/obj on local SD. >=20 > ... > --- lib_tputs.So --- > cc -fpic -DPIC -O -pipe -I. -I/usr/obj/home/builder/arm- > build/head/lib/ncurses/ncurses/../ncurses -I/home/builder/arm- > build/head/lib/ncurses/ncurses/../ncurses -I/home/builder/arm- > build/head/lib/ncurses/ncurses/../ncurses -I/home/builder/arm- > build/head/lib/ncurses/ncurses/../../../contrib/ncurses/include -I/home/b= uilder/arm- > build/head/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall -DN= DEBUG - > DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -Wsystem-headers -= Werror -Wall -Wno- > format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototy= pes -Wpointer- > arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-pl= us-int -Wno- > unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-pa= rentheses- > equality -Wno-unused-function -Wno-enum-conversion -Qunused-arguments -c > /home/builder/arm- > build/head/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/lib= _tputs.c -o > lib_tputs.So > --- lib/ncurses/ncursesw__L --- > --- free_ttype.So --- > cc -fpic -DPIC -O -pipe -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. - > I/usr/obj/home/builder/arm-build/head/lib/ncurses/ncursesw/../ncursesw - > I/home/builder/arm-build/head/lib/ncurses/ncursesw/../ncursesw -I/home/bu= ilder/arm- > build/head/lib/ncurses/ncursesw/../ncurses -I/home/builder/arm- > build/head/lib/ncurses/ncursesw/../../../contrib/ncurses/include -I/home/= builder/arm- > build/head/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses -Wall -D= NDEBUG - > DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -Wsystem-headers -= Werror -Wall -Wno- > format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototy= pes -Wpointer- > arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-pl= us-int -Wno- > unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-pa= rentheses- > equality -Wno-unused-function -Wno-enum-conversion -Qunused-arguments -c > /home/builder/arm- > build/head/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/tinfo/fr= ee_ttype.c -o > free_ttype.So > --- kerberos5/lib/libheimsqlite__L --- > cc: error: unable to execute command: Bus error (core dumped) > cc: error: clang frontend command failed due to signal (use -v to see inv= ocation) > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > Target: armv6--freebsd11.0-gnueabi > Thread model: posix > cc: note: diagnostic msg: PLEASE submit a bug report to https://bugs.free= bsd.org/submit/ > and include the crash backtrace, preprocessed source, and associated run = script. > cc: note: diagnostic msg: Error generating preprocessed source(s). > *** [sqlite3.o] Error code 254 >=20 > make[4]: stopped in /home/builder/arm-build/head/kerberos5/lib/libheimsql= ite > --- lib/msun__L --- > A failure has been detected in another branch of the parallel make >=20 > make[4]: stopped in /home/builder/arm-build/head/lib/msun > --- lib/ncurses/ncursesw__L --- > A failure has been detected in another branch of the parallel make >=20 > make[4]: stopped in /home/builder/arm-build/head/lib/ncurses/ncursesw > --- lib/ncurses/ncurses__L --- > A failure has been detected in another branch of the parallel make >=20 > make[4]: stopped in /home/builder/arm-build/head/lib/ncurses/ncurses > --- kerberos5/lib/libheimsqlite__L --- > 1 error >=20 > make[4]: stopped in /home/builder/arm-build/head/kerberos5/lib/libheimsql= ite > --- secure/lib/libcrypto__L --- > A failure has been detected in another branch of the parallel make >=20 > make[4]: stopped in /home/builder/arm-build/head/secure/lib/libcrypto > A failure has been detected in another branch of the parallel make >=20 > make[3]: stopped in /home/builder/arm-build/head > *** [libraries] Error code 2 >=20 > make[2]: stopped in /home/builder/arm-build/head > 1 error >=20 > make[2]: stopped in /home/builder/arm-build/head > *** [_libraries] Error code 2 >=20 > make[1]: stopped in /home/builder/arm-build/head > 1 error >=20 > make[1]: stopped in /home/builder/arm-build/head > *** [buildworld] Error code 2 >=20 > make: stopped in /home/builder/arm-build/head > 1 error >=20 > make: stopped in /home/builder/arm-build/head > 71773.091u 36752.279s 2:47:24.86 1080.4% -40+98k 2728+6318io 4153p= f+0w > Exit 2 >=20 >=20 > [170]wandboard# gdb /usr/obj/home/builder/arm-build/head/tmp/usr/bin/cc c= c.core > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "armv6-marcel-freebsd"...(no debugging symbols= found)... > Core was generated by `cc'. > Program terminated with signal 10, Bus error. > #0 0x008dc410 in clang::SrcMgr::ContentCache::getBuffer () > (gdb) bt > #0 0x008dc410 in clang::SrcMgr::ContentCache::getBuffer () > #1 0x00914330 in clang::SourceManager::getBuffer () > #2 0x00912260 in clang::Preprocessor::EnterSourceFile () > #3 0x008f70e8 in clang::Preprocessor::EnterMainSourceFile () > #4 0x0030e760 in clang::ParseAST () > #5 0x000411bc in clang::ASTFrontendAction::ExecuteAction () > #6 0x001c0998 in clang::CodeGenAction::ExecuteAction () > #7 0x00040a38 in clang::FrontendAction::Execute () > #8 0x00060120 in clang::CompilerInstance::ExecuteAction () > #9 0x00010340 in $a () > #10 0x00010340 in $a () > (gdb) >=20 >=20 > Retry without -j: > CC=3D'cc ' mkdep -f .depend -a -I/home/builder/arm- > build/head/kerberos5/lib/libheimsqlite/../../../crypto/heimdal/lib/sqlite= -DHAVE_CONFIG_H > -I/home/builder/arm-build/head/kerberos5/lib/libheimsqlite/../../include = -std=3Dgnu99 > /home/builder/arm- > build/head/kerberos5/lib/libheimsqlite/../../../crypto/heimdal/lib/sqlite= /sqlite3.c > Stack dump: > 0. Program arguments: /usr/obj/home/builder/arm-build/head/tmp/usr/b= in/cc -cc1 - > triple armv6--freebsd11.0-gnueabi -Eonly -disable-free -main-file-name sq= lite3.c - > mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-= cpu arm1176jzf-s > -target-feature +soft-float -target-feature +soft-float-abi -target-featu= re -neon -target- > abi aapcs-linux -msoft-float -mfloat-abi soft -resource-dir /usr/obj/home= /builder/arm- > build/head/tmp/usr/bin/../lib/clang/3.4.1 -dependency-file - -MT sqlite3.= o -sys-header- > deps -D HAVE_CONFIG_H -I /home/builder/arm- > build/head/kerberos5/lib/libheimsqlite/../../../crypto/heimdal/lib/sqlite= -I > /home/builder/arm-build/head/kerberos5/lib/libheimsqlite/../../include -i= sysroot > /usr/obj/home/builder/arm-build/head/tmp -std=3Dgnu99 -fno-dwarf-director= y-asm -fdebug- > compilation-dir /usr/obj/home/builder/arm-build/head/kerberos5/lib/libhei= msqlite -ferror- > limit 19 -fmessage-length 132 -mstackrealign -fno-signed-char -fobjc-runt= ime=3Dgnustep - > fdiagnostics-show > -option -fcolor-diagnostics -vectorize-slp -x c /home/builder/arm- > build/head/kerberos5/lib/libheimsqlite/../../../crypto/heimdal/lib/sqlite= /sqlite3.c > cc: error: unable to execute command: Bus error (core dumped) > cc: error: clang frontend command failed due to signal (use -v to see inv= ocation) > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > Target: armv6--freebsd11.0-gnueabi > Thread model: posix > cc: note: diagnostic msg: PLEASE submit a bug report to https://bugs.free= bsd.org/submit/ > and include the crash backtrace, preprocessed source, and associated run = script. > cc: error: unable to execute command: Bus error (core dumped) > cc: note: diagnostic msg: Error generating preprocessed source(s). > mkdep: compile failed > *** Error code 1 >=20 > Stop. > make[4]: stopped in /home/builder/arm-build/head/kerberos5/lib/libheimsql= ite > *** Error code 1 >=20 > Stop. > make[3]: stopped in /home/builder/arm-build/head > *** Error code 1 >=20 > Stop. > make[2]: stopped in /home/builder/arm-build/head > *** Error code 1 >=20 > Stop. > make[1]: stopped in /home/builder/arm-build/head > *** Error code 1 >=20 > Stop. > make: stopped in /home/builder/arm-build/head > 24569.709u 5898.985s 6:06:54.09 138.4% 116+219k 2557+11302io 77pf+0w > Exit 1 > [175]wandboard# >=20 > [180]wandboard# date > Wed Sep 10 10:20:14 UTC 2014 > [181]wandboard# gdb /usr/obj/home/builder/arm-build/head/tmp/usr/bin/cc c= c.core > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "armv6-marcel-freebsd"...(no debugging symbols= found)... > Core was generated by `cc'. > Program terminated with signal 10, Bus error. > #0 0x008dc410 in clang::SrcMgr::ContentCache::getBuffer () > (gdb) bt > #0 0x008dc410 in clang::SrcMgr::ContentCache::getBuffer () > #1 0x00914330 in clang::SourceManager::getBuffer () > #2 0x00912260 in clang::Preprocessor::EnterSourceFile () > #3 0x008f70e8 in clang::Preprocessor::EnterMainSourceFile () > #4 0x00013ac8 in clang::PreprocessOnlyAction::ExecuteAction () > #5 0x00040a38 in clang::FrontendAction::Execute () > #6 0x00060120 in clang::CompilerInstance::ExecuteAction () > #7 0x00010340 in $a () > #8 0x00010340 in $a () >=20 >=20 > It's not obvious from -j8 run, but it happened when compiling in the same > directory, maybe even the same file. >=20 > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > _______________________________________________ > 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 Tue Nov 18 01:55:31 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0208656F for ; Tue, 18 Nov 2014 01:55:31 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C3AAF88F for ; Tue, 18 Nov 2014 01:55:30 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sAI1tUPJ042873 for ; Tue, 18 Nov 2014 01:55:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 195009] [patch]: [arm] Use 400 kHz as the default OMAP4 I2C bus speed Date: Tue, 18 Nov 2014 01:55:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 01:55:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195009 --- Comment #3 from commit-hook@freebsd.org --- A commit references this bug: Author: ian Date: Tue Nov 18 01:54:33 UTC 2014 New revision: 274641 URL: https://svnweb.freebsd.org/changeset/base/274641 Log: Allow i2c bus speed to be configured via hints, FDT data, and sysctl. The current support for controlling i2c bus speed is an inconsistant mess. There are 4 symbolic speed values defined, UNKNOWN, SLOW, FAST, FASTEST. It seems to be universally assumed that SLOW means the standard 100KHz rate from the original spec. Nothing ever calls iicbus_reset() with a speed of FAST, although some drivers would treat it as the 400KHz standard speed. Mostly iicbus_reset() is called with the speed set to UNKNOWN or FASTEST, and there's really no telling what any individual driver will do with those. The speed of an i2c bus is limited by the speed of the slowest device on the bus. This means that generally the bus speed needs to be configured based on the board/system and the components within it. Historically for i2c we've configured with device hints. Newer systems use FDT data and it documents a clock-frequency property for i2c busses. Hobbyists and developers are likely to want on the fly changes. These changes provide all 3 methods, but do not require any existing drivers to change to use the new facilities. This adds an iicbus method, iicbus_get_frequency(dev, speed) that gets the frequency for the requested symbolic speed. If the symbolic speed is SLOW or if there is no speed configured for the bus, the returned value is 100KHz, always. Otherwise, if bus speed is configured by hints, fdt, tunable, or sysctl, that speed is returned. It also adds a helper function, iicbus_init_frequency() that any bus driver subclassed from iicbus can initialize the frequency from some other source of info. Initial driver implementations are provided for Freescale and TI. Differential Revision: https://reviews.freebsd.org/D1174 PR: 195009 Changes: head/sys/arm/freescale/imx/imx_i2c.c head/sys/arm/ti/ti_i2c.c head/sys/dev/iicbus/iicbus.c head/sys/dev/iicbus/iicbus.h head/sys/dev/iicbus/iicbus_if.m head/sys/dev/ofw/ofw_iicbus.c -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue Nov 18 02:02:15 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35D096C4 for ; Tue, 18 Nov 2014 02:02:15 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1DEAE977 for ; Tue, 18 Nov 2014 02:02:15 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sAI22EBC083606 for ; Tue, 18 Nov 2014 02:02:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 195009] [patch]: [arm] Use 400 kHz as the default OMAP4 I2C bus speed Date: Tue, 18 Nov 2014 02:02:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 02:02:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195009 --- Comment #4 from Ian Lepore --- (In reply to Luiz Otavio O Souza from comment #2) > (In reply to Scott Ellis from comment #0) > > The I2C bus speed for OMAP4 boards defaults to 842 kHz. > > > > The formula for calculating this comes from the TRM table 23-8 > > > > scl = i2c_fclk / ( ( psc + 1) * ( (scll + 7) + (sclh + 5) ) ) > > > > The code says it's attempting 1 MHz, but it's using the wrong values. > > Yes, that is right. > > These values comes from TRM table 23-9 in "Fast Mode+". > > The TRM doesn't take into account the '+ 1' for the prescaler value (psc), > but only for Fast Mode+, all the other values seems correct. > > For a internal clock frequency of 19.2 MHz we need to set the prescaler to 4: > > 96 MHz / (4 + 1) = 19.2 MHz > > And then the bus frequency is: > > 19.2 MHz / (3 + 7) + (4 + 5) = 1.010 MHz > > Good catch! Thanks! I'm thinking of fixing this a different way... { 1000000, 5, 1, 3, 0, 0}, That gives 96 / 6 = 16 MHz then 16 / (1 + 7 + 3 + 5) = 1 MHz exactly. I've got another commit coming that fixes this and the fact that we've been running the i2c bus at half speed on beaglebone/am335x systems (root clock is 48mhz not 96). -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue Nov 18 03:27:37 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB3A1491 for ; Tue, 18 Nov 2014 03:27:37 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9341F1D9 for ; Tue, 18 Nov 2014 03:27:37 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sAI3Rbp5096827 for ; Tue, 18 Nov 2014 03:27:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 195009] [patch]: [arm] Use 400 kHz as the default OMAP4 I2C bus speed Date: Tue, 18 Nov 2014 03:27:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 03:27:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195009 --- Comment #5 from commit-hook@freebsd.org --- A commit references this bug: Author: ian Date: Tue Nov 18 03:26:52 UTC 2014 New revision: 274644 URL: https://svnweb.freebsd.org/changeset/base/274644 Log: Fix the i2c bus speed divisors for TI OMAP4 and AM335x. For OMAP4, the old values for 1MHz gave a bus frequency of about 890KHz. The new numbers hit 1MHz exactly. For AM335x the prescaler values are adjusted to give a 24MHz clock for all 3 standard speeds, as the manual recommends (as near as we can tell, there are errors and typos apparent in the document). Also, 1MHz speed is added, and has been tested successfully on a BeagleboneWhite board. PR: 195009 Changes: head/sys/arm/ti/ti_i2c.c -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue Nov 18 05:43:00 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F43A3E4 for ; Tue, 18 Nov 2014 05:43:00 +0000 (UTC) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D2304FC2 for ; Tue, 18 Nov 2014 05:42:59 +0000 (UTC) Received: by mail-qg0-f54.google.com with SMTP id q107so191510qgd.27 for ; Mon, 17 Nov 2014 21:42: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:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=eQs1eTvrDjq9JBI6ey8JZ0onMpCxw16HDeQesojV2nY=; b=SmXMxhEubfLU3ieBrEjeoa1nQ1k6stoKCZC7KeNH/6T1+0TS9uBskk5ABo4PIsV0kJ GpP4AJ7nwpk/fBc1FP+ZZJSTTTWrK7770vbHqFLMwkM2KtDJMxV8G9MQxopjTwG9ME98 uEmDCZ0a3x3C2Q4LBt90zWaMGLIt/wh2/N4bdYl6uFo3xlnAg87Dl9x0hftRLTh1XPbt bPK3Lb3EbfGwIvuSKzNWWo/F0DonawB/b8HtYlgWghMqktJwDIoHdq01B4SXsIRZZeP9 tQ/pyJfLWgNZo7JwjTlH3+UduS6iLilRECtuHClIzp0SvfAa9d5KoWQWIjpUw6sVqNTr EDBQ== X-Gm-Message-State: ALoCoQkaNlirA/Ep5ZsgyRGA6O0JnuQMTIghyaEokUiXMHfdzzUiH8zdD3QBIruMfNdN3T04OPRU MIME-Version: 1.0 X-Received: by 10.140.21.106 with SMTP id 97mr40268648qgk.61.1416289377637; Mon, 17 Nov 2014 21:42:57 -0800 (PST) Received: by 10.140.240.83 with HTTP; Mon, 17 Nov 2014 21:42:57 -0800 (PST) Received: by 10.140.240.83 with HTTP; Mon, 17 Nov 2014 21:42:57 -0800 (PST) In-Reply-To: References: Date: Tue, 18 Nov 2014 00:42:57 -0500 Message-ID: Subject: 3D accelerated support under BeagleBone Black From: Black Fox To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 05:43:00 -0000 Hello, I have a BeagleBone Black here and I have an LCD I hooked up to it to get graphics. I was wondering whether the DVI header is working, because I'd love to get this onto a bigger screen. From owner-freebsd-arm@FreeBSD.ORG Tue Nov 18 06:13:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 442938BA for ; Tue, 18 Nov 2014 06:13:03 +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)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 15A95385 for ; Tue, 18 Nov 2014 06:13:02 +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 sAI6D1tW048493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Nov 2014 22:13:01 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAI6D1Ib048492; Mon, 17 Nov 2014 22:13:01 -0800 (PST) (envelope-from jmg) Date: Mon, 17 Nov 2014 22:13:01 -0800 From: John-Mark Gurney To: Black Fox Subject: Re: 3D accelerated support under BeagleBone Black Message-ID: <20141118061301.GY24601@funkthat.com> Mail-Followup-To: Black Fox , freebsd-arm@freebsd.org References: 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 IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 17 Nov 2014 22:13:02 -0800 (PST) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 06:13:03 -0000 Black Fox wrote this message on Tue, Nov 18, 2014 at 00:42 -0500: > I have a BeagleBone Black here and I have an LCD I hooked up to it to get > graphics. I was wondering whether the DVI header is working, because I'd > love to get this onto a bigger screen. Sadly, the docs for the HDMI framer chip requires an NDA... Once I get a copy of the programming docs, I plan to get things working... -- 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 Tue Nov 18 07:21: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C11C660 for ; Tue, 18 Nov 2014 07:21:05 +0000 (UTC) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 18169B18 for ; Tue, 18 Nov 2014 07:21:04 +0000 (UTC) Received: by mail-qc0-f172.google.com with SMTP id m20so4020421qcx.31 for ; Mon, 17 Nov 2014 23:20:58 -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=DuKRC6ubHMMDK0e1yxhjrIXP4vESnKn+vIk8W4sm1Zg=; b=jXWz9vsm30/RC6DK7tNfQL4082knRTMkpnFNKLdENDrlbLfuEwhPXlFix2mSUctoBl Y1Ieq9LjfNQ/9BKcGT/1xV8APXp5pM68QfkYH6uotHfCDU590hzyUKPBDHKCz9kTZtoL e3ANVBZ4n8+sYtX/qZHo3BxBX7Ik87iyNfUqfZjrWs4vsz/J2XKfc3/io7n+bNrYhK1K mdxFmKzk+3pViGKHyfDeaJXzePwHxzq8mFESgfqoJktLc74fdtk2AHnoUh3qQwETMRIU 7i0yOiOwH76XciXaKRn5Gr7N1FbhY9/wht4CHZ88YJ8QF6sw8Dan0dUJkfvirVpBDfA7 nacA== X-Gm-Message-State: ALoCoQlQpw1SFzU9ExO6R9qfi+y67mGXe+9jpSzvZw+CAV2gpg95F4SqmYgbmBH3d/sk7a4C86aN MIME-Version: 1.0 X-Received: by 10.140.96.203 with SMTP id k69mr16235889qge.33.1416291328188; Mon, 17 Nov 2014 22:15:28 -0800 (PST) Received: by 10.140.240.83 with HTTP; Mon, 17 Nov 2014 22:15:28 -0800 (PST) Received: by 10.140.240.83 with HTTP; Mon, 17 Nov 2014 22:15:28 -0800 (PST) In-Reply-To: <20141118061301.GY24601@funkthat.com> References: <20141118061301.GY24601@funkthat.com> Date: Tue, 18 Nov 2014 01:15:28 -0500 Message-ID: Subject: Re: 3D accelerated support under BeagleBone Black From: Black Fox To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 07:21:05 -0000 On 18 Nov 2014 01:13, "John-Mark Gurney" wrote: > > Black Fox wrote this message on Tue, Nov 18, 2014 at 00:42 -0500: > > I have a BeagleBone Black here and I have an LCD I hooked up to it to get > > graphics. I was wondering whether the DVI header is working, because I'd > > love to get this onto a bigger screen. > > Sadly, the docs for the HDMI framer chip requires an NDA... Once I > get a copy of the programming docs, I plan to get things working... Ah yes company NDAs are pretty awful to deal with. So I guess this applies for the DVI header/cape as well? Good luck and keep us updated on progress > > -- > 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 Tue Nov 18 11:16:36 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32C7364A; Tue, 18 Nov 2014 11:16:36 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id F20D7650; Tue, 18 Nov 2014 11:16:35 +0000 (UTC) Received: from bender.lan (97e078e7.skybroadband.com [151.224.120.231]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id A0F0E7328F; Tue, 18 Nov 2014 11:16:28 +0000 (UTC) Date: Tue, 18 Nov 2014 11:16:23 +0000 From: Andrew Turner To: freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org Subject: FDT patch for testing Message-ID: <20141118111623.398d95ae@bender.lan> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/XVDG2gO_jWjC=1=jAs3RNpI" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 11:16:36 -0000 --MP_/XVDG2gO_jWjC=1=jAs3RNpI Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm looking for a review and testing of the attached fdt patch. It is from a review at [1]. It updates fdt_get_range to remove the assumption it's parent bus address is directly usable. Instead it checks if the parent has a ranges property and looks up the bus address there. If there is no such property it keeps the existing behaviour. The two users of this function are the FDT uart and Marvell interrupt controller. Because it has a chance to stop the uart from woking I would like it if it could be tested on a few boards before I commit it. I have tested it on a Pandaboard so would be interested in the results on other FDT enabled boards. Andrew [1] https://reviews.freebsd.org/D1160 --MP_/XVDG2gO_jWjC=1=jAs3RNpI Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=D1160.diff Index: sys/dev/fdt/fdt_common.c =================================================================== --- sys/dev/fdt/fdt_common.c +++ sys/dev/fdt/fdt_common.c @@ -64,12 +64,84 @@ struct fdt_ic_list fdt_ic_list_head = SLIST_HEAD_INITIALIZER(fdt_ic_list_head); +static int +fdt_get_range_by_busaddr(phandle_t node, u_long addr, u_long *base, + u_long *size) +{ + pcell_t ranges[32], *rangesptr; + pcell_t addr_cells, size_cells, par_addr_cells; + u_long bus_addr, par_bus_addr, pbase, psize; + int err, i, len, tuple_size, tuples; + + if ((fdt_addrsize_cells(node, &addr_cells, &size_cells)) != 0) + return (ENXIO); + /* + * Process 'ranges' property. + */ + par_addr_cells = fdt_parent_addr_cells(node); + if (par_addr_cells > 2) { + return (ERANGE); + } + + len = OF_getproplen(node, "ranges"); + if (len < 0) + return (-1); + if (len > sizeof(ranges)) + return (ENOMEM); + if (len == 0) { + *base = 0; + *size = ULONG_MAX; + return (0); + } + + if (OF_getprop(node, "ranges", ranges, sizeof(ranges)) <= 0) + return (EINVAL); + + tuple_size = addr_cells + par_addr_cells + size_cells; + tuples = len / (tuple_size * sizeof(cell_t)); + + if (fdt_ranges_verify(ranges, tuples, par_addr_cells, + addr_cells, size_cells)) { + return (ERANGE); + } + *base = 0; + *size = 0; + + for (i = 0; i < tuples; i++) { + rangesptr = &ranges[i * tuple_size]; + + bus_addr = fdt_data_get((void *)rangesptr, addr_cells); + if (bus_addr != addr) + continue; + rangesptr += addr_cells; + + par_bus_addr = fdt_data_get((void *)rangesptr, par_addr_cells); + rangesptr += par_addr_cells; + + err = fdt_get_range_by_busaddr(OF_parent(node), par_bus_addr, + &pbase, &psize); + if (err > 0) + return (err); + if (err == 0) + *base = pbase; + else + *base = par_bus_addr; + + *size = fdt_data_get((void *)rangesptr, size_cells); + + return (0); + } + + return (EINVAL); +} + int fdt_get_range(phandle_t node, int range_id, u_long *base, u_long *size) { pcell_t ranges[6], *rangesptr; pcell_t addr_cells, size_cells, par_addr_cells; - int len, tuple_size, tuples; + u_long par_bus_addr, pbase, psize; + int err, len, tuple_size, tuples; if ((fdt_addrsize_cells(node, &addr_cells, &size_cells)) != 0) return (ENXIO); @@ -109,8 +181,17 @@ *base = fdt_data_get((void *)rangesptr, addr_cells); rangesptr += addr_cells; - *base += fdt_data_get((void *)rangesptr, par_addr_cells); + + par_bus_addr = fdt_data_get((void *)rangesptr, par_addr_cells); rangesptr += par_addr_cells; + + err = fdt_get_range_by_busaddr(OF_parent(node), par_bus_addr, + &pbase, &psize); + if (err == 0) + *base += pbase; + else + *base += par_bus_addr; + *size = fdt_data_get((void *)rangesptr, size_cells); return (0); } @@ -292,7 +373,7 @@ /* Find out #address-cells of the superior bus. */ if (OF_searchprop(OF_parent(node), "#address-cells", &addr_cells, sizeof(addr_cells)) <= 0) - addr_cells = 2; + return (2); return ((int)fdt32_to_cpu(addr_cells)); } --MP_/XVDG2gO_jWjC=1=jAs3RNpI-- From owner-freebsd-arm@FreeBSD.ORG Tue Nov 18 15:25: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A767B28 for ; Tue, 18 Nov 2014 15:25:40 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 82AFE5E2 for ; Tue, 18 Nov 2014 15:25:40 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sAIFPeCC064490 for ; Tue, 18 Nov 2014 15:25:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 195009] [patch]: [arm] Use 400 kHz as the default OMAP4 I2C bus speed Date: Tue, 18 Nov 2014 15:25:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jumpnowtek@gmail.com X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 15:25:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195009 --- Comment #6 from Scott Ellis --- Running r274646 on an OMAP4 Duovero Modifying i2c speeds through sysctl isn't working. sysctl says the speed has changed, but the when using the bus, the speed remains what it was at boot. Modifying the speed through loader.conf or the dts file works. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue Nov 18 15:33:52 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE365DB1 for ; Tue, 18 Nov 2014 15:33:52 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 965C1767 for ; Tue, 18 Nov 2014 15:33:52 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sAIFXqdk006349 for ; Tue, 18 Nov 2014 15:33:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 195009] [patch]: [arm] Use 400 kHz as the default OMAP4 I2C bus speed Date: Tue, 18 Nov 2014 15:33:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 15:33:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195009 --- Comment #7 from Ian Lepore --- You need to reset the bus after changing the speed with sysctl to make the change take effect, i2c -r -f /dev/iic#. I'm waiting for a review from the documentation team before I check in the new manpage that tells you that. :) Also, I forgot to mention in the commit message, but I checked the bus speeds with an oscilloscope on a beaglebone white to verify that the new divisors are correct. I also verified that i2c eeprom devices can be read at all 3 speeds. I don't have hardware to test omap4. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue Nov 18 16:15:52 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22220149 for ; Tue, 18 Nov 2014 16:15:52 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A10EC4D for ; Tue, 18 Nov 2014 16:15:52 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sAIGFpm3064733 for ; Tue, 18 Nov 2014 16:15:51 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 195009] [patch]: [arm] Use 400 kHz as the default OMAP4 I2C bus speed Date: Tue, 18 Nov 2014 16:15:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jumpnowtek@gmail.com X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 16:15:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195009 --- Comment #8 from Scott Ellis --- Excellent! i2c -r -f /dev/iic# is working great here. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue Nov 18 18:17:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42FA1ED2 for ; Tue, 18 Nov 2014 18:17:03 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::4]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCD20EA6 for ; Tue, 18 Nov 2014 18:17:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416334597; l=5996; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:Subject:To:From: Date; bh=BHr5EEz40cRSdmNnh2KuChcFq1I=; b=KUn8LR2D68L3Z4wPDruBtMU81cIkUcKZjgoH4AkJUfY+D0F4aDXZwjbtPqw/tekLkXG mmAFylmwcZ1qb/SxVoMRIREcitDdNus23ruHQ5v6oeUIfU9Rlo8ZhrPqGtWoSe9KKmE2q KiWMsNzwXnAJvJaSZnrzC4nJJsdwxlrNaxM= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg48v8v5Nss= X-RZG-CLASS-ID: mo00 Received: from bbu (p54869347.dip0.t-ipconnect.de [84.134.147.71]) by smtp.strato.de (RZmta 35.12 DYNA|AUTH) with ESMTPSA id 6079e5qAIIGQK5J (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) for ; Tue, 18 Nov 2014 19:16:26 +0100 (CET) Date: Tue, 18 Nov 2014 19:16:25 +0100 From: Ulrich Grey To: freebsd-arm@freebsd.org Subject: Compilation x11/libX11 fails with panic Message-Id: <20141118191625.ec7749080739e8472405a645@ulrich-grey.de> Organization: - X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; armv6-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 18:17:03 -0000 I am trying to compile x11/libX11 with a Wandboard-Quad: FreeBSD 11.0-CURRENT #0 r274634M: Tue Nov 18 00:44:36 UTC 2014 gwgpi@quad:/usr/local/DEVEL/obj/usr/local/DEVEL/SRC/head/sys/WANDBOARD-QUAD arm FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: Cortex A9-r2 rev 10 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext The compilation fails with this message: --- XKBGeom.lo --- CC XKBGeom.lo --- XKBSetGeom.lo --- CC XKBSetGeom.lo : jemalloc_arena.c:600: Failed assertion: "arena_mapbits_unzeroed_get(chunk, i) == unzeroed" This causes a panic: root@quad:/usr/local/DEVEL/CRASH # panic: vm_radix_insert: key 111 is already present cpuid = 1 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc246968c lr = 0xc20435f0 (db_trace_self_wrapper+0x30) sp = 0xfb1c2660 fp = 0xfb1c2778 r10 = 0xc74a9680 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc20435f0 lr = 0xc21e3d14 (kdb_backtrace+0x38) sp = 0xfb1c2780 fp = 0xfb1c2788 r4 = 0xc25ad634 r5 = 0xc24c6686 r6 = 0x00000001 r7 = 0xc259e310 kdb_backtrace() at kdb_backtrace+0x38 pc = 0xc21e3d14 lr = 0xc219f68c (panic+0x124) sp = 0xfb1c2790 fp = 0xfb1c27b0 r4 = 0x00000100 panic() at panic+0x124 pc = 0xc219f68c lr = 0xc245b19c ($d) sp = 0xfb1c27c8 fp = 0xfb1c27f8 r4 = 0xffffffe6 r5 = 0xe0675b84 r6 = 0xc480f041 r7 = 0x00000100 r8 = 0x0000ffff r9 = 0x00000111 r10 = 0xc480f041 $d() at $d pc = 0xc245b19c lr = 0xc244f5a4 (vm_page_alloc+0x5c4) sp = 0xfb1c2800 fp = 0xfb1c2848 r4 = 0xc7da8640 r5 = 0xc7da8640 r6 = 0xc480f058 r7 = 0x00000000 r8 = 0x00000110 r9 = 0xc480f040 r10 = 0x00000000 vm_page_alloc() at vm_page_alloc+0x5c4 pc = 0xc244f5a4 lr = 0xc24512d8 (vm_page_grab+0x80) sp = 0xfb1c2850 fp = 0xfb1c2890 r4 = 0x00000000 r5 = 0xc7da8640 r6 = 0x00000111 r7 = 0xc7da8650 r8 = 0x00000111 r9 = 0x00000000 r10 = 0xc7da8670 vm_page_grab() at vm_page_grab+0x80 pc = 0xc24512d8 lr = 0xc2223a10 (uiomove_object+0x154) sp = 0xfb1c2898 fp = 0xfb1c28f8 r4 = 0x00111000 r5 = 0xc7da8650 r6 = 0x00000111 r7 = 0x00000000 r8 = 0xc7da8650 r9 = 0x00001000 r10 = 0x00000000 uiomove_object() at uiomove_object+0x154 pc = 0xc2223a10 lr = 0xc210ef44 (tmpfs_write+0x184) sp = 0xfb1c2900 fp = 0xfb1c2938 r4 = 0xc7c85a20 r5 = 0xfb1c2a58 r6 = 0x0000000e r7 = 0x00000001 r8 = 0xc7c79b98 r9 = 0xc7c79b80 r10 = 0xfb1c2a38 tmpfs_write() at tmpfs_write+0x184 pc = 0xc210ef44 lr = 0xc24952f0 (VOP_WRITE_APV+0x194) sp = 0xfb1c2940 fp = 0xfb1c29f8 r4 = 0xfb1c2a58 r5 = 0xc74a9680 r6 = 0x00000000 r7 = 0x00000000 r8 = 0x00000000 r9 = 0xc2562a74 r10 = 0x00000001 VOP_WRITE_APV() at VOP_WRITE_APV+0x194 pc = 0xc24952f0 lr = 0xc22731dc (vn_rdwr+0x2a8) sp = 0xfb1c2a00 fp = 0xfb1c2a88 r4 = 0x00004101 r5 = 0xc74a9680 r6 = 0x00000000 r7 = 0xfb1c2a58 r8 = 0xfb1c2ab8 r9 = 0xc7c85a20 vn_rdwr() at vn_rdwr+0x2a8 pc = 0xc22731dc lr = 0xc2273640 (vn_rdwr_inchunks+0xa4) sp = 0xfb1c2a90 fp = 0xfb1c2ad8 r4 = 0x21ced000 r5 = 0x00010000 r6 = 0x00000000 r7 = 0x00713000 r8 = 0x00713000 r9 = 0x00110000 r10 = 0x00000001 vn_rdwr_inchunks() at vn_rdwr_inchunks+0xa4 pc = 0xc2273640 lr = 0xc2133dcc (elf32_coredump+0x840) sp = 0xfb1c2ae0 fp = 0xfb1c2b88 r4 = 0xc73ca900 r5 = 0x00000000 r6 = 0x00000002 r7 = 0x00000000 r8 = 0xc73ca940 r9 = 0x00000000 r10 = 0x00023000 elf32_coredump() at elf32_coredump+0x840 pc = 0xc2133dcc lr = 0xc21a3144 ($a+0x51c) sp = 0xfb1c2b90 fp = 0xfb1c2d68 r4 = 0xc213358c r5 = 0x0000004e r6 = 0xc7431500 r7 = 0xc7c85a20 r8 = 0xc7503000 r9 = 0xc75030ac r10 = 0xc7c85af8 $a() at $a+0x51c pc = 0xc21a3144 lr = 0xc21a3cf8 (sys_sigaltstack) sp = 0xfb1c2d70 fp = 0xfb1c2e18 r4 = 0x00000005 r5 = 0xc74a9680 r6 = 0xc7d76000 r7 = 0x00000001 r8 = 0xc7503000 r9 = 0xc7503000 r10 = 0x00000006 sys_sigaltstack() at sys_sigaltstack pc = 0xc21a3cf8 lr = 0xc21f7734 (ast+0x4f4) sp = 0xfb1c2e20 fp = 0xfb1c2e58 r4 = 0xc75030ac r5 = 0xc7503000 r6 = 0x00020804 r7 = 0x00000ab8 ast() at ast+0x4f4 pc = 0xc21f7734 lr = 0xc246b41c (swi_exit+0x40) sp = 0xfb1c2e60 fp = 0xbffff1e8 r4 = 0x40000013 r5 = 0xc74a9680 r6 = 0x00000000 r7 = 0x00000025 r8 = 0x01a75e18 r9 = 0x21c000c0 r10 = 0x01a75e3c swi_exit() at swi_exit+0x40 pc = 0xc246b41c lr = 0xc246b41c (swi_exit+0x40) sp = 0xfb1c2e60 fp = 0xbffff1e8 KDB: enter: panic [ thread pid 7797 tid 100107 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! db> dump Physical memory: 2040 MB Dumping 38 MB: 35 31 27 23 19 15 11 7 3 Dump complete db> reboot ## root@quad:/usr/local/DEVEL/CRASH # less info.1 Dump header from device /dev/da0s1b Architecture: armv6 Architecture Version: 1 Dump Length: 40381440B (38 MB) Blocksize: 512 Dumptime: Tue Nov 18 16:46:48 2014 Hostname: quad Magic: FreeBSD Kernel Dump Version String: FreeBSD 11.0-CURRENT #0 r274634M: Tue Nov 18 00:44:36 UTC 2014 gwgpi@quad:/usr/local/DEVEL/obj/usr/local/DEVEL/SRC/head/sys/WANDBOARD-QUAD Panic String: vm_radix_insert: key 111 is already present Dump Parity: 2774862373 Bounds: 1 Dump Status: good ## root@quad:/usr/obj/usr/local/DEVEL/SRC/head/sys/WANDBOARD-QUAD # kgdb kernel.debug /usr/local/DEVEL/CRASH/vmcore.1 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "armv6-marcel-freebsd"... Cannot access memory at address 0xc26ecfc8 (kgdb) ---------- Ulrich From owner-freebsd-arm@FreeBSD.ORG Tue Nov 18 18:27:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61827F1 for ; Tue, 18 Nov 2014 18:27: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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 35951FA1 for ; Tue, 18 Nov 2014 18:27:36 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XqnUw-000FgP-Ag; Tue, 18 Nov 2014 18:27:30 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sAIIRScO006413; Tue, 18 Nov 2014 11:27:29 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18xuBF/Nkcbh2u9YT3p7mYH X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Compilation x11/libX11 fails with panic From: Ian Lepore To: Ulrich Grey In-Reply-To: <20141118191625.ec7749080739e8472405a645@ulrich-grey.de> References: <20141118191625.ec7749080739e8472405a645@ulrich-grey.de> Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Nov 2014 11:27:28 -0700 Message-ID: <1416335248.1147.57.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.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 18:27:37 -0000 On Tue, 2014-11-18 at 19:16 +0100, Ulrich Grey wrote: > I am trying to compile x11/libX11 with a Wandboard-Quad: > > FreeBSD 11.0-CURRENT #0 r274634M: Tue Nov 18 00:44:36 UTC 2014 > gwgpi@quad:/usr/local/DEVEL/obj/usr/local/DEVEL/SRC/head/sys/WANDBOARD-QUAD > arm > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > CPU: Cortex A9-r2 rev 10 (Cortex-A core) > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > > The compilation fails with this message: > > --- XKBGeom.lo > --- CC > XKBGeom.lo > --- XKBSetGeom.lo > --- CC > XKBSetGeom.lo : jemalloc_arena.c:600: Failed assertion: > "arena_mapbits_unzeroed_get(chunk, i) == unzeroed" [...] I'm curious whether the workaround mentioned recently by Jurgen Weiss also works for you, that is, setting: vm.pmap.sp_enabled=0 in loader.conf or using sysctl. It's not a fix of course, but it might help you make progress, and it would be a clue where we should start looking for trouble. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Nov 18 18:53:17 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA978796 for ; Tue, 18 Nov 2014 18:53:17 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::6]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DD6A2B1 for ; Tue, 18 Nov 2014 18:53:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416336769; l=1640; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Subject:Cc:To:From:Date; bh=0NNhn61bIIfhlzCTBgfKFmDZsoE=; b=UQq2JS18QS373ovC7zBzfnfLYdeHV62yRBtJKPqjqeAnDxz++EBdT8I5rlHsf0YF9aK Gfv5eKGCd2ITDru+lULn6Sk+3Po6uuRzueWCt1OST7jVG7/L2YOgGGphIHfUjzNSXs1hl WM9SXqv3cSVbSlp1xzTx1ZF53cMyQOPQkL4= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg48v8v5Nss= X-RZG-CLASS-ID: mo00 Received: from bbu (p54869347.dip0.t-ipconnect.de [84.134.147.71]) by smtp.strato.de (RZmta 35.12 DYNA|AUTH) with ESMTPSA id m02c17qAIIqcJBu (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate); Tue, 18 Nov 2014 19:52:38 +0100 (CET) Date: Tue, 18 Nov 2014 19:52:36 +0100 From: Ulrich Grey To: Ian Lepore Subject: Re: Compilation x11/libX11 fails with panic Message-Id: <20141118195236.418c332234f1ab951fc3d538@ulrich-grey.de> In-Reply-To: <1416335248.1147.57.camel@revolution.hippie.lan> References: <20141118191625.ec7749080739e8472405a645@ulrich-grey.de> <1416335248.1147.57.camel@revolution.hippie.lan> Organization: - X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; armv6-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 18:53:17 -0000 I had read the posting from J=FCrgen Weiss. Hence I had disabled superpages. Here are the settings during the crash: root@quad:~ # uname -a FreeBSD quad 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r274634M: Tue Nov 18 00:44:36 UTC 2014 gwgpi@quad:/usr/local/DEVEL/obj/usr/local/DEVEL/SRC/head/sys/WANDBOARD-QUAD arm=20 root@quad:~ # sysctl vm.pmap.sp_enabled vm.pmap.sp_enabled: 0 ---------------------------------- On Tue, 18 Nov 2014 11:27:28 -0700 Ian Lepore wrote: > On Tue, 2014-11-18 at 19:16 +0100, Ulrich Grey wrote: > > I am trying to compile x11/libX11 with a Wandboard-Quad: > >=20 > > FreeBSD 11.0-CURRENT #0 r274634M: Tue Nov 18 00:44:36 UTC 2014 > > gwgpi@quad:/usr/local/DEVEL/obj/usr/local/DEVEL/SRC/head/sys/WANDBO= ARD-QUAD > > arm > > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) > > 20140512 CPU: Cortex A9-r2 rev 10 (Cortex-A core) > > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 > > Security_Ext > >=20 > > The compilation fails with this message: > >=20 > > --- XKBGeom.lo > > --- CC > > XKBGeom.lo > > --- XKBSetGeom.lo > > --- CC > > XKBSetGeom.lo : jemalloc_arena.c:600: Failed assertion: > > "arena_mapbits_unzeroed_get(chunk, i) =3D=3D unzeroed" =20 > [...] >=20 > I'm curious whether the workaround mentioned recently by Jurgen Weiss > also works for you, that is, setting: >=20 > vm.pmap.sp_enabled=3D0 >=20 > in loader.conf or using sysctl. It's not a fix of course, but it > might help you make progress, and it would be a clue where we should > start looking for trouble. >=20 > -- Ian >=20 >=20 From owner-freebsd-arm@FreeBSD.ORG Tue Nov 18 19:31:58 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA3BDF23 for ; Tue, 18 Nov 2014 19:31:58 +0000 (UTC) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A13B4919 for ; Tue, 18 Nov 2014 19:31:58 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id ar1so2640838iec.7 for ; Tue, 18 Nov 2014 11:31:52 -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=QTjYCMszprhI5FkIo/zRb6fjSeCiWthYs/uLy7N3vL0=; b=fbT39tLerBsafUEgmrhZT46wYPoJQPaNuPzWXvJ6WxGv3amzK+TUrPVdJfW0DmhY3I 3wth/KX6WQ7QX3cQi+MYsUYnJnTluV9ELQrtroX0qz2D2i3BgwzC3rJRKI+hvv7qPzP/ r3nIrrORW5ykg4eYUINqkPSkm7Mi+hyYWZpG8OmK0gT3XJi7bhMhLhIdb2wbU22XqPHo zLjfHFLSlPlHqYtGKfgrgkJiJpN1nzcZrbIrnoWsVRvv7ZXxEBYPfvCTEbcK8H4fxJjX UGceolgxfgGMCcxtDpSP2ZohBGfrTrAkOCZTmU0OQmrR6IsVjTQe7dXkmSJkIc6V1Hw4 HvvQ== X-Gm-Message-State: ALoCoQlE3sDHPSThtA12Ruf7d2yRjQbdVkiS9V+mPHxSqPk+neon5cX1FCL5hNcww/QZt86BtnZn MIME-Version: 1.0 X-Received: by 10.43.128.71 with SMTP id hd7mr35838377icc.36.1416339111817; Tue, 18 Nov 2014 11:31:51 -0800 (PST) Received: by 10.107.170.2 with HTTP; Tue, 18 Nov 2014 11:31:51 -0800 (PST) In-Reply-To: References: <542271AE.6070807@andrew.cmu.edu> <2c451765bffb43e8b9dab56927bb351a@e15be-02.zdv.Uni-Mainz.DE> Date: Tue, 18 Nov 2014 14:31:51 -0500 Message-ID: Subject: Re: Jetson TK1 board support From: David Rayson To: =?UTF-8?B?V2Vpw58sIERyLiBKw7xyZ2Vu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 19:31:58 -0000 Thanks -- it works for me now! I added a driver for the RTC (although it's still not super useful without being battery-backed); I'll send patches later today. Would it make sense to set up a repository somewhere to put this in instead of just sending around patches? --David On Fri, Nov 14, 2014 at 3:58 PM, Wei=C3=9F, Dr. J=C3=BCrgen wrote: > The Ethernet works quite well. But there has been a change in a more > recent version of u-boot which did not initialize the interrupt > routing of the pcie bridge. So you do not get receive interrupts. > > I put more recent patches for the jetson tk1 board to > > http://www.staff.uni-mainz.de/weiss/jetson-tk1-20141114.tgz > > New changes to u-boot: > (diff to git://nv-tegra.nvidia.com/3rdparty/u-boot.git): > device enumeration through the u-boot API did only return the > first device of each type. > > New changes to the FreeBSD kernel: > (diff to FreeBSD current): > better initialize pcie bridge interrupt routing. > change cpu clock to 2 GHz (about 3 times faster) > SDHCI support. Tested only with non-highspeed cards. > changed cpu_reset to return to boot loader (u-boot). > > Regards > > Juergen > > Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, > weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: > +49(6131)39-26407 > > > > -----Original Message----- > > From: David Rayson [mailto:drayson@andrew.cmu.edu] > > Sent: Friday, November 14, 2014 8:29 AM > > To: Wei=C3=9F, Dr. J=C3=BCrgen > > Cc: freebsd-arm@freebsd.org > > Subject: Re: Jetson TK1 board support > > > > How well does the ethernet support work for you? When I try to use it, > packets are sent > > successfully, but no packets are received (usually). I think there > might be some sort of > > odd race condition: if I break into the debugger, let it sit for a > while, then continue, > > it will start to (very intermittently) receive a packet every now and > then (typically > > after a watchdog timeout message from the ethernet driver). Any idea > what could be going > > on there? > > > > > > --David > > > > > > On Fri, Oct 3, 2014 at 9:33 AM, Wei=C3=9F, Dr. J=C3=BCrgen > wrote: > > > > > > If you enable the sdhci controller(s) in the fdt, the controllers > and > > the cards are (at least partially) recognized. Read data transfer= s > > from the sd card slot return only data bytes with zero contents. > > The quirk in the fdt should disable DMA. The transfers are done > > in pio mode. > > > > U-boot should already have initialized the controllers. But the > > generic sdhci driver tries at least to set frequency and bus widt= h > > according to the cards present. For the EMMC it certainly does > > not know how to handle 8 bit transfers without further help > > from a tegra specific driver extensions. > > > > Juergen > > > > Juergen Weiss |Universitaet Mainz, Zentrum fuer > Datenverarbeitung, > > weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361 > > > , FAX: +49(6131)39-26407 > > > > > -----Original Message----- > > > From: David Rayson [mailto:drayson@andrew.cmu.edu] > > > Sent: Thursday, October 02, 2014 11:54 PM > > > To: Wei=C3=9F, Dr. J=C3=BCrgen > > > Cc: freebsd-arm@freebsd.org > > > Subject: Re: Jetson TK1 board support > > > > > > > > How much work do you think would be needed to get the SD > controller working? Would > > it > > > simply be a matter of doing the appropriate initialization > (wouldn't U-Boot do this > > > already even?), enabling it in the device tree, and using the > standard FreeBSD > > SDHCI > > > driver, or is there something more complicated that would need > to be done? > > > > > > > > > (This would probably be simple to test, but I don't have access > to the hardware > > right now) > > > > > > > > > --David > > > > > > > > > On Fri, Sep 26, 2014 at 4:39 PM, Wei=C3=9F, Dr. J=C3=BCrgen < > weiss@uni-mainz.de> wrote: > > > > > > > > > Hi, > > > > > > sorry, I did not have any time during the week. > > > > > > I just sent a mail to the list with a link to my changes. > > > > > > Only serial, USB2 and PCIe/Ethernet hardware is working - > so no > > > SATA. > > > > > > The drivers rely on u-boot to initialize the hardware. > While this > > > is ok for pinmux, other initializations should be done by > the > > > drivers. > > > > > > The interrupt handling for PCIe is rather ad hoc. The > interrupt > > > routing should honor the FDT description. > > > > > > The Tegra platform has a GIC with extensions for interrup= t > > > routing. I just made a copy of the GIC code end extended = it > > > in a few cases. There should probably be a mechanism to d= o > > > this without duplicating code. > > > > > > I changed some non tegra files to get FreeBSD running on > the > > > hardware. There should be better solutions, which can be > merged > > > back to the FreeBSD source tree. For example the problem > > > with cache coherency due to aggressive L2 prefetch awaits > > > a real solution. > > > > > > There is no code to change the cpu clock yet. > > > > > > There is no support for SDHCI or EMMC. > > > > > > So I would consider this a first step, which allows to do > > > native development on the platform. > > > > > > Besides that, the kernel seems to be quite stable - at > least with > > > the compiles I did. > > > > > > Regards > > > > > > Juergen > > > > > > Juergen Weiss |Universitaet Mainz, Zentrum fuer > Datenverarbeitung, > > > > > weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361 > > > > > , FAX: +49(6131)39-26407 > > 26407> > > > > > > > > > > > > -----Original Message----- > > > > From: owner-freebsd-arm@freebsd.org [mailto: > owner-freebsd-arm@freebsd.org] > > On > > > Behalf Of > > > > David Rayson > > > > Sent: Wednesday, September 24, 2014 9:25 AM > > > > To: freebsd-arm@freebsd.org > > > > Subject: Re: Jetson TK1 board support > > > > > > > > Hi, > > > > > > > > What other work would be useful to get this port workin= g > well? I might > > > > be interested in working on improving it, but first I > want to make sure > > > > I have a clear sense of what's been done so far (and ho= w > stable/not it > > > > is) and what still remains to be done. > > > > > > > > --David > > > > > > > > > Hi, > > > > > > > > > > I have a rather rough port of FreeBSD current on arm > to Jetson TK1. I > > > > > used Stephen Warren's tegra u-boot sources, which > initialize and > > configure > > > > > USB and PCIe. > > > > > > > > > > So SMP, USB and the onboard PCIe Ethernet adapter wor= k. > > > > > > > > > > After Ian's changes to busdma_machdep-v6 (r269212) I > had problems with > > > > > cache coherency with the Ethernet adapter. Seems this > is due to the > > aggressive > > > > > L2 prefetcher of Cortex A15. Disabling L2 prefetch > does help, as well as > > > > > invalidating the cache a second time after the dma > transfer. I'm not > > > > > sure what the correct solution to this problem is. I > wonder how > > > > > other Cortex A15 platforms (exynos5) handle this. > > > > > > > > > > I will probably be able to do some cleanups and put > patches on the web > > > > > within a week. > > > > > > > > > > Regards > > > > > > > > > > Juergen > > > > > > > > > > Juergen Weiss |Universitaet Mainz, Zentrum fuer > Datenverarbeitung, > > > > > weiss at uni-mainz.de > > > > > |55099 > > > > > > Mainz, Tel: +49(6131)39-26361 > > > , FAX: +49(6131)39 > - > > > 26407 > > > > > > > > > > > > >/ -----Original Message----- > > > > > />/ From:owner-freebsd-arm at freebsd.org > > > > > [mailto:owner- > > freebsd-arm > > > at > > > > freebsd.org < > http://lists.freebsd.org/mailman/listinfo/freebsd-arm>] On > > Behalf Of > > > > > />/ Ian Lepore > > > > > />/ Sent: Sunday, September 21, 2014 3:44 PM > > > > > />/ To: Lundberg, Johannes > > > > > />/ Cc:freebsd-arm at freebsd.org > > > > > > arm> > > > > > />/ Subject: Re: Jetson TK1 board support > > > > > />/ > > > > > />/ On Sun, 2014-09-21 at 16:45 +0900, Lundberg, > Johannes wrote: > > > > > />/ > Great! > > > > > />/ > > > > > > />/ > What I've done so far is > > > > > />/ > > > > > > />/ > - build and patch (enable API) u-boot-nvidia o= n > freebsd (i think i > > got it > > > > > />/ > fromgit:// > nv-tegra.nvidia.com/3rdparty/u-boot.git, the normal u- > > boot > > > > > />/ > wouldn't work...) > > > > > />/ > - flash u-boot-dtb-tegra.img onto the board's > mmc using nvidia's > > flash > > > tool > > > > > />/ > on ubuntu > > > > > />/ > - build an image using crochet and dd to sd > card (so far I copied > > the > > > > > />/ > beaglebone setup, just to get a ubldr and a > kernel file) > > > > > />/ > > > > > > />/ > > > > > > />/ > From u-boot I can see all devices. I load ubld= r > with > > > > > />/ > fatload mmc 1:1 0x80200000 ubldr > > > > > />/ > bootelf 0x80200000 > > > > > />/ > > > > > > />/ > ubldr load fine but, from ubldr I can only see > the mmc 0 and net > > devices. > > > > > />/ > There's no sd card (mmc 1), and no ufs > partition.. > > > > > />/ > > > > > > />/ > > > > > > />/ > > > > > > />/ > > > > > > />/ > -- > > > > > />/ > Johannes Lundberg > > > > > />/ > BRILLIANTSERVICE CO., LTD. > > > > > />/ > > > > > > />/ > On Fri, Sep 19, 2014 at 8:25 PM, John Howie > > > > = > > wrote: > > > > > />/ > > > > > > />/ > > Hi all, > > > > > />/ > > > > > > > />/ > > I am up for testing and supporting this > board. I ordered and > > received > > > > > />/ > > mine, but have not really had a chance to us= e > it due to work to- > > date. > > > The > > > > > />/ > > good news is the next few months I will have > bandwidth. > > > > > />/ > > > > > > > />/ > > Regards, > > > > > />/ > > > > > > > />/ > > John > > > > > />/ > > > > > > > />/ > > > > > > > />/ > > On 9/19/14, 12:15 PM, "Lundberg, Johannes" > > > > > />/ > > > > > = > > wrote: > > > > > />/ > > > > > > > />/ > > >Hi > > > > > />/ > > > > > > > > />/ > > >I started working on adding the Jetson TK1 > board to Crochet. Is > > there > > > any > > > > > />/ > > >work in progress on this? > > > > > />/ > > >I guess there is quite a lot of work that > has to been done to > > get full > > > > > />/ > > >support for it in the kernel as well.. > > > > > />/ > > > > > > > > />/ > > >Best regards > > > > > />/ > > >-- > > > > > />/ > > >Johannes Lundberg > > > > > />/ > > > > > > > > />/ > > > > > />/ You may have to change some u-boot options to > support multiple > > mmc/sd > > > > > />/ interfaces. Look in the config header for > > CONFIG_SYS_MMC_MAX_DEVICE; if > > > > > />/ it's not there you may need to add it. For > wandboard I also had to > > add > > > > > />/ a freescale-specific one, > CONFIG_SYS_FSL_USDHC_NUM, so there may be > > > > > />/ something like that you need to find as well. > > > > > />/ > > > > > />/ -- Ian > > > > > />/ > > > > > />/ > > > > > />/ _______________________________________________ > > > > > />/ freebsd-arm at freebsd.org > > > > > > > mailing list > > > > > />/ > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > > > > />/ To unsubscribe, send any mail to > "freebsd-arm-unsubscribe at > > freebsd.org > > > > >"/ > > > > _______________________________________________ > > > > 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 Tue Nov 18 19:55:42 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A021635F for ; Tue, 18 Nov 2014 19:55:42 +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)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 51122B20 for ; Tue, 18 Nov 2014 19:55:41 +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 sAIJteU7064723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2014 11:55:40 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAIJte9J064722; Tue, 18 Nov 2014 11:55:40 -0800 (PST) (envelope-from jmg) Date: Tue, 18 Nov 2014 11:55:40 -0800 From: John-Mark Gurney To: Black Fox Subject: Re: 3D accelerated support under BeagleBone Black Message-ID: <20141118195540.GC24601@funkthat.com> Mail-Followup-To: Black Fox , freebsd-arm@freebsd.org References: <20141118061301.GY24601@funkthat.com> 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 IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 18 Nov 2014 11:55:40 -0800 (PST) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 19:55:42 -0000 Black Fox wrote this message on Tue, Nov 18, 2014 at 01:15 -0500: > On 18 Nov 2014 01:13, "John-Mark Gurney" wrote: > > > > Black Fox wrote this message on Tue, Nov 18, 2014 at 00:42 -0500: > > > I have a BeagleBone Black here and I have an LCD I hooked up to it to > get > > > graphics. I was wondering whether the DVI header is working, because I'd > > > love to get this onto a bigger screen. > > > > Sadly, the docs for the HDMI framer chip requires an NDA... Once I > > get a copy of the programming docs, I plan to get things working... > Ah yes company NDAs are pretty awful to deal with. So I guess this applies > for the DVI header/cape as well? > > Good luck and keep us updated on progress The DVI-D cape uses a different framer than the BBB... It uses the TFP410 from TI, and a basic register description list[1] is freely available for it.. I'm not sure if that is enough to write a driver for it though, but it looks like it may be... There is a differences between the two chips, as the TI chip does only video, and only supports an older version of the DVI spec, while the NXP on board chip supports audio, and other advanced features of HDMI... The LCD driver side is supposedly already written for the BBB, the only thing necessary is the framer driver... As the DVI-D cape uses the LCD driver, if you were to write a driver to activate the TFP410, it should "just work" assuming that the existing LCD driver works.. [1] http://www.ti.com/lit/ds/symlink/tfp410.pdf -- 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 Wed Nov 19 04:31:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B43C5C32 for ; Wed, 19 Nov 2014 04:31:18 +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)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 445D2825 for ; Wed, 19 Nov 2014 04:31:17 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id sAJ4J1Ah094740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Nov 2014 05:19:02 +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 sAJ4IuFL066488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Nov 2014 05:18:56 +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 sAJ4Iu9m099907; Wed, 19 Nov 2014 05:18:56 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id sAJ4Iu3U099906; Wed, 19 Nov 2014 05:18:56 +0100 (CET) (envelope-from ticso) Date: Wed, 19 Nov 2014 05:18:54 +0100 From: Bernd Walter To: =?iso-8859-1?B?V2Vp3ywgIERyLiBK/HJnZW4=?= Subject: Re: buildworld selfbuild failure Message-ID: <20141119041854.GA99887@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20140910111616.GA31990@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: "freebsd-arm@freebsd.org" , "'ticso@cicely.de'" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 04:31:18 -0000 On Mon, Nov 17, 2014 at 09:53:27PM +0000, Weiß, Dr. Jürgen wrote: > Same problem with freebsd current of 2 days ago on a Jetson TK1. > > After unmounting /usr/src and /usr/obj and mounting again, compilation without -j x > succeeds. > > Without unmounting /usr/src and /usr/obj calling cc directly from the shell gives the > same error. > > > using ktrace gives > > 59705 cc CALL open(0x22019050,0,0xa5a50063) > 59705 cc NAMI "/usr/src/kerberos5/lib/libheimsqlite/../../../crypto/heimdal/lib/sqlite/sqlite3.c" > 59705 cc RET open 4 > 59705 cc CALL fstat(0x4,0xbfffe450) > 59705 cc STRU struct stat {dev=973143810, ino=32026, mode=0100644, nlink=1, uid=0, gid=0, rdev=20792, atime=1416131826.751760829, stime=1403290613, ctime=1413735753.593422297, birthtim > e=-1, size=4623536, blksize=4096, blocks=9225, flags=0x0 } > 59705 cc RET fstat 0 > 59705 cc CALL fstat(0x4,0xbfffe220) > 59705 cc STRU struct stat {dev=973143810, ino=32026, mode=0100644, nlink=1, uid=0, gid=0, rdev=20792, atime=1416131826.751760829, stime=1403290613, ctime=1413735753.593422297, birthtim > e=-1, size=4623536, blksize=4096, blocks=9225, flags=0x0 } > 59705 cc RET fstat 0 > 59705 cc CALL mmap(0,0x468cb0,0x1,0x2,0x4,0xbfffe580,0,0) > 59705 cc RET mmap 574619648/0x22400000 > 59705 cc CALL close(0x4) > 59705 cc RET close 0 > 59705 cc PSIG SIGBUS caught handler=0x152de90 mask=0x0 code=SI_NOINFO > > > After disabling superpages by > > vm.pmap.sp_enabled=0 Interesting - that's something I will try out. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Wed Nov 19 12:53: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A23F6668 for ; Wed, 19 Nov 2014 12:53:48 +0000 (UTC) Received: from mail.issei-syoji.co.jp (mail.issei-syoji.co.jp [203.143.100.227]) by mx1.freebsd.org (Postfix) with ESMTP id 3A4CD165 for ; Wed, 19 Nov 2014 12:53:47 +0000 (UTC) Received: from SRVPEETERS (unknown [91.183.125.209]) by mail.issei-syoji.co.jp (Postfix) with ESMTP id 4FC09308781 for ; Wed, 19 Nov 2014 21:53:44 +0900 (JST) From: "Charles Benneth" Subject: Re: Product Inquiry To: freebsd-arm@freebsd.org MIME-Version: 1.0 Reply-To: elliota234@live.co.uk Date: Wed, 19 Nov 2014 13:53:54 +0100 Message-Id: <20141119125345.4FC09308781@mail.issei-syoji.co.jp> Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 12:53:48 -0000 - This mail is in HTML. Some elements may be ommited in plain text. - Good day, My Name is Mr Charles Bennett the Sales Manager off tong heer thiala= nd co LTD I Am Interested in some of your product could you kindly sen= d me your full catalog of products with clear photos, and list of FOB = prices in USD with prices,competitive prices for serious starting. Wai= ting your quick response. Best Regards TONG HEER ( EXPORT ) CO. LTD. Amata Nakorn Industrial Estate 700/553, Moo 7, T.Don Hua Roh, A.Maung,= Chonburi, 20000, Thailand Tel :+66 38 454 537-9 Fax :+66 38 454 327 From owner-freebsd-arm@FreeBSD.ORG Wed Nov 19 13:01:04 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1135C7F for ; Wed, 19 Nov 2014 13:01:04 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 77D9F2C9 for ; Wed, 19 Nov 2014 13:01:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416402041; l=7360; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Subject:Cc:To:From:Date; bh=BpDEI+L5uIy4LvK2P5Lyf8rWaeI=; b=Q5sxVH91xBRm2Q0Q//nktstKkqfGb2g1EvRTAdXua0rIHxAqMDn3NsWS02BzVoeJbEN fZqnL6vIK9aOIAKxYbbx91fqV9o6kCTljwj5v4DC9pFFaQFu014pfkuPas9o+csFNFXGi 1MsZy2lYg6Q4icG6YixElIulqPBWyDOEq40= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg47vsv/RkV1 X-RZG-CLASS-ID: mo00 Received: from bbu (p54868898.dip0.t-ipconnect.de [84.134.136.152]) by smtp.strato.de (RZmta 35.12 DYNA|AUTH) with ESMTPSA id t06f42qAJD0YVDG (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate); Wed, 19 Nov 2014 14:00:34 +0100 (CET) Date: Wed, 19 Nov 2014 14:00:31 +0100 From: Ulrich Grey To: Ian Lepore Subject: Re: Compilation x11/libX11 fails with panic Message-Id: <20141119140031.7091bd891fee6b0e163e956f@ulrich-grey.de> In-Reply-To: <1416335248.1147.57.camel@revolution.hippie.lan> References: <20141118191625.ec7749080739e8472405a645@ulrich-grey.de> <1416335248.1147.57.camel@revolution.hippie.lan> Organization: - X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; armv6-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 13:01:05 -0000 After the last crash the system compiled editors/texworks without problems (uptime ca. 18 hours) with superpages disabled: root@quad:/usr/home/gwgpi # sysctl vm.pmap. vm.pmap.sp_enabled: 0 vm.pmap.pv_entry_count: 10917 vm.pmap.pv_entry_max: 1744848 vm.pmap.shpgperproc: 200 vm.pmap.section.demotions: 0 vm.pmap.section.mappings: 0 vm.pmap.section.p_failures: 0 vm.pmap.section.promotions: 0 root@quad:/usr/home/gwgpi #=20 In the following I have done: make -j10 buildworld in /usr/src The system crashes after ca. 1 hour. I tryed to get a coredump, but that did not work: vm_fault(0xc75dc4f0, 0, 1, 0) -> 0 Fatal kernel mode data abort: 'Translation Fault (P)' trapframe: 0xfb289cb0 FSR=3D00000017, FAR=3D00000008, spsr=3D200000d3 r0 =3D00000000, r1 =3D00000001, r2 =3D000000ac, r3 =3D000000ac r4 =3Dfb289d94, r5 =3D00000000, r6 =3D00000000, r7 =3D00000014 r8 =3D000006c0, r9 =3Dc25ab8c0, r10=3D0000 0 0v0m0_,f aru1l1t=3D(f0bx2c8295db8906 5 8r,1 20=3D,c 215,b 90b)5 0-,> s0s p =3DFfabt2a8l9 dk0e0r,n esll rm=3Docd2e4 6dda1tfac ,a bpocr t=3D:c 2'1T6r1afnes0l a t i on Fault (P)' trapframe: 0xf4920d40 FSR=3D00000017, FAR=3D00000000, spsr=3D600001d3 r0 =3D00000000, r1 =3D00000001, r2 =3Dc6f64680, r3 =3Dc25ab8d0 r4 =3D00000000, r5 =3Dc6f64680, r6 =3D0000000b, r7 =3D00000000 r8 =3Dc25ba41c, r9 =3Dc6f64680, r10=3Dc6f64990, r11=3Df4920de0 r12=3D00000001, ssp=3Df4920d94, slr=3Dc21d09ac, pc =3Dc2187f84 timeout stopping cpus [ thread pid 87965 tid 100174 ] Stopped at $a+0x148: ldr r1, [r0, #0x008] db> timeout stopping cpus [ thread pid 11 tid 100007 ] Stopped at thread_lock_block+0xc: ldr r1, [r0] db> d db> qum =08No such command db> p =08c2187f84 db> u =08Ambiguous db> dputm =08No such command db> p[A=08 =08 =08 =20 =08c2187f84 db>=20 c2187f84 db> [=08A [=08=08=08 =08[=08A [=08=08=08 =08[A =08Bad character ? db>=20 c218c72f8148 7 f8d4b > db> q =08No such command db> cpasl la udxo =08No such command db> adduummpp =08No such command db>=20 d =08Not set. db> duummpp =08No such command db>=20 Not set. db> d=08d =08=08u=08u =08=08m =08 vm_fault(0xc25b9658, 0, 1, 0) -> 0 Fatal kernel mode data abort: 'Translation Fault (P)' trapframe: 0xf4920d40 FSR=3D00000017, FAR=3D00000000, spsr=3D600001d3 r0 =3D00000000, r1 =3D00000001, r2 =3Dc6f64680, r3 =3Dc25ab8d0 r4 =3D00000000, r5 =3Dc6f64680, r6 =3D0000000b, r7 =3D00000000 r8 =3Dc25ba41c, r9 =3Dc6f64680, r10=3Dc6f64990, r11=3Df4920de0 r12=3D00000001, ssp=3Df4920d94, slr=3Dc21d09ac, pc =3Dc2187f84 panic: Fatal abort cpuid =3D 0 KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc246968c lr =3D 0xc20435f0 (db_trace_self_wrapper+0x30) sp =3D 0xf4920b00 fp =3D 0xf4920c18 r10 =3D 0xc6f64680 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435f0 lr =3D 0xc21e3d14 (kdb_backtrace+0x38) sp =3D 0xf4920c20 fp =3D 0xf4920c28 r4 =3D 0xc25ad634 r5 =3D 0xc24e1e8a r6 =3D 0x00000001 r7 =3D 0xc259e310 kdb_backtrace() at kdb_backtrace+0x38 pc =3D 0xc21e3d14 lr =3D 0xc219f68c (panic+0x124) sp =3D 0xf4920c30 fp =3D 0xf4920c50 r4 =3D 0x00000100 panic() at panic+0x124 pc =3D 0xc219f68c lr =3D 0xc24814e0 ($d) sp =3D 0xf4920c68 fp =3D 0xf4920c80 r4 =3D 0xf4920d40 r5 =3D 0x00000017 r6 =3D 0x600001d3 r7 =3D 0x00000000 r8 =3D 0xf4920d40 r9 =3D 0x00000017 r10 =3D 0x00000000 $d() at $d pc =3D 0xc24814e0 lr =3D 0xc248127c (data_abort_handler+0x560) sp =3D 0xf4920c88 fp =3D 0xf4920d38 r4 =3D 0x00000013 r5 =3D 0xc6f64680 r6 =3D 0xf4920eb0 r7 =3D 0x00000000 data_abort_handler() at data_abort_handler+0x560 pc =3D 0xc248127c lr =3D 0xc246b44c (exception_exit) sp =3D 0xf4920d40 fp =3D 0xf4920de0 r4 =3D 0x00000000 r5 =3D 0xc6f64680 r6 =3D 0x0000000b r7 =3D 0x00000000 r8 =3D 0xc25ba41c r9 =3D 0xc6f64680 r10 =3D 0xc6f64990 exception_exit() at exception_exit pc =3D 0xc246b44c lr =3D 0xc21d09ac (sched_switch+0x3fc) sp =3D 0xf4920d94 fp =3D 0xf4920de0 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0xc6f64680 r3 =3D 0xc25ab8d0 r4 =3D 0x00000000 r5 =3D 0xc6f64680 r6 =3D 0x0000000b r7 =3D 0x00000000 r8 =3D 0xc25ba41c r9 =3D 0xc6f64680 r10 =3D 0xc6f64990 r12 =3D 0x00000001 thread_lock_block() at thread_lock_block+0xc pc =3D 0xc2187f84 lr =3D 0xc21aa4b4 (mi_switch+0x12c) sp =3D 0xf4920de8 fp =3D 0xf4920e00 r4 =3D 0x00000000 mi_switch() at mi_switch+0x12c pc =3D 0xc21aa4b4 lr =3D 0xc21662a4 (ithread_loop+0x18c) sp =3D 0xf4920e08 fp =3D 0xf4920e38 r4 =3D 0xc6e19eb0 r5 =3D 0xc6f64680 r6 =3D 0xc6e39900 r7 =3D 0xc6e39970 r8 =3D 0xc256aaf0 r9 =3D 0x00000000 ithread_loop() at ithread_loop+0x18c pc =3D 0xc21662a4 lr =3D 0xc216245c (fork_exit+0xa4) sp =3D 0xf4920e40 fp =3D 0xf4920e58 r4 =3D 0xc6f64680 r5 =3D 0xc6f62000 r6 =3D 0xc2166118 r7 =3D 0xc6e19eb0 r8 =3D 0xf4920e60 r9 =3D 0x00000000 r10 =3D 0x00000000 fork_exit() at fork_exit+0xa4 pc =3D 0xc216245c lr =3D 0xc246b3dc (swi_exit) sp =3D 0xf4920e60 fp =3D 0x00000000 r4 =3D 0xc2166118 r5 =3D 0xc6e19eb0 r6 =3D 0x00000000 r7 =3D 0x00000000 r8 =3D 0x00000000 swi_exit() at swi_exit pc =3D 0xc246b3dc lr =3D 0xc246b3dc (swi_exit) sp =3D 0xf4920e60 fp =3D 0x00000000 Uptime: 19h16m19s panicA:ft eUnr de42f iniends triunscttiruocnsti o(n0 ilnoa kdser,n e0l s.t o r ecsp)u, i d [ =3D t1h r eUadpt ipmied: 1 11 9thi16dm 1190s0 0 07 ] Stopped at thread_lock_block+0x4c: ldmea r13!, {r4, r11, r15} db> p c2187fc4 db>=20 c2187fc4 db> panic panic: from debugger cpuid =3D 0 KDB: enter: panic After 42 instructions (0 loads, 0 stores), [ thread pid 11 tid 100007 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! db> dump Physical memory: 2040 MB Dumping 145 MB: ---------------------------------------------------------------- On Tue, 18 Nov 2014 11:27:28 -0700 Ian Lepore wrote: > On Tue, 2014-11-18 at 19:16 +0100, Ulrich Grey wrote: > > I am trying to compile x11/libX11 with a Wandboard-Quad: > >=20 > > FreeBSD 11.0-CURRENT #0 r274634M: Tue Nov 18 00:44:36 UTC 2014 > > gwgpi@quad:/usr/local/DEVEL/obj/usr/local/DEVEL/SRC/head/sys/WANDBO= ARD-QUAD > > arm > > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) > > 20140512 CPU: Cortex A9-r2 rev 10 (Cortex-A core) > > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 > > Security_Ext > >=20 > > The compilation fails with this message: > >=20 > > --- XKBGeom.lo > > --- CC > > XKBGeom.lo > > --- XKBSetGeom.lo > > --- CC > > XKBSetGeom.lo : jemalloc_arena.c:600: Failed assertion: > > "arena_mapbits_unzeroed_get(chunk, i) =3D=3D unzeroed" =20 > [...] >=20 > I'm curious whether the workaround mentioned recently by Jurgen Weiss > also works for you, that is, setting: >=20 > vm.pmap.sp_enabled=3D0 >=20 > in loader.conf or using sysctl. It's not a fix of course, but it > might help you make progress, and it would be a clue where we should > start looking for trouble. >=20 > -- Ian >=20 >=20 From owner-freebsd-arm@FreeBSD.ORG Wed Nov 19 13:26:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4217E4D8 for ; Wed, 19 Nov 2014 13:26:18 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A55C6782 for ; Wed, 19 Nov 2014 13:26:17 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id mc6so489692lab.10 for ; Wed, 19 Nov 2014 05:26:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=amqvuhjQWv5EfxQrc2D8hOCvVIxPd9rNDkX6x8LE41c=; b=oqInNYbtyCo+uR74neBaPdQXrEgzy55DNh+WgKXUEMsby1f0r59G2MoBrRuU1/XQ/B OlhFYoOA9D5UHofbmM7eNv7vqjdZPpzczte28mTg8pS6penhYl8vb/DaYhWrgoP8yKEn VdUxO5epyGhhWkdIqn+fPv/2dE7RbZRT3rH5fu4PpNW9chFvNocoX4zLO0cQ6O8n4Sxq 1yRtF+gytJozlGSkICiMcG/mM7QGBhX1TgOjSjyb16Rjea1r2mEL7GGmtz7an63+pgOD 2Sn4zhMZAgAXTJr4QfXVMd+EV3fdOQzy2zPfTcc59hGPweMSfP8y2pBxFkKQgd2uNYKN +bZA== MIME-Version: 1.0 X-Received: by 10.112.170.99 with SMTP id al3mr42848720lbc.17.1416403575616; Wed, 19 Nov 2014 05:26:15 -0800 (PST) Received: by 10.25.126.216 with HTTP; Wed, 19 Nov 2014 05:26:15 -0800 (PST) In-Reply-To: <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> Date: Wed, 19 Nov 2014 14:26:15 +0100 Message-ID: Subject: Re: Wandboard-Quad crashes From: Svatopluk Kraus To: Ulrich Grey Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arm@freebsd.org, Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 13:26:18 -0000 If you want to give it a try, you can find my and Michal new arm-v6 stuff here: https://github.com/strejda/freebsd ARM_NEW_PMAP option must be defined to build our stuff. Regards, Svatopluk Kraus On Sat, Nov 15, 2014 at 2:34 PM, Ulrich Grey wrote: > On Thu, 13 Nov 2014 08:37:13 -0800 > Rui Paulo wrote: > > > On Nov 13, 2014, at 03:52, Ulrich Grey wrote: > > > > > > I am running FreeBSD on a Wandboard-Quad: > > > > > > FreeBSD 11.0-CURRENT #0 r274420M: Wed Nov 12 14:17:26 UTC 2014 > > > user@quad > :/usr/local/DEVEL/obj/usr/local/DEVEL/SRC/head/sys/WANDBOARD-QUAD > > > arm FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) > > > 20140512 WARNING: WITNESS option enabled, expect reduced > > > performance. CPU: Cortex A9-r2 rev 10 (Cortex-A core) > > > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 > > > Security_Ext > > > > > > If I try to compile x11/libX11 the system frequently crashes: > > > > > > Fatal kernel mode data abort: 'Alignment Fault 1' > > > trapframe: 0xf72e0ae8 > > > FSR=00000001, FAR=000000a7, spsr=60000013 > > > r0 =00000004, r1 =00000000, r2 =c242b953, r3 =00000970 > > > r4 =c847fd80, r5 =c242b953, r6 =000000a7, r7 =c7df6810 > > > r8 =00000000, r9 =00000097, r10=00000970, r11=f72e0b68 > > > r12=000000c0, ssp=f72e0b38, slr=c220ebf4, pc =c214fbb4 > > > > > > [ thread pid 23015 tid 100147 ] > > > > > > Stopped at __mtx_lock_flags+0x50: ldr r0, [r6] > > > > > > What can I do? > > > > Can you send us the backtrace? > > > > Here are the contents of the info files of the last two crashes: > > root@quad:/var/crash # less info.0 > Dump header from device /dev/da0s1b > Architecture: armv6 > Architecture Version: 1 > Dump Length: 64605184B (61 MB) > Blocksize: 512 > Dumptime: Fri Nov 14 15:52:43 2014 > Hostname: quad > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 11.0-CURRENT #1 r274420M: Fri Nov 14 12:57:30 > UTC 2014 > gwgpi@quad > :/usr/local/DEVEL/obj/usr/local/DEVEL/SRC/head/sys/WANDBOARD-QUAD > Panic String: vm_fault: fault on nofault entry, addr: c74c5000 Dump > Parity: 1136560497 Bounds: 0 > Dump Status: good > > Dump header from device /dev/da0s1b > Architecture: armv6 > Architecture Version: 1 > Dump Length: 46439424B (44 MB) > Blocksize: 512 > Dumptime: Sat Nov 15 10:38:33 2014 > Hostname: quad > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 11.0-CURRENT #1 r274420M: Fri Nov 14 12:57:30 > UTC 2014 > gwgpi@quad > :/usr/local/DEVEL/obj/usr/local/DEVEL/SRC/head/sys/WANDBOARD-QUAD > Panic String: Trying to access non-existent page va e6000 pte bfffeff2 > Dump Parity: 1943179849 Bounds: 1 > Dump Status: good > > I am not able to get a backtrace: > > root@quad:/usr/obj/usr/local/DEVEL/SRC/head/sys/WANDBOARD-QUAD # kgdb > kernel.debug GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are welcome to change it and/or distribute copies of it under > certain conditions. Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. This GDB was configured as "armv6-marcel-freebsd"...Dwarf > Error: Could not find abbrev number 114 [in > module > /usr/local/DEVEL/obj/usr/local/DEVEL/SRC/head/sys/WANDBOARD-QUAD/kernel.debug] > No struct type named linker_file. No struct type named linker_file. No > struct type named linker_file. No symbol "linker_path" in current > context. No symbol "linker_files" in current context. > > (kgdb) file kernel.symbols > Reading symbols from kernel.symbols...Dwarf Error: Could not find > abbrev number 114 [in > module > /usr/local/DEVEL/obj/usr/local/DEVEL/SRC/head/sys/WANDBOARD-QUAD/kernel.symbols] > No struct type named linker_file. No struct type named linker_file. No > struct type named linker_file. No symbol "linker_path" in current > context. No symbol "linker_files" in current context. > (kgdb) > > ----- > Ulrich > _______________________________________________ > 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 Wed Nov 19 17:06:31 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B5645FD for ; Wed, 19 Nov 2014 17:06:31 +0000 (UTC) Received: from mail.FoxValley.net (mail.FoxValley.net [64.135.192.34]) by mx1.freebsd.org (Postfix) with SMTP id E136F382 for ; Wed, 19 Nov 2014 17:06:30 +0000 (UTC) Received: (qmail 9238 invoked from network) for freebsd-arm@freebsd.org; 19 Nov 2014 11:06:24 -0600 Received: from marengo.foxvalley.net (draymond@64.135.192.25) by mail.foxvalley.net with SMTP; 19 Nov 2014 11:06:24 -0600 Received: from sp5.qualcomm.com (sp5.qualcomm.com [199.106.103.55]) by webmail.FoxValley.net (Horde MIME library) with HTTP; Wed, 19 Nov 2014 11:06:24 -0600 Message-ID: <20141119110624.95dbkcz1y98o0gws@webmail.FoxValley.net> Date: Wed, 19 Nov 2014 11:06:24 -0600 From: draymond@FoxValley.net To: freebsd-arm@freebsd.org Subject: dovecot panic MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 17:06:31 -0000 I tried compiling the port of dovecot (/usr/ports/mail/dovecot) on my Raspberry Pi. Getting it running was more work than most other ports: vi /usr/local/etc/dovecot.conf protocols = imap pop3 imaps pop3s cd /usr/local/share/examples/dovecot vi dovecot-openssl.cnf (fill out fields) mkdir /etc/ssl/certs mkdir /etc/ssl/private ./mkcert.sh echo 'dovecot_enable="YES"' >> /etc/rc.conf /usr/local/etc/rc.d/dovecot start While I was testing it (manual telnet into port 110 and checking mail) dovecot panicked and brought down the system. I rebooted and tried again and got the same result: panic: pmap_zero_page_gen: page has mappings KDB: enter: panic [ thread pid 13779 tid 100095 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! db> Has anyone else had success with dovecot on ARMv6? Is there a more stable choice for a basic POP3/IMAP daemon? From owner-freebsd-arm@FreeBSD.ORG Wed Nov 19 17:40:24 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10DF1EB7 for ; Wed, 19 Nov 2014 17:40:24 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C70649C1 for ; Wed, 19 Nov 2014 17:40:23 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Xr9Ee-0002P8-UJ for freebsd-arm@freebsd.org; Wed, 19 Nov 2014 18:40:15 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: dovecot panic References: <20141119110624.95dbkcz1y98o0gws@webmail.FoxValley.net> Date: Wed, 19 Nov 2014 18:40:07 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <20141119110624.95dbkcz1y98o0gws@webmail.FoxValley.net> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: -- X-Spam-Score: -2.9 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=disabled version=3.3.1 X-Scan-Signature: c09395f469c52153b963e4ff2d10f427 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 17:40:24 -0000 On Wed, 19 Nov 2014 18:06:24 +0100, wrote: > I tried compiling the port of dovecot (/usr/ports/mail/dovecot) on my > Raspberry Pi. Getting it running was more work than most other ports: > > vi /usr/local/etc/dovecot.conf > > protocols = imap pop3 imaps pop3s > > cd /usr/local/share/examples/dovecot > vi dovecot-openssl.cnf > > (fill out fields) > > mkdir /etc/ssl/certs > mkdir /etc/ssl/private > ./mkcert.sh > echo 'dovecot_enable="YES"' >> /etc/rc.conf > /usr/local/etc/rc.d/dovecot start > > While I was testing it (manual telnet into port 110 and checking mail) > dovecot panicked and brought down the system. I rebooted and tried > again and got the same result: > > panic: pmap_zero_page_gen: page has mappings > KDB: enter: panic > [ thread pid 13779 tid 100095 ] > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > db> > > Has anyone else had success with dovecot on ARMv6? Is there a more > stable choice for a basic POP3/IMAP daemon? > Funny coincidence. I just compiled dovecot2 on my ARM Sheevaplug system. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195168 But, your panic should not have to do with dovecot. Applications are not supposed to make the kernel panic. It normally is the kernel itself which makes it panic. Does disabling superpages help? Put vm.pmap.sp_enabled=0 in loader.conf or sysctl.conf. Other people mentioned a problem with that the previous days. NB: what version of FreeBSD are you running? Regards, Ronald. From owner-freebsd-arm@FreeBSD.ORG Wed Nov 19 18:35: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17339684 for ; Wed, 19 Nov 2014 18:35:16 +0000 (UTC) Received: from mail.FoxValley.net (mail.FoxValley.net [64.135.192.34]) by mx1.freebsd.org (Postfix) with SMTP id BCD89F54 for ; Wed, 19 Nov 2014 18:35:15 +0000 (UTC) Received: (qmail 6463 invoked from network) for freebsd-arm@freebsd.org; 19 Nov 2014 12:35:14 -0600 Received: from marengo.foxvalley.net (draymond@64.135.192.25) by mail.foxvalley.net with SMTP; 19 Nov 2014 12:35:14 -0600 Received: from sp5.qualcomm.com (sp5.qualcomm.com [199.106.103.55]) by webmail.FoxValley.net (Horde MIME library) with HTTP; Wed, 19 Nov 2014 12:35:14 -0600 Message-ID: <20141119123514.rxv2b9ogorkg8kgo@webmail.FoxValley.net> Date: Wed, 19 Nov 2014 12:35:14 -0600 From: draymond@FoxValley.net To: freebsd-arm@freebsd.org Subject: re: re: dovecot panic MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 18:35:16 -0000 Hi, Ronald. My build version is r274416. I don't know if dovecot is directly causing the panic but it seems to be related. I have been using this build heavily for about a week now (including lots of compiling) and haven't had any panics. I installed dovecot and got two in a row, both during a telnet session to port 110 (talking to dovecot). The first time I got as far as (USER xxx, PASS xxx, LIST). The second time I got as far as (USER xxx, PASS xxx, LIST, RETR 1, RETR 2, QUIT). I'll try "vm.pmap.sp_enabled=0" this evening. Have you tested dovecot2 very much? What did you have to do to get it to load successfully? There were a few configuration changes required for dovecot before it would start. From owner-freebsd-arm@FreeBSD.ORG Wed Nov 19 21:59:32 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B11B627D for ; Wed, 19 Nov 2014 21:59:32 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E1B18C15 for ; Wed, 19 Nov 2014 21:59:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416434346; l=85833; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Subject:Cc:To:From:Date; bh=KD0h0d2DB1e9cwTwsqpK2OTPEF4=; b=MrKZVTILceykWzIWhZ5CP0yceOhoMnY7g7/n3LKa5Jy+9F4F7OjdIpw5RqiioP58Qxt HDQdQJ0wma5D8wV4utrUgiP0NTAW4kAezbzb7cms0fQEhsjUfXGnbT1ZMrDLOLvtns4LY 9FwQ1SmaQrRLxVbthkegJqXarZKuE9efB/4= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg47vsv/RkV1 X-RZG-CLASS-ID: mo00 Received: from bbu (p54868898.dip0.t-ipconnect.de [84.134.136.152]) by smtp.strato.de (RZmta 35.12 DYNA|AUTH) with ESMTPSA id f032e5qAJLx4am2 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate); Wed, 19 Nov 2014 22:59:04 +0100 (CET) Date: Wed, 19 Nov 2014 22:59:03 +0100 From: Ulrich Grey To: Svatopluk Kraus Subject: Re: Wandboard-Quad crashes Message-Id: <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> In-Reply-To: References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> Organization: - X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; armv6-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@freebsd.org, Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 21:59:32 -0000 Thank you for the offer, I have tried it. After I had cloned your repository I have added 2 lines to src/sys/arm/conf/IMX6: makeoptions WITHOUT_MODULES=3D"ispfw" # compile error makeoptions ARM_NEW_PMAP=3D"yes" # is that ok ? I have enabled superpages: root@quad:~ # sysctl vm.pmap. vm.pmap.sp_enabled: 1 vm.pmap.pv_entry_count: 152311 vm.pmap.pv_entry_max: 1744848 vm.pmap.shpgperproc: 200 vm.pmap.section.demotions: 5790 vm.pmap.section.mappings: 0 vm.pmap.section.p_failures: 2623 vm.pmap.section.promotions: 42642 This is the running kernel: root@quad:~ # uname -a FreeBSD quad 11.0-CURRENT FreeBSD 11.0-CURRENT #0 751adfd (master)-dirty: Wed Nov 19 17:15:31 UTC 2014 gwgpi@quad:/usr/local/DEVEL/obj/usr/local/DEVEL/STREJDA/freebsd/sys/WANDBOA= RD-QUAD arm The userland is on revision: r274634M Then I did: make -j 10 buildworld in /usr/src After ca. 3 1/2 hours I got a crash: ############## root@quad:~ # Fatal kernel mode data abort: 'Alignment FauFlatt'a lo nk errenaedl=20 mtordaep fdraatmae :a b0oxrftb:2 3'eA9lbi0g nFmSeRn=3Dt0 0F0a0u0l0t1'1 ,o nF ArRe=3Dabdf b ftfr7a5pef,r asmpes:r =3D0ax0f0b020c08193b 0 r 0F S=3DR0=3D3030c0a0b060e0,1 ,r 1F A=3DR0=3D0b0f1bfffff7f5,e ,r 2s p=3Dscr7=3D1a8020000000,1 3r 3 r=3D00 1=3D0003031c9a3b 7 0r,4 r=3D1c 2=3D50b010410f4f,f fr,5 r=3D20 0=3D0c0701080200,0 0r,6 r=3D3f b=3D2031e0c0a081,9 3r 7 r=3D40 0=3D0c02050bc174 0 4r,8 r=3D5b f=3Db0f0f0704060,0 0r,9 r=3D6c 7=3D4fbbc2ac280c,a 8r,1 0r=3D7c 2=3D50b010308000,c 7r 1 1r=3D8f b=3D2b3febaf6f07 4 6r,1 2r=3D90 0=3D0c07040b0c2a,2 0s,s pr=3D1f0b=3D2c32e5ab0103,8 0s,l rr=3D1c12=3D2f4b92ec580a,6 0p c r=3D1c22=3D204090f0a000 0 2 , ssp=3Dfb2c8a00, slr=3Dc2249e50, pc =3Dc2249fa0 timeout stopping cpus [ thread pid 20194 tid 100146 ] Stopped at cache_lookup+0x1c0: ldr r0, [r8, #0x018] db> timeout stopping cpus [ thread pid 20202 tid 100192 ] Stopped at cache_lookup+0x1c0: ldr r0, [r8, #0x018] db> l =08No such command db> d uvmmp.p =08Symbol not found KDB: reentering KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc2469c14 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23e4d0 fp =3D 0xfb23e5e8 r10 =3D 0xfb23e660 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23e5f0 fp =3D 0xfb23e5f8 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2041018 (db_error+0x24) sp =3D 0xfb23e600 fp =3D 0xfb23e600 r4 =3D 0x00000001 r5 =3D 0xfb23e630 db_error() at db_error+0x24 pc =3D 0xc2041018 lr =3D 0xc20424ac ($a+0xa0) sp =3D 0xfb23e608 fp =3D 0xfb23e610 $a() at $a+0xa0 pc =3D 0xc20424ac lr =3D 0xc204238c (db_unary+0x8c) sp =3D 0xfb23e618 fp =3D 0xfb23e620 r4 =3D 0xfb23e630 r5 =3D 0x00000000 db_unary() at db_unary+0x8c pc =3D 0xc204238c lr =3D 0xc2042200 (db_mult_expr+0x18) sp =3D 0xfb23e628 fp =3D 0xfb23e650 r4 =3D 0x00000000 db_mult_expr() at db_mult_expr+0x18 pc =3D 0xc2042200 lr =3D 0xc204215c (db_add_expr+0x18) sp =3D 0xfb23e658 fp =3D 0xfb23e678 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 r8 =3D 0xfb23e688 r9 =3D 0xc2557d88 r10 =3D 0xc25b83dc db_add_expr() at db_add_expr+0x18 pc =3D 0xc204215c lr =3D 0xc204208c (db_expression+0x18) sp =3D 0xfb23e680 fp =3D 0xfb23e6a8 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 r8 =3D 0x00000001 db_expression() at db_expression+0x18 pc =3D 0xc204208c lr =3D 0xc2040efc (db_command+0x304) sp =3D 0xfb23e6b0 fp =3D 0xfb23e750 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0x00000000 r7 =3D 0xc2557f20 r8 =3D 0x00000001 r9 =3D 0xc2557d88 r10 =3D 0xc25b83dc db_command() at db_command+0x304 pc =3D 0xc2040efc lr =3D 0xc2040bcc (db_command_loop+0x60) sp =3D 0xfb23e758 fp =3D 0xfb23e768 r4 =3D 0xc24b2808 r5 =3D 0xc24c3b66 r6 =3D 0xc25b83c8 r7 =3D 0xfb23e9b0 r8 =3D 0x00000001 r9 =3D 0xc25581b8 r10 =3D 0xc25ad634 db_command_loop() at db_command_loop+0x60 pc =3D 0xc2040bcc lr =3D 0xc2043710 (db_trap+0xd8) sp =3D 0xfb23e770 fp =3D 0xfb23e890 r4 =3D 0x00000000 r5 =3D 0xc25b83d4 r6 =3D 0xc25ad658 db_trap() at db_trap+0xd8 pc =3D 0xc2043710 lr =3D 0xc21e48b4 (kdb_trap+0x15c) sp =3D 0xfb23e898 fp =3D 0xfb23e8b8 r4 =3D 0x00000000 r5 =3D 0x00000011 r6 =3D 0xc25ad658 r7 =3D 0xfb23e9b0 kdb_trap() at kdb_trap+0x15c pc =3D 0xc21e48b4 lr =3D 0xc248196c (abort_fatal+0x180) sp =3D 0xfb23e8c0 fp =3D 0xfb23e8d8 r4 =3D 0xfb23e9b0 r5 =3D 0x00000013 r6 =3D 0xbfbff75e r7 =3D 0x00000001 r8 =3D 0x00000011 r9 =3D 0xbfbff75e r10 =3D 0x00000000 abort_fatal() at abort_fatal+0x180 pc =3D 0xc248196c lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e8e0 fp =3D 0xfb23e8f0 r4 =3D 0x00000000 r5 =3D 0x00000001 r6 =3D 0x00000013 r7 =3D 0x00000011 r8 =3D 0x00000000 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e8f4 fp =3D 0xfb23e9a8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e9ac fp =3D 0xfb23ea60 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ea64 fp =3D 0xfb23ea98 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ea9c fp =3D 0xfb23eab0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eab4 fp =3D 0xfb23eb08 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eb0c fp =3D 0xfb23eb98 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eb9c fp =3D 0xfb23ecf8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ecfc fp =3D 0xfb23ed90 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ed94 fp =3D 0xfb23ee48 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ee4c fp =3D 0xbfbfd5a8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5ac fp =3D 0xbfbfd5c8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5cc fp =3D 0xbfbfd5e0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5e4 fp =3D 0xbfbfd608 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd60c fp =3D 0xbfbfd668 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd66c fp =3D 0xbfbfd898 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd89c fp =3D 0xbfbfd900 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd904 fp =3D 0xbfbfd958 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd95c fp =3D 0xbfbfd970 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd974 fp =3D 0xbfbfdae0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdae4 fp =3D 0xbfbfdaf8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdafc fp =3D 0xbfbfdb30 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdb34 fp =3D 0xbfbfdbc8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdbcc fp =3D 0xbfbfdf78 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdf7c fp =3D 0xbfbfeab0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfeab4 fp =3D 0xbfbfead8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfeadc fp =3D 0x00000000 KDB: reentering KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc2469c14 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23e1e8 fp =3D 0xfb23e300 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23e308 fp =3D 0xfb23e310 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23e318 fp =3D 0xfb23e3c8 r4 =3D 0xfb23e3d0 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23e3d0 fp =3D 0xfb23e468 r4 =3D 0xfb23e470 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e480 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23e420 fp =3D 0xfb23e468 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23e470 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e480 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23e470 fp =3D 0xfb23e4c8 r4 =3D 0xfb2c8778 r5 =3D 0xfb23e4d0 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 r8 =3D 0xfb23e688 r9 =3D 0xc2557d88 r10 =3D 0xfb23e660 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23e4d0 fp =3D 0xfb23e5e8 r10 =3D 0xfb23e660 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23e5f0 fp =3D 0xfb23e5f8 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2041018 (db_error+0x24) sp =3D 0xfb23e600 fp =3D 0xfb23e600 r4 =3D 0x00000001 r5 =3D 0xfb23e630 db_error() at db_error+0x24 pc =3D 0xc2041018 lr =3D 0xc20424ac ($a+0xa0) sp =3D 0xfb23e608 fp =3D 0xfb23e610 $a() at $a+0xa0 pc =3D 0xc20424ac lr =3D 0xc204238c (db_unary+0x8c) sp =3D 0xfb23e618 fp =3D 0xfb23e620 r4 =3D 0xfb23e630 r5 =3D 0x00000000 db_unary() at db_unary+0x8c pc =3D 0xc204238c lr =3D 0xc2042200 (db_mult_expr+0x18) sp =3D 0xfb23e628 fp =3D 0xfb23e650 r4 =3D 0x00000000 db_mult_expr() at db_mult_expr+0x18 pc =3D 0xc2042200 lr =3D 0xc204215c (db_add_expr+0x18) sp =3D 0xfb23e658 fp =3D 0xfb23e678 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 r8 =3D 0xfb23e688 r9 =3D 0xc2557d88 r10 =3D 0xc25b83dc db_add_expr() at db_add_expr+0x18 pc =3D 0xc204215c lr =3D 0xc204208c (db_expression+0x18) sp =3D 0xfb23e680 fp =3D 0xfb23e6a8 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 r8 =3D 0x00000001 db_expression() at db_expression+0x18 pc =3D 0xc204208c lr =3D 0xc2040efc (db_command+0x304) sp =3D 0xfb23e6b0 fp =3D 0xfb23e750 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0x00000000 r7 =3D 0xc2557f20 r8 =3D 0x00000001 r9 =3D 0xc2557d88 r10 =3D 0xc25b83dc db_command() at db_command+0x304 pc =3D 0xc2040efc lr =3D 0xc2040bcc (db_command_loop+0x60) sp =3D 0xfb23e758 fp =3D 0xfb23e768 r4 =3D 0xc24b2808 r5 =3D 0xc24c3b66 r6 =3D 0xc25b83c8 r7 =3D 0xfb23e9b0 r8 =3D 0x00000001 r9 =3D 0xc25581b8 r10 =3D 0xc25ad634 db_command_loop() at db_command_loop+0x60 pc =3D 0xc2040bcc lr =3D 0xc2043710 (db_trap+0xd8) sp =3D 0xfb23e770 fp =3D 0xfb23e890 r4 =3D 0x00000000 r5 =3D 0xc25b83d4 r6 =3D 0xc25ad658 db_trap() at db_trap+0xd8 pc =3D 0xc2043710 lr =3D 0xc21e48b4 (kdb_trap+0x15c) sp =3D 0xfb23e898 fp =3D 0xfb23e8b8 r4 =3D 0x00000000 r5 =3D 0x00000011 r6 =3D 0xc25ad658 r7 =3D 0xfb23e9b0 kdb_trap() at kdb_trap+0x15c pc =3D 0xc21e48b4 lr =3D 0xc248196c (abort_fatal+0x180) sp =3D 0xfb23e8c0 fp =3D 0xfb23e8d8 r4 =3D 0xfb23e9b0 r5 =3D 0x00000013 r6 =3D 0xbfbff75e r7 =3D 0x00000001 r8 =3D 0x00000011 r9 =3D 0xbfbff75e r10 =3D 0x00000000 abort_fatal() at abort_fatal+0x180 pc =3D 0xc248196c lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e8e0 fp =3D 0xfb23e8f0 r4 =3D 0x00000000 r5 =3D 0x00000001 r6 =3D 0x00000013 r7 =3D 0x00000011 r8 =3D 0x00000000 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e8f4 fp =3D 0xfb23e9a8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e9ac fp =3D 0xfb23ea60 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ea64 fp =3D 0xfb23ea98 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ea9c fp =3D 0xfb23eab0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eab4 fp =3D 0xfb23eb08 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eb0c fp =3D 0xfb23eb98 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eb9c fp =3D 0xfb23ecf8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ecfc fp =3D 0xfb23ed90 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ed94 fp =3D 0xfb23ee48 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ee4c fp =3D 0xbfbfd5a8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5ac fp =3D 0xbfbfd5c8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5cc fp =3D 0xbfbfd5e0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5e4 fp =3D 0xbfbfd608 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd60c fp =3D 0xbfbfd668 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd66c fp =3D 0xbfbfd898 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd89c fp =3D 0xbfbfd900 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd904 fp =3D 0xbfbfd958 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd95c fp =3D 0xbfbfd970 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd974 fp =3D 0xbfbfdae0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdae4 fp =3D 0xbfbfdaf8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdafc fp =3D 0xbfbfdb30 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdb34 fp =3D 0xbfbfdbc8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdbcc fp =3D 0xbfbfdf78 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdf7c fp =3D 0xbfbfeab0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfeab4 fp =3D 0xbfbfead8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfeadc fp =3D 0x00000000 KDB: reentering KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc2469c14 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23df00 fp =3D 0xfb23e018 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23e020 fp =3D 0xfb23e028 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23e030 fp =3D 0xfb23e0e0 r4 =3D 0xfb23e0e8 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23e0e8 fp =3D 0xfb23e180 r4 =3D 0xfb23e188 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e198 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23e138 fp =3D 0xfb23e180 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23e188 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e198 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23e188 fp =3D 0xfb23e1e0 r4 =3D 0xfb23e4d0 r5 =3D 0xfb23e1e8 r6 =3D 0x00000013 r7 =3D 0x00000017 r8 =3D 0x00000000 r9 =3D 0x00000000 r10 =3D 0x00000000 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23e1e8 fp =3D 0xfb23e300 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23e308 fp =3D 0xfb23e310 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23e318 fp =3D 0xfb23e3c8 r4 =3D 0xfb23e3d0 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23e3d0 fp =3D 0xfb23e468 r4 =3D 0xfb23e470 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e480 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23e420 fp =3D 0xfb23e468 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23e470 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e480 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23e470 fp =3D 0xfb23e4c8 r4 =3D 0xfb2c8778 r5 =3D 0xfb23e4d0 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 r8 =3D 0xfb23e688 r9 =3D 0xc2557d88 r10 =3D 0xfb23e660 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23e4d0 fp =3D 0xfb23e5e8 r10 =3D 0xfb23e660 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23e5f0 fp =3D 0xfb23e5f8 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2041018 (db_error+0x24) sp =3D 0xfb23e600 fp =3D 0xfb23e600 r4 =3D 0x00000001 r5 =3D 0xfb23e630 db_error() at db_error+0x24 pc =3D 0xc2041018 lr =3D 0xc20424ac ($a+0xa0) sp =3D 0xfb23e608 fp =3D 0xfb23e610 $a() at $a+0xa0 pc =3D 0xc20424ac lr =3D 0xc204238c (db_unary+0x8c) sp =3D 0xfb23e618 fp =3D 0xfb23e620 r4 =3D 0xfb23e630 r5 =3D 0x00000000 db_unary() at db_unary+0x8c pc =3D 0xc204238c lr =3D 0xc2042200 (db_mult_expr+0x18) sp =3D 0xfb23e628 fp =3D 0xfb23e650 r4 =3D 0x00000000 db_mult_expr() at db_mult_expr+0x18 pc =3D 0xc2042200 lr =3D 0xc204215c (db_add_expr+0x18) sp =3D 0xfb23e658 fp =3D 0xfb23e678 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 r8 =3D 0xfb23e688 r9 =3D 0xc2557d88 r10 =3D 0xc25b83dc db_add_expr() at db_add_expr+0x18 pc =3D 0xc204215c lr =3D 0xc204208c (db_expression+0x18) sp =3D 0xfb23e680 fp =3D 0xfb23e6a8 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 r8 =3D 0x00000001 db_expression() at db_expression+0x18 pc =3D 0xc204208c lr =3D 0xc2040efc (db_command+0x304) sp =3D 0xfb23e6b0 fp =3D 0xfb23e750 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0x00000000 r7 =3D 0xc2557f20 r8 =3D 0x00000001 r9 =3D 0xc2557d88 r10 =3D 0xc25b83dc db_command() at db_command+0x304 pc =3D 0xc2040efc lr =3D 0xc2040bcc (db_command_loop+0x60) sp =3D 0xfb23e758 fp =3D 0xfb23e768 r4 =3D 0xc24b2808 r5 =3D 0xc24c3b66 r6 =3D 0xc25b83c8 r7 =3D 0xfb23e9b0 r8 =3D 0x00000001 r9 =3D 0xc25581b8 r10 =3D 0xc25ad634 db_command_loop() at db_command_loop+0x60 pc =3D 0xc2040bcc lr =3D 0xc2043710 (db_trap+0xd8) sp =3D 0xfb23e770 fp =3D 0xfb23e890 r4 =3D 0x00000000 r5 =3D 0xc25b83d4 r6 =3D 0xc25ad658 db_trap() at db_trap+0xd8 pc =3D 0xc2043710 lr =3D 0xc21e48b4 (kdb_trap+0x15c) sp =3D 0xfb23e898 fp =3D 0xfb23e8b8 r4 =3D 0x00000000 r5 =3D 0x00000011 r6 =3D 0xc25ad658 r7 =3D 0xfb23e9b0 kdb_trap() at kdb_trap+0x15c pc =3D 0xc21e48b4 lr =3D 0xc248196c (abort_fatal+0x180) sp =3D 0xfb23e8c0 fp =3D 0xfb23e8d8 r4 =3D 0xfb23e9b0 r5 =3D 0x00000013 r6 =3D 0xbfbff75e r7 =3D 0x00000001 r8 =3D 0x00000011 r9 =3D 0xbfbff75e r10 =3D 0x00000000 abort_fatal() at abort_fatal+0x180 pc =3D 0xc248196c lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e8e0 fp =3D 0xfb23e8f0 r4 =3D 0x00000000 r5 =3D 0x00000001 r6 =3D 0x00000013 r7 =3D 0x00000011 r8 =3D 0x00000000 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e8f4 fp =3D 0xfb23e9a8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e9ac fp =3D 0xfb23ea60 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ea64 fp =3D 0xfb23ea98 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ea9c fp =3D 0xfb23eab0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eab4 fp =3D 0xfb23eb08 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eb0c fp =3D 0xfb23eb98 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eb9c fp =3D 0xfb23ecf8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ecfc fp =3D 0xfb23ed90 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ed94 fp =3D 0xfb23ee48 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ee4c fp =3D 0xbfbfd5a8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5ac fp =3D 0xbfbfd5c8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5cc fp =3D 0xbfbfd5e0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5e4 fp =3D 0xbfbfd608 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd60c fp =3D 0xbfbfd668 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd66c fp =3D 0xbfbfd898 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd89c fp =3D 0xbfbfd900 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd904 fp =3D 0xbfbfd958 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd95c fp =3D 0xbfbfd970 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd974 fp =3D 0xbfbfdae0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdae4 fp =3D 0xbfbfdaf8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdafc fp =3D 0xbfbfdb30 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdb34 fp =3D 0xbfbfdbc8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdbcc fp =3D 0xbfbfdf78 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdf7c fp =3D 0xbfbfeab0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfeab4 fp =3D 0xbfbfead8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfeadc fp =3D 0x00000000 KDB: reentering KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc2469c14 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23dc18 fp =3D 0xfb23dd30 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23dd38 fp =3D 0xfb23dd40 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23dd48 fp =3D 0xfb23ddf8 r4 =3D 0xfb23de00 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23de00 fp =3D 0xfb23de98 r4 =3D 0xfb23dea0 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23deb0 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23de50 fp =3D 0xfb23de98 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23dea0 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23deb0 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23dea0 fp =3D 0xfb23def8 r4 =3D 0xfb23e1e8 r5 =3D 0xfb23df00 r6 =3D 0x00000013 r7 =3D 0x00000017 r8 =3D 0x00000000 r9 =3D 0x00000000 r10 =3D 0x00000000 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23df00 fp =3D 0xfb23e018 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23e020 fp =3D 0xfb23e028 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23e030 fp =3D 0xfb23e0e0 r4 =3D 0xfb23e0e8 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23e0e8 fp =3D 0xfb23e180 r4 =3D 0xfb23e188 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e198 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23e138 fp =3D 0xfb23e180 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23e188 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e198 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23e188 fp =3D 0xfb23e1e0 r4 =3D 0xfb23e4d0 r5 =3D 0xfb23e1e8 r6 =3D 0x00000013 r7 =3D 0x00000017 r8 =3D 0x00000000 r9 =3D 0x00000000 r10 =3D 0x00000000 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23e1e8 fp =3D 0xfb23e300 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23e308 fp =3D 0xfb23e310 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23e318 fp =3D 0xfb23e3c8 r4 =3D 0xfb23e3d0 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23e3d0 fp =3D 0xfb23e468 r4 =3D 0xfb23e470 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e480 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23e420 fp =3D 0xfb23e468 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23e470 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e480 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23e470 fp =3D 0xfb23e4c8 r4 =3D 0xfb2c8778 r5 =3D 0xfb23e4d0 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 r8 =3D 0xfb23e688 r9 =3D 0xc2557d88 r10 =3D 0xfb23e660 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23e4d0 fp =3D 0xfb23e5e8 r10 =3D 0xfb23e660 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23e5f0 fp =3D 0xfb23e5f8 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2041018 (db_error+0x24) sp =3D 0xfb23e600 fp =3D 0xfb23e600 r4 =3D 0x00000001 r5 =3D 0xfb23e630 db_error() at db_error+0x24 pc =3D 0xc2041018 lr =3D 0xc20424ac ($a+0xa0) sp =3D 0xfb23e608 fp =3D 0xfb23e610 $a() at $a+0xa0 pc =3D 0xc20424ac lr =3D 0xc204238c (db_unary+0x8c) sp =3D 0xfb23e618 fp =3D 0xfb23e620 r4 =3D 0xfb23e630 r5 =3D 0x00000000 db_unary() at db_unary+0x8c pc =3D 0xc204238c lr =3D 0xc2042200 (db_mult_expr+0x18) sp =3D 0xfb23e628 fp =3D 0xfb23e650 r4 =3D 0x00000000 db_mult_expr() at db_mult_expr+0x18 pc =3D 0xc2042200 lr =3D 0xc204215c (db_add_expr+0x18) sp =3D 0xfb23e658 fp =3D 0xfb23e678 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 r8 =3D 0xfb23e688 r9 =3D 0xc2557d88 r10 =3D 0xc25b83dc db_add_expr() at db_add_expr+0x18 pc =3D 0xc204215c lr =3D 0xc204208c (db_expression+0x18) sp =3D 0xfb23e680 fp =3D 0xfb23e6a8 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 r8 =3D 0x00000001 db_expression() at db_expression+0x18 pc =3D 0xc204208c lr =3D 0xc2040efc (db_command+0x304) sp =3D 0xfb23e6b0 fp =3D 0xfb23e750 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0x00000000 r7 =3D 0xc2557f20 r8 =3D 0x00000001 r9 =3D 0xc2557d88 r10 =3D 0xc25b83dc db_command() at db_command+0x304 pc =3D 0xc2040efc lr =3D 0xc2040bcc (db_command_loop+0x60) sp =3D 0xfb23e758 fp =3D 0xfb23e768 r4 =3D 0xc24b2808 r5 =3D 0xc24c3b66 r6 =3D 0xc25b83c8 r7 =3D 0xfb23e9b0 r8 =3D 0x00000001 r9 =3D 0xc25581b8 r10 =3D 0xc25ad634 db_command_loop() at db_command_loop+0x60 pc =3D 0xc2040bcc lr =3D 0xc2043710 (db_trap+0xd8) sp =3D 0xfb23e770 fp =3D 0xfb23e890 r4 =3D 0x00000000 r5 =3D 0xc25b83d4 r6 =3D 0xc25ad658 db_trap() at db_trap+0xd8 pc =3D 0xc2043710 lr =3D 0xc21e48b4 (kdb_trap+0x15c) sp =3D 0xfb23e898 fp =3D 0xfb23e8b8 r4 =3D 0x00000000 r5 =3D 0x00000011 r6 =3D 0xc25ad658 r7 =3D 0xfb23e9b0 kdb_trap() at kdb_trap+0x15c pc =3D 0xc21e48b4 lr =3D 0xc248196c (abort_fatal+0x180) sp =3D 0xfb23e8c0 fp =3D 0xfb23e8d8 r4 =3D 0xfb23e9b0 r5 =3D 0x00000013 r6 =3D 0xbfbff75e r7 =3D 0x00000001 r8 =3D 0x00000011 r9 =3D 0xbfbff75e r10 =3D 0x00000000 abort_fatal() at abort_fatal+0x180 pc =3D 0xc248196c lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e8e0 fp =3D 0xfb23e8f0 r4 =3D 0x00000000 r5 =3D 0x00000001 r6 =3D 0x00000013 r7 =3D 0x00000011 r8 =3D 0x00000000 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e8f4 fp =3D 0xfb23e9a8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e9ac fp =3D 0xfb23ea60 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ea64 fp =3D 0xfb23ea98 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ea9c fp =3D 0xfb23eab0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eab4 fp =3D 0xfb23eb08 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eb0c fp =3D 0xfb23eb98 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eb9c fp =3D 0xfb23ecf8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ecfc fp =3D 0xfb23ed90 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ed94 fp =3D 0xfb23ee48 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ee4c fp =3D 0xbfbfd5a8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5ac fp =3D 0xbfbfd5c8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5cc fp =3D 0xbfbfd5e0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5e4 fp =3D 0xbfbfd608 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd60c fp =3D 0xbfbfd668 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd66c fp =3D 0xbfbfd898 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd89c fp =3D 0xbfbfd900 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd904 fp =3D 0xbfbfd958 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd95c fp =3D 0xbfbfd970 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd974 fp =3D 0xbfbfdae0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdae4 fp =3D 0xbfbfdaf8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdafc fp =3D 0xbfbfdb30 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdb34 fp =3D 0xbfbfdbc8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdbcc fp =3D 0xbfbfdf78 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdf7c fp =3D 0xbfbfeab0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfeab4 fp =3D 0xbfbfead8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfeadc fp =3D 0x00000000 KDB: reentering KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc2469c14 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23d930 fp =3D 0xfb23da48 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23da50 fp =3D 0xfb23da58 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23da60 fp =3D 0xfb23db10 r4 =3D 0xfb23db18 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23db18 fp =3D 0xfb23dbb0 r4 =3D 0xfb23dbb8 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23dbc8 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23db68 fp =3D 0xfb23dbb0 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23dbb8 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23dbc8 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23dbb8 fp =3D 0xfb23dc10 r4 =3D 0xfb23df00 r5 =3D 0xfb23dc18 r6 =3D 0x00000013 r7 =3D 0x00000017 r8 =3D 0x00000000 r9 =3D 0x00000000 r10 =3D 0x00000000 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23dc18 fp =3D 0xfb23dd30 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23dd38 fp =3D 0xfb23dd40 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23dd48 fp =3D 0xfb23ddf8 r4 =3D 0xfb23de00 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23de00 fp =3D 0xfb23de98 r4 =3D 0xfb23dea0 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23deb0 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23de50 fp =3D 0xfb23de98 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23dea0 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23deb0 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23dea0 fp =3D 0xfb23def8 r4 =3D 0xfb23e1e8 r5 =3D 0xfb23df00 r6 =3D 0x00000013 r7 =3D 0x00000017 r8 =3D 0x00000000 r9 =3D 0x00000000 r10 =3D 0x00000000 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23df00 fp =3D 0xfb23e018 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23e020 fp =3D 0xfb23e028 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23e030 fp =3D 0xfb23e0e0 r4 =3D 0xfb23e0e8 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23e0e8 fp =3D 0xfb23e180 r4 =3D 0xfb23e188 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e198 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23e138 fp =3D 0xfb23e180 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23e188 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e198 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23e188 fp =3D 0xfb23e1e0 r4 =3D 0xfb23e4d0 r5 =3D 0xfb23e1e8 r6 =3D 0x00000013 r7 =3D 0x00000017 r8 =3D 0x00000000 r9 =3D 0x00000000 r10 =3D 0x00000000 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23e1e8 fp =3D 0xfb23e300 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23e308 fp =3D 0xfb23e310 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23e318 fp =3D 0xfb23e3c8 r4 =3D 0xfb23e3d0 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23e3d0 fp =3D 0xfb23e468 r4 =3D 0xfb23e470 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e480 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23e420 fp =3D 0xfb23e468 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23e470 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e480 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23e470 fp =3D 0xfb23e4c8 r4 =3D 0xfb2c8778 r5 =3D 0xfb23e4d0 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 r8 =3D 0xfb23e688 r9 =3D 0xc2557d88 r10 =3D 0xfb23e660 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23e4d0 fp =3D 0xfb23e5e8 r10 =3D 0xfb23e660 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23e5f0 fp =3D 0xfb23e5f8 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2041018 (db_error+0x24) sp =3D 0xfb23e600 fp =3D 0xfb23e600 r4 =3D 0x00000001 r5 =3D 0xfb23e630 db_error() at db_error+0x24 pc =3D 0xc2041018 lr =3D 0xc20424ac ($a+0xa0) sp =3D 0xfb23e608 fp =3D 0xfb23e610 $a() at $a+0xa0 pc =3D 0xc20424ac lr =3D 0xc204238c (db_unary+0x8c) sp =3D 0xfb23e618 fp =3D 0xfb23e620 r4 =3D 0xfb23e630 r5 =3D 0x00000000 db_unary() at db_unary+0x8c pc =3D 0xc204238c lr =3D 0xc2042200 (db_mult_expr+0x18) sp =3D 0xfb23e628 fp =3D 0xfb23e650 r4 =3D 0x00000000 db_mult_expr() at db_mult_expr+0x18 pc =3D 0xc2042200 lr =3D 0xc204215c (db_add_expr+0x18) sp =3D 0xfb23e658 fp =3D 0xfb23e678 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 r8 =3D 0xfb23e688 r9 =3D 0xc2557d88 r10 =3D 0xc25b83dc db_add_expr() at db_add_expr+0x18 pc =3D 0xc204215c lr =3D 0xc204208c (db_expression+0x18) sp =3D 0xfb23e680 fp =3D 0xfb23e6a8 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 r8 =3D 0x00000001 db_expression() at db_expression+0x18 pc =3D 0xc204208c lr =3D 0xc2040efc (db_command+0x304) sp =3D 0xfb23e6b0 fp =3D 0xfb23e750 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0x00000000 r7 =3D 0xc2557f20 r8 =3D 0x00000001 r9 =3D 0xc2557d88 r10 =3D 0xc25b83dc db_command() at db_command+0x304 pc =3D 0xc2040efc lr =3D 0xc2040bcc (db_command_loop+0x60) sp =3D 0xfb23e758 fp =3D 0xfb23e768 r4 =3D 0xc24b2808 r5 =3D 0xc24c3b66 r6 =3D 0xc25b83c8 r7 =3D 0xfb23e9b0 r8 =3D 0x00000001 r9 =3D 0xc25581b8 r10 =3D 0xc25ad634 db_command_loop() at db_command_loop+0x60 pc =3D 0xc2040bcc lr =3D 0xc2043710 (db_trap+0xd8) sp =3D 0xfb23e770 fp =3D 0xfb23e890 r4 =3D 0x00000000 r5 =3D 0xc25b83d4 r6 =3D 0xc25ad658 db_trap() at db_trap+0xd8 pc =3D 0xc2043710 lr =3D 0xc21e48b4 (kdb_trap+0x15c) sp =3D 0xfb23e898 fp =3D 0xfb23e8b8 r4 =3D 0x00000000 r5 =3D 0x00000011 r6 =3D 0xc25ad658 r7 =3D 0xfb23e9b0 kdb_trap() at kdb_trap+0x15c pc =3D 0xc21e48b4 lr =3D 0xc248196c (abort_fatal+0x180) sp =3D 0xfb23e8c0 fp =3D 0xfb23e8d8 r4 =3D 0xfb23e9b0 r5 =3D 0x00000013 r6 =3D 0xbfbff75e r7 =3D 0x00000001 r8 =3D 0x00000011 r9 =3D 0xbfbff75e r10 =3D 0x00000000 abort_fatal() at abort_fatal+0x180 pc =3D 0xc248196c lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e8e0 fp =3D 0xfb23e8f0 r4 =3D 0x00000000 r5 =3D 0x00000001 r6 =3D 0x00000013 r7 =3D 0x00000011 r8 =3D 0x00000000 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e8f4 fp =3D 0xfb23e9a8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e9ac fp =3D 0xfb23ea60 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ea64 fp =3D 0xfb23ea98 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ea9c fp =3D 0xfb23eab0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eab4 fp =3D 0xfb23eb08 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eb0c fp =3D 0xfb23eb98 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eb9c fp =3D 0xfb23ecf8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ecfc fp =3D 0xfb23ed90 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ed94 fp =3D 0xfb23ee48 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ee4c fp =3D 0xbfbfd5a8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5ac fp =3D 0xbfbfd5c8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5cc fp =3D 0xbfbfd5e0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5e4 fp =3D 0xbfbfd608 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd60c fp =3D 0xbfbfd668 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd66c fp =3D 0xbfbfd898 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd89c fp =3D 0xbfbfd900 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd904 fp =3D 0xbfbfd958 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd95c fp =3D 0xbfbfd970 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd974 fp =3D 0xbfbfdae0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdae4 fp =3D 0xbfbfdaf8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdafc fp =3D 0xbfbfdb30 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdb34 fp =3D 0xbfbfdbc8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdbcc fp =3D 0xbfbfdf78 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdf7c fp =3D 0xbfbfeab0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfeab4 fp =3D 0xbfbfead8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfeadc fp =3D 0x00000000 KDB: reentering KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc2469c14 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23d648 fp =3D 0xfb23d760 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23d768 fp =3D 0xfb23d770 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23d778 fp =3D 0xfb23d828 r4 =3D 0xfb23d830 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23d830 fp =3D 0xfb23d8c8 r4 =3D 0xfb23d8d0 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23d8e0 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23d880 fp =3D 0xfb23d8c8 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23d8d0 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23d8e0 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23d8d0 fp =3D 0xfb23d928 r4 =3D 0xfb23dc18 r5 =3D 0xfb23d930 r6 =3D 0x00000013 r7 =3D 0x00000017 r8 =3D 0x00000000 r9 =3D 0x00000000 r10 =3D 0x00000000 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23d930 fp =3D 0xfb23da48 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23da50 fp =3D 0xfb23da58 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23da60 fp =3D 0xfb23db10 r4 =3D 0xfb23db18 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23db18 fp =3D 0xfb23dbb0 r4 =3D 0xfb23dbb8 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23dbc8 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23db68 fp =3D 0xfb23dbb0 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23dbb8 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23dbc8 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23dbb8 fp =3D 0xfb23dc10 r4 =3D 0xfb23df00 r5 =3D 0xfb23dc18 r6 =3D 0x00000013 r7 =3D 0x00000017 r8 =3D 0x00000000 r9 =3D 0x00000000 r10 =3D 0x00000000 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23dc18 fp =3D 0xfb23dd30 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23dd38 fp =3D 0xfb23dd40 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23dd48 fp =3D 0xfb23ddf8 r4 =3D 0xfb23de00 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23de00 fp =3D 0xfb23de98 r4 =3D 0xfb23dea0 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23deb0 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23de50 fp =3D 0xfb23de98 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23dea0 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23deb0 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23dea0 fp =3D 0xfb23def8 r4 =3D 0xfb23e1e8 r5 =3D 0xfb23df00 r6 =3D 0x00000013 r7 =3D 0x00000017 r8 =3D 0x00000000 r9 =3D 0x00000000 r10 =3D 0x00000000 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23df00 fp =3D 0xfb23e018 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23e020 fp =3D 0xfb23e028 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23e030 fp =3D 0xfb23e0e0 r4 =3D 0xfb23e0e8 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23e0e8 fp =3D 0xfb23e180 r4 =3D 0xfb23e188 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e198 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23e138 fp =3D 0xfb23e180 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23e188 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e198 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23e188 fp =3D 0xfb23e1e0 r4 =3D 0xfb23e4d0 r5 =3D 0xfb23e1e8 r6 =3D 0x00000013 r7 =3D 0x00000017 r8 =3D 0x00000000 r9 =3D 0x00000000 r10 =3D 0x00000000 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23e1e8 fp =3D 0xfb23e300 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23e308 fp =3D 0xfb23e310 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23e318 fp =3D 0xfb23e3c8 r4 =3D 0xfb23e3d0 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23e3d0 fp =3D 0xfb23e468 r4 =3D 0xfb23e470 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e480 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23e420 fp =3D 0xfb23e468 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23e470 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e480 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23e470 fp =3D 0xfb23e4c8 r4 =3D 0xfb2c8778 r5 =3D 0xfb23e4d0 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 r8 =3D 0xfb23e688 r9 =3D 0xc2557d88 r10 =3D 0xfb23e660 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23e4d0 fp =3D 0xfb23e5e8 r10 =3D 0xfb23e660 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23e5f0 fp =3D 0xfb23e5f8 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2041018 (db_error+0x24) sp =3D 0xfb23e600 fp =3D 0xfb23e600 r4 =3D 0x00000001 r5 =3D 0xfb23e630 db_error() at db_error+0x24 pc =3D 0xc2041018 lr =3D 0xc20424ac ($a+0xa0) sp =3D 0xfb23e608 fp =3D 0xfb23e610 $a() at $a+0xa0 pc =3D 0xc20424ac lr =3D 0xc204238c (db_unary+0x8c) sp =3D 0xfb23e618 fp =3D 0xfb23e620 r4 =3D 0xfb23e630 r5 =3D 0x00000000 db_unary() at db_unary+0x8c pc =3D 0xc204238c lr =3D 0xc2042200 (db_mult_expr+0x18) sp =3D 0xfb23e628 fp =3D 0xfb23e650 r4 =3D 0x00000000 db_mult_expr() at db_mult_expr+0x18 pc =3D 0xc2042200 lr =3D 0xc204215c (db_add_expr+0x18) sp =3D 0xfb23e658 fp =3D 0xfb23e678 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 r8 =3D 0xfb23e688 r9 =3D 0xc2557d88 r10 =3D 0xc25b83dc db_add_expr() at db_add_expr+0x18 pc =3D 0xc204215c lr =3D 0xc204208c (db_expression+0x18) sp =3D 0xfb23e680 fp =3D 0xfb23e6a8 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 r8 =3D 0x00000001 db_expression() at db_expression+0x18 pc =3D 0xc204208c lr =3D 0xc2040efc (db_command+0x304) sp =3D 0xfb23e6b0 fp =3D 0xfb23e750 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0x00000000 r7 =3D 0xc2557f20 r8 =3D 0x00000001 r9 =3D 0xc2557d88 r10 =3D 0xc25b83dc db_command() at db_command+0x304 pc =3D 0xc2040efc lr =3D 0xc2040bcc (db_command_loop+0x60) sp =3D 0xfb23e758 fp =3D 0xfb23e768 r4 =3D 0xc24b2808 r5 =3D 0xc24c3b66 r6 =3D 0xc25b83c8 r7 =3D 0xfb23e9b0 r8 =3D 0x00000001 r9 =3D 0xc25581b8 r10 =3D 0xc25ad634 db_command_loop() at db_command_loop+0x60 pc =3D 0xc2040bcc lr =3D 0xc2043710 (db_trap+0xd8) sp =3D 0xfb23e770 fp =3D 0xfb23e890 r4 =3D 0x00000000 r5 =3D 0xc25b83d4 r6 =3D 0xc25ad658 db_trap() at db_trap+0xd8 pc =3D 0xc2043710 lr =3D 0xc21e48b4 (kdb_trap+0x15c) sp =3D 0xfb23e898 fp =3D 0xfb23e8b8 r4 =3D 0x00000000 r5 =3D 0x00000011 r6 =3D 0xc25ad658 r7 =3D 0xfb23e9b0 kdb_trap() at kdb_trap+0x15c pc =3D 0xc21e48b4 lr =3D 0xc248196c (abort_fatal+0x180) sp =3D 0xfb23e8c0 fp =3D 0xfb23e8d8 r4 =3D 0xfb23e9b0 r5 =3D 0x00000013 r6 =3D 0xbfbff75e r7 =3D 0x00000001 r8 =3D 0x00000011 r9 =3D 0xbfbff75e r10 =3D 0x00000000 abort_fatal() at abort_fatal+0x180 pc =3D 0xc248196c lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e8e0 fp =3D 0xfb23e8f0 r4 =3D 0x00000000 r5 =3D 0x00000001 r6 =3D 0x00000013 r7 =3D 0x00000011 r8 =3D 0x00000000 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e8f4 fp =3D 0xfb23e9a8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e9ac fp =3D 0xfb23ea60 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ea64 fp =3D 0xfb23ea98 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ea9c fp =3D 0xfb23eab0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eab4 fp =3D 0xfb23eb08 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eb0c fp =3D 0xfb23eb98 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eb9c fp =3D 0xfb23ecf8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ecfc fp =3D 0xfb23ed90 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ed94 fp =3D 0xfb23ee48 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ee4c fp =3D 0xbfbfd5a8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5ac fp =3D 0xbfbfd5c8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5cc fp =3D 0xbfbfd5e0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5e4 fp =3D 0xbfbfd608 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd60c fp =3D 0xbfbfd668 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd66c fp =3D 0xbfbfd898 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd89c fp =3D 0xbfbfd900 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd904 fp =3D 0xbfbfd958 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd95c fp =3D 0xbfbfd970 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd974 fp =3D 0xbfbfdae0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdae4 fp =3D 0xbfbfdaf8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdafc fp =3D 0xbfbfdb30 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdb34 fp =3D 0xbfbfdbc8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdbcc fp =3D 0xbfbfdf78 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdf7c fp =3D 0xbfbfeab0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfeab4 fp =3D 0xbfbfead8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfeadc fp =3D 0x00000000 KDB: reentering KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc2469c14 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23d360 fp =3D 0xfb23d478 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23d480 fp =3D 0xfb23d488 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23d490 fp =3D 0xfb23d540 r4 =3D 0xfb23d548 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23d548 fp =3D 0xfb23d5e0 r4 =3D 0xfb23d5e8 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23d5f8 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23d598 fp =3D 0xfb23d5e0 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23d5e8 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23d5f8 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23d5e8 fp =3D 0xfb23d640 r4 =3D 0xfb23d930 r5 =3D 0xfb23d648 r6 =3D 0x00000013 r7 =3D 0x00000017 r8 =3D 0x00000000 r9 =3D 0x00000000 r10 =3D 0x00000000 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23d648 fp =3D 0xfb23d760 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23d768 fp =3D 0xfb23d770 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23d778 fp =3D 0xfb23d828 r4 =3D 0xfb23d830 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23d830 fp =3D 0xfb23d8c8 r4 =3D 0xfb23d8d0 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23d8e0 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23d880 fp =3D 0xfb23d8c8 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23d8d0 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23d8e0 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23d8d0 fp =3D 0xfb23d928 r4 =3D 0xfb23dc18 r5 =3D 0xfb23d930 r6 =3D 0x00000013 r7 =3D 0x00000017 r8 =3D 0x00000000 r9 =3D 0x00000000 r10 =3D 0x00000000 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23d930 fp =3D 0xfb23da48 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23da50 fp =3D 0xfb23da58 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23da60 fp =3D 0xfb23db10 r4 =3D 0xfb23db18 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23db18 fp =3D 0xfb23dbb0 r4 =3D 0xfb23dbb8 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23dbc8 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23db68 fp =3D 0xfb23dbb0 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23dbb8 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23dbc8 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23dbb8 fp =3D 0xfb23dc10 r4 =3D 0xfb23df00 r5 =3D 0xfb23dc18 r6 =3D 0x00000013 r7 =3D 0x00000017 r8 =3D 0x00000000 r9 =3D 0x00000000 r10 =3D 0x00000000 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23dc18 fp =3D 0xfb23dd30 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23dd38 fp =3D 0xfb23dd40 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23dd48 fp =3D 0xfb23ddf8 r4 =3D 0xfb23de00 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23de00 fp =3D 0xfb23de98 r4 =3D 0xfb23dea0 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23deb0 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23de50 fp =3D 0xfb23de98 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23dea0 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23deb0 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23dea0 fp =3D 0xfb23def8 r4 =3D 0xfb23e1e8 r5 =3D 0xfb23df00 r6 =3D 0x00000013 r7 =3D 0x00000017 r8 =3D 0x00000000 r9 =3D 0x00000000 r10 =3D 0x00000000 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23df00 fp =3D 0xfb23e018 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23e020 fp =3D 0xfb23e028 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23e030 fp =3D 0xfb23e0e0 r4 =3D 0xfb23e0e8 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23e0e8 fp =3D 0xfb23e180 r4 =3D 0xfb23e188 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e198 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23e138 fp =3D 0xfb23e180 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23e188 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e198 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23e188 fp =3D 0xfb23e1e0 r4 =3D 0xfb23e4d0 r5 =3D 0xfb23e1e8 r6 =3D 0x00000013 r7 =3D 0x00000017 r8 =3D 0x00000000 r9 =3D 0x00000000 r10 =3D 0x00000000 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23e1e8 fp =3D 0xfb23e300 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23e308 fp =3D 0xfb23e310 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000017 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23e318 fp =3D 0xfb23e3c8 r4 =3D 0xfb23e3d0 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23e3d0 fp =3D 0xfb23e468 r4 =3D 0xfb23e470 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e480 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0x00000001 (0x1) sp =3D 0xfb23e420 fp =3D 0xfb23e468 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000007 r3 =3D 0x0000000b r4 =3D 0xfb23e470 r5 =3D 0x809b8080 r6 =3D 0x00000001 r7 =3D 0x809b8080 r8 =3D 0xc24cd41b r9 =3D 0xc24e0c1e r10 =3D 0xfb23e480 r12 =3D 0x0000000b db_stack_trace_cmd() at db_stack_trace_cmd+0x3b8 pc =3D 0xc2469a0c lr =3D 0xc2469c40 (db_trace_self+0x2c) sp =3D 0xfb23e470 fp =3D 0xfb23e4c8 r4 =3D 0xfb2c8778 r5 =3D 0xfb23e4d0 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 r8 =3D 0xfb23e688 r9 =3D 0xc2557d88 r10 =3D 0xfb23e660 db_trace_self() at db_trace_self+0x2c pc =3D 0xc2469c40 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23e4d0 fp =3D 0xfb23e5e8 r10 =3D 0xfb23e660 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23e5f0 fp =3D 0xfb23e5f8 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2041018 (db_error+0x24) sp =3D 0xfb23e600 fp =3D 0xfb23e600 r4 =3D 0x00000001 r5 =3D 0xfb23e630 db_error() at db_error+0x24 pc =3D 0xc2041018 lr =3D 0xc20424ac ($a+0xa0) sp =3D 0xfb23e608 fp =3D 0xfb23e610 $a() at $a+0xa0 pc =3D 0xc20424ac lr =3D 0xc204238c (db_unary+0x8c) sp =3D 0xfb23e618 fp =3D 0xfb23e620 r4 =3D 0xfb23e630 r5 =3D 0x00000000 db_unary() at db_unary+0x8c pc =3D 0xc204238c lr =3D 0xc2042200 (db_mult_expr+0x18) sp =3D 0xfb23e628 fp =3D 0xfb23e650 r4 =3D 0x00000000 db_mult_expr() at db_mult_expr+0x18 pc =3D 0xc2042200 lr =3D 0xc204215c (db_add_expr+0x18) sp =3D 0xfb23e658 fp =3D 0xfb23e678 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 r8 =3D 0xfb23e688 r9 =3D 0xc2557d88 r10 =3D 0xc25b83dc db_add_expr() at db_add_expr+0x18 pc =3D 0xc204215c lr =3D 0xc204208c (db_expression+0x18) sp =3D 0xfb23e680 fp =3D 0xfb23e6a8 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xfb23e6b8 r7 =3D 0xc2557f20 r8 =3D 0x00000001 db_expression() at db_expression+0x18 pc =3D 0xc204208c lr =3D 0xc2040efc (db_command+0x304) sp =3D 0xfb23e6b0 fp =3D 0xfb23e750 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0x00000000 r7 =3D 0xc2557f20 r8 =3D 0x00000001 r9 =3D 0xc2557d88 r10 =3D 0xc25b83dc db_command() at db_command+0x304 pc =3D 0xc2040efc lr =3D 0xc2040bcc (db_command_loop+0x60) sp =3D 0xfb23e758 fp =3D 0xfb23e768 r4 =3D 0xc24b2808 r5 =3D 0xc24c3b66 r6 =3D 0xc25b83c8 r7 =3D 0xfb23e9b0 r8 =3D 0x00000001 r9 =3D 0xc25581b8 r10 =3D 0xc25ad634 db_command_loop() at db_command_loop+0x60 pc =3D 0xc2040bcc lr =3D 0xc2043710 (db_trap+0xd8) sp =3D 0xfb23e770 fp =3D 0xfb23e890 r4 =3D 0x00000000 r5 =3D 0xc25b83d4 r6 =3D 0xc25ad658 db_trap() at db_trap+0xd8 pc =3D 0xc2043710 lr =3D 0xc21e48b4 (kdb_trap+0x15c) sp =3D 0xfb23e898 fp =3D 0xfb23e8b8 r4 =3D 0x00000000 r5 =3D 0x00000011 r6 =3D 0xc25ad658 r7 =3D 0xfb23e9b0 kdb_trap() at kdb_trap+0x15c pc =3D 0xc21e48b4 lr =3D 0xc248196c (abort_fatal+0x180) sp =3D 0xfb23e8c0 fp =3D 0xfb23e8d8 r4 =3D 0xfb23e9b0 r5 =3D 0x00000013 r6 =3D 0xbfbff75e r7 =3D 0x00000001 r8 =3D 0x00000011 r9 =3D 0xbfbff75e r10 =3D 0x00000000 abort_fatal() at abort_fatal+0x180 pc =3D 0xc248196c lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e8e0 fp =3D 0xfb23e8f0 r4 =3D 0x00000000 r5 =3D 0x00000001 r6 =3D 0x00000013 r7 =3D 0x00000011 r8 =3D 0x00000000 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e8f4 fp =3D 0xfb23e9a8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23e9ac fp =3D 0xfb23ea60 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ea64 fp =3D 0xfb23ea98 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ea9c fp =3D 0xfb23eab0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eab4 fp =3D 0xfb23eb08 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eb0c fp =3D 0xfb23eb98 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23eb9c fp =3D 0xfb23ecf8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ecfc fp =3D 0xfb23ed90 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ed94 fp =3D 0xfb23ee48 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xfb23ee4c fp =3D 0xbfbfd5a8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5ac fp =3D 0xbfbfd5c8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5cc fp =3D 0xbfbfd5e0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd5e4 fp =3D 0xbfbfd608 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd60c fp =3D 0xbfbfd668 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd66c fp =3D 0xbfbfd898 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd89c fp =3D 0xbfbfd900 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd904 fp =3D 0xbfbfd958 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd95c fp =3D 0xbfbfd970 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfd974 fp =3D 0xbfbfdae0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdae4 fp =3D 0xbfbfdaf8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdafc fp =3D 0xbfbfdb30 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdb34 fp =3D 0xbfbfdbc8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdbcc fp =3D 0xbfbfdf78 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfdf7c fp =3D 0xbfbfeab0 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfeab4 fp =3D 0xbfbfead8 abort_icache() at abort_icache pc =3D 0xc2481a18 lr =3D 0xc2481a18 (abort_icache) sp =3D 0xbfbfeadc fp =3D 0x00000000 KDB: reentering KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc2469c14 lr =3D 0xc20435dc (db_trace_self_wrapper+0x30) sp =3D 0xfb23bdc8 fp =3D 0xfb23bee0 r10 =3D 0x00000000 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc20435dc lr =3D 0xc21e44bc (kdb_reenter+0x60) sp =3D 0xfb23bee8 fp =3D 0xfb23bef0 r4 =3D 0xc25ad650 r5 =3D 0xc25ad634 r6 =3D 0x00000013 r7 =3D 0x00000807 kdb_reenter() at kdb_reenter+0x60 pc =3D 0xc21e44bc lr =3D 0xc2481254 (abort_handler+0x118) sp =3D 0xfb23bef8 fp =3D 0xfb23bfa8 r4 =3D 0xfb23bfb0 r5 =3D 0x00000007 abort_handler() at abort_handler+0x118 pc =3D 0xc2481254 lr =3D 0xc246b9f0 (exception_exit) sp =3D 0xfb23bfb0 fp =3D 0xfb23d080 r4 =3D 0x0000004b r5 =3D 0xfb23d160 r6 =3D 0x00000000 r7 =3D 0x00000000 r8 =3D 0x00000000 r9 =3D 0xc21eaec4 r10 =3D 0xfb23d160 exception_exit() at exception_exit pc =3D 0xc246b9f0 lr =3D 0xc21eaef8 (putchar+0x34) sp =3D 0xfb23c004 fp =3D 0xfb23d080 r0 =3D 0xc246bad4 r1 =3D 0xc26c7000 r2 =3D 0xfb23c00c r3 =3D 0x200001d3 r4 =3D 0x0000004b r5 =3D 0xfb23d160 r6 =3D 0x00000000 r7 =3D 0x00000000 r8 =3D 0x00000000 r9 =3D 0xc21eaec4 r10 =3D 0xfb23d160 r12 =3D 0xfb23d18c data_abort_entry() at data_abort_entry+0x28 pc =3D 0xc246bad4 lr =3D 0xc21eaef8 (putchar+0x34) sp =3D 0xfb23c004 fp =3D 0xfb23d080 Unwind failure (no registers changed) dKbKKDKDDKDKBD:B: rereeentnetreirningg KDKBD:B : sstatcackk b abcackktrtaracce:e : db_trace_sdbe_ltfr()ac e _ se l f () a t at db_trace_selfd b _ t ra c e_ s el f=20 =20 p c =3D 0x c 2 4 6 9 c1 4 l r =3D 0x c 2 0 4 3 5 dc ( pc =3D 0xc246db9_c1tr4a c e _s e l f_ w r ap p er + 0 x 3 0) l r =3D 0x c 20 4 3 5 d c ( sp =3D 0dxbf_bt2cra7ccec_8 se l f_ w ra p pe r + 0x 3 0)=20 f p =3D 0x f b2 c7 d e 0=20 =20 srp 1=3D 00 x f=3Db02cx07f00700 00f0p 1=20 =20 =3D 0xfb2c8088 #### ... ----------------------------------- On Wed, 19 Nov 2014 14:26:15 +0100 Svatopluk Kraus wrote: > If you want to give it a try, you can find my and Michal new arm-v6 > stuff here: >=20 > https://github.com/strejda/freebsd >=20 > ARM_NEW_PMAP option must be defined to build our stuff. >=20 > Regards, > Svatopluk Kraus >=20 >=20 >=20 >=20 > On Sat, Nov 15, 2014 at 2:34 PM, Ulrich Grey > wrote: >=20 > > On Thu, 13 Nov 2014 08:37:13 -0800 > > Rui Paulo wrote: > > > > > On Nov 13, 2014, at 03:52, Ulrich Grey > > > wrote: > > > > > > > > I am running FreeBSD on a Wandboard-Quad: > > > > > > > > FreeBSD 11.0-CURRENT #0 r274420M: Wed Nov 12 14:17:26 UTC 2014 > > > > user@quad > > :/usr/local/DEVEL/obj/usr/local/DEVEL/SRC/head/sys/WANDBOARD-QUAD > > > > arm FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final > > > > 208032) 20140512 WARNING: WITNESS option enabled, expect reduced > > > > performance. CPU: Cortex A9-r2 rev 10 (Cortex-A core) > > > > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 > > > > Security_Ext > > > > > > > > If I try to compile x11/libX11 the system frequently crashes: > > > > > > > > Fatal kernel mode data abort: 'Alignment Fault 1' > > > > trapframe: 0xf72e0ae8 > > > > FSR=3D00000001, FAR=3D000000a7, spsr=3D60000013 > > > > r0 =3D00000004, r1 =3D00000000, r2 =3Dc242b953, r3 =3D00000970 > > > > r4 =3Dc847fd80, r5 =3Dc242b953, r6 =3D000000a7, r7 =3Dc7df6810 > > > > r8 =3D00000000, r9 =3D00000097, r10=3D00000970, r11=3Df72e0b68 > > > > r12=3D000000c0, ssp=3Df72e0b38, slr=3Dc220ebf4, pc =3Dc214fbb4 > > > > > > > > [ thread pid 23015 tid 100147 ] > > > > > > > > Stopped at __mtx_lock_flags+0x50: ldr r0, [r6] > > > > > > > > What can I do? > > > > > > Can you send us the backtrace? > > > > > > > Here are the contents of the info files of the last two crashes: > > > > root@quad:/var/crash # less info.0 > > Dump header from device /dev/da0s1b > > Architecture: armv6 > > Architecture Version: 1 > > Dump Length: 64605184B (61 MB) > > Blocksize: 512 > > Dumptime: Fri Nov 14 15:52:43 2014 > > Hostname: quad > > Magic: FreeBSD Kernel Dump > > Version String: FreeBSD 11.0-CURRENT #1 r274420M: Fri Nov 14 > > 12:57:30 UTC 2014 > > gwgpi@quad > > :/usr/local/DEVEL/obj/usr/local/DEVEL/SRC/head/sys/WANDBOARD-QUAD > > Panic String: vm_fault: fault on nofault entry, addr: c74c5000 Dump > > Parity: 1136560497 Bounds: 0 > > Dump Status: good > > > > Dump header from device /dev/da0s1b > > Architecture: armv6 > > Architecture Version: 1 > > Dump Length: 46439424B (44 MB) > > Blocksize: 512 > > Dumptime: Sat Nov 15 10:38:33 2014 > > Hostname: quad > > Magic: FreeBSD Kernel Dump > > Version String: FreeBSD 11.0-CURRENT #1 r274420M: Fri Nov 14 > > 12:57:30 UTC 2014 > > gwgpi@quad > > :/usr/local/DEVEL/obj/usr/local/DEVEL/SRC/head/sys/WANDBOARD-QUAD > > Panic String: Trying to access non-existent page va e6000 pte > > bfffeff2 Dump Parity: 1943179849 Bounds: 1 > > Dump Status: good > > > > I am not able to get a backtrace: > > > > root@quad:/usr/obj/usr/local/DEVEL/SRC/head/sys/WANDBOARD-QUAD # > > kgdb kernel.debug GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and > > you are welcome to change it and/or distribute copies of it under > > certain conditions. Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for > > details. This GDB was configured as "armv6-marcel-freebsd"...Dwarf > > Error: Could not find abbrev number 114 [in > > module > > /usr/local/DEVEL/obj/usr/local/DEVEL/SRC/head/sys/WANDBOARD-QUAD/kernel= .debug] > > No struct type named linker_file. No struct type named linker_file. > > No struct type named linker_file. No symbol "linker_path" in current > > context. No symbol "linker_files" in current context. > > > > (kgdb) file kernel.symbols > > Reading symbols from kernel.symbols...Dwarf Error: Could not find > > abbrev number 114 [in > > module > > /usr/local/DEVEL/obj/usr/local/DEVEL/SRC/head/sys/WANDBOARD-QUAD/kernel= .symbols] > > No struct type named linker_file. No struct type named linker_file. > > No struct type named linker_file. No symbol "linker_path" in current > > context. No symbol "linker_files" in current context. > > (kgdb) > > > > ----- > > Ulrich > > _______________________________________________ > > 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 Wed Nov 19 23:04:39 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63D48284 for ; Wed, 19 Nov 2014 23:04:39 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A1E937C for ; Wed, 19 Nov 2014 23:04:39 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id x12so1164143qac.32 for ; Wed, 19 Nov 2014 15:04:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VI5X6LHxuP024AbYd9/HgQX5pbRfl4v6ox2nRtCUxIs=; b=fm+FZ1L6NxXF32F4UUEOUYWI5O8mm3VFEWRDGrArR5uzk+iybo+tsQqYMOJonsitmL vI1dOZJ9LjIxbFJSOKkqwfF/c1NnuEaFrpqFt4lT6cetowSe3LSJ8GnWq2hZkkJ+J+tT a5UwQvcLpVgO9Vaia3rZtzD/+Z7blNDKJWM3cxpo/K/Dsx0JzAUXdP+H+2YO27IhfQHm 6S+FAegfiaQM1zxMdYO0XIVkM3O7LA24lbVs8vEWk23UxPLrR3v81hmNJ7BZiC8z83TM vWlTsJWJgO4nRlMDNpERqyZYq3vNx2zSXFwL9SGxpPzbTsG55ukTXZtxJvyLbsr7gCMw TrNA== MIME-Version: 1.0 X-Received: by 10.224.129.196 with SMTP id p4mr41312982qas.1.1416438278172; Wed, 19 Nov 2014 15:04:38 -0800 (PST) Received: by 10.140.23.242 with HTTP; Wed, 19 Nov 2014 15:04:38 -0800 (PST) In-Reply-To: <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> Date: Thu, 20 Nov 2014 00:04:38 +0100 Message-ID: Subject: Re: Wandboard-Quad crashes From: Svatopluk Kraus To: Ulrich Grey Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arm@freebsd.org, Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 23:04:39 -0000 On Wed, Nov 19, 2014 at 10:59 PM, Ulrich Grey wrote: > Thank you for the offer, I have tried it. > > After I had cloned your repository I have added 2 lines to > src/sys/arm/conf/IMX6: > > makeoptions WITHOUT_MODULES="ispfw" # compile error > makeoptions ARM_NEW_PMAP="yes" # is that ok ? > > Add this line to sys/arm/conf/IMX6 file: options ARM_NEW_PMAP Svatopluk Kraus From owner-freebsd-arm@FreeBSD.ORG Wed Nov 19 23:15:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97932A83; Wed, 19 Nov 2014 23:15:23 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 198FA69B; Wed, 19 Nov 2014 23:15:23 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id k14so2177849wgh.38 for ; Wed, 19 Nov 2014 15:15:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=fwV7lnxC4s9Fjm4qeHGwYpo5vBPxE1wmrUmRpP+gEmI=; b=mzadHcMEL5VaC4pOD9o11/RVMihDS//BDflENybOtATwQd+oQyx3HxnxRLRucjsRD5 VmnxbiDwWkngOZLmSkomlHoPzKzx/07jHUnV9wQvPYaHVrblX8+fC5bmZZX/LbKRMKF/ kZS/qaD8C2pwABtRVt6aT/6dMjlyKaABkQ/Zlw+dDNTgrAS1r5+kUBAttdkG01/KZvkU Fbab5N+v983swTaYj76ighFc1eTbqbU+UsFBuVoidm8twF65EdtXEq7IEkxjD7siWaTX sWlAhD8WDn59t20rp8BppN78iJXjOzVj33hfdpWdC/8LAkXSxbf2uldBoYhBTMbg7Re4 JUrw== MIME-Version: 1.0 X-Received: by 10.194.87.131 with SMTP id ay3mr63582922wjb.66.1416438921441; Wed, 19 Nov 2014 15:15:21 -0800 (PST) Sender: zbodek@gmail.com Received: by 10.216.123.1 with HTTP; Wed, 19 Nov 2014 15:15:21 -0800 (PST) In-Reply-To: <20141119140031.7091bd891fee6b0e163e956f@ulrich-grey.de> References: <20141118191625.ec7749080739e8472405a645@ulrich-grey.de> <1416335248.1147.57.camel@revolution.hippie.lan> <20141119140031.7091bd891fee6b0e163e956f@ulrich-grey.de> Date: Thu, 20 Nov 2014 00:15:21 +0100 X-Google-Sender-Auth: fD13zv5TCU_jqji5ZyhGQpAb0N0 Message-ID: Subject: Re: Compilation x11/libX11 fails with panic From: Zbigniew Bodek To: Ulrich Grey Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 23:15:23 -0000 2014-11-19 14:00 GMT+01:00 Ulrich Grey : > After the last crash the system compiled > editors/texworks without problems (uptime ca. 18 hours) > with superpages disabled: > > root@quad:/usr/home/gwgpi # sysctl vm.pmap. > vm.pmap.sp_enabled: 0 > vm.pmap.pv_entry_count: 10917 > vm.pmap.pv_entry_max: 1744848 > vm.pmap.shpgperproc: 200 > vm.pmap.section.demotions: 0 > vm.pmap.section.mappings: 0 > vm.pmap.section.p_failures: 0 > vm.pmap.section.promotions: 0 > root@quad:/usr/home/gwgpi # > > In the following I have done: > > make -j10 buildworld in /usr/src > > The system crashes after ca. 1 hour. > I tryed to get a coredump, but that did not work: > > > vm_fault(0xc75dc4f0, 0, 1, 0) -> 0 > > Fatal kernel mode data abort: 'Translation Fault (P)' > Hello, I'm a little confused now. Could you please clarify whether crashes occur exclusively when superpages are enabled or when you disable superpages you also observe system failures? Best regards zbb > trapframe: 0xfb289cb0 > > FSR=00000017, FAR=00000008, spsr=200000d3 > > r0 =00000000, r1 =00000001, r2 =000000ac, r3 =000000ac > > r4 =fb289d94, r5 =00000000, r6 =00000000, r7 =00000014 > > r8 =000006c0, r9 =c25ab8c0, r10=0000 > 0 > 0v0m0_,f aru1l1t=(f0bx2c8295db8906 > 5 > 8r,1 20=,c 215,b 90b)5 0-,> s0s > p > =Ffabt2a8l9 dk0e0r,n esll rm=ocd2e4 6dda1tfac ,a bpocr t=:c > 2'1T6r1afnes0l a > t > i > on Fault (P)' > > trapframe: 0xf4920d40 > > FSR=00000017, FAR=00000000, spsr=600001d3 > > r0 =00000000, r1 =00000001, r2 =c6f64680, r3 =c25ab8d0 > > r4 =00000000, r5 =c6f64680, r6 =0000000b, r7 =00000000 > > r8 =c25ba41c, r9 =c6f64680, r10=c6f64990, r11=f4920de0 > > r12=00000001, ssp=f4920d94, slr=c21d09ac, pc =c2187f84 > > > > timeout stopping cpus > > [ thread pid 87965 tid 100174 ] > > Stopped at $a+0x148: ldr r1, [r0, #0x008] > > db> timeout stopping cpus > > [ thread pid 11 tid 100007 ] > > Stopped at thread_lock_block+0xc: ldr r1, [r0] > > db> d > > db> qum > > > > No such command > > db> p > > > > c2187f84 > > db> u > > > > Ambiguous > > db> dputm > > > > No such command > > db> p[A > > c2187f84 > > db> > > c2187f84 > > db> [ A [ [ A [ [A > > > > Bad character > > ? > > db> > > > > c218c72f8148 > 7 > f8d4b >> > db> q > > > > No such command > > db> cpasl la udxo > > > > No such command > > db> adduummpp > > > > No such command > > db> > d > > > Not set. > > db> duummpp > > > > No such command > > db> > > Not set. > > db> d d u u m > > > > > > vm_fault(0xc25b9658, 0, 1, 0) -> 0 > > Fatal kernel mode data abort: 'Translation Fault (P)' > > trapframe: 0xf4920d40 > > FSR=00000017, FAR=00000000, spsr=600001d3 > > r0 =00000000, r1 =00000001, r2 =c6f64680, r3 =c25ab8d0 > > r4 =00000000, r5 =c6f64680, r6 =0000000b, r7 =00000000 > > r8 =c25ba41c, r9 =c6f64680, r10=c6f64990, r11=f4920de0 > > r12=00000001, ssp=f4920d94, slr=c21d09ac, pc =c2187f84 > > > > panic: Fatal abort > > cpuid = 0 > > KDB: stack backtrace: > > db_trace_self() at db_trace_self > > pc = 0xc246968c lr = 0xc20435f0 (db_trace_self_wrapper+0x30) > > sp = 0xf4920b00 fp = 0xf4920c18 > > r10 = 0xc6f64680 > > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > > pc = 0xc20435f0 lr = 0xc21e3d14 (kdb_backtrace+0x38) > > sp = 0xf4920c20 fp = 0xf4920c28 > > r4 = 0xc25ad634 r5 = 0xc24e1e8a > > r6 = 0x00000001 r7 = 0xc259e310 > > kdb_backtrace() at kdb_backtrace+0x38 > > pc = 0xc21e3d14 lr = 0xc219f68c (panic+0x124) > > sp = 0xf4920c30 fp = 0xf4920c50 > > r4 = 0x00000100 > > panic() at panic+0x124 > > pc = 0xc219f68c lr = 0xc24814e0 ($d) > > sp = 0xf4920c68 fp = 0xf4920c80 > > r4 = 0xf4920d40 r5 = 0x00000017 > > r6 = 0x600001d3 r7 = 0x00000000 > > r8 = 0xf4920d40 r9 = 0x00000017 > > r10 = 0x00000000 > > $d() at $d > > pc = 0xc24814e0 lr = 0xc248127c (data_abort_handler+0x560) > > sp = 0xf4920c88 fp = 0xf4920d38 > > r4 = 0x00000013 r5 = 0xc6f64680 > > r6 = 0xf4920eb0 r7 = 0x00000000 > > data_abort_handler() at data_abort_handler+0x560 > > pc = 0xc248127c lr = 0xc246b44c (exception_exit) > > sp = 0xf4920d40 fp = 0xf4920de0 > > r4 = 0x00000000 r5 = 0xc6f64680 > > r6 = 0x0000000b r7 = 0x00000000 > > r8 = 0xc25ba41c r9 = 0xc6f64680 > > r10 = 0xc6f64990 > > exception_exit() at exception_exit > > pc = 0xc246b44c lr = 0xc21d09ac (sched_switch+0x3fc) > > sp = 0xf4920d94 fp = 0xf4920de0 > > r0 = 0x00000000 r1 = 0x00000001 > > r2 = 0xc6f64680 r3 = 0xc25ab8d0 > > r4 = 0x00000000 r5 = 0xc6f64680 > > r6 = 0x0000000b r7 = 0x00000000 > > r8 = 0xc25ba41c r9 = 0xc6f64680 > > r10 = 0xc6f64990 r12 = 0x00000001 > > thread_lock_block() at thread_lock_block+0xc > > pc = 0xc2187f84 lr = 0xc21aa4b4 (mi_switch+0x12c) > > sp = 0xf4920de8 fp = 0xf4920e00 > > r4 = 0x00000000 > > mi_switch() at mi_switch+0x12c > > pc = 0xc21aa4b4 lr = 0xc21662a4 (ithread_loop+0x18c) > > sp = 0xf4920e08 fp = 0xf4920e38 > > r4 = 0xc6e19eb0 r5 = 0xc6f64680 > > r6 = 0xc6e39900 r7 = 0xc6e39970 > > r8 = 0xc256aaf0 r9 = 0x00000000 > > ithread_loop() at ithread_loop+0x18c > > pc = 0xc21662a4 lr = 0xc216245c (fork_exit+0xa4) > > sp = 0xf4920e40 fp = 0xf4920e58 > > r4 = 0xc6f64680 r5 = 0xc6f62000 > > r6 = 0xc2166118 r7 = 0xc6e19eb0 > > r8 = 0xf4920e60 r9 = 0x00000000 > > r10 = 0x00000000 > > fork_exit() at fork_exit+0xa4 > > pc = 0xc216245c lr = 0xc246b3dc (swi_exit) > > sp = 0xf4920e60 fp = 0x00000000 > > r4 = 0xc2166118 r5 = 0xc6e19eb0 > > r6 = 0x00000000 r7 = 0x00000000 > > r8 = 0x00000000 > > swi_exit() at swi_exit > > pc = 0xc246b3dc lr = 0xc246b3dc (swi_exit) > > sp = 0xf4920e60 fp = 0x00000000 > > Uptime: 19h16m19s > > panicA:ft eUnr de42f iniends triunscttiruocnsti o(n0 ilnoa kdser,n e0l > s.t o > r > > ecsp)u, > i > d [ = t1h > r > eUadpt ipmied: 1 11 9thi16dm 1190s0 > 0 > 07 ] > > Stopped at thread_lock_block+0x4c: ldmea r13!, > {r4, r11, r15} > > > > db> p > > c2187fc4 > > > > db> > > c2187fc4 > > > > db> panic > > panic: from debugger > > cpuid = 0 > > KDB: enter: panic > > After 42 instructions (0 loads, 0 stores), > > [ thread pid 11 tid 100007 ] > > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > > db> dump > > Physical memory: 2040 MB > > Dumping 145 MB: > ---------------------------------------------------------------- > On Tue, 18 Nov 2014 11:27:28 -0700 > Ian Lepore wrote: > >> On Tue, 2014-11-18 at 19:16 +0100, Ulrich Grey wrote: >> > I am trying to compile x11/libX11 with a Wandboard-Quad: >> > >> > FreeBSD 11.0-CURRENT #0 r274634M: Tue Nov 18 00:44:36 UTC 2014 >> > gwgpi@quad:/usr/local/DEVEL/obj/usr/local/DEVEL/SRC/head/sys/WANDBOARD-QUAD >> > arm >> > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) >> > 20140512 CPU: Cortex A9-r2 rev 10 (Cortex-A core) >> > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 >> > Security_Ext >> > >> > The compilation fails with this message: >> > >> > --- XKBGeom.lo >> > --- CC >> > XKBGeom.lo >> > --- XKBSetGeom.lo >> > --- CC >> > XKBSetGeom.lo : jemalloc_arena.c:600: Failed assertion: >> > "arena_mapbits_unzeroed_get(chunk, i) == unzeroed" >> [...] >> >> I'm curious whether the workaround mentioned recently by Jurgen Weiss >> also works for you, that is, setting: >> >> vm.pmap.sp_enabled=0 >> >> in loader.conf or using sysctl. It's not a fix of course, but it >> might help you make progress, and it would be a clue where we should >> start looking for trouble. >> >> -- Ian >> >> > _______________________________________________ > 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 Thu Nov 20 13:41:59 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C21EF519; Thu, 20 Nov 2014 13:41:59 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 019FAB92; Thu, 20 Nov 2014 13:41:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416490894; l=9150; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Subject:Cc:To:From:Date; bh=B7yA2hxQ7MvgvR+QyAW9zY0/yJk=; b=IboliqxwylllRkxVwrNYaDkNYWO1FUK+BdXVoC96t+GvsUFtMhCsGQ/ypsZOVGvI9qs QNL/tzhmuZQVMkpQt/m1EbV8CYS74K0/2UWXjWnls8ilA55Kg2/3/ICeMMNl6LeltQbqB jKrOaybDenjL7E1VOGGwb8uzrUzYVMq6Or8= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg49ucv33PI= X-RZG-CLASS-ID: mo00 Received: from bbu (p5486975B.dip0.t-ipconnect.de [84.134.151.91]) by smtp.strato.de (RZmta 35.12 DYNA|AUTH) with ESMTPSA id e01801qAKDfOfN9 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate); Thu, 20 Nov 2014 14:41:24 +0100 (CET) Date: Thu, 20 Nov 2014 14:41:22 +0100 From: Ulrich Grey To: Zbigniew Bodek Subject: Re: Compilation x11/libX11 fails with panic Message-Id: <20141120144122.89f7c1549c4632c350d426b8@ulrich-grey.de> In-Reply-To: References: <20141118191625.ec7749080739e8472405a645@ulrich-grey.de> <1416335248.1147.57.camel@revolution.hippie.lan> <20141119140031.7091bd891fee6b0e163e956f@ulrich-grey.de> Organization: - X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; armv6-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 13:41:59 -0000 Hello, the crashes I talk about in this thread occur with superpages disabled. The crashes I talk about in the above thread "Wandboard-Quad crashes" occur with superpages enabled. It was my mistake not to mention that. Sorry. Ulrich ---------------------------------- On Thu, 20 Nov 2014 00:15:21 +0100 Zbigniew Bodek wrote: > 2014-11-19 14:00 GMT+01:00 Ulrich Grey : > > After the last crash the system compiled > > editors/texworks without problems (uptime ca. 18 hours) > > with superpages disabled: > > > > root@quad:/usr/home/gwgpi # sysctl vm.pmap. > > vm.pmap.sp_enabled: 0 > > vm.pmap.pv_entry_count: 10917 > > vm.pmap.pv_entry_max: 1744848 > > vm.pmap.shpgperproc: 200 > > vm.pmap.section.demotions: 0 > > vm.pmap.section.mappings: 0 > > vm.pmap.section.p_failures: 0 > > vm.pmap.section.promotions: 0 > > root@quad:/usr/home/gwgpi # > > > > In the following I have done: > > > > make -j10 buildworld in /usr/src > > > > The system crashes after ca. 1 hour. > > I tryed to get a coredump, but that did not work: > > > > > > vm_fault(0xc75dc4f0, 0, 1, 0) -> 0 > > > > Fatal kernel mode data abort: 'Translation Fault (P)' > > > > Hello, > > I'm a little confused now. Could you please clarify whether crashes > occur exclusively when superpages are enabled or when you disable > superpages you also observe system failures? > > Best regards > zbb > > > > trapframe: 0xfb289cb0 > > > > FSR=00000017, FAR=00000008, spsr=200000d3 > > > > r0 =00000000, r1 =00000001, r2 =000000ac, r3 =000000ac > > > > r4 =fb289d94, r5 =00000000, r6 =00000000, r7 =00000014 > > > > r8 =000006c0, r9 =c25ab8c0, r10=0000 > > 0 > > 0v0m0_,f aru1l1t=(f0bx2c8295db8906 > > 5 > > 8r,1 20=,c 215,b 90b)5 0-,> s0s > > p > > =Ffabt2a8l9 dk0e0r,n esll rm=ocd2e4 6dda1tfac ,a bpocr t=:c > > 2'1T6r1afnes0l a > > t > > i > > on Fault (P)' > > > > trapframe: 0xf4920d40 > > > > FSR=00000017, FAR=00000000, spsr=600001d3 > > > > r0 =00000000, r1 =00000001, r2 =c6f64680, r3 =c25ab8d0 > > > > r4 =00000000, r5 =c6f64680, r6 =0000000b, r7 =00000000 > > > > r8 =c25ba41c, r9 =c6f64680, r10=c6f64990, r11=f4920de0 > > > > r12=00000001, ssp=f4920d94, slr=c21d09ac, pc =c2187f84 > > > > > > > > timeout stopping cpus > > > > [ thread pid 87965 tid 100174 ] > > > > Stopped at $a+0x148: ldr r1, [r0, #0x008] > > > > db> timeout stopping cpus > > > > [ thread pid 11 tid 100007 ] > > > > Stopped at thread_lock_block+0xc: ldr r1, [r0] > > > > db> d > > > > db> qum > > > > > > > > No such command > > > > db> p > > > > > > > > c2187f84 > > > > db> u > > > > > > > > Ambiguous > > > > db> dputm > > > > > > > > No such command > > > > db> p[A > > > > c2187f84 > > > > db> > > > > c2187f84 > > > > db> [ A [ [ A [ [A > > > > > > > > Bad character > > > > ? > > > > db> > > > > > > > > c218c72f8148 > > 7 > > f8d4b > >> > > db> q > > > > > > > > No such command > > > > db> cpasl la udxo > > > > > > > > No such command > > > > db> adduummpp > > > > > > > > No such command > > > > db> > > d > > > > > > Not set. > > > > db> duummpp > > > > > > > > No such command > > > > db> > > > > Not set. > > > > db> d d u u m > > > > > > > > > > > > vm_fault(0xc25b9658, 0, 1, 0) -> 0 > > > > Fatal kernel mode data abort: 'Translation Fault (P)' > > > > trapframe: 0xf4920d40 > > > > FSR=00000017, FAR=00000000, spsr=600001d3 > > > > r0 =00000000, r1 =00000001, r2 =c6f64680, r3 =c25ab8d0 > > > > r4 =00000000, r5 =c6f64680, r6 =0000000b, r7 =00000000 > > > > r8 =c25ba41c, r9 =c6f64680, r10=c6f64990, r11=f4920de0 > > > > r12=00000001, ssp=f4920d94, slr=c21d09ac, pc =c2187f84 > > > > > > > > panic: Fatal abort > > > > cpuid = 0 > > > > KDB: stack backtrace: > > > > db_trace_self() at db_trace_self > > > > pc = 0xc246968c lr = 0xc20435f0 (db_trace_self_wrapper > > +0x30) > > > > sp = 0xf4920b00 fp = 0xf4920c18 > > > > r10 = 0xc6f64680 > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > > > > pc = 0xc20435f0 lr = 0xc21e3d14 (kdb_backtrace+0x38) > > > > sp = 0xf4920c20 fp = 0xf4920c28 > > > > r4 = 0xc25ad634 r5 = 0xc24e1e8a > > > > r6 = 0x00000001 r7 = 0xc259e310 > > > > kdb_backtrace() at kdb_backtrace+0x38 > > > > pc = 0xc21e3d14 lr = 0xc219f68c (panic+0x124) > > > > sp = 0xf4920c30 fp = 0xf4920c50 > > > > r4 = 0x00000100 > > > > panic() at panic+0x124 > > > > pc = 0xc219f68c lr = 0xc24814e0 ($d) > > > > sp = 0xf4920c68 fp = 0xf4920c80 > > > > r4 = 0xf4920d40 r5 = 0x00000017 > > > > r6 = 0x600001d3 r7 = 0x00000000 > > > > r8 = 0xf4920d40 r9 = 0x00000017 > > > > r10 = 0x00000000 > > > > $d() at $d > > > > pc = 0xc24814e0 lr = 0xc248127c (data_abort_handler+0x560) > > > > sp = 0xf4920c88 fp = 0xf4920d38 > > > > r4 = 0x00000013 r5 = 0xc6f64680 > > > > r6 = 0xf4920eb0 r7 = 0x00000000 > > > > data_abort_handler() at data_abort_handler+0x560 > > > > pc = 0xc248127c lr = 0xc246b44c (exception_exit) > > > > sp = 0xf4920d40 fp = 0xf4920de0 > > > > r4 = 0x00000000 r5 = 0xc6f64680 > > > > r6 = 0x0000000b r7 = 0x00000000 > > > > r8 = 0xc25ba41c r9 = 0xc6f64680 > > > > r10 = 0xc6f64990 > > > > exception_exit() at exception_exit > > > > pc = 0xc246b44c lr = 0xc21d09ac (sched_switch+0x3fc) > > > > sp = 0xf4920d94 fp = 0xf4920de0 > > > > r0 = 0x00000000 r1 = 0x00000001 > > > > r2 = 0xc6f64680 r3 = 0xc25ab8d0 > > > > r4 = 0x00000000 r5 = 0xc6f64680 > > > > r6 = 0x0000000b r7 = 0x00000000 > > > > r8 = 0xc25ba41c r9 = 0xc6f64680 > > > > r10 = 0xc6f64990 r12 = 0x00000001 > > > > thread_lock_block() at thread_lock_block+0xc > > > > pc = 0xc2187f84 lr = 0xc21aa4b4 (mi_switch+0x12c) > > > > sp = 0xf4920de8 fp = 0xf4920e00 > > > > r4 = 0x00000000 > > > > mi_switch() at mi_switch+0x12c > > > > pc = 0xc21aa4b4 lr = 0xc21662a4 (ithread_loop+0x18c) > > > > sp = 0xf4920e08 fp = 0xf4920e38 > > > > r4 = 0xc6e19eb0 r5 = 0xc6f64680 > > > > r6 = 0xc6e39900 r7 = 0xc6e39970 > > > > r8 = 0xc256aaf0 r9 = 0x00000000 > > > > ithread_loop() at ithread_loop+0x18c > > > > pc = 0xc21662a4 lr = 0xc216245c (fork_exit+0xa4) > > > > sp = 0xf4920e40 fp = 0xf4920e58 > > > > r4 = 0xc6f64680 r5 = 0xc6f62000 > > > > r6 = 0xc2166118 r7 = 0xc6e19eb0 > > > > r8 = 0xf4920e60 r9 = 0x00000000 > > > > r10 = 0x00000000 > > > > fork_exit() at fork_exit+0xa4 > > > > pc = 0xc216245c lr = 0xc246b3dc (swi_exit) > > > > sp = 0xf4920e60 fp = 0x00000000 > > > > r4 = 0xc2166118 r5 = 0xc6e19eb0 > > > > r6 = 0x00000000 r7 = 0x00000000 > > > > r8 = 0x00000000 > > > > swi_exit() at swi_exit > > > > pc = 0xc246b3dc lr = 0xc246b3dc (swi_exit) > > > > sp = 0xf4920e60 fp = 0x00000000 > > > > Uptime: 19h16m19s > > > > panicA:ft eUnr de42f iniends triunscttiruocnsti o(n0 ilnoa kdser,n > > e0l s.t o > > r > > > > ecsp)u, > > i > > d [ = t1h > > r > > eUadpt ipmied: 1 11 9thi16dm 1190s0 > > 0 > > 07 ] > > > > Stopped at thread_lock_block+0x4c: ldmea r13!, > > {r4, r11, r15} > > > > > > > > db> p > > > > c2187fc4 > > > > > > > > db> > > > > c2187fc4 > > > > > > > > db> panic > > > > panic: from debugger > > > > cpuid = 0 > > > > KDB: enter: panic > > > > After 42 instructions (0 loads, 0 stores), > > > > [ thread pid 11 tid 100007 ] > > > > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > > > > db> dump > > > > Physical memory: 2040 MB > > > > Dumping 145 MB: > > ---------------------------------------------------------------- > > On Tue, 18 Nov 2014 11:27:28 -0700 > > Ian Lepore wrote: > > > >> On Tue, 2014-11-18 at 19:16 +0100, Ulrich Grey wrote: > >> > I am trying to compile x11/libX11 with a Wandboard-Quad: > >> > > >> > FreeBSD 11.0-CURRENT #0 r274634M: Tue Nov 18 00:44:36 UTC 2014 > >> > gwgpi@quad:/usr/local/DEVEL/obj/usr/local/DEVEL/SRC/head/sys/WANDBOARD-QUAD > >> > arm > >> > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) > >> > 20140512 CPU: Cortex A9-r2 rev 10 (Cortex-A core) > >> > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 > >> > Security_Ext > >> > > >> > The compilation fails with this message: > >> > > >> > --- XKBGeom.lo > >> > --- CC > >> > XKBGeom.lo > >> > --- XKBSetGeom.lo > >> > --- CC > >> > XKBSetGeom.lo : jemalloc_arena.c:600: Failed assertion: > >> > "arena_mapbits_unzeroed_get(chunk, i) == unzeroed" > >> [...] > >> > >> I'm curious whether the workaround mentioned recently by Jurgen > >> Weiss also works for you, that is, setting: > >> > >> vm.pmap.sp_enabled=0 > >> > >> in loader.conf or using sysctl. It's not a fix of course, but it > >> might help you make progress, and it would be a clue where we > >> should start looking for trouble. > >> > >> -- Ian > >> > >> > > _______________________________________________ > > 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 Thu Nov 20 14:19: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D1F122F for ; Thu, 20 Nov 2014 14:19:48 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::3]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E54EAF29 for ; Thu, 20 Nov 2014 14:19:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416493159; l=8363; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Subject:Cc:To:From:Date; bh=0YP/mkPz9uXG8tRV53ztacJ3RPU=; b=AeEB8xmfIinInktu0/xJFryjoi22e0CDm/tGXHZmhxW+yapQMPnpmfzlT2sin0IiH6x g6ucU712jBAL+MdyQPQrA62cwqfYVOiN8mBKgFmecYM1QFrZAhhy7bUypled26lSmYfyG HdHOa4RwDSjzzRK+bYdarY+9g4ocRW16hrU= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg49ucv33PI= X-RZG-CLASS-ID: mo00 Received: from bbu (p5486975B.dip0.t-ipconnect.de [84.134.151.91]) by smtp.strato.de (RZmta 35.12 DYNA|AUTH) with ESMTPSA id y02dafqAKEJ2g0z (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate); Thu, 20 Nov 2014 15:19:02 +0100 (CET) Date: Thu, 20 Nov 2014 15:19:00 +0100 From: Ulrich Grey To: Svatopluk Kraus Subject: Re: Wandboard-Quad crashes Message-Id: <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> In-Reply-To: References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> Organization: - X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; armv6-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 14:19:48 -0000 Hello, here the second try: I added this two lines in src/sys/arm/conf/IMX6 makeoptions WITHOUT_MODULES="ispfw" without this I got a compile error in the past. options ARM_NEW_PMAP I have build the kernel without problems and rebooted. Superpages are enabled. This is the running kernel: root@quad:~ # uname -a FreeBSD quad 11.0-CURRENT FreeBSD 11.0-CURRENT #0 751adfd (master)-dirty: Wed Nov 19 17:15:31 UTC 2014 gwgpi@quad:/usr/local/DEVEL/obj/usr/local/DEVEL/STREJDA/freebsd/sys/WANDBOARD-QUAD arm The userland is on revision: r274634M Then I went to /usr/src and build your source tree: make -j10 buildworld After some hours the compilation stopped, but no crash occurs (an endless loop?): cc -fpic -DPIC -O -pipe -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/include -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../include -I/usr/local/DEVEL/STREJDA/freebsd/lib/lib c/arm -DNLS -D__DBINTERFACE_PRIVATE -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/gdtoa -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/libc-vis -DINET6 -I/ usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/libc -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../li bmd -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/jemalloc/include -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/tzcode/stdtime -I/usr/local/DEVEL/STREJDA/f reebsd/lib/libc/stdtime -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/rpc -I/usr/local/DEVEL/ STREJDA/freebsd/lib/libc/arm/softfloat -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno- parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c nslexer.c -o nslexer.So --- libc.so.7 --- --- libc_pic.a --- building shared library libc.so.7 building special pic c library ranlib -D libc_pic.a I waited some hours, but nothing happened anymore. root@quad:~ # ps auxww USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 10 295.9 0.5 0 10488 - RL 1:16AM 1121:36.09 [idle] root 92318 100.0 1.3 35396 27460 0 R 3:34AM 344:30.76 cc -O -pipe -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/include -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../include -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/arm -DNLS -D__DBINTERFACE_PRIVATE -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/gdtoa -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/libc-vis -DINET6 -I/usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/libc -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../libmd -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/jemalloc/include -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/tzcode/stdtime -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/stdtime -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/rpc -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/arm/softfloat -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c munlock.S root 16 0.2 0.5 0 10464 - DL 1:16AM 1:54.06 [syncer] root 97452 0.2 0.1 11580 2996 1 S+ 9:14AM 0:01.34 top -P root 0 0.0 0.5 0 10488 - DLs 1:16AM 0:00.19 [kernel] root 1 0.0 0.0 9296 884 - ILs 1:16AM 0:00.05 /sbin/init -- root 2 0.0 0.5 0 10472 - DL 1:16AM 7:43.52 [cam] root 3 0.0 0.5 0 10464 - DL 1:16AM 0:00.00 [sctp_iterator] root 4 0.0 0.5 0 10464 - DL 1:16AM 0:00.21 [mmcsd0: mmc/sd card] root 5 0.0 0.5 0 10464 - DL 1:16AM 0:00.26 [mmcsd1: mmc/sd card] root 6 0.0 0.5 0 10464 - DL 1:16AM 0:12.04 [pagedaemon] root 7 0.0 0.5 0 10464 - DL 1:16AM 0:00.00 [vmdaemon] root 8 0.0 0.5 0 10464 - DL 1:16AM 0:00.00 [pagezero] root 9 0.0 0.5 0 10472 - DL 1:16AM 0:01.06 [bufdaemon] root 11 0.0 0.5 0 10576 - WL 1:16AM 50:52.07 [intr] root 12 0.0 0.5 0 10480 - DL 1:16AM 5:42.76 [geom] root 13 0.0 0.5 0 10464 - DL 1:16AM 2:14.70 [rand_harvestq] root 14 0.0 0.5 0 10520 - DL 1:16AM 54:25.17 [usb] root 15 0.0 0.5 0 10464 - DL 1:16AM 0:03.81 [vnlru] root 262 0.0 0.1 8896 1048 - Ss 1:17AM 0:00.05 /sbin/devd root 347 0.0 0.1 10224 1528 - Ss 1:17AM 0:00.18 /usr/sbin/syslogd -ss root 440 0.0 0.1 10468 1216 - Is 1:17AM 0:00.01 casperd: zygote (casperd) root 441 0.0 0.1 10468 1292 - Is 1:17AM 0:00.02 /sbin/casperd messagebus 475 0.0 0.1 10780 1552 - Is 1:17AM 0:00.01 /usr/local/bin/dbus-daemon --system root 511 0.0 0.1 12712 2604 - Ss 1:17AM 0:02.21 /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f /var/db/ntpd.drift root 541 0.0 0.1 15836 3012 - Is 1:17AM 0:00.02 /usr/sbin/sshd root 545 0.0 0.1 10300 1784 - Ss 1:17AM 0:00.43 /usr/sbin/cron -s root 601 0.0 0.3 18904 6452 - Is 1:19AM 0:00.13 sshd: gwgpi [priv] (sshd) gwgpi 604 0.0 0.2 18904 4032 - I 1:19AM 2:23.04 sshd: gwgpi@pts/0 (sshd) root 878 0.0 0.3 18904 6540 - Is 1:20AM 0:00.18 sshd: gwgpi [priv] (sshd) gwgpi 896 0.0 0.2 18904 4032 - S 1:20AM 0:01.03 sshd: gwgpi@pts/1 (sshd) root 590 0.0 0.1 11208 2864 u0 Is 1:17AM 0:00.10 login [pam] (login) root 591 0.0 0.2 11208 4472 u0 S 1:17AM 0:00.21 -csh (csh) root 97457 0.0 0.1 10448 2084 u0 R+ 9:21AM 0:00.01 ps auxww gwgpi 605 0.0 0.2 11208 3768 0 Is 1:19AM 0:00.07 -csh (csh) root 607 0.0 0.1 11200 2708 0 I 1:19AM 0:00.08 su root 608 0.0 0.2 11208 3764 0 I 1:19AM 0:00.08 _su (csh) root 613 0.0 0.1 8944 1120 0 S+ 1:20AM 0:03.32 make -j10 buildworld root 618 0.0 0.1 10740 2288 0 I 1:20AM 0:00.01 sh -ev root 619 0.0 0.1 8944 1648 0 S 1:20AM 0:02.76 make -m /usr/local/DEVEL/STREJDA/freebsd/share/mk -f Makefile.inc1 TARGET=arm TARGET_ARCH=armv6 buildworld root 83869 0.0 0.1 10740 2340 0 I 3:23AM 0:00.02 sh -ev root 83870 0.0 0.1 8944 1724 0 S 3:23AM 0:00.94 make -f Makefile.inc1 DESTDIR=/usr/obj/usr/local/DEVEL/STREJDA/freebsd/tmp -DNO_FSCHG MK_HTML=no MK_INFO=no -DNO_LINT MK_MAN=no MK_PROFILE=no MK_TESTS=no MK_TESTS_SUPPORT=yes libraries root 83883 0.0 0.1 10740 2288 0 I 3:23AM 0:00.01 sh -ev root 84734 0.0 0.1 8944 1724 0 S 3:24AM 0:01.01 make -f Makefile.inc1 _startup_libs root 84750 0.0 0.1 10740 2340 0 I 3:24AM 0:00.04 sh -ev root 86840 0.0 1.2 29424 24084 0 S 3:28AM 0:15.96 make MK_TESTS=no DIRPRFX=lib/libc/ all root 92313 0.0 0.1 10740 2284 0 I 3:34AM 0:00.09 sh -ev gwgpi 897 0.0 0.2 11208 3768 1 Is 1:20AM 0:00.08 -csh (csh) root 906 0.0 0.1 11200 2708 1 I 1:20AM 0:00.11 su root 945 0.0 0.2 11208 3764 1 I 1:20AM 0:00.21 _su (csh) root@quad:~ # sysctl vm.pmap. vm.pmap.sp_enabled: 1 vm.pmap.pv_entry_count: 5691 vm.pmap.pv_entry_max: 1744848 vm.pmap.shpgperproc: 200 vm.pmap.section.demotions: 3 vm.pmap.section.mappings: 0 vm.pmap.section.p_failures: 35 vm.pmap.section.promotions: 8 -- regards Ulrich ---------------------------------- On Thu, 20 Nov 2014 00:04:38 +0100 Svatopluk Kraus wrote: > On Wed, Nov 19, 2014 at 10:59 PM, Ulrich Grey > wrote: > > > Thank you for the offer, I have tried it. > > > > After I had cloned your repository I have added 2 lines to > > src/sys/arm/conf/IMX6: > > > > makeoptions WITHOUT_MODULES="ispfw" # compile error > > makeoptions ARM_NEW_PMAP="yes" # is that ok ? > > > > > Add this line to sys/arm/conf/IMX6 file: > > options ARM_NEW_PMAP > > Svatopluk Kraus From owner-freebsd-arm@FreeBSD.ORG Thu Nov 20 16:06:18 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F29FB42C for ; Thu, 20 Nov 2014 16:06:17 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A3706F06 for ; Thu, 20 Nov 2014 16:06:17 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id bm13so2094591qab.40 for ; Thu, 20 Nov 2014 08:06:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4x80Z2hENJAIyp3vq2qO0lEyI4F/8vkKBPPumtCSDoQ=; b=AT4ouIK2e5BGcHMMDQ/wzz/14F2IiSXo2ugb+6jMH9T9ONccHn88QXX+Vlcvw3AJzB AlTAfqYnv/OMKRxfoyMTY/gSMdlpVpzctDxsTC5gRAjpXssye3cLVFLo8pzCdA10xSe+ humckAap9VwJo5Y0MpNQiwpwt8zBE4ew6eXL5bcvjZEZASa8TtMMq5ZVQhqgi/MAMFD5 YviJNDapCWZ92n99ZvyVRgQiHukvu1dCZFeJ0cDGl/a3JL5YevpB8sSFFadgaUSVESFs kthFyNcPksTzzq80e0lXU/ktsfcO47FJl0pevI1TT6+UStYyOtdcSoQgfVwvlsj4P/a5 O6Sg== MIME-Version: 1.0 X-Received: by 10.140.94.233 with SMTP id g96mr39708990qge.77.1416499576710; Thu, 20 Nov 2014 08:06:16 -0800 (PST) Received: by 10.140.23.242 with HTTP; Thu, 20 Nov 2014 08:06:16 -0800 (PST) In-Reply-To: <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> Date: Thu, 20 Nov 2014 17:06:16 +0100 Message-ID: Subject: Re: Wandboard-Quad crashes From: Svatopluk Kraus To: Ulrich Grey Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arm@freebsd.org, Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 16:06:18 -0000 Are you running the kernel with our pmap? If you type "sysctl vm.pmap", you should get something like this: root@pandaboard:~ # sysctl vm.pmap vm.pmap.pv_entry_max: 1488480 vm.pmap.shpgperproc: 200 vm.pmap.nkpt2pg: 10 vm.pmap.sp_enabled: 1 vm.pmap.pte1.demotions: 0 vm.pmap.pte1.mappings: 0 vm.pmap.pte1.p_failures: 44 vm.pmap.pte1.promotions: 9 vm.pmap.pv_entry_count: 11082 vm.pmap.pc_chunk_count: 42 vm.pmap.pc_chunk_allocs: 2882 vm.pmap.pc_chunk_frees: 2840 vm.pmap.pc_chunk_tryfail: 0 vm.pmap.pv_entry_frees: 534924 vm.pmap.pv_entry_allocs: 546006 vm.pmap.pv_entry_spare: 3030 Svatopluk Kraus On Thu, Nov 20, 2014 at 3:19 PM, Ulrich Grey wrote: > Hello, > > here the second try: > > I added this two lines in src/sys/arm/conf/IMX6 > > makeoptions WITHOUT_MODULES="ispfw" > without this I got a compile error in the past. > > options ARM_NEW_PMAP > > I have build the kernel without problems and rebooted. > Superpages are enabled. > > This is the running kernel: > > root@quad:~ # uname -a > FreeBSD quad 11.0-CURRENT FreeBSD 11.0-CURRENT #0 751adfd > (master)-dirty: Wed Nov 19 17:15:31 UTC 2014 > gwgpi@quad > :/usr/local/DEVEL/obj/usr/local/DEVEL/STREJDA/freebsd/sys/WANDBOARD-QUAD > arm > > The userland is on revision: r274634M > > Then I went to /usr/src and build your source tree: > > make -j10 buildworld > > After some hours the compilation stopped, but no crash occurs (an > endless loop?): > > cc -fpic -DPIC -O -pipe > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/include > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../include > -I/usr/local/DEVEL/STREJDA/freebsd/lib/lib c/arm -DNLS > -D__DBINTERFACE_PRIVATE > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/gdtoa > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/libc-vis > -DINET6 -I/ usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/libc > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/resolv -D_ACL_PRIVATE > -DPOSIX_MISTAKE -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../li > bmd > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/jemalloc/include > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/tzcode/stdtime > -I/usr/local/DEVEL/STREJDA/f reebsd/lib/libc/stdtime > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/locale -DBROKEN_DES > -DPORTMAP -DDES_BUILTIN -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/rpc > -I/usr/local/DEVEL/ STREJDA/freebsd/lib/libc/arm/softfloat > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/softfloat > -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 > -Wsystem-headers -Werror -Wall -Wno-format-y2k > -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body > -Wno-string-plus-int -Wno-unused-const-variable > -Wno-tautological-compare -Wno-unused-value -Wno- > parentheses-equality -Wno-unused-function -Wno-enum-conversion > -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter > -Qunused-arguments -c nslexer.c -o nslexer.So > --- libc.so.7 --- > --- libc_pic.a --- > building shared library libc.so.7 > building special pic c library > ranlib -D libc_pic.a > > I waited some hours, but nothing happened anymore. > > root@quad:~ # ps auxww > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME > COMMAND > > root 10 295.9 0.5 0 10488 - RL 1:16AM 1121:36.09 > [idle] > > root 92318 100.0 1.3 35396 27460 0 R 3:34AM 344:30.76 cc > -O -pipe -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/include > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../include > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/arm -DNLS > -D__DBINTERFACE_PRIVATE > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/gdtoa > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/libc-vis > -DINET6 -I/usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/libc > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/resolv -D_ACL_PRIVATE > -DPOSIX_MISTAKE -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../libmd > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/jemalloc/include > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/tzcode/stdtime > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/stdtime > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/locale -DBROKEN_DES > -DPORTMAP -DDES_BUILTIN -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/rpc > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/arm/softfloat > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/softfloat > -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 > -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int > -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value > -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion > -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter > -Qunused-arguments -c munlock.S > > root 16 0.2 0.5 0 10464 - DL 1:16AM 1:54.06 > [syncer] > > root 97452 0.2 0.1 11580 2996 1 S+ 9:14AM 0:01.34 top > -P > > root 0 0.0 0.5 0 10488 - DLs 1:16AM 0:00.19 > [kernel] > > root 1 0.0 0.0 9296 884 - ILs 1:16AM > 0:00.05 /sbin/init -- > > root 2 0.0 0.5 0 10472 - DL 1:16AM 7:43.52 > [cam] > > root 3 0.0 0.5 0 10464 - DL 1:16AM 0:00.00 > [sctp_iterator] > > root 4 0.0 0.5 0 10464 - DL 1:16AM 0:00.21 > [mmcsd0: mmc/sd card] > > root 5 0.0 0.5 0 10464 - DL 1:16AM 0:00.26 > [mmcsd1: mmc/sd card] > > root 6 0.0 0.5 0 10464 - DL 1:16AM 0:12.04 > [pagedaemon] > > root 7 0.0 0.5 0 10464 - DL 1:16AM 0:00.00 > [vmdaemon] > > root 8 0.0 0.5 0 10464 - DL 1:16AM 0:00.00 > [pagezero] > > root 9 0.0 0.5 0 10472 - DL 1:16AM 0:01.06 > [bufdaemon] > > root 11 0.0 0.5 0 10576 - WL 1:16AM 50:52.07 > [intr] > > root 12 0.0 0.5 0 10480 - DL 1:16AM 5:42.76 > [geom] > > root 13 0.0 0.5 0 10464 - DL 1:16AM 2:14.70 > [rand_harvestq] > > root 14 0.0 0.5 0 10520 - DL 1:16AM 54:25.17 > [usb] > > root 15 0.0 0.5 0 10464 - DL 1:16AM 0:03.81 > [vnlru] > > root 262 0.0 0.1 8896 1048 - Ss 1:17AM > 0:00.05 /sbin/devd > > root 347 0.0 0.1 10224 1528 - Ss 1:17AM > 0:00.18 /usr/sbin/syslogd -ss > > root 440 0.0 0.1 10468 1216 - Is 1:17AM 0:00.01 > casperd: zygote (casperd) > > root 441 0.0 0.1 10468 1292 - Is 1:17AM > 0:00.02 /sbin/casperd > > messagebus 475 0.0 0.1 10780 1552 - Is 1:17AM > 0:00.01 /usr/local/bin/dbus-daemon --system > > root 511 0.0 0.1 12712 2604 - Ss 1:17AM > 0:02.21 /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid > -f /var/db/ntpd.drift > > root 541 0.0 0.1 15836 3012 - Is 1:17AM > 0:00.02 /usr/sbin/sshd > > root 545 0.0 0.1 10300 1784 - Ss 1:17AM > 0:00.43 /usr/sbin/cron -s > > root 601 0.0 0.3 18904 6452 - Is 1:19AM 0:00.13 > sshd: gwgpi [priv] (sshd) > > gwgpi 604 0.0 0.2 18904 4032 - I 1:19AM 2:23.04 > sshd: gwgpi@pts/0 (sshd) > > root 878 0.0 0.3 18904 6540 <3%2018904%20%206540> - Is > 1:20AM 0:00.18 > sshd: gwgpi [priv] (sshd) > > gwgpi 896 0.0 0.2 18904 4032 - S 1:20AM 0:01.03 > sshd: gwgpi@pts/1 (sshd) > > root 590 0.0 0.1 11208 2864 u0 Is 1:17AM 0:00.10 > login [pam] (login) > > root 591 0.0 0.2 11208 4472 u0 S 1:17AM 0:00.21 > -csh (csh) > > root 97457 0.0 0.1 10448 2084 u0 R+ 9:21AM 0:00.01 ps > auxww > > gwgpi 605 0.0 0.2 11208 3768 0 Is 1:19AM 0:00.07 > -csh (csh) > > root 607 0.0 0.1 11200 2708 0 I 1:19AM 0:00.08 su > > root 608 0.0 0.2 11208 3764 0 I 1:19AM 0:00.08 _su > (csh) > > root 613 0.0 0.1 8944 1120 0 S+ 1:20AM 0:03.32 > make -j10 buildworld > > root 618 0.0 0.1 10740 2288 0 I 1:20AM 0:00.01 sh > -ev > > root 619 0.0 0.1 8944 1648 0 S 1:20AM 0:02.76 > make -m /usr/local/DEVEL/STREJDA/freebsd/share/mk -f Makefile.inc1 > TARGET=arm TARGET_ARCH=armv6 buildworld > > root 83869 0.0 0.1 10740 2340 0 I 3:23AM 0:00.02 sh > -ev > > root 83870 0.0 0.1 8944 1724 0 S 3:23AM 0:00.94 > make -f Makefile.inc1 > DESTDIR=/usr/obj/usr/local/DEVEL/STREJDA/freebsd/tmp -DNO_FSCHG > MK_HTML=no MK_INFO=no -DNO_LINT MK_MAN=no MK_PROFILE=no MK_TESTS=no > MK_TESTS_SUPPORT=yes libraries > > root 83883 0.0 0.1 10740 2288 0 I 3:23AM 0:00.01 sh > -ev > > root 84734 0.0 0.1 8944 1724 0 S 3:24AM 0:01.01 > make -f Makefile.inc1 _startup_libs > > root 84750 0.0 0.1 10740 2340 0 I 3:24AM 0:00.04 sh > -ev > > root 86840 0.0 1.2 29424 24084 0 S 3:28AM 0:15.96 > make MK_TESTS=no DIRPRFX=lib/libc/ all > > root 92313 0.0 0.1 10740 2284 0 I 3:34AM 0:00.09 sh > -ev > > gwgpi 897 0.0 0.2 11208 3768 1 Is 1:20AM 0:00.08 > -csh (csh) > > root 906 0.0 0.1 11200 2708 1 I 1:20AM 0:00.11 su > > root 945 0.0 0.2 11208 3764 1 I 1:20AM 0:00.21 _su > (csh) > > root@quad:~ # sysctl vm.pmap. > vm.pmap.sp_enabled: 1 > vm.pmap.pv_entry_count: 5691 > vm.pmap.pv_entry_max: 1744848 > vm.pmap.shpgperproc: 200 > vm.pmap.section.demotions: 3 > vm.pmap.section.mappings: 0 > vm.pmap.section.p_failures: 35 > vm.pmap.section.promotions: 8 > > -- > regards > Ulrich > ---------------------------------- > On Thu, 20 Nov 2014 00:04:38 +0100 > Svatopluk Kraus wrote: > > > On Wed, Nov 19, 2014 at 10:59 PM, Ulrich Grey > > wrote: > > > > > Thank you for the offer, I have tried it. > > > > > > After I had cloned your repository I have added 2 lines to > > > src/sys/arm/conf/IMX6: > > > > > > makeoptions WITHOUT_MODULES="ispfw" # compile error > > > makeoptions ARM_NEW_PMAP="yes" # is that ok ? > > > > > > > > Add this line to sys/arm/conf/IMX6 file: > > > > options ARM_NEW_PMAP > > > > Svatopluk Kraus > From owner-freebsd-arm@FreeBSD.ORG Thu Nov 20 17:04:52 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D6755A4 for ; Thu, 20 Nov 2014 17:04:52 +0000 (UTC) Received: from relay.waschbuesch.it (relay.waschbuesch.it [80.254.137.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "*.waschbuesch.it", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 30AA285E for ; Thu, 20 Nov 2014 17:04:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=waschbuesch.de; s=dkim; h=Mime-Version:To:Message-Id:Date:Subject:Content-Type:From; bh=XuxvcWU+u18VLZlMrJq0UFJx5NWLvsA+dlrS7P3OUuI=; b=dejW6v1NcWgUKuycIVOHpGAZVQJIwhWXuebua72n4tVi0nt0sNMYIlrSnl+VQpbGSLV2Dy8R36xRo9SUTt30y/zUulBQ7ler+6dZ15mILQfzz8gzTlASYogKFazL7NQvi1f97yds9yuY0G6S3rCwQeS1dm2lohyWKSSSBrsM0H0=; Received: by relay.waschbuesch.it with esmtpsa (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim) (envelope-from ) id 1XrUrj-0008GA-3E for freebsd-arm@freebsd.org; Thu, 20 Nov 2014 17:45:55 +0100 From: =?utf-8?Q?Waschb=C3=BCsch_Martin?= X-Pgp-Agent: GPGMail 2.5b2 Content-Type: multipart/signed; boundary="Apple-Mail=_39B62E95-A752-4B70-A428-0515242FD7B9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Utilite support Date: Thu, 20 Nov 2014 17:45:54 +0100 Message-Id: To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 17:04:52 -0000 --Apple-Mail=_39B62E95-A752-4B70-A428-0515242FD7B9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hey there, I just read on https://wiki.freebsd.org/FreeBSD/arm/imx6 that Utilite might also be supported. Has anyone managed to install FreeBSD on such a device? Or could give me some pointers on how to do it? The unit I have is the Utilite Pro (quad core with 2G RAM and internal mSata SSD). I have looked at the crochet script but have not yet managed to get the thing to booting. Any and all help is appreciated! Thanks, Martin --Apple-Mail=_39B62E95-A752-4B70-A428-0515242FD7B9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUbhrCAAoJEP0QXR2ClIJ9plQH+wenY72Lf+c5SG8PJNUWFhpJ 9tcaoAvGckvItvMqlVXIcPSe16tOz2b1Vk1K6AFROdLQMDxqH1gJjq/tL5ByBqJ0 jlcss7E9WWe00ULHP5sCMJNnY2G0Ivq/QLfsuOSwAnhJ6QCmCeuCy/DBdOL7XdJ1 T4jsdn9HZC8zFwszRw2Q5SuOGBDR26RViNKJPHg+56cx7l+DoI5mepa5BcgCb7+6 oNLUHfaQ10u6G6uW51fE0Brso2Vllz0PpIKCeOGIp7baI0CfpbLHFxvimiJ1dsGz L5+uK7nCmOHt0dPFMhISirGNkx4M72cf/OrNibybIht3Raml38zvW/0yiIIWy0s= =kZFR -----END PGP SIGNATURE----- --Apple-Mail=_39B62E95-A752-4B70-A428-0515242FD7B9-- From owner-freebsd-arm@FreeBSD.ORG Thu Nov 20 17:20:02 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8668DEB3 for ; Thu, 20 Nov 2014 17:20:02 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5A301A7F for ; Thu, 20 Nov 2014 17:20:02 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XrVOi-0004cd-Bw; Thu, 20 Nov 2014 17:20:00 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sAKHJwHn001330; Thu, 20 Nov 2014 10:19:58 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX189uE8tL2uenkoVX9qLLb47 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Utilite support From: Ian Lepore To: =?ISO-8859-1?Q?Waschb=FCsch?= Martin In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 20 Nov 2014 10:19:58 -0700 Message-ID: <1416503998.1147.185.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 ilsoft.org id sAKHJwHn001330 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 17:20:02 -0000 On Thu, 2014-11-20 at 17:45 +0100, Waschb=FCsch Martin wrote: > Hey there, >=20 > I just read on https://wiki.freebsd.org/FreeBSD/arm/imx6 that Utilite > might also be supported. Has anyone managed to install FreeBSD > on such a device? Or could give me some pointers on how to do it? > The unit I have is the Utilite Pro (quad core with 2G RAM and internal > mSata SSD). I have looked at the crochet script but have not yet > managed to get the thing to booting. >=20 > Any and all help is appreciated! >=20 > Thanks, >=20 > Martin I'm the one who added that "might be..." on the basis that the Utilite setup looks close enough to Wandboard that it should be "easy" to get it working, for some loose definition of "easy". When I wrote that I had planned to buy one and get it working, but they're just too expensive for what they include so I never did. What I did do a few days ago is buy the new SolidRun Cubox i4pro v2, it should be here soon. That will give me some idea of how easy or hard it is to get freebsd running on some imx6 box that isn't a wandboard (and isn't one of our custom systems at $work). There is some chance that "it might just work." Actually a better chance now than when I originally wrote that. :) Try using crochet for wandboard and in the wandboard kernel config file change FDT_DTS_FILE to "imx6q-cm-fx6.dts". There's a good chance you'll end up with a bootable image on an sdcard. You will need a serial console for debugging, we don't support a video console yet on imx6 systems. The Compulab FitPc2 x86 systems need a special serial debugging cable that you have to buy separately. I hope that's not also the case with Utilite. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Nov 20 19:13: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F4807C1 for ; Thu, 20 Nov 2014 19:13:08 +0000 (UTC) Received: from mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EA0B2D4C for ; Thu, 20 Nov 2014 19:13:07 +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 848E2125EE2 for ; Thu, 20 Nov 2014 11:13:01 -0800 (PST) Received: from pop.rubicorp.com (unknown [72.34.113.100]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.nomadlogic.org (Postfix) with ESMTPSA id 792F6125EBA for ; Thu, 20 Nov 2014 11:13:01 -0800 (PST) Message-ID: <546E3D3D.30004@nomadlogic.org> Date: Thu, 20 Nov 2014 11:13:01 -0800 From: Pete Wright User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Utilite support References: <1416503998.1147.185.camel@revolution.hippie.lan> In-Reply-To: <1416503998.1147.185.camel@revolution.hippie.lan> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 19:13:08 -0000 On 11/20/14 09:19, Ian Lepore wrote: > On Thu, 2014-11-20 at 17:45 +0100, Waschbüsch Martin wrote: >> Hey there, >> >> I just read on https://wiki.freebsd.org/FreeBSD/arm/imx6 that Utilite >> might also be supported. Has anyone managed to install FreeBSD >> on such a device? Or could give me some pointers on how to do it? >> The unit I have is the Utilite Pro (quad core with 2G RAM and internal >> mSata SSD). I have looked at the crochet script but have not yet >> managed to get the thing to booting. >> >> Any and all help is appreciated! >> >> Thanks, >> >> Martin > > I'm the one who added that "might be..." on the basis that the Utilite > setup looks close enough to Wandboard that it should be "easy" to get it > working, for some loose definition of "easy". When I wrote that I had > planned to buy one and get it working, but they're just too expensive > for what they include so I never did. > > What I did do a few days ago is buy the new SolidRun Cubox i4pro v2, it > should be here soon. That will give me some idea of how easy or hard it > is to get freebsd running on some imx6 box that isn't a wandboard (and > isn't one of our custom systems at $work). > > There is some chance that "it might just work." Actually a better > chance now than when I originally wrote that. :) Try using crochet for > wandboard and in the wandboard kernel config file change FDT_DTS_FILE to > "imx6q-cm-fx6.dts". There's a good chance you'll end up with a bootable > image on an sdcard. > > You will need a serial console for debugging, we don't support a video > console yet on imx6 systems. The Compulab FitPc2 x86 systems need a > special serial debugging cable that you have to buy separately. I hope > that's not also the case with Utilite. > I've been doing on-again off-again testing of FreeBSD on utilite. This is great info Ian, I am hoping that now that my dayjob has just hit our US holiday's release freeze I'll have some time next week to test again. -pete -- Pete Wright pete@nomadlogic.org twitter => @nomadlogicLA From owner-freebsd-arm@FreeBSD.ORG Thu Nov 20 22:02:32 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3731DF5B for ; Thu, 20 Nov 2014 22:02:32 +0000 (UTC) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F216938E for ; Thu, 20 Nov 2014 22:02:31 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id rd18so3767663iec.1 for ; Thu, 20 Nov 2014 14:02:25 -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=ZANt+pBiYC1WN08gjH+NraqCD4m/ITxmhPfRpN+0pEQ=; b=TSlh+nxXRaIBQjHWwfWVI62+zpmT2KTn0/fiXTWYNOmnYcGlB5MpVIzDoeuCsXQAUj PUB40tbE1METu2EqWX6kbxyWtS/1rUpd+OXVbnvdFG3kjYOrG+cvu5i495cdZRK+AQ3F 4+5AGkrjfQPnJvDk3n9ToU89esjGaUNy06IW8NnTX0W12K4sdSrOLo1nfgRXhRPRUt8P 3/KaERrR4qzcK+d056sv9rMvGwHgHkSSMzuAUseHPSnklTyHIPysZB/KYjrXrm/MLNeJ E4Mi35N/miOb0BN27ZBYby0KTW6Tb6ctal8dU27XL1BGGSnvq+4JUogtL7k8/NeYMXBm ZLmA== X-Gm-Message-State: ALoCoQmt//ymtx7j+YStFY9H0oIvz+EhwPSwBr+ZxzPEYBz3h+lE4GrG+bDyVu/Scifi3TbyLeoK MIME-Version: 1.0 X-Received: by 10.50.66.179 with SMTP id g19mr11926425igt.8.1416520944877; Thu, 20 Nov 2014 14:02:24 -0800 (PST) Received: by 10.107.170.2 with HTTP; Thu, 20 Nov 2014 14:02:24 -0800 (PST) In-Reply-To: References: <542271AE.6070807@andrew.cmu.edu> <2c451765bffb43e8b9dab56927bb351a@e15be-02.zdv.Uni-Mainz.DE> Date: Thu, 20 Nov 2014 17:02:24 -0500 Message-ID: Subject: Re: Jetson TK1 board support From: David Rayson To: =?UTF-8?B?V2Vpw58sIERyLiBKw7xyZ2Vu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 22:02:32 -0000 Here is a patch (on top of your last patch set) that adds support for the RTC (just for use as a clock; not for timers/alarms): http://www.contrib.andrew.cmu.edu/~drayson/tegra-rtc.patch I'm also taking a look at what it would take to get a framebuffer console working... --David On Tue, Nov 18, 2014 at 2:31 PM, David Rayson wrote: > Thanks -- it works for me now! I added a driver for the RTC (although > it's still not super useful without being battery-backed); I'll send > patches later today. Would it make sense to set up a repository somewher= e > to put this in instead of just sending around patches? > > --David > > On Fri, Nov 14, 2014 at 3:58 PM, Wei=C3=9F, Dr. J=C3=BCrgen > wrote: > >> The Ethernet works quite well. But there has been a change in a more >> recent version of u-boot which did not initialize the interrupt >> routing of the pcie bridge. So you do not get receive interrupts. >> >> I put more recent patches for the jetson tk1 board to >> >> http://www.staff.uni-mainz.de/weiss/jetson-tk1-20141114.tgz >> >> New changes to u-boot: >> (diff to git://nv-tegra.nvidia.com/3rdparty/u-boot.git): >> device enumeration through the u-boot API did only return the >> first device of each type. >> >> New changes to the FreeBSD kernel: >> (diff to FreeBSD current): >> better initialize pcie bridge interrupt routing. >> change cpu clock to 2 GHz (about 3 times faster) >> SDHCI support. Tested only with non-highspeed cards. >> changed cpu_reset to return to boot loader (u-boot). >> >> Regards >> >> Juergen >> >> Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, >> weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: >> +49(6131)39-26407 >> >> >> > -----Original Message----- >> > From: David Rayson [mailto:drayson@andrew.cmu.edu] >> > Sent: Friday, November 14, 2014 8:29 AM >> > To: Wei=C3=9F, Dr. J=C3=BCrgen >> > Cc: freebsd-arm@freebsd.org >> > Subject: Re: Jetson TK1 board support >> > >> > How well does the ethernet support work for you? When I try to use it= , >> packets are sent >> > successfully, but no packets are received (usually). I think there >> might be some sort of >> > odd race condition: if I break into the debugger, let it sit for a >> while, then continue, >> > it will start to (very intermittently) receive a packet every now and >> then (typically >> > after a watchdog timeout message from the ethernet driver). Any idea >> what could be going >> > on there? >> > >> > >> > --David >> > >> > >> > On Fri, Oct 3, 2014 at 9:33 AM, Wei=C3=9F, Dr. J=C3=BCrgen >> wrote: >> > >> > >> > If you enable the sdhci controller(s) in the fdt, the controller= s >> and >> > the cards are (at least partially) recognized. Read data transfe= rs >> > from the sd card slot return only data bytes with zero contents. >> > The quirk in the fdt should disable DMA. The transfers are done >> > in pio mode. >> > >> > U-boot should already have initialized the controllers. But the >> > generic sdhci driver tries at least to set frequency and bus wid= th >> > according to the cards present. For the EMMC it certainly does >> > not know how to handle 8 bit transfers without further help >> > from a tegra specific driver extensions. >> > >> > Juergen >> > >> > Juergen Weiss |Universitaet Mainz, Zentrum fuer >> Datenverarbeitung, >> > weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361 >> >> > , FAX: +49(6131)39-26407 >> > >> > > -----Original Message----- >> > > From: David Rayson [mailto:drayson@andrew.cmu.edu] >> > > Sent: Thursday, October 02, 2014 11:54 PM >> > > To: Wei=C3=9F, Dr. J=C3=BCrgen >> > > Cc: freebsd-arm@freebsd.org >> > > Subject: Re: Jetson TK1 board support >> > > >> > >> > > How much work do you think would be needed to get the SD >> controller working? Would >> > it >> > > simply be a matter of doing the appropriate initialization >> (wouldn't U-Boot do this >> > > already even?), enabling it in the device tree, and using the >> standard FreeBSD >> > SDHCI >> > > driver, or is there something more complicated that would need >> to be done? >> > > >> > > >> > > (This would probably be simple to test, but I don't have acces= s >> to the hardware >> > right now) >> > > >> > > >> > > --David >> > > >> > > >> > > On Fri, Sep 26, 2014 at 4:39 PM, Wei=C3=9F, Dr. J=C3=BCrgen < >> weiss@uni-mainz.de> wrote: >> > > >> > > >> > > Hi, >> > > >> > > sorry, I did not have any time during the week. >> > > >> > > I just sent a mail to the list with a link to my changes= . >> > > >> > > Only serial, USB2 and PCIe/Ethernet hardware is working = - >> so no >> > > SATA. >> > > >> > > The drivers rely on u-boot to initialize the hardware. >> While this >> > > is ok for pinmux, other initializations should be done b= y >> the >> > > drivers. >> > > >> > > The interrupt handling for PCIe is rather ad hoc. The >> interrupt >> > > routing should honor the FDT description. >> > > >> > > The Tegra platform has a GIC with extensions for interru= pt >> > > routing. I just made a copy of the GIC code end extended >> it >> > > in a few cases. There should probably be a mechanism to = do >> > > this without duplicating code. >> > > >> > > I changed some non tegra files to get FreeBSD running on >> the >> > > hardware. There should be better solutions, which can be >> merged >> > > back to the FreeBSD source tree. For example the problem >> > > with cache coherency due to aggressive L2 prefetch await= s >> > > a real solution. >> > > >> > > There is no code to change the cpu clock yet. >> > > >> > > There is no support for SDHCI or EMMC. >> > > >> > > So I would consider this a first step, which allows to d= o >> > > native development on the platform. >> > > >> > > Besides that, the kernel seems to be quite stable - at >> least with >> > > the compiles I did. >> > > >> > > Regards >> > > >> > > Juergen >> > > >> > > Juergen Weiss |Universitaet Mainz, Zentrum fuer >> Datenverarbeitung, >> > >> > > weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361 >> > >> > > , FAX: +49(6131)39-26407 >> > > 26407> >> > >> > > >> > > >> > > > -----Original Message----- >> > > > From: owner-freebsd-arm@freebsd.org [mailto: >> owner-freebsd-arm@freebsd.org] >> > On >> > > Behalf Of >> > > > David Rayson >> > > > Sent: Wednesday, September 24, 2014 9:25 AM >> > > > To: freebsd-arm@freebsd.org >> > > > Subject: Re: Jetson TK1 board support >> > > > >> > > > Hi, >> > > > >> > > > What other work would be useful to get this port >> working well? I might >> > > > be interested in working on improving it, but first I >> want to make sure >> > > > I have a clear sense of what's been done so far (and >> how stable/not it >> > > > is) and what still remains to be done. >> > > > >> > > > --David >> > > > >> > > > > Hi, >> > > > > >> > > > > I have a rather rough port of FreeBSD current on arm >> to Jetson TK1. I >> > > > > used Stephen Warren's tegra u-boot sources, which >> initialize and >> > configure >> > > > > USB and PCIe. >> > > > > >> > > > > So SMP, USB and the onboard PCIe Ethernet adapter >> work. >> > > > > >> > > > > After Ian's changes to busdma_machdep-v6 (r269212) I >> had problems with >> > > > > cache coherency with the Ethernet adapter. Seems thi= s >> is due to the >> > aggressive >> > > > > L2 prefetcher of Cortex A15. Disabling L2 prefetch >> does help, as well as >> > > > > invalidating the cache a second time after the dma >> transfer. I'm not >> > > > > sure what the correct solution to this problem is. I >> wonder how >> > > > > other Cortex A15 platforms (exynos5) handle this. >> > > > > >> > > > > I will probably be able to do some cleanups and put >> patches on the web >> > > > > within a week. >> > > > > >> > > > > Regards >> > > > > >> > > > > Juergen >> > > > > >> > > > > Juergen Weiss |Universitaet Mainz, Zentrum fuer >> Datenverarbeitung, >> > > > > weiss at uni-mainz.de >> > >> > > |55099 >> > >> > > > Mainz, Tel: +49(6131)39-26361 >> >> > , FAX: +49(6131)39 >> - >> > > 26407 >> > >> > > > > >> > > > > >/ -----Original Message----- >> > > > > />/ From:owner-freebsd-arm at freebsd.org >> > > > >> [mailto:owner- >> > freebsd-arm >> > > at >> > > > freebsd.org < >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm>] On >> > Behalf Of >> > > > > />/ Ian Lepore >> > > > > />/ Sent: Sunday, September 21, 2014 3:44 PM >> > > > > />/ To: Lundberg, Johannes >> > > > > />/ Cc:freebsd-arm at freebsd.org >> > > > > > > arm> >> > > > > />/ Subject: Re: Jetson TK1 board support >> > > > > />/ >> > > > > />/ On Sun, 2014-09-21 at 16:45 +0900, Lundberg, >> Johannes wrote: >> > > > > />/ > Great! >> > > > > />/ > >> > > > > />/ > What I've done so far is >> > > > > />/ > >> > > > > />/ > - build and patch (enable API) u-boot-nvidia >> on freebsd (i think i >> > got it >> > > > > />/ > fromgit:// >> nv-tegra.nvidia.com/3rdparty/u-boot.git, the normal u- >> > boot >> > > > > />/ > wouldn't work...) >> > > > > />/ > - flash u-boot-dtb-tegra.img onto the board's >> mmc using nvidia's >> > flash >> > > tool >> > > > > />/ > on ubuntu >> > > > > />/ > - build an image using crochet and dd to sd >> card (so far I copied >> > the >> > > > > />/ > beaglebone setup, just to get a ubldr and a >> kernel file) >> > > > > />/ > >> > > > > />/ > >> > > > > />/ > From u-boot I can see all devices. I load >> ubldr with >> > > > > />/ > fatload mmc 1:1 0x80200000 ubldr >> > > > > />/ > bootelf 0x80200000 >> > > > > />/ > >> > > > > />/ > ubldr load fine but, from ubldr I can only se= e >> the mmc 0 and net >> > devices. >> > > > > />/ > There's no sd card (mmc 1), and no ufs >> partition.. >> > > > > />/ > >> > > > > />/ > >> > > > > />/ > >> > > > > />/ > >> > > > > />/ > -- >> > > > > />/ > Johannes Lundberg >> > > > > />/ > BRILLIANTSERVICE CO., LTD. >> > > > > />/ > >> > > > > />/ > On Fri, Sep 19, 2014 at 8:25 PM, John Howie >> > > > > > >> wrote: >> > > > > />/ > >> > > > > />/ > > Hi all, >> > > > > />/ > > >> > > > > />/ > > I am up for testing and supporting this >> board. I ordered and >> > received >> > > > > />/ > > mine, but have not really had a chance to >> use it due to work to- >> > date. >> > > The >> > > > > />/ > > good news is the next few months I will hav= e >> bandwidth. >> > > > > />/ > > >> > > > > />/ > > Regards, >> > > > > />/ > > >> > > > > />/ > > John >> > > > > />/ > > >> > > > > />/ > > >> > > > > />/ > > On 9/19/14, 12:15 PM, "Lundberg, Johannes" >> > > > > />/ > > > > > > > >> wrote: >> > > > > />/ > > >> > > > > />/ > > >Hi >> > > > > />/ > > > >> > > > > />/ > > >I started working on adding the Jetson TK1 >> board to Crochet. Is >> > there >> > > any >> > > > > />/ > > >work in progress on this? >> > > > > />/ > > >I guess there is quite a lot of work that >> has to been done to >> > get full >> > > > > />/ > > >support for it in the kernel as well.. >> > > > > />/ > > > >> > > > > />/ > > >Best regards >> > > > > />/ > > >-- >> > > > > />/ > > >Johannes Lundberg >> > > > > />/ > > > >> > > > > />/ >> > > > > />/ You may have to change some u-boot options to >> support multiple >> > mmc/sd >> > > > > />/ interfaces. Look in the config header for >> > CONFIG_SYS_MMC_MAX_DEVICE; if >> > > > > />/ it's not there you may need to add it. For >> wandboard I also had to >> > add >> > > > > />/ a freescale-specific one, >> CONFIG_SYS_FSL_USDHC_NUM, so there may be >> > > > > />/ something like that you need to find as well. >> > > > > />/ >> > > > > />/ -- Ian >> > > > > />/ >> > > > > />/ >> > > > > />/ _______________________________________________ >> > > > > />/ freebsd-arm at freebsd.org >> > > >> > > > mailing list >> > > > > />/ >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> > > > > />/ To unsubscribe, send any mail to >> "freebsd-arm-unsubscribe at >> > freebsd.org >> > > > > >"/ >> > > > _______________________________________________ >> > > > freebsd-arm@freebsd.org mailing list >> > > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> > > > To unsubscribe, send any mail to " >> freebsd-arm-unsubscribe@freebsd.org" >> > > >> > > >> > >> > >> > >> >> > From owner-freebsd-arm@FreeBSD.ORG Fri Nov 21 00:08:41 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3ED36326 for ; Fri, 21 Nov 2014 00:08:41 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F2E9723B for ; Fri, 21 Nov 2014 00:08:40 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Xrbly-0004Uo-Gz for freebsd-arm@freebsd.org; Fri, 21 Nov 2014 01:08:32 +0100 Content-Type: multipart/mixed; boundary=----------lHujyQQGqdnquNiu09LRct To: freebsd-arm@freebsd.org Subject: Re: re: dovecot panic References: <20141119123514.rxv2b9ogorkg8kgo@webmail.FoxValley.net> Date: Fri, 21 Nov 2014 01:08:25 +0100 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: In-Reply-To: <20141119123514.rxv2b9ogorkg8kgo@webmail.FoxValley.net> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: b76837ecbba1170f708de966edddc2d0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 00:08:41 -0000 ------------lHujyQQGqdnquNiu09LRct Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Wed, 19 Nov 2014 19:35:14 +0100, wrote: > Hi, Ronald. My build version is r274416. I don't know if dovecot is > directly causing the panic but it seems to be related. I have been > using this build heavily for about a week now (including lots of > compiling) and haven't had any panics. I installed dovecot and got two > in a row, both during a telnet session to port 110 (talking to > dovecot). The first time I got as far as (USER xxx, PASS xxx, LIST). > The second time I got as far as (USER xxx, PASS xxx, LIST, RETR 1, RETR > 2, QUIT). > > I'll try "vm.pmap.sp_enabled=0" this evening. Have you tested dovecot2 > very much? What did you have to do to get it to load successfully? > There were a few configuration changes required for dovecot before it > would start. My dovecot.conf is in the attachment (if the mailinglist accepts it.) I copy this around since some time and I saw that the current default config uses include files so my configuration might be old-fashioned. I just installed dovecot2 on ARM this week and had it running on amd64 for the last two years. Before I was already running it on ARM for quite some time. Also STARTTLS for IMAP does not work anymore. I did not have the time to look into that yet. I did not use POP3, so that configuration might not work. NB: just for the record. I have this ARM Sheevaplug running postfix+dovecot2+spamassassing+mailman for a low-traffic mailinglist and some old low-traffic mailboxes. Another Sheevaplug runs collectd5+rrdtool for collecting statistics from my ADSL-router and the other computers in my network. Regards, Ronald. ------------lHujyQQGqdnquNiu09LRct Content-Disposition: attachment; filename=dovecot.conf Content-Type: application/octet-stream; name=dovecot.conf Content-Transfer-Encoding: Base64 IyBJZiB5b3UncmUgaW4gYSBodXJyeSwgc2VlIGh0dHA6Ly93aWtpLmRvdmVjb3Qu b3JnL1F1aWNrQ29uZmlndXJhdGlvbgoKbGlzdGVuID0gKgojbW1hcF9kaXNhYmxl ID0geWVzCnByb3RvY29scyA9IGltYXAgcG9wMwojIG1hbmFnZXNpZXZlCmRpc2Fi bGVfcGxhaW50ZXh0X2F1dGggPSBubwpsb2dfdGltZXN0YW1wID0gIiVZLSVtLSVk ICVIOiVNOiVTICIKI3NzbF9kaXNhYmxlID0gbm8Kc3NsX2NlcnQgPSA8L2V0Yy9z c2wvY2VydHMvZG92ZWNvdC5wZW0Kc3NsX2tleSA9IDwvZXRjL3NzbC9wcml2YXRl L2RvdmVjb3QucGVtCnNzbF9jaXBoZXJfbGlzdCA9IEFMTDohTE9XOiFTU0x2MjpB TEw6IWFOVUxMOiFBREg6IWVOVUxMOiFFWFA6UkM0K1JTQTorSElHSDorTUVESVVN Cm1haWxfbG9jYXRpb24gPSBtYWlsZGlyOn4vTWFpbGRpcgptYWlsX3ByaXZpbGVn ZWRfZ3JvdXAgPSBtYWlsCnByb3RvY29sIGltYXAgewogIG1haWxfbWF4X3VzZXJp cF9jb25uZWN0aW9ucyA9IDEwCiMgIGxvZ2luX2dyZWV0aW5nX2NhcGFiaWxpdHkg PSB5ZXMKICBpbWFwX2NsaWVudF93b3JrYXJvdW5kcyA9IGRlbGF5LW5ld21haWwK fQpwcm90b2NvbCBwb3AzIHsKICBwb3AzX3VpZGxfZm9ybWF0ID0gJTA4WHUlMDhY dgogIG1haWxfbWF4X3VzZXJpcF9jb25uZWN0aW9ucyA9IDMKICBwb3AzX2NsaWVu dF93b3JrYXJvdW5kcyA9IG91dGxvb2stbm8tbnVscyBvZS1ucy1lb2gKfQojcHJv dG9jb2wgbWFuYWdlc2lldmUgewojICBzaWV2ZT1+Ly5kb3ZlY290LnNpZXZlCiMg IHNpZXZlX3N0b3JhZ2U9fi9zaWV2ZQojfQpwcm90b2NvbCBsZGEgewogIHBvc3Rt YXN0ZXJfYWRkcmVzcyA9IHBvc3RtYXN0ZXIKICBtYWlsX3BsdWdpbnMgPSBjbXVz aWV2ZQogIHF1b3RhX2Z1bGxfdGVtcGZhaWwgPSB5ZXMKICBkZWxpdmVyX2xvZ19m b3JtYXQgPSBtc2dpZD0lbTogJSQKICByZWplY3Rpb25fcmVhc29uID0gWW91ciBt ZXNzYWdlIHRvIDwldD4gd2FzIGF1dG9tYXRpY2FsbHkgcmVqZWN0ZWQ6JW4lcgp9 CmF1dGhfdXNlcm5hbWVfY2hhcnMgPSBhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5 ekFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaMDEyMzQ1Njc4OTAuLV9ACmF1dGhf bWVjaGFuaXNtcyA9IHBsYWluIGxvZ2luCnBhc3NkYiB7CiAgYXJncyA9IC9kYXRh L3ZtYWlsL3Bhc3N3ZAogIGRyaXZlciA9IHBhc3N3ZC1maWxlCn0KCnVzZXJkYiB7 CiAgYXJncyA9IHVpZD01MDAgZ2lkPTYxIGhvbWU9L2RhdGEvdm1haWwvJWQvdXNl cnMvJW4KICBkcml2ZXIgPSBzdGF0aWMKfQoKc2VydmljZSBhdXRoIHsKICB1bml4 X2xpc3RlbmVyIHsKICAgIHBhdGggPSAvdmFyL3Nwb29sL3Bvc3RmaXgvcHJpdmF0 ZS9kb3ZlY290LWF1dGgKICAgIG1vZGUgPSAwNjYwCiAgICB1c2VyID0gcG9zdGZp eAogICAgZ3JvdXAgPSBwb3N0Zml4CiAgfQogIHVzZXIgPSByb290CiAgbmFtZSA9 IGF1dGgKfQoKZGljdCB7Cn0KCnBsdWdpbiB7Cn0K ------------lHujyQQGqdnquNiu09LRct-- From owner-freebsd-arm@FreeBSD.ORG Fri Nov 21 00:14:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76E233C3; Fri, 21 Nov 2014 00:14:25 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1DA0C31C; Fri, 21 Nov 2014 00:14:24 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Xrbrd-0005mq-5K; Fri, 21 Nov 2014 01:14:22 +0100 Content-Type: multipart/mixed; boundary=----------JxeXu0Csk7rvM8RhMGHkI1 To: "Konstantin Belousov" , "Ian Lepore" Subject: Re: panic in nfs on arm References: <1388627434.7506173.1414279273153.JavaMail.root@uoguelph.ca> <20141026075720.GO1877@kib.kiev.ua> <1414335557.12052.672.camel@revolution.hippie.lan> Date: Fri, 21 Nov 2014 01:14:16 +0100 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: In-Reply-To: <1414335557.12052.672.camel@revolution.hippie.lan> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.3.2 X-Scan-Signature: e919acc199487664c4b881d73fbb3695 Cc: freebsd-fs@freebsd.org, freebsd-arm@freebsd.org, Rick Macklem X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 00:14:25 -0000 ------------JxeXu0Csk7rvM8RhMGHkI1 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Sun, 26 Oct 2014 15:59:17 +0100, Ian Lepore wrote: > On Sun, 2014-10-26 at 09:57 +0200, Konstantin Belousov wrote: >> On Sat, Oct 25, 2014 at 07:21:13PM -0400, Rick Macklem wrote: >> > Ronald Klop wrote: >> > > Hi, >> > > >> > > I got a panic on my arm computer while building a port with >> > > /usr/ports >> > > mounted from my FreeBSD-10-STABLE/amd64 machine. >> > > >> > > This is the machine which paniced: >> > > FreeBSD 11.0-CURRENT #1 r272028M: Tue Sep 23 17:11:45 CEST 2014 >> > > root@sjakie.klop.ws:/usr/obj-arm/arm.arm/usr/src-arm/sys/SHEEVAPLUG >> > > arm >> > > >> > > >> > > Tracing pid 90295 tid 100119 td 0xc5f8c960 >> > > db_trace_self() at db_trace_self >> > > pc = 0xc0bb12c8 lr = 0xc0bb1354 (db_trace_thread+0x50) >> > > sp = 0xdf29e5d0 fp = 0xc3e07120 >> > > db_trace_thread() at db_trace_thread+0x50 >> > > pc = 0xc0bb1354 lr = 0xc0936314 (db_command_init+0x5a4) >> > > sp = 0xdf29e630 fp = 0xc3e07120 >> > > db_command_init() at db_command_init+0x5a4 >> > > pc = 0xc0936314 lr = 0xc0935ad0 (db_skip_to_eol+0x484) >> > > sp = 0xdf29e648 fp = 0xc3e07120 >> > > r4 = 0xc0c8d350 r5 = 0x00000000 >> > > db_skip_to_eol() at db_skip_to_eol+0x484 >> > > pc = 0xc0935ad0 lr = 0xc0935c38 (db_command_loop+0x5c) >> > > sp = 0xdf29e6e8 fp = 0xc3e07120 >> > > r4 = 0xdf29e6fc r5 = 0xc0c8d64c >> > > r6 = 0x3cd90e75 r7 = 0x00000000 >> > > r8 = 0x00000001 r10 = 0x600000d3 >> > > db_command_loop() at db_command_loop+0x5c >> > > pc = 0xc0935c38 lr = 0xc0937f80 (X_db_sym_numargs+0xec) >> > > sp = 0xdf29e6f0 fp = 0xc3e07120 >> > > X_db_sym_numargs() at X_db_sym_numargs+0xec >> > > pc = 0xc0937f80 lr = 0xc0a6f0c0 (kdb_trap+0x94) >> > > sp = 0xdf29e808 fp = 0xc3e07120 >> > > r4 = 0xdf29e8f8 >> > > kdb_trap() at kdb_trap+0x94 >> > > pc = 0xc0a6f0c0 lr = 0xc0bc1d60 (badaddr_read+0x274) >> > > sp = 0xdf29e828 fp = 0xc3e07120 >> > > r4 = 0xdf29e8f8 r5 = 0x00000001 >> > > r6 = 0x3cd90e75 r7 = 0xc5f8c960 >> > > r8 = 0xdf29e8f8 r10 = 0xdf2a1eb0 >> > > badaddr_read() at badaddr_read+0x274 >> > > pc = 0xc0bc1d60 lr = 0xc0bc1e98 (badaddr_read+0x3ac) >> > > sp = 0xdf29e840 fp = 0xc3e07120 >> > > r4 = 0xc5f8c960 r5 = 0xdf29e8f8 >> > > r6 = 0x3cd90e05 >> > > badaddr_read() at badaddr_read+0x3ac >> > > pc = 0xc0bc1e98 lr = 0xc0bc2278 >> (data_abort_handler+0x10c) >> > > sp = 0xdf29e858 fp = 0xc3e07120 >> > > r4 = 0xc0cd8af8 r5 = 0xffff1004 >> > > data_abort_handler() at data_abort_handler+0x10c >> > > pc = 0xc0bc2278 lr = 0xc0bb2f40 (exception_exit) >> > > sp = 0xdf29e8f8 fp = 0xc3e07120 >> > > r4 = 0xffffffff r5 = 0xffff1004 >> > > r6 = 0x3cd90e05 r7 = 0xc0e0ea48 >> > > r8 = 0x0000000f r9 = 0x00000101 >> > > r10 = 0x0000001d >> > > exception_exit() at exception_exit >> > > pc = 0xc0bb2f40 lr = 0xc0b8daf8 (uma_reclaim+0x1f8) >> > > sp = 0xdf29e948 fp = 0xc3e07120 >> > > r0 = 0xba9b9127 r1 = 0x8b3de5fb >> > > r2 = 0xc61c1fc8 r3 = 0xba9b9126 >> > > r4 = 0x00000000 r5 = 0xc61c1fc8 >> > > r6 = 0x3cd90e05 r7 = 0xc0e0ea48 >> > > r8 = 0x0000000f r9 = 0x00000101 >> > > r10 = 0x0000001d r12 = 0x00000000 >> > > uma_reclaim() at uma_reclaim+0x24c >> > This looks to me like a crash in uma_reclaim() and I find UMA >> > way too obscure to understand. >> > >> > I have no idea if it might be related, but alc@ put a fix for low >> > memory situations in r272071 (or maybe it's r272221?). >> > >> > Might be worth trying a slightly newer kernel to see if the >> > problem still occurs. >> > >> > And hopefully someone more conversant with UMA (or this stack >> > trace) can help more. >> > >> > rick >> > >> > > pc = 0xc0b8db4c lr = 0xc0b8c800 (uma_zalloc_arg+0x2f0) >> > > sp = 0xdf29e978 fp = 0xdf29ec10 >> > > r4 = 0xc3e071d8 r5 = 0xc0e0ea00 >> > > r6 = 0xc3e07120 r7 = 0x00000000 >> > > r8 = 0x00000102 r9 = 0xdf29ecf8 >> > > r10 = 0xc61c0760 >> > > uma_zalloc_arg() at uma_zalloc_arg+0x2f0 >> uma_reclaim() is not called from uma_zalloc(). >> I think there is some issue with ddb on arm, which means that >> the backtrace is not useful. See below for one more. >> > > pc = 0xc0b8c800 lr = 0xc09e1df0 (nfscl_nget+0x308) >> > > sp = 0xdf29e990 fp = 0xdf29ec10 >> > > r4 = 0x9bb9fa43 r5 = 0x00000000 >> > > r6 = 0xc550dce8 r7 = 0xc3edaa00 >> > > r8 = 0xc3ebbac0 >> > > nfscl_nget() at nfscl_nget+0x308 >> > > pc = 0xc09e1df0 lr = 0xc09da69c (ncl_readlinkrpc+0xf60) >> > > sp = 0xdf29e9d8 fp = 0xdf29ea10 >> > > r4 = 0xc550dce8 r5 = 0x00000000 >> > > r6 = 0xc550dcf8 r7 = 0xdf29ecf8 >> > > r8 = 0xdf29ec6c r9 = 0x00000000 >> > > r10 = 0xdf29ed28 >> > > ncl_readlinkrpc() at ncl_readlinkrpc+0xf60 >> > > pc = 0xc09da69c lr = 0xc0bdae44 (VOP_MKDIR_APV+0x94) >> > > sp = 0xdf29ec40 fp = 0xbffff620 >> > > r4 = 0xc0c95c68 r5 = 0xdf29ec6c >> > > r6 = 0x00000001 r7 = 0x00020284 >> > > r8 = 0xffffff9c r9 = 0x00200800 >> > > r10 = 0xc5f8c960 >> > > VOP_MKDIR_APV() at VOP_MKDIR_APV+0x94 >> I do not see how VOP_MKDIR() may end up calling ncl_readlinkrpc(), >> esp. without intervening frame. >> > > Notice that the address is actually ncl_readlinkrpc+0xf60, 0xf60 is a > pretty big offset into a function, it's probably in some static function > that follows ncl_readlinkrpc in the source file but the symbol info has > been stripped. Using addr2line on the pc and lr values will give > reliable source line numbers (but I can't do that without Ronald's > kernel config). > > -- Ian Sorry for the late reply and I don't know if it is very interesting (or high prio) still. Attached my kernel config and the diff of my source tree. Ronald. > > > >> > > pc = 0xc0bdae44 lr = 0xc0aca614 (kern_mkdirat+0x18c) >> > > sp = 0xdf29ec50 fp = 0xbffff620 >> > > r4 = 0xdf29ed28 r5 = 0xdf29ec90 >> > > r6 = 0x00000000 >> > > kern_mkdirat() at kern_mkdirat+0x18c >> > > pc = 0xc0aca614 lr = 0xc0aca684 (kern_mkdir+0x24) >> > > sp = 0xdf29ede0 fp = 0xbffff620 >> > > r4 = 0x00020290 r5 = 0xc5f8c960 >> > > r6 = 0x00000000 r7 = 0xc5f7f000 >> > > r8 = 0x00000000 r10 = 0x00013640 >> > > kern_mkdir() at kern_mkdir+0x24 >> > > pc = 0xc0aca684 lr = 0xc0aca6a8 (sys_mkdir+0x1c) >> > > sp = 0xdf29edf0 fp = 0xbffff620 >> > > sys_mkdir() at sys_mkdir+0x1c >> > > pc = 0xc0aca6a8 lr = 0xc0bc2884 (swi_handler+0x254) >> > > sp = 0xdf29edf8 fp = 0xbffff620 >> > > swi_handler() at swi_handler+0x254 >> > > pc = 0xc0bc2884 lr = 0xc0bb2ed0 (swi_exit) >> > > sp = 0xdf29ee60 fp = 0xbffff620 >> > > r4 = 0x00020290 r5 = 0x2085e8e0 >> > > r6 = 0x00020284 r7 = 0x00000088 >> > > r8 = 0x00000001 >> > > swi_exit() at swi_exit >> > > pc = 0xc0bb2ed0 lr = 0xc0bb2ed0 (swi_exit) >> > > sp = 0xdf29ee60 fp = 0xbffff620 >> > > Unable to unwind further >> > > >> > > >> > > Unfortunately dumping the kernel core also paniced. >> > > db> dump >> > > Physical memory: 507 MB >> > > Dumping 74 MB: 71 67 63 >> > > vm_fault(0xc4147000, 0, 1, 0) -> 0 >> > > Fatal kernel mode data abort: 'Translation Fault (P)' >> > > trapframe: 0xdf29e0b8 >> > > FSR=00000017, FAR=00000014, spsr=a00000d3 >> > > r0 =c0cd0f40, r1 =00000000, r2 =c5f8c960, r3 =00000004 >> > > r4 =00000000, r5 =00000000, r6 =00000000, r7 =c3ead01c >> > > r8 =c3ead000, r9 =c3e9e88c, r10=00000000, r11=0000000a >> > > r12=600000d3, ssp=df29e108, slr=c0bb4e24, pc =c0a7d060 >> > > >> > > panic: Fatal abort >> > > Uptime: 3d18h30m32s >> > > Sleeping thread (tid 100119, pid 90295) owns a non-sleepable lock > > > _______________________________________________ > 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" ------------JxeXu0Csk7rvM8RhMGHkI1 Content-Disposition: attachment; filename=SHEEVAPLUG Content-Type: application/octet-stream; name=SHEEVAPLUG Content-Transfer-Encoding: Base64 IwojIEN1c3RvbSBrZXJuZWwgZm9yIE1hcnZlbGwgU2hlZXZhUGx1ZyBkZXZpY2Vz LgojCiMgJEZyZWVCU0Q6IGhlYWQvc3lzL2FybS9jb25mL1NIRUVWQVBMVUcgMjYz MzAxIDIwMTQtMDMtMTggMTQ6NDE6MThaIGltcCAkCiMKCmlkZW50CQlTSEVFVkFQ TFVHCmluY2x1ZGUJCSIuLi9tdi9raXJrd29vZC9zdGQuZGI4OGY2eHh4IgoKb3B0 aW9ucyAJU09DX01WX0tJUktXT09ECm1ha2VvcHRpb25zCU1PRFVMRVNfT1ZFUlJJ REU9IiIKCm1ha2VvcHRpb25zCURFQlVHPS1nCQkjIEJ1aWxkIGtlcm5lbCB3aXRo IGdkYigxKSBkZWJ1ZyBzeW1ib2xzCiNvcHRpb25zCQlJTlZBUklBTlRTCiNvcHRp b25zCQlJTlZBUklBTlRfU1VQUE9SVAojb3B0aW9ucwkJV0lUTkVTUwojb3B0aW9u cwkJREVCVUdfTE9DS1MKI29wdGlvbnMJCURFQlVHX1ZGU19MT0NLUwojb3B0aW9u cwkJRElBR05PU1RJQwptYWtlb3B0aW9ucwlXRVJST1I9Ii1XZXJyb3IiCm9wdGlv biBLU1RBQ0tfUEFHRVM9NQpvcHRpb24gQVJNX0RFVklDRV9NVUxUSVBBU1MKCm9w dGlvbnMgCVNDSEVEXzRCU0QJCSMgNEJTRCBzY2hlZHVsZXIKb3B0aW9ucyAJSU5F VAkJCSMgSW50ZXJORVR3b3JraW5nCiNvcHRpb25zIAlJTkVUNgkJCSMgSVB2NiBj b21tdW5pY2F0aW9ucyBwcm90b2NvbHMKb3B0aW9ucyAJR0VPTV9QQVJUX0JTRAkJ IyBCU0QgcGFydGl0aW9uIHNjaGVtZQpvcHRpb25zIAlHRU9NX1BBUlRfTUJSCQkj IE1CUiBwYXJ0aXRpb24gc2NoZW1lCm9wdGlvbnMgCVRNUEZTCQkJIyBFZmZpY2ll bnQgbWVtb3J5IGZpbGVzeXN0ZW0Kb3B0aW9ucyAJRkZTCQkJIyBCZXJrZWxleSBG YXN0IEZpbGVzeXN0ZW0Kb3B0aW9ucyAJTkFOREZTCQkJIyBOQU5EIEZpbGVzeXN0 ZW0Kb3B0aW9ucyAJTkZTQ0wJCQkjIE5ldyBOZXR3b3JrIEZpbGVzeXN0ZW0gQ2xp ZW50Cm9wdGlvbnMgCU5GU0xPQ0tECQkjIE5ldHdvcmsgTG9jayBNYW5hZ2VyCiNv cHRpb25zIAlORlNfUk9PVAkJIyBORlMgdXNhYmxlIGFzIC8sIHJlcXVpcmVzIE5G U0NMCiNvcHRpb25zIAlCT09UUAojb3B0aW9ucyAJQk9PVFBfTkZTUk9PVAojb3B0 aW9ucyAJQk9PVFBfTkZTVjMKI29wdGlvbnMgCUJPT1RQX1dJUkVEX1RPPW1nZTAK IyBBZGRlZCBieSBSb25hbGQKb3B0aW9ucyAJU09GVFVQREFURVMKb3B0aW9ucyAJ TVNET1NGUwpvcHRpb25zIAlJUEZJUkVXQUxMCm9wdGlvbnMgCUlQRklSRVdBTExf REVGQVVMVF9UT19BQ0NFUFQKCiMgUm9vdCBmcyBvbiBVU0IgZGV2aWNlCm9wdGlv bnMgCVJPT1RERVZOQU1FPVwidWZzOi9kZXYvZGEwczFhXCIKI29wdGlvbnMgCVJP T1RERVZOQU1FPVwidWZzOi9kZXYvZGEwczJkXCIKI29wdGlvbnMgCVJPT1RERVZO QU1FPVwibmFuZGZzOi9kZXYvZGEwczJkXCIKI29wdGlvbnMgCVJPT1RERVZOQU1F PVwibmFuZGZzOi9kZXYvZ25hbmQwcy5yb290XCIKCm9wdGlvbnMgCVNZU1ZTSE0J CQkjIFNZU1Ytc3R5bGUgc2hhcmVkIG1lbW9yeQpvcHRpb25zIAlTWVNWTVNHCQkJ IyBTWVNWLXN0eWxlIG1lc3NhZ2UgcXVldWVzCm9wdGlvbnMgCVNZU1ZTRU0JCQkj IFNZU1Ytc3R5bGUgc2VtYXBob3JlcwpvcHRpb25zIAlfS1BPU0lYX1BSSU9SSVRZ X1NDSEVEVUxJTkcgIyBQb3NpeCBQMTAwM18xQiByZWFsLXRpbWUgZXh0ZW5zaW9u cwpvcHRpb25zIAlNVVRFWF9OT0lOTElORQpvcHRpb25zIAlSV0xPQ0tfTk9JTkxJ TkUKb3B0aW9ucyAJTk9fRkZTX1NOQVBTSE9UCm9wdGlvbnMgCU5PX1NXQVBQSU5H CgojIERlYnVnZ2luZwpvcHRpb25zIAlBTFRfQlJFQUtfVE9fREVCVUdHRVIKb3B0 aW9ucyAJRERCCm9wdGlvbnMgCUtEQgoKIyBQc2V1ZG8gZGV2aWNlcwpkZXZpY2UJ CXJhbmRvbQpkZXZpY2UJCWxvb3AKZGV2aWNlCQltZAoKIyBTZXJpYWwgcG9ydHMK ZGV2aWNlCQl1YXJ0CgojIE5ldHdvcmtpbmcKZGV2aWNlCQlldGhlcgpkZXZpY2UJ CW1nZQkJCSMgTWFydmVsbCBHaWdhYml0IEV0aGVybmV0IGNvbnRyb2xsZXIKZGV2 aWNlCQltaWkKZGV2aWNlCQllMTAwMHBoeQpkZXZpY2UJCWJwZgpvcHRpb25zIAlI Wj0xMDAwCm9wdGlvbnMgCURFVklDRV9QT0xMSU5HCmRldmljZQkJdmxhbgoKZGV2 aWNlCQljZXNhCQkJIyBNYXJ2ZWxsIHNlY3VyaXR5IGVuZ2luZQpkZXZpY2UJCWNy eXB0bwpkZXZpY2UJCWNyeXB0b2RldgoKIyBVU0IKb3B0aW9ucyAJVVNCX0RFQlVH CQkjIGVuYWJsZSBkZWJ1ZyBtc2dzCmRldmljZQkJdXNiCmRldmljZQkJZWhjaQpk ZXZpY2UJCXVtYXNzCmRldmljZQkJc2NidXMKZGV2aWNlCQlwYXNzCmRldmljZQkJ ZGEKCiMgTkFORApkZXZpY2UJCW5hbmQKCiNkZXZpY2UgCQltbWMKI2RldmljZSAJ CW1tY3NkCiNkZXZpY2UgCQlzZGhjaQoKIyBGbGF0dGVuZWQgRGV2aWNlIFRyZWUK b3B0aW9ucyAJRkRUCm9wdGlvbnMgCUZEVF9EVEJfU1RBVElDCm1ha2VvcHRpb25z CUZEVF9EVFNfRklMRT1zaGVldmFwbHVnLmR0cwo= ------------JxeXu0Csk7rvM8RhMGHkI1 Content-Disposition: attachment; filename=svn.diff.txt Content-Type: text/plain; name=svn.diff.txt Content-Transfer-Encoding: 7bit Index: sys/arm/conf/SHEEVAPLUG =================================================================== --- sys/arm/conf/SHEEVAPLUG (revision 273634) +++ sys/arm/conf/SHEEVAPLUG (working copy) @@ -10,12 +10,20 @@ options SOC_MV_KIRKWOOD makeoptions MODULES_OVERRIDE="" -#makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols +makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols +#options INVARIANTS +#options INVARIANT_SUPPORT +#options WITNESS +#options DEBUG_LOCKS +#options DEBUG_VFS_LOCKS +#options DIAGNOSTIC makeoptions WERROR="-Werror" +option KSTACK_PAGES=5 +option ARM_DEVICE_MULTIPASS options SCHED_4BSD # 4BSD scheduler options INET # InterNETworking -options INET6 # IPv6 communications protocols +#options INET6 # IPv6 communications protocols options GEOM_PART_BSD # BSD partition scheme options GEOM_PART_MBR # MBR partition scheme options TMPFS # Efficient memory filesystem @@ -23,14 +31,22 @@ options NANDFS # NAND Filesystem options NFSCL # New Network Filesystem Client options NFSLOCKD # Network Lock Manager -options NFS_ROOT # NFS usable as /, requires NFSCL -options BOOTP -options BOOTP_NFSROOT -options BOOTP_NFSV3 -options BOOTP_WIRED_TO=mge0 +#options NFS_ROOT # NFS usable as /, requires NFSCL +#options BOOTP +#options BOOTP_NFSROOT +#options BOOTP_NFSV3 +#options BOOTP_WIRED_TO=mge0 +# Added by Ronald +options SOFTUPDATES +options MSDOSFS +options IPFIREWALL +options IPFIREWALL_DEFAULT_TO_ACCEPT # Root fs on USB device -#options ROOTDEVNAME=\"ufs:/dev/da0a\" +options ROOTDEVNAME=\"ufs:/dev/da0s1a\" +#options ROOTDEVNAME=\"ufs:/dev/da0s2d\" +#options ROOTDEVNAME=\"nandfs:/dev/da0s2d\" +#options ROOTDEVNAME=\"nandfs:/dev/gnand0s.root\" options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues @@ -49,6 +65,7 @@ # Pseudo devices device random device loop +device md # Serial ports device uart @@ -79,6 +96,10 @@ # NAND device nand +#device mmc +#device mmcsd +#device sdhci + # Flattened Device Tree options FDT options FDT_DTB_STATIC Index: sys/boot/fdt/dts/arm/sheevaplug.dts =================================================================== --- sys/boot/fdt/dts/arm/sheevaplug.dts (revision 273634) +++ sys/boot/fdt/dts/arm/sheevaplug.dts (working copy) @@ -95,7 +95,12 @@ }; slice@200000 { - reg = <0x200000 0x1fe00000>; + reg = <0x200000 0x600000>; + label = "fbsd-boot"; + }; + + slice@800000 { + reg = <0x800000 0x1f800000>; label = "root"; }; }; ------------JxeXu0Csk7rvM8RhMGHkI1-- From owner-freebsd-arm@FreeBSD.ORG Fri Nov 21 00:52:03 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4194D9F for ; Fri, 21 Nov 2014 00:52:03 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9D65A936 for ; Fri, 21 Nov 2014 00:52:03 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 5EFA9193964 for ; Fri, 21 Nov 2014 00:52:02 +0000 (UTC) Subject: ARMv6 -- pkg repo build From: Sean Bruno Reply-To: sbruno@freebsd.org To: freebsd-arm Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-0vXZMiO+O68ghcJZO58Y" Date: Thu, 20 Nov 2014 16:52:01 -0800 Message-ID: <1416531121.7423.47.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 00:52:03 -0000 --=-0vXZMiO+O68ghcJZO58Y Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://chips.ysv.freebsd.org/build.html?mastername=3D11armv6-11armv6&build= =3D2014-11-21_00h06m29s I'm making an attempt at ARMv6 packages this week. If you see ports that you know how to fix fail (e.g. bmake or deforas-libsystem) file a bugzilla ticket with your proposed fixes and I'll drive them into the tree. Once this build is done, an ARMv6 package repo will be available on this server for alpha testing while we figure out some mechanical bits to the qemu-emulation I'm using. sean --=-0vXZMiO+O68ghcJZO58Y Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJUboyxXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kaQwIAIb0bEsO0CjasnX4M6hTZSxq +wabxNXGpVi/ASkAu3TVxivRs7zbbAouJ+Oj6N3BlQyA9OyzoEjzl1wpcADvhTh2 g5IWZXgv1gFwYQtxmBLrnFWLrmVJbTbW2hwP1UnZrGspezU+F5QNBr7trGyfTkMg hzgySWpeDF0LY/OcL03QjEJBAI4yovL1C/F7pX/BBYrKOZC6jslpqG1m2+WIVEg4 /7UKdZl4maXZstm3hx1v8i8vnEDlAYyIxBzFDtxzsYiGv9j+waL6PaWcmW4urRkb 98vLEv9xtmcKqbJsW8VoWHq9PhbaM6cOwxppgh5Ma/SW2OOEmcyHPDPquTyyANg= =SRCl -----END PGP SIGNATURE----- --=-0vXZMiO+O68ghcJZO58Y-- From owner-freebsd-arm@FreeBSD.ORG Fri Nov 21 01:19:07 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C72A263; Fri, 21 Nov 2014 01:19:07 +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)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 13B62B2F; Fri, 21 Nov 2014 01:19:06 +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 sAL1J5YR001305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2014 17:19:05 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAL1J571001304; Thu, 20 Nov 2014 17:19:05 -0800 (PST) (envelope-from jmg) Date: Thu, 20 Nov 2014 17:19:05 -0800 From: John-Mark Gurney To: sbruno@freebsd.org Subject: Re: ARMv6 -- pkg repo build Message-ID: <20141121011905.GC99957@funkthat.com> Mail-Followup-To: sbruno@freebsd.org, freebsd-arm References: <1416531121.7423.47.camel@bruno> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1416531121.7423.47.camel@bruno> 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 IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 20 Nov 2014 17:19:06 -0800 (PST) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 01:19:07 -0000 Sean Bruno wrote this message on Thu, Nov 20, 2014 at 16:52 -0800: > http://chips.ysv.freebsd.org/build.html?mastername=11armv6-11armv6&build=2014-11-21_00h06m29s > > I'm making an attempt at ARMv6 packages this week. If you see > ports that you know how to fix fail (e.g. bmake or deforas-libsystem) > file a bugzilla ticket with your proposed fixes and I'll drive them into > the tree. > > Once this build is done, an ARMv6 package repo will be available on > this server for alpha testing while we figure out some mechanical bits > to the qemu-emulation I'm using. re: cuse4bsd failing: a) not sure why cuse4bsd is being built as a port, since it's been integrated into HEAD as cuse.. b) this looks like a mismatch w/ headers, trying to use machine local headers instead of arm's... -- 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 Fri Nov 21 02:33:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E957535 for ; Fri, 21 Nov 2014 02:33:49 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DFD2D2C9 for ; Fri, 21 Nov 2014 02:33:48 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 2719E193964; Fri, 21 Nov 2014 02:33:47 +0000 (UTC) Subject: Re: ARMv6 -- pkg repo build From: Sean Bruno Reply-To: sbruno@freebsd.org To: John-Mark Gurney In-Reply-To: <20141121011905.GC99957@funkthat.com> References: <1416531121.7423.47.camel@bruno> <20141121011905.GC99957@funkthat.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-9k8agoD5S2kwbpmYSgem" Date: Thu, 20 Nov 2014 18:33:44 -0800 Message-ID: <1416537224.7423.49.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 02:33:49 -0000 --=-9k8agoD5S2kwbpmYSgem Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thu, 2014-11-20 at 17:19 -0800, John-Mark Gurney wrote: > Sean Bruno wrote this message on Thu, Nov 20, 2014 at 16:52 -0800: > > http://chips.ysv.freebsd.org/build.html?mastername=3D11armv6-11armv6&bu= ild=3D2014-11-21_00h06m29s > >=20 > > I'm making an attempt at ARMv6 packages this week. If you see > > ports that you know how to fix fail (e.g. bmake or deforas-libsystem) > > file a bugzilla ticket with your proposed fixes and I'll drive them int= o > > the tree. > >=20 > > Once this build is done, an ARMv6 package repo will be available on > > this server for alpha testing while we figure out some mechanical bits > > to the qemu-emulation I'm using. >=20 > re: cuse4bsd failing: >=20 > a) not sure why cuse4bsd is being built as a port, since it's been > integrated into HEAD as cuse.. >=20 Ah, that is odd. I wonder if we've resolved all the dependencies to make ports depend on the base system component? > b) this looks like a mismatch w/ headers, trying to use machine local > headers instead of arm's... >=20 Odd, this is being done in a jail, even with all my hackery, this shouldn't be possible. However, if the build of the arm jail is copying the wrong headers into it in the first place, that's different. sean --=-9k8agoD5S2kwbpmYSgem Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJUbqSIXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kP8cIALaCLsBlgujdT33hBvz5wSJk 9WbdNvOjVPWZjSbWJTWNNYOLZ+ENL+figlu98kGfsm4FKI7VnJfIACY3Xlwyyka1 OCvJYa8cuAjBmrBKIejYqCpRiBUy++UTE5lH7QqEVBMsfiUOSgndsUzXE2s5c8Y3 IgPtR/bIX1d3ZNjSD3gSMnH5Di3dX3E7HnGiQXr9n1zvs+vZ5EUkzNvkVQKuSh+K sJ0xcjgrw2ruGc9kN6JJmvBcJfSVqWmSClTsBCptKrZO9LmeBMiPDBAJa/8cyvkK 2MmsQ5UilT8S82bk0QnH+5d53egZL+RQ+7KxpNNFvHcBc6WIrkuxNa4WXTPZoic= =AgZ1 -----END PGP SIGNATURE----- --=-9k8agoD5S2kwbpmYSgem-- From owner-freebsd-arm@FreeBSD.ORG Fri Nov 21 04:24:55 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EA53C32; Fri, 21 Nov 2014 04:24:55 +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)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B83EF57; Fri, 21 Nov 2014 04:24:54 +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 sAL4OrlJ003087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2014 20:24:53 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAL4Orkl003086; Thu, 20 Nov 2014 20:24:53 -0800 (PST) (envelope-from jmg) Date: Thu, 20 Nov 2014 20:24:53 -0800 From: John-Mark Gurney To: sbruno@freebsd.org Subject: Re: ARMv6 -- pkg repo build Message-ID: <20141121042452.GD99957@funkthat.com> Mail-Followup-To: sbruno@freebsd.org, freebsd-arm References: <1416531121.7423.47.camel@bruno> <20141121011905.GC99957@funkthat.com> <1416537224.7423.49.camel@bruno> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1416537224.7423.49.camel@bruno> 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 IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 20 Nov 2014 20:24:53 -0800 (PST) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 04:24:55 -0000 Sean Bruno wrote this message on Thu, Nov 20, 2014 at 18:33 -0800: > On Thu, 2014-11-20 at 17:19 -0800, John-Mark Gurney wrote: > > Sean Bruno wrote this message on Thu, Nov 20, 2014 at 16:52 -0800: > > > http://chips.ysv.freebsd.org/build.html?mastername=11armv6-11armv6&build=2014-11-21_00h06m29s > > > > > > I'm making an attempt at ARMv6 packages this week. If you see > > > ports that you know how to fix fail (e.g. bmake or deforas-libsystem) > > > file a bugzilla ticket with your proposed fixes and I'll drive them into > > > the tree. > > > > > > Once this build is done, an ARMv6 package repo will be available on > > > this server for alpha testing while we figure out some mechanical bits > > > to the qemu-emulation I'm using. > > > > re: cuse4bsd failing: > > > > a) not sure why cuse4bsd is being built as a port, since it's been > > integrated into HEAD as cuse.. > > > > Ah, that is odd. I wonder if we've resolved all the dependencies to > make ports depend on the base system component? It's only been in head for 5 months, so it's possible that the porters don't know about it yet.. Imported: https://svnweb.freebsd.org/changeset/base/r266581 Enabled w/ version bump (1100023 has cuse): https://svnweb.freebsd.org/changeset/base/r267440 After this I looked at the skipped ports, and there are a handful (30+) that were skipped because of cuse being missing... > > b) this looks like a mismatch w/ headers, trying to use machine local > > headers instead of arm's... > > Odd, this is being done in a jail, even with all my hackery, this > shouldn't be possible. However, if the build of the arm jail is copying > the wrong headers into it in the first place, that's different. Ahh, it's an issue w/ sys/conf/kmod.mk when it builds the machine link... In kmod.mk it does: ${.OBJDIR}/${_link}: @case ${.TARGET:T} in \ machine) \ path=${SYSDIR}/${MACHINE}/include ;; \ So, looks like MACHINE isn't set correctly, or MACHINE isn't what's suppose to be here... Not sure which is correct... -- 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 Fri Nov 21 04:37:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18C96D79 for ; Fri, 21 Nov 2014 04:37:25 +0000 (UTC) Received: from mail.FoxValley.net (mail.FoxValley.net [64.135.192.34]) by mx1.freebsd.org (Postfix) with SMTP id BFFABAF for ; Fri, 21 Nov 2014 04:37:24 +0000 (UTC) Received: (qmail 11441 invoked from network) for freebsd-arm@freebsd.org; 20 Nov 2014 22:37:18 -0600 Received: from 71-211-193-1.hlrn.qwest.net (HELO ?192.168.1.3?) (draymond@71.211.193.1) by mail.foxvalley.net with SMTP; 20 Nov 2014 22:37:17 -0600 Message-ID: <546EC17A.7070601@foxvalley.net> Date: Thu, 20 Nov 2014 21:37:14 -0700 From: Dan Raymond User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: re: dovecot panic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 04:37:25 -0000 I deinstalled dovecot and installed /usr/ports/mail/dovecot2. It took a lot longer to build (100 minutes vs. 35 minutes) and it required more tweaks to get it working but I haven't seen a panic yet. Here are the configuration changes I needed, by the way: cp -R /usr/local/share/doc/dovecot/example-config/* /usr/local/etc/dovecot vi /usr/local/etc/dovecot/dovecot.conf protocols = imap pop3 vi /usr/local/etc/dovecot/conf.d/10-mail.conf mail_location = mbox:~/mail:INBOX=/var/mail/%u mail_privileged_group = mail vi /usr/local/etc/dovecot/conf.d/10-master.conf service imap-login { inet_listener imap { port = 0 } } // note this spans multiple lines service pop3-login { inet_listener pop3 { port = 0 } } // note this spans multiple lines cd /usr/local/share/examples/dovecot vi dovecot-openssl.cnf (fill out fields) mkdir /etc/ssl/certs mkdir /etc/ssl/private ./mkcert.sh From owner-freebsd-arm@FreeBSD.ORG Fri Nov 21 05:06:53 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4012CFC4 for ; Fri, 21 Nov 2014 05:06:53 +0000 (UTC) Received: from mail.FoxValley.net (mail.FoxValley.net [64.135.192.34]) by mx1.freebsd.org (Postfix) with SMTP id E58A2354 for ; Fri, 21 Nov 2014 05:06:52 +0000 (UTC) Received: (qmail 8787 invoked from network) for freebsd-arm@freebsd.org; 20 Nov 2014 23:06:52 -0600 Received: from 71-211-193-1.hlrn.qwest.net (HELO ?192.168.1.3?) (draymond@71.211.193.1) by mail.foxvalley.net with SMTP; 20 Nov 2014 23:06:52 -0600 Message-ID: <546EC869.4030507@foxvalley.net> Date: Thu, 20 Nov 2014 22:06:49 -0700 From: Dan Raymond User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: tcpflow and tcpick Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 05:06:53 -0000 I tried compiling /usr/ports/net/tcpflow and /usr/ports/net/tcpick for ARMv6 on my Raspberry Pi. Tcpflow took around 24 hours to compile and it seems to be working OK. Tcpick took 2 minutes to compile but it doesn't work correctly. When I execute 'tcpick' I get no output: root@raspberry-pi:~ # tcpick important: `man 8 tcpick' explains all options available The same port works fine when I compile and run it inside an x64 virtual machine: root@draymond-bsd:~ # tcpick important: `man 8 tcpick' explains all options available Starting tcpick 0.2.1 at 2014-11-20 20:44 MST Timeout for connections is 600 tcpick: listening on em0 1 SYN-SENT xx.xx.xxx.xxx:54344 > xx.xxx.xx.xx:ssh 1 SYN-RECEIVED xx.xx.xxx.xxx:54344 > xx.xxx.xx.xx:ssh 1 ESTABLISHED xx.xx.xxx.xxx:54344 > xx.xxx.xx.xx:ssh From owner-freebsd-arm@FreeBSD.ORG Fri Nov 21 05:23: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E7931E7 for ; Fri, 21 Nov 2014 05:23:14 +0000 (UTC) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D2F26E0 for ; Fri, 21 Nov 2014 05:23:14 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id bj1so4062562pad.23 for ; Thu, 20 Nov 2014 21:23:13 -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:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=P7UN16Eq1nnF4pA9lhOznHyXr9CsbmxKF8NjIGsuKRY=; b=CAeZcprWkfeKiaQUfe0eVRdCHHJLxgYMZKW9v8etM3tUKExcIi2/6WpQQmwqZo84SZ Igp2YIEZvzS1W15islDN7QmvqaGYiDBG8p7uE7i+ye7cau7/BMkf2Tm8xNZ2GB2iWm5I vs7jqObB2konVK1hEnk/5eGt5m6X2pV9PRm+ttDO3fMuClhOgmUZKcsHZhGeq+APOqCK uiU+6rmXuJXRRQP1VXn2uO5rK375dY8nzQIhVWIGvGxNcxDz3dK4R7QibrZBT2oql35z 1d7OJyO0/ZjZ77yOoxzn4BUeP/1J9GGTX2dXyKoZur1mfT+JABdcrtmRnUArrMz6hjo8 VFNQ== X-Gm-Message-State: ALoCoQn2jY6FfoN5YrWSpV3R1CCxaurDIFQWhLuP3zL/D9cSB+DPnz6QO+rrgnGB0HkaQYNV5tmA X-Received: by 10.66.157.161 with SMTP id wn1mr3629665pab.40.1416547393594; Thu, 20 Nov 2014 21:23:13 -0800 (PST) Received: from [10.64.27.119] ([69.53.236.236]) by mx.google.com with ESMTPSA id ml5sm3592772pab.32.2014.11.20.21.23.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Nov 2014 21:23:12 -0800 (PST) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_A5C918C5-AA0B-4F0D-B43E-64DD3A9FA6F1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: ARMv6 -- pkg repo build From: Warner Losh In-Reply-To: <20141121042452.GD99957@funkthat.com> Date: Thu, 20 Nov 2014 22:23:09 -0700 Message-Id: References: <1416531121.7423.47.camel@bruno> <20141121011905.GC99957@funkthat.com> <1416537224.7423.49.camel@bruno> <20141121042452.GD99957@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 05:23:14 -0000 --Apple-Mail=_A5C918C5-AA0B-4F0D-B43E-64DD3A9FA6F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 20, 2014, at 9:24 PM, John-Mark Gurney wrote: > Sean Bruno wrote this message on Thu, Nov 20, 2014 at 18:33 -0800: >> On Thu, 2014-11-20 at 17:19 -0800, John-Mark Gurney wrote: >>> Sean Bruno wrote this message on Thu, Nov 20, 2014 at 16:52 -0800: >>>> = http://chips.ysv.freebsd.org/build.html?mastername=3D11armv6-11armv6&build= =3D2014-11-21_00h06m29s >>>>=20 >>>> I'm making an attempt at ARMv6 packages this week. If you see >>>> ports that you know how to fix fail (e.g. bmake or = deforas-libsystem) >>>> file a bugzilla ticket with your proposed fixes and I'll drive them = into >>>> the tree. >>>>=20 >>>> Once this build is done, an ARMv6 package repo will be available on >>>> this server for alpha testing while we figure out some mechanical = bits >>>> to the qemu-emulation I'm using. >>>=20 >>> re: cuse4bsd failing: >>>=20 >>> a) not sure why cuse4bsd is being built as a port, since it's been >>> integrated into HEAD as cuse.. >>>=20 >>=20 >> Ah, that is odd. I wonder if we've resolved all the dependencies to >> make ports depend on the base system component? >=20 > It's only been in head for 5 months, so it's possible that the porters > don't know about it yet.. >=20 > Imported: > https://svnweb.freebsd.org/changeset/base/r266581 >=20 > Enabled w/ version bump (1100023 has cuse): > https://svnweb.freebsd.org/changeset/base/r267440 >=20 > After this I looked at the skipped ports, and there are a handful > (30+) that were skipped because of cuse being missing... >=20 >>> b) this looks like a mismatch w/ headers, trying to use machine = local >>> headers instead of arm's... >>=20 >> Odd, this is being done in a jail, even with all my hackery, this >> shouldn't be possible. However, if the build of the arm jail is = copying >> the wrong headers into it in the first place, that's different. >=20 > Ahh, it's an issue w/ sys/conf/kmod.mk when it builds the machine > link... In kmod.mk it does: > ${.OBJDIR}/${_link}: > @case ${.TARGET:T} in \ > machine) \ > path=3D${SYSDIR}/${MACHINE}/include ;; \ >=20 > So, looks like MACHINE isn't set correctly, or MACHINE isn't what's > suppose to be here... Not sure which is correct=85 this is correct. MACHINE should be arm. If it is anything else, then bad = things are going to happen. There=92s safeties to prevent it, but are you sure you=92re saying = TARGET=3Darm TARGET_ARCH=3Darmv6? and not TARGET=3Darmv6? Warner --Apple-Mail=_A5C918C5-AA0B-4F0D-B43E-64DD3A9FA6F1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUbsw9AAoJEGwc0Sh9sBEAHs8P/1JHz+d5JTNHB43B74uSdVZB 14gwsOh1z8bUCPT9mt2k8b8t1HphmW4D8kZi3xoc8OE0gUFNVG9ate2mLQbyuLL0 KRY0VKUESnnsxCvf/Z9mDq+MWw7g86V7uQIkJ1xg4tv3fWyjnmILSluq24o5ght1 r8OQ+04QXsAFS8+t29iYs6iY3u3JEtJ53NHau9jfdsmCwpFG4naVpwcSTVWvZbwx GHDG6USYIHLwQkwKN+bzJM9Vbh2RB5ChZ+sCjEmP17UoR+oJuBKk0lAwQw5MwP18 wIYx9QVsRlvd5zamMlS5q+morS8Kh/hdwUodQ5xqHyuESoth0iNvP2EmnCgBWLOR OHtWrYvB6zS2+GyxpMhVpVvrQpXD/+udHS/soORcyvwiKXZOU9ekx5IJP+wVbeni iekMk+Ht92y7e+WWJVFyWHypj1Mlkb1B3tNxJzh/PuLWjt7vs6vjmDYES39yqCa5 ofHuM4Yu6LJatTpSZXsc2630/k6rIkyCo3SRp+iP76Si29/ZEEdsKz5c26ke0W5+ 3laZV6uR40KmvihFr1jvltkyK9+yjoAHzVd8msnfLRZlqwukDTmd/9uqA2rxDvdC GlejRa500e+dpMgm9l+N8kk0By4X+lmd+T38nn2bPL3IlMVSA9fnLwoRC85dMYgZ UhppvrhjCxEWAQLqKFpL =5G9Q -----END PGP SIGNATURE----- --Apple-Mail=_A5C918C5-AA0B-4F0D-B43E-64DD3A9FA6F1-- From owner-freebsd-arm@FreeBSD.ORG Fri Nov 21 11:00:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 852FBF50 for ; Fri, 21 Nov 2014 11:00:08 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::5]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E5A7DDBD for ; Fri, 21 Nov 2014 11:00:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1416567583; l=11918; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Subject:Cc:To:From:Date; bh=YoJHvbnEFnJ8kKkAfvQrUFdDmHc=; b=mQiBI33CoNWuLL8CM215p0YUHL0/YNrpKXrBtnXvd6GdE1sNKLrXaQUGUrMDRUf2avJ x08rbuanNrhRGl1w4vd+COCFQsikO9KUuynd+39HtfdUkDZj5ktp16uYMnqd+mbcsb8Cq 2R66bOSP/EZxki5V+5khd0jXV3npz88/GtQ= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg4+v8v/rJ76 X-RZG-CLASS-ID: mo00 Received: from bbu (p5486A782.dip0.t-ipconnect.de [84.134.167.130]) by smtp.strato.de (RZmta 35.13 DYNA|AUTH) with ESMTPSA id Z0438aqALAxh1Hd (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate); Fri, 21 Nov 2014 11:59:43 +0100 (CET) Date: Fri, 21 Nov 2014 11:59:41 +0100 From: Ulrich Grey To: Svatopluk Kraus Subject: Re: Wandboard-Quad crashes Message-Id: <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> In-Reply-To: References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> Organization: - X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; armv6-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 11:00:08 -0000 Now it works! I have cloned the source tree from here: https://github.com/strejda/freebsd With crochet I have compiled an Image for Wandboard-Quad. This Image started without problems. To use the new pmap I had to add: options ARM_NEW_PMAP to the file src/sys/arm/conf/IMX6 and to recompile the kernel. This kernel was not bootable, it crashes immediately. I had to add options NKPT2PG=64 (advice from Svatopluk Kraus)* to the kernel config file and recompile. This time the kernel booted without problems. root@quad:/usr/src # uname -a FreeBSD quad 11.0-CURRENT FreeBSD 11.0-CURRENT #2 751adfd (master)-dirty: Thu Nov 20 23:41:14 UTC 2014 gwgpi@quad:/usr/local/DEVEL/obj/usr/local/DEVEL/STREJDA/freebsd/sys/WANDBOARD-QUAD arm root@quad:/usr/src # sysctl vm.pmap. vm.pmap.pv_entry_max: 1744848 vm.pmap.shpgperproc: 200 vm.pmap.nkpt2pg: 64 vm.pmap.sp_enabled: 1 vm.pmap.pte1.demotions: 146 vm.pmap.pte1.mappings: 0 vm.pmap.pte1.p_failures: 8089 vm.pmap.pte1.promotions: 2815 vm.pmap.pv_entry_count: 65363 vm.pmap.pc_chunk_count: 247 vm.pmap.pc_chunk_allocs: 177924 vm.pmap.pc_chunk_frees: 177677 vm.pmap.pc_chunk_tryfail: 0 vm.pmap.pv_entry_frees: 54109068 vm.pmap.pv_entry_allocs: 54174439 vm.pmap.pv_entry_spare: 17620 In /usr/src I did: make -j10 buildworld and it accomplished without crash. Thank you to all for the advice Ulrich --- * You can experiment with the number. Explanation can be found in sys/arm/include/pmap-v6.h (advice from Svatopluk Kraus). ------------------------------------------------------------------ On Thu, 20 Nov 2014 17:06:16 +0100 Svatopluk Kraus wrote: > Are you running the kernel with our pmap? If you type "sysctl > vm.pmap", you should get something like this: > > root@pandaboard:~ # sysctl vm.pmap > vm.pmap.pv_entry_max: 1488480 > vm.pmap.shpgperproc: 200 > vm.pmap.nkpt2pg: 10 > vm.pmap.sp_enabled: 1 > vm.pmap.pte1.demotions: 0 > vm.pmap.pte1.mappings: 0 > vm.pmap.pte1.p_failures: 44 > vm.pmap.pte1.promotions: 9 > vm.pmap.pv_entry_count: 11082 > vm.pmap.pc_chunk_count: 42 > vm.pmap.pc_chunk_allocs: 2882 > vm.pmap.pc_chunk_frees: 2840 > vm.pmap.pc_chunk_tryfail: 0 > vm.pmap.pv_entry_frees: 534924 > vm.pmap.pv_entry_allocs: 546006 > vm.pmap.pv_entry_spare: 3030 > > > Svatopluk Kraus > > > > On Thu, Nov 20, 2014 at 3:19 PM, Ulrich Grey > wrote: > > > Hello, > > > > here the second try: > > > > I added this two lines in src/sys/arm/conf/IMX6 > > > > makeoptions WITHOUT_MODULES="ispfw" > > without this I got a compile error in the past. > > > > options ARM_NEW_PMAP > > > > I have build the kernel without problems and rebooted. > > Superpages are enabled. > > > > This is the running kernel: > > > > root@quad:~ # uname -a > > FreeBSD quad 11.0-CURRENT FreeBSD 11.0-CURRENT #0 751adfd > > (master)-dirty: Wed Nov 19 17:15:31 UTC 2014 > > gwgpi@quad > > :/usr/local/DEVEL/obj/usr/local/DEVEL/STREJDA/freebsd/sys/WANDBOARD-QUAD > > arm > > > > The userland is on revision: r274634M > > > > Then I went to /usr/src and build your source tree: > > > > make -j10 buildworld > > > > After some hours the compilation stopped, but no crash occurs (an > > endless loop?): > > > > cc -fpic -DPIC -O -pipe > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/include > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../include > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/lib c/arm -DNLS > > -D__DBINTERFACE_PRIVATE > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/gdtoa > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/libc-vis > > -DINET6 -I/ usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/libc > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/resolv -D_ACL_PRIVATE > > -DPOSIX_MISTAKE -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../li > > bmd > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/jemalloc/include > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/tzcode/stdtime > > -I/usr/local/DEVEL/STREJDA/f reebsd/lib/libc/stdtime > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/locale -DBROKEN_DES > > -DPORTMAP -DDES_BUILTIN > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/rpc -I/usr/local/DEVEL/ > > STREJDA/freebsd/lib/libc/arm/softfloat > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/softfloat > > -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING > > -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k > > -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body > > -Wno-string-plus-int -Wno-unused-const-variable > > -Wno-tautological-compare -Wno-unused-value -Wno- > > parentheses-equality -Wno-unused-function > > -Wno-enum-conversion -Wno-switch -Wno-switch-enum > > -Wno-knr-promoted-parameter -Qunused-arguments -c nslexer.c -o > > nslexer.So > > --- libc.so.7 --- > > --- libc_pic.a --- > > building shared library libc.so.7 > > building special pic c library > > ranlib -D libc_pic.a > > > > I waited some hours, but nothing happened anymore. > > > > root@quad:~ # ps auxww > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME > > COMMAND > > > > root 10 295.9 0.5 0 10488 - RL 1:16AM 1121:36.09 > > [idle] > > > > root 92318 100.0 1.3 35396 27460 0 R 3:34AM 344:30.76 > > cc -O -pipe -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/include > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../include > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/arm -DNLS > > -D__DBINTERFACE_PRIVATE > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/gdtoa > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/libc-vis > > -DINET6 -I/usr/obj/usr/local/DEVEL/STREJDA/freebsd/lib/libc > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/resolv -D_ACL_PRIVATE > > -DPOSIX_MISTAKE -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../libmd > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/jemalloc/include > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/../../contrib/tzcode/stdtime > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/stdtime > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/locale -DBROKEN_DES > > -DPORTMAP -DDES_BUILTIN > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/rpc > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/arm/softfloat > > -I/usr/local/DEVEL/STREJDA/freebsd/lib/libc/softfloat > > -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING > > -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k > > -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body > > -Wno-string-plus-int -Wno-unused-const-variable > > -Wno-tautological-compare -Wno-unused-value > > -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion > > -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter > > -Qunused-arguments -c munlock.S > > > > root 16 0.2 0.5 0 10464 - DL 1:16AM 1:54.06 > > [syncer] > > > > root 97452 0.2 0.1 11580 2996 1 S+ 9:14AM 0:01.34 > > top -P > > > > root 0 0.0 0.5 0 10488 - DLs 1:16AM 0:00.19 > > [kernel] > > > > root 1 0.0 0.0 9296 884 - ILs 1:16AM > > 0:00.05 /sbin/init -- > > > > root 2 0.0 0.5 0 10472 - DL 1:16AM 7:43.52 > > [cam] > > > > root 3 0.0 0.5 0 10464 - DL 1:16AM 0:00.00 > > [sctp_iterator] > > > > root 4 0.0 0.5 0 10464 - DL 1:16AM 0:00.21 > > [mmcsd0: mmc/sd card] > > > > root 5 0.0 0.5 0 10464 - DL 1:16AM 0:00.26 > > [mmcsd1: mmc/sd card] > > > > root 6 0.0 0.5 0 10464 - DL 1:16AM 0:12.04 > > [pagedaemon] > > > > root 7 0.0 0.5 0 10464 - DL 1:16AM 0:00.00 > > [vmdaemon] > > > > root 8 0.0 0.5 0 10464 - DL 1:16AM 0:00.00 > > [pagezero] > > > > root 9 0.0 0.5 0 10472 - DL 1:16AM 0:01.06 > > [bufdaemon] > > > > root 11 0.0 0.5 0 10576 - WL 1:16AM 50:52.07 > > [intr] > > > > root 12 0.0 0.5 0 10480 - DL 1:16AM 5:42.76 > > [geom] > > > > root 13 0.0 0.5 0 10464 - DL 1:16AM 2:14.70 > > [rand_harvestq] > > > > root 14 0.0 0.5 0 10520 - DL 1:16AM 54:25.17 > > [usb] > > > > root 15 0.0 0.5 0 10464 - DL 1:16AM 0:03.81 > > [vnlru] > > > > root 262 0.0 0.1 8896 1048 - Ss 1:17AM > > 0:00.05 /sbin/devd > > > > root 347 0.0 0.1 10224 1528 - Ss 1:17AM > > 0:00.18 /usr/sbin/syslogd -ss > > > > root 440 0.0 0.1 10468 1216 - Is 1:17AM 0:00.01 > > casperd: zygote (casperd) > > > > root 441 0.0 0.1 10468 1292 - Is 1:17AM > > 0:00.02 /sbin/casperd > > > > messagebus 475 0.0 0.1 10780 1552 - Is 1:17AM > > 0:00.01 /usr/local/bin/dbus-daemon --system > > > > root 511 0.0 0.1 12712 2604 - Ss 1:17AM > > 0:02.21 /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid > > -f /var/db/ntpd.drift > > > > root 541 0.0 0.1 15836 3012 - Is 1:17AM > > 0:00.02 /usr/sbin/sshd > > > > root 545 0.0 0.1 10300 1784 - Ss 1:17AM > > 0:00.43 /usr/sbin/cron -s > > > > root 601 0.0 0.3 18904 6452 - Is 1:19AM 0:00.13 > > sshd: gwgpi [priv] (sshd) > > > > gwgpi 604 0.0 0.2 18904 4032 - I 1:19AM 2:23.04 > > sshd: gwgpi@pts/0 (sshd) > > > > root 878 0.0 0.3 18904 6540 <3%2018904%20%206540> - Is > > 1:20AM 0:00.18 > > sshd: gwgpi [priv] (sshd) > > > > gwgpi 896 0.0 0.2 18904 4032 - S 1:20AM 0:01.03 > > sshd: gwgpi@pts/1 (sshd) > > > > root 590 0.0 0.1 11208 2864 u0 Is 1:17AM 0:00.10 > > login [pam] (login) > > > > root 591 0.0 0.2 11208 4472 u0 S 1:17AM 0:00.21 > > -csh (csh) > > > > root 97457 0.0 0.1 10448 2084 u0 R+ 9:21AM 0:00.01 > > ps auxww > > > > gwgpi 605 0.0 0.2 11208 3768 0 Is 1:19AM 0:00.07 > > -csh (csh) > > > > root 607 0.0 0.1 11200 2708 0 I 1:19AM 0:00.08 > > su > > > > root 608 0.0 0.2 11208 3764 0 I 1:19AM 0:00.08 > > _su (csh) > > > > root 613 0.0 0.1 8944 1120 0 S+ 1:20AM 0:03.32 > > make -j10 buildworld > > > > root 618 0.0 0.1 10740 2288 0 I 1:20AM 0:00.01 > > sh -ev > > > > root 619 0.0 0.1 8944 1648 0 S 1:20AM 0:02.76 > > make -m /usr/local/DEVEL/STREJDA/freebsd/share/mk -f Makefile.inc1 > > TARGET=arm TARGET_ARCH=armv6 buildworld > > > > root 83869 0.0 0.1 10740 2340 0 I 3:23AM 0:00.02 > > sh -ev > > > > root 83870 0.0 0.1 8944 1724 0 S 3:23AM 0:00.94 > > make -f Makefile.inc1 > > DESTDIR=/usr/obj/usr/local/DEVEL/STREJDA/freebsd/tmp -DNO_FSCHG > > MK_HTML=no MK_INFO=no -DNO_LINT MK_MAN=no MK_PROFILE=no MK_TESTS=no > > MK_TESTS_SUPPORT=yes libraries > > > > root 83883 0.0 0.1 10740 2288 0 I 3:23AM 0:00.01 > > sh -ev > > > > root 84734 0.0 0.1 8944 1724 0 S 3:24AM 0:01.01 > > make -f Makefile.inc1 _startup_libs > > > > root 84750 0.0 0.1 10740 2340 0 I 3:24AM 0:00.04 > > sh -ev > > > > root 86840 0.0 1.2 29424 24084 0 S 3:28AM 0:15.96 > > make MK_TESTS=no DIRPRFX=lib/libc/ all > > > > root 92313 0.0 0.1 10740 2284 0 I 3:34AM 0:00.09 > > sh -ev > > > > gwgpi 897 0.0 0.2 11208 3768 1 Is 1:20AM 0:00.08 > > -csh (csh) > > > > root 906 0.0 0.1 11200 2708 1 I 1:20AM 0:00.11 > > su > > > > root 945 0.0 0.2 11208 3764 1 I 1:20AM 0:00.21 > > _su (csh) > > > > root@quad:~ # sysctl vm.pmap. > > vm.pmap.sp_enabled: 1 > > vm.pmap.pv_entry_count: 5691 > > vm.pmap.pv_entry_max: 1744848 > > vm.pmap.shpgperproc: 200 > > vm.pmap.section.demotions: 3 > > vm.pmap.section.mappings: 0 > > vm.pmap.section.p_failures: 35 > > vm.pmap.section.promotions: 8 > > > > -- > > regards > > Ulrich > > ---------------------------------- > > On Thu, 20 Nov 2014 00:04:38 +0100 > > Svatopluk Kraus wrote: > > > > > On Wed, Nov 19, 2014 at 10:59 PM, Ulrich Grey > > > wrote: > > > > > > > Thank you for the offer, I have tried it. > > > > > > > > After I had cloned your repository I have added 2 lines to > > > > src/sys/arm/conf/IMX6: > > > > > > > > makeoptions WITHOUT_MODULES="ispfw" # compile error > > > > makeoptions ARM_NEW_PMAP="yes" # is that ok ? > > > > > > > > > > > Add this line to sys/arm/conf/IMX6 file: > > > > > > options ARM_NEW_PMAP > > > > > > Svatopluk Kraus > > From owner-freebsd-arm@FreeBSD.ORG Fri Nov 21 13:04:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5D5A79E for ; Fri, 21 Nov 2014 13:04:30 +0000 (UTC) Received: from relay.waschbuesch.it (relay.waschbuesch.it [80.254.137.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "*.waschbuesch.it", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56D44D69 for ; Fri, 21 Nov 2014 13:04:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=waschbuesch.de; s=dkim; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=8b2NryuQVXCGH77hkjKxBtXvhbmlmhXqwbLSGasMufc=; b=a4Qq22YD2fA5AfT2IFwv44CxIp35VQcejXvH4K+F1TmXI2DCglpgbrKBn6f7pC/cptb3MiHpeFhYLTst6n6GgwnuRp2zFTPwiGFH4MZZVznESyRGvhrgVr+j9XgTizdfSu+uoT2tHrWpf7vGPxJs+6C8/NAvNBFh+4y4XFn1SJc=; Received: by relay.waschbuesch.it with esmtpsa (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim) (envelope-from ) id 1Xrnsv-0000Ow-Bp for freebsd-arm@freebsd.org; Fri, 21 Nov 2014 14:04:25 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_F86284CB-69CB-434B-AB8A-8F2A755A124C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: Utilite support X-Pgp-Agent: GPGMail 2.5b2 From: =?utf-8?Q?Waschb=C3=BCsch_Martin?= In-Reply-To: <1416503998.1147.185.camel@revolution.hippie.lan> Date: Fri, 21 Nov 2014 14:04:24 +0100 Message-Id: References: <1416503998.1147.185.camel@revolution.hippie.lan> To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.1993) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 13:04:30 -0000 --Apple-Mail=_F86284CB-69CB-434B-AB8A-8F2A755A124C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 > Am 20.11.2014 um 18:19 schrieb Ian Lepore : > > There is some chance that "it might just work." Actually a better > chance now than when I originally wrote that. :) Try using crochet for > wandboard and in the wandboard kernel config file change FDT_DTS_FILE to > "imx6q-cm-fx6.dts". There's a good chance you'll end up with a bootable > image on an sdcard. > > You will need a serial console for debugging, we don't support a video > console yet on imx6 systems. The Compulab FitPc2 x86 systems need a > special serial debugging cable that you have to buy separately. I hope > that's not also the case with Utilite. > > -- Ian Hello Ian, I tried to follow your suggestion, but realized that there might be a significant difference between Wandboard and Utilite: Utilite does not read u-boot from disk. Instead, it holds u-boot as 'firmware' in a flash module. Don't know why I had not realized this earlier, but anyway, I guess if I had compiled it before, I would have noticed. So far I had played around with pre-built Wandboard images... What this means is that the current crochet scripts will fail because the u-boot compilation for cm-fx6 will not output a u-boot.imx file and is probably not needed anyway. What I will try next is make a copy of crochet's boards/Wandboard to boards/Utilite and try to adapt the setup.sh script. Questions: Are there requirements that u-boot must meet in order to boot ubldr? If so, I'll have to look into rebuilding u-boot plus flashing that. Martin --Apple-Mail=_F86284CB-69CB-434B-AB8A-8F2A755A124C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUbzhZAAoJEP0QXR2ClIJ98JYIALHy0ObxZHYhO40BxE+r1jrw rT2J9quOLNJJQBVuVNv8AnO97z4HUqepjpGLjI9KX9Aa6owmV4jQ7KFDgblR655i YcGae81Nxlh8jp0mtA05kwesPceohmDGIEo0XrOHybPkjx0RQ6ZiCH2h6U8n/AGd 3h5sKcYvuf/w8UUD+P4U6TYqoz7NQuDrr8Hn+yag83CKmnTynVeCVQlBZiwR3kaW Lp9BHnsFlzuhqY12nWVH+0njF5mkGmzmGjKJnpwmfqE4R4vJhaMR7K0VHRvhhrhd KC6yDmgx3ly9O3+VVl4tr6lSCh+2FvWe4/kQqcI5ZGc0LLkRoFpEepBBc/TZcyM= =UNRo -----END PGP SIGNATURE----- --Apple-Mail=_F86284CB-69CB-434B-AB8A-8F2A755A124C-- From owner-freebsd-arm@FreeBSD.ORG Fri Nov 21 14:15:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35A54812 for ; Fri, 21 Nov 2014 14:15:37 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 12DFF6C7 for ; Fri, 21 Nov 2014 14:15:36 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 20D38193964; Fri, 21 Nov 2014 14:15:35 +0000 (UTC) Subject: Re: ARMv6 -- pkg repo build From: Sean Bruno Reply-To: sbruno@freebsd.org To: Warner Losh In-Reply-To: References: <1416531121.7423.47.camel@bruno> <20141121011905.GC99957@funkthat.com> <1416537224.7423.49.camel@bruno> <20141121042452.GD99957@funkthat.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-WAkJYaq/zkqM1VlVGw3z" Date: Fri, 21 Nov 2014 06:15:33 -0800 Message-ID: <1416579333.7423.51.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 14:15:37 -0000 --=-WAkJYaq/zkqM1VlVGw3z Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable > > Ahh, it's an issue w/ sys/conf/kmod.mk when it builds the machine > > link... In kmod.mk it does: > > ${.OBJDIR}/${_link}: > > @case ${.TARGET:T} in \ > > machine) \ > > path=3D${SYSDIR}/${MACHINE}/include ;; \ > >=20 > > So, looks like MACHINE isn't set correctly, or MACHINE isn't what's > > suppose to be here... Not sure which is correct=85 >=20 > this is correct. MACHINE should be arm. If it is anything else, then bad = things > are going to happen. >=20 > There=92s safeties to prevent it, but are you sure you=92re saying TARGET= =3Darm > TARGET_ARCH=3Darmv6? and not TARGET=3Darmv6? >=20 > Warner I'm positive. The poudriere code accepts takes "-a TARGET.TARGET_ARCH" and nowhere in the code does it substitue armv6 for armv7 sean --=-WAkJYaq/zkqM1VlVGw3z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJUb0kFXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kk0kH/iHmxRrO9k2nWloHkvI9GVkA CCNbF2NmB1p/dbyMxBDFy+gkTcqIYtgozDqTxfkQd9f88N4dH0+7YsT0c9pyGJYH owFuwtrj1B2XSKDOF/h7IkMZGsxD85Bu3xU7/0UaJomGNwanXtNRIQy3xvTHdgC9 sskNqcP1Uvj+SBaso4pX3yiE61Xvq7aWlw9OQkiLakeOtj0dVOSN92ummIYlWxMG 1W1e0WVYhNysEJSzXNtj3r+b2NVudwfxhSkaPJlczwPLxwcsxIyzNIrfSHJEYw27 gO0kzScSJatmYI+kMbn+9mIaAwcv4Vt6SszCH2lGa+mTuyiawke/ZMKvL4ocyHM= =G7CU -----END PGP SIGNATURE----- --=-WAkJYaq/zkqM1VlVGw3z-- From owner-freebsd-arm@FreeBSD.ORG Fri Nov 21 15:36:00 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83C49217 for ; Fri, 21 Nov 2014 15:36:00 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3B5D9F93 for ; Fri, 21 Nov 2014 15:35:59 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XrqFb-000Oq5-0B; Fri, 21 Nov 2014 15:35:59 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sALFZvFj003697; Fri, 21 Nov 2014 08:35:57 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 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/d0vnAMG320G6z/rQoEJxT X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Utilite support From: Ian Lepore To: =?ISO-8859-1?Q?Waschb=FCsch?= Martin In-Reply-To: References: <1416503998.1147.185.camel@revolution.hippie.lan> Date: Fri, 21 Nov 2014 08:35:56 -0700 Message-ID: <1416584156.1147.259.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 15:36:00 -0000 On Fri, 2014-11-21 at 14:04 +0100, Waschb=FCsch Martin wrote: > > Am 20.11.2014 um 18:19 schrieb Ian Lepore : > >=20 > > There is some chance that "it might just work." Actually a better > > chance now than when I originally wrote that. :) Try using crochet f= or > > wandboard and in the wandboard kernel config file change FDT_DTS_FILE= to > > "imx6q-cm-fx6.dts". There's a good chance you'll end up with a boota= ble > > image on an sdcard. > >=20 > > You will need a serial console for debugging, we don't support a vide= o > > console yet on imx6 systems. The Compulab FitPc2 x86 systems need a > > special serial debugging cable that you have to buy separately. I ho= pe > > that's not also the case with Utilite. > >=20 > > -- Ian >=20 > Hello Ian, >=20 > I tried to follow your suggestion, but realized that there might be > a significant difference between Wandboard and Utilite: Utilite does > not read u-boot from disk. Instead, it holds u-boot as 'firmware' in > a flash module. > Don't know why I had not realized this earlier, but anyway, I guess > if I had compiled it before, I would have noticed. So far I had played > around with pre-built Wandboard images... > What this means is that the current crochet scripts will fail because > the u-boot compilation for cm-fx6 will not output a u-boot.imx file and > is probably not needed anyway. > What I will try next is make a copy of crochet's boards/Wandboard to > boards/Utilite and try to adapt the setup.sh script. > Questions: > Are there requirements that u-boot must meet in order to boot ubldr? If > so, I'll have to look into rebuilding u-boot plus flashing that. >=20 > Martin I'll attach the patches I use for building u-boot (I use the uboot for Technexion EDM modules for Wandboard too; wandboard uses technexion modules). The API option is the main one for running ubldr. Check whether the uboot on the Utilite has the 'bmode' command. You may be able to insert an sdcard with a new uboot and freebsd on it and say "bmode mmc0" (or mmc1 or whatever) and the system will reset and boot from the sdcard instead of the flash. My Cubox i4pro arrived yesterday. Its uboot doesn't have the API option (they almost never do; linux doesn't use it). I tried compiling the dtb into the kernel and launching it directly, and that fails because the cubox dts doesn't have a memory=3D<> property. I think the uboot probabl= y figures out the amount of ram and modifies the dtb it passes to the kernel. Ick. I hacked around that and now the kernel hangs as soon as initarm() installs new page tables. So the barriers to launching a non-linux kernel using just what a system vendor provides are even bigger than I had imagined. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Nov 21 15:51:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5E9F949 for ; Fri, 21 Nov 2014 15:51:49 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A1A2C1B2 for ; Fri, 21 Nov 2014 15:51:49 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 2C4E0193964; Fri, 21 Nov 2014 15:51:48 +0000 (UTC) Subject: Re: ARMv6 -- pkg repo build From: Sean Bruno Reply-To: sbruno@freebsd.org To: Warner Losh In-Reply-To: <1416579333.7423.51.camel@bruno> References: <1416531121.7423.47.camel@bruno> <20141121011905.GC99957@funkthat.com> <1416537224.7423.49.camel@bruno> <20141121042452.GD99957@funkthat.com> <1416579333.7423.51.camel@bruno> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-3+ug5WTUP/JMitmvTU1D" Date: Fri, 21 Nov 2014 07:51:46 -0800 Message-ID: <1416585106.7423.52.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 15:51:49 -0000 --=-3+ug5WTUP/JMitmvTU1D Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable On Fri, 2014-11-21 at 06:15 -0800, Sean Bruno wrote: > > > Ahh, it's an issue w/ sys/conf/kmod.mk when it builds the machine > > > link... In kmod.mk it does: > > > ${.OBJDIR}/${_link}: > > > @case ${.TARGET:T} in \ > > > machine) \ > > > path=3D${SYSDIR}/${MACHINE}/include ;; \ > > >=20 > > > So, looks like MACHINE isn't set correctly, or MACHINE isn't what's > > > suppose to be here... Not sure which is correct=85 > >=20 > > this is correct. MACHINE should be arm. If it is anything else, then ba= d things > > are going to happen. > >=20 > > There=92s safeties to prevent it, but are you sure you=92re saying TARG= ET=3Darm > > TARGET_ARCH=3Darmv6? and not TARGET=3Darmv6? > >=20 > > Warner >=20 >=20 > I'm positive. The poudriere code accepts takes "-a TARGET.TARGET_ARCH" > and nowhere in the code does it substitue armv6 for armv7 >=20 > sean Full output from: poudriere jail -c -j 11armv6 -m svn -v head -a arm.armv6 -x https://people.freebsd.org/~sbruno/poudriere_arm_armv6.txt See anything odd in there? sean --=-3+ug5WTUP/JMitmvTU1D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJUb1+SXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kJlMIAL33eRYNuojLZjgqfo7O56gK 4pyrRcvSHUMKO7hI4n83FpY7WTWMr6XWKtjXrh7CGAAcuAtWgZppRExWmgdicdTt qNZNvomFyi5B9iEQWW/9HM9+Wrh7rHJ3ccR2RhoTcOz7a+rsOP/SiNJ213ZwprHv LF/OwySSxKoiW7OPo35cF1Nu8VvZ6tdOAThuCyvJpS1RRwGYyhu0FPIGnoHDtU22 RJxVPQ411O1wt8pFGqKWaUPpTuG7jYDe7+IZ7rGL7wAvPqcewECb2TAon+4IsfUw vsp5/yn7cZKMVUltsyO4jeUzKinj5qdcMciXip75gXNoajV++cE+Nrp87z1bOmw= =1INa -----END PGP SIGNATURE----- --=-3+ug5WTUP/JMitmvTU1D-- From owner-freebsd-arm@FreeBSD.ORG Fri Nov 21 17:19: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1204B5C6 for ; Fri, 21 Nov 2014 17:19:21 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E1F41DCF for ; Fri, 21 Nov 2014 17:19:20 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id DD780193964; Fri, 21 Nov 2014 17:19:19 +0000 (UTC) Subject: Re: ARMv6 -- pkg repo build From: Sean Bruno Reply-To: sbruno@freebsd.org To: Warner Losh In-Reply-To: <1416585106.7423.52.camel@bruno> References: <1416531121.7423.47.camel@bruno> <20141121011905.GC99957@funkthat.com> <1416537224.7423.49.camel@bruno> <20141121042452.GD99957@funkthat.com> <1416579333.7423.51.camel@bruno> <1416585106.7423.52.camel@bruno> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-UvUZjbD8uUzBLhqIkKqE" Date: Fri, 21 Nov 2014 09:19:19 -0800 Message-ID: <1416590359.7423.61.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 17:19:21 -0000 --=-UvUZjbD8uUzBLhqIkKqE Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable On Fri, 2014-11-21 at 07:51 -0800, Sean Bruno wrote: > On Fri, 2014-11-21 at 06:15 -0800, Sean Bruno wrote: > > > > Ahh, it's an issue w/ sys/conf/kmod.mk when it builds the machine > > > > link... In kmod.mk it does: > > > > ${.OBJDIR}/${_link}: > > > > @case ${.TARGET:T} in \ > > > > machine) \ > > > > path=3D${SYSDIR}/${MACHINE}/include ;; \ > > > >=20 > > > > So, looks like MACHINE isn't set correctly, or MACHINE isn't what's > > > > suppose to be here... Not sure which is correct=85 > > >=20 > > > this is correct. MACHINE should be arm. If it is anything else, then = bad things > > > are going to happen. > > >=20 > > > There=92s safeties to prevent it, but are you sure you=92re saying TA= RGET=3Darm > > > TARGET_ARCH=3Darmv6? and not TARGET=3Darmv6? > > >=20 > > > Warner > >=20 > >=20 > > I'm positive. The poudriere code accepts takes "-a TARGET.TARGET_ARCH" > > and nowhere in the code does it substitue armv6 for armv7 > >=20 > > sean >=20 >=20 > Full output from: >=20 > poudriere jail -c -j 11armv6 -m svn -v head -a arm.armv6 -x >=20 > https://people.freebsd.org/~sbruno/poudriere_arm_armv6.txt >=20 > See anything odd in there? >=20 > sean Hrm ... I notice that MACHINE_CPU is set to the host version (amd64) and not the jail version in my port builds. So, for things like math/fftw3, it tries to compile with x86 cpu options. I wonder if this is causing grief and how I should work around this? sean --=-UvUZjbD8uUzBLhqIkKqE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJUb3QXXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5klSYH/R1CSTmNqm3b7HUAmttseIfP AL5lR5RRR1okpKx6HXVUrF6oJdD/3QZnLB4djdddpQgHJgS6+zMKQde+OOtan399 jkoMZLk7cWccEXTyL7BXUXRSdbE9Hg/HKp9PEq2Slam2nZmJP1MtU4J1mpdpdSoL oOTZhB963zEwKdatHnaCZkgB0RL+5c2xkq1c92K1isCSKUdMfgZdhajPmKH27bu/ Y5qR5r5vN78+GZVXsuCrVIfrYoGkFu8DGnKV1GZ8uDijUCwGGOlC5rTRpqAHeADZ ON7/Kc6vXbUtmGI/trBJeUTICMRM2Jowl9ZCctMlvnG8BNB3SKMEbCkCLHlQhjU= =SAay -----END PGP SIGNATURE----- --=-UvUZjbD8uUzBLhqIkKqE-- From owner-freebsd-arm@FreeBSD.ORG Fri Nov 21 20:25:32 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75AA0FB9 for ; Fri, 21 Nov 2014 20:25:32 +0000 (UTC) Received: from mail.FoxValley.net (mail.FoxValley.net [64.135.192.34]) by mx1.freebsd.org (Postfix) with SMTP id 2734C784 for ; Fri, 21 Nov 2014 20:25:31 +0000 (UTC) Received: (qmail 17434 invoked from network) for freebsd-arm@freebsd.org; 21 Nov 2014 14:25:30 -0600 Received: from marengo.foxvalley.net (draymond@64.135.192.25) by mail.foxvalley.net with SMTP; 21 Nov 2014 14:25:30 -0600 Received: from sp5.qualcomm.com (sp5.qualcomm.com [199.106.103.55]) by webmail.FoxValley.net (Horde MIME library) with HTTP; Fri, 21 Nov 2014 14:25:30 -0600 Message-ID: <20141121142530.3f0wlemfl5m0o0os@webmail.FoxValley.net> Date: Fri, 21 Nov 2014 14:25:30 -0600 From: draymond@FoxValley.net To: freebsd-arm@freebsd.org Subject: re: new support for Raspberry Pi B+ MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 20:25:32 -0000 I ordered another SD card to experiment with FreeBSD 11 on Raspberry =20 Pi B+. This one was a Kingston 16GB Class 6. It booted successfully =20 10 out of 10 times when using low speed (hw.bcm2835.sdhci.hs=3D"0"). It =20 failed to boot 10 out of 10 times when using high speed =20 (hw.bcm2835.sdhci.hs=3D"1"). To summarize my findings so far: 16GB Transcend Class 10: will not boot using high speed; boots =20 consistently at low speed but experienced catastrophic file system =20 corruption after 10 days of heavy use 32GB Sandisk Class 10: boots consistently at high speed (41.6MHz) and =20 low speed (25MHz); however it always panics during auto-resizing; =20 panic when building pkg 32GB Samsung Class 6: will not boot using high speed; boots =20 consistently at low speed; have not had any SD card related panics yet =20 after 6 days of heavy use 16GB Kingston Class 6: will not boot using high speed; boots =20 consistently at low speed Luiz, have you made any progress finding the root cause of these SD =20 card problems? Are you seeing similar results during your testing? From owner-freebsd-arm@FreeBSD.ORG Fri Nov 21 21:30:42 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFE2956F for ; Fri, 21 Nov 2014 21:30:42 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A7FA2EA0 for ; Fri, 21 Nov 2014 21:30:42 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sALLUgmC060492 for ; Fri, 21 Nov 2014 21:30:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 195009] [patch]: [arm] Use 400 kHz as the default OMAP4 I2C bus speed Date: Fri, 21 Nov 2014 21:30:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 21:30:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195009 --- Comment #9 from commit-hook@freebsd.org --- A commit references this bug: Author: ian Date: Fri Nov 21 21:30:09 UTC 2014 New revision: 274822 URL: https://svnweb.freebsd.org/changeset/base/274822 Log: Document the recent enhancements for configuring bus speed in iicbus(4). Differential Revision: https://reviews.freebsd.org/D1182 PR: 195009 Changes: head/share/man/man4/iicbus.4 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Nov 21 21:33:40 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FA9C6F0 for ; Fri, 21 Nov 2014 21:33:40 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB799ED6 for ; Fri, 21 Nov 2014 21:33:39 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sALLXdMI092978 for ; Fri, 21 Nov 2014 21:33:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 195009] [patch]: [arm] Use 400 kHz as the default OMAP4 I2C bus speed Date: Fri, 21 Nov 2014 21:33:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: Needs MFC X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 21:33:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195009 Ian Lepore changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Needs MFC -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sat Nov 22 03:07:32 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB6BCFF5; Sat, 22 Nov 2014 03:07:32 +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)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0AEDD2EE; Sat, 22 Nov 2014 03:07:30 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id sAM36x8e045738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 22 Nov 2014 04:07:04 +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 sAM36qsZ017754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Nov 2014 04:06:53 +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 sAM36qoN019385; Sat, 22 Nov 2014 04:06:52 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id sAM36qP7019384; Sat, 22 Nov 2014 04:06:52 +0100 (CET) (envelope-from ticso) Date: Sat, 22 Nov 2014 04:06:52 +0100 From: Bernd Walter To: Ian Lepore Subject: Re: Utilite support Message-ID: <20141122030652.GD15350@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <1416503998.1147.185.camel@revolution.hippie.lan> <1416584156.1147.259.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1416584156.1147.259.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=ham 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.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 03:07:32 -0000 On Fri, Nov 21, 2014 at 08:35:56AM -0700, Ian Lepore wrote: > On Fri, 2014-11-21 at 14:04 +0100, Waschbüsch Martin wrote: > > > Am 20.11.2014 um 18:19 schrieb Ian Lepore : > > > > > > There is some chance that "it might just work." Actually a better > > > chance now than when I originally wrote that. :) Try using crochet for > > > wandboard and in the wandboard kernel config file change FDT_DTS_FILE to > > > "imx6q-cm-fx6.dts". There's a good chance you'll end up with a bootable > > > image on an sdcard. > > > > > > You will need a serial console for debugging, we don't support a video > > > console yet on imx6 systems. The Compulab FitPc2 x86 systems need a > > > special serial debugging cable that you have to buy separately. I hope > > > that's not also the case with Utilite. > > > > > > -- Ian > > > > Hello Ian, > > > > I tried to follow your suggestion, but realized that there might be > > a significant difference between Wandboard and Utilite: Utilite does > > not read u-boot from disk. Instead, it holds u-boot as 'firmware' in > > a flash module. > > Don't know why I had not realized this earlier, but anyway, I guess > > if I had compiled it before, I would have noticed. So far I had played > > around with pre-built Wandboard images... > > What this means is that the current crochet scripts will fail because > > the u-boot compilation for cm-fx6 will not output a u-boot.imx file and > > is probably not needed anyway. > > What I will try next is make a copy of crochet's boards/Wandboard to > > boards/Utilite and try to adapt the setup.sh script. > > Questions: > > Are there requirements that u-boot must meet in order to boot ubldr? If > > so, I'll have to look into rebuilding u-boot plus flashing that. > > > > Martin > > I'll attach the patches I use for building u-boot (I use the uboot for > Technexion EDM modules for Wandboard too; wandboard uses technexion > modules). The API option is the main one for running ubldr. > > Check whether the uboot on the Utilite has the 'bmode' command. You may > be able to insert an sdcard with a new uboot and freebsd on it and say > "bmode mmc0" (or mmc1 or whatever) and the system will reset and boot > from the sdcard instead of the flash. > > My Cubox i4pro arrived yesterday. Its uboot doesn't have the API option > (they almost never do; linux doesn't use it). I tried compiling the dtb > into the kernel and launching it directly, and that fails because the > cubox dts doesn't have a memory=<> property. I think the uboot probably > figures out the amount of ram and modifies the dtb it passes to the > kernel. Ick. I hacked around that and now the kernel hangs as soon as > initarm() installs new page tables. So how is that uboot thing handled in this case? Can you go and compile uboot from the same source as for a wandboard, or do we need to have different source for each of the boards? As you know I do own a bunch of different iMX6 boards and I'm happy to do test boots and minor tweaking (if required by readin gschematics) on all of them. > So the barriers to launching a non-linux kernel using just what a system > vendor provides are even bigger than I had imagined. :-( -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sat Nov 22 03:26:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 674CC5D1 for ; Sat, 22 Nov 2014 03:26:37 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26DC5686 for ; Sat, 22 Nov 2014 03:26:36 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Xs1LH-0005LN-9h; Sat, 22 Nov 2014 03:26:35 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sAM3QW1k005036; Fri, 21 Nov 2014 20:26:32 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 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/6q3uYxdQF/iACvmdgzdlF X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Utilite support From: Ian Lepore To: ticso@cicely.de In-Reply-To: <20141122030652.GD15350@cicely7.cicely.de> References: <1416503998.1147.185.camel@revolution.hippie.lan> <1416584156.1147.259.camel@revolution.hippie.lan> <20141122030652.GD15350@cicely7.cicely.de> Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 21 Nov 2014 20:26:32 -0700 Message-ID: <1416626792.1147.325.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 ilsoft.org id sAM3QW1k005036 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 03:26:37 -0000 On Sat, 2014-11-22 at 04:06 +0100, Bernd Walter wrote: > On Fri, Nov 21, 2014 at 08:35:56AM -0700, Ian Lepore wrote: > > On Fri, 2014-11-21 at 14:04 +0100, Waschb=FCsch Martin wrote: > > > > Am 20.11.2014 um 18:19 schrieb Ian Lepore : > > > >=20 > > > > There is some chance that "it might just work." Actually a bette= r > > > > chance now than when I originally wrote that. :) Try using croch= et for > > > > wandboard and in the wandboard kernel config file change FDT_DTS_= FILE to > > > > "imx6q-cm-fx6.dts". There's a good chance you'll end up with a b= ootable > > > > image on an sdcard. > > > >=20 > > > > You will need a serial console for debugging, we don't support a = video > > > > console yet on imx6 systems. The Compulab FitPc2 x86 systems nee= d a > > > > special serial debugging cable that you have to buy separately. = I hope > > > > that's not also the case with Utilite. > > > >=20 > > > > -- Ian > > >=20 > > > Hello Ian, > > >=20 > > > I tried to follow your suggestion, but realized that there might be > > > a significant difference between Wandboard and Utilite: Utilite doe= s > > > not read u-boot from disk. Instead, it holds u-boot as 'firmware' i= n > > > a flash module. > > > Don't know why I had not realized this earlier, but anyway, I guess > > > if I had compiled it before, I would have noticed. So far I had pla= yed > > > around with pre-built Wandboard images... > > > What this means is that the current crochet scripts will fail becau= se > > > the u-boot compilation for cm-fx6 will not output a u-boot.imx file= and > > > is probably not needed anyway. > > > What I will try next is make a copy of crochet's boards/Wandboard t= o > > > boards/Utilite and try to adapt the setup.sh script. > > > Questions: > > > Are there requirements that u-boot must meet in order to boot ubldr= ? If > > > so, I'll have to look into rebuilding u-boot plus flashing that. > > >=20 > > > Martin > >=20 > > I'll attach the patches I use for building u-boot (I use the uboot fo= r > > Technexion EDM modules for Wandboard too; wandboard uses technexion > > modules). The API option is the main one for running ubldr. > >=20 > > Check whether the uboot on the Utilite has the 'bmode' command. You = may > > be able to insert an sdcard with a new uboot and freebsd on it and sa= y > > "bmode mmc0" (or mmc1 or whatever) and the system will reset and boot > > from the sdcard instead of the flash. > >=20 > > My Cubox i4pro arrived yesterday. Its uboot doesn't have the API opt= ion > > (they almost never do; linux doesn't use it). I tried compiling the = dtb > > into the kernel and launching it directly, and that fails because the > > cubox dts doesn't have a memory=3D<> property. I think the uboot pro= bably > > figures out the amount of ram and modifies the dtb it passes to the > > kernel. Ick. I hacked around that and now the kernel hangs as soon = as > > initarm() installs new page tables. >=20 > So how is that uboot thing handled in this case? > Can you go and compile uboot from the same source as for a wandboard, o= r > do we need to have different source for each of the boards? > As you know I do own a bunch of different iMX6 boards and I'm happy to > do test boots and minor tweaking (if required by readin gschematics) on > all of them. >=20 I'm trying to figure that out at this very moment. A while back I came up with a single master u-boot-imx6 port that works for all flavors (solo, dual, quad) of wandboards and technexion edm modules. But the u-boot sources I used for that don't have the cubox stuff, so first I've got to get some sources that do. I think that's probably the world we're stuck in... more or less a separate u-boot port for every flavor of board we support, with maybe an occasional opportunity to collapse several similar boards into one port. A lot of times there are vendor-specific tweaks to u-boot and they don't always push them back to the u-boot project, they just publish them on github to comply with gpl (if you're lucky) and call it done. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Nov 22 07:02: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A266280 for ; Sat, 22 Nov 2014 07:02:44 +0000 (UTC) Received: from relay.waschbuesch.it (relay.waschbuesch.it [80.254.137.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "*.waschbuesch.it", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC378BF4 for ; Sat, 22 Nov 2014 07:02:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=waschbuesch.de; s=dkim; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=zpViRlYnSeyWY1TqikFOeym/1jWQN214UZmTRr3weQU=; b=HsSv5PaKoCwXhMpN+Ex1SDVqMz+DuPUnJlev3CXtc2W/yKSWTONV8i7WyH+muJzTuojnNJ5zyUdvuGMLei5Oe7zxaqtH1uzFGmgn7OTDUdpk+CYzGgo4BurJxLainjI5RRdFsW7kh5gDP7+8WR5ocAU+M2soFHSJl1NfhlTiqVg=; Received: by relay.waschbuesch.it with esmtpsa (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim) (envelope-from ) id 1Xs4iG-0000lg-UC for freebsd-arm@freebsd.org; Sat, 22 Nov 2014 08:02:32 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_982AFBE9-8BCF-4957-A756-E0480D94FB95"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: Utilite support X-Pgp-Agent: GPGMail 2.5b2 From: =?utf-8?Q?Waschb=C3=BCsch_Martin?= In-Reply-To: <1416626792.1147.325.camel@revolution.hippie.lan> Date: Sat, 22 Nov 2014 08:02:32 +0100 Message-Id: References: <1416503998.1147.185.camel@revolution.hippie.lan> <1416584156.1147.259.camel@revolution.hippie.lan> <20141122030652.GD15350@cicely7.cicely.de> <1416626792.1147.325.camel@revolution.hippie.lan> To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.1993) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 07:02:44 -0000 --Apple-Mail=_982AFBE9-8BCF-4957-A756-E0480D94FB95 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 > Am 22.11.2014 um 04:26 schrieb Ian Lepore : > > I think that's probably the world we're stuck in... more or less a > separate u-boot port for every flavor of board we support, with maybe an > occasional opportunity to collapse several similar boards into one port. > A lot of times there are vendor-specific tweaks to u-boot and they don't > always push them back to the u-boot project, they just publish them on > github to comply with gpl (if you're lucky) and call it done. > > -- Ian At least w/r to Utilite, it is reasonable enough: They give you a patch and tell you which commit of the vanilla u-boot repo it will apply to, as opposed to publishing their own, independent source tree. --Apple-Mail=_982AFBE9-8BCF-4957-A756-E0480D94FB95 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUcDUIAAoJEP0QXR2ClIJ9fL0H/12x+K8DpADRIxlKTBh2Nqyv jvRzNWlDmGv2WavGkJoIQ6o2VDdPDo4qmyVs8S6x6eE+2osLlhkoVj6fYoDxevXm CSuI9YMBQ1lh7JiQVxEbDWJMaEDqmx8cfpus3QP5PBi8rZkdbYdSnIvFWUrV+k5l 3fIEcGVXfDBJw1g+FOhnOffPOYWXnBOXVYOpFQwLtyDUb5ea/7xE3wybMBTxgpWY M9Pazmwxrb/CF7urOVlqb3Nfh14+OEM2VSdNqW58hKnSeSh4OBp70G0DUTK221mW I/tRvsebgS8HpCQI/P9rDxnnCNZq1vzek0u1KWX8esk5SUfLMmu2LjNQhoNaFUA= =7Ys/ -----END PGP SIGNATURE----- --Apple-Mail=_982AFBE9-8BCF-4957-A756-E0480D94FB95-- From owner-freebsd-arm@FreeBSD.ORG Sat Nov 22 07:14:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F8EC340; Sat, 22 Nov 2014 07:14:50 +0000 (UTC) Received: from relay.waschbuesch.it (relay.waschbuesch.it [80.254.137.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "*.waschbuesch.it", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B190CCA9; Sat, 22 Nov 2014 07:14:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=waschbuesch.de; s=dkim; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=kmABz175mDs5ywXYPJ7GqOtBFHvM2wbjrxxyG4Yf9+E=; b=NfHWAzBH/y+4Oo9a0D9iBBfhtkYen/V2JRraoCrR65wy7fTyimHIOIAEb6I72Q9igimJtRb9+mPHFmrbR2v0ZsNhCs+hfOwqyXwUpH31npshuNZon9AsFkt4HUQd4so8KDQHU06hqKqEjxrlkgVZ/xluM7tfS/TMp99Rvh1wrFY=; Received: by relay.waschbuesch.it with esmtpsa (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim) (envelope-from ) id 1Xs4u5-0000lv-1M; Sat, 22 Nov 2014 08:14:45 +0100 Subject: Re: Utilite support Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_634B8B50-C35D-47C5-A246-26201C23CAD2"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b2 From: =?utf-8?Q?Waschb=C3=BCsch_Martin?= In-Reply-To: <1416626792.1147.325.camel@revolution.hippie.lan> Date: Sat, 22 Nov 2014 08:14:44 +0100 Message-Id: References: <1416503998.1147.185.camel@revolution.hippie.lan> <1416584156.1147.259.camel@revolution.hippie.lan> <20141122030652.GD15350@cicely7.cicely.de> <1416626792.1147.325.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1993) Cc: freebsd-arm@freebsd.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 07:14:50 -0000 --Apple-Mail=_634B8B50-C35D-47C5-A246-26201C23CAD2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 > Am 22.11.2014 um 04:26 schrieb Ian Lepore : >> >> So how is that uboot thing handled in this case? >> Can you go and compile uboot from the same source as for a wandboard, or >> do we need to have different source for each of the boards? >> As you know I do own a bunch of different iMX6 boards and I'm happy to >> do test boots and minor tweaking (if required by readin gschematics) on >> all of them. >> > > I'm trying to figure that out at this very moment. Hm, I guess it would make sense to document these things in detail. E.g. extend https://wiki.freebsd.org/FreeBSD/arm or some other appropriate place to include info on hardware specs, used version of uboot, links to documentation, repos, as well as status of driver support for individual components, etc? --Apple-Mail=_634B8B50-C35D-47C5-A246-26201C23CAD2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUcDfkAAoJEP0QXR2ClIJ9aFsIALxlCtfxx4J4q+0b3qILhvw2 fNanOHKqFQf3hDKtCsJoOh1waKArCpJ4xAB5W0zEbyhkbtJHR+XZZULyU2wiP0K0 zIJQI2o6BlPQFWR7dy1TwMm1KMzYutEbqe0VnSEj6pxwduW8zFhVtcrYkLzhR1vQ D6YRx944M8CciFkJ7fabShaCy2bkgbHR5qTPG3jZDQrgPsUnjXEcDEGNOia3EyUM BMiW1/rc609OWvgBc2UHue8Enjj5BzyPagfXicGq1LwHNTbrmtR9sypAgV8Bo0fh xRa/cFxCwWWjo/yK80K6a47ulphahWzMXK+BWuEp3n1Qb0ZG+nCtknCE+vNEPok= =Qoch -----END PGP SIGNATURE----- --Apple-Mail=_634B8B50-C35D-47C5-A246-26201C23CAD2-- From owner-freebsd-arm@FreeBSD.ORG Sat Nov 22 19:46:46 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DB60C99 for ; Sat, 22 Nov 2014 19:46:46 +0000 (UTC) Received: from mail.FoxValley.net (mail.FoxValley.net [64.135.192.34]) by mx1.freebsd.org (Postfix) with SMTP id 309FFBAE for ; Sat, 22 Nov 2014 19:46:45 +0000 (UTC) Received: (qmail 1861 invoked from network) for freebsd-arm@freebsd.org; 22 Nov 2014 13:46:38 -0600 Received: from 71-211-193-1.hlrn.qwest.net (HELO ?192.168.1.3?) (draymond@71.211.193.1) by mail.foxvalley.net with SMTP; 22 Nov 2014 13:46:38 -0600 Message-ID: <5470E81A.3070009@foxvalley.net> Date: Sat, 22 Nov 2014 12:46:34 -0700 From: Dan Raymond User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: re: new support for Raspberry Pi B+ Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 19:46:46 -0000 Further testing with the 16GB Kingston reveals that it is unstable even at low speed. I hit the following panic while executing "portsnap fetch update" on a r274416 build: dev = mmcsd0s2a, ino = 155101, fs = /mnt/ufs panic: ffs_freefile: freeing free inode KDB: enter: panic [ thread pid 8 tid 100056 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! db> From owner-freebsd-arm@FreeBSD.ORG Sat Nov 22 20:10:39 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D62FF25D for ; Sat, 22 Nov 2014 20:10:39 +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)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 68509D72 for ; Sat, 22 Nov 2014 20:10:38 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id sAMK9x68050836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 22 Nov 2014 21:10:16 +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 sAMK9qo4024896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Nov 2014 21:09:53 +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 sAMK9qTJ023681; Sat, 22 Nov 2014 21:09:52 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id sAMK9qAU023680; Sat, 22 Nov 2014 21:09:52 +0100 (CET) (envelope-from ticso) Date: Sat, 22 Nov 2014 21:09:52 +0100 From: Bernd Walter To: Dan Raymond Subject: Re: new support for Raspberry Pi B+ Message-ID: <20141122200952.GA22446@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <5470E81A.3070009@foxvalley.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5470E81A.3070009@foxvalley.net> 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=ham 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.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 20:10:39 -0000 On Sat, Nov 22, 2014 at 12:46:34PM -0700, Dan Raymond wrote: > Further testing with the 16GB Kingston reveals that it is unstable even > at low speed. I hit the following panic while executing "portsnap fetch > update" on a r274416 build: > > dev = mmcsd0s2a, ino = 155101, fs = /mnt/ufs > panic: ffs_freefile: freeing free inode > KDB: enter: panic > [ thread pid 8 tid 100056 ] > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > db> Maybe you've received a counterfeit. Unfortunately there are a lot of them on the market. Some of them are technically smaller than they claim and overwrite other data if they run short. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sat Nov 22 20:56:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D716F919 for ; Sat, 22 Nov 2014 20:56:35 +0000 (UTC) Received: from mail.FoxValley.net (mail.FoxValley.net [64.135.192.34]) by mx1.freebsd.org (Postfix) with SMTP id 87A9E240 for ; Sat, 22 Nov 2014 20:56:35 +0000 (UTC) Received: (qmail 1197 invoked from network) for freebsd-arm@freebsd.org; 22 Nov 2014 14:56:34 -0600 Received: from 71-211-193-1.hlrn.qwest.net (HELO ?192.168.1.3?) (draymond@71.211.193.1) by mail.foxvalley.net with SMTP; 22 Nov 2014 14:56:34 -0600 Message-ID: <5470F87D.1040208@foxvalley.net> Date: Sat, 22 Nov 2014 13:56:29 -0700 From: Dan Raymond User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ticso@cicely.de Subject: Re: new support for Raspberry Pi B+ References: <5470E81A.3070009@foxvalley.net> <20141122200952.GA22446@cicely7.cicely.de> In-Reply-To: <20141122200952.GA22446@cicely7.cicely.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 20:56:35 -0000 On 11/22/2014 1:09 PM, Bernd Walter wrote: > On Sat, Nov 22, 2014 at 12:46:34PM -0700, Dan Raymond wrote: >> Further testing with the 16GB Kingston reveals that it is unstable even >> at low speed. I hit the following panic while executing "portsnap fetch >> update" on a r274416 build: >> >> dev = mmcsd0s2a, ino = 155101, fs = /mnt/ufs >> panic: ffs_freefile: freeing free inode >> KDB: enter: panic >> [ thread pid 8 tid 100056 ] >> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >> db> > Maybe you've received a counterfeit. > Unfortunately there are a lot of them on the market. > Some of them are technically smaller than they claim and overwrite > other data if they run short. I considered that originally which is why I bought 4 different cards of different brands for testing (Transcend, SanDisk, Samsung, Kingston): http://www.amazon.com/gp/product/B00CBD0XSI/ref=oh_aui_detailpage_o06_s00?ie=UTF8&psc=1 http://www.amazon.com/gp/product/B00M55C0NS/ref=oh_aui_detailpage_o04_s00?ie=UTF8&psc=1 http://www.amazon.com/gp/product/B00IVPU7DQ/ref=oh_aui_detailpage_o03_s00?ie=UTF8&psc=1 http://www.amazon.com/gp/product/B003WIRFD2/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1 None of them will boot FreeBSD at high speed and I have seen SD related panics with 3 of them (so far) at low speed. From owner-freebsd-arm@FreeBSD.ORG Sat Nov 22 21:06:02 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B41FDC2 for ; Sat, 22 Nov 2014 21:06:02 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5EE9D356 for ; Sat, 22 Nov 2014 21:06:02 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XsHsR-0005mL-1F; Sat, 22 Nov 2014 21:05:55 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sAML5rVS006968; Sat, 22 Nov 2014 14:05:53 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 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/YDEirbI5ki3tgbQqN1sHO X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: new support for Raspberry Pi B+ From: Ian Lepore To: Dan Raymond In-Reply-To: <5470F87D.1040208@foxvalley.net> References: <5470E81A.3070009@foxvalley.net> <20141122200952.GA22446@cicely7.cicely.de> <5470F87D.1040208@foxvalley.net> Content-Type: text/plain; charset="us-ascii" Date: Sat, 22 Nov 2014 14:05:52 -0700 Message-ID: <1416690352.1147.333.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" , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 21:06:02 -0000 On Sat, 2014-11-22 at 13:56 -0700, Dan Raymond wrote: > On 11/22/2014 1:09 PM, Bernd Walter wrote: > > On Sat, Nov 22, 2014 at 12:46:34PM -0700, Dan Raymond wrote: > >> Further testing with the 16GB Kingston reveals that it is unstable even > >> at low speed. I hit the following panic while executing "portsnap fetch > >> update" on a r274416 build: > >> > >> dev = mmcsd0s2a, ino = 155101, fs = /mnt/ufs > >> panic: ffs_freefile: freeing free inode > >> KDB: enter: panic > >> [ thread pid 8 tid 100056 ] > >> Stopped at $d: ldrb r15, [r15, r15, ror r15]! > >> db> > > Maybe you've received a counterfeit. > > Unfortunately there are a lot of them on the market. > > Some of them are technically smaller than they claim and overwrite > > other data if they run short. > > I considered that originally which is why I bought 4 different cards of > different brands for testing (Transcend, SanDisk, Samsung, Kingston): > > http://www.amazon.com/gp/product/B00CBD0XSI/ref=oh_aui_detailpage_o06_s00?ie=UTF8&psc=1 > http://www.amazon.com/gp/product/B00M55C0NS/ref=oh_aui_detailpage_o04_s00?ie=UTF8&psc=1 > http://www.amazon.com/gp/product/B00IVPU7DQ/ref=oh_aui_detailpage_o03_s00?ie=UTF8&psc=1 > http://www.amazon.com/gp/product/B003WIRFD2/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1 > > None of them will boot FreeBSD at high speed and I have seen SD related > panics with 3 of them (so far) at low speed. I would actually dispute that this one is an sd-related panic, unless you have messages about gvfs_iodone failures on the console before the panic. Otherwise this is more likely another memory corruption problem similar to the panics being reported on wandboard. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Nov 22 21:20:18 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F229938C for ; Sat, 22 Nov 2014 21:20:18 +0000 (UTC) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C00556D2 for ; Sat, 22 Nov 2014 21:20:18 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id rd3so7145185pab.28 for ; Sat, 22 Nov 2014 13:20:12 -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:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ad95WCIsqPFnN5EcKDJf0+XtXOwROIml8M34R9NlF8A=; b=arUisUozYIhNXWBg6H2U14oPlq+ih/n/3c4G9d4WNov6Fu9Lm4v+wBK+uS/w6kRYPc MDA5pOiLC/ctmJNn1fn13zcV0jCNIdcuiR+Moub1aIkwv5QsLaBxYOPGc4t+oWtqgAyP /gnZT4uWYZIJFEtv3cEBjHrgYJ5wzRDuTntMFc3fuGIOGe8SAOi2jtiSHpivjqCnjzuD WG0tBj56As2ajvI5FfU0TM0A4G2S8lYnMzQ/t5/jr3TZl4k7TB/yfUuJwojZSTvWk7EL yGerBsxQ/CwmzilZm+IY/A8PqxFNwfxSsAB0dC/V1Au85Bv30yQ0nwDwJlFwxMF2qIAg 6dpg== X-Gm-Message-State: ALoCoQnSjYTitrJvCf9jmr/b9sk0887gH9FXbRttiexfsbMiRhx1VN/LVPCl9UQ4hXwhwMEnQ94l X-Received: by 10.70.96.228 with SMTP id dv4mr19182077pdb.105.1416691211912; Sat, 22 Nov 2014 13:20:11 -0800 (PST) Received: from lgmac-stuffs.corp.netflix.com ([69.53.236.236]) by mx.google.com with ESMTPSA id j3sm8237644pde.22.2014.11.22.13.20.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 22 Nov 2014 13:20:11 -0800 (PST) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_D1421D4D-375B-4842-B45B-1E76EB0DF67A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: new support for Raspberry Pi B+ From: Warner Losh In-Reply-To: <1416690352.1147.333.camel@revolution.hippie.lan> Date: Sat, 22 Nov 2014 14:20:02 -0700 Message-Id: References: <5470E81A.3070009@foxvalley.net> <20141122200952.GA22446@cicely7.cicely.de> <5470F87D.1040208@foxvalley.net> <1416690352.1147.333.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-arm@freebsd.org" , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 21:20:19 -0000 --Apple-Mail=_D1421D4D-375B-4842-B45B-1E76EB0DF67A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 22, 2014, at 2:05 PM, Ian Lepore wrote: > On Sat, 2014-11-22 at 13:56 -0700, Dan Raymond wrote: >> On 11/22/2014 1:09 PM, Bernd Walter wrote: >>> On Sat, Nov 22, 2014 at 12:46:34PM -0700, Dan Raymond wrote: >>>> Further testing with the 16GB Kingston reveals that it is unstable = even >>>> at low speed. I hit the following panic while executing "portsnap = fetch >>>> update" on a r274416 build: >>>>=20 >>>> dev =3D mmcsd0s2a, ino =3D 155101, fs =3D /mnt/ufs >>>> panic: ffs_freefile: freeing free inode >>>> KDB: enter: panic >>>> [ thread pid 8 tid 100056 ] >>>> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >>>> db> >>> Maybe you've received a counterfeit. >>> Unfortunately there are a lot of them on the market. >>> Some of them are technically smaller than they claim and overwrite >>> other data if they run short. >>=20 >> I considered that originally which is why I bought 4 different cards = of=20 >> different brands for testing (Transcend, SanDisk, Samsung, Kingston): >>=20 >> = http://www.amazon.com/gp/product/B00CBD0XSI/ref=3Doh_aui_detailpage_o06_s0= 0?ie=3DUTF8&psc=3D1 >> = http://www.amazon.com/gp/product/B00M55C0NS/ref=3Doh_aui_detailpage_o04_s0= 0?ie=3DUTF8&psc=3D1 >> = http://www.amazon.com/gp/product/B00IVPU7DQ/ref=3Doh_aui_detailpage_o03_s0= 0?ie=3DUTF8&psc=3D1 >> = http://www.amazon.com/gp/product/B003WIRFD2/ref=3Doh_aui_detailpage_o01_s0= 0?ie=3DUTF8&psc=3D1 >>=20 >> None of them will boot FreeBSD at high speed and I have seen SD = related=20 >> panics with 3 of them (so far) at low speed. >=20 > I would actually dispute that this one is an sd-related panic, unless > you have messages about gvfs_iodone failures on the console before the > panic. Otherwise this is more likely another memory corruption = problem > similar to the panics being reported on wandboard. The RPi is also sensitive to power. I=92ve seen weird corruption like = this when I tried to run my RPi off a battery and the battery was getting weak... Warner --Apple-Mail=_D1421D4D-375B-4842-B45B-1E76EB0DF67A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUcP4CAAoJEGwc0Sh9sBEAEC0QAIJZBVauxHunOh32kf2HKxVq +dH+lW64MYtbByWwoR+tdPt7K1PKUV59D7lu/i6NFgUMIyasy33YZMH96+dQHqZ+ jSYH62XqnrNsgHkr/G4vhX4lW24pa/bbwzeh0EaXrOF5Pt5sX6IYTfSoNscEL8ir eK5StD07wE7h3jaZTvLWGR0vNkugASzOOBTkbXrMGmHuri+BatEGdM0R9PZP0Ktt ikSw40PrHP0OdaLqYxtVI91/l34QTjJHvg8R0iQ8MzRH4f4Td7TMkp1w3PAhddNu NsYUdmtEd/h2goZJUFHDWsiwCVAD1pzffZ/5Ksp9meGjV3ZjyT99m6Qe/x7iy5tJ xAhKPO0P/poXI0uPL3hxpiiohb4+VOYsM7tarKBTZaq0VVVQhP3GE4QU+roi1hMS PEo1/E/B7PUmUJvzL21VteOGznhznTNX1PVjDD8V8FirQE5qaOlJd9Cw5PL+edWq haeM5p0ho5awndqXeuYGbn8c2TJD2ZTf/oEHYDDpWsHGxfQHClnlOF7FQ8DRvfP3 CkSeZh2IkL+Paw12bRWkyrekS6xMOZwYCtTu/3CWvlLytUiUKnmGTIRUdN6QPNXe 3FJzwLEXThV2WD57jTVs/c6J2SrMpz5+++XJXZ4vZu1N8goHuyq88S0lswzZNj8x 7GvxEClxfGFp7s1XyAJH =7s27 -----END PGP SIGNATURE----- --Apple-Mail=_D1421D4D-375B-4842-B45B-1E76EB0DF67A-- From owner-freebsd-arm@FreeBSD.ORG Sat Nov 22 21:33:00 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 095546A0; Sat, 22 Nov 2014 21:33:00 +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)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 910077F9; Sat, 22 Nov 2014 21:32:58 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id sAMLW4vU054607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 22 Nov 2014 22:32:28 +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 sAMLVuPL025476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Nov 2014 22:31:56 +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 sAMLVuEY024016; Sat, 22 Nov 2014 22:31:56 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id sAMLVtEd024015; Sat, 22 Nov 2014 22:31:55 +0100 (CET) (envelope-from ticso) Date: Sat, 22 Nov 2014 22:31:55 +0100 From: Bernd Walter To: Warner Losh Subject: Re: new support for Raspberry Pi B+ Message-ID: <20141122213155.GB22446@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <5470E81A.3070009@foxvalley.net> <20141122200952.GA22446@cicely7.cicely.de> <5470F87D.1040208@foxvalley.net> <1416690352.1147.333.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: "freebsd-arm@freebsd.org" , ticso@cicely.de, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 21:33:00 -0000 On Sat, Nov 22, 2014 at 02:20:02PM -0700, Warner Losh wrote: > > On Nov 22, 2014, at 2:05 PM, Ian Lepore wrote: > > > On Sat, 2014-11-22 at 13:56 -0700, Dan Raymond wrote: > >> On 11/22/2014 1:09 PM, Bernd Walter wrote: > >>> On Sat, Nov 22, 2014 at 12:46:34PM -0700, Dan Raymond wrote: > >>>> Further testing with the 16GB Kingston reveals that it is unstable even > >>>> at low speed. I hit the following panic while executing "portsnap fetch > >>>> update" on a r274416 build: > >>>> > >>>> dev = mmcsd0s2a, ino = 155101, fs = /mnt/ufs > >>>> panic: ffs_freefile: freeing free inode > >>>> KDB: enter: panic > >>>> [ thread pid 8 tid 100056 ] > >>>> Stopped at $d: ldrb r15, [r15, r15, ror r15]! > >>>> db> > >>> Maybe you've received a counterfeit. > >>> Unfortunately there are a lot of them on the market. > >>> Some of them are technically smaller than they claim and overwrite > >>> other data if they run short. > >> > >> I considered that originally which is why I bought 4 different cards of > >> different brands for testing (Transcend, SanDisk, Samsung, Kingston): > >> > >> http://www.amazon.com/gp/product/B00CBD0XSI/ref=oh_aui_detailpage_o06_s00?ie=UTF8&psc=1 > >> http://www.amazon.com/gp/product/B00M55C0NS/ref=oh_aui_detailpage_o04_s00?ie=UTF8&psc=1 > >> http://www.amazon.com/gp/product/B00IVPU7DQ/ref=oh_aui_detailpage_o03_s00?ie=UTF8&psc=1 > >> http://www.amazon.com/gp/product/B003WIRFD2/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1 > >> > >> None of them will boot FreeBSD at high speed and I have seen SD related > >> panics with 3 of them (so far) at low speed. Well high speed seems to be a different issue. But if it happens on multiple different cards, then the corruption is unlikely card related. > > I would actually dispute that this one is an sd-related panic, unless > > you have messages about gvfs_iodone failures on the console before the > > panic. Otherwise this is more likely another memory corruption problem > > similar to the panics being reported on wandboard. > > The RPi is also sensitive to power. I?ve seen weird corruption like this when I tried to run > my RPi off a battery and the battery was getting weak... They completely redesigned the power design in the B+, including the use of decent switching regulators. Assuming the problem happens on a B+ as the subject claims. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sat Nov 22 22:00: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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF1D1FD8 for ; Sat, 22 Nov 2014 22:00:22 +0000 (UTC) Received: from mail.FoxValley.net (mail.FoxValley.net [64.135.192.34]) by mx1.freebsd.org (Postfix) with SMTP id 7615B9FA for ; Sat, 22 Nov 2014 22:00:21 +0000 (UTC) Received: (qmail 28252 invoked from network) for freebsd-arm@freebsd.org; 22 Nov 2014 16:00:20 -0600 Received: from 71-211-193-1.hlrn.qwest.net (HELO ?192.168.1.3?) (draymond@71.211.193.1) by mail.foxvalley.net with SMTP; 22 Nov 2014 16:00:20 -0600 Message-ID: <54710770.5040801@foxvalley.net> Date: Sat, 22 Nov 2014 15:00:16 -0700 From: Dan Raymond User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ticso@cicely.de, Warner Losh Subject: Re: new support for Raspberry Pi B+ References: <5470E81A.3070009@foxvalley.net> <20141122200952.GA22446@cicely7.cicely.de> <5470F87D.1040208@foxvalley.net> <1416690352.1147.333.camel@revolution.hippie.lan> <20141122213155.GB22446@cicely7.cicely.de> In-Reply-To: <20141122213155.GB22446@cicely7.cicely.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 22:00:22 -0000 >> I considered that originally which is why I bought 4 different cards of >> different brands for testing (Transcend, SanDisk, Samsung, Kingston): >> >> http://www.amazon.com/gp/product/B00CBD0XSI/ref=oh_aui_detailpage_o06_s00?ie=UTF8&psc=1 >> http://www.amazon.com/gp/product/B00M55C0NS/ref=oh_aui_detailpage_o04_s00?ie=UTF8&psc=1 >> http://www.amazon.com/gp/product/B00IVPU7DQ/ref=oh_aui_detailpage_o03_s00?ie=UTF8&psc=1 >> http://www.amazon.com/gp/product/B003WIRFD2/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1 >> >> None of them will boot FreeBSD at high speed and I have seen SD related >> panics with 3 of them (so far) at low speed. > Well high speed seems to be a different issue. > But if it happens on multiple different cards, then the corruption is unlikely > card related. > >>> I would actually dispute that this one is an sd-related panic, unless >>> you have messages about gvfs_iodone failures on the console before the >>> panic. Otherwise this is more likely another memory corruption problem >>> similar to the panics being reported on wandboard. >> The RPi is also sensitive to power. I?ve seen weird corruption like this when I tried to run >> my RPi off a battery and the battery was getting weak... > They completely redesigned the power design in the B+, including the > use of decent switching regulators. > Assuming the problem happens on a B+ as the subject claims. > Yes, it is a Raspberry Pi B+. I just received a second one yesterday to do more testing and I am experiencing issues on this one too. From owner-freebsd-arm@FreeBSD.ORG Sat Nov 22 22:26:10 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3F13A10 for ; Sat, 22 Nov 2014 22:26:10 +0000 (UTC) Received: from mail.FoxValley.net (mail.FoxValley.net [64.135.192.34]) by mx1.freebsd.org (Postfix) with SMTP id 76D2FC62 for ; Sat, 22 Nov 2014 22:26:10 +0000 (UTC) Received: (qmail 3105 invoked from network) for freebsd-arm@freebsd.org; 22 Nov 2014 16:26:09 -0600 Received: from 71-211-193-1.hlrn.qwest.net (HELO ?192.168.1.3?) (draymond@71.211.193.1) by mail.foxvalley.net with SMTP; 22 Nov 2014 16:26:09 -0600 Message-ID: <54710D7D.3000303@foxvalley.net> Date: Sat, 22 Nov 2014 15:26:05 -0700 From: Dan Raymond User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: latest VM images fail to compile for ARM Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 22:26:10 -0000 The latest two VM images here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/11.0-CURRENT/amd64/ are: FreeBSD-11.0-CURRENT-amd64-20141025-r273635.vmdk.xz FreeBSD-11.0-CURRENT-amd64-20141113-r274463.vmdk.xz They won't compile ARM images using crochet. I am getting errors while building xdev. This looks like a regression because I have no problems with the previous VM image (FreeBSD-11.0-CURRENT-amd64-20140918-r271779.vmdk.xz).