From owner-freebsd-arm@FreeBSD.ORG Sun Apr 28 01:59:42 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 686A58C6 for ; Sun, 28 Apr 2013 01:59:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 0689412F3 for ; Sun, 28 Apr 2013 01:59:41 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id e11so2814940wgh.1 for ; Sat, 27 Apr 2013 18:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=t/e0bLEwr5m8Jzkef8wu2s0OkARcjK8hzWJCq9w8Ntc=; b=gp+FBCLUCSxXjQHV0+PanfQSRAQf0fEaWwcW5QZ/FhneKhMn1OG8srLzcy9zNaFjD5 Qp13IAv9g47tzXT3LPlID8eryl1x9xN/ExGcTSq41B3WDUfZYfTKW18Hnuh3DKPI6vod Ub2xoiW0beCoeMi3WMz+A279pVq9cPD7B+7eB7m90zul/BglAQTe8fY8Pe9h3P0Erkta lMfhllLJswGSaXa7WvPXzjHKZ1U3u2W1bxtfpLBMgEFlVxIEs16ZGtA+FA7kJLCRhg5s 4x7W86u4PJo8S5H4eI9dBGwNYgNhIo+AgRuJmXu4TufeMFsa8TZFtrYk+ix3oDfUVksl mlRQ== MIME-Version: 1.0 X-Received: by 10.180.93.134 with SMTP id cu6mr10906824wib.8.1367114381188; Sat, 27 Apr 2013 18:59:41 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.58.138 with HTTP; Sat, 27 Apr 2013 18:59:40 -0700 (PDT) Date: Sat, 27 Apr 2013 18:59:40 -0700 X-Google-Sender-Auth: Jz1L4mkYhO9GkLS8KRtFdiAnSfk Message-ID: Subject: zedboard article / howto? From: Adrian Chadd To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 01:59:42 -0000 Hi! I saw the zedboard support show up recently in -HEAD. Is there any documentation in the wiki yet for it? Would anyone be willing to write up an article about it? Adrian From owner-freebsd-arm@FreeBSD.ORG Sun Apr 28 02:45:14 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AC8FAADC for ; Sun, 28 Apr 2013 02:45:14 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 690E914FF for ; Sun, 28 Apr 2013 02:45:14 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UWHAS-000Iw6-T0 for arm@freebsd.org; Sat, 27 Apr 2013 19:16:46 -0700 Message-ID: <517C868B.4060002@bluezbox.com> Date: Sat, 27 Apr 2013 19:16:43 -0700 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: arm@freebsd.org Subject: clang/ARM regression Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Hi, There seems to be some kind of regression in recently imported clang on ARM. Beaglebone kernel built using clang with WITNESS enabled panics on boot. If I change optimization flags from -O to -O0 it works fine. I'm trying to isolate test case but it panics fairly early in boot process so it's not easy. If somebody tracks clang development and aware of known issues that might cause it - please share. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 02:45:14 -0000 Hi, There seems to be some kind of regression in recently imported clang on ARM. Beaglebone kernel built using clang with WITNESS enabled panics on boot. If I change optimization flags from -O to -O0 it works fine. I'm trying to isolate test case but it panics fairly early in boot process so it's not easy. If somebody tracks clang development and aware of known issues that might cause it - please share. So far I tried fix from this bug but it didn't help: http://llvm.org/bugs/show_bug.cgi?id=15581 From owner-freebsd-arm@FreeBSD.ORG Sun Apr 28 02:50:19 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6ABBDB2F for ; Sun, 28 Apr 2013 02:50:19 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x22a.google.com (mail-ia0-x22a.google.com [IPv6:2607:f8b0:4001:c02::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 3EADB150E for ; Sun, 28 Apr 2013 02:50:19 +0000 (UTC) Received: by mail-ia0-f170.google.com with SMTP id k20so1669422iak.15 for ; Sat, 27 Apr 2013 19:50:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=gFzML5nFZloAdYIO62jjGID4e+4ePSLbAa0Q1O23sy4=; b=btPX8/nQ/QE50bgrUxOb5HsfQjRHcRAoTniYVyigNlDZ8GQTy8PLfcrLbOBkPHrFWe Fpeh3ZQXdywC/+qdaVe0fj1ehS3q9H403VFSeCA84OD9aOGPnIuLqGXb6jyjnxXM0fzt i0Ap/38j2GT2WNvJWa+b5g32+VIfEnBlyWXWNqho5MbvBHRswhX9rYAENBkiD9vvYUUK I3XWbAt94y3PwY6EzB9xFCKGrKjjdI8sRItn4wAGxWyu3RR0D7+u7+MnWHFe79gIH9f8 RYe4/6WUApg3UMd6p2oImqBOfn1xYCzWCrluWwLDUDg1DM7HZmUNj5d6XDumGR3E3CVI bkhg== X-Received: by 10.50.153.43 with SMTP id vd11mr5043680igb.13.1367117418140; Sat, 27 Apr 2013 19:50:18 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id o10sm11909302igh.2.2013.04.27.19.50.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Apr 2013 19:50:17 -0700 (PDT) Sender: Warner Losh Subject: Re: clang/ARM regression Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <517C868B.4060002@bluezbox.com> Date: Sat, 27 Apr 2013 20:50:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <517C868B.4060002@bluezbox.com> To: Oleksandr Tymoshenko X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlQipp4gHHViwT12/1KNZOhGYLMvVR9b/osS/yUPmz4xdMIxzGMnUNwJmfngeGEc6B6uVtT Cc: arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 02:50:19 -0000 Turning WITNESS off also fixes it :) Sadly, the stack traceback stuff seems busted lately too... Warner On Apr 27, 2013, at 8:16 PM, Oleksandr Tymoshenko wrote: > Hi, >=20 > There seems to be some kind of regression in recently imported clang = on ARM. > Beaglebone kernel built using clang with WITNESS enabled panics > on boot. If I change optimization flags from -O to -O0 it works fine. > I'm trying to isolate test case but it panics fairly early in boot = process > so it's not easy. If somebody tracks clang development and aware of > known issues that might cause it - please share. >=20 > So far I tried fix from this bug but it didn't help: > http://llvm.org/bugs/show_bug.cgi?id=3D15581 >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sun Apr 28 06:47:46 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CAFB05D4; Sun, 28 Apr 2013 06:47:46 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id AA2131B65; Sun, 28 Apr 2013 06:47:45 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r3S6lijt062470; Sun, 28 Apr 2013 06:47:44 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id a32a6vrkjubqchtwyzdc4yjw8w; Sun, 28 Apr 2013 06:47:44 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: BeagleBone Black Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <54A0884D-31D0-4FC6-BBB5-58E3D11050E6@freebsd.org> Date: Sat, 27 Apr 2013 23:47:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <26A08C89-95EA-463D-98C5-A471F8D15C90@freebsd.org> <54A0884D-31D0-4FC6-BBB5-58E3D11050E6@freebsd.org> To: George Neville-Neil X-Mailer: Apple Mail (2.1283) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 06:47:46 -0000 > I have mine now but I think that the USB drivers need an update. It's = not recognized when > I plug it in. The last update to uftdi on my box is April 15th. I'll = go check if there's a newer one > and/or if I need to add a value for the new board. Just got mine a few minutes ago=85 Apparently, the BeagleBone Black lacks the built-in serial to USB = adapter that the original BeagleBone had. Serial is available on a = 6-pin header that should work with common 3.3v serial-to-USB adapters. = I'll try it in the morning. It looks like the 2GB Flash takes the form of an eMMC connected to the = second MMC interface. So it should be straightforward to add support = for it. With 8-bit support, it should be a lot faster than a uSD card. = We'll see. Past bedtime. Darn. ;-) Tim P.S. I really hate blue LEDs. From owner-freebsd-arm@FreeBSD.ORG Sun Apr 28 07:14:01 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4BBE08B7; Sun, 28 Apr 2013 07:14:01 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 29A7C1BCF; Sun, 28 Apr 2013 07:14:00 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r3S7E0JF062595; Sun, 28 Apr 2013 07:14:00 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id rmngrwijks2dz2zfj4hk3bvyvw; Sun, 28 Apr 2013 07:14:00 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: BeagleBone Black Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: Date: Sun, 28 Apr 2013 00:13:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <77E91A57-7880-4908-8999-6115333F5002@kientzle.com> References: <26A08C89-95EA-463D-98C5-A471F8D15C90@freebsd.org> <54A0884D-31D0-4FC6-BBB5-58E3D11050E6@freebsd.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1283) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 07:14:01 -0000 On Apr 27, 2013, at 11:47 PM, Tim Kientzle wrote: >> I have mine now but I think that the USB drivers need an update. = It's not recognized when >> I plug it in. The last update to uftdi on my box is April 15th. = I'll go check if there's a newer one >> and/or if I need to add a value for the new board. >=20 > Just got mine a few minutes ago=85 >=20 > Apparently, the BeagleBone Black lacks the built-in serial to USB = adapter that the original BeagleBone had. Serial is available on a = 6-pin header that should work with common 3.3v serial-to-USB adapters. = I'll try it in the morning. The 4-pin adapter I got from Adafruit for use with Raspberry Pi seems to work just fine, though the CircuitCo documentation has the = instructions wrong. It should be: Black =3D> Pin 1 Green =3D> Pin 4 White =3D> Pin 5 > It looks like the 2GB Flash takes the form of an eMMC connected to the = second MMC interface. So it should be straightforward to add support = for it. With 8-bit support, it should be a lot faster than a uSD card. = We'll see. Harumph. Looks like it always boots initially from the eMMC and U-Boot then looks at the boot switch to decide whether to continue from eMMC or uSD. This sucks: the U-Boot on the eMMC doesn't have ELF support nor API support so can't load and boot ubldr. Short version: The existing FreeBSD images for BeagleBone won't work as-is. At a minimum, we'll have to replace the U-Boot on the eMMC with one that has ELF and API enabled. I guess I'll be spending more quality time with U-Boot. :-/ Tim From owner-freebsd-arm@FreeBSD.ORG Sun Apr 28 07:20:44 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D794B93B; Sun, 28 Apr 2013 07:20:44 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id A30571BF6; Sun, 28 Apr 2013 07:20:44 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r3S7KhhW062637; Sun, 28 Apr 2013 07:20:44 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id ibf2y3yru68ky336fxtvcgxnmw; Sun, 28 Apr 2013 07:20:43 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: zedboard article / howto? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Sun, 28 Apr 2013 00:20:43 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Adrian Chadd X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 07:20:44 -0000 On Apr 27, 2013, at 6:59 PM, Adrian Chadd wrote: > Hi! > > I saw the zedboard support show up recently in -HEAD. I copied Thomas' board-building outline into Crochet. I don't have one, though, so I can't tell if it works. From owner-freebsd-arm@FreeBSD.ORG Sun Apr 28 07:49:55 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 560B7CAA for ; Sun, 28 Apr 2013 07:49:55 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id 302A41C54 for ; Sun, 28 Apr 2013 07:49:55 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id bn7so6344217ieb.27 for ; Sun, 28 Apr 2013 00:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=IG6Ynqgbzj7XptCI4VhNpaxdo4Cjzpo2yg4W442HB0M=; b=NkIvMbL+ph6KwKMg+zUONl4DNEwNLLFqL1DSNjLuA/uAb5V6QaDGY0zlmi06+dfj5V htl462FmSlBiQ+KTV5X0gOYwANcIXSCAtS0lM2kY9DdzkqI5zguo0c213nclze0WK8Nk ba+urdLLKIHsBEQfIQ2IUCuNESppiEOUz/AYDXJghHpdA4B6KZvMR5ybbQJZvycs/J5J 9UJ5tj2wTJ/FxOj9p/gPxoyf+xrsXIP//GEiINSPFoCB2reBVAoAqPSQReuVbSRviOPx dFUBqbyuk04sTyUwbXvHNzMa62+NZXrl6GgY+/nbr0Bf6bpjO7t3yr3GHC5GXzSD3X6L +j6w== MIME-Version: 1.0 X-Received: by 10.42.203.68 with SMTP id fh4mr12785536icb.36.1367135394778; Sun, 28 Apr 2013 00:49:54 -0700 (PDT) Received: by 10.50.92.34 with HTTP; Sun, 28 Apr 2013 00:49:54 -0700 (PDT) Date: Sun, 28 Apr 2013 09:49:54 +0200 Message-ID: Subject: Raspberry Pi VM tests From: Tom Vijlbrief To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 07:49:55 -0000 I did some testing to see if I could reproduce the strange killed processes which I experienced during build world on my 256MB RPI. I disabled the swap partition on my USB drive and did some testing with the "stress" program from ports: stress --vm 1 --vm-bytes 200M --vm-keep results in dmesg: pid 664 (stress), uid 1000, was killed: out of swap space That's logical. Next I did a stress --vm 1 --vm-bytes 150M --vm-keep and a few moments later: pid 606 (sshd), uid 0: exited on signal 11 pid 610 (cron), uid 0: exited on signal 11 (core dumped) This should NOT happen. Another problem is that i tried a large zmodem upload on the serial console of a 10MB file. Minicom and sz on the sending site, rz (from lrzsz from ports) on the receiving site. This works, but if I run a compile in another ssh session during the transfer then the transfer hangs and the serial console will no longer handle any input. Killing the console shell results in a new getty but it cannot receive any input. It's dead. data > /dev/console does show output however. I use a kernel from a current tree a few days old. Can others reproduce these problems? From owner-freebsd-arm@FreeBSD.ORG Sun Apr 28 09:37:06 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3EB6FB5 for ; Sun, 28 Apr 2013 09:37:06 +0000 (UTC) (envelope-from iain@g7iii.net) Received: from hal.g7iii.net (unknown [IPv6:2600:3c02::f03c:91ff:feae:1cbe]) by mx1.freebsd.org (Postfix) with ESMTP id 209181F43 for ; Sun, 28 Apr 2013 09:37:05 +0000 (UTC) Received: from [192.168.39.76] (157.17.187.81.in-addr.arpa [81.187.17.157]) by hal.g7iii.net (Postfix) with ESMTP id C9998208F5 for ; Sun, 28 Apr 2013 09:37:04 +0000 (UTC) Message-ID: <517CEDBF.3090102@g7iii.net> Date: Sun, 28 Apr 2013 10:37:03 +0100 From: Iain Young User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: BeagleBone Black References: <26A08C89-95EA-463D-98C5-A471F8D15C90@freebsd.org> <54A0884D-31D0-4FC6-BBB5-58E3D11050E6@freebsd.org> <77E91A57-7880-4908-8999-6115333F5002@kientzle.com> In-Reply-To: <77E91A57-7880-4908-8999-6115333F5002@kientzle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 09:37:06 -0000 On 28/04/13 08:13, Tim Kientzle wrote: > The 4-pin adapter I got from Adafruit for use with Raspberry Pi seems > to work just fine, though the CircuitCo documentation has the instructions > wrong. It should be: > Black => Pin 1 > Green => Pin 4 > White => Pin 5 Hurm, I wonder what the other 3 pins are used for. They seem to be undocumented in the SRM [SNIP] > Harumph. Looks like it always boots initially from the eMMC and > U-Boot then looks at the boot switch to decide whether to continue > from eMMC or uSD. This would appear to be the default behaviour, but can be over-ridden if I read the SRM correctly. For a one off force to uSD boot, hold down the "boot" button". See Page 57 of the SRM > This sucks: the U-Boot on the eMMC doesn't have ELF support > nor API support so can't load and boot ubldr. > > Short version: The existing FreeBSD images for BeagleBone > won't work as-is. At a minimum, we'll have to replace the U-Boot > on the eMMC with one that has ELF and API enabled. I guess > I'll be spending more quality time with U-Boot. :-/ Or wipe the eMMC. In that case, then it appears it boots off the uSD card next. (Yes, I know for general user usage this wouldn't be acceptable, but for us hackers, it would be a quick way to get the board up and running in userspace and checkout any other changes that might need fixups..) Best Regards Iain From owner-freebsd-arm@FreeBSD.ORG Sun Apr 28 11:06:47 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 03467887 for ; Sun, 28 Apr 2013 11:06:47 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-ia0-x236.google.com (mail-ia0-x236.google.com [IPv6:2607:f8b0:4001:c02::236]) by mx1.freebsd.org (Postfix) with ESMTP id D0D3D1114 for ; Sun, 28 Apr 2013 11:06:46 +0000 (UTC) Received: by mail-ia0-f182.google.com with SMTP id w33so2504797iag.27 for ; Sun, 28 Apr 2013 04:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=+ONWONzivAkf8atILPhs4Q48y5oHGNEZjKJLNL5TDmw=; b=Fb7EePm9ZRqRY2hlXLUfiylKFwsZkL9q/RYge6coRjpgsxGk/egkZNRuce2y4NhSTk Ji+86GzP57HfqK8e+EY9h+SZz3RAgeOZausO0vhLGe95CqQTT5Cfe18gmJPOHJ2SbEf+ 5w1aVJzwO6VqKef1vdzgz/5ELo2vWmZ8jcZA7B8LmdOfow0eEeWXtuHsvTivUx/aaDXM hyOOk38K8GDBBmlXwg0FPBzxvoqFlJRA+dA144jmfKpjBuuB32fR79iWphHhcggMJfq8 fP7h0U1fRd2KfB/qsnxrVzygRkBfbnSR1CumfydFv7yRAcUhChLb+T2DjtSe86xsOeQp ZWSw== MIME-Version: 1.0 X-Received: by 10.50.50.8 with SMTP id y8mr5592198ign.55.1367147206537; Sun, 28 Apr 2013 04:06:46 -0700 (PDT) Received: by 10.50.92.34 with HTTP; Sun, 28 Apr 2013 04:06:46 -0700 (PDT) Date: Sun, 28 Apr 2013 13:06:46 +0200 Message-ID: Subject: Re: Raspberry Pi VM tests From: Tom Vijlbrief To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 11:06:47 -0000 I used a GPU allocation of 16MB in my previous test (I use my Pi headless) I am now using gpu_mem=64 in config.txt and reattached my USB swap and I have no new killed processes. Could this be the cause? The serial console failure during large transfers issue remains. From owner-freebsd-arm@FreeBSD.ORG Sun Apr 28 16:26:50 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5874479A for ; Sun, 28 Apr 2013 16:26:50 +0000 (UTC) (envelope-from ThomasSkibo@sbcglobal.net) Received: from nm16.access.bullet.mail.mud.yahoo.com (nm16.access.bullet.mail.mud.yahoo.com [66.94.237.217]) by mx1.freebsd.org (Postfix) with ESMTP id F13BE1CB8 for ; Sun, 28 Apr 2013 16:26:49 +0000 (UTC) Received: from [66.94.237.196] by nm16.access.bullet.mail.mud.yahoo.com with NNFMP; 28 Apr 2013 16:20:23 -0000 Received: from [98.138.84.214] by tm7.access.bullet.mail.mud.yahoo.com with NNFMP; 28 Apr 2013 16:20:23 -0000 Received: from [127.0.0.1] by smtp103.sbc.mail.ne1.yahoo.com with NNFMP; 28 Apr 2013 16:20:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1367166023; bh=+We0Q+WLE+NW7oYm5/57QMeQCGBnXoQ8KY0NDQ/ZLp4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=6aSufm24SbkTayjqJWM3iqTw7H1mCit7ST7N2ky9N1DNyVrXsSjwdJe4iZcMxz+U/98CuIB/UaXMTjzYnEDuk5FeeT0SW+0L8l8SdKJq62G9X3pGUybsVlwnXk3EyT6DbB6t6qzCXOoSEXtPjsvwjB4/3KT67PrinBNEbMbHHyg= X-Yahoo-Newman-Id: 394539.97535.bm@smtp103.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: eqCiGv8VM1kRbG03aGgqUkV_Z7d_WTNUvCfDho9oOTuxZV1 JEfNyO_h.X2LRIcrLz9TKJl6QNSpLgSlyknFm5eDHu.L.WVv6Qr9bEJAR7ls .zoMG4.sqetr73tTsBs6ydbJKunDy6_cQwhM1bAsMxGJsr7iNIMhbq5QGKn7 S6z6Q421oeztiQS8.fhz.osTWboMblgNQidhGLVQBv74M6aJVhEAWV_Tnw6g C3E5eSNrpHUcJOEIsrcLGgtrA7hX5Q3HcC0hWwfsy2pVRug8ptIDU0YbP3wI TpouuAXu04PyHPBDmoatzCTvc_xx9YWWL_vYKsdzw7bEJk0e3ipo69zVXGUI 3bLqui2N0LYDmdy0uXYudb922CmRV128DIGqpJbftPyV.uCrcuuhMXjB9nz0 LeK3gNqNohFc77Wg4xv1pTN0_PNPL4EqTb3ZRQtO10dRYxOHYXAF4r8XHxhs 3Z.qM.V._bUljPTDD6mxyWw7CnJzwfPU.Ug-- X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- X-Rocket-Received: from [192.168.1.9] (ThomasSkibo@71.139.162.8 with plain) by smtp103.sbc.mail.ne1.yahoo.com with SMTP; 28 Apr 2013 16:20:23 +0000 UTC Message-ID: <517D4C46.1050106@sbcglobal.net> Date: Sun, 28 Apr 2013 09:20:22 -0700 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: zedboard article / howto? References: In-Reply-To: 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 16:26:50 -0000 I'm working on a page in the Wiki. What I have so far is at https://wiki.freebsd.org/FreeBSD/arm/Zedboard. I'll add a link from the FreeBSD/arm page now that it's in -HEAD. --Thomas On 4/27/13 6:59 PM, Adrian Chadd wrote: > Hi! > > I saw the zedboard support show up recently in -HEAD. > > Is there any documentation in the wiki yet for it? Would anyone be > willing to write up an article about it? > > > > Adrian > _______________________________________________ > 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" > -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Sun Apr 28 17:03:49 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E060F219 for ; Sun, 28 Apr 2013 17:03:49 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id A708F1D6A for ; Sun, 28 Apr 2013 17:03:48 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r3SH3lVY065841; Sun, 28 Apr 2013 17:03:47 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id e4mhyj7k7uxfwd89rf9agqp4ta; Sun, 28 Apr 2013 17:03:47 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: BeagleBone Black Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <517CEDBF.3090102@g7iii.net> Date: Sun, 28 Apr 2013 10:03:46 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <26A08C89-95EA-463D-98C5-A471F8D15C90@freebsd.org> <54A0884D-31D0-4FC6-BBB5-58E3D11050E6@freebsd.org> <77E91A57-7880-4908-8999-6115333F5002@kientzle.com> <517CEDBF.3090102@g7iii.net> To: Iain Young X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 17:03:49 -0000 On Apr 28, 2013, at 2:37 AM, Iain Young wrote: > On 28/04/13 08:13, Tim Kientzle wrote: > >> The 4-pin adapter I got from Adafruit for use with Raspberry Pi seems >> to work just fine, though the CircuitCo documentation has the instructions >> wrong. It should be: >> Black => Pin 1 >> Green => Pin 4 >> White => Pin 5 > > Hurm, I wonder what the other 3 pins are used for. They seem to be > undocumented in the SRM I believe they're unconnected. They're only there for compatibility with the common FTDI TTL-232R-3v3 USB-to-serial adapter that has a 6-pin connector. >> Harumph. Looks like it always boots initially from the eMMC and >> U-Boot then looks at the boot switch to decide whether to continue >> from eMMC or uSD. > > This would appear to be the default behaviour, but can be over-ridden > if I read the SRM correctly. For a one off force to uSD boot, hold down > the "boot" button". See Page 57 of the SRM Tried that, but from watching the serial console, it's still loading U-Boot from the eMMC. It's U-Boot that actually looks at that pin (there are some messages on the serial console about U-Boot inspecting a GPIO pin). >> This sucks: the U-Boot on the eMMC doesn't have ELF support >> nor API support so can't load and boot ubldr. >> >> Short version: The existing FreeBSD images for BeagleBone >> won't work as-is. At a minimum, we'll have to replace the U-Boot >> on the eMMC with one that has ELF and API enabled. I guess >> I'll be spending more quality time with U-Boot. :-/ > > Or wipe the eMMC. In that case, then it appears it boots off > the uSD card next. Yep. Or replace U-Boot on the eMMC, which is what I was hoping to look into today. The model that the BeagleBone seems to use for "installing a new OS" is basically a two-drive model (in essence, the micro-SD is drive 0 and the eMMC is drive 1): * Download an "installer image" to micro-SD. * Boot from that micro-SD/drive 0. * That "installer" copies the OS onto drive 1/eMMC * Reboot from eMMC. Tim From owner-freebsd-arm@FreeBSD.ORG Sun Apr 28 21:07:55 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9A929B9 for ; Sun, 28 Apr 2013 21:07:55 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from smtprelay-b31.telenor.se (smtprelay-b31.telenor.se [213.150.131.20]) by mx1.freebsd.org (Postfix) with ESMTP id 327B8151A for ; Sun, 28 Apr 2013 21:07:54 +0000 (UTC) Received: from ipb3.telenor.se (ipb3.telenor.se [195.54.127.166]) by smtprelay-b31.telenor.se (Postfix) with ESMTP id 49FE0EA6B6 for ; Sun, 28 Apr 2013 22:39:24 +0200 (CEST) X-SENDER-IP: [85.229.94.62] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtHMABOIfVFV5V4+PGdsb2JhbABTgwYBNrdNhnQEgQAXAwEBAQE4NYJYASOBMQwKDog5CJ0wnnUEjU0VG4E6gzkDjlaYI4RiOoEu X-IronPort-AV: E=Sophos;i="4.87,568,1363129200"; d="scan'208";a="322134097" Received: from c-3e5ee555.06-11-73746f31.cust.bredbandsbolaget.se (HELO sigyn.alvermark.net) ([85.229.94.62]) by ipb3.telenor.se with ESMTP; 28 Apr 2013 22:39:24 +0200 Received: from localhost ([127.0.0.1] helo=alvermark.net) by sigyn.alvermark.net with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UWYNX-000LCa-4n for freebsd-arm@freebsd.org; Sun, 28 Apr 2013 22:39:23 +0200 Received: from 85.229.95.25 (SquirrelMail authenticated user alvis) by alvermark.net with HTTP; Sun, 28 Apr 2013 22:39:23 +0200 (CEST) Message-ID: <53141.85.229.95.25.1367181563.squirrel@alvermark.net> Date: Sun, 28 Apr 2013 22:39:23 +0200 (CEST) Subject: could not process 'interrupts' property From: "Jakob Alvermark" To: freebsd-arm@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 21:07:55 -0000 Hi! I got my hands on an Olinuxino A13 (https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino/) It is based on the Allwinner A13, which is a stripped down A10 (no SATA, HDMI, only one USB host, fewer UARTs) Since we have (limited) A10 support in HEAD I thought I would give it a try. Starting from cubieboard I essentially just removed the second USB host and changed UART0 to UART1. When it boots I get the results below, "could not process 'interrupts' property". I can't figure out what's wrong, does anyone have a clue? Jakob U-Boot 2012.10-04259-g832a8e5 (Nov 08 2012 - 06:49:37) Allwinner Technology CPU: SUNXI Family Board: A13-OLinuXino I2C: ready DRAM: 512 MiB MMC: SUNXI SD/MMC: 0 In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 sun5i#fatload mmc 0 0x40200000 kernel.bin reading kernel.bin 3800740 bytes read sun5i#go 0x40200000 ## Starting application at 0x40200000 ... KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #13 r250014M: Sun Apr 28 16:06:38 CEST 2013 root@test10:/home/jakob/a13-gonzo/obj/arm.armv6/usr/src/sys/A13 arm FreeBSD clang version 3.3 (trunk 178860) 20130405 WARNING: WITNESS option enabled, expect reduced performance. CPU: Cortex A8-r3 rev 2 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:2 LoUIS:1 Cache level 1: 32KB/64B 4-way data cache WT WB Read-Alloc 32KB/64B 4-way instruction cache Read-Alloc Cache level 2: 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc real memory = 536870912 (512 MB) avail memory = 511303680 (487 MB) random device not loaded; using insecure entropy simplebus0: on fdtbus0 simplebus0: timer@01c20c00: could not process 'interrupts' property simplebus0: gpio@01c20800: could not process 'interrupts' property simplebus0: usb@01c14000: could not process 'interrupts' property simplebus0: serial@01c28400: could not process 'interrupts' property aintc0: mem 0x1c20400-0x1c207ff on simplebus0 a13_ccm0: mem 0x1c20000-0x1c203ff on simplebus0 a13wd0: mem 0x1c20c90-0x1c20c97 on simplebus0 panic: No usable event timer found! KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at kdb_enter+0x4c: ldrb r15, [r15, r15, ror r15]! db> From owner-freebsd-arm@FreeBSD.ORG Sun Apr 28 21:10:44 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 282A1147 for ; Sun, 28 Apr 2013 21:10:44 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id D3248153C for ; Sun, 28 Apr 2013 21:10:43 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UWYro-00080H-5v for freebsd-arm@freebsd.org; Sun, 28 Apr 2013 14:10:42 -0700 Message-ID: <517D904C.9060209@bluezbox.com> Date: Sun, 28 Apr 2013 14:10:36 -0700 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: could not process 'interrupts' property References: <53141.85.229.95.25.1367181563.squirrel@alvermark.net> In-Reply-To: <53141.85.229.95.25.1367181563.squirrel@alvermark.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 4/28/2013 1:39 PM, Jakob Alvermark wrote: > Hi! > > I got my hands on an Olinuxino A13 > (https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino/) > It is based on the Allwinner A13, which is a stripped down A10 (no SATA, > HDMI, only one USB host, fewer UARTs) > > Since we have (limited) A10 support in HEAD I thought I would give it a try. > Starting from cubieboard I essentially just removed the second USB host > and changed UART0 to UART1. > When it boots I get the results below, "could not process 'interrupts' > property". > > I can't figure out what's wrong, does anyone have a clue? I saw this when there was no interrupt-parent property in FDT node. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 21:10:44 -0000 On 4/28/2013 1:39 PM, Jakob Alvermark wrote: > Hi! > > I got my hands on an Olinuxino A13 > (https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino/) > It is based on the Allwinner A13, which is a stripped down A10 (no SATA, > HDMI, only one USB host, fewer UARTs) > > Since we have (limited) A10 support in HEAD I thought I would give it a try. > Starting from cubieboard I essentially just removed the second USB host > and changed UART0 to UART1. > When it boots I get the results below, "could not process 'interrupts' > property". > > I can't figure out what's wrong, does anyone have a clue? I saw this when there was no interrupt-parent property in FDT node. From owner-freebsd-arm@FreeBSD.ORG Sun Apr 28 23:24:37 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E8F3796A for ; Sun, 28 Apr 2013 23:24:37 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id CBE821B26 for ; Sun, 28 Apr 2013 23:24:37 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r3SNNsLY067973; Sun, 28 Apr 2013 23:23:54 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id prghies9w87kq29wqau6vjxm86; Sun, 28 Apr 2013 23:23:54 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: clang/ARM regression Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <517C868B.4060002@bluezbox.com> Date: Sun, 28 Apr 2013 16:23:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <517C868B.4060002@bluezbox.com> To: Oleksandr Tymoshenko X-Mailer: Apple Mail (2.1283) Cc: arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 23:24:38 -0000 On Apr 27, 2013, at 7:16 PM, Oleksandr Tymoshenko wrote: > Hi, >=20 > There seems to be some kind of regression in recently imported clang = on ARM. > Beaglebone kernel built using clang with WITNESS enabled panics > on boot. If I change optimization flags from -O to -O0 it works fine. > I'm trying to isolate test case but it panics fairly early in boot = process > so it's not easy. If somebody tracks clang development and aware of > known issues that might cause it - please share. >=20 > So far I tried fix from this bug but it didn't help: > http://llvm.org/bugs/show_bug.cgi?id=3D15581 I'm seeing a crash early on as well. Is this the same one? /boot/kernel/kernel data=3D0x404564+0x17c9f8 = syms=3D[0x4+0x76a60+0x4+0x4bf98] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 Using DTB provided by U-Boot. Kernel entry at 0x80200100... Kernel args: (null) KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0: Sun Apr 28 05:25:04 PDT 2013 = root@fci386.localdomain:/usr/home/tim/projects/crochet-rpi/work/obj/arm.ar= mv6/usr/src/sys/BEAGLEBONE arm FreeBSD clang version 3.3 (trunk 178860) 20130405 WARNING: WITNESS option enabled, expect reduced performance. panic: acquiring blockable sleep lock with spinlock or critical section = held (rw) pmap pv global @ /usr/src/sys/arm/arm/pmap-v6.c:1187 KDB: enter: panic [ thread pid 0 tid 0 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! db>=20 From owner-freebsd-arm@FreeBSD.ORG Mon Apr 29 01:13:47 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9F9F9C08 for ; Mon, 29 Apr 2013 01:13:47 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 638461DF1 for ; Mon, 29 Apr 2013 01:13:46 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r3T1Djgu068549; Mon, 29 Apr 2013 01:13:45 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id dwmtk2s4sssht4mhw5sz99gw4w; Mon, 29 Apr 2013 01:13:45 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: BeagleBone Black Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Sun, 28 Apr 2013 18:13:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <511086A4-37A1-40B5-867E-64996A49EBB8@kientzle.com> References: <26A08C89-95EA-463D-98C5-A471F8D15C90@freebsd.org> <54A0884D-31D0-4FC6-BBB5-58E3D11050E6@freebsd.org> <77E91A57-7880-4908-8999-6115333F5002@kientzle.com> <517CEDBF.3090102@g7iii.net> To: Tim Kientzle X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 01:13:47 -0000 On Apr 28, 2013, at 10:03 AM, Tim Kientzle wrote: > On Apr 28, 2013, at 2:37 AM, Iain Young wrote: >> On 28/04/13 08:13, Tim Kientzle wrote: >>=20 >>> The 4-pin adapter I got from Adafruit for use with Raspberry Pi = seems >>> to work just fine, though the CircuitCo documentation has the = instructions >>> wrong. It should be: >>> Black =3D> Pin 1 >>> Green =3D> Pin 4 >>> White =3D> Pin 5 >>=20 >> Hurm, I wonder what the other 3 pins are used for. They seem to be >> undocumented in the SRM >=20 > I believe they're unconnected. They're only there for compatibility > with the common FTDI TTL-232R-3v3 USB-to-serial > adapter that has a 6-pin connector. Adafruit has added a photograph of using their 4-wire adapter with the BB Black: http://www.adafruit.com/products/954 >=20 >>> Harumph. Looks like it always boots initially from the eMMC and >>> U-Boot then looks at the boot switch to decide whether to continue >>> from eMMC or uSD. >>=20 >> This would appear to be the default behaviour, but can be over-ridden >> if I read the SRM correctly. For a one off force to uSD boot, hold = down >> the "boot" button". See Page 57 of the SRM >=20 > Tried that, but from watching the serial console, it's still > loading U-Boot from the eMMC. It's U-Boot that actually looks > at that pin (there are some messages on the serial console > about U-Boot inspecting a GPIO pin). I was wrong. The point that was confusing me: The "boot switch" is *only* read when you apply power. Resetting the board doesn't read the boot switch; you have to actually remove power and then connect power while holding the switch. U-Boot does fiddle GPIO pins, but only to set some LEDs to indicate boot progress. >>> This sucks: the U-Boot on the eMMC doesn't have ELF support >>> nor API support so can't load and boot ubldr. Again, I was wrong. It actually is possible to build a micro-SD image and just boot it. So far, I have managed to build an image that would boot on either old or new BeagleBone. The build isn't quite repeatable --- I need to clean up some patches and fix a few loose ends. I was hoping to finish that tonight ... Tim From owner-freebsd-arm@FreeBSD.ORG Mon Apr 29 01:38:59 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2F0C2EA7 for ; Mon, 29 Apr 2013 01:38:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 013351E71 for ; Mon, 29 Apr 2013 01:38:58 +0000 (UTC) Received: by mail-ia0-f175.google.com with SMTP id i38so5094251iae.6 for ; Sun, 28 Apr 2013 18:38:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=Rua5rPKkoslNzfq+4aFFr+3k+bmYx+mhdGPtMMi8moU=; b=DVTqugqgWS4lrkY/s6VQqObE5lW3iV6AUiH/uJ07czVh64Xx4ahM1rZPmd+1tRVlkG yDtOW/gZAJi0uOi2K1i7n6i+WGba0/96Fo7U+3tcrLLGwS+Ylfb5CMiNjAjq/pucNHkl oBPg3FqBdk9cAJFAIdKkA3Dmp6rIw28mTKrJn1UdO/LTg1tK8xJSSs89ZeTqd9Td25pG rL2urLPVUZ4x6teNH6JG7Ukt7XurFCbvZ5f674V+55cQe0KWzIZBmIWEkPh9E0Dxgz5z vO9BsjA9zqn9PDg+rqzqwKlerx65FhJidMSwapZogpn3874cDv9/ewyeoX8E+9U9IJol VoPQ== X-Received: by 10.50.138.166 with SMTP id qr6mr6242325igb.45.1367199538621; Sun, 28 Apr 2013 18:38:58 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id qn10sm15303178igc.6.2013.04.28.18.38.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Apr 2013 18:38:57 -0700 (PDT) Sender: Warner Losh Subject: Re: clang/ARM regression Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 28 Apr 2013 19:38:54 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <517C868B.4060002@bluezbox.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlqTUlmrbI+WYbqkX6GdNqEU2Pttsoei6fecR35NcsT5k3v7mWWvrpN9sumRFir3kSdOXED Cc: arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 01:38:59 -0000 On Apr 28, 2013, at 5:23 PM, Tim Kientzle wrote: >=20 > On Apr 27, 2013, at 7:16 PM, Oleksandr Tymoshenko wrote: >=20 >> Hi, >>=20 >> There seems to be some kind of regression in recently imported clang = on ARM. >> Beaglebone kernel built using clang with WITNESS enabled panics >> on boot. If I change optimization flags from -O to -O0 it works fine. >> I'm trying to isolate test case but it panics fairly early in boot = process >> so it's not easy. If somebody tracks clang development and aware of >> known issues that might cause it - please share. >>=20 >> So far I tried fix from this bug but it didn't help: >> http://llvm.org/bugs/show_bug.cgi?id=3D15581 >=20 > I'm seeing a crash early on as well. Is this the same one? >=20 > /boot/kernel/kernel data=3D0x404564+0x17c9f8 = syms=3D[0x4+0x76a60+0x4+0x4bf98] > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... =20 > Using DTB provided by U-Boot. > Kernel entry at 0x80200100... > Kernel args: (null) > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2013 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 > The Regents of the University of California. All rights = reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 10.0-CURRENT #0: Sun Apr 28 05:25:04 PDT 2013 > = root@fci386.localdomain:/usr/home/tim/projects/crochet-rpi/work/obj/arm.ar= mv6/usr/src/sys/BEAGLEBONE arm > FreeBSD clang version 3.3 (trunk 178860) 20130405 > WARNING: WITNESS option enabled, expect reduced performance. > panic: acquiring blockable sleep lock with spinlock or critical = section held (rw) pmap pv global @ /usr/src/sys/arm/arm/pmap-v6.c:1187 > KDB: enter: panic > [ thread pid 0 tid 0 ] > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > db>=20 That's similar to what I'm seeing on my Allwinner board. Warner= From owner-freebsd-arm@FreeBSD.ORG Mon Apr 29 04:20:45 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 704F4DF8 for ; Mon, 29 Apr 2013 04:20:45 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 35EC0123A for ; Mon, 29 Apr 2013 04:20:44 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r3T4Khpi069705 for freebsd-arm@freebsd.org; Mon, 29 Apr 2013 04:20:43 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id antg9srjbyemi2brpy3s7s78gn; for freebsd-arm@freebsd.org; Mon, 29 Apr 2013 04:20:43 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: multipart/signed; boundary="Apple-Mail=_4210E4DE-B383-4882-814B-C35424A8C5A8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: FreeBSD on BeagleBone Black Date: Sun, 28 Apr 2013 21:20:41 -0700 Message-Id: To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 04:20:45 -0000 --Apple-Mail=_4210E4DE-B383-4882-814B-C35424A8C5A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I got the boot chain for BeagleBone Black working today. There's still = work to do, but I thought other people might appreciate the first = results: http://people.freebsd.org/~kientzle/beaglebone-and-black-bootfiles.tgz These are the files you'll need on the FAT partition for a Micro-SD = image that can boot on either BeagleBone or BeagleBone Black. These = should be usable to update an existing BeagleBone image to also work on = the Black. Note that there are two sets of DTS/DTB files here: * bbone.dtb is loaded when booting on a "white" BeagleBone. * bboneblk.dtb is loaded when booting on a BeagleBone Black. Right now, bboneblk.dtb is just a copy of bbone.dtb. That will, of = course, need to change in order to take advantage of the additional = memory and other peripherals. The DTS files are there for reference; = you can edit them, recompile and reboot to try changes. If you want to build from source, I just pushed the necessary changes to = Crochet: The BeagleBone board definition will now build an image that = boots on BeagleBone Black as well. This now uses the Denx 2013.04 = U-Boot source snapshot instead of my patched github clone of the Arago = sources. Caveat: Of course, a freshly built kernel will crash right now due to = the issue that Oleksandr and Warner have reported. Between builds, I spent some time today adding more information to the = FreeBSD Wiki: https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack and https://wiki.freebsd.org/FreeBSD/arm/BeagleBone Next steps: * Edit FDT to try to enable more memory * Enable second SD/MMC port to access the eMMC (maybe just an FDT = edit?) * Try booting from eMMC. Cheers, Tim --Apple-Mail=_4210E4DE-B383-4882-814B-C35424A8C5A8 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----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQEcBAEBAgAGBQJRffUZAAoJEGMNyGo0rfFBkd8H/27katRvU0FzpaLnTIFlopFj 02lCOt3mmewvwdSKxI/3LWCzExvagTi7pD9p0qJkuGu4XXquLZUOVVSD/x42jyZK cGmZOdhqUvuVtZWk6usHAv9oP8+4O4Zc2UCPldb2C5K3k7TRg/ars1eexGb6Pw+K QAehbqUb4c/NBT/LZO0ljxrkblonkd/7XY9PBHV5CjBq0MNfwGo3rRyyeIYFakf9 mviMEQJtOMB4Tv6KU/8SVU+cARbRFTrFjIJiGYA75IjX8x2l7PHIPCj+faKXuQ52 W+W/uI4ILaz1NzO9x5HAwA2cczrSrHUJi0wAuQ5mfW8eKhZniBzybBBfwwwzth0= =VAFx -----END PGP SIGNATURE----- --Apple-Mail=_4210E4DE-B383-4882-814B-C35424A8C5A8-- From owner-freebsd-arm@FreeBSD.ORG Mon Apr 29 05:02:14 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1DDE2538 for ; Mon, 29 Apr 2013 05:02:14 +0000 (UTC) (envelope-from contact@ijtemt.org) Received: from ns54.Host1.yourdomainname.com (50.22.181.244-static.reverse.softlayer.com [50.22.181.244]) by mx1.freebsd.org (Postfix) with ESMTP id 096A714E6 for ; Mon, 29 Apr 2013 05:02:13 +0000 (UTC) X-Sender: "Editor IJTEMT" X-Receiver: freebsd-arm@freebsd.org From: "Editor IJTEMT" To: freebsd-arm@freebsd.org Date: 28 Apr 2013 21:59:33 -0700 Subject: Call for Papers IJTEMT. Kindly impart in your University/Organization/College/Colleagues/Academia/Circle. Priority: urgent Importance: normal Message-Id: <20130429050214.1DDE2538@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Editor IJTEMT List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 05:02:14 -0000 INTERNATIONAL JOURNAL OF TRENDS IN ECONOMICS MANAGEMENT & TECHNOLOGY IJTEMT invites you to submit your research paper for publishing in Volume II, Issue II ( April 2013). CALL FOR PAPERS VOLUME II, ISSUE II www.ijtemt.org About IJTEMT International Journal of Trends in Economics Management and Technology (IJTEMT) in an International Academic Journal e-published bimonthly in India and open to the world. In this present interdisciplinary era, here at IJTEMT, a group of intellectual came together to find a common platform for three major components of any economy i.e., Economics, Management and Technology. Here we provide a forum to bridge the gap between the brushed-up professional in their respective fields and the new researcher which will results in better understanding and fruitful outcomes. The focus of this journal is to publish paper on economics management and technology. Submitted papers are reviewed by a full double blind manner by the technical committee of the journal. The audience for the journal is professionals from related fields, academicians and new students & research scholars. All submitted articles should report original, previously unpublished research results, experimental or theoretical, and will be peer-reviewed. Articles submitted to the journal should meet these criteria and must not be under consideration for publication elsewhere. Manuscripts should follow the style of the journal and are subject to both review and editing. Why Select IJTEMT Journal IJTEMT Provides E-Certificates to Author's if Needed.IJTEMT is Globally Approved International Journal having Strong Editorial Board. This is Online Open Journal .Author's can Download Paper from Library of Journal at any Time from Anywhere.IJTEMT is a Association of Eminent Scientist, Researchers and Experienced Members of More than 20 Countries.IJTEMT Publishes High Quality Papers which are Peer Reviewed by International/National Reviewers. Author's Query can be solved within 18 Hours. Subject Category: ECONOMICS, MANAGEMENT & TECHNOLOGY. Important Dates: Paper Submission: 30th April 2013 Review Results (Acceptance/Rejection) Notification: Within two weeks after submitting manuscript. Guidelines for submission and Review Process: IJTEMT welcomes author submission of papers concerning any branch of the economics, management and technology and their applications in business, industry and other subjects relevant. The review process goes through following phases which can take time from ten days to two months: a. Each manuscript will be initially evaluated by the editorial board / editor, who may make use of appropriate software to examine the originality of the contents of the manuscript. b. The manuscripts passed through screening at above noted level will be forwarded to two referees for blind peer review, each of whom will make a recommendation to publish the article in its present form/edit/reject. During this period referees shall treat the contents of papers under review as privileged information. c. The reviewers' recommendations determine whether a paper will be accepted / accepted subject to change / subject to resubmission with significant changes / rejected. d. For papers which require changes, the same reviewers will be used to ensure that the quality of the revised paper is acceptable. e. All papers are refereed, and the Editor-in-Chief reserves the right to refuse any typescript, whether on invitation or otherwise, and to make suggestions and/or modifications before publication. Submission of Paper will takes place in two phases: a. Initial Paper Submission: Prospective author (s) is/are encouraged to submit their manuscript including charts, tables, figures and appendixes in .pdf and .doc (both) format to e-mail: [1]submit@ijtemt.org. All submitted articles should report original, previously unpublished research results, experimental or theoretical. Articles submitted to the IJIMT should meet these criteria and must not be under consideration for publication elsewhere. b. Camera Ready Paper Submission:On the acceptance of the paper after completion of the review process the author (s) is/are has to submit camera ready full text paper in .doc and .pdf (both) format to e-mail: [2]submitfinal@ijtemt.org along with the corresponding signed copy of copyright transfer form and scanned copy of payment slip. Publication fees Each accepted paper will be charged, for publication and paper handling, 100 USD per paper (for a maximum of 8 pages, above which 10 USD will be charged for every additional page) which is to be paid as per the instructions mentioned in the letter of acceptance of the manuscript submitted. Editor International Journal of Trends in Economics Management & Technology Website: [3]www.ijtemt.org Email: [4]editor@ijtemt.org, [5]coedtech@ijtemt.org, [6]contact@ijtemt.org. Paper Submission Email: [7]submit@ijtemt.org. References 1. mailto:submit@ijtemt.org 2. mailto:submitfinal@ijtemt.org 3. http://www.ijtemt.org/ 4. mailto:editor@ijtemt.org 5. mailto:coedtech@ijtemt.org 6. mailto:contact@ijtemt.org 7. mailto:submit@ijtemt.org From owner-freebsd-arm@FreeBSD.ORG Mon Apr 29 09:54:45 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0374B5AA for ; Mon, 29 Apr 2013 09:54:45 +0000 (UTC) (envelope-from adutkowski@gmail.com) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by mx1.freebsd.org (Postfix) with ESMTP id C588B14E9 for ; Mon, 29 Apr 2013 09:54:44 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id j6so5906906oag.9 for ; Mon, 29 Apr 2013 02:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fN+M8Jp8vP4/UCoedGILELLW/zWyCdDPZGFaNYWDgOE=; b=0m6on7P5A4O9HxyDaCs/9CtoMpTegV68kcQ/jkOlwhydJHoN/7mGdWw3PHPnq/VFRy QSFKeIPjSN7LgURK7AUoGh27xhvhNjV5X+aRCQXmqcyiIj5IWQIhH0U54Ds0ZvsliVSN W3jUZTRCBBZ+qCmcbRMq/JVRipRxtY8YOEmbWAjWTjGDc8droW6Yk3HMsJss2ZHLPHnk mAWQnl3UlkHRUbu9uM6jKN2NtJU6pcz19h0FRxVFv2m+5mhe2KPqI0EGwM/C1PX+Ut44 +aoFIT3Gqm7TvD0MM36z3VzwoBy4aBLmH3uZKDa5XvSkXztJjU22XHW7ZOO2GHKtt2s8 M9nw== MIME-Version: 1.0 X-Received: by 10.60.99.68 with SMTP id eo4mr23215123oeb.126.1367229278157; Mon, 29 Apr 2013 02:54:38 -0700 (PDT) Sender: adutkowski@gmail.com Received: by 10.76.95.194 with HTTP; Mon, 29 Apr 2013 02:54:37 -0700 (PDT) In-Reply-To: <53141.85.229.95.25.1367181563.squirrel@alvermark.net> References: <53141.85.229.95.25.1367181563.squirrel@alvermark.net> Date: Mon, 29 Apr 2013 11:54:37 +0200 X-Google-Sender-Auth: xOBCjxpDkkg0dY8iz44CyBwm0G8 Message-ID: Subject: Re: could not process 'interrupts' property From: Aleksander To: Jakob Alvermark Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 09:54:45 -0000 this info is also shown, when you have no interrupt decoding function. For example, for TI OMAP, the function is in sys/arm/ti/common.c [1] [1] http://svnweb.freebsd.org/base/head/sys/arm/ti/common.c?revision=239281&view=markup On Sun, Apr 28, 2013 at 10:39 PM, Jakob Alvermark wrote: > Hi! > > I got my hands on an Olinuxino A13 > (https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino/) > It is based on the Allwinner A13, which is a stripped down A10 (no SATA, > HDMI, only one USB host, fewer UARTs) > > Since we have (limited) A10 support in HEAD I thought I would give it a > try. > Starting from cubieboard I essentially just removed the second USB host > and changed UART0 to UART1. > When it boots I get the results below, "could not process 'interrupts' > property". > > I can't figure out what's wrong, does anyone have a clue? > > Jakob > > > > > > U-Boot 2012.10-04259-g832a8e5 (Nov 08 2012 - 06:49:37) Allwinner Technology > > CPU: SUNXI Family > Board: A13-OLinuXino > I2C: ready > DRAM: 512 MiB > MMC: SUNXI SD/MMC: 0 > In: serial > Out: serial > Err: serial > Hit any key to stop autoboot: 0 > sun5i#fatload mmc 0 0x40200000 kernel.bin > reading kernel.bin > > 3800740 bytes read > sun5i#go 0x40200000 > ## Starting application at 0x40200000 ... > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2013 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 10.0-CURRENT #13 r250014M: Sun Apr 28 16:06:38 CEST 2013 > root@test10:/home/jakob/a13-gonzo/obj/arm.armv6/usr/src/sys/A13 arm > FreeBSD clang version 3.3 (trunk 178860) 20130405 > WARNING: WITNESS option enabled, expect reduced performance. > CPU: Cortex A8-r3 rev 2 (Cortex-A core) > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > WB disabled EABT branch prediction enabled > LoUU:2 LoC:2 LoUIS:1 > Cache level 1: > 32KB/64B 4-way data cache WT WB Read-Alloc > 32KB/64B 4-way instruction cache Read-Alloc > Cache level 2: > 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc > real memory = 536870912 (512 MB) > avail memory = 511303680 (487 MB) > random device not loaded; using insecure entropy > simplebus0: on fdtbus0 > simplebus0: timer@01c20c00: could not process 'interrupts' property > simplebus0: gpio@01c20800: could not process 'interrupts' property > simplebus0: usb@01c14000: could not process 'interrupts' property > simplebus0: serial@01c28400: could not process 'interrupts' property > aintc0: mem 0x1c20400-0x1c207ff on > simplebus0 > a13_ccm0: mem 0x1c20000-0x1c203ff on > simplebus0 > a13wd0: mem 0x1c20c90-0x1c20c97 on simplebus0 > panic: No usable event timer found! > KDB: enter: panic > [ thread pid 0 tid 100000 ] > Stopped at kdb_enter+0x4c: ldrb r15, [r15, r15, ror r15]! > db> > > > _______________________________________________ > 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" > -- regards aleek From owner-freebsd-arm@FreeBSD.ORG Mon Apr 29 11:06:41 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1E0B4315 for ; Mon, 29 Apr 2013 11:06:41 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E994A1910 for ; Mon, 29 Apr 2013 11:06:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3TB6enk018043 for ; Mon, 29 Apr 2013 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3TB6elN018041 for freebsd-arm@FreeBSD.org; Mon, 29 Apr 2013 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 29 Apr 2013 11:06:40 GMT Message-Id: <201304291106.r3TB6elN018041@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 11:06:41 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177685 arm [kernel] [patch] Correct return type and usage of at91 o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o arm/176424 arm Compiler warning, TARGET_ARCH=armv6, make MALLOC_PRODU o arm/175803 arm building xdev for arm failing o arm/175605 arm please fix build binutils-2.23.1 in raspberry pi o arm/174461 arm [patch] Fix off-by-one in arm9/arm10 cache maintenance o arm/173617 arm Dreamplug exhibits eSATA file corruption using network o kern/171096 arm [arm][xscale][ixp]Allow 16bit access on PCI bus o arm/166256 arm build fail in pmap.c o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) p arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on p arm/134338 arm [patch] Lock GPIO accesses on ixp425 23 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Apr 29 12:42:02 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 74C7A8BC for ; Mon, 29 Apr 2013 12:42:02 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 30210124F for ; Mon, 29 Apr 2013 12:42:02 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 0A403C4C40 for ; Mon, 29 Apr 2013 14:41:55 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id Jn18P3kArLgK for ; Mon, 29 Apr 2013 14:41:54 +0200 (CEST) Received: from [10.0.0.93] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 84831C3850 for ; Mon, 29 Apr 2013 14:41:54 +0200 (CEST) Message-ID: <517E8610.5050204@semihalf.com> Date: Mon, 29 Apr 2013 16:39:12 +0200 From: Grzegorz Bernacki User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.24) Gecko/20120127 Thunderbird/3.1.16 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: RFC: Patches with AXP support and pmap&smp fixes. 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 12:42:02 -0000 Hi, I am going to submit some changes related to Armada XP support and some general ARM fixes. You can find them at: http://people.freebsd.org/~gber/armada It would be good if someone could review changes in generic ARM code i.e.: 1) http://people.freebsd.org/~gber/armada/0004-arm-smp-Fix-AP-processors-initialization-procedure.patch This patch fixes race condition in pcpu_init function. pcpu_init performs operation on signly-linked tail queue and the queue can be corrupted by secondary cpus initialization. 2) http://people.freebsd.org/~gber/armada/0007-arm-Fix-L2-PTE-access-permissions-management.patch http://people.freebsd.org/~gber/armada/0008-arm-Fix-page-reference-emulation-on-ARMv6-and-v7.patch These are changes which fixes reference simulation and access permissions in pmap v6. It would be great if you could also review armada patches. We will appreciate all comments and remarks. If there will be no objections I am going to submit these changes at the beginning of the next week. thanks, greg From owner-freebsd-arm@FreeBSD.ORG Tue Apr 30 07:22:37 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 84496538; Tue, 30 Apr 2013 07:22:37 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from smtprelay-h21.telenor.se (smtprelay-h21.telenor.se [195.54.99.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1BABC1008; Tue, 30 Apr 2013 07:22:33 +0000 (UTC) Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-h21.telenor.se (Postfix) with ESMTP id 03710E951A; Tue, 30 Apr 2013 08:54:47 +0200 (CEST) X-SENDER-IP: [85.229.94.62] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjNAAANpf1FV5V4+PGdsb2JhbABSgwc2AbYiAYgzgQgXAwEBAQE4NYIfAQEEAVYjBQsLBBQuLQwKFAYTiBAKCLAtjliNYoE0BAeCbmEDmESTF4Fo X-IronPort-AV: E=Sophos;i="4.87,579,1363129200"; d="scan'208,217";a="540546773" Received: from c-3e5ee555.06-11-73746f31.cust.bredbandsbolaget.se (HELO sigyn.alvermark.net) ([85.229.94.62]) by ipb2.telenor.se with ESMTP; 30 Apr 2013 08:54:47 +0200 Received: from gw.inter-sonic.com ([212.247.8.97] helo=[192.168.1.191]) by sigyn.alvermark.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UX4Sc-00029v-Rs; Tue, 30 Apr 2013 08:54:47 +0200 Subject: Re: could not process 'interrupts' property Mime-Version: 1.0 (Apple Message framework v1085) From: Jakob Alvermark In-Reply-To: Date: Tue, 30 Apr 2013 08:54:45 +0200 Message-Id: References: <53141.85.229.95.25.1367181563.squirrel@alvermark.net> To: Aleksander X-Mailer: Apple Mail (2.1085) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 07:22:37 -0000 On 29 apr 2013, at 11:54, Aleksander wrote: > this info is also shown, when you have no interrupt decoding function. = For example, for TI OMAP, the function is in sys/arm/ti/common.c [1] >=20 > [1] = http://svnweb.freebsd.org/base/head/sys/arm/ti/common.c?revision=3D239281&= view=3Dmarkup >=20 Yes, thank you for pointing in the right direction. It was a simple = typo. Now on to the next problem... > On Sun, Apr 28, 2013 at 10:39 PM, Jakob Alvermark = wrote: > Hi! >=20 > I got my hands on an Olinuxino A13 > (https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino/) > It is based on the Allwinner A13, which is a stripped down A10 (no = SATA, > HDMI, only one USB host, fewer UARTs) >=20 > Since we have (limited) A10 support in HEAD I thought I would give it = a try. > Starting from cubieboard I essentially just removed the second USB = host > and changed UART0 to UART1. > When it boots I get the results below, "could not process 'interrupts' > property". > --=20 > regards > aleek From owner-freebsd-arm@FreeBSD.ORG Tue Apr 30 13:45:40 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A18A3601; Tue, 30 Apr 2013 13:45:40 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp3.cerberusmail.co.uk (smtp3.cerberusmail.co.uk [46.37.32.63]) by mx1.freebsd.org (Postfix) with ESMTP id 655221388; Tue, 30 Apr 2013 13:45:40 +0000 (UTC) Received: from 46-37-55-90.dsl.cnl.uk.net ([46.37.55.90] helo=bender.lan) by smtp3.cerberusmail.co.uk with smtp (Exim 4.76) (envelope-from ) id 1UXAal-0001aG-46; Tue, 30 Apr 2013 14:27:36 +0100 Date: Tue, 30 Apr 2013 14:27:01 +0100 From: Andrew Turner To: Grzegorz Bernacki Subject: Re: RFC: Patches with AXP support and pmap&smp fixes. Message-ID: <20130430142701.5bbfec2b@bender.lan> In-Reply-To: <517E8610.5050204@semihalf.com> References: <517E8610.5050204@semihalf.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-SA-Score: 2.0 X-SA-Report: "relay01.cerberus.net.uk", classified this message as SPAM. SPAM Score: 2.0 Scan Date: Tue, 30 Apr 2013 14:27:36 +0100 pts rule name description ---- ---------------------- -------------------------------------------------- 2.0 HELO_LH_HOME HELO_LH_HOME 0.0 TVD_RCVD_IP TVD_RCVD_IP Please consult your outgoing E-mail supplier's "E-mail Acceptable Use Policy" for further details. Cc: freebsd-arm@freebsd.org, Olivier Houchard X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 13:45:40 -0000 On Mon, 29 Apr 2013 16:39:12 +0200 Grzegorz Bernacki wrote: > Hi, >=20 > I am going to submit some changes related to Armada XP support and > some general ARM fixes. You can find them at: > http://people.freebsd.org/~gber/armada >=20 > It would be good if someone could review changes in generic ARM code > i.e.: 1) > http://people.freebsd.org/~gber/armada/0004-arm-smp-Fix-AP-processors-ini= tialization-procedure.patch >=20 > This patch fixes race condition in pcpu_init function. pcpu_init=20 > performs operation on signly-linked tail queue and the queue can be=20 > corrupted by secondary cpus initialization. =46rom this patch I can infer you have used FreeBSD ARM with SMP. Have you tried with WITNESS enabled? If not can you try? There is a known issue where accessing curthread is non-atomic when it is required to be. In it's current state mutexes may fail when they are unlocked. Olivier Houchard had a patch a few months ago to rework how the data is stored. My understanding is this helped but I have not seen or tried the patch. Olivier, is the above correct, and are we able to get this work into the tree so we can work on making SMP stable? Andrew From owner-freebsd-arm@FreeBSD.ORG Tue Apr 30 14:33:36 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2E1B058E for ; Tue, 30 Apr 2013 14:33:36 +0000 (UTC) (envelope-from cognet@ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:150:ca0a:a9ff:fef1:a4c9]) by mx1.freebsd.org (Postfix) with ESMTP id AE1B2167A for ; Tue, 30 Apr 2013 14:33:35 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.5/8.14.5) with ESMTP id r3UEXB71072048; Tue, 30 Apr 2013 16:33:11 +0200 (CEST) (envelope-from cognet@ci0.org) Received: (from doginou@localhost) by kanar.ci0.org (8.14.5/8.14.5/Submit) id r3UEXBGh072047; Tue, 30 Apr 2013 16:33:11 +0200 (CEST) (envelope-from cognet@ci0.org) X-Authentication-Warning: kanar.ci0.org: doginou set sender to cognet@ci0.org using -f Date: Tue, 30 Apr 2013 16:33:11 +0200 From: Olivier Houchard To: Andrew Turner Subject: Re: RFC: Patches with AXP support and pmap&smp fixes. Message-ID: <20130430143311.GA71966@ci0.org> References: <517E8610.5050204@semihalf.com> <20130430142701.5bbfec2b@bender.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130430142701.5bbfec2b@bender.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 14:33:36 -0000 On Tue, Apr 30, 2013 at 02:27:01PM +0100, Andrew Turner wrote: > On Mon, 29 Apr 2013 16:39:12 +0200 > Grzegorz Bernacki wrote: > > > Hi, > > > > I am going to submit some changes related to Armada XP support and > > some general ARM fixes. You can find them at: > > http://people.freebsd.org/~gber/armada > > > > It would be good if someone could review changes in generic ARM code > > i.e.: 1) > > http://people.freebsd.org/~gber/armada/0004-arm-smp-Fix-AP-processors-initialization-procedure.patch > > > > This patch fixes race condition in pcpu_init function. pcpu_init > > performs operation on signly-linked tail queue and the queue can be > > corrupted by secondary cpus initialization. > > >From this patch I can infer you have used FreeBSD ARM with SMP. Have > you tried with WITNESS enabled? If not can you try? > > There is a known issue where accessing curthread is non-atomic when it > is required to be. In it's current state mutexes may fail when they are > unlocked. Olivier Houchard had a patch a few months ago to rework how > the data is stored. My understanding is this helped but I have not seen > or tried the patch. > > Olivier, is the above correct, and are we able to get this work into > the tree so we can work on making SMP stable? > > Andrew Hi Andrew, That's true, the patch helped a lot, by storing curthread and curpcb on the stack, and disabling interrupts while accessing less used pcpu entries. However something was still wrong, after maybe between 30 minutes and 1 hour of building port, I would get a random panic, usually from the VM, that I was unable to diagnose so far. I can dust of the patch, and share it anyway, even if it's still more a proof of concept than anything else, if somebody is willing to work with me on the remaining issues. Also, it was my understanding that Semihalf also had an alternative patch to solve the very same issue, did I get that wrong ? Regards, Olivier From owner-freebsd-arm@FreeBSD.ORG Tue Apr 30 15:18:52 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D3AE237B for ; Tue, 30 Apr 2013 15:18:52 +0000 (UTC) (envelope-from sef@kithrup.com) Received: from kithrup.com (Kithrup.COM [64.142.31.202]) by mx1.freebsd.org (Postfix) with ESMTP id A67631858 for ; Tue, 30 Apr 2013 15:18:52 +0000 (UTC) Received: from kithrup.com (localhost [127.0.0.1]) by kithrup.com (8.14.4/8.14.4) with ESMTP id r3UF5OQL026409 for ; Tue, 30 Apr 2013 08:05:25 -0700 (PDT) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.14.4/8.14.4/Submit) id r3UF5OOd026408 for freebsd-arm@freebsd.org; Tue, 30 Apr 2013 08:05:24 -0700 (PDT) (envelope-from sef) Date: Tue, 30 Apr 2013 08:05:24 -0700 (PDT) From: Sean Eric Fagan Message-Id: <201304301505.r3UF5OOd026408@kithrup.com> To: freebsd-arm@freebsd.org Subject: Raspberry Pi: Cannot mount root (error 19) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 15:18:52 -0000 I've tried rebuilding the image several times; I haven't tried dropping back to using FreeBSD 9 instead of 10 as the host for building. Any ideas? From owner-freebsd-arm@FreeBSD.ORG Tue Apr 30 16:04:36 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 12E588A1 for ; Tue, 30 Apr 2013 16:04:36 +0000 (UTC) (envelope-from tom@0x544745.com) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by mx1.freebsd.org (Postfix) with ESMTP id D77C31C08 for ; Tue, 30 Apr 2013 16:04:35 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id f4so652564oah.21 for ; Tue, 30 Apr 2013 09:04:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=cVowAgIjmOaLCkEPguMRRAbtMUrSBe1hhfiq4htR3p0=; b=CSrF8GAtN9q4K4N74W0bHymXa+0c4csu7oyz+ZYZ6qkTvO2VLzper4uUU3WiW5MTo+ mVeDKBUzxk9sahb84O+AxXV6CIHiMvgAOBIEcKuRu+0/9zFIQArLkNZneicDsr7x2xBs xBHxTt9hHLMGcDABv2n6bsbxSWC6SAro+GOWG5x0y/CkMFBW2sfwX+qeDmzvM64blKvk USNcnMEUaiB0Xa1NAhdl1xdDDWjGy1xIpm+VmaKRzOgQnsJt+dLXZmSJ/H9Ye2lJfEWh WEKK+X2zIySpcTW/bEHJ/xlTZkba8C0BAcJTSuzbeE2RPyqz8KWLzKpMb6c6JI7SDSww /Amg== MIME-Version: 1.0 X-Received: by 10.60.98.235 with SMTP id el11mr18033423oeb.57.1367337874782; Tue, 30 Apr 2013 09:04:34 -0700 (PDT) Received: by 10.182.245.5 with HTTP; Tue, 30 Apr 2013 09:04:34 -0700 (PDT) In-Reply-To: <201304301505.r3UF5OOd026408@kithrup.com> References: <201304301505.r3UF5OOd026408@kithrup.com> Date: Tue, 30 Apr 2013 10:04:34 -0600 Message-ID: Subject: Re: Raspberry Pi: Cannot mount root (error 19) From: Tom Everett To: Sean Eric Fagan X-Gm-Message-State: ALoCoQnhtIhO9kw5LrsFrKPXfRvdqb9p5O1CTv8c9Z98/HLAlISDsGYg+6eJkuByTpfGZpkP/a8V Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 16:04:36 -0000 If you're interested, there are some CURRENT images here: http://files.khubla.com, and quick discussion of creating them with gonzo's script here: http://blog.khubla.com On Tue, Apr 30, 2013 at 9:05 AM, Sean Eric Fagan wrote: > I've tried rebuilding the image several times; I haven't tried dropping > back > to using FreeBSD 9 instead of 10 as the host for building. > > Any ideas? > > _______________________________________________ > 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" > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Tue Apr 30 16:21:19 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 223602DC for ; Tue, 30 Apr 2013 16:21:19 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by mx1.freebsd.org (Postfix) with ESMTP id F2A5C1D2C for ; Tue, 30 Apr 2013 16:21:18 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UXDIs-0007IW-1P; Tue, 30 Apr 2013 16:21:18 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r3UGLFWr007533; Tue, 30 Apr 2013 10:21:15 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+ETJSeO7NeJLqciw8tUK2I Subject: Re: RFC: Patches with AXP support and pmap&smp fixes. From: Ian Lepore To: Grzegorz Bernacki In-Reply-To: <517E8610.5050204@semihalf.com> References: <517E8610.5050204@semihalf.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Apr 2013 10:21:15 -0600 Message-ID: <1367338875.1180.44.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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 16:21:19 -0000 On Mon, 2013-04-29 at 16:39 +0200, Grzegorz Bernacki wrote: > Hi, > > I am going to submit some changes related to Armada XP support and some > general ARM fixes. You can find them at: > http://people.freebsd.org/~gber/armada > > It would be good if someone could review changes in generic ARM code i.e.: > 1) > http://people.freebsd.org/~gber/armada/0004-arm-smp-Fix-AP-processors-initialization-procedure.patch > > This patch fixes race condition in pcpu_init function. pcpu_init > performs operation on signly-linked tail queue and the queue can be > corrupted by secondary cpus initialization. > > 2) > http://people.freebsd.org/~gber/armada/0007-arm-Fix-L2-PTE-access-permissions-management.patch > http://people.freebsd.org/~gber/armada/0008-arm-Fix-page-reference-emulation-on-ARMv6-and-v7.patch > > These are changes which fixes reference simulation and access > permissions in pmap v6. > > It would be great if you could also review armada patches. > We will appreciate all comments and remarks. If there will be no > objections I am going to submit these changes at the beginning of the > next week. > > thanks, > greg I've reviewed them, and see no problems. It might not be a bad idea to paste the protections truth table from the commit message as a comment block in pmap_set_prot(); I had to keep referring to it while convincing myself the changes were right for every path through the routine. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed May 1 05:56:10 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 92F14483 for ; Wed, 1 May 2013 05:56:10 +0000 (UTC) (envelope-from br@bsdpad.com) Received: from mail.bsdpad.com (mail.bsdpad.com [109.107.176.56]) by mx1.freebsd.org (Postfix) with ESMTP id 54D521C22 for ; Wed, 1 May 2013 05:56:10 +0000 (UTC) Received: from br by mail.bsdpad.com with local (Exim 4.80.1) (envelope-from ) id 1UXPwA-0005Hm-Ty for arm@freebsd.org; Wed, 01 May 2013 05:50:42 +0000 Date: Wed, 1 May 2013 05:50:42 +0000 From: Ruslan Bukin To: arm@freebsd.org Subject: Re: usb on exynos5 Message-ID: <20130501055042.GA2161@jail.io> References: <20130426073302.GA1592@jail.io> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130426073302.GA1592@jail.io> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 05:56:10 -0000 sorry for the noise...it fixed. it was misconfiguration in timer and usb PHY settings. Seems now usb works stable. -Ruslan On Fri, Apr 26, 2013 at 07:33:02AM +0000, Ruslan Bukin wrote: > hi > > I'm trying to setup usb EHCI on Exynos5250. > EHCI works OK in u-boot and also in ubldr > > but no luck in kernel. I tried with and without > PHY re-initialize, but results is almost the same: > > http://pastebin.ca/2367010 > > usb powered by two GPIO pins. they stay unchanged (turned ON) > while kernel take-off > > may be it is about wrong eventtimer configuration? > GIC works fine though... > > -Ruslan > _______________________________________________ > 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 May 1 06:12:27 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B1185812 for ; Wed, 1 May 2013 06:12:27 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 77FAA1CEE for ; Wed, 1 May 2013 06:12:27 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id bn16so1954699qab.6 for ; Tue, 30 Apr 2013 23:12:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=8EH6auMm5IhFJTgboI72e++I/LkchKOoEtFpdC5Ny/s=; b=Jcs3r6TjyEJjPuzdCFXL3tyk8QXn0WNU72dokJG67MJmpymYnjexgjky1AaUB1eWnC z13aSi9lDoMFQ5ghZeaCflEoHNOD8ovmEz5Ds5JLPwEXjI1+1V5a8YvW0k92NTtXsD5j 9/RC/9E9jWscUpfvT6llykR2pJbqfljj0+MZAhftHHRFEruUdgA31VMEXZJLWq7ErTp2 iJaBbctYlg+3zJ7FENIdZjkrPG8H/FAgsSgg0WFiThTrsH8c06NozBQLwxB1yk/dgtjC vnSyQN48Gp6W3TfdDXDtp/TIbYMM1aTmNMjjv7SbJjBWt0DRYnuKbE0L72B5NlyWjqNq W6dA== MIME-Version: 1.0 X-Received: by 10.224.128.69 with SMTP id j5mr2060403qas.25.1367388746920; Tue, 30 Apr 2013 23:12:26 -0700 (PDT) Received: by 10.49.132.195 with HTTP; Tue, 30 Apr 2013 23:12:26 -0700 (PDT) In-Reply-To: <20130501055042.GA2161@jail.io> References: <20130426073302.GA1592@jail.io> <20130501055042.GA2161@jail.io> Date: Wed, 1 May 2013 14:12:26 +0800 Message-ID: Subject: Re: usb on exynos5 From: Alie Tan To: Ruslan Bukin X-Gm-Message-State: ALoCoQkKxUuqx09RQ4QLa+Lxta8hKYbSQPZacv0zEdHoRCkp1EpMCHSOr/o89NcRRZqRXSagAkrs Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 06:12:27 -0000 On Wed, May 1, 2013 at 1:50 PM, Ruslan Bukin wrote: > sorry for the noise...it fixed. > it was misconfiguration in timer and usb PHY settings. > > Seems now usb works stable. > Hi Ruslan, may we know the status updates for FreeBSD on Exynos? > > -Ruslan > > On Fri, Apr 26, 2013 at 07:33:02AM +0000, Ruslan Bukin wrote: > > hi > > > > I'm trying to setup usb EHCI on Exynos5250. > > EHCI works OK in u-boot and also in ubldr > > > > but no luck in kernel. I tried with and without > > PHY re-initialize, but results is almost the same: > > > > http://pastebin.ca/2367010 > > > > usb powered by two GPIO pins. they stay unchanged (turned ON) > > while kernel take-off > > > > may be it is about wrong eventtimer configuration? > > GIC works fine though... > > > > -Ruslan > > _______________________________________________ > > 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" > _______________________________________________ > 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 May 1 06:37:02 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E9865CD9 for ; Wed, 1 May 2013 06:37:02 +0000 (UTC) (envelope-from br@bsdpad.com) Received: from mail.bsdpad.com (mail.bsdpad.com [109.107.176.56]) by mx1.freebsd.org (Postfix) with ESMTP id A983A1DAE for ; Wed, 1 May 2013 06:37:02 +0000 (UTC) Received: from br by mail.bsdpad.com with local (Exim 4.80.1) (envelope-from ) id 1UXQZo-0002u6-Cv; Wed, 01 May 2013 06:31:40 +0000 Date: Wed, 1 May 2013 06:31:40 +0000 From: Ruslan Bukin To: Alie Tan Subject: Re: usb on exynos5 Message-ID: <20130501063140.GA7152@jail.io> References: <20130426073302.GA1592@jail.io> <20130501055042.GA2161@jail.io> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 06:37:03 -0000 Yes. For now, UART, GIC, generic_timer and EHCI works OK on exynos5250. no SMP yet ported. exynos5 bootlog: http://p.linode.com/7630 the code are cleaning now -Ruslan On Wed, May 01, 2013 at 02:12:26PM +0800, Alie Tan wrote: > On Wed, May 1, 2013 at 1:50 PM, Ruslan Bukin <[1]br@bsdpad.com> wrote: > > sorry for the noise...it fixed. > it was misconfiguration in timer and usb PHY settings. > > Seems now usb works stable. > > Hi Ruslan, may we know the status updates for FreeBSD on Exynos? > > -Ruslan > > On Fri, Apr 26, 2013 at 07:33:02AM +0000, Ruslan Bukin wrote: > > hi > > > > I'm trying to setup usb EHCI on Exynos5250. > > EHCI works OK in u-boot and also in ubldr > > > > but no luck in kernel. I tried with and without > > PHY re-initialize, but results is almost the same: > > > > [2]http://pastebin.ca/2367010 > > > > usb powered by two GPIO pins. they stay unchanged (turned ON) > > while kernel take-off > > > > may be it is about wrong eventtimer configuration? > > GIC works fine though... > > > > -Ruslan > > _______________________________________________ > > [3]freebsd-arm@freebsd.org mailing list > > [4]http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to > "[5]freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > [6]freebsd-arm@freebsd.org mailing list > [7]http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to > "[8]freebsd-arm-unsubscribe@freebsd.org" > > References > > Visible links > 1. mailto:br@bsdpad.com > 2. http://pastebin.ca/2367010 > 3. mailto:freebsd-arm@freebsd.org > 4. http://lists.freebsd.org/mailman/listinfo/freebsd-arm > 5. mailto:freebsd-arm-unsubscribe@freebsd.org > 6. mailto:freebsd-arm@freebsd.org > 7. http://lists.freebsd.org/mailman/listinfo/freebsd-arm > 8. mailto:freebsd-arm-unsubscribe@freebsd.org From owner-freebsd-arm@FreeBSD.ORG Wed May 1 14:43:28 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8DBE9882 for ; Wed, 1 May 2013 14:43:28 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from smtprelay-h22.telenor.se (smtprelay-h22.telenor.se [195.54.99.197]) by mx1.freebsd.org (Postfix) with ESMTP id 2650B1261 for ; Wed, 1 May 2013 14:43:27 +0000 (UTC) Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-h22.telenor.se (Postfix) with ESMTP id 91B4EE85CB for ; Wed, 1 May 2013 16:09:57 +0200 (CEST) X-SENDER-IP: [85.229.94.62] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AobSACYhgVFV5V4+PGdsb2JhbABSgwYBAYgmsC6EFIJfBHwXAwEBAQE4NYJNCwEjgTEMCog9n0afP418gTqDOgOOXZgnhF46 X-IronPort-AV: E=Sophos;i="4.87,589,1363129200"; d="scan'208";a="541475748" Received: from c-3e5ee555.06-11-73746f31.cust.bredbandsbolaget.se (HELO sigyn.alvermark.net) ([85.229.94.62]) by ipb2.telenor.se with ESMTP; 01 May 2013 16:09:57 +0200 Received: from localhost ([127.0.0.1] helo=alvermark.net) by sigyn.alvermark.net with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UXXjI-0006X1-7v for freebsd-arm@freebsd.org; Wed, 01 May 2013 16:09:56 +0200 Received: from 85.229.93.125 (SquirrelMail authenticated user alvis) by alvermark.net with HTTP; Wed, 1 May 2013 16:09:56 +0200 (CEST) Message-ID: <63837.85.229.93.125.1367417396.squirrel@alvermark.net> Date: Wed, 1 May 2013 16:09:56 +0200 (CEST) Subject: Allwinner A13: Fatal kernel mode data abort: 'Translation Fault (S)' From: "Jakob Alvermark" To: freebsd-arm@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 14:43:28 -0000 Hi again, In my effort to get FreeBSD running on the A13 I got a little further, however not quite so far as I was hoping for. Any clues on this? Jakob sun5i#go 0x40200100 ## Starting application at 0x40200100 ... KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0 r250141M: Wed May 1 14:15:44 CEST 2013 root@test10:/home/jakob/a13-gonzo/obj/arm.armv6/usr/src/sys/A13 arm FreeBSD clang version 3.3 (trunk 178860) 20130405 WARNING: WITNESS option enabled, expect reduced performance. CPU: Cortex A8-r3 rev 2 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:2 LoUIS:1 Cache level 1: 32KB/64B 4-way data cache WT WB Read-Alloc 32KB/64B 4-way instruction cache Read-Alloc Cache level 2: 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc real memory = 536870912 (512 MB) avail memory = 511303680 (487 MB) random device not loaded; using insecure entropy simplebus0: on fdtbus0 a13_ccm0: mem 0x1c20000-0x1c203ff on simplebus0 a13_timer0: mem 0x1c20c00-0x1c20c8f irq 22 on simplebus0 vm_fault(0xc0716ff8, 0, 1, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xc072aad4 FSR=00000005, FAR=00000008, spsr=a00000d3 r0 =00000000, r1 =00000004, r2 =00000001, r3 =c2f93b48 r4 =00000120, r5 =00000040, r6 =c30ac500, r7 =00000000 r8 =c0716508, r9 =00000000, r10=00000016, r11=c072ab40 r12=c0716da4, ssp=c072ab20, slr=c04b0c64, pc =c04c013c [ thread pid 0 tid 100000 ] Stopped at arm_unmask_irq+0x24: ldr r2, [r0, #0x008] db> From owner-freebsd-arm@FreeBSD.ORG Wed May 1 14:55:06 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A250DC0E for ; Wed, 1 May 2013 14:55:06 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id 7DBC412C7 for ; Wed, 1 May 2013 14:55:05 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UXYQt-000FLt-H3; Wed, 01 May 2013 14:54:59 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r41EstF8008653; Wed, 1 May 2013 08:54:55 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19n/+T3lCPK1znCIWegeA6T Subject: Re: Allwinner A13: Fatal kernel mode data abort: 'Translation Fault (S)' From: Ian Lepore To: Jakob Alvermark In-Reply-To: <63837.85.229.93.125.1367417396.squirrel@alvermark.net> References: <63837.85.229.93.125.1367417396.squirrel@alvermark.net> Content-Type: text/plain; charset="us-ascii" Date: Wed, 01 May 2013 08:54:55 -0600 Message-ID: <1367420095.1180.68.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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 14:55:06 -0000 On Wed, 2013-05-01 at 16:09 +0200, Jakob Alvermark wrote: > Hi again, > > In my effort to get FreeBSD running on the A13 I got a little further, > however not quite so far as I was hoping for. > > Any clues on this? > > Jakob > > sun5i#go 0x40200100 > ## Starting application at 0x40200100 ... > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2013 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 10.0-CURRENT #0 r250141M: Wed May 1 14:15:44 CEST 2013 > root@test10:/home/jakob/a13-gonzo/obj/arm.armv6/usr/src/sys/A13 arm > FreeBSD clang version 3.3 (trunk 178860) 20130405 > WARNING: WITNESS option enabled, expect reduced performance. > CPU: Cortex A8-r3 rev 2 (Cortex-A core) > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > WB disabled EABT branch prediction enabled > LoUU:2 LoC:2 LoUIS:1 > Cache level 1: > 32KB/64B 4-way data cache WT WB Read-Alloc > 32KB/64B 4-way instruction cache Read-Alloc > Cache level 2: > 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc > real memory = 536870912 (512 MB) > avail memory = 511303680 (487 MB) > random device not loaded; using insecure entropy > simplebus0: on fdtbus0 > a13_ccm0: mem 0x1c20000-0x1c203ff on > simplebus0 > a13_timer0: mem 0x1c20c00-0x1c20c8f irq 22 on > simplebus0 > > vm_fault(0xc0716ff8, 0, 1, 0) -> 1 > Fatal kernel mode data abort: 'Translation Fault (S)' > trapframe: 0xc072aad4 > FSR=00000005, FAR=00000008, spsr=a00000d3 > r0 =00000000, r1 =00000004, r2 =00000001, r3 =c2f93b48 > r4 =00000120, r5 =00000040, r6 =c30ac500, r7 =00000000 > r8 =c0716508, r9 =00000000, r10=00000016, r11=c072ab40 > r12=c0716da4, ssp=c072ab20, slr=c04b0c64, pc =c04c013c > > [ thread pid 0 tid 100000 ] > Stopped at arm_unmask_irq+0x24: ldr r2, [r0, #0x008] > db> It looks like the timer driver tried to set up interrupts before the interrupt controller driver had attached. The arm_unmask_irq() routine tried to dereference a NULL pointer, I'm thinking from where it died it was a10_aintc_sc. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed May 1 20:17:37 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3D8B5F25 for ; Wed, 1 May 2013 20:17:37 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by mx1.freebsd.org (Postfix) with ESMTP id 157FE11DD for ; Wed, 1 May 2013 20:17:36 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UXdT5-0004VK-WA; Wed, 01 May 2013 20:17:36 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r41KHW6M008916; Wed, 1 May 2013 14:17:32 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+pYlUasqUxmg7X0e5aTnoH Subject: A fix for the clang + eabi + kdb backtrace endless loop From: Ian Lepore To: freebsd-arm Content-Type: multipart/mixed; boundary="=-R74sECJmrSUq+3Vwtpin" Date: Wed, 01 May 2013 14:17:32 -0600 Message-ID: <1367439452.1180.92.camel@revolution.hippie.lan> 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 20:17:37 -0000 --=-R74sECJmrSUq+3Vwtpin Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The attached patch fixes the problem where a kdb backtrace loops endlessly on an eabi kernel. I'm no expert on this stuff, so while this fixes the problem for me, I'm not sure it's right, especially the STOP_UNWINDING in exception_exit (which handles a test case of breaking into the debugger with the keyboard and typing 'bt'). I'm not going to commit this until it's been reviewed by someone who actually knows what they're doing. :) -- Ian --=-R74sECJmrSUq+3Vwtpin Content-Disposition: inline; filename="eabi_unwind_fixes.diff" Content-Type: text/x-patch; name="eabi_unwind_fixes.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/arm/arm/db_trace.c =================================================================== --- sys/arm/arm/db_trace.c (revision 248960) +++ sys/arm/arm/db_trace.c (working copy) @@ -354,7 +354,7 @@ index = db_find_index(state->start_pc); if (index->insn == EXIDX_CANTUNWIND) { - db_printf("Unable to unwind\n"); + db_printf("Unable to unwind further\n"); break; } else if (index->insn & (1 << 31)) { /* The data is within the instruction */ @@ -412,6 +412,23 @@ } } db_printf("\n"); + + /* Stop if we've unwound back to the thread entry point. */ + if (state->registers[FP] == 0) { + break; + } + + /* + * Stop if the unwind function didn't change the PC, to avoid + * getting stuck in this loop forever. If this happens, it's an + * indication that the unwind information is incorrect somehow + * for the function named in the last frame printed before you + * see this message. + */ + if (state->start_pc == state->registers[PC]) { + db_printf("Unwind failure (PC didn't change)\n"); + break; + } } } #endif Index: sys/arm/arm/exception.S =================================================================== --- sys/arm/arm/exception.S (revision 248960) +++ sys/arm/arm/exception.S (working copy) @@ -196,15 +196,19 @@ * Interrupts are disabled at suitable points to avoid ASTs * being posted between testing and exit to user mode. * - * This function uses PULLFRAMEFROMSVCANDEXIT and - * DO_AST - * only be called if the exception handler used PUSHFRAMEINSVC + * This function uses PULLFRAMEFROMSVCANDEXIT and DO_AST and can + * only be called if the exception handler used PUSHFRAMEINSVC. * + * For EABI, don't try to unwind any further than this, because the unwind + * info generated here is a single INSN_FINISH instruction. Nothing gets + * unwound (no registers change) so the unwind would loop here forever. */ -exception_exit: +ASENTRY_NP(exception_exit) + STOP_UNWINDING DO_AST PULLFRAMEFROMSVCANDEXIT +END(exception_exit) /* * undefined_entry: --=-R74sECJmrSUq+3Vwtpin-- From owner-freebsd-arm@FreeBSD.ORG Thu May 2 00:03:45 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E971FDCD; Thu, 2 May 2013 00:03:45 +0000 (UTC) (envelope-from awg@embtoolkit.org) Received: from duppyconqueror.embtoolkit.org (duppyconqueror.embtoolkit.org [188.165.227.169]) by mx1.freebsd.org (Postfix) with ESMTP id 39D951AEA; Thu, 2 May 2013 00:03:44 +0000 (UTC) Received: from [192.168.1.100] (nogent.walsimou.com [82.67.240.252]) (AUTH: PLAIN awg@embtoolkit.org) by duppyconqueror.embtoolkit.org with ESMTPA; Thu, 02 May 2013 01:58:10 +0200 id 0298FAAD.000000005181AC12.00007BD4 Message-ID: <5181AC1A.2020400@embtoolkit.org> Date: Thu, 02 May 2013 01:58:18 +0200 From: Abdoulaye Walsimou Gaye User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_duppyconqueror.embtoolkit.org-31700-1367452691-0001-2" To: Jakob Alvermark Subject: Re: Allwinner A13: Fatal kernel mode data abort: 'Translation Fault (S)' References: <63837.85.229.93.125.1367417396.squirrel@alvermark.net> In-Reply-To: <63837.85.229.93.125.1367417396.squirrel@alvermark.net> Cc: freebsd-arm@freebsd.org, ian@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 00:03:46 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_duppyconqueror.embtoolkit.org-31700-1367452691-0001-2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 05/01/2013 04:09 PM, Jakob Alvermark wrote: > Hi again, > > In my effort to get FreeBSD running on the A13 I got a little further, > however not quite so far as I was hoping for. > > Any clues on this? > > Jakob > > sun5i#go 0x40200100 > ## Starting application at 0x40200100 ... > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2013 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 10.0-CURRENT #0 r250141M: Wed May 1 14:15:44 CEST 2013 > root@test10:/home/jakob/a13-gonzo/obj/arm.armv6/usr/src/sys/A13 arm > FreeBSD clang version 3.3 (trunk 178860) 20130405 > WARNING: WITNESS option enabled, expect reduced performance. > CPU: Cortex A8-r3 rev 2 (Cortex-A core) > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > WB disabled EABT branch prediction enabled > LoUU:2 LoC:2 LoUIS:1 > Cache level 1: > 32KB/64B 4-way data cache WT WB Read-Alloc > 32KB/64B 4-way instruction cache Read-Alloc > Cache level 2: > 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc > real memory = 536870912 (512 MB) > avail memory = 511303680 (487 MB) > random device not loaded; using insecure entropy > simplebus0: on fdtbus0 > a13_ccm0: mem 0x1c20000-0x1c203ff on > simplebus0 > a13_timer0: mem 0x1c20c00-0x1c20c8f irq 22 on > simplebus0 > > vm_fault(0xc0716ff8, 0, 1, 0) -> 1 > Fatal kernel mode data abort: 'Translation Fault (S)' > trapframe: 0xc072aad4 > FSR=00000005, FAR=00000008, spsr=a00000d3 > r0 =00000000, r1 =00000004, r2 =00000001, r3 =c2f93b48 > r4 =00000120, r5 =00000040, r6 =c30ac500, r7 =00000000 > r8 =c0716508, r9 =00000000, r10=00000016, r11=c072ab40 > r12=c0716da4, ssp=c072ab20, slr=c04b0c64, pc =c04c013c > > [ thread pid 0 tid 100000 ] > Stopped at arm_unmask_irq+0x24: ldr r2, [r0, #0x008] > db> > > Hello, I have similar boot error while trying to boot my openrd-base, with a KERNCONF based on DB-88F6XXX (see attached files) ## Starting application at 0x00900000 ... dtbp = 0xc0c9a8f8 KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-STABLE #1 r+aed5102-dirty: Thu May 2 01:50:19 CEST 2013 walsimou@vbox-fbsd64:/home/walsimou/embtk-fbsd/obj/arm.arm/usr/home/walsimou/freebsd.git/sys/OPENRD-BASE arm gcc version 4.2.1 20070831 patched [FreeBSD] WARNING: DIAGNOSTIC option enabled, expect reduced performance. module mvs already present! CPU: Feroceon 88FR131 rev 1 (Marvell core) DC enabled IC enabled WB enabled EABT branch prediction enabled 16KB/32B 4-way Instruction cache 16KB/32B 4-way write-back-locking-C Data cache real memory = 536870912 (512 MB) avail memory = 519278592 (495 MB) SOC: Marvell 88F6281 rev A0, TClock 200MHz simplebus0: on fdtbus0 ic0: mem 0xf1020200-0xf102023b on simplebus0 timer0: mem 0xf1020300-0xf102032f irq 1 on simplebus0 Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 gpio0: mem 0xf1010100-0xf101011f irq 35,36,37,38,39,40,41 on simplebus0 rtc0: mem 0xf1010300-0xf1010307 on simplebus0 twsi0: mem 0xf1011000-0xf101101f irq 43 on simplebus0 iicbus0: on twsi0 iic0: on iicbus0 mge0: mem 0xf1072000-0xf1073fff irq 12,13,14,11,46 on simplebus0 mge0: Ethernet address: 00:50:43:01:a1:32 miibus0: on mge0 e1000phy0: PHY 8 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto uart0: <16550 or compatible> mem 0xf1012000-0xf101201f irq 33 on simplebus0 uart0: console (114678,n,8,1) uart1: <16550 or compatible> mem 0xf1012100-0xf101211f irq 34 on simplebus0 cesa0: mem 0xf1030000-0xf103ffff irq 22 on simplebus0 ehci0: mem 0xf1050000-0xf1050fff irq 48,19 on simplebus0 usbus0: EHCI version 1.0 usbus0: stop timeout usbus0: set host controller mode vm_fault(0xc0cc6674, 0, 1, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xc0cfab68 FSR=00000005, FAR=00000010, spsr=200000d3 r0 =c36605c0, r1 =c0cc6390, r2 =600000d3, r3 =00000000 r4 =c0a4e65c, r5 =80000003, r6 =c36640d0, r7 =c0c12278 r8 =ffffffff, r9 =c350f280, r10=c3664080, r11=c0cfabf0 r12=c0cc8aa0, ssp=c0cfabb4, slr=c0c26698, pc =c0a50964 [ thread pid 0 tid 100000 ] Stopped at --=_duppyconqueror.embtoolkit.org-31700-1367452691-0001-2 Content-Type: text/plain; charset=utf-8; name="openrd-base.dts" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="openrd-base.dts" LyoKICogQ29weXJpZ2h0IChjKSAyMDA5LTIwMTAgVGhlIEZyZWVCU0QgRm91bmRhdGlvbgog KiBBbGwgcmlnaHRzIHJlc2VydmVkLgogKgogKiBUaGlzIHNvZnR3YXJlIHdhcyBkZXZlbG9w ZWQgYnkgU2VtaWhhbGYgdW5kZXIgc3BvbnNvcnNoaXAgZnJvbQogKiB0aGUgRnJlZUJTRCBG b3VuZGF0aW9uLgogKgogKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQg YmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKICogbW9kaWZpY2F0aW9uLCBhcmUgcGVy bWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCiAqIGFyZSBt ZXQ6CiAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0 aGUgYWJvdmUgY29weXJpZ2h0CiAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlv bnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KICogMi4gUmVkaXN0cmlidXRpb25z IGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKICog ICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBk aXNjbGFpbWVyIGluIHRoZQogKiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRl cmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgogKgogKiBUSElTIFNPRlRX QVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElT JycgQU5ECiAqIEFOWSBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5H LCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRQogKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVS Q0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQogKiBB UkUgRElTQ0xBSU1FRC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhPUiBPUiBDT05UUklC VVRPUlMgQkUgTElBQkxFCiAqIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRB TCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCiAqIERBTUFHRVMgKElO Q0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRF IEdPT0RTCiAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsg T1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKQogKiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5Z IFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAogKiBM SUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkg QVJJU0lORyBJTiBBTlkgV0FZCiAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUs IEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKICogU1VDSCBEQU1BR0Uu CiAqCiAqIE1hcnZlbGwgREItODhGNjI4MSBEZXZpY2UgVHJlZSBTb3VyY2UuCiAqCiAqICRG cmVlQlNEOiByZWxlYXNlLzkuMS4wL3N5cy9ib290L2ZkdC9kdHMvZGI4OGY2MjgxLmR0cyAy MzQ1NTkgMjAxMi0wNC0yMSAyMDoyMjowMlogcmFqICQKICovCgovZHRzLXYxLzsKCi8gewoJ bW9kZWwgPSAibXJ2bCxEQi04OEY2MjgxIjsKCWNvbXBhdGlibGUgPSAiREItODhGNjI4MS1C UCIsICJEQi04OEY2MjgxLUJQLUEiLCAiT3BlblJELUJBU0UiOwoJI2FkZHJlc3MtY2VsbHMg PSA8MT47Cgkjc2l6ZS1jZWxscyA9IDwxPjsKCglhbGlhc2VzIHsKCQlldGhlcm5ldDAgPSAm ZW5ldDA7CgkJbXBwID0gJk1QUDsKCQlwY2kwID0gJnBjaTA7CgkJc2VyaWFsMCA9ICZzZXJp YWwwOwoJCXNlcmlhbDEgPSAmc2VyaWFsMTsKCQlzb2MgPSAmU09DOwoJCXNyYW0gPSAmU1JB TTsKCX07CgoJY2hvc2VuIHsKCQlzdGRpbiAgPSAic2VyaWFsMCI7CgkJc3Rkb3V0ID0gInNl cmlhbDAiOwoJfTsKCgljcHVzIHsKCQkjYWRkcmVzcy1jZWxscyA9IDwxPjsKCQkjc2l6ZS1j ZWxscyA9IDwwPjsKCgkJY3B1QDAgewoJCQlkZXZpY2VfdHlwZSA9ICJjcHUiOwoJCQljb21w YXRpYmxlID0gIkFSTSw4OEZSMTMxIjsKCQkJcmVnID0gPDB4MD47CgkJCWQtY2FjaGUtbGlu ZS1zaXplID0gPDMyPjsJLy8gMzIgYnl0ZXMKCQkJaS1jYWNoZS1saW5lLXNpemUgPSA8MzI+ OwkvLyAzMiBieXRlcwoJCQlkLWNhY2hlLXNpemUgPSA8MHg0MDAwPjsJLy8gTDEsIDE2SwoJ CQlpLWNhY2hlLXNpemUgPSA8MHg0MDAwPjsJLy8gTDEsIDE2SwoJCQl0aW1lYmFzZS1mcmVx dWVuY3kgPSA8MD47CgkJCWJ1cy1mcmVxdWVuY3kgPSA8MD47CgkJCWNsb2NrLWZyZXF1ZW5j eSA9IDwwPjsKCQl9OwoJfTsKCgltZW1vcnkgewoJCWRldmljZV90eXBlID0gIm1lbW9yeSI7 CgkJcmVnID0gPDB4MCAweDIwMDAwMDAwPjsJCS8vIDUxMk0gYXQgMHgwCgl9OwoKCWxvY2Fs YnVzQGYxMDAwMDAwIHsKCQkjYWRkcmVzcy1jZWxscyA9IDwyPjsKCQkjc2l6ZS1jZWxscyA9 IDwxPjsKCQljb21wYXRpYmxlID0gIm1ydmwsbGJjIjsKCgkJLyogVGhpcyByZWZsZWN0cyBD UFUgZGVjb2RlIHdpbmRvd3Mgc2V0dXAuICovCgkJcmFuZ2VzID0gPDB4MCAweDBmIDB4Zjkz MDAwMDAgMHgwMDEwMDAwMAoJCQkgIDB4MSAweDFlIDB4ZmEwMDAwMDAgMHgwMDEwMDAwMAoJ CQkgIDB4MiAweDFkIDB4ZmExMDAwMDAgMHgwMjAwMDAwMAoJCQkgIDB4MyAweDFiIDB4ZmMx MDAwMDAgMHgwMDAwMDQwMD47CgoJCW5vckAwLDAgewoJCQkjYWRkcmVzcy1jZWxscyA9IDwx PjsKCQkJI3NpemUtY2VsbHMgPSA8MT47CgkJCWNvbXBhdGlibGUgPSAiY2ZpLWZsYXNoIjsK CQkJcmVnID0gPDB4MCAweDAgMHgwMDEwMDAwMD47CgkJCWJhbmstd2lkdGggPSA8Mj47CgkJ CWRldmljZS13aWR0aCA9IDwxPjsKCQl9OwoKCQlsZWRAMSwwIHsKCQkJI2FkZHJlc3MtY2Vs bHMgPSA8MT47CgkJCSNzaXplLWNlbGxzID0gPDE+OwoJCQljb21wYXRpYmxlID0gImxlZCI7 CgkJCXJlZyA9IDwweDEgMHgwIDB4MDAxMDAwMDA+OwoJCX07CgoJCW5vckAyLDAgewoJCQkj YWRkcmVzcy1jZWxscyA9IDwxPjsKCQkJI3NpemUtY2VsbHMgPSA8MT47CgkJCWNvbXBhdGli bGUgPSAiY2ZpLWZsYXNoIjsKCQkJcmVnID0gPDB4MiAweDAgMHgwMjAwMDAwMD47CgkJCWJh bmstd2lkdGggPSA8Mj47CgkJCWRldmljZS13aWR0aCA9IDwxPjsKCQl9OwoKCQluYW5kQDMs MCB7CgkJCSNhZGRyZXNzLWNlbGxzID0gPDE+OwoJCQkjc2l6ZS1jZWxscyA9IDwxPjsKCQkJ cmVnID0gPDB4MyAweDAgMHgwMDEwMDAwMD47CgkJCWJhbmstd2lkdGggPSA8Mj47CgkJCWRl dmljZS13aWR0aCA9IDwxPjsKCQl9OwoJfTsKCglTT0M6IHNvYzg4ZjYyODFAZjEwMDAwMDAg ewoJCSNhZGRyZXNzLWNlbGxzID0gPDE+OwoJCSNzaXplLWNlbGxzID0gPDE+OwoJCWNvbXBh dGlibGUgPSAic2ltcGxlLWJ1cyI7CgkJcmFuZ2VzID0gPDB4MCAweGYxMDAwMDAwIDB4MDAx MDAwMDA+OwoJCWJ1cy1mcmVxdWVuY3kgPSA8MD47CgoJCVBJQzogcGljQDIwMjAwIHsKCQkJ aW50ZXJydXB0LWNvbnRyb2xsZXI7CgkJCSNhZGRyZXNzLWNlbGxzID0gPDA+OwoJCQkjaW50 ZXJydXB0LWNlbGxzID0gPDE+OwoJCQlyZWcgPSA8MHgyMDIwMCAweDNjPjsKCQkJY29tcGF0 aWJsZSA9ICJtcnZsLHBpYyI7CgkJfTsKCgkJdGltZXJAMjAzMDAgewoJCQljb21wYXRpYmxl ID0gIm1ydmwsdGltZXIiOwoJCQlyZWcgPSA8MHgyMDMwMCAweDMwPjsKCQkJaW50ZXJydXB0 cyA9IDwxPjsKCQkJaW50ZXJydXB0LXBhcmVudCA9IDwmUElDPjsKCQkJbXJ2bCxoYXMtd2R0 OwoJCX07CgoJCU1QUDogbXBwQDEwMDAwIHsKCQkJI3Bpbi1jZWxscyA9IDwyPjsKCQkJY29t cGF0aWJsZSA9ICJtcnZsLG1wcCI7CgkJCXJlZyA9IDwweDEwMDAwIDB4MzQ+OwoJCQlwaW4t Y291bnQgPSA8NTA+OwoJCQlwaW4tbWFwID0gPAoJCQkJMCAgMQkJLyogTVBQWzBdOiAgTkZf SU9bMl0gKi8KCQkJCTEgIDEJCS8qIE1QUFsxXTogIE5GX0lPWzNdICovCgkJCQkyICAxCQkv KiBNUFBbMl06ICBORl9JT1s0XSAqLwoJCQkJMyAgMQkJLyogTVBQWzNdOiAgTkZfSU9bNV0g Ki8KCQkJCTQgIDEJCS8qIE1QUFs0XTogIE5GX0lPWzZdICovCgkJCQk1ICAxCQkvKiBNUFBb NV06ICBORl9JT1s3XSAqLwoJCQkJNiAgMQkJLyogTVBQWzZdOiAgU1lTUlNUX09VVG4gKi8K CQkJCTcgIDIJCS8qIE1QUFs3XTogIFNQSV9TQ24gKi8KCQkJCTggIDEJCS8qIE1QUFs4XTog IFRXX1NEQSAqLwoJCQkJOSAgMQkJLyogTVBQWzldOiAgVFdfU0NLICovCgkJCQkxMCAzCQkv KiBNUFBbMTBdOiBVQTBfVFhEICovCgkJCQkxMSAzCQkvKiBNUFBbMTFdOiBVQTBfUlhEICov CgkJCQkxMiAxCQkvKiBNUFBbMTJdOiBTRF9DTEsgKi8KCQkJCTEzIDEJCS8qIE1QUFsxM106 IFNEX0NNRCAqLwoJCQkJMTQgMQkJLyogTVBQWzE0XTogU0RfRFswXSAqLwoJCQkJMTUgMQkJ LyogTVBQWzE1XTogU0RfRFsxXSAqLwoJCQkJMTYgMQkJLyogTVBQWzE2XTogU0RfRFsyXSAq LwoJCQkJMTcgMQkJLyogTVBQWzE3XTogU0RfRFszXSAqLwoJCQkJMTggMQkJLyogTVBQWzE4 XTogTkZfSU9bMF0gKi8KCQkJCTE5IDEJCS8qIE1QUFsxOV06IE5GX0lPWzFdICovCgkJCQky MCA1CQkvKiBNUFBbMjBdOiBTQVRBMV9BQyAqLwoJCQkJMjEgNSA+OwkJLyogTVBQWzIxXTog U0FUQTBfQUMgKi8KCQl9OwoKCQlHUElPOiBncGlvQDEwMTAwIHsKCQkJI2dwaW8tY2VsbHMg PSA8Mz47CgkJCWNvbXBhdGlibGUgPSAibXJ2bCxncGlvIjsKCQkJcmVnID0gPDB4MTAxMDAg MHgyMD47CgkJCWdwaW8tY29udHJvbGxlcjsKCQkJaW50ZXJydXB0cyA9IDwzNSAzNiAzNyAz OCAzOSA0MCA0MT47CgkJCWludGVycnVwdC1wYXJlbnQgPSA8JlBJQz47CgkJfTsKCgkJcnRj QDEwMzAwIHsKCQkJY29tcGF0aWJsZSA9ICJtcnZsLHJ0YyI7CgkJCXJlZyA9IDwweDEwMzAw IDB4MDg+OwoJCX07CgoJCXR3c2lAMTEwMDAgewoJCQkjYWRkcmVzcy1jZWxscyA9IDwxPjsK CQkJI3NpemUtY2VsbHMgPSA8MD47CgkJCWNvbXBhdGlibGUgPSAibXJ2bCx0d3NpIjsKCQkJ cmVnID0gPDB4MTEwMDAgMHgyMD47CgkJCWludGVycnVwdHMgPSA8NDM+OwoJCQlpbnRlcnJ1 cHQtcGFyZW50ID0gPCZQSUM+OwoJCX07CgoJCWVuZXQwOiBldGhlcm5ldEA3MjAwMCB7CgkJ CSNhZGRyZXNzLWNlbGxzID0gPDE+OwoJCQkjc2l6ZS1jZWxscyA9IDwxPjsKCQkJbW9kZWwg PSAiVjIiOwoJCQljb21wYXRpYmxlID0gIm1ydmwsZ2UiOwoJCQlyZWcgPSA8MHg3MjAwMCAw eDIwMDA+OwoJCQlyYW5nZXMgPSA8MHgwIDB4NzIwMDAgMHgyMDAwPjsKCQkJbG9jYWwtbWFj LWFkZHJlc3MgPSBbIDAwIDAwIDAwIDAwIDAwIDAwIF07CgkJCWludGVycnVwdHMgPSA8MTIg MTMgMTQgMTEgNDY+OwoJCQlpbnRlcnJ1cHQtcGFyZW50ID0gPCZQSUM+OwoJCQlwaHktaGFu ZGxlID0gPCZwaHkwPjsKCgkJCW1kaW9AMCB7CgkJCQkjYWRkcmVzcy1jZWxscyA9IDwxPjsK CQkJCSNzaXplLWNlbGxzID0gPDA+OwoJCQkJY29tcGF0aWJsZSA9ICJtcnZsLG1kaW8iOwoK CQkJCXBoeTA6IGV0aGVybmV0LXBoeUAwIHsKCQkJCQlyZWcgPSA8MHg4PjsKCQkJCX07CgkJ CX07CgkJfTsKCgkJc2VyaWFsMDogc2VyaWFsQDEyMDAwIHsKCQkJY29tcGF0aWJsZSA9ICJu czE2NTUwIjsKCQkJcmVnID0gPDB4MTIwMDAgMHgyMD47CgkJCXJlZy1zaGlmdCA9IDwyPjsK CQkJY2xvY2stZnJlcXVlbmN5ID0gPDA+OwoJCQlpbnRlcnJ1cHRzID0gPDMzPjsKCQkJaW50 ZXJydXB0LXBhcmVudCA9IDwmUElDPjsKCQl9OwoKCQlzZXJpYWwxOiBzZXJpYWxAMTIxMDAg ewoJCQljb21wYXRpYmxlID0gIm5zMTY1NTAiOwoJCQlyZWcgPSA8MHgxMjEwMCAweDIwPjsK CQkJcmVnLXNoaWZ0ID0gPDI+OwoJCQljbG9jay1mcmVxdWVuY3kgPSA8MD47CgkJCWludGVy cnVwdHMgPSA8MzQ+OwoJCQlpbnRlcnJ1cHQtcGFyZW50ID0gPCZQSUM+OwoJCX07CgoJCWNy eXB0b0AzMDAwMCB7CgkJCWNvbXBhdGlibGUgPSAibXJ2bCxjZXNhIjsKCQkJcmVnID0gPDB4 MzAwMDAgMHgxMDAwMD47CgkJCWludGVycnVwdHMgPSA8MjI+OwoJCQlpbnRlcnJ1cHQtcGFy ZW50ID0gPCZQSUM+OwoKCQkJc3JhbS1oYW5kbGUgPSA8JlNSQU0+OwoJCX07CgoJCXVzYkA1 MDAwMCB7CgkJCWNvbXBhdGlibGUgPSAibXJ2bCx1c2ItZWhjaSIsICJ1c2ItZWhjaSI7CgkJ CXJlZyA9IDwweDUwMDAwIDB4MTAwMD47CgkJCWludGVycnVwdHMgPSA8NDggMTk+OwoJCQlp bnRlcnJ1cHQtcGFyZW50ID0gPCZQSUM+OwoJCX07CgoJCXhvckA2MDAwMCB7CgkJCWNvbXBh dGlibGUgPSAibXJ2bCx4b3IiOwoJCQlyZWcgPSA8MHg2MDAwMCAweDEwMDA+OwoJCQlpbnRl cnJ1cHRzID0gPDUgNiA3IDg+OwoJCQlpbnRlcnJ1cHQtcGFyZW50ID0gPCZQSUM+OwoJCX07 CgoJCXNhdGFAODAwMDAgewoJCQljb21wYXRpYmxlID0gIm1ydmwsc2F0YSI7CgkJCXJlZyA9 IDwweDgwMDAwIDB4NjAwMD47CgkJCWludGVycnVwdHMgPSA8MjE+OwoJCQlpbnRlcnJ1cHQt cGFyZW50ID0gPCZQSUM+OwoJCX07Cgl9OwoKCVNSQU06IHNyYW1AZmQwMDAwMDAgewoJCWNv bXBhdGlibGUgPSAibXJ2bCxjZXNhLXNyYW0iOwoJCXJlZyA9IDwweGZkMDAwMDAwIDB4MDAx MDAwMDA+OwoJfTsKCglwY2kwOiBwY2llQGYxMDQwMDAwIHsKCQljb21wYXRpYmxlID0gIm1y dmwscGNpZSI7CgkJZGV2aWNlX3R5cGUgPSAicGNpIjsKCQkjaW50ZXJydXB0LWNlbGxzID0g PDE+OwoJCSNzaXplLWNlbGxzID0gPDI+OwoJCSNhZGRyZXNzLWNlbGxzID0gPDM+OwoJCXJl ZyA9IDwweGYxMDQwMDAwIDB4MjAwMD47CgkJYnVzLXJhbmdlID0gPDAgMjU1PjsKCQlyYW5n ZXMgPSA8MHgwMjAwMDAwMCAweDAgMHhmMTMwMDAwMCAweGYxMzAwMDAwIDB4MCAweDA0MDAw MDAwCgkJCSAgMHgwMTAwMDAwMCAweDAgMHgwMDAwMDAwMCAweGYxMTAwMDAwIDB4MCAweDAw MTAwMDAwPjsKCQljbG9jay1mcmVxdWVuY3kgPSA8MzMzMzMzMzM+OwoJCWludGVycnVwdC1w YXJlbnQgPSA8JlBJQz47CgkJaW50ZXJydXB0cyA9IDw0ND47CgkJaW50ZXJydXB0LW1hcC1t YXNrID0gPDB4ZjgwMCAweDAgMHgwIDB4Nz47CgkJaW50ZXJydXB0LW1hcCA9IDwKCQkJLyog SURTRUwgMHgxICovCgkJCTB4MDgwMCAweDAgMHgwIDB4MSAmUElDIDB4OQoJCQkweDA4MDAg MHgwIDB4MCAweDIgJlBJQyAweDkKCQkJMHgwODAwIDB4MCAweDAgMHgzICZQSUMgMHg5CgkJ CTB4MDgwMCAweDAgMHgwIDB4NCAmUElDIDB4OQoJCQk+OwoJCXBjaWVAMCB7CgkJCXJlZyA9 IDwweDAgMHgwIDB4MCAweDAgMHgwPjsKCQkJI3NpemUtY2VsbHMgPSA8Mj47CgkJCSNhZGRy ZXNzLWNlbGxzID0gPDM+OwoJCQlkZXZpY2VfdHlwZSA9ICJwY2kiOwoJCQlyYW5nZXMgPSA8 MHgwMjAwMDAwMCAweDAgMHhmMTMwMDAwMAoJCQkJICAweDAyMDAwMDAwIDB4MCAweGYxMzAw MDAwCgkJCQkgIDB4MCAweDA0MDAwMDAwCgoJCQkJICAweDAxMDAwMDAwIDB4MCAweDAKCQkJ CSAgMHgwMTAwMDAwMCAweDAgMHgwCgkJCQkgIDB4MCAweDAwMTAwMDAwPjsKCQl9OwoJfTsK fTsK --=_duppyconqueror.embtoolkit.org-31700-1367452691-0001-2 Content-Type: text/plain; charset=utf-8; name=OPENRD-BASE Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="OPENRD-BASE" IwojIEN1c3RvbSBrZXJuZWwgZm9yIE1hcnZlbGwgREItODhGNnh4eCBib2FyZHMuCiMKIyAk RnJlZUJTRDogcmVsZWFzZS85LjEuMC9zeXMvYXJtL2NvbmYvREItODhGNlhYWCAyMzQ1NTkg MjAxMi0wNC0yMSAyMDoyMjowMlogcmFqICQKIwoKaWRlbnQJCU9wZW5SRC1CQVNFCmluY2x1 ZGUJCSIuLi9tdi9raXJrd29vZC9zdGQuZGI4OGY2eHh4IgoKb3B0aW9ucyAJU09DX01WX0tJ UktXT09ECm1ha2VvcHRpb25zCU1PRFVMRVNfT1ZFUlJJREU9IiIKCm1ha2VvcHRpb25zCURF QlVHPS1nCQkjQnVpbGQga2VybmVsIHdpdGggZ2RiKDEpIGRlYnVnIHN5bWJvbHMKbWFrZW9w dGlvbnMJV0VSUk9SPSItV2Vycm9yIgoKb3B0aW9ucyAJU0NIRURfNEJTRAkJIzRCU0Qgc2No ZWR1bGVyCm9wdGlvbnMgCUlORVQJCQkjSW50ZXJORVR3b3JraW5nCm9wdGlvbnMgCUlORVQ2 CQkJI0lQdjYgY29tbXVuaWNhdGlvbnMgcHJvdG9jb2xzCm9wdGlvbnMgCUZGUwkJCSNCZXJr ZWxleSBGYXN0IEZpbGVzeXN0ZW0Kb3B0aW9ucyAJTkZTQ0wJCQkjTmV3IE5ldHdvcmsgRmls ZXN5c3RlbSBDbGllbnQKb3B0aW9ucyAJTkZTTE9DS0QJCSNOZXR3b3JrIExvY2sgTWFuYWdl cgpvcHRpb25zIAlORlNfUk9PVAkJI05GUyB1c2FibGUgYXMgLywgcmVxdWlyZXMgTkZTQ0wK b3B0aW9ucyAJQk9PVFAKb3B0aW9ucyAJQk9PVFBfTkZTUk9PVApvcHRpb25zIAlCT09UUF9O RlNWMwpvcHRpb25zIAlCT09UUF9XSVJFRF9UTz1tZ2UwCgojb3B0aW9ucyAJUk9PVERFVk5B TUU9XCJ1ZnM6L2Rldi9kYTBhXCIKCm9wdGlvbnMgCVNZU1ZTSE0JCQkjU1lTVi1zdHlsZSBz aGFyZWQgbWVtb3J5Cm9wdGlvbnMgCVNZU1ZNU0cJCQkjU1lTVi1zdHlsZSBtZXNzYWdlIHF1 ZXVlcwpvcHRpb25zIAlTWVNWU0VNCQkJI1NZU1Ytc3R5bGUgc2VtYXBob3JlcwpvcHRpb25z IAlfS1BPU0lYX1BSSU9SSVRZX1NDSEVEVUxJTkcgI1Bvc2l4IFAxMDAzXzFCIHJlYWwtdGlt ZSBleHRlbnNpb25zCm9wdGlvbnMgCU1VVEVYX05PSU5MSU5FCm9wdGlvbnMgCVJXTE9DS19O T0lOTElORQpvcHRpb25zIAlOT19GRlNfU05BUFNIT1QKb3B0aW9ucyAJTk9fU1dBUFBJTkcK CiMgRGVidWdnaW5nCm9wdGlvbnMgCUFMVF9CUkVBS19UT19ERUJVR0dFUgpvcHRpb25zIAlE REIKb3B0aW9ucyAJREVBRExLUkVTCQkjRW5hYmxlIHRoZSBkZWFkbG9jayByZXNvbHZlcgpv cHRpb25zIAlESUFHTk9TVElDCm9wdGlvbnMgCUlOVkFSSUFOVFMJCSNFbmFibGUgY2FsbHMg b2YgZXh0cmEgc2FuaXR5IGNoZWNraW5nCm9wdGlvbnMgCUlOVkFSSUFOVF9TVVBQT1JUCSNF eHRyYSBzYW5pdHkgY2hlY2tzIG9mIGludGVybmFsIHN0cnVjdHVyZXMsIHJlcXVpcmVkIGJ5 IElOVkFSSUFOVFMKb3B0aW9ucyAJS0RCCgojIFBDSSBleHByZXNzCmRldmljZQkJcGNpCgoj IFBzZXVkbyBkZXZpY2VzCmRldmljZQkJbG9vcApkZXZpY2UJCW1kCmRldmljZQkJcHR5CmRl dmljZQkJcmFuZG9tCgojIFNlcmlhbCBwb3J0cwpkZXZpY2UJCXVhcnQKCiMgTmV0d29ya2lu ZwpkZXZpY2UJCWV0aGVyCmRldmljZQkJbWdlCQkJIyBNYXJ2ZWxsIEdpZ2FiaXQgRXRoZXJu ZXQgY29udHJvbGxlcgpkZXZpY2UJCW1paQpkZXZpY2UJCWUxMDAwcGh5CmRldmljZQkJYnBm Cm9wdGlvbnMJCUhaPTEwMDAKb3B0aW9ucwkJREVWSUNFX1BPTExJTkcKZGV2aWNlCQl2bGFu CgpkZXZpY2UJCWNlc2EJCQkjIE1hcnZlbGwgc2VjdXJpdHkgZW5naW5lCmRldmljZQkJY3J5 cHRvCmRldmljZQkJY3J5cHRvZGV2CgojIFVTQgpvcHRpb25zIAlVU0JfREVCVUcJIyBlbmFi bGUgZGVidWcgbXNncwpkZXZpY2UJCXVzYgpkZXZpY2UJCWVoY2kKZGV2aWNlCQl1bWFzcwpk ZXZpY2UJCXNjYnVzCmRldmljZQkJcGFzcwpkZXZpY2UJCWRhCgojIEkyQyAoVFdTSSkKZGV2 aWNlCQlpaWMKZGV2aWNlCQlpaWNidXMKCiMgU0FUQQpkZXZpY2UJCW12cwoKIyBGbGF0dGVu ZWQgRGV2aWNlIFRyZWUKb3B0aW9ucyAJRkRUCm9wdGlvbnMJCUZEVF9EVEJfU1RBVElDCm1h a2VvcHRpb25zCUZEVF9EVFNfRklMRT1vcGVucmQtYmFzZS5kdHMK --=_duppyconqueror.embtoolkit.org-31700-1367452691-0001-2-- From owner-freebsd-arm@FreeBSD.ORG Thu May 2 03:28:29 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1EB2F911 for ; Thu, 2 May 2013 03:28:29 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id E9BE511BB for ; Thu, 2 May 2013 03:28:28 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id b11so208488iee.37 for ; Wed, 01 May 2013 20:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aunb5G0dXDDdf3Ca1RCIidjuiiSSjLlOttHM990BPcA=; b=yoOxvEQAShb5owje7qz9qko3rElgztCjd6J6MwnLOAsgvSAzcFBAllE0XaIvwUhOkF ueF/+c5kLknzekdhyPah4szc1BbXfBtwZptFD+WvAUsBTJcm/t9xB0nCwi+kdBM1E7wn 4FG0wcvmVkHVaf07UQMOuwnxuAn1vEiMsA1pDRhcTfpY9Sb8v8Yi8+VfMBpe4JghSGHM GBHlwtY8ZZ0dTfWdKLTp2W3i8rxzsqN6VHwoO+/VN/zWQe66SQMoh75lTApZq7yka+hK Ue5oJSXYG5UxBh99Cft8e6tkSLfd55oISx7XxcWIblnu2ic5drQj2kj8k+QvWZBD/Xne xeXg== MIME-Version: 1.0 X-Received: by 10.50.17.71 with SMTP id m7mr3194799igd.5.1367465308700; Wed, 01 May 2013 20:28:28 -0700 (PDT) Received: by 10.64.23.167 with HTTP; Wed, 1 May 2013 20:28:28 -0700 (PDT) In-Reply-To: <63837.85.229.93.125.1367417396.squirrel@alvermark.net> References: <63837.85.229.93.125.1367417396.squirrel@alvermark.net> Date: Thu, 2 May 2013 11:28:28 +0800 Message-ID: Subject: Re: Allwinner A13: Fatal kernel mode data abort: 'Translation Fault (S)' From: Ganbold Tsagaankhuu To: Jakob Alvermark Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 03:28:29 -0000 On Wed, May 1, 2013 at 10:09 PM, Jakob Alvermark wrote: > Hi again, > > In my effort to get FreeBSD running on the A13 I got a little further, > however not quite so far as I was hoping for. > > Any clues on this? > If you built the kernel with custom dts then please try with cubieboard.dts and see how it works. Ganbold > > Jakob > > sun5i#go 0x40200100 > ## Starting application at 0x40200100 ... > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2013 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 10.0-CURRENT #0 r250141M: Wed May 1 14:15:44 CEST 2013 > root@test10:/home/jakob/a13-gonzo/obj/arm.armv6/usr/src/sys/A13 arm > FreeBSD clang version 3.3 (trunk 178860) 20130405 > WARNING: WITNESS option enabled, expect reduced performance. > CPU: Cortex A8-r3 rev 2 (Cortex-A core) > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > WB disabled EABT branch prediction enabled > LoUU:2 LoC:2 LoUIS:1 > Cache level 1: > 32KB/64B 4-way data cache WT WB Read-Alloc > 32KB/64B 4-way instruction cache Read-Alloc > Cache level 2: > 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc > real memory = 536870912 (512 MB) > avail memory = 511303680 (487 MB) > random device not loaded; using insecure entropy > simplebus0: on fdtbus0 > a13_ccm0: mem 0x1c20000-0x1c203ff on > simplebus0 > a13_timer0: mem 0x1c20c00-0x1c20c8f irq 22 on > simplebus0 > > vm_fault(0xc0716ff8, 0, 1, 0) -> 1 > Fatal kernel mode data abort: 'Translation Fault (S)' > trapframe: 0xc072aad4 > FSR=00000005, FAR=00000008, spsr=a00000d3 > r0 =00000000, r1 =00000004, r2 =00000001, r3 =c2f93b48 > r4 =00000120, r5 =00000040, r6 =c30ac500, r7 =00000000 > r8 =c0716508, r9 =00000000, r10=00000016, r11=c072ab40 > r12=c0716da4, ssp=c072ab20, slr=c04b0c64, pc =c04c013c > > [ thread pid 0 tid 100000 ] > Stopped at arm_unmask_irq+0x24: ldr r2, [r0, #0x008] > db> > > > _______________________________________________ > 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 May 2 07:29:33 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4AD9612C for ; Thu, 2 May 2013 07:29:33 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from smtprelay-b31.telenor.se (smtprelay-b31.telenor.se [213.150.131.20]) by mx1.freebsd.org (Postfix) with ESMTP id BA7931B44 for ; Thu, 2 May 2013 07:29:32 +0000 (UTC) Received: from ipb5.telenor.se (ipb5.telenor.se [195.54.127.168]) by smtprelay-b31.telenor.se (Postfix) with ESMTP id 50BDFD351 for ; Thu, 2 May 2013 09:29:25 +0200 (CEST) X-SENDER-IP: [85.229.94.62] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhBAAKcUglFV5V4+PGdsb2JhbABSgwc3AbZwAYgzgQEXAwEBAQE4NYIfAQEBAQIBAQEBJCcIGAsFCwsYLicBBQQIChQGCAcEARwEh2UKCL8wjXCBMgeCcWEDlGeDaJMabIEE X-IronPort-AV: E=Sophos;i="4.87,595,1363129200"; d="scan'208,217";a="320218013" Received: from c-3e5ee555.06-11-73746f31.cust.bredbandsbolaget.se (HELO sigyn.alvermark.net) ([85.229.94.62]) by ipb5.telenor.se with ESMTP; 02 May 2013 09:29:24 +0200 Received: from gw.inter-sonic.com ([212.247.8.97] helo=[192.168.1.191]) by sigyn.alvermark.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UXnxD-0008uF-Lg; Thu, 02 May 2013 09:29:23 +0200 Subject: Re: Allwinner A13: Fatal kernel mode data abort: 'Translation Fault (S)' Mime-Version: 1.0 (Apple Message framework v1085) From: Jakob Alvermark In-Reply-To: Date: Thu, 2 May 2013 09:29:22 +0200 Message-Id: <17294042-8AA9-4866-95CF-E00FD03ABD2B@alvermark.net> References: <63837.85.229.93.125.1367417396.squirrel@alvermark.net> To: Ganbold Tsagaankhuu X-Mailer: Apple Mail (2.1085) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 07:29:33 -0000 On 2 maj 2013, at 05:28, Ganbold Tsagaankhuu wrote: > On Wed, May 1, 2013 at 10:09 PM, Jakob Alvermark = wrote: > Hi again, >=20 > In my effort to get FreeBSD running on the A13 I got a little further, > however not quite so far as I was hoping for. >=20 > Any clues on this? >=20 >=20 > If you built the kernel with custom dts then please try with = cubieboard.dts and see how it works. I found the problem, I had made another mistake. Now it boots to multiuser! I have made some changes to the .dts and drivers and I have some ideas = about doing it a little differently. I will clean it up a bit and send a diff. Maybe someone could review it. The GPIO stuff is also a little different from A10 and needs some work. Jakob > Ganbold >=20 > =20 >=20 > Jakob >=20 > sun5i#go 0x40200100 > ## Starting application at 0x40200100 ... > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2013 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 > The Regents of the University of California. All rights = reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 10.0-CURRENT #0 r250141M: Wed May 1 14:15:44 CEST 2013 > root@test10:/home/jakob/a13-gonzo/obj/arm.armv6/usr/src/sys/A13 = arm > FreeBSD clang version 3.3 (trunk 178860) 20130405 > WARNING: WITNESS option enabled, expect reduced performance. > CPU: Cortex A8-r3 rev 2 (Cortex-A core) > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > WB disabled EABT branch prediction enabled > LoUU:2 LoC:2 LoUIS:1 > Cache level 1: > 32KB/64B 4-way data cache WT WB Read-Alloc > 32KB/64B 4-way instruction cache Read-Alloc > Cache level 2: > 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc > real memory =3D 536870912 (512 MB) > avail memory =3D 511303680 (487 MB) > random device not loaded; using insecure entropy > simplebus0: on fdtbus0 > a13_ccm0: mem 0x1c20000-0x1c203ff on > simplebus0 > a13_timer0: mem 0x1c20c00-0x1c20c8f irq 22 on > simplebus0 >=20 > vm_fault(0xc0716ff8, 0, 1, 0) -> 1 > Fatal kernel mode data abort: 'Translation Fault (S)' > trapframe: 0xc072aad4 > FSR=3D00000005, FAR=3D00000008, spsr=3Da00000d3 > r0 =3D00000000, r1 =3D00000004, r2 =3D00000001, r3 =3Dc2f93b48 > r4 =3D00000120, r5 =3D00000040, r6 =3Dc30ac500, r7 =3D00000000 > r8 =3Dc0716508, r9 =3D00000000, r10=3D00000016, r11=3Dc072ab40 > r12=3Dc0716da4, ssp=3Dc072ab20, slr=3Dc04b0c64, pc =3Dc04c013c >=20 > [ thread pid 0 tid 100000 ] > Stopped at arm_unmask_irq+0x24: ldr r2, [r0, #0x008] > db> >=20 >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 From owner-freebsd-arm@FreeBSD.ORG Thu May 2 14:37:14 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7A56D7D2 for ; Thu, 2 May 2013 14:37:14 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 4F7071062 for ; Thu, 2 May 2013 14:37:14 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id aq17so725821iec.1 for ; Thu, 02 May 2013 07:37:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=gLEGtTo8ptdDTkgM+9swqQ2G5u3B07kbh/u6yHa/zRM=; b=VEhXE7JT7pfaJLccVeBVuq7JUmlZrs55N3AyD7xz/N8kbHXBt8CPOa6EAhGiLSZMKp TvRm/+C0qU9EaExJn0VBXKvqpAk8nyBTxznaovMRo9x5V/M4h0iKnVfStkYyFhgm1CV5 vkjyfNK1uelVU1toXipG3hbAs+xps2efoAwnyLvpO4fY0iXQquXJ7XsR0GX9vJdOKsS+ UGN6ogPKR8TQsnI/L/89gTRTfITBq9qfkCoNnFCWPcWLAyVdAZDEVvM51mvx0AFU3TTg sXD81Sdmq6nLbwYkgIInT0IcEG7R7uyHfvheVEVjUZOwr/8Mg/VIO19ayGni89es7dHG nh0w== MIME-Version: 1.0 X-Received: by 10.50.17.166 with SMTP id p6mr9222927igd.12.1367505433578; Thu, 02 May 2013 07:37:13 -0700 (PDT) Received: by 10.64.34.71 with HTTP; Thu, 2 May 2013 07:37:13 -0700 (PDT) In-Reply-To: References: <201304301505.r3UF5OOd026408@kithrup.com> Date: Thu, 2 May 2013 22:37:13 +0800 Message-ID: Subject: Re: Raspberry Pi: Cannot mount root (error 19) From: Alie Tan To: Tom Everett X-Gm-Message-State: ALoCoQmZuVpkA9DS/xdGj1OofIShWwn2sGDyrUaR5/Q2x3DoaEmrmtJfdYnAZxMig8MiW5wZmXv9 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Sean Eric Fagan , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 14:37:14 -0000 I am getting error 19 but not 100% reproduce-able, its like 1 time every 2-3 boot On Wed, May 1, 2013 at 12:04 AM, Tom Everett wrote: > If you're interested, there are some CURRENT images here: > > http://files.khubla.com, and quick discussion of creating them with > gonzo's > script here: http://blog.khubla.com > > > > > > On Tue, Apr 30, 2013 at 9:05 AM, Sean Eric Fagan wrote: > > > I've tried rebuilding the image several times; I haven't tried dropping > > back > > to using FreeBSD 9 instead of 10 as the host for building. > > > > Any ideas? > > > > _______________________________________________ > > 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" > > > > > > -- > A better world shall emerge based on faith and understanding - Douglas > MacArthur > _______________________________________________ > 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 May 2 15:09:46 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C5FB8482 for ; Thu, 2 May 2013 15:09:46 +0000 (UTC) (envelope-from tom@0x544745.com) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by mx1.freebsd.org (Postfix) with ESMTP id 92E0F1222 for ; Thu, 2 May 2013 15:09:45 +0000 (UTC) Received: by mail-oa0-f47.google.com with SMTP id m1so626559oag.6 for ; Thu, 02 May 2013 08:09:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=sEHVBnWwh+U39FleIqfnwWHOAIz8PoGa3OV18AVuyzY=; b=E9KuWx2l1wX7+CsTuBJxzjmsM3Sddv8osOsRLmOy3unYJni5OSXfQwXwE/JO4thgJB BB2LbTFbkASA+/fvAkfsKSb5gccwE807DtNfRt0mwD8aUyhlbV7qZbeUBunMQjuCdjKC oED0LqRzhsR5srG3eKGAUFlu+SE4EbCRs6vWm/eEPyBSC2FEYXzPIJbK1CifyZDqboJy idnr8oU5dr9jylwTYc0sTyHpIfKVgivz/iySASuY5Tpdyq4BPhcmWk+EllrtRRMxDPKF 6BfTuUgIYjgTYpnH71BoTgxCkriSZdU/gJXQzfg2tBcUbuxBZjw5Cb3cF/iEJlcyHVvE VCdg== MIME-Version: 1.0 X-Received: by 10.182.237.50 with SMTP id uz18mr1874024obc.51.1367507385375; Thu, 02 May 2013 08:09:45 -0700 (PDT) Received: by 10.182.245.5 with HTTP; Thu, 2 May 2013 08:09:45 -0700 (PDT) In-Reply-To: References: <201304301505.r3UF5OOd026408@kithrup.com> Date: Thu, 2 May 2013 09:09:45 -0600 Message-ID: Subject: Re: Raspberry Pi: Cannot mount root (error 19) From: Tom Everett To: Alie Tan X-Gm-Message-State: ALoCoQnnsDafIPtVVz1uAKllZSCFsn9Irq3CCFWgDUFVR2zyg/6sLVx0KjYjOaHB1jOYI6nnRk9W Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Sean Eric Fagan , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 15:09:46 -0000 Hm. Interesting. Gimme 10 min and I'll upload a new build. I did this one last night FreeBSD-HEAD-r250165-ARMv6-RPI-B-WIFI-4GB.img.tgz On Thu, May 2, 2013 at 8:37 AM, Alie Tan wrote: > I am getting error 19 but not 100% reproduce-able, its like 1 time every > 2-3 boot > > > On Wed, May 1, 2013 at 12:04 AM, Tom Everett wrote: > >> If you're interested, there are some CURRENT images here: >> >> http://files.khubla.com, and quick discussion of creating them with >> gonzo's >> script here: http://blog.khubla.com >> >> >> >> >> >> On Tue, Apr 30, 2013 at 9:05 AM, Sean Eric Fagan wrote: >> >> > I've tried rebuilding the image several times; I haven't tried dropping >> > back >> > to using FreeBSD 9 instead of 10 as the host for building. >> > >> > Any ideas? >> > >> > _______________________________________________ >> > 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" >> > >> >> >> >> -- >> A better world shall emerge based on faith and understanding - Douglas >> MacArthur >> _______________________________________________ >> 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" >> > > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Thu May 2 15:22:01 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8D1B8B01 for ; Thu, 2 May 2013 15:22:01 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id 644FA1319 for ; Thu, 2 May 2013 15:22:01 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UXvKU-000LxA-Lx; Thu, 02 May 2013 15:21:54 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r42FLql6009978; Thu, 2 May 2013 09:21:52 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19r9RwTlrqrSYqR04vdgqtD Subject: Re: vm fault on OpenRD [was: Re: Allwinner A13: Fatal kernel mode data abort: 'Translation Fault (S)'] From: Ian Lepore To: Abdoulaye Walsimou Gaye In-Reply-To: <5181AC1A.2020400@embtoolkit.org> References: <63837.85.229.93.125.1367417396.squirrel@alvermark.net> <5181AC1A.2020400@embtoolkit.org> Content-Type: multipart/mixed; boundary="=-ebWqrFW/G1F17ZAePZ+W" Date: Thu, 02 May 2013 09:21:51 -0600 Message-ID: <1367508111.1180.112.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 15:22:01 -0000 --=-ebWqrFW/G1F17ZAePZ+W Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, 2013-05-02 at 01:58 +0200, Abdoulaye Walsimou Gaye wrote: > On 05/01/2013 04:09 PM, Jakob Alvermark wrote: > > [...] > > > > Hello, > I have similar boot error while trying to boot my openrd-base, with a KERNCONF based on DB-88F6XXX (see attached files) > > ## Starting application at 0x00900000 ... > dtbp = 0xc0c9a8f8 > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2013 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.1-STABLE #1 r+aed5102-dirty: Thu May 2 01:50:19 CEST 2013 > walsimou@vbox-fbsd64:/home/walsimou/embtk-fbsd/obj/arm.arm/usr/home/walsimou/freebsd.git/sys/OPENRD-BASE arm > gcc version 4.2.1 20070831 patched [FreeBSD] > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > module mvs already present! > CPU: Feroceon 88FR131 rev 1 (Marvell core) > DC enabled IC enabled WB enabled EABT branch prediction enabled > 16KB/32B 4-way Instruction cache > 16KB/32B 4-way write-back-locking-C Data cache > real memory = 536870912 (512 MB) > avail memory = 519278592 (495 MB) > SOC: Marvell 88F6281 rev A0, TClock 200MHz > simplebus0: on fdtbus0 > ic0: mem 0xf1020200-0xf102023b on simplebus0 > timer0: mem 0xf1020300-0xf102032f irq 1 on simplebus0 > Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 > Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 > gpio0: mem 0xf1010100-0xf101011f irq 35,36,37,38,39,40,41 on simplebus0 > rtc0: mem 0xf1010300-0xf1010307 on simplebus0 > twsi0: mem 0xf1011000-0xf101101f irq 43 on simplebus0 > iicbus0: on twsi0 > iic0: on iicbus0 > mge0: mem 0xf1072000-0xf1073fff irq 12,13,14,11,46 on simplebus0 > mge0: Ethernet address: 00:50:43:01:a1:32 > miibus0: on mge0 > e1000phy0: PHY 8 on miibus0 > e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto > uart0: <16550 or compatible> mem 0xf1012000-0xf101201f irq 33 on simplebus0 > uart0: console (114678,n,8,1) > uart1: <16550 or compatible> mem 0xf1012100-0xf101211f irq 34 on simplebus0 > cesa0: mem 0xf1030000-0xf103ffff irq 22 on simplebus0 > ehci0: mem 0xf1050000-0xf1050fff irq 48,19 on simplebus0 > usbus0: EHCI version 1.0 > usbus0: stop timeout > usbus0: set host controller mode > > vm_fault(0xc0cc6674, 0, 1, 0) -> 1 > Fatal kernel mode data abort: 'Translation Fault (S)' > trapframe: 0xc0cfab68 > FSR=00000005, FAR=00000010, spsr=200000d3 > r0 =c36605c0, r1 =c0cc6390, r2 =600000d3, r3 =00000000 > r4 =c0a4e65c, r5 =80000003, r6 =c36640d0, r7 =c0c12278 > r8 =ffffffff, r9 =c350f280, r10=c3664080, r11=c0cfabf0 > r12=c0cc8aa0, ssp=c0cfabb4, slr=c0c26698, pc =c0a50964 > > [ thread pid 0 tid 100000 ] > Stopped at While the error messages are similar, it appears that the cause is completely different. Given that it appears to have crashed while initializing USB, I can think of two things to try... Add USB_HOST_ALIGN=32 to your kernel config file. This is required for all armv4 and armv5 platforms, but isn't in most of our stock config files right now. Also, try the attached patch. It avoids unconditionally enabling the cache "allocate on write" feature in the hardware, and instead leaves it in whatever state the bootloader set it to (on the assumption that the vendor-supplied bootloader knows best about when this feature is problematic; I think it may depend somewhat on how the board is designed). -- Ian --=-ebWqrFW/G1F17ZAePZ+W Content-Disposition: inline; filename="marvell_no_wralloc.diff" Content-Type: text/x-patch; name="marvell_no_wralloc.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/arm/arm/cpufunc.c =================================================================== --- sys/arm/arm/cpufunc.c (revision 243412) +++ sys/arm/arm/cpufunc.c (working copy) @@ -1067,13 +1067,13 @@ set_cpufuncs() */ if (cputype == CPU_ID_MV88FR571_VD || cputype == CPU_ID_MV88FR571_41) { - sheeva_control_ext(0xffffffff, - FC_DCACHE_STREAM_EN | FC_WR_ALLOC_EN | + sheeva_control_ext(0xffffffff & ~FC_WR_ALLOC_EN, + FC_DCACHE_STREAM_EN | FC_BRANCH_TARG_BUF_DIS | FC_L2CACHE_EN | FC_L2_PREF_DIS); } else { - sheeva_control_ext(0xffffffff, - FC_DCACHE_STREAM_EN | FC_WR_ALLOC_EN | + sheeva_control_ext(0xffffffff & ~FC_WR_ALLOC_EN, + FC_DCACHE_STREAM_EN | FC_BRANCH_TARG_BUF_DIS | FC_L2CACHE_EN); } --=-ebWqrFW/G1F17ZAePZ+W-- From owner-freebsd-arm@FreeBSD.ORG Thu May 2 15:24:05 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 875F6B74; Thu, 2 May 2013 15:24:05 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 3AB05133D; Thu, 2 May 2013 15:24:05 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 469C6D4C8F; Thu, 2 May 2013 17:24:04 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id ukndJudYkgvE; Thu, 2 May 2013 17:24:03 +0200 (CEST) Received: from [10.0.2.117] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id A3B29D4C7C; Thu, 2 May 2013 17:24:03 +0200 (CEST) Message-ID: <51828513.9000406@semihalf.com> Date: Thu, 02 May 2013 17:24:03 +0200 From: Zbyszek Bodek User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: RFC: Patches with AXP support and pmap&smp fixes. References: <517E8610.5050204@semihalf.com> <1367338875.1180.44.camel@revolution.hippie.lan> In-Reply-To: <1367338875.1180.44.camel@revolution.hippie.lan> 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 15:24:05 -0000 On 30.04.2013 18:21, Ian Lepore wrote: > On Mon, 2013-04-29 at 16:39 +0200, Grzegorz Bernacki wrote: >> Hi, >> >> I am going to submit some changes related to Armada XP support and some >> general ARM fixes. You can find them at: >> http://people.freebsd.org/~gber/armada >> >> It would be good if someone could review changes in generic ARM code i.e.: >> 1) >> http://people.freebsd.org/~gber/armada/0004-arm-smp-Fix-AP-processors-initialization-procedure.patch >> >> This patch fixes race condition in pcpu_init function. pcpu_init >> performs operation on signly-linked tail queue and the queue can be >> corrupted by secondary cpus initialization. >> >> 2) >> http://people.freebsd.org/~gber/armada/0007-arm-Fix-L2-PTE-access-permissions-management.patch >> http://people.freebsd.org/~gber/armada/0008-arm-Fix-page-reference-emulation-on-ARMv6-and-v7.patch >> >> These are changes which fixes reference simulation and access >> permissions in pmap v6. >> >> It would be great if you could also review armada patches. >> We will appreciate all comments and remarks. If there will be no >> objections I am going to submit these changes at the beginning of the >> next week. >> >> thanks, >> greg > > I've reviewed them, and see no problems. It might not be a bad idea to > paste the protections truth table from the commit message as a comment > block in pmap_set_prot(); I had to keep referring to it while convincing > myself the changes were right for every path through the routine. > > -- Ian > Hello Ian, Sure, we will add suggested comment to the code. But would it not be better to place it in the pmap.h file just before L2_S_PROT_R, L2_S_PROT_U, etc. definitions. Please notice that the similar to pmap_set_prot() protections setting sequence is also used in pmap_enter_locked(). What is your opinion? Best regards Zbyszek Bodek From owner-freebsd-arm@FreeBSD.ORG Thu May 2 15:40:00 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BD960C4 for ; Thu, 2 May 2013 15:40:00 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by mx1.freebsd.org (Postfix) with ESMTP id 97E661474 for ; Thu, 2 May 2013 15:40:00 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UXvbz-0003Rm-Sr; Thu, 02 May 2013 15:40:00 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r42FdvCl010049; Thu, 2 May 2013 09:39:57 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/Or/ZIdwry20SftJflJ45I Subject: Re: RFC: Patches with AXP support and pmap&smp fixes. From: Ian Lepore To: Zbyszek Bodek In-Reply-To: <51828513.9000406@semihalf.com> References: <517E8610.5050204@semihalf.com> <1367338875.1180.44.camel@revolution.hippie.lan> <51828513.9000406@semihalf.com> Content-Type: text/plain; charset="us-ascii" Date: Thu, 02 May 2013 09:39:57 -0600 Message-ID: <1367509197.1180.120.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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 15:40:00 -0000 On Thu, 2013-05-02 at 17:24 +0200, Zbyszek Bodek wrote: > On 30.04.2013 18:21, Ian Lepore wrote: > > On Mon, 2013-04-29 at 16:39 +0200, Grzegorz Bernacki wrote: > >> Hi, > >> > >> I am going to submit some changes related to Armada XP support and some > >> general ARM fixes. You can find them at: > >> http://people.freebsd.org/~gber/armada > >> > >> It would be good if someone could review changes in generic ARM code i.e.: > >> 1) > >> http://people.freebsd.org/~gber/armada/0004-arm-smp-Fix-AP-processors-initialization-procedure.patch > >> > >> This patch fixes race condition in pcpu_init function. pcpu_init > >> performs operation on signly-linked tail queue and the queue can be > >> corrupted by secondary cpus initialization. > >> > >> 2) > >> http://people.freebsd.org/~gber/armada/0007-arm-Fix-L2-PTE-access-permissions-management.patch > >> http://people.freebsd.org/~gber/armada/0008-arm-Fix-page-reference-emulation-on-ARMv6-and-v7.patch > >> > >> These are changes which fixes reference simulation and access > >> permissions in pmap v6. > >> > >> It would be great if you could also review armada patches. > >> We will appreciate all comments and remarks. If there will be no > >> objections I am going to submit these changes at the beginning of the > >> next week. > >> > >> thanks, > >> greg > > > > I've reviewed them, and see no problems. It might not be a bad idea to > > paste the protections truth table from the commit message as a comment > > block in pmap_set_prot(); I had to keep referring to it while convincing > > myself the changes were right for every path through the routine. > > > > -- Ian > > > > Hello Ian, > > Sure, we will add suggested comment to the code. > But would it not be better to place it in the pmap.h file > just before L2_S_PROT_R, L2_S_PROT_U, etc. definitions. > Please notice that the similar to pmap_set_prot() protections setting > sequence is also used in pmap_enter_locked(). > > What is your opinion? > > Best regards > Zbyszek Bodek > Yes, I think it does make more sense to put the comment block near where the constants are defined. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu May 2 15:55:20 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 434AD3DE for ; Thu, 2 May 2013 15:55:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 1459E158A for ; Thu, 2 May 2013 15:55:20 +0000 (UTC) Received: by mail-ia0-f174.google.com with SMTP id e36so588306iag.33 for ; Thu, 02 May 2013 08:55:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=Uc5Qw0VtcMRAeUn8xLdBWCKYoDsYmIzhExuN99rJbuc=; b=WgDJBBsv60+PVOedbZtT7vd1j3jcCZM1mCaUQcRBpNPeb/m/baIGfS4SQ/bAF5M3y+ LyvRNKoKZu+CslJC9fWRD+27eiMvyARbwf2C9P/y5hqEGLWysvbgXULOVgPU/2LWYK4D 4nvxQagQBoaH4NUlE/FQvpoACJCbGj+5HfIKOTWPY2X4yVs3A3xUeDEKeu+HBqxPCKHB oLswhFo37oxhBOmYFvbPM5UB0s8WizbimbBsCsh7aSsj1XZCpgGrBOFl2uUXR29ELzY+ UV8OYW/XI/vfEF2BD9xepXwQ1gUaPHFb3dLP0pn4Oq2kBVE/9Rm/ffK//nGcm5e7KB5n wMkw== X-Received: by 10.50.120.102 with SMTP id lb6mr4113217igb.103.1367510119620; Thu, 02 May 2013 08:55:19 -0700 (PDT) Received: from [10.0.0.53] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id f16sm9047770igt.8.2013.05.02.08.55.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 May 2013 08:55:18 -0700 (PDT) Sender: Warner Losh Subject: Re: vm fault on OpenRD [was: Re: Allwinner A13: Fatal kernel mode data abort: 'Translation Fault (S)'] Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1367508111.1180.112.camel@revolution.hippie.lan> Date: Thu, 2 May 2013 09:55:12 -0600 Content-Transfer-Encoding: 7bit Message-Id: <473929FE-61BB-4347-85A0-FD7F43BE4D63@bsdimp.com> References: <63837.85.229.93.125.1367417396.squirrel@alvermark.net> <5181AC1A.2020400@embtoolkit.org> <1367508111.1180.112.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnkUBTU86L8iUcUh23hliTbokpEWwe3/8JUyO391IwD1KlZQany48xZFdrYcLZ/1DxAy/tz Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 15:55:20 -0000 On May 2, 2013, at 9:21 AM, Ian Lepore wrote: > > Add USB_HOST_ALIGN=32 to your kernel config file. This is required for > all armv4 and armv5 platforms, but isn't in most of our stock config > files right now. I have patches in my tree that fix that, btw. Warner From owner-freebsd-arm@FreeBSD.ORG Thu May 2 21:56:29 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ECF18829; Thu, 2 May 2013 21:56:29 +0000 (UTC) (envelope-from awg@embtoolkit.org) Received: from duppyconqueror.embtoolkit.org (duppyconqueror.embtoolkit.org [188.165.227.169]) by mx1.freebsd.org (Postfix) with ESMTP id 872EE1744; Thu, 2 May 2013 21:56:29 +0000 (UTC) Received: from [192.168.1.100] (nogent.walsimou.com [82.67.240.252]) (AUTH: PLAIN awg@embtoolkit.org) by duppyconqueror.embtoolkit.org with ESMTPA; Thu, 02 May 2013 23:55:59 +0200 id 0298FAB3.000000005182E0EF.00003BF5 Message-ID: <5182E0FD.80300@embtoolkit.org> Date: Thu, 02 May 2013 23:56:13 +0200 From: Abdoulaye Walsimou Gaye User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ian Lepore Subject: Re: vm fault on OpenRD [was: Re: Allwinner A13: Fatal kernel mode data abort: 'Translation Fault (S)'] References: <63837.85.229.93.125.1367417396.squirrel@alvermark.net> <5181AC1A.2020400@embtoolkit.org> <1367508111.1180.112.camel@revolution.hippie.lan> In-Reply-To: <1367508111.1180.112.camel@revolution.hippie.lan> 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 21:56:30 -0000 On 05/02/2013 05:21 PM, Ian Lepore wrote: [....] > ehci0: mem 0xf1050000-0xf1050fff irq 48,19 on simplebus0 > usbus0: EHCI version 1.0 > usbus0: stop timeout > usbus0: set host controller mode > > vm_fault(0xc0cc6674, 0, 1, 0) -> 1 > Fatal kernel mode data abort: 'Translation Fault (S)' > trapframe: 0xc0cfab68 > FSR=00000005, FAR=00000010, spsr=200000d3 > r0 =c36605c0, r1 =c0cc6390, r2 =600000d3, r3 =00000000 > r4 =c0a4e65c, r5 =80000003, r6 =c36640d0, r7 =c0c12278 > r8 =ffffffff, r9 =c350f280, r10=c3664080, r11=c0cfabf0 > r12=c0cc8aa0, ssp=c0cfabb4, slr=c0c26698, pc =c0a50964 > > [ thread pid 0 tid 100000 ] > Stopped at > While the error messages are similar, it appears that the cause is > completely different. Ian, Yes I realized that, sorry for the original thread hijack! > Given that it appears to have crashed while > initializing USB, I can think of two things to try... > > Add USB_HOST_ALIGN=32 to your kernel config file. This is required for > all armv4 and armv5 platforms, but isn't in most of our stock config > files right now. Making only this change on my KERNCONF file leads to kernel hang on, 'usbus0: set host controller mode', see here: miibus0: on mge0 e1000phy0: PHY 8 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto uart0: <16550 or compatible> mem 0xf1012000-0xf101201f irq 33 on simplebus0 uart0: console (1056,n,8,1) uart1: <16550 or compatible> mem 0xf1012100-0xf101211f irq 34 on simplebus0 cesa0: mem 0xf1030000-0xf103ffff irq 22 on simplebus0 ehci0: mem 0xf1050000-0xf1050fff irq 48,19 on simplebus0 usbus0: EHCI version 1.0 usbus0: stop timeout usbus0: set host controller mode > Also, try the attached patch. It avoids unconditionally enabling the > cache "allocate on write" feature in the hardware, and instead leaves it > in whatever state the bootloader set it to (on the assumption that the > vendor-supplied bootloader knows best about when this feature is > problematic; I think it may depend somewhat on how the board is > designed). > Applying only your patch still leads to vm fault, see here: ehci0: mem 0xf1050000-0xf1050fff irq 48,19 on simplebus0 usbus0: EHCI version 1.0 usbus0: stop timeout usbus0: set host controller mode vm_fault(0xc0cbe934, ff0000, 1, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xc0cf2b5c FSR=00000005, FAR=00ff0000, spsr=200000d3 r0 =00000000, r1 =00000000, r2 =00000000, r3 =00000000 r4 =c34f0260, r5 =c365c080, r6 =00000000, r7 =00000001 r8 =c355ca80, r9 =00000000, r10=00000000, r11=c0cf2bd4 r12=00ff0000, ssp=c0cf2ba8, slr=c0c96acc, pc =c0a4b0c4 Making the two changes (KERNCONF USB_HOST_ALIGN=32 and your patch) lead also to the same vm fault as above. The board's bootloader is a mainline u-boot, see here: Marvell>> version U-Boot 2013.04-00008-g500bccf (Apr 27 2013 - 01:08:22) OpenRD-Base armel-unknown-linux-gnueabi-gcc (embtoolkit-00143-g3687f38) 4.7.4 20130411 (prerelease) GNU ld (GNU Binutils) 2.23.2 Note that you are right, it is USB initialization the issue. If I completely disable USB, the kernel boots correctly and tries to mount nfs root filesystem. I will try to figure out what's going on, any suggestions are welcome. Thanks, AWG From owner-freebsd-arm@FreeBSD.ORG Fri May 3 06:33:12 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3C833D4E for ; Fri, 3 May 2013 06:33:12 +0000 (UTC) (envelope-from werner@thieprojects.ch) Received: from newton.metanet.ch (newton2.metanet.ch [80.74.158.131]) by mx1.freebsd.org (Postfix) with ESMTP id 8C2AE183C for ; Fri, 3 May 2013 06:33:10 +0000 (UTC) Received: (qmail 24038 invoked from network); 3 May 2013 08:26:28 +0200 Received: from 217-071-083-008.ip-tech.ch (HELO ?192.168.11.88?) (217.71.83.8) by newton.metanet.ch with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 3 May 2013 08:26:28 +0200 Message-ID: <51835891.4050409@thieprojects.ch> Date: Fri, 03 May 2013 08:26:25 +0200 From: Werner Thie User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Is this related to the general panic discussed in freebsd-current? 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 06:33:12 -0000 Hi all just came around yesterday to start playing with crochet, built an image and KDB entering panic when booting FreeBSD 10.0-CURRENT #0 r250144M: Thu May 2 10:10:20 CEST 2013 root@xtools:/usr/home/wthie/proj/crochet-freebsd/work/obj/arm.armv6/usr/local/src/sys/BEAGLEBONE arm FreeBSD clang version 3.3 (trunk 178860) 20130405 WARNING: WITNESS option enabled, expect reduced performance. panic: acquiring blockable sleep lock with spinlock or critical section held (rw) pmap pv global @ /usr/local/src/sys/arm/arm/pmap-v6.c:1187 KDB: enter: panic [ thread pid 0 tid 0 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! Main system up to date: FreeBSD xtools 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #0: Mon Apr 29 18:11:52 UTC 2013 crochet out of git, config with board_setup BeagleBone AutoSize=1 SwapFile=768mb What am I missing? Mahalo, Werner From owner-freebsd-arm@FreeBSD.ORG Fri May 3 11:12:07 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C7339A2B; Fri, 3 May 2013 11:12:07 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from lon1-post-3.mail.demon.net (lon1-post-3.mail.demon.net [195.173.77.150]) by mx1.freebsd.org (Postfix) with ESMTP id 96D0217B4; Fri, 3 May 2013 11:12:07 +0000 (UTC) Received: from bostonbath-adsl.demon.co.uk ([80.176.134.48] helo=bender) by lon1-post-3.mail.demon.net with esmtp (Exim 4.69) id 1UYDaX-0002Cv-ea; Fri, 03 May 2013 10:51:49 +0000 Date: Fri, 3 May 2013 11:51:41 +0100 From: Andrew Turner To: Ian Lepore Subject: Re: A fix for the clang + eabi + kdb backtrace endless loop Message-ID: <20130503115141.6c9cd15a@bender> In-Reply-To: <1367439452.1180.92.camel@revolution.hippie.lan> References: <1367439452.1180.92.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 11:12:07 -0000 On Wed, 01 May 2013 14:17:32 -0600 Ian Lepore wrote: > The attached patch fixes the problem where a kdb backtrace loops > endlessly on an eabi kernel. > > I'm no expert on this stuff, so while this fixes the problem for me, > I'm not sure it's right, especially the STOP_UNWINDING in > exception_exit (which handles a test case of breaking into the > debugger with the keyboard and typing 'bt'). I'm not going to commit > this until it's been reviewed by someone who actually knows what > they're doing. :) STOP_UNWINDING tells binutils to generate the required unwind op-code to tell the kernel's unwinder it needs to stop in this function. There is a bug with the unwinder where it should tell the user it is in the function, however it doesn't currently. See below for more comments. > Index: sys/arm/arm/db_trace.c > =================================================================== > --- sys/arm/arm/db_trace.c (revision 248960) > +++ sys/arm/arm/db_trace.c (working copy) > @@ -354,7 +354,7 @@ > index = db_find_index(state->start_pc); > > if (index->insn == EXIDX_CANTUNWIND) { > - db_printf("Unable to unwind\n"); > + db_printf("Unable to unwind further\n"); > break; > } else if (index->insn & (1 << 31)) { > /* The data is within the instruction */ > @@ -412,6 +412,23 @@ > } > } > db_printf("\n"); > + > + /* Stop if we've unwound back to the thread entry > point. */ > + if (state->registers[FP] == 0) { > + break; > + } This appears to be wrong, FP is not used with EABI, as such it is valid for it to be 0 at this point in the code. > + > + /* > + * Stop if the unwind function didn't change the PC, > to avoid > + * getting stuck in this loop forever. If this > happens, it's an > + * indication that the unwind information is > incorrect somehow > + * for the function named in the last frame printed > before you > + * see this message. > + */ > + if (state->start_pc == state->registers[PC]) { > + db_printf("Unwind failure (PC didn't > change)\n"); I'm not sure about this change, it may be hit in a recursive function. We should also check if sp changes. It is still possible to write code that defeats this check but this should be good enough (tm). Whether there should be recursive functions in the kernel is a different question. > + break; > + } > } > } > #endif > Index: sys/arm/arm/exception.S > =================================================================== > --- sys/arm/arm/exception.S (revision 248960) > +++ sys/arm/arm/exception.S (working copy) > @@ -196,15 +196,19 @@ > * Interrupts are disabled at suitable points to avoid ASTs > * being posted between testing and exit to user mode. > * > - * This function uses PULLFRAMEFROMSVCANDEXIT and > - * DO_AST > - * only be called if the exception handler used PUSHFRAMEINSVC > + * This function uses PULLFRAMEFROMSVCANDEXIT and DO_AST and can > + * only be called if the exception handler used PUSHFRAMEINSVC. > * > + * For EABI, don't try to unwind any further than this, because the > unwind > + * info generated here is a single INSN_FINISH instruction. Nothing > gets > + * unwound (no registers change) so the unwind would loop here > forever. > */ > > -exception_exit: > +ASENTRY_NP(exception_exit) > + STOP_UNWINDING > DO_AST > PULLFRAMEFROMSVCANDEXIT > +END(exception_exit) This looks good for now. We may be able to add the required unwind directives [1] to the PULLFRAMEFROMSVCANDEXIT macro at a later date. The directives will need to be handled in a similar way to STOP_UNWINDING as we should only add them in the EABI and debug case. Andrew [1] http://sourceware.org/binutils/docs/as/ARM-Directives.html From owner-freebsd-arm@FreeBSD.ORG Fri May 3 13:13:29 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 02A50AAD for ; Fri, 3 May 2013 13:13:29 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by mx1.freebsd.org (Postfix) with ESMTP id D22881FF3 for ; Fri, 3 May 2013 13:13:28 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id 3so911080pdj.41 for ; Fri, 03 May 2013 06:13:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=2ydqIiYg4AwSTnIYShiZnsyLoWFaMfFa8q7Zy+OYj2k=; b=FYGqh3k1rjylL9hYb4jjSPctsq2aOut/hpGy4xsLtjV8drqPQJiWEEWoH+vtWgxram PFP/OlKYXBo0FHjlY/NNWPjZcTd2tJYqTrd5x4RGwKZBCnsBIuInMIoupgsZwOQ20cPj 7kOu13/1X4jJZdf5pvgi0r/O3A+3VniSUuJDNL8ovgZsF7G3TDSrZFzZ1SwO+Z7LdMmp cqPdd/K8LCgpXlSXD4vEBo+09k1i6qmvIzi1TX9pKOxRHbuvQ87k0P1s/ymieVjWVf0V BJK69vQHjJa4I8sod2j+fE3LIqqUiRiipNpnA+nqJYWb4BdBcWYouGXSBZT3ezOoWCns Af+Q== X-Received: by 10.66.5.133 with SMTP id s5mr14638300pas.43.1367586802505; Fri, 03 May 2013 06:13:22 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ag4sm11640652pbc.20.2013.05.03.06.13.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 May 2013 06:13:20 -0700 (PDT) Sender: Warner Losh Subject: Re: Is this related to the general panic discussed in freebsd-current? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <51835891.4050409@thieprojects.ch> Date: Fri, 3 May 2013 07:13:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <03971BD1-4ADE-4435-BDD0-B94B62634F1D@bsdimp.com> References: <51835891.4050409@thieprojects.ch> To: Werner Thie X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkULH9KJV1wPwqs7jEAWCCZty25gyOBrZSbhzvB8XxlkTnnDbpbzvep25s3euNG8aPqqpKU Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 13:13:29 -0000 On May 3, 2013, at 12:26 AM, Werner Thie wrote: > Hi all >=20 > just came around yesterday to start playing with crochet, built an = image and KDB entering panic when booting >=20 > FreeBSD 10.0-CURRENT #0 r250144M: Thu May 2 10:10:20 CEST 2013 > = root@xtools:/usr/home/wthie/proj/crochet-freebsd/work/obj/arm.armv6/usr/lo= cal/src/sys/BEAGLEBONE arm > FreeBSD clang version 3.3 (trunk 178860) 20130405 > WARNING: WITNESS option enabled, expect reduced performance. > panic: acquiring blockable sleep lock with spinlock or critical = section held (rw) pmap pv global @ = /usr/local/src/sys/arm/arm/pmap-v6.c:1187 > KDB: enter: panic > [ thread pid 0 tid 0 ] > Stopped at $d: ldrb r15, [r15, r15, ror r15]! This looks like the clang-built witness panic that's in arm. Warner >=20 > Main system up to date: > FreeBSD xtools 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #0: Mon Apr 29 = 18:11:52 UTC 2013 >=20 > crochet out of git, config with >=20 > board_setup BeagleBone > AutoSize=3D1 > SwapFile=3D768mb >=20 > What am I missing? >=20 > Mahalo, Werner > _______________________________________________ > 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 May 3 13:45:55 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 44B8977F for ; Fri, 3 May 2013 13:45:55 +0000 (UTC) (envelope-from werner@thieprojects.ch) Received: from newton.metanet.ch (newton2.metanet.ch [80.74.158.131]) by mx1.freebsd.org (Postfix) with ESMTP id 91EA9116D for ; Fri, 3 May 2013 13:45:53 +0000 (UTC) Received: (qmail 32321 invoked from network); 3 May 2013 15:45:52 +0200 Received: from 217-071-083-008.ip-tech.ch (HELO ?192.168.11.88?) (217.71.83.8) by newton.metanet.ch with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 3 May 2013 15:45:52 +0200 Message-ID: <5183BF8C.4040406@thieprojects.ch> Date: Fri, 03 May 2013 15:45:48 +0200 From: Werner Thie User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Warner Losh Subject: Re: Is this related to the general panic discussed in freebsd-current? References: <51835891.4050409@thieprojects.ch> <03971BD1-4ADE-4435-BDD0-B94B62634F1D@bsdimp.com> In-Reply-To: <03971BD1-4ADE-4435-BDD0-B94B62634F1D@bsdimp.com> 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 13:45:55 -0000 On 5/3/13 3:13 PM, Warner Losh wrote: > On May 3, 2013, at 12:26 AM, Werner Thie wrote: > >> Hi all >> >> just came around yesterday to start playing with crochet, built an image and KDB entering panic when booting >> >> FreeBSD 10.0-CURRENT #0 r250144M: Thu May 2 10:10:20 CEST 2013 >> root@xtools:/usr/home/wthie/proj/crochet-freebsd/work/obj/arm.armv6/usr/local/src/sys/BEAGLEBONE arm >> FreeBSD clang version 3.3 (trunk 178860) 20130405 >> WARNING: WITNESS option enabled, expect reduced performance. >> panic: acquiring blockable sleep lock with spinlock or critical section held (rw) pmap pv global @ /usr/local/src/sys/arm/arm/pmap-v6.c:1187 >> KDB: enter: panic >> [ thread pid 0 tid 0 ] >> Stopped at $d: ldrb r15, [r15, r15, ror r15]! > > This looks like the clang-built witness panic that's in arm. Thxs, Werner From owner-freebsd-arm@FreeBSD.ORG Sat May 4 15:08:25 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BBADC46D for ; Sat, 4 May 2013 15:08:25 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id 945A21ECE for ; Sat, 4 May 2013 15:08:25 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UYe4W-0003EY-Gv; Sat, 04 May 2013 15:08:24 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r44F8Jx1012111; Sat, 4 May 2013 09:08:20 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+mxz+XtdzYhV+3w07xi26G Subject: Re: A fix for the clang + eabi + kdb backtrace endless loop From: Ian Lepore To: Andrew Turner In-Reply-To: <20130503115141.6c9cd15a@bender> References: <1367439452.1180.92.camel@revolution.hippie.lan> <20130503115141.6c9cd15a@bender> Content-Type: multipart/mixed; boundary="=-ln0HrZPFdHK2Vh66Xe3w" Date: Sat, 04 May 2013 09:08:19 -0600 Message-ID: <1367680099.1180.162.camel@revolution.hippie.lan> 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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 15:08:25 -0000 --=-ln0HrZPFdHK2Vh66Xe3w Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, 2013-05-03 at 11:51 +0100, Andrew Turner wrote: > On Wed, 01 May 2013 14:17:32 -0600 > Ian Lepore wrote: > > > The attached patch fixes the problem where a kdb backtrace loops > > endlessly on an eabi kernel. > > > > I'm no expert on this stuff, so while this fixes the problem for me, > > I'm not sure it's right, especially the STOP_UNWINDING in > > exception_exit (which handles a test case of breaking into the > > debugger with the keyboard and typing 'bt'). I'm not going to commit > > this until it's been reviewed by someone who actually knows what > > they're doing. :) > STOP_UNWINDING tells binutils to generate the required unwind op-code > to tell the kernel's unwinder it needs to stop in this function. There > is a bug with the unwinder where it should tell the user it is in the > function, however it doesn't currently. > > See below for more comments. Thanks for the review and info. I didn't realize FP was unused in EABI. I guess keying off it just accidentally worked right in the few cases I tested. I was also a bit worried about the recursion case with using the PC to see if unwinding seemed to be stuck. I studied the code some more and discovered that there's a mask of which registers changed, used for pretty-printing. I think that's a safer way to determine whether unwinding is stuck in a loop -- if no registers changed then nothing was unwound. I also restructured things a bit so that the decision to stop unwinding isn't acted on until after the current frame is printed; that seems to ensure that the frame for a STOP_UNWINDING function gets printed before exiting the loop. So, here's a somewhat more clueful patch; how's this look? -- Ian --=-ln0HrZPFdHK2Vh66Xe3w Content-Disposition: inline; filename="eabi_unwind_fixes2.diff" Content-Type: text/x-patch; name="eabi_unwind_fixes2.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/arm/arm/db_trace.c =================================================================== --- sys/arm/arm/db_trace.c (revision 250163) +++ sys/arm/arm/db_trace.c (working copy) @@ -342,8 +342,11 @@ db_stack_trace_cmd(struct unwind_state *state) c_db_sym_t sym; u_int reg, i; char *sep; + uint16_t upd_mask; + bool finished; - while (1) { + finished = false; + while (!finished) { /* Reset the mask of updated registers */ state->update_mask = 0; @@ -353,28 +356,20 @@ db_stack_trace_cmd(struct unwind_state *state) /* Find the item to run */ index = db_find_index(state->start_pc); - if (index->insn == EXIDX_CANTUNWIND) { - db_printf("Unable to unwind\n"); - break; - } else if (index->insn & (1 << 31)) { - /* The data is within the instruction */ - state->insn = &index->insn; - } else { - /* We have a prel31 offset to the unwind table */ - uint32_t prel31_tbl = db_expand_prel31(index->insn); - - state->insn = (uint32_t *)((uintptr_t)&index->insn + - prel31_tbl); + if (index->insn != EXIDX_CANTUNWIND) { + if (index->insn & (1 << 31)) { + /* The data is within the instruction */ + state->insn = &index->insn; + } else { + /* A prel31 offset to the unwind table */ + state->insn = (uint32_t *) + ((uintptr_t)&index->insn + + db_expand_prel31(index->insn)); + } + /* Run the unwind function */ + finished = db_unwind_tab(state); } - /* Run the unwind function */ - if (db_unwind_tab(state) != 0) - break; - - /* This is not a kernel address, stop processing */ - if (state->registers[PC] < VM_MIN_KERNEL_ADDRESS) - break; - /* Print the frame details */ sym = db_search_symbol(state->start_pc, DB_STGY_ANY, &offset); if (sym == C_DB_SYM_NULL) { @@ -393,12 +388,11 @@ db_stack_trace_cmd(struct unwind_state *state) state->registers[SP], state->registers[FP]); /* Don't print the registers we have already printed */ - state->update_mask &= ~((1 << SP) | (1 << FP) | (1 << LR) | - (1 << PC)); + upd_mask = state->update_mask & + ~((1 << SP) | (1 << FP) | (1 << LR) | (1 << PC)); sep = "\n\t"; - for (i = 0, reg = 0; state->update_mask != 0; - state->update_mask >>= 1, reg++) { - if ((state->update_mask & 1) != 0) { + for (i = 0, reg = 0; upd_mask != 0; upd_mask >>= 1, reg++) { + if ((upd_mask & 1) != 0) { db_printf("%s%sr%d = 0x%08x", sep, (reg < 10) ? " " : "", reg, state->registers[reg]); @@ -412,6 +406,25 @@ db_stack_trace_cmd(struct unwind_state *state) } } db_printf("\n"); + + /* Stop if directed to do so, or if we've unwound back to the + * kernel entry point, or if the unwind function didn't change + * anything (to avoid getting stuck in this loop forever). + * If the latter happens, it's an indication that the unwind + * information is incorrect somehow for the function named in + * the last frame printed before you see the unwind failure + * message (maybe it needs a STOP_UNWINDING). + */ + if (index->insn == EXIDX_CANTUNWIND) { + db_printf("Unable to unwind further\n"); + finished = true; + } else if (state->registers[PC] < VM_MIN_KERNEL_ADDRESS) { + db_printf("Unable to unwind into user mode\n"); + finished = true; + } else if (state->update_mask == 0) { + db_printf("Unwind failure (no registers changed)\n"); + finished = true; + } } } #endif Index: sys/arm/arm/exception.S =================================================================== --- sys/arm/arm/exception.S (revision 250163) +++ sys/arm/arm/exception.S (working copy) @@ -196,15 +196,19 @@ END(address_exception_entry) * Interrupts are disabled at suitable points to avoid ASTs * being posted between testing and exit to user mode. * - * This function uses PULLFRAMEFROMSVCANDEXIT and - * DO_AST - * only be called if the exception handler used PUSHFRAMEINSVC + * This function uses PULLFRAMEFROMSVCANDEXIT and DO_AST and can + * only be called if the exception handler used PUSHFRAMEINSVC. * + * For EABI, don't try to unwind any further than this, because the unwind + * info generated here is a single INSN_FINISH instruction. Nothing gets + * unwound (no registers change) so the unwind would loop here forever. */ -exception_exit: +ASENTRY_NP(exception_exit) + STOP_UNWINDING DO_AST PULLFRAMEFROMSVCANDEXIT +END(exception_exit) /* * undefined_entry: Index: sys/arm/arm/locore.S =================================================================== --- sys/arm/arm/locore.S (revision 250163) +++ sys/arm/arm/locore.S (working copy) @@ -77,6 +77,8 @@ __FBSDID("$FreeBSD$"); */ ENTRY_NP(btext) ASENTRY_NP(_start) + STOP_UNWINDING /* Can't unwind into the bootloader! */ + mov r9, r0 /* 0 or boot mode from boot2 */ mov r8, r1 /* Save Machine type */ mov ip, r2 /* Save meta data */ Index: sys/arm/arm/swtch.S =================================================================== --- sys/arm/arm/swtch.S (revision 250163) +++ sys/arm/arm/swtch.S (working copy) @@ -540,6 +540,7 @@ ENTRY(savectx) END(savectx) ENTRY(fork_trampoline) + STOP_UNWINDING /* Can't unwind beyond the thread enty point */ mov r1, r5 mov r2, sp mov r0, r4 --=-ln0HrZPFdHK2Vh66Xe3w-- From owner-freebsd-arm@FreeBSD.ORG Sat May 4 16:17:17 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0F2352D4; Sat, 4 May 2013 16:17:17 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id E936B264; Sat, 4 May 2013 16:17:16 +0000 (UTC) Received: from bender (cpc24-aztw24-2-0-cust99.18-1.cable.virginmedia.com [92.237.65.100]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 7962E5E1F5; Sat, 4 May 2013 16:17:15 +0000 (UTC) Date: Sat, 4 May 2013 17:17:13 +0100 From: Andrew Turner To: Ian Lepore Subject: Re: A fix for the clang + eabi + kdb backtrace endless loop Message-ID: <20130504171713.1ae33892@bender> In-Reply-To: <1367680099.1180.162.camel@revolution.hippie.lan> References: <1367439452.1180.92.camel@revolution.hippie.lan> <20130503115141.6c9cd15a@bender> <1367680099.1180.162.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 16:17:17 -0000 On Sat, 04 May 2013 09:08:19 -0600 Ian Lepore wrote: > On Fri, 2013-05-03 at 11:51 +0100, Andrew Turner wrote: > > On Wed, 01 May 2013 14:17:32 -0600 > > Ian Lepore wrote: > > > > > The attached patch fixes the problem where a kdb backtrace loops > > > endlessly on an eabi kernel. > > > > > > I'm no expert on this stuff, so while this fixes the problem for > > > me, I'm not sure it's right, especially the STOP_UNWINDING in > > > exception_exit (which handles a test case of breaking into the > > > debugger with the keyboard and typing 'bt'). I'm not going to > > > commit this until it's been reviewed by someone who actually > > > knows what they're doing. :) > > STOP_UNWINDING tells binutils to generate the required unwind > > op-code to tell the kernel's unwinder it needs to stop in this > > function. There is a bug with the unwinder where it should tell the > > user it is in the function, however it doesn't currently. > > > > See below for more comments. > > Thanks for the review and info. I didn't realize FP was unused in > EABI. I guess keying off it just accidentally worked right in the few > cases I tested. > > I was also a bit worried about the recursion case with using the PC to > see if unwinding seemed to be stuck. I studied the code some more and > discovered that there's a mask of which registers changed, used for > pretty-printing. I think that's a safer way to determine whether > unwinding is stuck in a loop -- if no registers changed then nothing > was unwound. > > I also restructured things a bit so that the decision to stop > unwinding isn't acted on until after the current frame is printed; > that seems to ensure that the frame for a STOP_UNWINDING function > gets printed before exiting the loop. > > So, here's a somewhat more clueful patch; how's this look? > > -- Ian > The updated db_trace.c looks good, however I am currently unable to test the change. In exception.S you added the following comment: For EABI, don't try to unwind any further than this, because the unwind info generated here is a single INSN_FINISH instruction. Nothing gets unwound (no registers change) so the unwind would loop here forever. It's not quite correct. Registers are loaded in PULLFRAMEFROMSVCANDEXIT however we don't yet record this fact in the macro. I would suggest something like: For EABI, don't try to unwind any further than this, because the unwind info generated here is a single INSN_FINISH instruction. This is because, while PULLFRAMEFROMSVCANDEXIT modifies registers, we don't store these changes in the unwind table. Any other asm functions that shouldn't be unwound past can have STOP_UNWINDING added to them. For other ASM functions we need to start telling the unwinder about the register changes, allowing this is on my TODO list but I haven't had a chance to look into it yet. Andrew From owner-freebsd-arm@FreeBSD.ORG Sat May 4 16:24:39 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 66F7037D for ; Sat, 4 May 2013 16:24:39 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 317DA29F for ; Sat, 4 May 2013 16:24:38 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r44GOVIX019926; Sat, 4 May 2013 16:24:31 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id mhcj2qsn64m3d6q3q3kq4izr86; Sat, 04 May 2013 16:24:31 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Crochet Configuration Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <51835891.4050409@thieprojects.ch> Date: Sat, 4 May 2013 09:25:15 -0700 Content-Transfer-Encoding: 7bit Message-Id: <9FD9AABD-BB9B-4C3A-A49C-7CA0EEFE94AA@freebsd.org> References: <51835891.4050409@thieprojects.ch> To: Werner Thie X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 16:24:39 -0000 On May 2, 2013, at 11:26 PM, Werner Thie wrote: > crochet out of git, config with > > board_setup BeagleBone > AutoSize=1 > SwapFile=768mb FYI: This configuration won't quite do what you want. It should be: board_setup BeagleBone option AutoSize option SwapFile 768mb From owner-freebsd-arm@FreeBSD.ORG Sat May 4 17:30:20 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DBEA880C for ; Sat, 4 May 2013 17:30:20 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 892F67A5 for ; Sat, 4 May 2013 17:30:19 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 2B5A3D6C57 for ; Sat, 4 May 2013 19:30:12 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id TmF+ZtXsag13 for ; Sat, 4 May 2013 19:30:09 +0200 (CEST) Received: from [10.0.2.117] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 4BDC6D6B02 for ; Sat, 4 May 2013 19:30:09 +0200 (CEST) Message-ID: <518545A0.5020107@semihalf.com> Date: Sat, 04 May 2013 19:30:08 +0200 From: Zbyszek Bodek User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: New PV entry allocator for pmap-v6.c Content-Type: multipart/mixed; boundary="------------050801050308040305030206" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 17:30:20 -0000 This is a multi-part message in MIME format. --------------050801050308040305030206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello everyone, As a part of Semihalf work on Superpages support, we've made some pmap-v6.c improvements and clean-ups. We would like to start integrating our code to the mainline FreeBSD, therefore I'm happy to introduce the new PV entry allocator for pmap-v6.c ported from amd64/i386/mips. Alan Cox (alc) was so kind to review the code. If there are no objections, then we will commit this patch to the HEAD around Monday/Tuesday. Please check out the attachment for details. Best regards Zbyszek Bodek --------------050801050308040305030206 Content-Type: text/x-patch; name="0001-arm-Port-the-new-PV-entry-allocator-from-amd64-i386-.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-arm-Port-the-new-PV-entry-allocator-from-amd64-i386-.pa"; filename*1="tch" >From 07864f1ee68a911a9d011d99f98b052f106bba56 Mon Sep 17 00:00:00 2001 From: Zbigniew Bodek Date: Fri, 29 Mar 2013 16:16:26 +0100 Subject: [PATCH] arm: Port the new PV entry allocator from amd64/i386/mips PV entries are now roughly half the size. Instead of using a shared UMA zone for 28 byte pv entries (two 8-byte tailq nodes, a 4 byte pointer, a 4 byte address and 4 byte flags), we allocate a page at a time per process. This provides 252 pv entries per process (actually, per pmap address space) and eliminates one of the 8-byte tailq entries since we now can track per-process pv entries implicitly. The pointer to the pmap can be eliminated by doing address arithmetic to find the metadata on the page headers to find a single pointer shared by all 252 entries. There is an 8-int bitmap for the freelist of those 252 entries. When in serious low memory condition, allocation of another pv_chunk is possible by freeing some pages in pmap_pv_reclaim(). Added pv_entry/pv_chunk related statistics to pmap. pv_entry/pv_chunk statistics can be accessed via sysctl vm.pmap. Ported PTE freelist of KVA allocation and maintenance from i386. Using an idea from Stephan Uphoff, use the empty pte's that correspond to the unused kva in the pv memory block to thread a freelist through. This allows us to free pages that used to be used for pv entry chunks since we can now track holes in the kva memory block. As both ARM pmap.c and pmap-v6.c use the same header and pv_entry, pmap and md_page structures are different, it was needed to separate code designed for ARMv6/7 from the one for other ARMs. --- sys/arm/arm/pmap-v6.c | 522 +++++++++++++++++++++++++++++++++++++++++-------- sys/arm/include/pmap.h | 29 ++- sys/conf/options.arm | 1 + 3 files changed, 473 insertions(+), 79 deletions(-) diff --git a/sys/arm/arm/pmap-v6.c b/sys/arm/arm/pmap-v6.c index 9d16509..bdf243e 100644 --- a/sys/arm/arm/pmap-v6.c +++ b/sys/arm/arm/pmap-v6.c @@ -141,6 +141,7 @@ /* Include header files */ #include "opt_vm.h" +#include "opt_pmap.h" #include __FBSDID("$FreeBSD$"); @@ -158,6 +159,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include @@ -193,6 +195,12 @@ int pmap_debug_level = 0; #define PMAP_INLINE __inline #endif /* PMAP_DEBUG */ +#ifdef PV_STATS +#define PV_STAT(x) do { x ; } while (0) +#else +#define PV_STAT(x) do { } while (0) +#endif + #ifdef ARM_L2_PIPT #define pmap_l2cache_wbinv_range(va, pa, size) cpu_l2cache_wbinv_range((pa), (size)) #define pmap_l2cache_inv_range(va, pa, size) cpu_l2cache_inv_range((pa), (size)) @@ -206,8 +214,11 @@ extern struct pv_addr systempage; /* * Internal function prototypes */ -static void pmap_free_pv_entry (pv_entry_t); -static pv_entry_t pmap_get_pv_entry(void); + +static void pmap_free_pv_chunk(struct pv_chunk *pc); +static void pmap_free_pv_entry(pmap_t pmap, pv_entry_t pv); +static pv_entry_t pmap_get_pv_entry(pmap_t pmap, boolean_t try); +static vm_page_t pmap_pv_reclaim(pmap_t locked_pmap); static void pmap_enter_locked(pmap_t, vm_offset_t, vm_page_t, vm_prot_t, boolean_t, int); @@ -386,13 +397,73 @@ int pmap_needs_pte_sync; #define pmap_is_current(pm) ((pm) == pmap_kernel() || \ curproc->p_vmspace->vm_map.pmap == (pm)) -static uma_zone_t pvzone = NULL; + +/* + * Data for the pv entry allocation mechanism + */ +static TAILQ_HEAD(pch, pv_chunk) pv_chunks = TAILQ_HEAD_INITIALIZER(pv_chunks); +static int pv_entry_count, pv_entry_max, pv_entry_high_water; +static int shpgperproc = PMAP_SHPGPERPROC; + +struct pv_chunk *pv_chunkbase; /* KVA block for pv_chunks */ +int pv_maxchunks; /* How many chunks we have KVA for */ +vm_offset_t pv_vafree; /* Freelist stored in the PTE */ + +static __inline struct pv_chunk * +pv_to_chunk(pv_entry_t pv) +{ + + return ((struct pv_chunk *)((uintptr_t)pv & ~(uintptr_t)PAGE_MASK)); +} + +#define PV_PMAP(pv) (pv_to_chunk(pv)->pc_pmap) + +CTASSERT(sizeof(struct pv_chunk) == PAGE_SIZE); +CTASSERT(_NPCM == 8); +CTASSERT(_NPCPV == 252); + +#define PC_FREE0_6 0xfffffffful /* Free values for index 0 through 6 */ +#define PC_FREE7 0x0ffffffful /* Free values for index 7 */ + +static const uint32_t pc_freemask[_NPCM] = { + PC_FREE0_6, PC_FREE0_6, PC_FREE0_6, + PC_FREE0_6, PC_FREE0_6, PC_FREE0_6, + PC_FREE0_6, PC_FREE7 +}; + +static SYSCTL_NODE(_vm, OID_AUTO, pmap, CTLFLAG_RD, 0, "VM/pmap parameters"); + +SYSCTL_INT(_vm_pmap, OID_AUTO, pv_entry_count, CTLFLAG_RD, &pv_entry_count, 0, + "Current number of pv entries"); + +#ifdef PV_STATS +static int pc_chunk_count, pc_chunk_allocs, pc_chunk_frees, pc_chunk_tryfail; + +SYSCTL_INT(_vm_pmap, OID_AUTO, pc_chunk_count, CTLFLAG_RD, &pc_chunk_count, 0, + "Current number of pv entry chunks"); +SYSCTL_INT(_vm_pmap, OID_AUTO, pc_chunk_allocs, CTLFLAG_RD, &pc_chunk_allocs, 0, + "Current number of pv entry chunks allocated"); +SYSCTL_INT(_vm_pmap, OID_AUTO, pc_chunk_frees, CTLFLAG_RD, &pc_chunk_frees, 0, + "Current number of pv entry chunks frees"); +SYSCTL_INT(_vm_pmap, OID_AUTO, pc_chunk_tryfail, CTLFLAG_RD, &pc_chunk_tryfail, 0, + "Number of times tried to get a chunk page but failed."); + +static long pv_entry_frees, pv_entry_allocs; +static int pv_entry_spare; + +SYSCTL_LONG(_vm_pmap, OID_AUTO, pv_entry_frees, CTLFLAG_RD, &pv_entry_frees, 0, + "Current number of pv entry frees"); +SYSCTL_LONG(_vm_pmap, OID_AUTO, pv_entry_allocs, CTLFLAG_RD, &pv_entry_allocs, 0, + "Current number of pv entry allocs"); +SYSCTL_INT(_vm_pmap, OID_AUTO, pv_entry_spare, CTLFLAG_RD, &pv_entry_spare, 0, + "Current number of spare pv entries"); +#endif + uma_zone_t l2zone; static uma_zone_t l2table_zone; static vm_offset_t pmap_kernel_l2dtable_kva; static vm_offset_t pmap_kernel_l2ptp_kva; static vm_paddr_t pmap_kernel_l2ptp_phys; -static int pv_entry_count=0, pv_entry_max=0, pv_entry_high_water=0; static struct rwlock pvh_global_lock; int l1_mem_types[] = { @@ -846,7 +917,7 @@ pmap_clearbit(struct vm_page *pg, u_int maskbits) */ TAILQ_FOREACH(pv, &pg->md.pv_list, pv_list) { va = pv->pv_va; - pm = pv->pv_pmap; + pm = PV_PMAP(pv); oflags = pv->pv_flags; pv->pv_flags &= ~maskbits; @@ -923,12 +994,10 @@ pmap_enter_pv(struct vm_page *pg, struct pv_entry *pve, pmap_t pm, rw_assert(&pvh_global_lock, RA_WLOCKED); PMAP_ASSERT_LOCKED(pm); - pve->pv_pmap = pm; pve->pv_va = va; pve->pv_flags = flags; TAILQ_INSERT_HEAD(&pg->md.pv_list, pve, pv_list); - TAILQ_INSERT_HEAD(&pm->pm_pvlist, pve, pv_plist); pg->md.pvh_attrs |= flags & (PVF_REF | PVF_MOD); if (pve->pv_flags & PVF_WIRED) ++pm->pm_stats.wired_count; @@ -948,7 +1017,7 @@ pmap_find_pv(struct vm_page *pg, pmap_t pm, vm_offset_t va) rw_assert(&pvh_global_lock, RA_WLOCKED); TAILQ_FOREACH(pv, &pg->md.pv_list, pv_list) - if (pm == pv->pv_pmap && va == pv->pv_va) + if (pm == PV_PMAP(pv) && va == pv->pv_va) break; return (pv); } @@ -1011,7 +1080,6 @@ pmap_nuke_pv(struct vm_page *pg, pmap_t pm, struct pv_entry *pve) PMAP_ASSERT_LOCKED(pm); TAILQ_REMOVE(&pg->md.pv_list, pve, pv_list); - TAILQ_REMOVE(&pm->pm_pvlist, pve, pv_plist); if (pve->pv_flags & PVF_WIRED) --pm->pm_stats.wired_count; @@ -1044,7 +1112,7 @@ pmap_remove_pv(struct vm_page *pg, pmap_t pm, vm_offset_t va) pve = TAILQ_FIRST(&pg->md.pv_list); while (pve) { - if (pve->pv_pmap == pm && pve->pv_va == va) { /* match? */ + if (PV_PMAP(pve) == pm && pve->pv_va == va) { /* match? */ pmap_nuke_pv(pg, pm, pve); break; } @@ -1139,6 +1207,48 @@ pmap_page_init(vm_page_t m) m->md.pv_memattr = VM_MEMATTR_DEFAULT; } +static vm_offset_t +pmap_ptelist_alloc(vm_offset_t *head) +{ + pt_entry_t *pte; + vm_offset_t va; + + va = *head; + if (va == 0) + return (va); /* Out of memory */ + pte = vtopte(va); + *head = *pte; + if ((*head & L2_TYPE_MASK) != L2_TYPE_INV) + panic("%s: va is not L2_TYPE_INV!", __func__); + *pte = 0; + return (va); +} + +static void +pmap_ptelist_free(vm_offset_t *head, vm_offset_t va) +{ + pt_entry_t *pte; + + if ((va & L2_TYPE_MASK) != L2_TYPE_INV) + panic("%s: freeing va that is not L2_TYPE INV!", __func__); + pte = vtopte(va); + *pte = *head; /* virtual! L2_TYPE is L2_TYPE_INV though */ + *head = va; +} + +static void +pmap_ptelist_init(vm_offset_t *head, void *base, int npages) +{ + int i; + vm_offset_t va; + + *head = 0; + for (i = npages - 1; i >= 0; i--) { + va = (vm_offset_t)base + i * PAGE_SIZE; + pmap_ptelist_free(head, va); + } +} + /* * Initialize the pmap module. * Called by vm_init, to initialize any structures that the pmap @@ -1147,7 +1257,6 @@ pmap_page_init(vm_page_t m) void pmap_init(void) { - int shpgperproc = PMAP_SHPGPERPROC; PDEBUG(1, printf("pmap_init: phys_start = %08x\n", PHYSADDR)); @@ -1157,21 +1266,35 @@ pmap_init(void) NULL, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_VM | UMA_ZONE_NOFREE); /* - * Initialize the PV entry allocator. + * Initialize the address space for the pv chunks. */ - pvzone = uma_zcreate("PV ENTRY", sizeof (struct pv_entry), NULL, NULL, - NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_VM | UMA_ZONE_NOFREE); + TUNABLE_INT_FETCH("vm.pmap.shpgperproc", &shpgperproc); pv_entry_max = shpgperproc * maxproc + cnt.v_page_count; - uma_zone_reserve_kva(pvzone, pv_entry_max); + TUNABLE_INT_FETCH("vm.pmap.pv_entries", &pv_entry_max); + pv_entry_max = roundup(pv_entry_max, _NPCPV); pv_entry_high_water = 9 * (pv_entry_max / 10); + pv_maxchunks = MAX(pv_entry_max / _NPCPV, maxproc); + pv_chunkbase = (struct pv_chunk *)kmem_alloc_nofault(kernel_map, + PAGE_SIZE * pv_maxchunks); + + if (pv_chunkbase == NULL) + panic("pmap_init: not enough kvm for pv chunks"); + + pmap_ptelist_init(&pv_vafree, pv_chunkbase, pv_maxchunks); + /* * Now it is safe to enable pv_table recording. */ PDEBUG(1, printf("pmap_init: done!\n")); } +SYSCTL_INT(_vm_pmap, OID_AUTO, pv_entry_max, CTLFLAG_RD, &pv_entry_max, 0, + "Max number of PV entries"); +SYSCTL_INT(_vm_pmap, OID_AUTO, shpgperproc, CTLFLAG_RD, &shpgperproc, 0, + "Page share factor per proc"); + int pmap_fault_fixup(pmap_t pm, vm_offset_t va, vm_prot_t ftype, int user) { @@ -1653,7 +1776,7 @@ pmap_bootstrap(vm_offset_t firstaddr, struct pv_addr *l1pt) PMAP_LOCK_INIT(kernel_pmap); CPU_FILL(&kernel_pmap->pm_active); kernel_pmap->pm_domain = PMAP_DOMAIN_KERNEL; - TAILQ_INIT(&kernel_pmap->pm_pvlist); + TAILQ_INIT(&kernel_pmap->pm_pvchunk); /* * Initialize the global pv list lock. @@ -1921,38 +2044,61 @@ pmap_growkernel(vm_offset_t addr) void pmap_remove_pages(pmap_t pmap) { - struct pv_entry *pv, *npv; - struct l2_bucket *l2b = NULL; - vm_page_t m; - pt_entry_t *pt; - - rw_wlock(&pvh_global_lock); - PMAP_LOCK(pmap); - for (pv = TAILQ_FIRST(&pmap->pm_pvlist); pv; pv = npv) { - if (pv->pv_flags & PVF_WIRED) { - /* Cannot remove wired pages now. */ - npv = TAILQ_NEXT(pv, pv_plist); - continue; + struct pv_entry *pv; + struct l2_bucket *l2b = NULL; + vm_page_t m; + pt_entry_t *pt; + struct pv_chunk *pc, *npc; + uint32_t inuse, bitmask; + int allfree, bit, field, idx; + + rw_wlock(&pvh_global_lock); + PMAP_LOCK(pmap); + + TAILQ_FOREACH_SAFE(pc, &pmap->pm_pvchunk, pc_list, npc) { + allfree = 1; + for (field = 0; field < _NPCM; field++) { + inuse = ~pc->pc_map[field] & pc_freemask[field]; + while (inuse != 0) { + bit = ffs(inuse) - 1; + bitmask = 1ul << bit; + idx = field * sizeof(inuse) * NBBY + bit; + pv = &pc->pc_pventry[idx]; + inuse &= ~bitmask; + if (pv->pv_flags & PVF_WIRED) { + /* Cannot remove wired pages now. */ + allfree = 0; + continue; + } + l2b = pmap_get_l2_bucket(pmap, pv->pv_va); + KASSERT(l2b != NULL, ("No L2 bucket in pmap_remove_pages")); + pt = &l2b->l2b_kva[l2pte_index(pv->pv_va)]; + m = PHYS_TO_VM_PAGE(*pt & L2_ADDR_MASK); + KASSERT((vm_offset_t)m >= KERNBASE, ("Trying to access non-existent page va %x pte %x", pv->pv_va, *pt)); + *pt = 0; + PTE_SYNC(pt); + + /* Mark free */ + PV_STAT(pv_entry_frees++); + PV_STAT(pv_entry_spare++); + pv_entry_count--; + pmap->pm_stats.resident_count--; + pc->pc_map[field] |= bitmask; + pmap_nuke_pv(m, pmap, pv); + pmap_free_l2_bucket(pmap, l2b, 1); + } } - pmap->pm_stats.resident_count--; - l2b = pmap_get_l2_bucket(pmap, pv->pv_va); - KASSERT(l2b != NULL, ("No L2 bucket in pmap_remove_pages")); - pt = &l2b->l2b_kva[l2pte_index(pv->pv_va)]; - m = PHYS_TO_VM_PAGE(*pt & L2_ADDR_MASK); - KASSERT((vm_offset_t)m >= KERNBASE, ("Trying to access non-existent page va %x pte %x", pv->pv_va, *pt)); - *pt = 0; - PTE_SYNC(pt); - npv = TAILQ_NEXT(pv, pv_plist); - pmap_nuke_pv(m, pmap, pv); - if (TAILQ_EMPTY(&m->md.pv_list)) - vm_page_aflag_clear(m, PGA_WRITEABLE); - pmap_free_pv_entry(pv); - pmap_free_l2_bucket(pmap, l2b, 1); + if (allfree) { + TAILQ_REMOVE(&pmap->pm_pvchunk, pc, pc_list); + pmap_free_pv_chunk(pc); + } + } - rw_wunlock(&pvh_global_lock); - cpu_tlb_flushID(); - cpu_cpwait(); - PMAP_UNLOCK(pmap); + + rw_wunlock(&pvh_global_lock); + cpu_tlb_flushID(); + cpu_cpwait(); + PMAP_UNLOCK(pmap); } @@ -2303,6 +2449,7 @@ void pmap_remove_all(vm_page_t m) { pv_entry_t pv; + pmap_t pmap; pt_entry_t *ptep; struct l2_bucket *l2b; boolean_t flush = FALSE; @@ -2317,25 +2464,26 @@ pmap_remove_all(vm_page_t m) rw_wlock(&pvh_global_lock); curpm = vmspace_pmap(curproc->p_vmspace); while ((pv = TAILQ_FIRST(&m->md.pv_list)) != NULL) { - if (flush == FALSE && (pv->pv_pmap == curpm || - pv->pv_pmap == pmap_kernel())) + pmap = PV_PMAP(pv); + if (flush == FALSE && (pmap == curpm || + pmap == pmap_kernel())) flush = TRUE; - PMAP_LOCK(pv->pv_pmap); - l2b = pmap_get_l2_bucket(pv->pv_pmap, pv->pv_va); + PMAP_LOCK(pmap); + l2b = pmap_get_l2_bucket(pmap, pv->pv_va); KASSERT(l2b != NULL, ("No l2 bucket")); ptep = &l2b->l2b_kva[l2pte_index(pv->pv_va)]; if (L2_S_WRITABLE(*ptep)) vm_page_dirty(m); *ptep = 0; - if (pmap_is_current(pv->pv_pmap)) + if (pmap_is_current(pmap)) PTE_SYNC(ptep); - pmap_free_l2_bucket(pv->pv_pmap, l2b, 1); - pv->pv_pmap->pm_stats.resident_count--; + pmap_free_l2_bucket(pmap, l2b, 1); + pmap->pm_stats.resident_count--; flags |= pv->pv_flags; - pmap_nuke_pv(m, pv->pv_pmap, pv); - PMAP_UNLOCK(pv->pv_pmap); - pmap_free_pv_entry(pv); + pmap_nuke_pv(m, pmap, pv); + pmap_free_pv_entry(pmap, pv); + PMAP_UNLOCK(pmap); } m->md.pvh_attrs &= ~(PVF_MOD | PVF_REF); @@ -2690,15 +2838,13 @@ do_l2b_alloc: if ((pve = pmap_remove_pv(opg, pmap, va))) { oflags = pve->pv_flags; - if (m && ((m->oflags & VPO_UNMANAGED))) { - pmap_free_pv_entry(pve); - pve = NULL; - } + if (m && ((m->oflags & VPO_UNMANAGED))) + pmap_free_pv_entry(pmap, pve); } } if ((m && !(m->oflags & VPO_UNMANAGED))) { - if ((!pve) && (pve = pmap_get_pv_entry()) == NULL) + if ((!pve) && (pve = pmap_get_pv_entry(pmap, FALSE)) == NULL) panic("pmap_enter: no pv entries"); KASSERT(va < kmi.clean_sva || va >= kmi.clean_eva, @@ -3020,7 +3166,7 @@ pmap_pinit(pmap_t pmap) CPU_ZERO(&pmap->pm_active); - TAILQ_INIT(&pmap->pm_pvlist); + TAILQ_INIT(&pmap->pm_pvchunk); bzero(&pmap->pm_stats, sizeof pmap->pm_stats); pmap->pm_stats.resident_count = 1; if (vector_page < KERNBASE) { @@ -3036,31 +3182,253 @@ pmap_pinit(pmap_t pmap) * page management routines. ***************************************************/ +/* + * We are in a serious low memory condition. Resort to + * drastic measures to free some pages so we can allocate + * another pv entry chunk. + */ +static vm_page_t +pmap_pv_reclaim(pmap_t locked_pmap) +{ + struct pch newtail; + struct pv_chunk *pc; + struct l2_bucket *l2b = NULL; + pmap_t pmap; + pt_entry_t *pt; + pv_entry_t pv; + vm_offset_t va; + vm_page_t free, m, m_pc; + uint32_t inuse; + int bit, field, freed, idx; + + PMAP_ASSERT_LOCKED(locked_pmap); + pmap = NULL; + free = m_pc = NULL; + TAILQ_INIT(&newtail); + while ((pc = TAILQ_FIRST(&pv_chunks)) != NULL && (pv_vafree == 0 || + free == NULL)) { + TAILQ_REMOVE(&pv_chunks, pc, pc_lru); + if (pmap != pc->pc_pmap) { + if (pmap != NULL) { + cpu_tlb_flushID(); + cpu_cpwait(); + if (pmap != locked_pmap) + PMAP_UNLOCK(pmap); + } + pmap = pc->pc_pmap; + /* Avoid deadlock and lock recursion. */ + if (pmap > locked_pmap) + PMAP_LOCK(pmap); + else if (pmap != locked_pmap && !PMAP_TRYLOCK(pmap)) { + pmap = NULL; + TAILQ_INSERT_TAIL(&newtail, pc, pc_lru); + continue; + } + } + + /* + * Destroy every non-wired, 4 KB page mapping in the chunk. + */ + freed = 0; + for (field = 0; field < _NPCM; field++) { + for (inuse = ~pc->pc_map[field] & pc_freemask[field]; + inuse != 0; inuse &= ~(1UL << bit)) { + bit = ffs(inuse) - 1; + idx = field * sizeof(inuse) * NBBY + bit; + pv = &pc->pc_pventry[idx]; + if (pv->pv_flags & PVF_WIRED) + continue; + + va = pv->pv_va; + l2b = pmap_get_l2_bucket(pmap, va); + KASSERT(l2b != NULL, ("No l2 bucket")); + pt = &l2b->l2b_kva[l2pte_index(va)]; + m = PHYS_TO_VM_PAGE(l2pte_pa(*pt)); + KASSERT((vm_offset_t)m >= KERNBASE, + ("Trying to access non-existent page " + "va %x pte %x in %s", va, *pt)); + *pt = 0; + PTE_SYNC(pt); + pmap_nuke_pv(m, pmap, pv); + pc->pc_map[field] |= 1UL << bit; + freed++; + } + } + if (freed == 0) { + TAILQ_INSERT_TAIL(&newtail, pc, pc_lru); + continue; + } + /* Every freed mapping is for a 4 KB page. */ + pmap->pm_stats.resident_count -= freed; + PV_STAT(pv_entry_frees += freed); + PV_STAT(pv_entry_spare += freed); + pv_entry_count -= freed; + TAILQ_REMOVE(&pmap->pm_pvchunk, pc, pc_list); + for (field = 0; field < _NPCM; field++) + if (pc->pc_map[field] != pc_freemask[field]) { + TAILQ_INSERT_HEAD(&pmap->pm_pvchunk, pc, + pc_list); + TAILQ_INSERT_TAIL(&newtail, pc, pc_lru); + + /* + * One freed pv entry in locked_pmap is + * sufficient. + */ + if (pmap == locked_pmap) + goto out; + break; + } + if (field == _NPCM) { + PV_STAT(pv_entry_spare -= _NPCPV); + PV_STAT(pc_chunk_count--); + PV_STAT(pc_chunk_frees++); + /* Entire chunk is free; return it. */ + m_pc = PHYS_TO_VM_PAGE(pmap_kextract((vm_offset_t)pc)); + pmap_qremove((vm_offset_t)pc, 1); + pmap_ptelist_free(&pv_vafree, (vm_offset_t)pc); + break; + } + } +out: + TAILQ_CONCAT(&pv_chunks, &newtail, pc_lru); + if (pmap != NULL) { + cpu_tlb_flushID(); + cpu_cpwait(); + if (pmap != locked_pmap) + PMAP_UNLOCK(pmap); + } + return (m_pc); +} + +/* + * free the pv_entry back to the free list + */ static void -pmap_free_pv_entry(pv_entry_t pv) +pmap_free_pv_entry(pmap_t pmap, pv_entry_t pv) { + struct pv_chunk *pc; + int bit, field, idx; + + rw_assert(&pvh_global_lock, RA_WLOCKED); + PMAP_ASSERT_LOCKED(pmap); + PV_STAT(pv_entry_frees++); + PV_STAT(pv_entry_spare++); pv_entry_count--; - uma_zfree(pvzone, pv); + pc = pv_to_chunk(pv); + idx = pv - &pc->pc_pventry[0]; + field = idx / (sizeof(u_long) * NBBY); + bit = idx % (sizeof(u_long) * NBBY); + pc->pc_map[field] |= 1ul << bit; + for (idx = 0; idx < _NPCM; idx++) + if (pc->pc_map[idx] != pc_freemask[idx]) { + /* + * 98% of the time, pc is already at the head of the + * list. If it isn't already, move it to the head. + */ + if (__predict_false(TAILQ_FIRST(&pmap->pm_pvchunk) != + pc)) { + TAILQ_REMOVE(&pmap->pm_pvchunk, pc, pc_list); + TAILQ_INSERT_HEAD(&pmap->pm_pvchunk, pc, + pc_list); + } + return; + } + TAILQ_REMOVE(&pmap->pm_pvchunk, pc, pc_list); + pmap_free_pv_chunk(pc); } +static void +pmap_free_pv_chunk(struct pv_chunk *pc) +{ + vm_page_t m; + + TAILQ_REMOVE(&pv_chunks, pc, pc_lru); + PV_STAT(pv_entry_spare -= _NPCPV); + PV_STAT(pc_chunk_count--); + PV_STAT(pc_chunk_frees++); + /* entire chunk is free, return it */ + m = PHYS_TO_VM_PAGE(pmap_kextract((vm_offset_t)pc)); + pmap_qremove((vm_offset_t)pc, 1); + vm_page_unwire(m, 0); + vm_page_free(m); + pmap_ptelist_free(&pv_vafree, (vm_offset_t)pc); + +} -/* - * get a new pv_entry, allocating a block from the system - * when needed. - * the memory allocation is performed bypassing the malloc code - * because of the possibility of allocations at interrupt time. - */ static pv_entry_t -pmap_get_pv_entry(void) +pmap_get_pv_entry(pmap_t pmap, boolean_t try) { - pv_entry_t ret_value; + static const struct timeval printinterval = { 60, 0 }; + static struct timeval lastprint; + struct pv_chunk *pc; + pv_entry_t pv; + vm_page_t m; + int bit, field, idx; + rw_assert(&pvh_global_lock, RA_WLOCKED); + PMAP_ASSERT_LOCKED(pmap); + PV_STAT(pv_entry_allocs++); pv_entry_count++; + if (pv_entry_count > pv_entry_high_water) - pagedaemon_wakeup(); - ret_value = uma_zalloc(pvzone, M_NOWAIT); - return ret_value; + if (ratecheck(&lastprint, &printinterval)) + printf("%s: Approaching the limit on PV entries.\n", + __func__); +retry: + pc = TAILQ_FIRST(&pmap->pm_pvchunk); + if (pc != NULL) { + for (field = 0; field < _NPCM; field++) { + if (pc->pc_map[field]) { + bit = ffs(pc->pc_map[field]) - 1; + break; + } + } + if (field < _NPCM) { + idx = field * sizeof(pc->pc_map[field]) * NBBY + bit; + pv = &pc->pc_pventry[idx]; + pc->pc_map[field] &= ~(1ul << bit); + /* If this was the last item, move it to tail */ + for (field = 0; field < _NPCM; field++) + if (pc->pc_map[field] != 0) { + PV_STAT(pv_entry_spare--); + return (pv); /* not full, return */ + } + TAILQ_REMOVE(&pmap->pm_pvchunk, pc, pc_list); + TAILQ_INSERT_TAIL(&pmap->pm_pvchunk, pc, pc_list); + PV_STAT(pv_entry_spare--); + return (pv); + } + } + /* + * Access to the ptelist "pv_vafree" is synchronized by the pvh + * global lock. If "pv_vafree" is currently non-empty, it will + * remain non-empty until pmap_ptelist_alloc() completes. + */ + if (pv_vafree == 0 || (m = vm_page_alloc(NULL, 0, VM_ALLOC_NORMAL | + VM_ALLOC_NOOBJ | VM_ALLOC_WIRED)) == NULL) { + if (try) { + pv_entry_count--; + PV_STAT(pc_chunk_tryfail++); + return (NULL); + } + m = pmap_pv_reclaim(pmap); + if (m == NULL) + goto retry; + } + PV_STAT(pc_chunk_count++); + PV_STAT(pc_chunk_allocs++); + pc = (struct pv_chunk *)pmap_ptelist_alloc(&pv_vafree); + pmap_qenter((vm_offset_t)pc, &m, 1); + pc->pc_pmap = pmap; + pc->pc_map[0] = pc_freemask[0] & ~1ul; /* preallocated bit 0 */ + for (field = 1; field < _NPCM; field++) + pc->pc_map[field] = pc_freemask[field]; + TAILQ_INSERT_TAIL(&pv_chunks, pc, pc_lru); + pv = &pc->pc_pventry[0]; + TAILQ_INSERT_HEAD(&pmap->pm_pvchunk, pc, pc_list); + PV_STAT(pv_entry_spare += _NPCPV - 1); + return (pv); } /* @@ -3138,7 +3506,7 @@ pmap_remove(pmap_t pm, vm_offset_t sva, vm_offset_t eva) if (pve) { is_exec = PV_BEEN_EXECD(pve->pv_flags); is_refd = PV_BEEN_REFD(pve->pv_flags); - pmap_free_pv_entry(pve); + pmap_free_pv_entry(pm, pve); } } @@ -3381,7 +3749,7 @@ pmap_page_exists_quick(pmap_t pmap, vm_page_t m) rv = FALSE; rw_wlock(&pvh_global_lock); TAILQ_FOREACH(pv, &m->md.pv_list, pv_list) { - if (pv->pv_pmap == pmap) { + if (PV_PMAP(pv) == pmap) { rv = TRUE; break; } diff --git a/sys/arm/include/pmap.h b/sys/arm/include/pmap.h index 7c8d073..bb5f414 100644 --- a/sys/arm/include/pmap.h +++ b/sys/arm/include/pmap.h @@ -116,9 +116,12 @@ struct pv_addr { }; struct pv_entry; +struct pv_chunk; struct md_page { +#if (ARM_MMU_V6 + ARM_MMU_V7) == 0 int pvh_attrs; +#endif vm_memattr_t pv_memattr; vm_offset_t pv_kva; /* first kernel VA mapping */ TAILQ_HEAD(,pv_entry) pv_list; @@ -152,7 +155,11 @@ struct pmap { pd_entry_t *pm_pdir; /* KVA of page directory */ cpuset_t pm_active; /* active on cpus */ struct pmap_statistics pm_stats; /* pmap statictics */ +#if (ARM_MMU_V6 + ARM_MMU_V7) != 0 + TAILQ_HEAD(,pv_chunk) pm_pvchunk; /* list of mappings in pmap */ +#else TAILQ_HEAD(,pv_entry) pm_pvlist; /* list of mappings in pmap */ +#endif }; typedef struct pmap *pmap_t; @@ -180,13 +187,31 @@ extern struct pmap kernel_pmap_store; * mappings of that page. An entry is a pv_entry_t, the list is pv_list. */ typedef struct pv_entry { - pmap_t pv_pmap; /* pmap where mapping lies */ vm_offset_t pv_va; /* virtual address for mapping */ TAILQ_ENTRY(pv_entry) pv_list; - TAILQ_ENTRY(pv_entry) pv_plist; int pv_flags; /* flags (wired, etc...) */ +#if (ARM_MMU_V6 + ARM_MMU_V7) == 0 + pmap_t pv_pmap; /* pmap where mapping lies */ + TAILQ_ENTRY(pv_entry) pv_plist; +#endif } *pv_entry_t; +/* + * pv_entries are allocated in chunks per-process. This avoids the + * need to track per-pmap assignments. + */ +#define _NPCM 8 +#define _NPCPV 252 + +struct pv_chunk { + pmap_t pc_pmap; + TAILQ_ENTRY(pv_chunk) pc_list; + uint32_t pc_map[_NPCM]; /* bitmap; 1 = free */ + uint32_t pc_dummy[3]; /* aligns pv_chunk to 4KB */ + TAILQ_ENTRY(pv_chunk) pc_lru; + struct pv_entry pc_pventry[_NPCPV]; +}; + #ifdef _KERNEL boolean_t pmap_get_pde_pte(pmap_t, vm_offset_t, pd_entry_t **, pt_entry_t **); diff --git a/sys/conf/options.arm b/sys/conf/options.arm index 37be6f4..70dccf8 100644 --- a/sys/conf/options.arm +++ b/sys/conf/options.arm @@ -36,6 +36,7 @@ LINUX_BOOT_ABI opt_global.h LOADERRAMADDR opt_global.h NO_EVENTTIMERS opt_timer.h PHYSADDR opt_global.h +PV_STATS opt_pmap.h QEMU_WORKAROUNDS opt_global.h SOC_MV_ARMADAXP opt_global.h SOC_MV_DISCOVERY opt_global.h -- 1.8.2 --------------050801050308040305030206-- From owner-freebsd-arm@FreeBSD.ORG Sat May 4 21:41:07 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D33E7144 for ; Sat, 4 May 2013 21:41:07 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id B4217183 for ; Sat, 4 May 2013 21:41:07 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r44Lf3Xg022038; Sat, 4 May 2013 21:41:03 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id i3sb8zkh6d7e4i2ppk4e6swjdw; Sat, 04 May 2013 21:41:03 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Is this related to the general panic discussed in freebsd-current? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <5183BF8C.4040406@thieprojects.ch> Date: Sat, 4 May 2013 14:41:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51835891.4050409@thieprojects.ch> <03971BD1-4ADE-4435-BDD0-B94B62634F1D@bsdimp.com> <5183BF8C.4040406@thieprojects.ch> To: freebsd-arm@freebsd.org, Warner Losh X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 21:41:07 -0000 On May 3, 2013, at 6:45 AM, Werner Thie wrote: > On 5/3/13 3:13 PM, Warner Losh wrote: >> On May 3, 2013, at 12:26 AM, Werner Thie wrote: >>=20 >>> Hi all >>>=20 >>> just came around yesterday to start playing with crochet, built an = image and KDB entering panic when booting >>>=20 >>> FreeBSD 10.0-CURRENT #0 r250144M: Thu May 2 10:10:20 CEST 2013 >>> = root@xtools:/usr/home/wthie/proj/crochet-freebsd/work/obj/arm.armv6/usr/lo= cal/src/sys/BEAGLEBONE arm >>> FreeBSD clang version 3.3 (trunk 178860) 20130405 >>> WARNING: WITNESS option enabled, expect reduced performance. >>> panic: acquiring blockable sleep lock with spinlock or critical = section held (rw) pmap pv global @ = /usr/local/src/sys/arm/arm/pmap-v6.c:1187 >>> KDB: enter: panic >>> [ thread pid 0 tid 0 ] >>> Stopped at $d: ldrb r15, [r15, r15, ror r15]! I think I've managed to isolate this to the stack_capture function in = sys/arm/arm/stack_machdep.c. Here's the breadcrumb trail I've followed so far: 1. Witness is complaining about pmap_fault_fixup trying to acquire the = "pmap pv global" lock before it dies. 2. Inserted printfs, found that pmap_fault_fixup was being called from = data_abort_handler (in sys/arm/arm/trap.c). 3. Uncommenting the printf in data_abort_handler gives the next step: data abort: fault address=3D0xe28db008 (from pc=3D0xc0519d08 = lr=3D0xc0519d14) 4. According to objdump, the PC address above is in stack_save = (actually, the inlined version of stack_capture), in = sys/arm/arm/stack_machdep.c. If I add a printf() to the middle of stack_capture, the kernel boots. = So it definitely smells like a code-generation error of some sort. I'm going to start digging through the assembly next. Tim From owner-freebsd-arm@FreeBSD.ORG Sat May 4 22:44:41 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6633E752 for ; Sat, 4 May 2013 22:44:41 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 2CA253C6 for ; Sat, 4 May 2013 22:44:40 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r44MicVZ022335; Sat, 4 May 2013 22:44:38 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 3art5is5gmh9ttydkcee8jkt7e; Sat, 04 May 2013 22:44:38 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Is this related to the general panic discussed in freebsd-current? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Sat, 4 May 2013 15:44:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6D0E82C9-79D1-4804-9B39-3440F99AA8FE@kientzle.com> References: <51835891.4050409@thieprojects.ch> <03971BD1-4ADE-4435-BDD0-B94B62634F1D@bsdimp.com> <5183BF8C.4040406@thieprojects.ch> To: Tim Kientzle X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 22:44:41 -0000 On May 4, 2013, at 2:41 PM, Tim Kientzle wrote: >=20 > On May 3, 2013, at 6:45 AM, Werner Thie wrote: >=20 >> On 5/3/13 3:13 PM, Warner Losh wrote: >>> On May 3, 2013, at 12:26 AM, Werner Thie wrote: >>>=20 >>>> Hi all >>>>=20 >>>> just came around yesterday to start playing with crochet, built an = image and KDB entering panic when booting >>>>=20 >>>> FreeBSD 10.0-CURRENT #0 r250144M: Thu May 2 10:10:20 CEST 2013 >>>> = root@xtools:/usr/home/wthie/proj/crochet-freebsd/work/obj/arm.armv6/usr/lo= cal/src/sys/BEAGLEBONE arm >>>> FreeBSD clang version 3.3 (trunk 178860) 20130405 >>>> WARNING: WITNESS option enabled, expect reduced performance. >>>> panic: acquiring blockable sleep lock with spinlock or critical = section held (rw) pmap pv global @ = /usr/local/src/sys/arm/arm/pmap-v6.c:1187 >>>> KDB: enter: panic >>>> [ thread pid 0 tid 0 ] >>>> Stopped at $d: ldrb r15, [r15, r15, ror r15]! >=20 > I think I've managed to isolate this to the stack_capture function in = sys/arm/arm/stack_machdep.c. >=20 > Here's the breadcrumb trail I've followed so far: >=20 > 1. Witness is complaining about pmap_fault_fixup trying to acquire the = "pmap pv global" lock before it dies. >=20 > 2. Inserted printfs, found that pmap_fault_fixup was being called from = data_abort_handler (in sys/arm/arm/trap.c). >=20 > 3. Uncommenting the printf in data_abort_handler gives the next step: >=20 > data abort: fault address=3D0xe28db008 (from pc=3D0xc0519d08 = lr=3D0xc0519d14) >=20 > 4. According to objdump, the PC address above is in stack_save = (actually, the inlined version of stack_capture), in = sys/arm/arm/stack_machdep.c. >=20 > If I add a printf() to the middle of stack_capture, the kernel boots. = So it definitely smells like a code-generation error of some sort. >=20 > I'm going to start digging through the assembly next. I'm baffled. If I insert a printf into the loop in stack_capture, the = kernel boots. But the generated assembly looks perfectly correct to me in either case. So inserting the printf must have some side-effect. The stack does end up aligned differently: The failing version puts 16 = bytes on the stack, the working version puts 24 bytes. But I can't figure out = how that would explain what I'm seeing... Tim