From owner-freebsd-arm@FreeBSD.ORG Sun Feb 10 01:04:54 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 473EBB04 for ; Sun, 10 Feb 2013 01:04:54 +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 B5C8C158 for ; Sun, 10 Feb 2013 01:04:53 +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 1U4LLX-000HtH-2z; Sat, 09 Feb 2013 17:04:45 -0800 Message-ID: <5116F226.7010204@bluezbox.com> Date: Sat, 09 Feb 2013 17:04:38 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: hiren panchasara Subject: Re: Raspberry Pi No Login References: <09931DEF-C90A-4E72-B5EE-02BB0C6A8588@kobudo.homeunix.net> <5109A3F2.7010508@bluezbox.com> In-Reply-To: <5109A3F2.7010508@bluezbox.com> 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 1/30/2013 2:51 PM, Oleksandr Tymoshenko wrote: > On 1/30/2013 2:25 PM, hiren panchasara wrote: >> On Wed, Jan 30, 2013 at 9:15 AM, Tim Kientzle wrote: >>> On Jan 30, 2013, at 7:42 AM, Neal Nelson wrote: >>> >>>> HI. >>>> >>>> I'm able to build a bootable FreeBSD image using the beaglebone >>>> scripts, which I understand is the accepted way at the moment. >>>> >>>> The problem I have is that everything seems to be going nicely, but >>>> I never get a login prompt. The last thing I see, after the ssh key >>>> generation stuff, is a line showing the date, then nothing. This is >>>> true using Current as of today (2012-01-30). >>>> >>>> I've had this problem for some time now as every image I build >>>> using this process has the same problem. If anyone has an idea as >>>> to what I'm doing wrong, I'd be very grateful. >>> Look at the kernel boot messages for the SD card >>> check. >>> >>> Is it probing at 25MHz or 50MHz? >>> >>> I haven't tried RPi in a little while, but last time I did >>> there was an erratic bug which caused the SD card >>> to sometimes get probed at 50MHz and be non-functional. >>> >>> I believe some people worked around this by trying >>> different cards or maybe it's been fixed in the >>> SD driver by now? >> Not sure if its fixed in the driver now but I got around the frequency >> problem by the patch available at: >> http://www.peach.ne.jp/archives/rpi/patch/ >> >> Basically its setting freq to 25MHz instead of default 50MHz in >> bcm2835_sdhci.c > > The patch works around the issue although it does address several > issues with FreeBSD's > generic mmc driver. Namely: driver does not check for return value for > functions that read > card's CSD, SCR or the result of switch command. CSD and SCR register > contain card-specific > information drivers uses to tune its operations. So when register read > command silently > fails driver uses partially valid data and hence its behavior might or > might not manifest > problems. > > Now the interesting part is why these [...] 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] Cc: Tim Kientzle , 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, 10 Feb 2013 01:04:54 -0000 On 1/30/2013 2:51 PM, Oleksandr Tymoshenko wrote: > On 1/30/2013 2:25 PM, hiren panchasara wrote: >> On Wed, Jan 30, 2013 at 9:15 AM, Tim Kientzle wrote: >>> On Jan 30, 2013, at 7:42 AM, Neal Nelson wrote: >>> >>>> HI. >>>> >>>> I'm able to build a bootable FreeBSD image using the beaglebone >>>> scripts, which I understand is the accepted way at the moment. >>>> >>>> The problem I have is that everything seems to be going nicely, but >>>> I never get a login prompt. The last thing I see, after the ssh key >>>> generation stuff, is a line showing the date, then nothing. This is >>>> true using Current as of today (2012-01-30). >>>> >>>> I've had this problem for some time now as every image I build >>>> using this process has the same problem. If anyone has an idea as >>>> to what I'm doing wrong, I'd be very grateful. >>> Look at the kernel boot messages for the SD card >>> check. >>> >>> Is it probing at 25MHz or 50MHz? >>> >>> I haven't tried RPi in a little while, but last time I did >>> there was an erratic bug which caused the SD card >>> to sometimes get probed at 50MHz and be non-functional. >>> >>> I believe some people worked around this by trying >>> different cards or maybe it's been fixed in the >>> SD driver by now? >> Not sure if its fixed in the driver now but I got around the frequency >> problem by the patch available at: >> http://www.peach.ne.jp/archives/rpi/patch/ >> >> Basically its setting freq to 25MHz instead of default 50MHz in >> bcm2835_sdhci.c > > The patch works around the issue although it does address several > issues with FreeBSD's > generic mmc driver. Namely: driver does not check for return value for > functions that read > card's CSD, SCR or the result of switch command. CSD and SCR register > contain card-specific > information drivers uses to tune its operations. So when register read > command silently > fails driver uses partially valid data and hence its behavior might or > might not manifest > problems. > > Now the interesting part is why these commands fail. SDHCI controller > returns Data CRC > errors when executing them. It happens fairly early in initialization > sequence so at that point > card operates at 400KHz and should not have problem like this. Today I went all scientific on this issue and plugged logic analyzer to SD card using SparkFun's SD Sniffer[1]. What I found was that on power up SDHCI controller starts operating at frequency of 190KHz but shortly after it, before any data is read via DATA line, it switches to 8MHz. So I capped minimum frequency for SDHCI driver at 8MHz and got RPi into endless reboot cycle. Lo and behold: it's been almost two hours and so far no Data CRC Error interrupts. Patch: http://people.freebsd.org/~gonzo/arm/patches/rpi-sdhci.diff Description: - Do not silently ignore failure of "Read CSD" and "Read SCR" commands since data returned by them is essential for further initialization - Properly calculate minimum frequency for SDHCI 3.00 and higher - Add new method to SDHCI interface for setting driver-specific minimum frequency. Provide default implementation. - Cap minimum frequency at 8MHz for Raspberry Pi's SDHC I'd appreciate reviews and testing. There is one debug printf that will be removed from final version. [1] https://www.sparkfun.com/products/11468 From owner-freebsd-arm@FreeBSD.ORG Sun Feb 10 01:25:03 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 39324FFD; Sun, 10 Feb 2013 01:25:03 +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 E99991C9; Sun, 10 Feb 2013 01:25:02 +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 1U4LfA-000I3E-CS; Sat, 09 Feb 2013 17:25:02 -0800 Message-ID: <5116F6E7.7060608@bluezbox.com> Date: Sat, 09 Feb 2013 17:24:55 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: arm@freebsd.org, mips@freebsd.org Subject: Accessing GPIO from scripting languages 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: Hello, If you happen to work on FreeBSD-based automation project that involves GPIO you might be interested in this small project: https://github.com/gonzoua/freebsd-gpio [...] 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, 10 Feb 2013 01:25:03 -0000 Hello, If you happen to work on FreeBSD-based automation project that involves GPIO you might be interested in this small project: https://github.com/gonzoua/freebsd-gpio It's simplistic wrapper around FreeBSD's GPIO ioctl coded in three languages: Perl, Python, and Ruby. From owner-freebsd-arm@FreeBSD.ORG Sun Feb 10 05:23:59 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 B3AC1A9F for ; Sun, 10 Feb 2013 05:23:59 +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 8A99C9AC for ; Sun, 10 Feb 2013 05:23:58 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1A5NnBT004170; Sun, 10 Feb 2013 05:23:49 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id z5jtixse3hpghdwd3f7gxycbes; Sun, 10 Feb 2013 05:23:49 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <5116CB50.9080303@ceetonetechnology.com> Date: Sat, 9 Feb 2013 21:23:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> References: <5116CB50.9080303@ceetonetechnology.com> To: george@ceetonetechnology.com 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, 10 Feb 2013 05:23:59 -0000 On Feb 9, 2013, at 2:18 PM, George Rosamond wrote: >=20 > What is the recommended method of building images: Tim's scripts or = Gonzo's script? >=20 > Not looking for too much detail and without reviewing everything, what = are the important differences? Either one will get you a bootable RaspberryPi image. Oleksandr's script is simple and straightforward. If you're used to building images manually, you'll probably find his script a lot easier to understand and modify for your needs. My script has a couple of more ambitious goals: * Build everything from source. It will build all of the various boot bits from source (as far as possible), which should make it a better choice for tracking changes to those various pieces. * Be an extensible platform for building various types of images. It already has configuration knobs for things like whether to include /usr/src or /usr/ports, and I'm experimenting with installing packages as part of the build (pkgng "almost" makes this easy). It should be relatively simple to add hooks for other kinds of configuration tweaks. * Support several different boards. It cleanly supports both RaspberryPi and BeagleBone right now. It should be feasible to support others but I don't have access to other hardware right now. Cheers, Tim From owner-freebsd-arm@FreeBSD.ORG Sun Feb 10 06:21: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 A4AE0FE4 for ; Sun, 10 Feb 2013 06:21:02 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 53267ABD for ; Sun, 10 Feb 2013 06:21:01 +0000 (UTC) Received: from ivory.local (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1A6KqbP082415 for ; Sun, 10 Feb 2013 01:20:52 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Sun, 10 Feb 2013 01:20:52 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: Re: building RaspPi Images Message-ID: <20130210012052.4d7e1a46@ivory.local> In-Reply-To: <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 10 Feb 2013 06:21:02 -0000 Greeting- I was thinking that we should be able to generate a generic image that will boot on both the Pi and the Bone. Maybe a config file that includes the needed drivers for both boards. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 "The strongest reason for the people to retain the right to keep and bear arms is, as a last resort, to protect themselves against tyranny in government" - Thomas Jefferson. From owner-freebsd-arm@FreeBSD.ORG Sun Feb 10 07:03: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 B6766408 for ; Sun, 10 Feb 2013 07:03:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 5EC35B83 for ; Sun, 10 Feb 2013 07:03:20 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id bn7so6509849ieb.25 for ; Sat, 09 Feb 2013 23:03:19 -0800 (PST) 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=8/PyQVxuziDKimAR8jpvoTZN6s3ujDdwRuiQ0IGeo4w=; b=LqERehG/AoTr1r8HTC5FS876oJRxiZGom+EjcVIx6dm2ie1MNAqT0JjzhDxwHZWvok 5AemWgoN4Aet7bAph0TG6sxUv9Yv6gD+RIdH860Hf19pRZJgeOgKas7uLPO0TR9ZtS2f J8u1mMn4TeE016iBElImc1FgAis4gLlLFNZTrs2Pr9T7dU0hJp5UedGXi4sPsYoNqiWY Vp42/XuOyQCyNoq0bWVlm3e9lB+iKLOobVyo+Yl5m/R2CWbtsYIi8XOFRoraiHPPOPLn 9MT3dw66G3COazD3Qgd4dqAa0zJrdg+eFDTgD/s9qeVf2NoDB0VmJekRCTOJJ9FINP1h 6jhQ== X-Received: by 10.50.135.36 with SMTP id pp4mr9133615igb.6.1360479799301; Sat, 09 Feb 2013 23:03:19 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id xd4sm23161210igb.3.2013.02.09.23.03.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Feb 2013 23:03:18 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130210012052.4d7e1a46@ivory.local> Date: Sun, 10 Feb 2013 00:03:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> To: Brett Wynkoop X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkpuxtUeSjh0IaAwJrb4CkQidMxYe4IQL421zg1qZdrbzJj024+Pz/su38WuwYHhvNZ+Dfy 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, 10 Feb 2013 07:03:20 -0000 On Feb 9, 2013, at 11:20 PM, Brett Wynkoop wrote: > I was thinking that we should be able to generate a generic image that > will boot on both the Pi and the Bone. Maybe a config file that > includes the needed drivers for both boards. You'll also need to make sure that the FDT comes from the boot loader, = and isn't the one compiled into the kernel. Generally, we should avoid = doing that, but the Pi has presented some challenges in that respect.... Warner From owner-freebsd-arm@FreeBSD.ORG Sun Feb 10 07:03: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 71D7643C for ; Sun, 10 Feb 2013 07:03: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 53FA8B90 for ; Sun, 10 Feb 2013 07:03:40 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1A73eHl004443; Sun, 10 Feb 2013 07:03:40 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id z4jyk9effcnyd4cvgrjqttt2di; Sun, 10 Feb 2013 07:03:40 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20130210012052.4d7e1a46@ivory.local> Date: Sat, 9 Feb 2013 23:03:38 -0800 Content-Transfer-Encoding: 7bit Message-Id: <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> To: Brett Wynkoop 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, 10 Feb 2013 07:03:41 -0000 On Feb 9, 2013, at 10:20 PM, Brett Wynkoop wrote: > > I was thinking that we should be able to generate a generic image that > will boot on both the Pi and the Bone. Maybe a config file that > includes the needed drivers for both boards. I've thought about this and believe it is pretty routine, though I've not had time to actually try implementing it. This specific combination is simplified by the fact that the boot bits are so different, so you can just put them all on the same SD card image. There are a few pieces you'll need to work through: 1. An MSDOS partition with all the boot bits from both systems 2. A kernel with all of the drivers for both systems 3. ubldr will need to identify the board somehow 4. ubldr will need to obtain the correct FDT Except for #3, this should all be entirely routine. For #4, the trick is to not compile any DTB into the kernel. Instead, the DTB is given to the kernel by the boot bits: * For RPi, this already happens: the first-stage boot loads a DTB, ubldr uses "fdt addr" to access that DTB in a known location and then passes it to the kernel. * For Beaglebone, you can use loader.rc commands to load the proper DTB from the UFS partition. I'm using the following on my BeagleBone right now: /boot/beaglebone.dtb /boot/loader.rc contains load /boot/kernel/kernel load -t dtb /boot/beaglebone.dtb autoboot This should be an afternoon's work for someone who already has a good understanding of FreeBSD boot processes. Tim From owner-freebsd-arm@FreeBSD.ORG Sun Feb 10 07:07: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 ED25551D for ; Sun, 10 Feb 2013 07:07:36 +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 B44B1BEF for ; Sun, 10 Feb 2013 07:07:36 +0000 (UTC) Received: by mail-ia0-f174.google.com with SMTP id o25so5583737iad.33 for ; Sat, 09 Feb 2013 23:07:36 -0800 (PST) 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=hMwMxeDPlMeCwuV0j2RoMpGFYAp5K/TNGtrY3Zx+8eQ=; b=kl7cDK0vyd6jLk1SQnjNw/nkCnzsfDiUhagtQtCK2ms2iP5bR+06jQpiWIks+239Ix srviJbp/cy/Lt09oHrbyffmgrXPmFUR/mCVek0klp16+4paNuHpJk6rG6TZoPYi1vQsF JYv+UyIR9uDY3FH2ftJf0l8wZPwFWxuTYk6g18z9vGVGtdqUrBiihdhM7mns0kyPnKB/ GNyyCakVM8rYGpybFL0RNbt1bUgge+eX9tHlmAgtxzj0YY89pBsXs79/RpvGQNykOQ16 Lcc2bcLADcH+Lzc17D5kJGtGIahqB2oTa9MeMS7uU+QLi11Ouqh0Rn9j7Kk6MVFJr61m PRCw== X-Received: by 10.50.242.9 with SMTP id wm9mr9030860igc.59.1360480056247; Sat, 09 Feb 2013 23:07:36 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ig8sm23183598igc.10.2013.02.09.23.07.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Feb 2013 23:07:35 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> Date: Sun, 10 Feb 2013 00:07:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkKH9QAWMItWm3gdLbRLP31NzjAYygWUkqP4IWeSWLSezKyYS8JYRC0z7BIBYqS8oQiNibr Cc: freebsd-arm@freebsd.org, Brett Wynkoop 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, 10 Feb 2013 07:07:37 -0000 On Feb 10, 2013, at 12:03 AM, Tim Kientzle wrote: > On Feb 9, 2013, at 10:20 PM, Brett Wynkoop wrote: >>=20 >> I was thinking that we should be able to generate a generic image = that >> will boot on both the Pi and the Bone. Maybe a config file that >> includes the needed drivers for both boards. >=20 > I've thought about this and believe it is pretty routine, > though I've not had time to actually try implementing it. >=20 > This specific combination is simplified by the fact > that the boot bits are so different, so you can just > put them all on the same SD card image. >=20 > There are a few pieces you'll need to work through: > 1. An MSDOS partition with all the boot bits from both systems > 2. A kernel with all of the drivers for both systems > 3. ubldr will need to identify the board somehow > 4. ubldr will need to obtain the correct FDT uboot is supposed to be providing the correct FDT. IF we aren't using = it, we're doing FDT wrong and need to fix that. > Except for #3, this should all be entirely routine. >=20 > For #4, the trick is to not compile any DTB into the > kernel. Instead, the DTB is given to the kernel by > the boot bits: >=20 > * For RPi, this already happens: the first-stage boot > loads a DTB, ubldr uses "fdt addr" to access that DTB > in a known location and then passes it to the kernel. Doesn't the RPi's boot loader give our /boot/loader enough info to get = this without the fdt addr command? > * For Beaglebone, you can use loader.rc commands to load > the proper DTB from the UFS partition. I'm using the following > on my BeagleBone right now: > /boot/beaglebone.dtb > /boot/loader.rc contains > load /boot/kernel/kernel > load -t dtb /boot/beaglebone.dtb > autoboot why isnt' the beagle board's boot loader passing it to /boot/loader? > This should be an afternoon's work for someone who already > has a good understanding of FreeBSD boot processes. The real solution here is to get the FDT plumbed through from the boards = primary boot strap code into our code. Linux requires that this be = passed in via like r2 for Linux to boot. We should make use of that too. Warner From owner-freebsd-arm@FreeBSD.ORG Sun Feb 10 07:18: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 94389715 for ; Sun, 10 Feb 2013 07:18:12 +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 5C3D5C2F for ; Sun, 10 Feb 2013 07:18:12 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1A7I3CW004541; Sun, 10 Feb 2013 07:18:03 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id bixjh57mp29r9u9gwgtwvk4uwi; Sun, 10 Feb 2013 07:18:03 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Sat, 9 Feb 2013 23:18:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> To: Warner Losh X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org, Brett Wynkoop 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, 10 Feb 2013 07:18:12 -0000 On Feb 9, 2013, at 11:07 PM, Warner Losh wrote: >> * For RPi, this already happens: the first-stage boot >> loads a DTB, ubldr uses "fdt addr" to access that DTB >> in a known location and then passes it to the kernel. >=20 > Doesn't the RPi's boot loader give our /boot/loader enough info to get = this without the fdt addr command? I haven't dug into this yet, but there's a mismatch somewhere between the RPi first-stage boot loader, U-Boot, and our ubldr. I briefly tried loading our kernel straight from the RPi first stage boot loader (dropping U-Boot and ubldr phases) but didn't get very far with it. Tim From owner-freebsd-arm@FreeBSD.ORG Sun Feb 10 07:32:25 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 33C40AF6 for ; Sun, 10 Feb 2013 07:32:25 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp5.clear.net.nz (smtp5.clear.net.nz [203.97.33.68]) by mx1.freebsd.org (Postfix) with ESMTP id DC5A4CDF for ; Sun, 10 Feb 2013 07:32:24 +0000 (UTC) Received: from mxin1-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp5.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MHZ0051SU9QDZ30@smtp5.clear.net.nz> for freebsd-arm@freebsd.org; Sun, 10 Feb 2013 20:32:17 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO bender) ([202.0.48.19]) by smtpin1.paradise.net.nz with ESMTP; Sun, 10 Feb 2013 20:32:15 +1300 Date: Sun, 10 Feb 2013 20:32:22 +1300 From: Andrew Turner Subject: Re: building RaspPi Images In-reply-to: <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> To: Tim Kientzle Message-id: <20130210203222.6b51e505@bender> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> Cc: freebsd-arm@freebsd.org, Brett Wynkoop 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, 10 Feb 2013 07:32:25 -0000 On Sat, 9 Feb 2013 23:03:38 -0800 Tim Kientzle wrote: > On Feb 9, 2013, at 10:20 PM, Brett Wynkoop wrote: > > > > I was thinking that we should be able to generate a generic image > > that will boot on both the Pi and the Bone. Maybe a config file > > that includes the needed drivers for both boards. > > I've thought about this and believe it is pretty routine, > though I've not had time to actually try implementing it. > > This specific combination is simplified by the fact > that the boot bits are so different, so you can just > put them all on the same SD card image. > > There are a few pieces you'll need to work through: > 1. An MSDOS partition with all the boot bits from both systems > 2. A kernel with all of the drivers for both systems > 3. ubldr will need to identify the board somehow > 4. ubldr will need to obtain the correct FDT 5. Update the kernel to allow it to be built for multiple boards. You will need to at least fix: - locore.S generates a fixed VA -> PA map, it's not too hard to fix this, I've looked into it but don't have the time to get it into a usable state. - initarm calls a number of functions that have are implemented on a per SoC family case. - Update the IRQ mask/unmask/next irq functions to allow multiple implementations and pick the correct one on boot. - Ditto for DELAY, DMA, reset, etc functions. I would suggest the first step is to get a kernel that can boot on the BeagleBone and PandaBoard. As they both have Ti CPUs they are similar enough we could skip some of the items in my list as they are already using a common SoC specific code base. Andrew From owner-freebsd-arm@FreeBSD.ORG Sun Feb 10 07:47:53 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 5F7EAE08 for ; Sun, 10 Feb 2013 07:47:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by mx1.freebsd.org (Postfix) with ESMTP id E6F10D3F for ; Sun, 10 Feb 2013 07:47:52 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id ni5so5189712obc.26 for ; Sat, 09 Feb 2013 23:47:46 -0800 (PST) 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=XBp1GUL7UjlKFfqAbQtQEOUE38hjO/2Y9IJUoCok2x8=; b=d2BZ4xukG+D1rKsmalMinKBnznryJiodLM0WjJvuoo3LSavVHHI24Gdp4n97FeRMDW kJDPuPSm7hWHxMWPV+WbPlyI0+50Z1U3b2Yy572vhvQoJTob52q80ms5LbY0T/MAbK1B x+k3sEl/HvN1lumEMO7CsRXrd+00TMjEnSXtr73FVje3rLOYvGUSomnOEx26khy221aJ /Mt1WlUbElrOjy690KFCnavS5xR4QViG0Om/B3otRinDlBr6eADRT7bNybJoX+KB6gfg 1fSIivyhZ0UdiTba7qQOqLIUoVG4DZH4X0TA6GU/+dGSi1dkutSuBAL1ppWFf3gikWJj Nb6g== X-Received: by 10.60.8.40 with SMTP id o8mr7965966oea.112.1360482465880; Sat, 09 Feb 2013 23:47:45 -0800 (PST) Received: from 53.imp.bsdimp.com ([209.117.142.2]) by mx.google.com with ESMTPS id 9sm20829316oeh.8.2013.02.09.23.47.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Feb 2013 23:47:45 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 10 Feb 2013 00:47:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8087503F-BE98-45B9-888B-044D9DA58B80@bsdimp.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkuLQilZ52NE5ZtQ4++Y1wK+/pNBei1K0HyMjHERqpA3RzVvrkgj74lJGAWjDXzpoHYKPuX Cc: freebsd-arm@freebsd.org, Brett Wynkoop 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, 10 Feb 2013 07:47:53 -0000 On Feb 10, 2013, at 12:18 AM, Tim Kientzle wrote: > On Feb 9, 2013, at 11:07 PM, Warner Losh wrote: >=20 >>> * For RPi, this already happens: the first-stage boot >>> loads a DTB, ubldr uses "fdt addr" to access that DTB >>> in a known location and then passes it to the kernel. >>=20 >> Doesn't the RPi's boot loader give our /boot/loader enough info to = get this without the fdt addr command? >=20 > I haven't dug into this yet, but there's a mismatch somewhere > between the RPi first-stage boot loader, U-Boot, and our ubldr. >=20 > I briefly tried loading our kernel straight from the RPi > first stage boot loader (dropping U-Boot and ubldr > phases) but didn't get very far with it. Our ubldr currently ignores r2 on boot, and tries to get the FDT via a = different uboot interface, but I'm thinking that part is broken...=20 Warner= From owner-freebsd-arm@FreeBSD.ORG Sun Feb 10 07:52: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 25B4E343 for ; Sun, 10 Feb 2013 07:52:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by mx1.freebsd.org (Postfix) with ESMTP id E67BBD8F for ; Sun, 10 Feb 2013 07:52:24 +0000 (UTC) Received: by mail-oa0-f45.google.com with SMTP id o6so5268035oag.4 for ; Sat, 09 Feb 2013 23:52:24 -0800 (PST) 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=JR1rsVDGrrr5SP6/ABljDEpNfWM/IAtVNQGG8wdyWyM=; b=UahGjNloX+fjEGhZ5I1lcasiNFw6n+JBSDYzpL3OvOsh4qenquR8eQNJN1Rux29bEM CJ1QQc3dj8eKEX5oepVtxvLXZbziGidv4qUvFDlQPf8ZmvQBzzz3hyknC7vf95buGwgY 7JUH0GWj1Cr/p8wUh4z8VhJr67OlLq2rYrIvtBjRyIOwHDKF/wZJejtQ5G3zDWDTffLm aXpAd3alFR9bgzZTVRVMjYEIbFiig3VEvDYArfXTn0UuOkLDrjeraaQueMOYX8e4zv6R hz6PebqUA+tK2Bm2Baxk+6DOT+m74dcraJrNRU/o4SFXyv+2WnMhWBvAXKhVq+NIG8uc UW1A== X-Received: by 10.182.54.102 with SMTP id i6mr7923396obp.67.1360482744057; Sat, 09 Feb 2013 23:52:24 -0800 (PST) Received: from 53.imp.bsdimp.com ([209.117.142.2]) by mx.google.com with ESMTPS id k4sm45812954oeb.5.2013.02.09.23.52.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Feb 2013 23:52:23 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130210203222.6b51e505@bender> Date: Sun, 10 Feb 2013 00:52:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <20130210203222.6b51e505@bender> To: Andrew Turner X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmZPl4y+vJIr8tzBFIywtv/F38YlWYsIU8TRty2wTPh3bv34829r+d+JrqBWSx4IwhCEzJO Cc: Tim Kientzle , freebsd-arm@freebsd.org, Brett Wynkoop 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, 10 Feb 2013 07:52:25 -0000 On Feb 10, 2013, at 12:32 AM, Andrew Turner wrote: > On Sat, 9 Feb 2013 23:03:38 -0800 > Tim Kientzle wrote: >=20 >> On Feb 9, 2013, at 10:20 PM, Brett Wynkoop wrote: >>>=20 >>> I was thinking that we should be able to generate a generic image >>> that will boot on both the Pi and the Bone. Maybe a config file >>> that includes the needed drivers for both boards. >>=20 >> I've thought about this and believe it is pretty routine, >> though I've not had time to actually try implementing it. >>=20 >> This specific combination is simplified by the fact >> that the boot bits are so different, so you can just >> put them all on the same SD card image. >>=20 >> There are a few pieces you'll need to work through: >> 1. An MSDOS partition with all the boot bits from both systems >> 2. A kernel with all of the drivers for both systems >> 3. ubldr will need to identify the board somehow >> 4. ubldr will need to obtain the correct FDT > 5. Update the kernel to allow it to be built for multiple boards. You > will need to at least fix: > - locore.S generates a fixed VA -> PA map, it's not too hard to fix > this, I've looked into it but don't have the time to get it into a > usable state. Aren't there also a number of VA/PA translations elsewhere that are also = hard coded via various #defines... > - initarm calls a number of functions that have are implemented on a > per SoC family case. FDT can help us here. We can get the SoC from it. > - Update the IRQ mask/unmask/next irq functions to allow multiple > implementations and pick the correct one on boot. > - Ditto for DELAY, DMA, reset, etc functions. I started on this at one point... > I would suggest the first step is to get a kernel that can boot on the > BeagleBone and PandaBoard. As they both have Ti CPUs they are similar > enough we could skip some of the items in my list as they are already > using a common SoC specific code base. I've also been pushing this for different Atmel boards as well, but = there isn't even FDT support for it just yet... Warner= From owner-freebsd-arm@FreeBSD.ORG Sun Feb 10 08:06:32 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 DED68FD for ; Sun, 10 Feb 2013 08:06:32 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp4.clear.net.nz (smtp4.clear.net.nz [203.97.37.64]) by mx1.freebsd.org (Postfix) with ESMTP id AE23EE41 for ; Sun, 10 Feb 2013 08:06:32 +0000 (UTC) Received: from mxin2-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp4.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MHZ008V4VUMQF00@smtp4.clear.net.nz> for freebsd-arm@freebsd.org; Sun, 10 Feb 2013 21:06:24 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO bender) ([202.0.48.19]) by smtpin2.paradise.net.nz with ESMTP; Sun, 10 Feb 2013 21:06:22 +1300 Date: Sun, 10 Feb 2013 21:06:27 +1300 From: Andrew Turner Subject: Re: building RaspPi Images In-reply-to: To: Warner Losh Message-id: <20130210210627.128f7b4a@bender> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <20130210203222.6b51e505@bender> Cc: Tim Kientzle , freebsd-arm@freebsd.org, Brett Wynkoop 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, 10 Feb 2013 08:06:32 -0000 On Sun, 10 Feb 2013 00:52:16 -0700 Warner Losh wrote: > > On Feb 10, 2013, at 12:32 AM, Andrew Turner wrote: > > > On Sat, 9 Feb 2013 23:03:38 -0800 > > Tim Kientzle wrote: > > > >> On Feb 9, 2013, at 10:20 PM, Brett Wynkoop wrote: > >>> > >>> I was thinking that we should be able to generate a generic image > >>> that will boot on both the Pi and the Bone. Maybe a config file > >>> that includes the needed drivers for both boards. > >> > >> I've thought about this and believe it is pretty routine, > >> though I've not had time to actually try implementing it. > >> > >> This specific combination is simplified by the fact > >> that the boot bits are so different, so you can just > >> put them all on the same SD card image. > >> > >> There are a few pieces you'll need to work through: > >> 1. An MSDOS partition with all the boot bits from both systems > >> 2. A kernel with all of the drivers for both systems > >> 3. ubldr will need to identify the board somehow > >> 4. ubldr will need to obtain the correct FDT > > 5. Update the kernel to allow it to be built for multiple boards. > > You will need to at least fix: > > - locore.S generates a fixed VA -> PA map, it's not too hard to fix > > this, I've looked into it but don't have the time to get it into a > > usable state. > > Aren't there also a number of VA/PA translations elsewhere that are > also hard coded via various #defines... Yes, some of these are safe as they are for devices we use before the dynamic mapping is set up, e.g. for the uart. > > > - initarm calls a number of functions that have are implemented on a > > per SoC family case. > > FDT can help us here. We can get the SoC from it. > > > - Update the IRQ mask/unmask/next irq functions to allow multiple > > implementations and pick the correct one on boot. > > - Ditto for DELAY, DMA, reset, etc functions. > > I started on this at one point... > > > I would suggest the first step is to get a kernel that can boot on > > the BeagleBone and PandaBoard. As they both have Ti CPUs they are > > similar enough we could skip some of the items in my list as they > > are already using a common SoC specific code base. > > I've also been pushing this for different Atmel boards as well, but > there isn't even FDT support for it just yet... I'm planning on returning to FDT Atmel when EABI is in a usable state with clang, real soon now(tm), along with other FDT work. Andrew From owner-freebsd-arm@FreeBSD.ORG Sun Feb 10 08:20:22 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 573C4526 for ; Sun, 10 Feb 2013 08:20:22 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp4.clear.net.nz (smtp4.clear.net.nz [203.97.37.64]) by mx1.freebsd.org (Postfix) with ESMTP id 25E05EA9 for ; Sun, 10 Feb 2013 08:20:21 +0000 (UTC) Received: from mxin2-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp4.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MHZ0085SWHWQF10@smtp4.clear.net.nz> for freebsd-arm@freebsd.org; Sun, 10 Feb 2013 21:20:21 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO bender) ([202.0.48.19]) by smtpin2.paradise.net.nz with ESMTP; Sun, 10 Feb 2013 21:20:20 +1300 Date: Sun, 10 Feb 2013 21:20:25 +1300 From: Andrew Turner Subject: Re: building RaspPi Images In-reply-to: <8087503F-BE98-45B9-888B-044D9DA58B80@bsdimp.com> To: Warner Losh Message-id: <20130210212025.009ee482@bender> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <8087503F-BE98-45B9-888B-044D9DA58B80@bsdimp.com> Cc: Tim Kientzle , freebsd-arm@freebsd.org, Brett Wynkoop 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, 10 Feb 2013 08:20:22 -0000 On Sun, 10 Feb 2013 00:47:38 -0700 Warner Losh wrote: > > On Feb 10, 2013, at 12:18 AM, Tim Kientzle wrote: > > > On Feb 9, 2013, at 11:07 PM, Warner Losh wrote: > > > >>> * For RPi, this already happens: the first-stage boot > >>> loads a DTB, ubldr uses "fdt addr" to access that DTB > >>> in a known location and then passes it to the kernel. > >> > >> Doesn't the RPi's boot loader give our /boot/loader enough info to > >> get this without the fdt addr command? > > > > I haven't dug into this yet, but there's a mismatch somewhere > > between the RPi first-stage boot loader, U-Boot, and our ubldr. > > > > I briefly tried loading our kernel straight from the RPi > > first stage boot loader (dropping U-Boot and ubldr > > phases) but didn't get very far with it. > > Our ubldr currently ignores r2 on boot, and tries to get the FDT via > a different uboot interface, but I'm thinking that part is broken... As I understand it ubldr is an elf image. We use the bootelf command from U-Boot to jump into it. This command executes entry(argc, argv); to run ubldr. As argc is an int and argv is a pointer these will be in r0 and r1 respectively, as such is shouldn't look at r2. It looks like ubldr doesn't look at argc and argv, and should have no need to unless we decide to have it take the address of the dtb on the command line, or have some other data passed in from U-Boot. Andrew From owner-freebsd-arm@FreeBSD.ORG Sun Feb 10 12:53: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 4F869C70 for ; Sun, 10 Feb 2013 12:53:01 +0000 (UTC) (envelope-from taguchi@ff.iij4u.or.jp) Received: from mfo.iij4u.or.jp (mfo11.iij4u.or.jp [210.138.174.81]) by mx1.freebsd.org (Postfix) with ESMTP id ED688B10 for ; Sun, 10 Feb 2013 12:53:00 +0000 (UTC) Received: by mfo.iij4u.or.jp (mfo11) id r1ACMCrh025013; Sun, 10 Feb 2013 21:22:12 +0900 DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=ff.iij4u.or.jp;h= Message-ID:Date:From:MIME-Version:To:Content-Type; i=taguchi@ff.iij4u.or.jp; s= 20120530.iij4u; t=1360498926; x=1361708526; bh=xy3kmp9K/pW7cRVB+aGjBH5NVn8U3DM3E IKUT8Ektdw=; b=bVHqvanyZUUf8C7CJuSaEHrGoH3FUDdFZyrcoEkEwxTN3J0FwhCKvZnKVprpfK6 QuUnI9kBYe6BokYkH9lccbPbFRuMDjyEX7wW7c0emKtwe8aokL3P5GQYvx30sRxDYVM7/hua1Wu7m j5+FC2DMSYo+tvujchz+yp3gf4sYEeQ=; Received: by mo.iij4u.or.jp (mo10) id r1ACM6wV000878; Sun, 10 Feb 2013 21:22:06 +0900 Received: from [10.0.1.129] (55.178.30.125.dy.iij4u.or.jp [125.30.178.55]) by mbox.iij4u.or.jp (mbox10) id r1ACM5pR030452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 10 Feb 2013 21:22:06 +0900 Message-ID: <511790F3.7070806@ff.iij4u.or.jp> Date: Sun, 10 Feb 2013 21:22:11 +0900 From: Takeshi Taguchi User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: add versatilepb support to tim's script Content-Type: multipart/mixed; boundary="------------040402090004050805000202" 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, 10 Feb 2013 12:53:01 -0000 This is a multi-part message in MIME format. --------------040402090004050805000202 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi, all Attached patch add support versatilepb to tim's script: https://github.com/kientzle/freebsd-beaglebone use: board_setup VersatilePB in config.sh. and try to run: sh beaglebine/sh then you will get following images: FreeBSD-VERSATILEPB.flash : kernel image FreeBSD-VERSATILEPB.img : userland image and then try to exec: qemu-system-arm -M versatilepb -m 128M \ -kernel FreeBSD-VERSATILEPB.flash \ -cpu arm1176 \ -hda FreeBSD-VERSATILEPB.img Thanks. - T.T --------------040402090004050805000202 Content-Type: text/plain; charset=Shift_JIS; name="freebsd-beaglebone.add_to_support_VersatilePB.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="freebsd-beaglebone.add_to_support_VersatilePB.diff" ZGlmZiAtLWdpdCBhL2JlYWdsZWJzZC5zaCBiL2JlYWdsZWJzZC5zaAppbmRleCBjYzE1Yzgy Li4zZWNiYTMzIDEwMDY0NAotLS0gYS9iZWFnbGVic2Quc2gKKysrIGIvYmVhZ2xlYnNkLnNo CkBAIC0yMyw2ICsyMywxNiBAQCBib2FyZF9jaGVja19wcmVyZXF1aXNpdGVzICggKSB7CiBi b2FyZF9idWlsZF9ib290bG9hZGVyICggKSB7IH0KIGJvYXJkX2NvbnN0cnVjdF9ib290X3Bh cnRpdGlvbiAoICkgeyB9CiBib2FyZF9jdXN0b21pemVfZnJlZWJzZF9wYXJ0aXRpb24gKCAp IHsgfQorYm9hcmRfc2hvd19tZXNzYWdlICggKSB7CisgICAgZWNobyAiRE9ORS4iCisgICAg ZWNobyAiQ29tcGxldGVkIGRpc2sgaW1hZ2UgaXMgaW46ICR7SU1HfSIKKyAgICBlY2hvCisg ICAgZWNobyAiQ29weSB0byBhIE1pY3JvU0RIQyBjYXJkIHVzaW5nIGEgY29tbWFuZCBzdWNo IGFzOiIKKyAgICBlY2hvICJkZCBpZj0ke0lNR30gb2Y9L2Rldi9kYTAgYnM9MW0iCisgICAg ZWNobyAiKFJlcGxhY2UgL2Rldi9kYTAgd2l0aCB0aGUgYXBwcm9wcmlhdGUgcGF0aCBmb3Ig eW91ciBTREhDIGNhcmQgcmVhZGVyLikiCisgICAgZWNobworfQorCiAKICMgRW1wdHkgZGVm aW5pdGlvbnMgb2YgZnVuY3Rpb25zIHRvIGJlIG92ZXJyaWRkZW4gYnkgdXNlci4KIGN1c3Rv bWl6ZV9ib290X3BhcnRpdGlvbiAoICkgeyB9CkBAIC03MywxMiArODMsMTIgQEAgdGhlbgog ICAgIGlmIFsgLWQgJHtCT0FSRERJUn0vb3ZlcmxheSBdCiAgICAgdGhlbgogCWVjaG8gIk92 ZXJsYXlpbmcgYm9hcmQtc3BlY2lmaWMgZmlsZXMgZnJvbSAke0JPQVJERElSfS9vdmVybGF5 IgotCShjZCAke0JPQVJERElSfS9vdmVybGF5OyBmaW5kIC4gfCBjcGlvIC1wICR7VUZTX01P VU5UfSkKKwkoY2QgJHtCT0FSRERJUn0vb3ZlcmxheTsgZmluZCAuIHwgY3BpbyAtcG11ZCAk e1VGU19NT1VOVH0pCiAgICAgZmkKICAgICBpZiBbIC1kICR7V09SS0RJUn0vb3ZlcmxheSBd CiAgICAgdGhlbgogCWVjaG8gIk92ZXJsYXlpbmcgZmlsZXMgZnJvbSAke1dPUktESVJ9L292 ZXJsYXkiCi0JKGNkICR7V09SS0RJUn0vb3ZlcmxheTsgZmluZCAuIHwgY3BpbyAtcCAke1VG U19NT1VOVH0pCisJKGNkICR7V09SS0RJUn0vb3ZlcmxheTsgZmluZCAuIHwgY3BpbyAtcG11 ZCAke1VGU19NT1VOVH0pCiAgICAgZmkKIAogZmkKQEAgLTk3LDExICsxMDcsNSBAQCBkaXNr X3JlbGVhc2VfaW1hZ2UKICMKICMgV2UgaGF2ZSBhIGZpbmlzaGVkIGltYWdlOyBleHBsYWlu IHdoYXQgdG8gZG8gd2l0aCBpdC4KICMKLWVjaG8gIkRPTkUuIgotZWNobyAiQ29tcGxldGVk IGRpc2sgaW1hZ2UgaXMgaW46ICR7SU1HfSIKLWVjaG8KLWVjaG8gIkNvcHkgdG8gYSBNaWNy b1NESEMgY2FyZCB1c2luZyBhIGNvbW1hbmQgc3VjaCBhczoiCi1lY2hvICJkZCBpZj0ke0lN R30gb2Y9L2Rldi9kYTAgYnM9MW0iCi1lY2hvICIoUmVwbGFjZSAvZGV2L2RhMCB3aXRoIHRo ZSBhcHByb3ByaWF0ZSBwYXRoIGZvciB5b3VyIFNESEMgY2FyZCByZWFkZXIuKSIKLWVjaG8K K2JvYXJkX3Nob3dfbWVzc2FnZQogZGF0ZQpkaWZmIC0tZ2l0IGEvYm9hcmQvVmVyc2F0aWxl UEIvb3ZlcmxheS9ib290L2xvYWRlci5yYyBiL2JvYXJkL1ZlcnNhdGlsZVBCL292ZXJsYXkv Ym9vdC9sb2FkZXIucmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uNDAw Y2MyMwotLS0gL2Rldi9udWxsCisrKyBiL2JvYXJkL1ZlcnNhdGlsZVBCL292ZXJsYXkvYm9v dC9sb2FkZXIucmMKQEAgLTAsMCArMSBAQAorZmR0IGFkZHIgMHgxMDAKZGlmZiAtLWdpdCBh L2JvYXJkL1ZlcnNhdGlsZVBCL292ZXJsYXkvZXRjL2ZzdGFiIGIvYm9hcmQvVmVyc2F0aWxl UEIvb3ZlcmxheS9ldGMvZnN0YWIKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAw MC4uY2E0MDgxOQotLS0gL2Rldi9udWxsCisrKyBiL2JvYXJkL1ZlcnNhdGlsZVBCL292ZXJs YXkvZXRjL2ZzdGFiCkBAIC0wLDAgKzEsMiBAQAorIyBEZXZpY2UJTW91bnRwb2ludAlGU3R5 cGUJT3B0aW9ucwlEdW1wCVBhc3MjCisvZGV2L21tY3NkMHMyYSAvIAkJdWZzIHJ3LG5vYXRp bWUgMSAxCmRpZmYgLS1naXQgYS9ib2FyZC9WZXJzYXRpbGVQQi9vdmVybGF5L2V0Yy9yYy5j b25mIGIvYm9hcmQvVmVyc2F0aWxlUEIvb3ZlcmxheS9ldGMvcmMuY29uZgpuZXcgZmlsZSBt b2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi44Yzg1YWNmCi0tLSAvZGV2L251bGwKKysrIGIv Ym9hcmQvVmVyc2F0aWxlUEIvb3ZlcmxheS9ldGMvcmMuY29uZgpAQCAtMCwwICsxLDEyIEBA Citob3N0bmFtZT0idmVyc2F0aWxlcGIiCitpZmNvbmZpZ191ZTA9IkRIQ1AiCitzc2hkX2Vu YWJsZT0iWUVTIgorCisjIFR1cm4gb2ZmIGEgbG90IG9mIHN0YW5kYXJkIHN0dWZmCisjIGZv ciBtb3JlIGZyZWUgbWVtb3J5LgorY3Jvbl9lbmFibGU9Ik5PIgorZGV2ZF9lbmFibGU9Ik5P Igorc3lzbG9nZF9lbmFibGU9Ik5PIgorc2VuZG1haWxfc3VibWl0X2VuYWJsZT0iTk8iCitz ZW5kbWFpbF9vdXRib3VuZF9lbmFibGU9Ik5PIgorc2VuZG1haWxfbXNwX3F1ZXVlX2VuYWJs ZT0iTk8iCmRpZmYgLS1naXQgYS9ib2FyZC9WZXJzYXRpbGVQQi9vdmVybGF5L2V0Yy90dHlz IGIvYm9hcmQvVmVyc2F0aWxlUEIvb3ZlcmxheS9ldGMvdHR5cwpuZXcgZmlsZSBtb2RlIDEw MDY0NAppbmRleCAwMDAwMDAwLi5hOTVmNmNjCi0tLSAvZGV2L251bGwKKysrIGIvYm9hcmQv VmVyc2F0aWxlUEIvb3ZlcmxheS9ldGMvdHR5cwpAQCAtMCwwICsxLDEwIEBACit0dHl2MCAi L3Vzci9saWJleGVjL2dldHR5IFBjIiB4dGVybSBvbiBzZWN1cmUKK3R0eXYxICIvdXNyL2xp YmV4ZWMvZ2V0dHkgUGMiIHh0ZXJtIG9uIHNlY3VyZQordHR5djIgIi91c3IvbGliZXhlYy9n ZXR0eSBQYyIgeHRlcm0gb24gc2VjdXJlCit0dHl2MyAiL3Vzci9saWJleGVjL2dldHR5IFBj IiB4dGVybSBvbiBzZWN1cmUKK3R0eXY0ICIvdXNyL2xpYmV4ZWMvZ2V0dHkgUGMiIHh0ZXJt IG9uIHNlY3VyZQordHR5djUgIi91c3IvbGliZXhlYy9nZXR0eSBQYyIgeHRlcm0gb24gc2Vj dXJlCit0dHl2NiAiL3Vzci9saWJleGVjL2dldHR5IFBjIiB4dGVybSBvbiBzZWN1cmUKK3R0 eXY3ICIvdXNyL2xpYmV4ZWMvZ2V0dHkgUGMiIHh0ZXJtIG9uIHNlY3VyZQordHR5dTAgIi91 c3IvbGliZXhlYy9nZXR0eSAzd2lyZS4xMTUyMDAiIHZ0MTAyIG9uIHNlY3VyZQorCmRpZmYg LS1naXQgYS9ib2FyZC9WZXJzYXRpbGVQQi9zZXR1cC5zaCBiL2JvYXJkL1ZlcnNhdGlsZVBC L3NldHVwLnNoCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjc3YzE0MjgK LS0tIC9kZXYvbnVsbAorKysgYi9ib2FyZC9WZXJzYXRpbGVQQi9zZXR1cC5zaApAQCAtMCww ICsxLDM1IEBACitGUkVFQlNEX1NSQz0vdXNyL3NyYworS0VSTkNPTkY9VkVSU0FUSUxFUEIK K0lNRz0ke1dPUktESVJ9L0ZyZWVCU0QtJHtLRVJOQ09ORn0uaW1nCitGTEFTSD0ke1dPUktE SVJ9L0ZyZWVCU0QtJHtLRVJOQ09ORn0uZmxhc2gKK0tFUk5FTEJJTj0ke1dPUktESVJ9L29i ai9hcm0uYXJtdjZgcmVhbHBhdGggJHtGUkVFQlNEX1NSQ31gL3N5cy8ke0tFUk5DT05GfS9r ZXJuZWwuYmluCisKK2JvYXJkX2NvbnN0cnVjdF9ib290X3BhcnRpdGlvbiAoICkgeworICAg ICMgZHVtbXkgcGFydGl0aW9uLgorICAgIGRpc2tfZmF0X2NyZWF0ZSA4bQorICAgICMgYnVp bGQga2VybmVsIGZsdXNoIGltYWdlCisgICAgIyAgZm9sbG93aW5nIGNvZGUgaXMgc3RvcnJl biBmcm9tIGdvbnpvLCB0aGFua3MuCisgICAgcm0gLWYgJEZMQVNICisgICAgIyBzZXQgcjAu LnIzIHRvIHplcm8KKyAgICAvdXNyL2Jpbi9wcmludGYgIlwwXDBcMjQwXDM0MyIgPiAke1dP UktESVJ9L2ZpcnN0X2NvbW1hbmRzCisgICAgL3Vzci9iaW4vcHJpbnRmICJcMFwwMjBcMjQw XDM0MyIgPj4gJHtXT1JLRElSfS9maXJzdF9jb21tYW5kcworICAgIC91c3IvYmluL3ByaW50 ZiAiXDBcMDQwXDI0MFwzNDMiID4+ICR7V09SS0RJUn0vZmlyc3RfY29tbWFuZHMKKyAgICAv dXNyL2Jpbi9wcmludGYgIlwwXDA2MFwyNDBcMzQzIiA+PiAke1dPUktESVJ9L2ZpcnN0X2Nv bW1hbmRzCisgICAgIyBqdW1wIHRvIGtlcm5lbCBlbnRyeSBwb2ludAorICAgIC91c3IvYmlu L3ByaW50ZiAiXDAwMVwzNjZcMjQwXDM0MyIgPj4gJHtXT1JLRElSfS9maXJzdF9jb21tYW5k cworCisgICAgZGQgb2Y9JEZMQVNIIGJzPTFNIGNvdW50PTQgaWY9L2Rldi96ZXJvCisgICAg ZGQgb2Y9JEZMQVNIIGJzPTEgY29udj1ub3RydW5jIGlmPSR7V09SS0RJUn0vZmlyc3RfY29t bWFuZHMKKyAgICBkZCBvZj0kRkxBU0ggYnM9NjRrIG9zZWVrPTE1IGNvbnY9bm90cnVuYyBp Zj0kS0VSTkVMQklOCisgICAgCit9CisKK2JvYXJkX3Nob3dfbWVzc2FnZSAoICkgeworICAg IGVjaG8gIkRPTkUuIgorICAgIGVjaG8gIkNvbXBsZXRlZCBkaXNrIGltYWdlIGlzIGluOiAk e0lNR30iCisgICAgZWNobyAiQW5kIGtlcm5lbCBpbWFnZSBpcyBpbjogJHtGTEFTSH0iCisg ICAgZWNobworICAgIGVjaG8gIlRyeSB0byBydW46IgorICAgIGVjaG8gInFlbXUtc3lzdGVt LWFybSAtTSB2ZXJzYXRpbGVwYiAtbSAxMjhNIC1rZXJuZWwgJHtGTEFTSH0gLWNwdSBhcm0x MTc2IC1oZGEgJHtJTUd9IgorICAgIGVjaG8KK30KZGlmZiAtLWdpdCBhL2NvbmZpZy5zaC5z YW1wbGUgYi9jb25maWcuc2guc2FtcGxlCmluZGV4IDJkZjY5ZmMuLmRkNDg1YjkgMTAwNjQ0 Ci0tLSBhL2NvbmZpZy5zaC5zYW1wbGUKKysrIGIvY29uZmlnLnNoLnNhbXBsZQpAQCAtMTMs NiArMTMsNyBAQAogIyBib2FyZF9zZXR1cCBCZWFnbGVCb25lCiAjIGJvYXJkX3NldHVwIFJh c3BiZXJyeVBpCiAjIGJvYXJkX3NldHVwIFBhbmRhQm9hcmQKKyMgYm9hcmRfc2V0dXAgVmVy c2F0aWxlUEIKIAogIwogIyBSZWFkIGJvYXJkLzxib2FyZC1uYW1lPi9SRUFETUUgZm9yIG1v cmUgZGV0YWlscwo= --------------040402090004050805000202-- From owner-freebsd-arm@FreeBSD.ORG Sun Feb 10 14:56:16 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 2AD6A4F9 for ; Sun, 10 Feb 2013 14:56:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by mx1.freebsd.org (Postfix) with ESMTP id EFB241B3 for ; Sun, 10 Feb 2013 14:56:15 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id k13so6719016iea.35 for ; Sun, 10 Feb 2013 06:56:15 -0800 (PST) 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=DlDmLFvDB236eIQaOPDh1HHdFfAMv4nC9h8rvyP5rps=; b=DnGZ/R+XeuP863PdE6gQFF9BqEzDtXHoRDYy+Ndqcb3NcUNz/iFT0rwDxe3YSuO5xQ jNqJF/ShhryCzU1HX8EouLidT/7auae2h3vTyOWIDZxSq4CavEPJhDyPuNKMY/dMOqOJ 2bJrbQACV8PpDvhn3ud/omuzfn2ilJAtRKFyjWSSoj+tdCgDzOvxb52hw7bHc4zW3+Xz jY/+JGzCyUkFlOtriX2FB5y7tAxC122qyJnCmJHP7lzczl4CxDZyyBkIjVCvWwKsAvD+ KhLt1b6IPF17BzFYu2xrKLSS7nwxYi5GFnC7xATgm0RL1fDJlTfA6Ef5t39Q3mFgCysa A2XQ== X-Received: by 10.50.187.225 with SMTP id fv1mr9756132igc.96.1360508175501; Sun, 10 Feb 2013 06:56:15 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id fa6sm24181956igb.2.2013.02.10.06.56.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Feb 2013 06:56:14 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130210212025.009ee482@bender> Date: Sun, 10 Feb 2013 07:56:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <8087503F-BE98-45B9-888B-044D9DA58B80@bsdimp.com> <20130210212025.009ee482@bender> To: Andrew Turner X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkI5pjtfTEeRv/LsaJ0E3PHrWb1UySEaXUhjrjxVEsVk2GFtcBh2gNvejhVFUeu5sVXs/VZ Cc: Tim Kientzle , freebsd-arm@freebsd.org, Brett Wynkoop 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, 10 Feb 2013 14:56:16 -0000 On Feb 10, 2013, at 1:20 AM, Andrew Turner wrote: > On Sun, 10 Feb 2013 00:47:38 -0700 > Warner Losh wrote: >=20 >>=20 >> On Feb 10, 2013, at 12:18 AM, Tim Kientzle wrote: >>=20 >>> On Feb 9, 2013, at 11:07 PM, Warner Losh wrote: >>>=20 >>>>> * For RPi, this already happens: the first-stage boot >>>>> loads a DTB, ubldr uses "fdt addr" to access that DTB >>>>> in a known location and then passes it to the kernel. >>>>=20 >>>> Doesn't the RPi's boot loader give our /boot/loader enough info to >>>> get this without the fdt addr command? >>>=20 >>> I haven't dug into this yet, but there's a mismatch somewhere >>> between the RPi first-stage boot loader, U-Boot, and our ubldr. >>>=20 >>> I briefly tried loading our kernel straight from the RPi >>> first stage boot loader (dropping U-Boot and ubldr >>> phases) but didn't get very far with it. >>=20 >> Our ubldr currently ignores r2 on boot, and tries to get the FDT via >> a different uboot interface, but I'm thinking that part is broken...=20= >=20 > As I understand it ubldr is an elf image. We use the bootelf command > from U-Boot to jump into it. This command executes entry(argc, argv); > to run ubldr. As argc is an int and argv is a pointer these will be in > r0 and r1 respectively, as such is shouldn't look at r2. Right, we're doing it wrong. Or rather, we're using the standalone = interface when we should be using the linux interface. The stand alone = interface should, in theory, provide us with the DTB, but the code that = is in ubldr doesn't seem to be reliably getitng this image. If we can't = get it reliably from the standalone interface, we should switch to the = linux interface, where it should be trivial to get it. > It looks like ubldr doesn't look at argc and argv, and should have no > need to unless we decide to have it take the address of the dtb on the > command line, or have some other data passed in from U-Boot. uboot is supposed pass dtb to us. We're using the self-hosted interface, = rather than the linux interface, to boot. uboot is supposed to have a = jump table that we find and use to get the dtb from it, but that code = seems to not be working reliably. uboot gives linux images the DTB w/o = any problem today, but you have to run mkimage to get the image file to = load into uboot for that to work. We sure shouldn't be passing an address of the dtb via a command line = argument. Warner= From owner-freebsd-arm@FreeBSD.ORG Sun Feb 10 16:03:23 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 33C6C67A for ; Sun, 10 Feb 2013 16:03:23 +0000 (UTC) (envelope-from werner@thieprojects.ch) Received: from newton.metanet.ch (newton.metanet.ch [80.74.158.130]) by mx1.freebsd.org (Postfix) with ESMTP id 75F50402 for ; Sun, 10 Feb 2013 16:03:21 +0000 (UTC) Received: (qmail 32305 invoked from network); 10 Feb 2013 17:03:13 +0100 Received: from 217-071-083-008.ip-tech.ch (HELO ?192.168.11.88?) (217.71.83.8) by newton.metanet.ch with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Feb 2013 17:03:13 +0100 Message-ID: <5117C4C2.9010907@thieprojects.ch> Date: Sun, 10 Feb 2013 17:03:14 +0100 From: Werner Thie User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: named kills raspberry pi - Kudos and thanks References: <20130207223038.ec308967273d6a16c41be97b@sohara.org> <20130208075702.a755649a60d10dabf10a058b@sohara.org> <0B9B84F3-D627-497F-B1DA-BE4D0F9BC5DA@bsdimp.com> <20130208121803.e6b57c3822271cce6e56b4b2@sohara.org> <20130208152351.GB19514@FreeBSD.org> <20130208162814.346c605ce15a229e878dee27@sohara.org> <20130209102413.5c5d8fe6@bender> <1360362075.4545.32.camel@revolution.hippie.lan> <51162D16.7000206@thieprojects.ch> <5116703C.3000904@ceetonetechnology.com> <399EC5F6-6820-40A0-A58B-B3ECA1B58E76@kientzle.com> <540FFB37-3802-4D7E-A3A6-CF2C5C16B55A@kientzle.com> In-Reply-To: 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: Sun, 10 Feb 2013 16:03:23 -0000 Hi Tim > I believe this is fixed in r246601. That was timely and quick, mahalo nui loa, Werner From owner-freebsd-arm@FreeBSD.ORG Sun Feb 10 17:02: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 5C1F5461 for ; Sun, 10 Feb 2013 17:02:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id DA93784A for ; Sun, 10 Feb 2013 17:02:54 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id x48so4268276wey.37 for ; Sun, 10 Feb 2013 09:02:54 -0800 (PST) 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=h0APzbQmduMtuHXxZoEE9qkMms84rnqJXIXPnHBok9M=; b=Qlh44c/r4Et/3GEk0r2L9J3BvUhITIBsKAl59XBi8wJcuE1n8Tcj7FVYpGnS9YUQ1x zz2Ev/gaVSmWuOeWZIbSpfpInOj65U2nCA26El5l2A8luyjceIEXc2NiW/3f6NvIWjqk 1RK+wx+TBPvfrFcaKWg52JB9bPRFYVbMXSjRKh4Pc4J8u3LL5i3pHPffoadAzaVE+EVl xf6WjPE0yPFkb9diVvM9z/+3YesnERKLAt1ZYTP78ZLfLML4/1gemNlT2WY3+Izurl7G M/uV3gAb6YH5T/kgtCcEVHxYeZES9EaIvzth2g17hvITrkLTQKC9BmJ5IQLxG8SO6gdr NB2g== MIME-Version: 1.0 X-Received: by 10.180.99.227 with SMTP id et3mr11793407wib.6.1360515773916; Sun, 10 Feb 2013 09:02:53 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Sun, 10 Feb 2013 09:02:53 -0800 (PST) In-Reply-To: <5116F226.7010204@bluezbox.com> References: <09931DEF-C90A-4E72-B5EE-02BB0C6A8588@kobudo.homeunix.net> <5109A3F2.7010508@bluezbox.com> <5116F226.7010204@bluezbox.com> Date: Sun, 10 Feb 2013 09:02:53 -0800 X-Google-Sender-Auth: 7nBeT0m8jORq82wqWUTq48pDOyQ Message-ID: Subject: Re: Raspberry Pi No Login From: Adrian Chadd To: Oleksandr Tymoshenko Content-Type: text/plain; charset=ISO-8859-1 Cc: Tim Kientzle , 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, 10 Feb 2013 17:02:55 -0000 Hey, nice catch! Adrian (hardware is fun!) On 9 February 2013 17:04, Oleksandr Tymoshenko wrote: > On 1/30/2013 2:51 PM, Oleksandr Tymoshenko wrote: >> >> On 1/30/2013 2:25 PM, hiren panchasara wrote: >>> >>> On Wed, Jan 30, 2013 at 9:15 AM, Tim Kientzle wrote: >>>> >>>> On Jan 30, 2013, at 7:42 AM, Neal Nelson wrote: >>>> >>>>> HI. >>>>> >>>>> I'm able to build a bootable FreeBSD image using the beaglebone >>>>> scripts, which I understand is the accepted way at the moment. >>>>> >>>>> The problem I have is that everything seems to be going nicely, but I >>>>> never get a login prompt. The last thing I see, after the ssh key generation >>>>> stuff, is a line showing the date, then nothing. This is true using Current >>>>> as of today (2012-01-30). >>>>> >>>>> I've had this problem for some time now as every image I build using >>>>> this process has the same problem. If anyone has an idea as to what I'm >>>>> doing wrong, I'd be very grateful. >>>> >>>> Look at the kernel boot messages for the SD card >>>> check. >>>> >>>> Is it probing at 25MHz or 50MHz? >>>> >>>> I haven't tried RPi in a little while, but last time I did >>>> there was an erratic bug which caused the SD card >>>> to sometimes get probed at 50MHz and be non-functional. >>>> >>>> I believe some people worked around this by trying >>>> different cards or maybe it's been fixed in the >>>> SD driver by now? >>> >>> Not sure if its fixed in the driver now but I got around the frequency >>> problem by the patch available at: >>> http://www.peach.ne.jp/archives/rpi/patch/ >>> >>> Basically its setting freq to 25MHz instead of default 50MHz in >>> bcm2835_sdhci.c >> >> >> The patch works around the issue although it does address several issues >> with FreeBSD's >> generic mmc driver. Namely: driver does not check for return value for >> functions that read >> card's CSD, SCR or the result of switch command. CSD and SCR register >> contain card-specific >> information drivers uses to tune its operations. So when register read >> command silently >> fails driver uses partially valid data and hence its behavior might or >> might not manifest >> problems. >> >> Now the interesting part is why these commands fail. SDHCI controller >> returns Data CRC >> errors when executing them. It happens fairly early in initialization >> sequence so at that point >> card operates at 400KHz and should not have problem like this. > > > Today I went all scientific on this issue and plugged logic analyzer > to SD card using SparkFun's SD Sniffer[1]. What I found was that on > power up SDHCI controller starts operating at frequency of 190KHz but > shortly after it, before any data is read via DATA line, it switches to > 8MHz. So I capped minimum frequency for SDHCI driver at 8MHz and got > RPi into endless reboot cycle. Lo and behold: it's been almost two > hours and so far no Data CRC Error interrupts. > > Patch: http://people.freebsd.org/~gonzo/arm/patches/rpi-sdhci.diff > > Description: > - Do not silently ignore failure of "Read CSD" and "Read SCR" > commands since data returned by them is essential for further > initialization > - Properly calculate minimum frequency for SDHCI 3.00 and higher > - Add new method to SDHCI interface for setting driver-specific > minimum frequency. Provide default implementation. > - Cap minimum frequency at 8MHz for Raspberry Pi's SDHC > > I'd appreciate reviews and testing. There is one debug printf that > will be removed from final version. > > [1] https://www.sparkfun.com/products/11468 > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 00:40:00 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 0672FBB0 for ; Mon, 11 Feb 2013 00:40:00 +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 BFB2EADC for ; Mon, 11 Feb 2013 00:39:59 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1B0do3G009260; Mon, 11 Feb 2013 00:39:50 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id sm3pzikzsjmystbzf4vpygwvqa; Mon, 11 Feb 2013 00:39:50 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: Date: Sun, 10 Feb 2013 16:39:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1339E085-2B31-485D-9EED-9D0AFB7664C5@kientzle.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <8087503F-BE98-45B9-888B-044D9DA58B80@bsdimp.com> <20130210212025.009ee482@bender> To: Warner Losh X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org, Brett Wynkoop 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, 11 Feb 2013 00:40:00 -0000 On Feb 10, 2013, at 6:56 AM, Warner Losh wrote: >=20 > Right, we're doing it wrong. Or rather, we're using the standalone = interface when we should be using the linux interface. So you think that ubldr should startup like a Linux kernel? That's an interesting idea=85 Hmmmm=85.. > The stand alone interface should, in theory, provide us with the DTB, = but the code that is in ubldr doesn't seem to be reliably getitng this = image. I don't think anyone has spent time on this. We've just been focused on "making it work" and the compiled-in DTB does work for any single board. > uboot is supposed pass dtb to us. We're using the self-hosted = interface, rather than the linux interface, to boot. uboot is supposed = to have a jump table that we find and use to get the dtb from it, but = that code seems to not be working reliably. The interface works (I've spent a fair few hours fixing it), but I don't think anyone has tried getting the DTB from it. Any ideas for addressing the load-address problem? E.g., RPi has initial RAM mapped starting at address 0 and BeagleBone starts with RAM mapped to 0x80000000. Right now, that means we can't even share ubldr across those two systems because it has to be linked differently. > uboot gives linux images the DTB w/o any problem today, but you have = to run mkimage to get the image file to load into uboot for that to = work. Actually, the statement above isn't quite right for RPi. Linux on RPi doesn't use U-Boot. So we're currently using: RPi boot loader =3D> U-Boot =3D> ubldr =3D> kernel. The RPi boot loader does load the FDT and will pass it to a Linux kernel, but I don't think U-Boot implements that part of the linux kernel startup (which is why ubldr on RPi looks at a particular address in RAM to get the FDT from the RPi boot loader). Tim From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 01:00: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 9E92A355 for ; Mon, 11 Feb 2013 01:00:06 +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 81777C28 for ; Mon, 11 Feb 2013 01:00:06 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1B102N7009386; Mon, 11 Feb 2013 01:00:03 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id p5rp8jfbm2vwrdqcainzh4fu7e; Mon, 11 Feb 2013 01:00:02 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: add versatilepb support to tim's script Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-2022-jp From: Tim Kientzle In-Reply-To: <511790F3.7070806@ff.iij4u.or.jp> Date: Sun, 10 Feb 2013 17:00:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <511790F3.7070806@ff.iij4u.or.jp> To: Takeshi Taguchi 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, 11 Feb 2013 01:00:06 -0000 On Feb 10, 2013, at 4:22 AM, Takeshi Taguchi wrote: > Hi, all > Attached patch add support versatilepb to tim's script: > https://github.com/kientzle/freebsd-beaglebone >=20 > use: > board_setup VersatilePB > in config.sh. and try to run: > sh beaglebine/sh > then you will get following images: > FreeBSD-VERSATILEPB.flash : kernel image > FreeBSD-VERSATILEPB.img : userland image >=20 > and then try to exec: > qemu-system-arm -M versatilepb -m 128M \ > -kernel FreeBSD-VERSATILEPB.flash \ > -cpu arm1176 \ > -hda FreeBSD-VERSATILEPB.img >=20 > Thanks. > - > T.T Thank you! This is wonderful! I've merged this to the code on Github. I only have one suggestion for improving it: You use this code to get the kernel object file: KERNELBIN=3D${WORKDIR}/obj/arm.armv6`realpath = ${FREEBSD_SRC}`/sys/${KERNCONF}/kernel.bin then dd of=3D$FLASH =1B$B!D=1B(B. if=3D$KERNELBIN This approach is a little brittle. Elsewhere, I've used something similar to the following: mkdir ${WORKDIR}/kernel freebsd_kernel_install ${WORKDIR}/kernel dd .... if=3D${WORKDIR}/kernel/.../kernel.bin If this doesn't work, please consider adding a new function to lib/freebsd.sh to copy kernel.bin; that way, there will be only one place that knows about this kind of detail. (Rather than having copies of your code for every board.) Tim From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 03:33:12 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 28F9C3A5 for ; Mon, 11 Feb 2013 03:33:12 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id D0C2931E for ; Mon, 11 Feb 2013 03:33:10 +0000 (UTC) Received: from ivory.local (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1B3X9Dm000302 for ; Sun, 10 Feb 2013 22:33:09 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Sun, 10 Feb 2013 22:33:08 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: Raspberry-Pi B question and news Message-ID: <20130210223308.7df3f14f@ivory.local> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 11 Feb 2013 03:33:12 -0000 Greeting- I am holding a Raspberry-Pi B in my hand and it seems to have 2 white connectors on it that I do not find mentioned anywhere. Does anyone on this list know what they are for? One is near the RJ45 and the other is near the SD card slot. BTW my Pi is running FreeBSD by virtue of this 4Gb image: http://www.raspberrypi.org/archives/3094 I was unable to keep my FreeBSD 9 x86 box running long enough to build an image. I have to get to the root of disk issues in FreeBSD 9 x86 at some point. The Pi is happily talking on the net and has a 16G usb stick mounted as additional storage for ports, local and home dirs. Once I get a couple of ports built I plan to try to use Tims scripts on the Pi to try and build new BeagleBone and Pi images. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 I would never invade the United States. There would be a gun behind every blade of grass. --Isoroku Yamamoto From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 03:40: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 4EFB2415 for ; Mon, 11 Feb 2013 03:40:44 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id F04FD34E for ; Mon, 11 Feb 2013 03:40:43 +0000 (UTC) Received: from ivory.local (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1B3edxu000427; Sun, 10 Feb 2013 22:40:39 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Sun, 10 Feb 2013 22:40:39 -0500 From: Brett Wynkoop To: Dave Cheney Subject: Re: Raspberry-Pi B question and news Message-ID: <20130210224039.46998745@ivory.local> In-Reply-To: References: <20130210223308.7df3f14f@ivory.local> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 11 Feb 2013 03:40:44 -0000 On Mon, 11 Feb 2013 14:36:49 +1100 Dave Cheney wrote: > They have names which I do not know but one is for the camera module, > the other is a Low voltage differential interface to an lcd screen, > that you would typically find on a mobile phone. Hth Thanks Dave! -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 Gun Control: The theory that a woman found dead in an alley, raped and strangled with her own pantyhose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 03:49:28 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 AE406484 for ; Mon, 11 Feb 2013 03:49:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by mx1.freebsd.org (Postfix) with ESMTP id 4D61B374 for ; Mon, 11 Feb 2013 03:49:27 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id h2so5884987oag.10 for ; Sun, 10 Feb 2013 19:49:27 -0800 (PST) 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=KNRteHA4+qX/CdMUKoiC8FIW59atiKYcWaXvWS701hc=; b=RmDxFbYnT3hkUW2Y+ZOugd2fnMXwoMSd7yA1YKNC2d6CNZ8y0BPSCRWkTeCKOQ0s3K Pw4kC3+lcMiZUyUgrb85woXjuAcVTYEG/+olUCdxYAglHcDiQZU7c7EdHPRxpZni/TLE 6WSZhHp/mQn5lkXj3SHFrbEG6/N/unbR9ssfoysBJlywscvMRar6K+mv7nh4x2TGAaUg Dftxo9K6lKn0qqD6xz+ZO+ZOitzHdTkIQXB5DvOis9rYO23VW3TuhpWCzMb3cVCm4MIm r6jt7xQOs9H8YHGiSpf81vTvkofFUNEYqJ/kEa9KjSwuMptHxKzru7yqWVVLvFCVgQqT /Jpg== X-Received: by 10.182.73.67 with SMTP id j3mr9494953obv.102.1360554567373; Sun, 10 Feb 2013 19:49:27 -0800 (PST) Received: from 53.imp.bsdimp.com ([209.117.142.2]) by mx.google.com with ESMTPS id y4sm48957504oea.7.2013.02.10.19.49.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Feb 2013 19:49:26 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: <1339E085-2B31-485D-9EED-9D0AFB7664C5@kientzle.com> Date: Sun, 10 Feb 2013 20:49:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7F7AE905-7A08-48EE-8905-8D688266739A@bsdimp.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <8087503F-BE98-45B9-888B-044D9DA58B80@bsdimp.com> <20130210212025.009ee482@bender> <1339E085-2B31-485D-9EED-9D0AFB7664C5@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlQcrzBkT2gTVyP9ttph344wlUu9y+sc149m/ITGKyGdbUk0AQIyo/I9Bq0DpcbLGrGHvZc Cc: freebsd-arm@freebsd.org, Brett Wynkoop 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, 11 Feb 2013 03:49:28 -0000 On Feb 10, 2013, at 5:39 PM, Tim Kientzle wrote: > On Feb 10, 2013, at 6:56 AM, Warner Losh wrote: >>=20 >> Right, we're doing it wrong. Or rather, we're using the standalone = interface when we should be using the linux interface. >=20 > So you think that ubldr should startup like a Linux kernel? > That's an interesting idea=85 Hmmmm=85.. If it isn't getting the FDT via the alternate interface, then yes. >> The stand alone interface should, in theory, provide us with the DTB, = but the code that is in ubldr doesn't seem to be reliably getitng this = image. >=20 > I don't think anyone has spent time on this. We've > just been focused on "making it work" and the compiled-in > DTB does work for any single board. Ah, that makes sense. I just know the theory, not the practice. I = haven't had time for armv6 stuff... >> uboot is supposed pass dtb to us. We're using the self-hosted = interface, rather than the linux interface, to boot. uboot is supposed = to have a jump table that we find and use to get the dtb from it, but = that code seems to not be working reliably. >=20 > The interface works (I've spent a fair few hours fixing it), > but I don't think anyone has tried getting the DTB from it. We should try... > Any ideas for addressing the load-address problem? > E.g., RPi has initial RAM mapped starting at address 0 > and BeagleBone starts with RAM mapped to 0x80000000. > Right now, that means we can't even share ubldr across > those two systems because it has to be linked differently. I'm unsure how Linux deals with it... I'm guessing that if we can turn = on the vm translation early enough, then this won't matter... >> uboot gives linux images the DTB w/o any problem today, but you have = to run mkimage to get the image file to load into uboot for that to = work. >=20 > Actually, the statement above isn't quite right for RPi. > Linux on RPi doesn't use U-Boot. Well, all Linux kernels require DTBs today, although some compile it = into the image... > So we're currently > using: >=20 > RPi boot loader =3D> U-Boot =3D> ubldr =3D> kernel. >=20 > The RPi boot loader does load the FDT and will pass > it to a Linux kernel, but I don't think U-Boot implements > that part of the linux kernel startup (which is why ubldr > on RPi looks at a particular address in RAM to get > the FDT from the RPi boot loader). Ah, it implements the standard interface. That should be an option, = since it is relatively easy to do. Maybe I should give in and get a RPi :) Warner From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 04:17:11 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 E63EF6E1 for ; Mon, 11 Feb 2013 04:17:11 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 83EED642 for ; Mon, 11 Feb 2013 04:17:10 +0000 (UTC) Received: from ivory.local (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1B4H9DV000901 for ; Sun, 10 Feb 2013 23:17:09 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Sun, 10 Feb 2013 23:17:09 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: New BeagleBone errors Message-ID: <20130210231709.26f122dc@ivory.local> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 11 Feb 2013 04:17:12 -0000 Greeting- I am in the process of transferring man pages from the Bone to the Pi and I got this on the bone console: a ./man1/ls.1.gzcpsw0: watchdog timeout interrupt storm detected on "intr42:"; throttling interrupt source I am transferring by shoving a tar down nc....so tar cpvf - . | nc Pi 8080 I am not sure if the above info will be helpful to kernel hackers, but I hope it is. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 I would never invade the United States. There would be a gun behind every blade of grass. --Isoroku Yamamoto From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 04:26:56 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 6D58376D for ; Mon, 11 Feb 2013 04:26:56 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 34185680 for ; Mon, 11 Feb 2013 04:26:55 +0000 (UTC) Received: from ivory.local (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1B4Qtvs001016; Sun, 10 Feb 2013 23:26:55 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Sun, 10 Feb 2013 23:26:54 -0500 From: Brett Wynkoop To: Brett Wynkoop Subject: Re: New BeagleBone errors Message-ID: <20130210232654.386900d8@ivory.local> In-Reply-To: <20130210231709.26f122dc@ivory.local> References: <20130210231709.26f122dc@ivory.local> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 11 Feb 2013 04:26:56 -0000 On Sun, 10 Feb 2013 23:17:09 -0500 Brett Wynkoop wrote: > Greeting- > > I am in the process of transferring man pages from the Bone to the Pi > and I got this on the bone console: > > a ./man1/ls.1.gzcpsw0: watchdog timeout > interrupt storm detected on "intr42:"; throttling interrupt source > > > I am transferring by shoving a tar down nc....so > > tar cpvf - . | nc Pi 8080 > > I am not sure if the above info will be helpful to kernel hackers, but > I hope it is. > > -Brett > More info....looks like the Bone is locked up. I can not ping it and I have no console control. Single stepping at the debugger showed me that instructions continue to execute, but I am not sure what I am looking at. I guess it is assembler code prefaced with the module name, but not sure. I have given up on trying to figure anything more out and I reset the board. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 Gun Control: The theory that a woman found dead in an alley, raped and strangled with her own pantyhose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 06:07:40 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 4FB44398 for ; Mon, 11 Feb 2013 06:07:40 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id EBF82854 for ; Mon, 11 Feb 2013 06:07:39 +0000 (UTC) Received: from ivory.local (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1B67cYh002050 for ; Mon, 11 Feb 2013 01:07:38 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Mon, 11 Feb 2013 01:07:38 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: Bone locking up Message-ID: <20130211010738.0cfccc77@ivory.local> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 11 Feb 2013 06:07:40 -0000 Greeting- Well it seems that any non-trivial network activity is now causing the bone to lock up. I am trying to csup now and will build a new kernel when that is done. If anyone has any ideas let me know. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 "The strongest reason for the people to retain the right to keep and bear arms is, as a last resort, to protect themselves against tyranny in government" - Thomas Jefferson. From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 06:11:04 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 57EB03F4 for ; Mon, 11 Feb 2013 06:11:04 +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 2C14786F for ; Mon, 11 Feb 2013 06:11:03 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1B6B1rd010805; Mon, 11 Feb 2013 06:11:01 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id hmezjkabgapqzfw8nrnc77v8qs; Mon, 11 Feb 2013 06:11:00 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/mixed; boundary="Apple-Mail=_0DC54B77-4C16-4E6E-8F21-53D8FA7DFB88" From: Tim Kientzle In-Reply-To: <7F7AE905-7A08-48EE-8905-8D688266739A@bsdimp.com> Date: Sun, 10 Feb 2013 22:11:00 -0800 Message-Id: <67660AAE-0489-40F1-9729-FF2F0C631DF8@kientzle.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <8087503F-BE98-45B9-888B-044D9DA58B80@bsdimp.com> <20130210212025.009ee482@bender> <1339E085-2B31-485D-9EED-9D0AFB7664C5@kientzle.com> <7F7AE905-7A08-48EE-8905-8D688266739A@bsdimp.com> To: Warner Losh 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, 11 Feb 2013 06:11:04 -0000 --Apple-Mail=_0DC54B77-4C16-4E6E-8F21-53D8FA7DFB88 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >=20 >>> The stand alone interface should, in theory, provide us with the = DTB, but the code that is in ubldr doesn't seem to be reliably getitng = this image. >>=20 >> I don't think anyone has spent time on this. We've >> just been focused on "making it work" and the compiled-in >> DTB does work for any single board. >=20 > Ah, that makes sense. I just know the theory, not the practice. I = haven't had time for armv6 stuff=85 I started taking a look at this tonight. It appears we can get the FDT through the U-Boot API. In particular, U-Boot exposes an environment variable "fdtaddr" with the address of the FDT blob in memory. The attached (entirely untested) patch might do the trick. Hopefully I'll have time this week to rebuild all the boot bits and test this. Cheers, Tim --Apple-Mail=_0DC54B77-4C16-4E6E-8F21-53D8FA7DFB88 Content-Disposition: attachment; filename=t.diff Content-Type: application/octet-stream; name="t.diff" Content-Transfer-Encoding: 7bit Index: fdt/fdt_loader_cmd.c =================================================================== --- fdt/fdt_loader_cmd.c (revision 246647) +++ fdt/fdt_loader_cmd.c (working copy) @@ -238,23 +238,30 @@ fdt_setup_fdtp() { struct preloaded_file *bfp; + char *s, *p; vm_offset_t va; - bfp = file_findfile(NULL, "dtb"); - if (bfp == NULL) { - if ((va = fdt_find_static_dtb()) == 0) { - command_errmsg = "no device tree blob found!"; - return (1); + if (bfp = file_findfile(NULL, "dtb") != NULL) { + return fdt_load_dtb(bfp->f_addr); + } + + /* Experiment: See if we can get something reasonable out of U-Boot. */ + /* (But don't try to use this yet.) */ + s = ub_env_get("fdtaddr"); + if (s != NULL && *s != '\0') { + va = strtoul(s, &p, 16); + if (**p == '\0') { + printf("U-Boot has offered us a device tree at: 0x%08lX\n", (unsigned long)va); + /* TODO: Try loading DTB */ } - } else { - /* Dynamic blob has precedence over static. */ - va = bfp->f_addr; } - if (fdt_load_dtb(va) != 0) - return (1); - - return (0); + if (va = fdt_find_static_dtb() != 0) { + return (fdt_load_dtb(va)); + } + + command_errmsg = "no device tree blob found!"; + return (1); } #define fdt_strtovect(str, cellbuf, lim, cellsize) _fdt_strtovect((str), \ --Apple-Mail=_0DC54B77-4C16-4E6E-8F21-53D8FA7DFB88 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 --Apple-Mail=_0DC54B77-4C16-4E6E-8F21-53D8FA7DFB88-- From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 06:17:09 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 01FA343C for ; Mon, 11 Feb 2013 06:17:08 +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 CB9FD87E for ; Mon, 11 Feb 2013 06:17:08 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1B6H8hR010849; Mon, 11 Feb 2013 06:17:08 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 4ammtaytnzfe5bpr453m5jqfmi; Mon, 11 Feb 2013 06:17:07 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: New BeagleBone errors Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20130210231709.26f122dc@ivory.local> Date: Sun, 10 Feb 2013 22:17:07 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <20130210231709.26f122dc@ivory.local> To: Brett Wynkoop 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, 11 Feb 2013 06:17:09 -0000 On Feb 10, 2013, at 8:17 PM, Brett Wynkoop wrote: > Greeting- > > I am in the process of transferring man pages from the Bone to the Pi > and I got this on the bone console: > > a ./man1/ls.1.gzcpsw0: watchdog timeout > interrupt storm detected on "intr42:"; throttling interrupt source > > I am transferring by shoving a tar down nc....so > > tar cpvf - . | nc Pi 8080 Can you tell me the SVN revision of your BeagleBone kernel? Also, the output of "sysctl dev.cpsw" might hold useful clues whenever this happens. Interrupt 42 is the RX interrupt for the CPSW ethernet; it sounds like the driver is no longer correctly acknowledging RX interrupts after the watchdog reset. Tim From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 06:22:16 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 774D8492 for ; Mon, 11 Feb 2013 06:22:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) by mx1.freebsd.org (Postfix) with ESMTP id 148A9897 for ; Mon, 11 Feb 2013 06:22:15 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id ef5so5830671obb.11 for ; Sun, 10 Feb 2013 22:22:15 -0800 (PST) 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=ZmVyg4bEITxDHv9bja7gbkxLIbfGi3QJvC1d6eWXZ1c=; b=kIVvy4wdVuzwgVglEh4ljuad9EKn7RXfYOwEG9yz/QZpNqE89I1IpiqWfYF/lpTqJU NzX3iIQw/rVYi1GG/AEST25Kwwqt2o49HLyrY7Uvt8/5TA418glcHA8fQGtJ1Vm3L6P2 SNDLRmB4+DFzzAsEDkc2zaVfkebWD71RL6eNK/P9liK0ba7p2CR2VOCJ76ZZfW7k3GbX s+Kc0aM2dgd4qq9/26g2cycO17is3T06wsIVSgUJJKR34X6Wn1yHQ7+rX24tCimaQ+4x Mw+Cq32qpAQnZTag+bgK9XlQDw5eWACRqjlYYeKjbcTufIoUyJXjsFbSSUXe9MGFgqq8 1GXg== X-Received: by 10.182.231.39 with SMTP id td7mr9932827obc.86.1360563734988; Sun, 10 Feb 2013 22:22:14 -0800 (PST) Received: from 53.imp.bsdimp.com ([209.117.142.2]) by mx.google.com with ESMTPS id rn9sm48091102obb.11.2013.02.10.22.22.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Feb 2013 22:22:14 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: <67660AAE-0489-40F1-9729-FF2F0C631DF8@kientzle.com> Date: Sun, 10 Feb 2013 23:22:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8454CB00-22D2-40ED-AAE3-51C1AF28463A@bsdimp.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <8087503F-BE98-45B9-888B-044D9DA58B80@bsdimp.com> <20130210212025.009ee482@bender> <1339E085-2B31-485D-9EED-9D0AFB7664C5@kientzle.com> <7F7AE905-7A08-48EE-8905-8D688266739A@bsdimp.com> <67660AAE-0489-40F1-9729-FF2F0C631DF8@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmEPsn6A7lD1g0hCpY2x7+3iLm7XMGZd64KJFSYgDmTVlSOJhDyDa2x1gxFMV2DneLcXpXN 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, 11 Feb 2013 06:22:16 -0000 On Feb 10, 2013, at 11:11 PM, Tim Kientzle wrote: >>=20 >>>> The stand alone interface should, in theory, provide us with the = DTB, but the code that is in ubldr doesn't seem to be reliably getitng = this image. >>>=20 >>> I don't think anyone has spent time on this. We've >>> just been focused on "making it work" and the compiled-in >>> DTB does work for any single board. >>=20 >> Ah, that makes sense. I just know the theory, not the practice. I = haven't had time for armv6 stuff=85 >=20 > I started taking a look at this tonight. It appears > we can get the FDT through the U-Boot API. Cool! > In particular, U-Boot exposes an environment > variable "fdtaddr" with the address of the FDT > blob in memory. The attached (entirely untested) > patch might do the trick. That's really cool! It looks good to me, but I don't know how well the = docs match the code :) > Hopefully I'll have time this week to rebuild all > the boot bits and test this. >=20 > Cheers, >=20 > Tim >=20 > >=20 From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 06:47:16 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 7ED1A5D7 for ; Mon, 11 Feb 2013 06:47:16 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 23A4290E for ; Mon, 11 Feb 2013 06:47:13 +0000 (UTC) Received: from ivory.local (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1B6l4Ql002491; Mon, 11 Feb 2013 01:47:04 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Mon, 11 Feb 2013 01:47:04 -0500 From: Brett Wynkoop To: Tim Kientzle Subject: Re: New BeagleBone errors Message-ID: <20130211014704.3d3f11be@ivory.local> In-Reply-To: References: <20130210231709.26f122dc@ivory.local> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 11 Feb 2013 06:47:16 -0000 On Sun, 10 Feb 2013 22:17:07 -0800 Tim Kientzle wrote: > > On Feb 10, 2013, at 8:17 PM, Brett Wynkoop wrote: > > > Greeting- > > > > I am in the process of transferring man pages from the Bone to the > > Pi and I got this on the bone console: > > > > a ./man1/ls.1.gzcpsw0: watchdog timeout > > interrupt storm detected on "intr42:"; throttling interrupt source > > > > I am transferring by shoving a tar down nc....so > > > > tar cpvf - . | nc Pi 8080 > > Can you tell me the SVN revision of your > BeagleBone kernel? I already did a csup, so I do not think I can grab that info. I am in the middle of a kernel rebuild. > > Also, the output of "sysctl dev.cpsw" > might hold useful clues whenever this > happens. > > Interrupt 42 is the RX interrupt for the > CPSW ethernet; it sounds like the driver > is no longer correctly acknowledging RX > interrupts after the watchdog reset. root@beaglebone:/home/wynkoop # sysctl dev.cpsw dev.cpsw.0.%desc: 3-port Switch Ethernet Subsystem dev.cpsw.0.%driver: cpsw dev.cpsw.0.%parent: simplebus0 root@beaglebone:/home/wynkoop # I expect since we see only 3 things it means I am still somehow on the wrong driver. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 "The strongest reason for the people to retain the right to keep and bear arms is, as a last resort, to protect themselves against tyranny in government" - Thomas Jefferson. From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 08:22:13 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 EC88FDE4 for ; Mon, 11 Feb 2013 08:22:13 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 92540CE7 for ; Mon, 11 Feb 2013 08:22:12 +0000 (UTC) Received: from ivory.local (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1B8MBU6006094; Mon, 11 Feb 2013 03:22:12 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Mon, 11 Feb 2013 03:22:11 -0500 From: Brett Wynkoop To: Tim Kientzle Subject: Re: New BeagleBone errors Message-ID: <20130211032211.2db51fdc@ivory.local> In-Reply-To: References: <20130210231709.26f122dc@ivory.local> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 11 Feb 2013 08:22:14 -0000 Greeting- Now I know I have your most recent driver because the sysctl gave me a list 56 lines long! Let's see if the Bone works better now. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 Gun Control: The theory that a woman found dead in an alley, raped and strangled with her own pantyhose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 09: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 CCF013D5 for ; Mon, 11 Feb 2013 09:07:55 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7B496E67 for ; Mon, 11 Feb 2013 09:07:54 +0000 (UTC) Received: from ivory.local (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1B97qF3006621; Mon, 11 Feb 2013 04:07:53 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Mon, 11 Feb 2013 04:07:52 -0500 From: Brett Wynkoop To: Tim Kientzle , freebsd-arm@freebsd.org Subject: Re: New BeagleBone errors Message-ID: <20130211040752.46763083@ivory.local> In-Reply-To: References: <20130210231709.26f122dc@ivory.local> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 11 Feb 2013 09:07:55 -0000 Greeting- Well I rebuilt with today's head and I now have the most recent cpsw driver. The BeagleBone seems more responsive and is running a lower load average. My problems may have been related to having one of the less than stable versions running. Time will tell. I am in the middle of a csup on the Pi as well as building some ports. Once I get a fair number of packages under /usr/ports/packages, which is on a usb drive, I will put a web server up on the Pi so people can grab packages. When the csup is done I will build a current kernel for the Pi. I sure wish the Bone had working USB. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 Gun Control: The theory that a woman found dead in an alley, raped and strangled with her own pantyhose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 11:05:13 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 36683D5 for ; Mon, 11 Feb 2013 11:05:13 +0000 (UTC) (envelope-from mats@exmandato.se) Received: from ext.mellstrand.net (ext.mellstrand.net [IPv6:2001:2040:4:2::51]) by mx1.freebsd.org (Postfix) with ESMTP id 6565A1B33 for ; Mon, 11 Feb 2013 11:05:12 +0000 (UTC) Received: by ext.mellstrand.net Mon, 11 Feb 2013 11:05:05 GMT Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Mats Mellstrand X-Priority: 3 In-Reply-To: Date: Mon, 11 Feb 2013 12:05:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <016DDBBF-D502-4C76-96B5-BEE2D46FC6CC@exmandato.se> References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> <20130131001553.GC67562@cicely7.cicely.de> <9E78813F3BF946A4A2FCEA2C363A847E@ad.peach.ne.jp> To: Daisuke Aoyama Cc: freebsd-arm@freebsd.org, ticso@cicely.de 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, 11 Feb 2013 11:05:13 -0000 Hi,=20 In trying to install the ports collection on my RPi, the following = happens: kmem_malloc(4096): kmem_map too small: 12582912 total allocated KDB: enter: panic [ thread pid 27505 tid 100053 ] Stopped at $d: ldrb r15, [r15, r15, ror r15]! Suggestions? (more than not installing the ports collection) I'm running: FreeBSD 10.0-CURRENT #0 r246066M: Thu Jan 31 23:24:06 JST 2013 = aoyama@fbs.local:/usr/obj-rpi-clang/arm.armv6/usr/src/sys/RPI-B-test16 = arm /mm On 31 jan 2013, at 16:17, Mats Mellstrand wrote: > Hi >=20 > Thanks!=20 >=20 > Your patch works fine! >=20 > /mm >=20 > On 31 jan 2013, at 16:07, Daisuke Aoyama wrote: >=20 >> Hi, >>=20 >> I found a solution. When disabling hardware check sum offload, it = works. >> (# ifconfig ue0 -rxcsum) >>=20 >> Please check new kernel or apply the patch attached this mail. >> http://www.peach.ne.jp/archives/rpi/kernel/kernel-20130131.gz >>=20 >> Thanks, >> --=20 >> Daisuke Aoyama >>=20 >> -------------------------------------------------- >> From: "Bernd Walter" >> Sent: Thursday, January 31, 2013 9:15 AM >> To: "Mats Mellstrand" >> Cc: "Daisuke Aoyama" ; >> Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot = + ubldr) >>=20 >>> On Wed, Jan 30, 2013 at 06:28:12PM +0100, Mats Mellstrand wrote: >>>> Hi >>>>=20 >>>>=20 >>>> On 30 jan 2013, at 17:28, Daisuke Aoyama = wrote: >>>>=20 >>>>>> The image works, but I can't get IPv6 to work as expected. >>>>>> I can ping6 to and from my Raspberry but trying to ssh in to RPIs = IPv6 address just hangs. >>>>>> The same happens when I try to ssh out from RPI to a IPv6 = address. >>>>>> IPv4 works. >>>>>=20 >>>>> Sorry, I didn't check with ue0. >>>>> It seems if_smsc is buggy. >>>>> I'm using axe for testing. It works IPv6. >>>>>=20 >>>>>> pi@raspberry-pi:~ % w >>>>>> 4:19PM up 2:50, 3 users, load averages: 0.00, 0.00, 0.00 >>>>>> USER TTY FROM LOGIN@ IDLE WHAT >>>>>> root u0 - 4:11PM - -csh = (csh) >>>>>> pi pts/0 172.18.0.20 4:12PM - _su = (csh) >>>>>> pi pts/1 2001:3e0:6cf:18:20c:29ff 4:19PM - w >>>>>> pi@raspberry-pi:~ % ifconfig ue1 >>>>>> ue1: flags=3D8843 metric = 0 mtu 1500 >>>>>> options=3D80008 >>>>>> ether 10:6f:3f:66:75:1d >>>>>> inet6 fe80::126f:3fff:fe66:751d%ue1 prefixlen 64 scopeid 0x3 >>>>>> inet 172.18.0.99 netmask 0xffff0000 broadcast 172.18.255.255 >>>>>> inet6 2001:3e0:6cf:18:126f:3fff:fe66:751d prefixlen 64 >>>>>> nd6 options=3D21 >>>>>> media: Ethernet autoselect (100baseTX ) >>>>>> status: active >>>>>=20 >>>>> If possible, please try other ether device (include wireless LAN). >>>>=20 >>>>=20 >>>> Thanks! The interface run0/wlan0 works fine with IPv6 >>>=20 >>> If IPv4 works, then usually multicast hash support is broken in = driver. >>> It is hard to debug if you are unaware of the undelying protocol = details. >>> Assuming machine B is the one with the brokmen driver. >>> You can't ping6 from A to B until B sends anything to A. >>> This way A learns MAC address from B without needing the neighbor >>> discovery packet (ARP replacement, although ND6 has other purpose as = well), >>> which is send via multicast, to be received by machine B. >>> Putting an interface into promiscuous helps as workaround, because = then >>> the interface won't filter anything and all multicast frames are = received >>> as well, unless promiscuous support is broken too. >>> If ping6 works both sides than ssh should do as well, but only if = you >>> try before the nd6 entries expire. >>> A simple ping6 test might look as if it works if you started ping6 = from >>> B to A before trying from A to B, so A already has nd6 entry for B. >>> You can lookup nd6 table by issuing ndp -an command. >>>=20 >>> Some low level details. >>> A system has an IPv6 adress configured on it's interface. >>> It also joins a multicast group for that IP address. >>> There is a formular to calculate the multicast address from the = unicast(*) >>> address. >>> (*) when I write unicast I also mean link local and anycast as well. >>> You can lookup all IP addresses including multicast by netstat -ia. >>> A system, which wants to send an IPv6 packet to an IPv6 address at = the >>> same LAN needs the MAC address of the machine, which has the IPv6 = address >>> configured. >>> Unless it has the address in his neighbor address cache already it >>> sends an inquiry (Neighbor Discovery ND) to the multicast address - = with >>> IPv4 it was send via broadcast. >>> It knows the multicast address by using the same formular from the >>> targeting unicast address as the host owning that address. >>> This way the inquiry packet won't disturb every host allowing larger = LANs. >>> Some IPv6 unicast addresses share the same multicast, so there are = some >>> collisions, but less than with broadcast. >>> Multicast however also needs to be transfered using target MAC = addresses. >>> There is a formular which translates an IPv6 multicast address to an >>> ethernet MAC address, giving more address collisions. >>> Network interfaces can't filter countless individual MAC addresses, = so >>> there is a filter layer as well, usually containg 64 bits, with each >>> bit allowing a given set of multicast MAC addresses. >>> The formular from MAC address to filter bit is hardware dependend, >>> although most use the plain old NE2000 formular, there are exeptions >>> with other formular and chips using more bits allowing finer = filters. >>> This point is often done wrong in drivers - some forgot to take care >>> about multicast bits completely, some use the standard NE2000 filter >>> with hardware using something different, etc... >>>=20 >>> PS: >>> In the end there are many collisions, only to be avoided by using >>> multicast aware switches in large LANs and a few multicast = addresses. >>> Therefor also wise to avoid some unicast addresses as they collide >>> with anyhost or other popular multicast addresses. >>>=20 >>>=20 >>> --=20 >>> B.Walter http://www.bwct.de >>> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner = uvm. >> >=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 Mon Feb 11 11:06:10 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 190AB144 for ; Mon, 11 Feb 2013 11:06:10 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ia0-x232.google.com (ia-in-x0232.1e100.net [IPv6:2607:f8b0:4001:c02::232]) by mx1.freebsd.org (Postfix) with ESMTP id E5C681B5E for ; Mon, 11 Feb 2013 11:06:09 +0000 (UTC) Received: by mail-ia0-f178.google.com with SMTP id y26so6420029iab.9 for ; Mon, 11 Feb 2013 03:06:09 -0800 (PST) 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=RkzdWB9lpDn2FpZIt7pG7iwo/7fW7JMUWJwiZnFp1l8=; b=TEGnzlLlWDkQAEXentzZJsWBGqPcYtytpeYblIXe4C+clpg+uZXFeebYnBBBnZ/uQ1 zKiLXBAFCnaA0MIJLzP85eICxSIXzL601/SSIyOL5oZL+VhCBbgEGjvOvba7eVoeLhAZ hGn7VcEEThsGc/KN1i7MzBkv//5ELx2kIMjaJT6FmoHc6U/gsgS/+Tm1ITKvtduDgPn3 +LAThksFbxB9Kv4G+t6qMnrmHqHHNw3u/1j9wfzDFeGfkspDVq5XInOc3AtzJz2JG4Of f30H9yjdy1JCNqsT810IDU3ubLUjRDkBVrWURUHZHwYZ6xpZdK5j9k728SvN20raP5Yg egUg== MIME-Version: 1.0 X-Received: by 10.50.207.70 with SMTP id lu6mr11788641igc.50.1360580769200; Mon, 11 Feb 2013 03:06:09 -0800 (PST) Received: by 10.64.7.44 with HTTP; Mon, 11 Feb 2013 03:06:09 -0800 (PST) In-Reply-To: <20121020044349.GA32806@jail.io> References: <20121015060703.GA58633@jail.io> <6F20448B-96A0-428B-ACC1-1B2E08E53EEE@kientzle.com> <20121019200522.GA24298@jail.io> <20121020044349.GA32806@jail.io> Date: Mon, 11 Feb 2013 19:06:09 +0800 Message-ID: Subject: Re: ubldr hangs on Exynos 4412 From: Ganbold Tsagaankhuu To: Ruslan Bukin Content-Type: text/plain; charset=ISO-8859-1 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: Mon, 11 Feb 2013 11:06:10 -0000 Ruslan, On Sat, Oct 20, 2012 at 12:43 PM, Ruslan Bukin wrote: > On Fri, Oct 19, 2012 at 09:08:49PM -0700, Tim Kientzle wrote: >> > Thanks, Tim, it helps: >> > bootelf 0x40008000 >> > ## Starting application at 0x40008054 ... >> > Consoles: U-Boot console >> > Compatible API signature found @c3d000c0 >> > >> > but now, ubldr hangs on first syscall in glue.c (function ub_dev_enum) >> > syscall(API_DEV_ENUM, NULL, di) >> > >> > why it can happen? >> >> Are you using the U-Boot from Arago project? >> >> Check disk/part.c to make sure it has this fix: >> >> diff --git a/disk/part.c b/disk/part.c >> index f07a17f..e0022d1 100644 >> --- a/disk/part.c >> +++ b/disk/part.c >> @@ -80,6 +80,8 @@ block_dev_desc_t *get_dev(char* ifname, int dev) >> block_dev_desc_t* (*reloc_get_dev)(int dev); >> char *name; >> >> + if (ifname == NULL) >> + return NULL; >> name = drvr->name; >> #ifdef CONFIG_NEEDS_MANUAL_RELOC >> name += gd->reloc_off; >> >> > > No, I'm using uboot from the device manufacturer. > Should I use Arago ? > > Thanks again, ubldr started after I applied the patch. > > Number of U-Boot devices: 1 > > FreeBSD/arm U-Boot loader, Revision 1.2 > (root@intel.bsdpad.com, Fri Oct 19 22:50:42 UTC 2012) > DRAM: 1023MB > > Device: disk > > Device: net > net_probe: no network devices found, maybe not enumerated yet..? > netboot: couldn't probe uboot_eth0 > [...] > > Verbose help not available, use '?' to list commands > loader> > > seems my u-boot don't see ethernet, but I think it is not a big > problem for now. Just curious, how is Exynos support is going? Did you able to boot into single user mode? thanks, Ganbold > > -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 Mon Feb 11 11:06: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 B3FEF213 for ; Mon, 11 Feb 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 A39791BBD for ; Mon, 11 Feb 2013 11:06:41 +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 r1BB6fdJ081203 for ; Mon, 11 Feb 2013 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1BB6fLm081201 for freebsd-arm@FreeBSD.org; Mon, 11 Feb 2013 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Feb 2013 11:06:41 GMT Message-Id: <201302111106.r1BB6fLm081201@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, 11 Feb 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/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 [patch] nslu2_led driver for the LEDs on the NSLU2 p arm/134338 arm [patch] Lock GPIO accesses on ixp425 18 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 13:07: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 3620067C for ; Mon, 11 Feb 2013 13:07:01 +0000 (UTC) (envelope-from taguchi@ff.iij4u.or.jp) Received: from mo.iij4u.or.jp (mo10.iij4u.or.jp [210.138.174.78]) by mx1.freebsd.org (Postfix) with ESMTP id B34137FF for ; Mon, 11 Feb 2013 13:06:59 +0000 (UTC) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=ff.iij4u.or.jp;h= Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To:Content-Type; i=taguchi@ff.iij4u.or.jp; s=20120530.iij4u; t=1360588011; x=1361797611; bh=XoNLsd dBTjDshIRD0NpOJ90QLvvja0RTxSKAv9UBlLc=; b=okvxXBeLNZ3H8UhEtnM6ba2tXr+pLa6SQeUS nlZUu9iikv6EzoUgACkr44s+rikMZXLlIEahBnvfGJBxtKhMMVjin/ZqO75sSmC0USqGpkYJH/gHr dOWx0M+EPgDSGCKDDbl8Y5zGKVkpE/c6hztl8r6N3YShK5di2GWl6gYYH0=; Received: by mo.iij4u.or.jp (mo10) id r1BD6pld007806; Mon, 11 Feb 2013 22:06:51 +0900 Received: from [10.0.1.129] (55.178.30.125.dy.iij4u.or.jp [125.30.178.55]) by mbox.iij4u.or.jp (mbox10) id r1BD6oMm025948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Feb 2013 22:06:51 +0900 Message-ID: <5118ECD8.1040107@ff.iij4u.or.jp> Date: Mon, 11 Feb 2013 22:06:32 +0900 From: Takeshi Taguchi User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Tim Kientzle Subject: Re: add versatilepb support to tim's script References: <511790F3.7070806@ff.iij4u.or.jp> In-Reply-To: Content-Type: multipart/mixed; boundary="------------080400070806070803000102" 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, 11 Feb 2013 13:07:01 -0000 This is a multi-part message in MIME format. --------------080400070806070803000102 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi, Tim Thanks for your suggestion. Here is a update patch. I'd test using qemu on windows. it was seem work fine. Thanks. -- T.T 2013/02/11 10:00), Tim Kientzle wrote: > > On Feb 10, 2013, at 4:22 AM, Takeshi Taguchi wrote: > >> Hi, all >> Attached patch add support versatilepb to tim's script: >> https://github.com/kientzle/freebsd-beaglebone >> >> use: >> board_setup VersatilePB >> in config.sh. and try to run: >> sh beaglebine/sh >> then you will get following images: >> FreeBSD-VERSATILEPB.flash : kernel image >> FreeBSD-VERSATILEPB.img : userland image >> >> and then try to exec: >> qemu-system-arm -M versatilepb -m 128M \ >> -kernel FreeBSD-VERSATILEPB.flash \ >> -cpu arm1176 \ >> -hda FreeBSD-VERSATILEPB.img >> >> Thanks. >> - >> T.T > > Thank you! This is wonderful! > I've merged this to the code on Github. > > I only have one suggestion for improving it: > > You use this code to get the kernel object file: > > KERNELBIN=${WORKDIR}/obj/arm.armv6`realpath ${FREEBSD_SRC}`/sys/${KERNCONF}/kernel.bin > > then > > dd of=$FLASH $B!D(B. if=$KERNELBIN > > This approach is a little brittle. Elsewhere, > I've used something similar to the following: > > mkdir ${WORKDIR}/kernel > freebsd_kernel_install ${WORKDIR}/kernel > dd .... if=${WORKDIR}/kernel/.../kernel.bin > > If this doesn't work, please consider adding a new > function to lib/freebsd.sh to copy kernel.bin; that way, > there will be only one place that knows about this > kind of detail. (Rather than having copies of your > code for every board.) > > Tim > > > --------------080400070806070803000102 Content-Type: text/plain; charset=Shift_JIS; name="update.20130211.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="update.20130211.diff" ZGlmZiAtLWdpdCBhL2JvYXJkL1ZlcnNhdGlsZVBCL3NldHVwLnNoIGIvYm9hcmQvVmVyc2F0 aWxlUEIvc2V0dXAuc2gKaW5kZXggNzdjMTQyOC4uNTNjM2JjOSAxMDA2NDQKLS0tIGEvYm9h cmQvVmVyc2F0aWxlUEIvc2V0dXAuc2gKKysrIGIvYm9hcmQvVmVyc2F0aWxlUEIvc2V0dXAu c2gKQEAgLTIsNyArMiw3IEBAIEZSRUVCU0RfU1JDPS91c3Ivc3JjCiBLRVJOQ09ORj1WRVJT QVRJTEVQQgogSU1HPSR7V09SS0RJUn0vRnJlZUJTRC0ke0tFUk5DT05GfS5pbWcKIEZMQVNI PSR7V09SS0RJUn0vRnJlZUJTRC0ke0tFUk5DT05GfS5mbGFzaAotS0VSTkVMQklOPSR7V09S S0RJUn0vb2JqL2FybS5hcm12NmByZWFscGF0aCAke0ZSRUVCU0RfU1JDfWAvc3lzLyR7S0VS TkNPTkZ9L2tlcm5lbC5iaW4KK0ZSRUVCU0RfSU5TVEFMTEtFUk5FTF9CT0FSRF9BUkdTPUtF Uk5FTF9FWFRSQV9JTlNUQUxMPWtlcm5lbC5iaW4KIAogYm9hcmRfY29uc3RydWN0X2Jvb3Rf cGFydGl0aW9uICggKSB7CiAgICAgIyBkdW1teSBwYXJ0aXRpb24uCkBAIC0xNywxMCArMTcs MTMgQEAgYm9hcmRfY29uc3RydWN0X2Jvb3RfcGFydGl0aW9uICggKSB7CiAgICAgL3Vzci9i aW4vcHJpbnRmICJcMFwwNjBcMjQwXDM0MyIgPj4gJHtXT1JLRElSfS9maXJzdF9jb21tYW5k cwogICAgICMganVtcCB0byBrZXJuZWwgZW50cnkgcG9pbnQKICAgICAvdXNyL2Jpbi9wcmlu dGYgIlwwMDFcMzY2XDI0MFwzNDMiID4+ICR7V09SS0RJUn0vZmlyc3RfY29tbWFuZHMKKyAg ICAjIGluc3RhbGwga2VybmVsCisgICAgWyAhIC1kICR7V09SS0RJUn0vXy5rZXJuZWwuYmlu IF0gJiYgbWtkaXIgJHtXT1JLRElSfS9fLmtlcm5lbC5iaW4KKyAgICBmcmVlYnNkX2luc3Rh bGxrZXJuZWwgJHtXT1JLRElSfS9fLmtlcm5lbC5iaW4KIAogICAgIGRkIG9mPSRGTEFTSCBi cz0xTSBjb3VudD00IGlmPS9kZXYvemVybwogICAgIGRkIG9mPSRGTEFTSCBicz0xIGNvbnY9 bm90cnVuYyBpZj0ke1dPUktESVJ9L2ZpcnN0X2NvbW1hbmRzCi0gICAgZGQgb2Y9JEZMQVNI IGJzPTY0ayBvc2Vlaz0xNSBjb252PW5vdHJ1bmMgaWY9JEtFUk5FTEJJTgorICAgIGRkIG9m PSRGTEFTSCBicz02NGsgb3NlZWs9MTUgY29udj1ub3RydW5jIGlmPSR7V09SS0RJUn0vYm9v dC9rZXJuZWwva2VybmVsLmJpbgogICAgIAogfQogCg== --------------080400070806070803000102-- From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 13:12: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 2858A85B; Mon, 11 Feb 2013 13:12:33 +0000 (UTC) (envelope-from steve@sohara.org) Received: from uk1rly2283.eechost.net (relay01a.mail.uk1.eechost.net [217.69.40.75]) by mx1.freebsd.org (Postfix) with ESMTP id BFD94843; Mon, 11 Feb 2013 13:12:32 +0000 (UTC) Received: from [31.186.37.179] (helo=smtp.marelmo.com) by uk1rly2283.eechost.net with esmtpa (Exim 4.72) (envelope-from ) id 1U4tBa-0008Uy-Jf; Mon, 11 Feb 2013 13:12:42 +0000 Received: from [192.168.63.1] (helo=steve.marelmo.com) by smtp.marelmo.com with smtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U4tBH-0002jr-De; Mon, 11 Feb 2013 13:12:23 +0000 Date: Mon, 11 Feb 2013 13:11:52 +0000 From: Steve O'Hara-Smith To: Andrew Turner Subject: Re: named kills raspberry pi Message-Id: <20130211131152.86d8e41b884c48e0a8523a16@sohara.org> In-Reply-To: <20130209102413.5c5d8fe6@bender> References: <20130207223038.ec308967273d6a16c41be97b@sohara.org> <20130208075702.a755649a60d10dabf10a058b@sohara.org> <0B9B84F3-D627-497F-B1DA-BE4D0F9BC5DA@bsdimp.com> <20130208121803.e6b57c3822271cce6e56b4b2@sohara.org> <20130208152351.GB19514@FreeBSD.org> <20130208162814.346c605ce15a229e878dee27@sohara.org> <20130209102413.5c5d8fe6@bender> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Auth-Info: 15567@permanet.ie (plain) Cc: Tim Kientzle , freebsd-arm@FreeBSD.org, Romain =?UTF-8?B?VGFydGnDqHJl?= 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, 11 Feb 2013 13:12:33 -0000 On Sat, 09 Feb 2013 10:24:13 +1300 Andrew Turner wrote: > Can you try this patch [1]. It should fix the arm isc_atomic_cmpxchg > and add an armv6 implementation. I wrote it without knowing about > Romain's patch but it appears our armv[45] changes are almost identical. > > Andrew > > [1] http://people.freebsd.org/~andrew/bind_atomic.diff I got the same lockup behaviour with your patch - so I updated, and built a new image with debug support so that I could use gdb to get some information. That build runs named without any trouble at all. I am now building the same sources without debug flags. -- Steve O'Hara-Smith | Directable Mirror Arrays C:>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/ From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 15:51: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 AF2DA89E for ; Mon, 11 Feb 2013 15:51:49 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 13ECFA73 for ; Mon, 11 Feb 2013 15:51:48 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1BFpmSV065907 for ; Mon, 11 Feb 2013 08:51:48 -0700 (MST) (envelope-from ian@FreeBSD.org) 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 r1BFpjHN039656; Mon, 11 Feb 2013 08:51:46 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Raspberry Pi No Login From: Ian Lepore To: Oleksandr Tymoshenko In-Reply-To: <5116F226.7010204@bluezbox.com> References: <09931DEF-C90A-4E72-B5EE-02BB0C6A8588@kobudo.homeunix.net> <5109A3F2.7010508@bluezbox.com> <5116F226.7010204@bluezbox.com> Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Feb 2013 08:51:45 -0700 Message-ID: <1360597905.4545.89.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , 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, 11 Feb 2013 15:51:49 -0000 On Sat, 2013-02-09 at 17:04 -0800, Oleksandr Tymoshenko wrote: > On 1/30/2013 2:51 PM, Oleksandr Tymoshenko wrote: > > On 1/30/2013 2:25 PM, hiren panchasara wrote: > >> On Wed, Jan 30, 2013 at 9:15 AM, Tim Kientzle wrote: > >>> On Jan 30, 2013, at 7:42 AM, Neal Nelson wrote: > >>> > >>>> HI. > >>>> > >>>> I'm able to build a bootable FreeBSD image using the beaglebone > >>>> scripts, which I understand is the accepted way at the moment. > >>>> > >>>> The problem I have is that everything seems to be going nicely, but > >>>> I never get a login prompt. The last thing I see, after the ssh key > >>>> generation stuff, is a line showing the date, then nothing. This is > >>>> true using Current as of today (2012-01-30). > >>>> > >>>> I've had this problem for some time now as every image I build > >>>> using this process has the same problem. If anyone has an idea as > >>>> to what I'm doing wrong, I'd be very grateful. > >>> Look at the kernel boot messages for the SD card > >>> check. > >>> > >>> Is it probing at 25MHz or 50MHz? > >>> > >>> I haven't tried RPi in a little while, but last time I did > >>> there was an erratic bug which caused the SD card > >>> to sometimes get probed at 50MHz and be non-functional. > >>> > >>> I believe some people worked around this by trying > >>> different cards or maybe it's been fixed in the > >>> SD driver by now? > >> Not sure if its fixed in the driver now but I got around the frequency > >> problem by the patch available at: > >> http://www.peach.ne.jp/archives/rpi/patch/ > >> > >> Basically its setting freq to 25MHz instead of default 50MHz in > >> bcm2835_sdhci.c > > > > The patch works around the issue although it does address several > > issues with FreeBSD's > > generic mmc driver. Namely: driver does not check for return value for > > functions that read > > card's CSD, SCR or the result of switch command. CSD and SCR register > > contain card-specific > > information drivers uses to tune its operations. So when register read > > command silently > > fails driver uses partially valid data and hence its behavior might or > > might not manifest > > problems. > > > > Now the interesting part is why these commands fail. SDHCI controller > > returns Data CRC > > errors when executing them. It happens fairly early in initialization > > sequence so at that point > > card operates at 400KHz and should not have problem like this. > > Today I went all scientific on this issue and plugged logic analyzer > to SD card using SparkFun's SD Sniffer[1]. What I found was that on > power up SDHCI controller starts operating at frequency of 190KHz but > shortly after it, before any data is read via DATA line, it switches to > 8MHz. So I capped minimum frequency for SDHCI driver at 8MHz and got > RPi into endless reboot cycle. Lo and behold: it's been almost two > hours and so far no Data CRC Error interrupts. > > Patch: http://people.freebsd.org/~gonzo/arm/patches/rpi-sdhci.diff > > Description: > - Do not silently ignore failure of "Read CSD" and "Read SCR" > commands since data returned by them is essential for further > initialization > - Properly calculate minimum frequency for SDHCI 3.00 and higher > - Add new method to SDHCI interface for setting driver-specific > minimum frequency. Provide default implementation. > - Cap minimum frequency at 8MHz for Raspberry Pi's SDHC > > I'd appreciate reviews and testing. There is one debug printf that > will be removed from final version. > > [1] https://www.sparkfun.com/products/11468 > I may not be understanding what you mean about the 8mhz clock, but if that refers to the speed on the sd/mmc bus itself, that sounds like a violation of the protocol. The bus is supposed to be run at no more than 400khz until the card identification procedure is completed. (I suspect most modern card can run the ID sequence at full speed.) I wonder if the real problem is a violation of a rule about switching speed after the ID sequence... I vaguely remember there are some rules about that, like after sending commands that change the bus config you have to wait a certain number of cycles for the card to adjust. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 16:02:01 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 71F35D0D for ; Mon, 11 Feb 2013 16:02:01 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id D6385AFF for ; Mon, 11 Feb 2013 16:01:56 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1BG1sMe066095 for ; Mon, 11 Feb 2013 09:01:56 -0700 (MST) (envelope-from ian@FreeBSD.org) 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 r1BG1pJp039675; Mon, 11 Feb 2013 09:01:51 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: building RaspPi Images From: Ian Lepore To: Warner Losh In-Reply-To: References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Feb 2013 09:01:51 -0700 Message-ID: <1360598511.4545.92.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm@FreeBSD.org, Brett Wynkoop 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, 11 Feb 2013 16:02:01 -0000 On Sun, 2013-02-10 at 00:07 -0700, Warner Losh wrote: > On Feb 10, 2013, at 12:03 AM, Tim Kientzle wrote: > > > On Feb 9, 2013, at 10:20 PM, Brett Wynkoop wrote: > >> > >> I was thinking that we should be able to generate a generic image that > >> will boot on both the Pi and the Bone. Maybe a config file that > >> includes the needed drivers for both boards. > > > > I've thought about this and believe it is pretty routine, > > though I've not had time to actually try implementing it. > > > > This specific combination is simplified by the fact > > that the boot bits are so different, so you can just > > put them all on the same SD card image. > > > > There are a few pieces you'll need to work through: > > 1. An MSDOS partition with all the boot bits from both systems > > 2. A kernel with all of the drivers for both systems > > 3. ubldr will need to identify the board somehow > > 4. ubldr will need to obtain the correct FDT > > uboot is supposed to be providing the correct FDT. IF we aren't using it, we're doing FDT wrong and need to fix that. > > > Except for #3, this should all be entirely routine. > > > > For #4, the trick is to not compile any DTB into the > > kernel. Instead, the DTB is given to the kernel by > > the boot bits: > > > > * For RPi, this already happens: the first-stage boot > > loads a DTB, ubldr uses "fdt addr" to access that DTB > > in a known location and then passes it to the kernel. > > Doesn't the RPi's boot loader give our /boot/loader enough info to get this without the fdt addr command? > > > * For Beaglebone, you can use loader.rc commands to load > > the proper DTB from the UFS partition. I'm using the following > > on my BeagleBone right now: > > /boot/beaglebone.dtb > > /boot/loader.rc contains > > load /boot/kernel/kernel > > load -t dtb /boot/beaglebone.dtb > > autoboot > > why isnt' the beagle board's boot loader passing it to /boot/loader? > > > This should be an afternoon's work for someone who already > > has a good understanding of FreeBSD boot processes. > > The real solution here is to get the FDT plumbed through from the boards primary boot strap code into our code. Linux requires that this be passed in via like r2 for Linux to boot. We should make use of that too. > > Warner I'm seeing an essential conflict here in the mission of FDT data. If changing the FDT is the way an end user customizes things like pinmux assignments ("I need these pins for gpio, not another uart"), then how can we just accept a cannonical hardware description from low-level boot code we have no control over? -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 16:10:18 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 195F5226 for ; Mon, 11 Feb 2013 16:10:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x230.google.com (ia-in-x0230.1e100.net [IPv6:2607:f8b0:4001:c02::230]) by mx1.freebsd.org (Postfix) with ESMTP id DB66FBD6 for ; Mon, 11 Feb 2013 16:10:17 +0000 (UTC) Received: by mail-ia0-f176.google.com with SMTP id i18so6415787iac.7 for ; Mon, 11 Feb 2013 08:10:17 -0800 (PST) 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=LU5uAO2EISRJ2KwtDMS//C9Yawq3zgmNbLv9qnJ3xjo=; b=midBjG3p7jnpKojFzdo1domPyWienTQZ6PAxTa0IjID8ni769F9JPoRQ4LqQ6W4/zI ocWMgPvHo9i8wnWevg1BJ+EGFNKbPUHpo1nDW0GzhIZSl9dGbGg1dc1/bl891HlRTGxf lUcbVdBvH4MfaTXknB8PdJqzwB/UzYcTIjPFkDTt3PIlpTDzjTqt8j/JNaVMd7gysmG2 AfAWmkrh+H8zP0HPou+A0AC1iC8VMKtRuetZmVPpBJASCRY8a/eH58pMpTaBiiZeiFfZ yN/dxBgzo2D57s3x+U50U9H05/2ZWg8pnWqzClUL3NuTyrYgLxyP2mcgF3mdnwCJwrPA oPEg== X-Received: by 10.50.236.42 with SMTP id ur10mr12443423igc.16.1360599017253; Mon, 11 Feb 2013 08:10:17 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id fa6sm28724689igb.2.2013.02.11.08.10.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 08:10:16 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1360598511.4545.92.camel@revolution.hippie.lan> Date: Mon, 11 Feb 2013 09:10:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQldQOdIHf1p6R3DQcDEY4jp4Z8ZBM6ypaQMpOa7kXegxsRel+hi8EqNCOzVe0qxG6QSZ7oa Cc: Tim Kientzle , freebsd-arm@FreeBSD.org, Brett Wynkoop 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, 11 Feb 2013 16:10:18 -0000 On Feb 11, 2013, at 9:01 AM, Ian Lepore wrote: > On Sun, 2013-02-10 at 00:07 -0700, Warner Losh wrote: >> On Feb 10, 2013, at 12:03 AM, Tim Kientzle wrote: >>=20 >>> On Feb 9, 2013, at 10:20 PM, Brett Wynkoop wrote: >>>>=20 >>>> I was thinking that we should be able to generate a generic image = that >>>> will boot on both the Pi and the Bone. Maybe a config file that >>>> includes the needed drivers for both boards. >>>=20 >>> I've thought about this and believe it is pretty routine, >>> though I've not had time to actually try implementing it. >>>=20 >>> This specific combination is simplified by the fact >>> that the boot bits are so different, so you can just >>> put them all on the same SD card image. >>>=20 >>> There are a few pieces you'll need to work through: >>> 1. An MSDOS partition with all the boot bits from both systems >>> 2. A kernel with all of the drivers for both systems >>> 3. ubldr will need to identify the board somehow >>> 4. ubldr will need to obtain the correct FDT >>=20 >> uboot is supposed to be providing the correct FDT. IF we aren't using = it, we're doing FDT wrong and need to fix that. >>=20 >>> Except for #3, this should all be entirely routine. >>>=20 >>> For #4, the trick is to not compile any DTB into the >>> kernel. Instead, the DTB is given to the kernel by >>> the boot bits: >>>=20 >>> * For RPi, this already happens: the first-stage boot >>> loads a DTB, ubldr uses "fdt addr" to access that DTB >>> in a known location and then passes it to the kernel. >>=20 >> Doesn't the RPi's boot loader give our /boot/loader enough info to = get this without the fdt addr command? >>=20 >>> * For Beaglebone, you can use loader.rc commands to load >>> the proper DTB from the UFS partition. I'm using the following >>> on my BeagleBone right now: >>> /boot/beaglebone.dtb >>> /boot/loader.rc contains >>> load /boot/kernel/kernel >>> load -t dtb /boot/beaglebone.dtb >>> autoboot >>=20 >> why isnt' the beagle board's boot loader passing it to /boot/loader? >>=20 >>> This should be an afternoon's work for someone who already >>> has a good understanding of FreeBSD boot processes. >>=20 >> The real solution here is to get the FDT plumbed through from the = boards primary boot strap code into our code. Linux requires that this = be passed in via like r2 for Linux to boot. We should make use of that = too. >>=20 >> Warner >=20 > I'm seeing an essential conflict here in the mission of FDT data. If > changing the FDT is the way an end user customizes things like pinmux > assignments ("I need these pins for gpio, not another uart"), then how > can we just accept a cannonical hardware description from low-level = boot > code we have no control over? If you are going to do crazy things like this, then you supply your own = custom FDT. If you use the board in its stock configuration, then you = use the thing from the boot loader. If you hack the board, you have to = hack the FDT to match... Warner= From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 16:14:09 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 362BC2DA for ; Mon, 11 Feb 2013 16:14:09 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 0E73FC0F for ; Mon, 11 Feb 2013 16:14:00 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1BGE0FW066200 for ; Mon, 11 Feb 2013 09:14:00 -0700 (MST) (envelope-from ian@FreeBSD.org) 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 r1BGDvPo039730; Mon, 11 Feb 2013 09:13:57 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) From: Ian Lepore To: Mats Mellstrand In-Reply-To: <016DDBBF-D502-4C76-96B5-BEE2D46FC6CC@exmandato.se> References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> <20130131001553.GC67562@cicely7.cicely.de> <9E78813F3BF946A4A2FCEA2C363A847E@ad.peach.ne.jp> <016DDBBF-D502-4C76-96B5-BEE2D46FC6CC@exmandato.se> Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Feb 2013 09:13:57 -0700 Message-ID: <1360599237.4545.94.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 11 Feb 2013 16:14:09 -0000 On Mon, 2013-02-11 at 12:05 +0100, Mats Mellstrand wrote: > Hi, > > In trying to install the ports collection on my RPi, the following happens: > > kmem_malloc(4096): kmem_map too small: 12582912 total allocated > KDB: enter: panic > [ thread pid 27505 tid 100053 ] > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > > Suggestions? (more than not installing the ports collection) > > I'm running: > > FreeBSD 10.0-CURRENT #0 r246066M: Thu Jan 31 23:24:06 JST 2013 aoyama@fbs.local:/usr/obj-rpi-clang/arm.armv6/usr/src/sys/RPI-B-test16 arm > > /mm > You need fresher kernel sources, specifically the change in r246204 (which can be applied without updating everything else, if need be). -- Ian > > On 31 jan 2013, at 16:17, Mats Mellstrand wrote: > > > Hi > > > > Thanks! > > > > Your patch works fine! > > > > /mm > > > > On 31 jan 2013, at 16:07, Daisuke Aoyama wrote: > > > >> Hi, > >> > >> I found a solution. When disabling hardware check sum offload, it works. > >> (# ifconfig ue0 -rxcsum) > >> > >> Please check new kernel or apply the patch attached this mail. > >> http://www.peach.ne.jp/archives/rpi/kernel/kernel-20130131.gz > >> > >> Thanks, > >> -- > >> Daisuke Aoyama > >> > >> -------------------------------------------------- > >> From: "Bernd Walter" > >> Sent: Thursday, January 31, 2013 9:15 AM > >> To: "Mats Mellstrand" > >> Cc: "Daisuke Aoyama" ; > >> Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) > >> > >>> On Wed, Jan 30, 2013 at 06:28:12PM +0100, Mats Mellstrand wrote: > >>>> Hi > >>>> > >>>> > >>>> On 30 jan 2013, at 17:28, Daisuke Aoyama wrote: > >>>> > >>>>>> The image works, but I can't get IPv6 to work as expected. > >>>>>> I can ping6 to and from my Raspberry but trying to ssh in to RPIs IPv6 address just hangs. > >>>>>> The same happens when I try to ssh out from RPI to a IPv6 address. > >>>>>> IPv4 works. > >>>>> > >>>>> Sorry, I didn't check with ue0. > >>>>> It seems if_smsc is buggy. > >>>>> I'm using axe for testing. It works IPv6. > >>>>> > >>>>>> pi@raspberry-pi:~ % w > >>>>>> 4:19PM up 2:50, 3 users, load averages: 0.00, 0.00, 0.00 > >>>>>> USER TTY FROM LOGIN@ IDLE WHAT > >>>>>> root u0 - 4:11PM - -csh (csh) > >>>>>> pi pts/0 172.18.0.20 4:12PM - _su (csh) > >>>>>> pi pts/1 2001:3e0:6cf:18:20c:29ff 4:19PM - w > >>>>>> pi@raspberry-pi:~ % ifconfig ue1 > >>>>>> ue1: flags=8843 metric 0 mtu 1500 > >>>>>> options=80008 > >>>>>> ether 10:6f:3f:66:75:1d > >>>>>> inet6 fe80::126f:3fff:fe66:751d%ue1 prefixlen 64 scopeid 0x3 > >>>>>> inet 172.18.0.99 netmask 0xffff0000 broadcast 172.18.255.255 > >>>>>> inet6 2001:3e0:6cf:18:126f:3fff:fe66:751d prefixlen 64 > >>>>>> nd6 options=21 > >>>>>> media: Ethernet autoselect (100baseTX ) > >>>>>> status: active > >>>>> > >>>>> If possible, please try other ether device (include wireless LAN). > >>>> > >>>> > >>>> Thanks! The interface run0/wlan0 works fine with IPv6 > >>> > >>> If IPv4 works, then usually multicast hash support is broken in driver. > >>> It is hard to debug if you are unaware of the undelying protocol details. > >>> Assuming machine B is the one with the brokmen driver. > >>> You can't ping6 from A to B until B sends anything to A. > >>> This way A learns MAC address from B without needing the neighbor > >>> discovery packet (ARP replacement, although ND6 has other purpose as well), > >>> which is send via multicast, to be received by machine B. > >>> Putting an interface into promiscuous helps as workaround, because then > >>> the interface won't filter anything and all multicast frames are received > >>> as well, unless promiscuous support is broken too. > >>> If ping6 works both sides than ssh should do as well, but only if you > >>> try before the nd6 entries expire. > >>> A simple ping6 test might look as if it works if you started ping6 from > >>> B to A before trying from A to B, so A already has nd6 entry for B. > >>> You can lookup nd6 table by issuing ndp -an command. > >>> > >>> Some low level details. > >>> A system has an IPv6 adress configured on it's interface. > >>> It also joins a multicast group for that IP address. > >>> There is a formular to calculate the multicast address from the unicast(*) > >>> address. > >>> (*) when I write unicast I also mean link local and anycast as well. > >>> You can lookup all IP addresses including multicast by netstat -ia. > >>> A system, which wants to send an IPv6 packet to an IPv6 address at the > >>> same LAN needs the MAC address of the machine, which has the IPv6 address > >>> configured. > >>> Unless it has the address in his neighbor address cache already it > >>> sends an inquiry (Neighbor Discovery ND) to the multicast address - with > >>> IPv4 it was send via broadcast. > >>> It knows the multicast address by using the same formular from the > >>> targeting unicast address as the host owning that address. > >>> This way the inquiry packet won't disturb every host allowing larger LANs. > >>> Some IPv6 unicast addresses share the same multicast, so there are some > >>> collisions, but less than with broadcast. > >>> Multicast however also needs to be transfered using target MAC addresses. > >>> There is a formular which translates an IPv6 multicast address to an > >>> ethernet MAC address, giving more address collisions. > >>> Network interfaces can't filter countless individual MAC addresses, so > >>> there is a filter layer as well, usually containg 64 bits, with each > >>> bit allowing a given set of multicast MAC addresses. > >>> The formular from MAC address to filter bit is hardware dependend, > >>> although most use the plain old NE2000 formular, there are exeptions > >>> with other formular and chips using more bits allowing finer filters. > >>> This point is often done wrong in drivers - some forgot to take care > >>> about multicast bits completely, some use the standard NE2000 filter > >>> with hardware using something different, etc... > >>> > >>> PS: > >>> In the end there are many collisions, only to be avoided by using > >>> multicast aware switches in large LANs and a few multicast addresses. > >>> Therefor also wise to avoid some unicast addresses as they collide > >>> with anyhost or other popular multicast addresses. > >>> > >>> > >>> -- > >>> B.Walter http://www.bwct.de > >>> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > >> > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 16:26:51 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 556DD4F8 for ; Mon, 11 Feb 2013 16:26:51 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2AC9DCF9 for ; Mon, 11 Feb 2013 16:26:50 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1BGQoTE066329 for ; Mon, 11 Feb 2013 09:26:50 -0700 (MST) (envelope-from ian@FreeBSD.org) 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 r1BGQmwP039768; Mon, 11 Feb 2013 09:26:48 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: building RaspPi Images From: Ian Lepore To: Warner Losh In-Reply-To: References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Feb 2013 09:26:47 -0700 Message-ID: <1360600007.4545.98.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm@FreeBSD.org, Brett Wynkoop 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, 11 Feb 2013 16:26:51 -0000 On Mon, 2013-02-11 at 09:10 -0700, Warner Losh wrote: > On Feb 11, 2013, at 9:01 AM, Ian Lepore wrote: > > > On Sun, 2013-02-10 at 00:07 -0700, Warner Losh wrote: > >> On Feb 10, 2013, at 12:03 AM, Tim Kientzle wrote: > >> > >>> On Feb 9, 2013, at 10:20 PM, Brett Wynkoop wrote: > >>>> > >>>> I was thinking that we should be able to generate a generic image that > >>>> will boot on both the Pi and the Bone. Maybe a config file that > >>>> includes the needed drivers for both boards. > >>> > >>> I've thought about this and believe it is pretty routine, > >>> though I've not had time to actually try implementing it. > >>> > >>> This specific combination is simplified by the fact > >>> that the boot bits are so different, so you can just > >>> put them all on the same SD card image. > >>> > >>> There are a few pieces you'll need to work through: > >>> 1. An MSDOS partition with all the boot bits from both systems > >>> 2. A kernel with all of the drivers for both systems > >>> 3. ubldr will need to identify the board somehow > >>> 4. ubldr will need to obtain the correct FDT > >> > >> uboot is supposed to be providing the correct FDT. IF we aren't using it, we're doing FDT wrong and need to fix that. > >> > >>> Except for #3, this should all be entirely routine. > >>> > >>> For #4, the trick is to not compile any DTB into the > >>> kernel. Instead, the DTB is given to the kernel by > >>> the boot bits: > >>> > >>> * For RPi, this already happens: the first-stage boot > >>> loads a DTB, ubldr uses "fdt addr" to access that DTB > >>> in a known location and then passes it to the kernel. > >> > >> Doesn't the RPi's boot loader give our /boot/loader enough info to get this without the fdt addr command? > >> > >>> * For Beaglebone, you can use loader.rc commands to load > >>> the proper DTB from the UFS partition. I'm using the following > >>> on my BeagleBone right now: > >>> /boot/beaglebone.dtb > >>> /boot/loader.rc contains > >>> load /boot/kernel/kernel > >>> load -t dtb /boot/beaglebone.dtb > >>> autoboot > >> > >> why isnt' the beagle board's boot loader passing it to /boot/loader? > >> > >>> This should be an afternoon's work for someone who already > >>> has a good understanding of FreeBSD boot processes. > >> > >> The real solution here is to get the FDT plumbed through from the boards primary boot strap code into our code. Linux requires that this be passed in via like r2 for Linux to boot. We should make use of that too. > >> > >> Warner > > > > I'm seeing an essential conflict here in the mission of FDT data. If > > changing the FDT is the way an end user customizes things like pinmux > > assignments ("I need these pins for gpio, not another uart"), then how > > can we just accept a cannonical hardware description from low-level boot > > code we have no control over? > > If you are going to do crazy things like this, then you supply your own custom FDT. If you use the board in its stock configuration, then you use the thing from the boot loader. If you hack the board, you have to hack the FDT to match... That's a massively unsatisfying answer. It makes sense for something like a DreamPlug that's sold as a consumer unit; the phrase "stock config" makes some sense there. What's the stock configuration of a BeagleBoard? Pretty much every ball on the chip is brought out to one of two headers on the board so that you can use the board for virtually anything you want. I think the basic problem here is a desire to treat u-boot as if it were a PC BIOS, but it lacks some of what a traditional BIOS allows a user to do in terms of configuring optional hardware and storing that config. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 16:58:22 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 B2C43EB6 for ; Mon, 11 Feb 2013 16:58:22 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7978BEC7 for ; Mon, 11 Feb 2013 16:58:22 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id i18so6512705oag.15 for ; Mon, 11 Feb 2013 08:58:16 -0800 (PST) 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=CvXnc34nqAhEJ6kS/IE0w9NJo1swyq5R+bKDs8mUWM4=; b=NV2txnMrWGoWqAhRC7lfMKYhxQ8DQOkEV14HjakSv9zFrsGPYn9Hgp3XWt+FeeL6c7 Mtv8QW557nfScDx5VdNM/6cA0tFu3cPIT96AeHbTpJnFOmAtFCtJWrSBGXWlwt0aRVrj 2Smd1y5G6QRKGLNEqEYgk1yUK7laaI6JKVVCUjtoKCtpAc4QJB+Hgj1rX9Akx3IX1xyz rVN42zRYCcOzP71ZNpSjCGnyYD0hx3jPDCHoJ8kTK93SzeUd0rXqRYZZB6Tv9tsD0Man /xAZe5pxyZmSNPFtxm40kzQnO7TSy7MED/KUtlNEiUrSiVOOHT0qlwm8BW/1Xj0gie2O fF6Q== X-Received: by 10.182.118.103 with SMTP id kl7mr11271492obb.13.1360601896274; Mon, 11 Feb 2013 08:58:16 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id j10sm44323030obg.4.2013.02.11.08.58.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 08:58:14 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1360600007.4545.98.camel@revolution.hippie.lan> Date: Mon, 11 Feb 2013 09:58:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4CCEF987-A506-436C-81FC-91910440507E@bsdimp.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQn+bjD9HUnGgvyGaF/1WgV1Rk6YTiOX1wM2+UGBOXfqipiVtNGMyJMkwsMqXOOV84akUZHm Cc: Tim Kientzle , freebsd-arm@FreeBSD.org, Brett Wynkoop 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, 11 Feb 2013 16:58:22 -0000 On Feb 11, 2013, at 9:26 AM, Ian Lepore wrote: > On Mon, 2013-02-11 at 09:10 -0700, Warner Losh wrote: >> On Feb 11, 2013, at 9:01 AM, Ian Lepore wrote: >>=20 >>> On Sun, 2013-02-10 at 00:07 -0700, Warner Losh wrote: >>>> On Feb 10, 2013, at 12:03 AM, Tim Kientzle wrote: >>>>=20 >>>>> On Feb 9, 2013, at 10:20 PM, Brett Wynkoop wrote: >>>>>>=20 >>>>>> I was thinking that we should be able to generate a generic image = that >>>>>> will boot on both the Pi and the Bone. Maybe a config file that >>>>>> includes the needed drivers for both boards. >>>>>=20 >>>>> I've thought about this and believe it is pretty routine, >>>>> though I've not had time to actually try implementing it. >>>>>=20 >>>>> This specific combination is simplified by the fact >>>>> that the boot bits are so different, so you can just >>>>> put them all on the same SD card image. >>>>>=20 >>>>> There are a few pieces you'll need to work through: >>>>> 1. An MSDOS partition with all the boot bits from both systems >>>>> 2. A kernel with all of the drivers for both systems >>>>> 3. ubldr will need to identify the board somehow >>>>> 4. ubldr will need to obtain the correct FDT >>>>=20 >>>> uboot is supposed to be providing the correct FDT. IF we aren't = using it, we're doing FDT wrong and need to fix that. >>>>=20 >>>>> Except for #3, this should all be entirely routine. >>>>>=20 >>>>> For #4, the trick is to not compile any DTB into the >>>>> kernel. Instead, the DTB is given to the kernel by >>>>> the boot bits: >>>>>=20 >>>>> * For RPi, this already happens: the first-stage boot >>>>> loads a DTB, ubldr uses "fdt addr" to access that DTB >>>>> in a known location and then passes it to the kernel. >>>>=20 >>>> Doesn't the RPi's boot loader give our /boot/loader enough info to = get this without the fdt addr command? >>>>=20 >>>>> * For Beaglebone, you can use loader.rc commands to load >>>>> the proper DTB from the UFS partition. I'm using the following >>>>> on my BeagleBone right now: >>>>> /boot/beaglebone.dtb >>>>> /boot/loader.rc contains >>>>> load /boot/kernel/kernel >>>>> load -t dtb /boot/beaglebone.dtb >>>>> autoboot >>>>=20 >>>> why isnt' the beagle board's boot loader passing it to = /boot/loader? >>>>=20 >>>>> This should be an afternoon's work for someone who already >>>>> has a good understanding of FreeBSD boot processes. >>>>=20 >>>> The real solution here is to get the FDT plumbed through from the = boards primary boot strap code into our code. Linux requires that this = be passed in via like r2 for Linux to boot. We should make use of that = too. >>>>=20 >>>> Warner >>>=20 >>> I'm seeing an essential conflict here in the mission of FDT data. = If >>> changing the FDT is the way an end user customizes things like = pinmux >>> assignments ("I need these pins for gpio, not another uart"), then = how >>> can we just accept a cannonical hardware description from low-level = boot >>> code we have no control over? >>=20 >> If you are going to do crazy things like this, then you supply your = own custom FDT. If you use the board in its stock configuration, then = you use the thing from the boot loader. If you hack the board, you have = to hack the FDT to match... >=20 > That's a massively unsatisfying answer. It makes sense for something > like a DreamPlug that's sold as a consumer unit; the phrase "stock > config" makes some sense there. I don't see how this is an unsatisfying answer. If there's a FDT from = the BIOS, we use it by default. If the user wants to change things on = the board, they need to provide a custom FDT to match their changes. > What's the stock configuration of a BeagleBoard? Pretty much every = ball > on the chip is brought out to one of two headers on the board so that > you can use the board for virtually anything you want. You CAN use it however you want, true. However, there are some defaults = that the default BIOS provides and if you want to change the defaults, = you have to change the defaults. The way to you do that is via a custom = FDT. > I think the basic problem here is a desire to treat u-boot as if it = were > a PC BIOS, but it lacks some of what a traditional BIOS allows a user = to > do in terms of configuring optional hardware and storing that config If you do customization, you have to have a custom FDT. There's no = getting around that. This is standard issue in the Linux world, and = should be standard issue in FreeBSD as well. We have to start converging = on interfaces that allow extensibility, and FDT is one such interface. But that's no different than what we have today, except *EVERYTHING* is = custom today. My position is that, by default, we use the FDT that the = BIOS provides, and if the user wants to do custom things, they do what = the do in Linux and load a custom FDT/DTB to describe those custom = things. My main two points: (1) We should really try harder to use the FDT from = the board and (2) We should avoid mechanisms outside of FDT to make it = "easy" since those mechanisms likely will make it harder. Warner= From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 17:03: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 C67C4120 for ; Mon, 11 Feb 2013 17:03:25 +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 A7781F16 for ; Mon, 11 Feb 2013 17:03:25 +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 E04DD208F5 for ; Mon, 11 Feb 2013 17:03:23 +0000 (UTC) Message-ID: <5119245A.5070704@g7iii.net> Date: Mon, 11 Feb 2013 17:03:22 +0000 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: building RaspPi Images References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> In-Reply-To: <1360600007.4545.98.camel@revolution.hippie.lan> 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, 11 Feb 2013 17:03:25 -0000 On 11/02/13 16:26, Ian Lepore wrote: > On Mon, 2013-02-11 at 09:10 -0700, Warner Losh wrote: [SNIP] >>>> The real solution here is to get the FDT plumbed through from the boards primary boot strap code into our code. Linux requires that this be passed in via like r2 for Linux to boot. We should make use of that too. >>>> >>>> Warner >>> >>> I'm seeing an essential conflict here in the mission of FDT data. If >>> changing the FDT is the way an end user customizes things like pinmux >>> assignments ("I need these pins for gpio, not another uart"), then how >>> can we just accept a cannonical hardware description from low-level boot >>> code we have no control over? >> >> If you are going to do crazy things like this, then you supply your own custom FDT. If you use the board in its stock configuration, then you use the thing from the boot loader. If you hack the board, you have to hack the FDT to match... > > That's a massively unsatisfying answer. It makes sense for something > like a DreamPlug that's sold as a consumer unit; the phrase "stock > config" makes some sense there. > > What's the stock configuration of a BeagleBoard? Pretty much every ball > on the chip is brought out to one of two headers on the board so that > you can use the board for virtually anything you want. Note: Linux also allows you to change the pinmux stuff once you've booted (It brings them up with their "default" mux setting, then you can change it by poking around in /sys/kernel/debug/omap_max) For example, to enable UART3_CTS on pin 36 of P8, you do: echo 26 >/sys/kernel/debug/omap_mux/lcd_data10 I'm not aware FreeBSD has any such mechanism at present. Iain (who's svn co of /usr/src has finally finished, and will now start buildworld and buildkernel after that before testing his patch to enable UARTS1-4) From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 17:14:51 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 4A582207; Mon, 11 Feb 2013 17:14:51 +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 1DFEAF61; Mon, 11 Feb 2013 17:14:50 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1BHEmjm014677; Mon, 11 Feb 2013 17:14:48 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id qb75kq8azscbrhewn2b22pihhn; Mon, 11 Feb 2013 17:14:48 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <1360600007.4545.98.camel@revolution.hippie.lan> Date: Mon, 11 Feb 2013 09:14:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org, Brett Wynkoop 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, 11 Feb 2013 17:14:51 -0000 >>> I'm seeing an essential conflict here in the mission of FDT data. = If >>> changing the FDT is the way an end user customizes things like = pinmux >>> assignments ("I need these pins for gpio, not another uart"), then = how >>> can we just accept a cannonical hardware description from low-level = boot >>> code we have no control over? Here are several answers: 1) The immediate result of this change will make it *easier* to change the FDT. Right now, most people are recompiling the kernel just to tweak the FDT. This change moves it out into a separate standalone file in the boot partition. (You still need to compile the DTS, but you can at least change it and reboot without touching the kernel.) 2) We're still debating the role of the FDT vis a vis end user customization. Personally, I would like to find some more dynamic approach to handling pinmux at runtime. (E.g., if you want to use a pin for gpio, you do this: $ gpioctl 1 7 out # Set gpio 1 7 for output, including pinmux = change $ gpioctl 1 7 on Similarly, I think that enabling uart2 should automatically adjust the pinmux appropriately. 3) IIUC, the FDT concept came from the PowerPC world, where the FDT is provided by the ROM. It's not really a tool for customizing the system; it's a tool for describing the hardware available. 4) Ubldr already has tools for adjusting the FDT dynamically at boot time. I just committed the online help for this "help fdt". So you can indeed adjust the FDT via loader.rc. That works today, even when the FDT is compiled into the kernel. >> If you are going to do crazy things like this, then you supply your = own custom FDT. If you use the board in its stock configuration, then = you use the thing from the boot loader. If you hack the board, you have = to hack the FDT to match... >=20 > That's a massively unsatisfying answer. It makes sense for something > like a DreamPlug that's sold as a consumer unit; the phrase "stock > config" makes some sense there. >=20 > What's the stock configuration of a BeagleBoard? Pretty much every = ball > on the chip is brought out to one of two headers on the board so that > you can use the board for virtually anything you want. > I think the basic problem here is a desire to treat u-boot as if it = were > a PC BIOS, but it lacks some of what a traditional BIOS allows a user = to > do in terms of configuring optional hardware and storing that config. Right now, we're using U-Boot for exactly two things: * Boot loader driver. Rather than writing board-specific drivers for ubldr for every board, we get to leverage U-Boot. * Providing the *default* FDT. The code I circulated yesterday uses the following logic to find the FDT: 1) If an FDT was loaded into ubldr, use that. (E.g., "load -t dtb = filename") 2) If U-Boot provided an FDT, use that. 3) If the kernel has a compiled-in FDT, use that. Tim From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 17:18:42 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 36869308 for ; Mon, 11 Feb 2013 17:18:42 +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 F1EDAF8F for ; Mon, 11 Feb 2013 17:18:41 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1BHIflD014695 for freebsd-arm@freebsd.org; Mon, 11 Feb 2013 17:18:41 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id x7ema79rmg7m34jsvbc65p927w; for freebsd-arm@freebsd.org; Mon, 11 Feb 2013 17:18:41 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: multipart/signed; boundary="Apple-Mail=_16DC8A02-6F4C-4C56-988B-00715C64E3A7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Build failure in libclang for ARM. Date: Mon, 11 Feb 2013 09:18:40 -0800 Message-Id: <53ED3A94-E4DD-441D-9E2C-46E23C21F8D1@freebsd.org> 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, 11 Feb 2013 17:18:42 -0000 --Apple-Mail=_16DC8A02-6F4C-4C56-988B-00715C64E3A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Been seeing this for a couple of days now. First with native ARM-on-ARM builds, and now with cross ARM-on-x86 builds. FWIW, my /etc/make.conf and /etc/src.conf are both empty. c++ -O -pipe = -I/usr/src/lib/clang/libclangsema/../../../contrib/llvm/include = -I/usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/includ= e = -I/usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Se= ma -I. = -I/usr/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/in= clude -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS -fno-strict-aliasing = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv6-unknown-freebsd10.0\" = -DLLVM_HOSTTRIPLE=3D\"armv6-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=3D\"\"= -fno-exceptions -fno-rtti -c = /usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema= /SemaTemplateInstantiateDecl.cpp -o SemaTemplateInstantiateDecl.o {standard input}: Assembler messages: {standard input}:48382: Warning: end of file not at end of a line; = newline inserted {standard input}:49458: Error: ARM register expected -- `mov' c++: Internal error: Killed (program cc1plus) Please submit a full bug report. See for instructions. *** [SemaTemplate.o] Error code 1 1 error *** [all] Error code 2 1 error *** [all] Error code 2 --Apple-Mail=_16DC8A02-6F4C-4C56-988B-00715C64E3A7 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) iQEcBAEBAgAGBQJRGSfxAAoJEGMNyGo0rfFByJ8IANaQFfEbIeSPEjO1naLZy/Xl Fjmv8qeekVvKf1w9Q3+RsxGtkhWK4MaLXbdQRpWPOS8KCG3hJSNNJQon34jEK4SG WIYycoHO0qCNTWxthBP0sNcNxReUtI56Py67HsnjDsdsQri3M8Jvto4at9BkYjlA ANMeurabB3ulGj1SHSPGU8WwG43x4sIjCM3accLo/AFFT8kyCoeeSpkWfvUxdluf 8CaeY7Qjny+akh030S06KWYyuIt2a4B429W1eGXrxIUMIni/xgjwd0izdpNYQs30 EVehNsP1Pk8e0FClI7qtMOxZHUynp5dzcSMYmzbmJd3CTq4KJJnTTiZvYSQtTe8= =PZMv -----END PGP SIGNATURE----- --Apple-Mail=_16DC8A02-6F4C-4C56-988B-00715C64E3A7-- From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 17:37:12 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 DA21E62B; Mon, 11 Feb 2013 17:37:12 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by mx1.freebsd.org (Postfix) with ESMTP id A137FDE; Mon, 11 Feb 2013 17:37:12 +0000 (UTC) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 5CD4F460175; Mon, 11 Feb 2013 11:37:11 -0600 (CST) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 5AB94460150; Mon, 11 Feb 2013 11:37:11 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from mh1.mail.rice.edu ([127.0.0.1]) by mh1.mail.rice.edu (mh1.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id TX7wFK2AnCZI; Mon, 11 Feb 2013 11:37:11 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id BEB1A460110; Mon, 11 Feb 2013 11:37:10 -0600 (CST) Message-ID: <51192C44.1060204@rice.edu> Date: Mon, 11 Feb 2013 11:37:08 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130127 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ian Lepore Subject: kernel address space & auto-tuning Content-Type: multipart/mixed; boundary="------------080206050506000802050208" Cc: "arm@freebsd.org" , Kostik Belousov , Alan Cox 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, 11 Feb 2013 17:37:12 -0000 This is a multi-part message in MIME format. --------------080206050506000802050208 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ian and others here, Could you please test the attached patch? However, before you apply this patch, can you run sysctl vm.max_kernel_address and record the output. I'd like to know how this output changes after the patch is applied. Here is an explanation of what the patch does: 1. Recently, a #define for VM_KMEM_SIZE_SCALE was added to arm/include/vmparam.h. This is good. However, it will create a problem as soon as someone gets arm hardware with more than ~1.5GB of RAM. This patch introduces a cap on the size of the kmem submap so that booting on future larger-memory systems won't fail. 2. It appears that arm is more like sparc64 than x86 in the respect that the ending address of the kernel address space can vary from machine to machine. To be more precise, I'm talking about the kernel address space into which we can dynamically map and unmap code/data and I'm not including regions for device access or direct maps. Thus, the current #define for VM_MAX_KERNEL_ADDRESS on arm is really incorrect or at least inconsistent with how this is defined on other architectures. This patch borrows from sparc64 in defining a global variable, vm_max_kernel_address, rather than a constant #define to represent the end of the kernel address space. Thanks, Alan --------------080206050506000802050208 Content-Type: text/plain; charset=ISO-8859-15; name="arm_kmem1.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arm_kmem1.patch" Index: arm/arm/machdep.c =================================================================== --- arm/arm/machdep.c (revision 246628) +++ arm/arm/machdep.c (working copy) @@ -1178,7 +1178,6 @@ initarm(struct arm_boot_params *abp) struct pv_addr kernel_l1pt; struct pv_addr dpcpu; vm_offset_t dtbp, freemempos, l2_start, lastaddr; - vm_offset_t pmap_bootstrap_lastaddr; uint32_t memsize, l2size; char *env; void *kmdp; @@ -1288,7 +1287,7 @@ initarm(struct arm_boot_params *abp) availmem_regions_sz = curr; /* Platform-specific initialisation */ - pmap_bootstrap_lastaddr = initarm_lastaddr(); + vm_max_kernel_address = initarm_lastaddr(); pcpu0_init(); @@ -1477,7 +1476,7 @@ initarm(struct arm_boot_params *abp) arm_intrnames_init(); arm_vector_init(ARM_VECTORS_HIGH, ARM_VEC_ALL); arm_dump_avail_init(memsize, sizeof(dump_avail) / sizeof(dump_avail[0])); - pmap_bootstrap(freemempos, pmap_bootstrap_lastaddr, &kernel_l1pt); + pmap_bootstrap(freemempos, vm_max_kernel_address, &kernel_l1pt); msgbufp = (void *)msgbufpv.pv_va; msgbufinit(msgbufp, msgbufsize); mutex_init(); Index: arm/arm/pmap-v6.c =================================================================== --- arm/arm/pmap-v6.c (revision 246628) +++ arm/arm/pmap-v6.c (working copy) @@ -231,6 +231,8 @@ vm_paddr_t kernel_l1pa; vm_offset_t kernel_vm_end = 0; +vm_offset_t vm_max_kernel_address; + struct pmap kernel_pmap_store; static pt_entry_t *csrc_pte, *cdst_pte; Index: arm/arm/pmap.c =================================================================== --- arm/arm/pmap.c (revision 246628) +++ arm/arm/pmap.c (working copy) @@ -220,6 +220,8 @@ vm_paddr_t kernel_l1pa; vm_offset_t kernel_vm_end = 0; +vm_offset_t vm_max_kernel_address; + struct pmap kernel_pmap_store; static pt_entry_t *csrc_pte, *cdst_pte; Index: arm/include/vmparam.h =================================================================== --- arm/include/vmparam.h (revision 246628) +++ arm/include/vmparam.h (working copy) @@ -133,7 +133,7 @@ #define VM_MIN_KERNEL_ADDRESS KERNBASE #endif -#define VM_MAX_KERNEL_ADDRESS 0xffffffff +#define VM_MAX_KERNEL_ADDRESS (vm_max_kernel_address) /* * Virtual size (bytes) for various kernel submaps. @@ -145,6 +145,14 @@ #define VM_KMEM_SIZE_SCALE (2) #endif +/* + * Ceiling on the size of the kmem submap: 60% of the kernel map. + */ +#ifndef VM_KMEM_SIZE_MAX +#define VM_KMEM_SIZE_MAX ((vm_max_kernel_address - \ + VM_MIN_KERNEL_ADDRESS + 1) * 3 / 5) +#endif + #define MAXTSIZ (16*1024*1024) #ifndef DFLDSIZ #define DFLDSIZ (128*1024*1024) @@ -166,6 +174,8 @@ #define UMA_MD_SMALL_ALLOC #endif /* ARM_USE_SMALL_ALLOC */ +extern vm_offset_t vm_max_kernel_address; + #define ZERO_REGION_SIZE (64 * 1024) /* 64KB */ #endif /* _MACHINE_VMPARAM_H_ */ Index: vm/vm_kern.c =================================================================== --- vm/vm_kern.c (revision 246628) +++ vm/vm_kern.c (working copy) @@ -98,7 +98,7 @@ SYSCTL_ULONG(_vm, OID_AUTO, min_kernel_address, CT NULL, VM_MIN_KERNEL_ADDRESS, "Min kernel address"); SYSCTL_ULONG(_vm, OID_AUTO, max_kernel_address, CTLFLAG_RD, -#ifdef __sparc64__ +#if defined(__arm__) || defined(__sparc64__) &vm_max_kernel_address, 0, #else NULL, VM_MAX_KERNEL_ADDRESS, --------------080206050506000802050208-- From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 17:42:45 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 3553469C for ; Mon, 11 Feb 2013 17:42:45 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id ED77B101 for ; Mon, 11 Feb 2013 17:42:44 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1BHghdI067273 for ; Mon, 11 Feb 2013 10:42:44 -0700 (MST) (envelope-from ian@FreeBSD.org) 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 r1BHgfAC039827; Mon, 11 Feb 2013 10:42:41 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: building RaspPi Images From: Ian Lepore To: Tim Kientzle In-Reply-To: <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Feb 2013 10:42:41 -0700 Message-ID: <1360604561.4545.115.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, Brett Wynkoop 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, 11 Feb 2013 17:42:45 -0000 On Mon, 2013-02-11 at 09:14 -0800, Tim Kientzle wrote: > >>> I'm seeing an essential conflict here in the mission of FDT data. If > >>> changing the FDT is the way an end user customizes things like pinmux > >>> assignments ("I need these pins for gpio, not another uart"), then how > >>> can we just accept a cannonical hardware description from low-level boot > >>> code we have no control over? > > Here are several answers: > > 1) The immediate result of this change will make > it *easier* to change the FDT. Right now, most people > are recompiling the kernel just to tweak the FDT. > This change moves it out into a separate standalone > file in the boot partition. (You still need to compile > the DTS, but you can at least change it and reboot > without touching the kernel.) > I actually find it much easier to recompile the kernel than any of the other alternatives I've run into, but I understand that an end user would see it differently. I also find that while I'm trying to be open-minded about fdt in general, I still find it much more cumbersome to work with than the old hints system. The very fact that you need a special compiler to change the fdt data is part of that. In general, the fdt data seems to be good at describing hardware relationships that are hard to express with simple hints, such as how pins that generate interrupts are mapped between various devices and interrupt controllers. But it seems to be hard to use when the nature of the customizations are simple choices. > 2) We're still debating the role of the FDT vis a vis > end user customization. Personally, I would like > to find some more dynamic approach to handling > pinmux at runtime. (E.g., if you want to use a pin > for gpio, you do this: > $ gpioctl 1 7 out # Set gpio 1 7 for output, including pinmux change > $ gpioctl 1 7 on > Similarly, I think that enabling uart2 should automatically > adjust the pinmux appropriately. > I whole-heartedly agree with that last sentence, but it's about a zillion miles from where our code is now. I'm not even sure it's fully possible, it just seems like a nice generic ideal "I asked for a uart, so the uart driver should enable power, enable clocks, and assign pins to make that happen." The problem crops up when "assign pins" has several sets of pins to choose from for a given device, and I know at least the Atmel SoCs do this a lot. > 3) IIUC, the FDT concept came from the PowerPC > world, where the FDT is provided by the ROM. > It's not really a tool for customizing the system; it's a tool > for describing the hardware available. > > 4) Ubldr already has tools for adjusting the FDT > dynamically at boot time. I just committed the > online help for this "help fdt". So you can indeed > adjust the FDT via loader.rc. That works today, even > when the FDT is compiled into the kernel. > I'll look into this, although when I was playing with it a couple weeks ago, I was having a hard time doing *anything* with loader.rc at all. That got me involved in trying to get the forth code running so that we'd have the full btx-loader goodness in the arm world with loader.conf files that we're all familiar with already. That was going pretty well except for our kernels not having proper elf headers, and I started to sidetrack to fix that, and then $work happened and I haven't gotten back to any of it yet. -- Ian > >> If you are going to do crazy things like this, then you supply your own custom FDT. If you use the board in its stock configuration, then you use the thing from the boot loader. If you hack the board, you have to hack the FDT to match... > > > > That's a massively unsatisfying answer. It makes sense for something > > like a DreamPlug that's sold as a consumer unit; the phrase "stock > > config" makes some sense there. > > > > What's the stock configuration of a BeagleBoard? Pretty much every ball > > on the chip is brought out to one of two headers on the board so that > > you can use the board for virtually anything you want. > > > I think the basic problem here is a desire to treat u-boot as if it were > > a PC BIOS, but it lacks some of what a traditional BIOS allows a user to > > do in terms of configuring optional hardware and storing that config. > > Right now, we're using U-Boot for exactly two things: > * Boot loader driver. Rather than writing board-specific > drivers for ubldr for every board, we get to leverage U-Boot. > * Providing the *default* FDT. > > The code I circulated yesterday uses the following logic to find > the FDT: > 1) If an FDT was loaded into ubldr, use that. (E.g., "load -t dtb filename") > 2) If U-Boot provided an FDT, use that. > 3) If the kernel has a compiled-in FDT, use that. From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 18:01: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 428E592B for ; Mon, 11 Feb 2013 18:01:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by mx1.freebsd.org (Postfix) with ESMTP id E9D5C1B5 for ; Mon, 11 Feb 2013 18:01:27 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id wc18so6416894obb.36 for ; Mon, 11 Feb 2013 10:01:27 -0800 (PST) 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=Gdx68cN2hZ5WNkGWe/Arv93VU30+lvX7rLv+RWcRjOo=; b=jG8Vl1PSwHFxceSfnHAYzVn1yIiKpNwvhTuCsM943ElQIrIrMT4BgwBtu0JMPH2kBR NwrpQkT3DSYrnm1/ah7n5Nb7eEzlYKbbk0IpSmza89O7taINjgObn4V94ziTrfgO6miy wwB3J8d5FaLwLLhNFIsOA8PXXLibZBHD5zHe6DbUOlcIkPTxjvDv6vn3GVP81SUs84Er S42mZYqLIDv41hZbBy2EGnDw75Vaibr80YVuPUa/lpXSeVe4qrK/M408hrW3BR1cVMUh 1TxUE1po+iVFp9XmV0osyBaX6SkCWvj/OYU6mOJy75H09rxt5fm9GFIpbd4+QxMmZxte lxbw== X-Received: by 10.60.26.137 with SMTP id l9mr11395706oeg.17.1360605686922; Mon, 11 Feb 2013 10:01:26 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id v8sm49771186obj.1.2013.02.11.10.01.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 10:01:25 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <5119245A.5070704@g7iii.net> Date: Mon, 11 Feb 2013 11:01:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <21D847EF-A61F-4612-A301-D2FC1D3AFAB1@bsdimp.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> <5119245A.5070704@g7iii.net> To: Iain Young X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQn7lomCTUfQrxiMtP+4JjTeoli8uG5u+cmW5jlAsAUg3V5SVUFqBakV8fn2drcUYYMtHwdg 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, 11 Feb 2013 18:01:28 -0000 On Feb 11, 2013, at 10:03 AM, Iain Young wrote: > On 11/02/13 16:26, Ian Lepore wrote: >> On Mon, 2013-02-11 at 09:10 -0700, Warner Losh wrote: >=20 > [SNIP] >=20 >>>>> The real solution here is to get the FDT plumbed through from the = boards primary boot strap code into our code. Linux requires that this = be passed in via like r2 for Linux to boot. We should make use of that = too. >>>>>=20 >>>>> Warner >>>>=20 >>>> I'm seeing an essential conflict here in the mission of FDT data. = If >>>> changing the FDT is the way an end user customizes things like = pinmux >>>> assignments ("I need these pins for gpio, not another uart"), then = how >>>> can we just accept a cannonical hardware description from low-level = boot >>>> code we have no control over? >>>=20 >>> If you are going to do crazy things like this, then you supply your = own custom FDT. If you use the board in its stock configuration, then = you use the thing from the boot loader. If you hack the board, you have = to hack the FDT to match... >>=20 >> That's a massively unsatisfying answer. It makes sense for something >> like a DreamPlug that's sold as a consumer unit; the phrase "stock >> config" makes some sense there. >>=20 >> What's the stock configuration of a BeagleBoard? Pretty much every = ball >> on the chip is brought out to one of two headers on the board so that >> you can use the board for virtually anything you want. >=20 > Note: Linux also allows you to change the pinmux stuff once you've > booted (It brings them up with their "default" mux setting, then you > can change it by poking around in /sys/kernel/debug/omap_max) >=20 > For example, to enable UART3_CTS on pin 36 of P8, you do: >=20 > echo 26 >/sys/kernel/debug/omap_mux/lcd_data10 >=20 > I'm not aware FreeBSD has any such mechanism at present. Yea, we're late to the pinmux/pinctl/gpio party here :( Warner= From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 18:05: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 EB17A99B for ; Mon, 11 Feb 2013 18:05:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by mx1.freebsd.org (Postfix) with ESMTP id B462B1D8 for ; Mon, 11 Feb 2013 18:05:01 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id 16so6372959obc.33 for ; Mon, 11 Feb 2013 10:04:54 -0800 (PST) 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=M4PJGqpRvM2lYaEJto3BN24ugqY9bDCoxDlOuVvVYIk=; b=bjMfHjDZoxiY7zTo/Jncl7P5DzJnJjIKPlBYxzR/oIXGmu5Z9QeV1vJyonw3xmvlw3 Z4XYktfVb8LyUMNihwMcCsffaSOfpyUE6HI6ibz9hbaDUHVi4XE3NIUfmanifp105Tyx rnCM2jOqkSpCGzRmk/+WVavdcrLlzjFn9EhA3jOawJhzC9GtrP4rl0EqIAxGsw8NpITo 4l9usC7tHrPFcbtlhW1xC2pKH6/fVpNfrCsrZYE+qyQhsgz28LKTyZbg98yxp+g2+aDJ f2WpMFaao4RH2QaUajGB0zc6GL1qLaIEvdJg/6W/seAMu1IczXtseteSrpNmTIolLOsI 6s0g== X-Received: by 10.60.4.35 with SMTP id h3mr11478634oeh.123.1360605894885; Mon, 11 Feb 2013 10:04:54 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id v2sm49759048obl.10.2013.02.11.10.04.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 10:04:53 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> Date: Mon, 11 Feb 2013 11:04:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <780B5A66-2727-4E16-B912-93AAD7FDE21B@bsdimp.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlim5fi265UD3S907XmqogrA7Q2Rj0IC4Y6WxsuV7wCACc/Ct2s/fFLwzhdUpaJT94J2XV5 Cc: freebsd-arm@freebsd.org, Brett Wynkoop , Ian Lepore 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, 11 Feb 2013 18:05:02 -0000 On Feb 11, 2013, at 10:14 AM, Tim Kientzle wrote: >>>> I'm seeing an essential conflict here in the mission of FDT data. = If >>>> changing the FDT is the way an end user customizes things like = pinmux >>>> assignments ("I need these pins for gpio, not another uart"), then = how >>>> can we just accept a cannonical hardware description from low-level = boot >>>> code we have no control over? >=20 > Here are several answers: >=20 > 1) The immediate result of this change will make > it *easier* to change the FDT. Right now, most people > are recompiling the kernel just to tweak the FDT. > This change moves it out into a separate standalone > file in the boot partition. (You still need to compile > the DTS, but you can at least change it and reboot > without touching the kernel.) This is good. > 2) We're still debating the role of the FDT vis a vis > end user customization. Personally, I would like > to find some more dynamic approach to handling > pinmux at runtime. (E.g., if you want to use a pin > for gpio, you do this: > $ gpioctl 1 7 out # Set gpio 1 7 for output, including pinmux = change > $ gpioctl 1 7 on > Similarly, I think that enabling uart2 should automatically > adjust the pinmux appropriately. These are also good, but we have a long ways to go in the kernel to get = there. And there are limits to how far you can push this envelope. However, enabling uart2 is also done through the FDT, at least in linux, = but it takes care of these pesky details for the most part. > 3) IIUC, the FDT concept came from the PowerPC > world, where the FDT is provided by the ROM. > It's not really a tool for customizing the system; it's a tool > for describing the hardware available. It is a tool to describe how the hardware is configured as well. It is = the only place where you can find how things are wired together. That's = its primary purpose. If you are customizing your hardware, you are = wiring it together differently. > 4) Ubldr already has tools for adjusting the FDT > dynamically at boot time. I just committed the > online help for this "help fdt". So you can indeed > adjust the FDT via loader.rc. That works today, even > when the FDT is compiled into the kernel. >=20 >>> If you are going to do crazy things like this, then you supply your = own custom FDT. If you use the board in its stock configuration, then = you use the thing from the boot loader. If you hack the board, you have = to hack the FDT to match... >>=20 >> That's a massively unsatisfying answer. It makes sense for something >> like a DreamPlug that's sold as a consumer unit; the phrase "stock >> config" makes some sense there. >>=20 >> What's the stock configuration of a BeagleBoard? Pretty much every = ball >> on the chip is brought out to one of two headers on the board so that >> you can use the board for virtually anything you want. >=20 >> I think the basic problem here is a desire to treat u-boot as if it = were >> a PC BIOS, but it lacks some of what a traditional BIOS allows a user = to >> do in terms of configuring optional hardware and storing that config. >=20 > Right now, we're using U-Boot for exactly two things: > * Boot loader driver. Rather than writing board-specific > drivers for ubldr for every board, we get to leverage U-Boot. > * Providing the *default* FDT. >=20 > The code I circulated yesterday uses the following logic to find > the FDT: > 1) If an FDT was loaded into ubldr, use that. (E.g., "load -t dtb = filename") > 2) If U-Boot provided an FDT, use that. > 3) If the kernel has a compiled-in FDT, use that. Yes, I like that. Warner= From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 18:08: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 A5343C08 for ; Mon, 11 Feb 2013 18:08:20 +0000 (UTC) (envelope-from imp@bsdimp.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 6CE3A227 for ; Mon, 11 Feb 2013 18:08:20 +0000 (UTC) Received: by mail-oa0-f47.google.com with SMTP id o17so6639771oag.34 for ; Mon, 11 Feb 2013 10:08:19 -0800 (PST) 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=+QgswuJN1Xx34rLCI/ZpHNEAwBK8iqVhG8EmeoyVEYc=; b=EXn3EDZYwkTzE7IcZVq5/Hli1NDKoBNHx17LhmRha4ojy3WWKd+BSAR+xfTU+E56gi 6gVJnNoGIVGaQ9xTsACZYweNEvqVi6JXp1TLNz9whpTqVQpO4a0qZ2ARqNR1X9PJn3/+ 9EgihH9rXQLZffTdQFzG8Pvrb/HddIj+qcby2L0ah/5XvbuNmGvgYADRWjK6rwZNpaAl 0Lsr/CkcvJMHJaUsAJuWCd4uUVKFE+GRunYWP9Y5rxh7BMLB1LJzdHLNsufmxJwdL5J4 BztPWetFaCWGkCJa2yT68VxEmIMh7kZ7naaM/T7aty0bcuZ3vTu95i7uMfaTMXiTRAKP 4Luw== X-Received: by 10.60.32.143 with SMTP id j15mr11168722oei.7.1360606099585; Mon, 11 Feb 2013 10:08:19 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id d17sm49798797obu.0.2013.02.11.10.08.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 10:08:18 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1360604561.4545.115.camel@revolution.hippie.lan> Date: Mon, 11 Feb 2013 11:08:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <82E702D7-3099-4D23-B233-A19F85FE4118@bsdimp.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> <1360604561.4545.115.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmFO4pAeFl4gLQpZ1a/tpGpgYW4wC65O5nCT1R1NPQg03ZZIFMm7xNb58pBn8LVDO7ELaf6 Cc: Tim Kientzle , freebsd-arm@FreeBSD.org, Brett Wynkoop 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, 11 Feb 2013 18:08:20 -0000 On Feb 11, 2013, at 10:42 AM, Ian Lepore wrote: > On Mon, 2013-02-11 at 09:14 -0800, Tim Kientzle wrote: >>>>> I'm seeing an essential conflict here in the mission of FDT data. = If >>>>> changing the FDT is the way an end user customizes things like = pinmux >>>>> assignments ("I need these pins for gpio, not another uart"), then = how >>>>> can we just accept a cannonical hardware description from = low-level boot >>>>> code we have no control over? >>=20 >> Here are several answers: >>=20 >> 1) The immediate result of this change will make >> it *easier* to change the FDT. Right now, most people >> are recompiling the kernel just to tweak the FDT. >> This change moves it out into a separate standalone >> file in the boot partition. (You still need to compile >> the DTS, but you can at least change it and reboot >> without touching the kernel.) >>=20 >=20 > I actually find it much easier to recompile the kernel than any of the > other alternatives I've run into, but I understand that an end user > would see it differently. I also find that while I'm trying to be > open-minded about fdt in general, I still find it much more cumbersome > to work with than the old hints system. The very fact that you need a > special compiler to change the fdt data is part of that. >=20 > In general, the fdt data seems to be good at describing hardware > relationships that are hard to express with simple hints, such as how > pins that generate interrupts are mapped between various devices and > interrupt controllers. But it seems to be hard to use when the nature > of the customizations are simple choices. Indeed. >> 2) We're still debating the role of the FDT vis a vis >> end user customization. Personally, I would like >> to find some more dynamic approach to handling >> pinmux at runtime. (E.g., if you want to use a pin >> for gpio, you do this: >> $ gpioctl 1 7 out # Set gpio 1 7 for output, including pinmux = change >> $ gpioctl 1 7 on >> Similarly, I think that enabling uart2 should automatically >> adjust the pinmux appropriately. >>=20 >=20 > I whole-heartedly agree with that last sentence, but it's about a > zillion miles from where our code is now. I'm not even sure it's = fully > possible, it just seems like a nice generic ideal "I asked for a uart, > so the uart driver should enable power, enable clocks, and assign pins > to make that happen." The problem crops up when "assign pins" has > several sets of pins to choose from for a given device, and I know at > least the Atmel SoCs do this a lot. In Linux land, at least for Atmel, they have created pin groups that are = switched together when things like the uarts are enabled. It looks to be = pretty slick, but I haven't seen it in its final form. We can do it mostly by default, with the special cases being handled = specially. >> 3) IIUC, the FDT concept came from the PowerPC >> world, where the FDT is provided by the ROM. >> It's not really a tool for customizing the system; it's a tool >> for describing the hardware available. >>=20 >> 4) Ubldr already has tools for adjusting the FDT >> dynamically at boot time. I just committed the >> online help for this "help fdt". So you can indeed >> adjust the FDT via loader.rc. That works today, even >> when the FDT is compiled into the kernel. >>=20 >=20 > I'll look into this, although when I was playing with it a couple = weeks > ago, I was having a hard time doing *anything* with loader.rc at all.=20= >=20 > That got me involved in trying to get the forth code running so that > we'd have the full btx-loader goodness in the arm world with = loader.conf > files that we're all familiar with already. That was going pretty = well > except for our kernels not having proper elf headers, and I started to > sidetrack to fix that, and then $work happened and I haven't gotten = back > to any of it yet. I hate it when $work happens... Warner > -- Ian >=20 >>>> If you are going to do crazy things like this, then you supply your = own custom FDT. If you use the board in its stock configuration, then = you use the thing from the boot loader. If you hack the board, you have = to hack the FDT to match... >>>=20 >>> That's a massively unsatisfying answer. It makes sense for = something >>> like a DreamPlug that's sold as a consumer unit; the phrase "stock >>> config" makes some sense there. >>>=20 >>> What's the stock configuration of a BeagleBoard? Pretty much every = ball >>> on the chip is brought out to one of two headers on the board so = that >>> you can use the board for virtually anything you want. >>=20 >>> I think the basic problem here is a desire to treat u-boot as if it = were >>> a PC BIOS, but it lacks some of what a traditional BIOS allows a = user to >>> do in terms of configuring optional hardware and storing that = config. >>=20 >> Right now, we're using U-Boot for exactly two things: >> * Boot loader driver. Rather than writing board-specific >> drivers for ubldr for every board, we get to leverage U-Boot. >> * Providing the *default* FDT. >>=20 >> The code I circulated yesterday uses the following logic to find >> the FDT: >> 1) If an FDT was loaded into ubldr, use that. (E.g., "load -t dtb = filename") >> 2) If U-Boot provided an FDT, use that. >> 3) If the kernel has a compiled-in FDT, use that. >=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" From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 18:08:34 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 4FA5CC43; Mon, 11 Feb 2013 18:08:34 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 166DE22F; Mon, 11 Feb 2013 18:08:33 +0000 (UTC) Received: from ivory.local (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1BI8Wkq013424; Mon, 11 Feb 2013 13:08:32 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Mon, 11 Feb 2013 13:08:22 -0500 From: Brett Wynkoop To: Tim Kientzle Subject: Re: Build failure in libclang for ARM. Message-ID: <20130211130822.20b41712@ivory.local> In-Reply-To: <53ED3A94-E4DD-441D-9E2C-46E23C21F8D1@freebsd.org> References: <53ED3A94-E4DD-441D-9E2C-46E23C21F8D1@freebsd.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/8q4h03d6CiVnXPSyAlkpJ/."; protocol="application/pgp-signature" 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, 11 Feb 2013 18:08:34 -0000 --Sig_/8q4h03d6CiVnXPSyAlkpJ/. Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 11 Feb 2013 09:18:40 -0800 Tim Kientzle wrote: > Been seeing this for a couple of days now. First with > native ARM-on-ARM builds, and now with cross ARM-on-x86 builds. > FWIW, my /etc/make.conf and /etc/src.conf are both empty. >=20 > c++ -O -pipe > -I/usr/src/lib/clang/libclangsema/../../../contrib/llvm/include > -I/usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/inclu= de > -I/usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/S= ema > -I. > -I/usr/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/i= nclude > -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS > -D__STDC_CONSTANT_MACROS -fno-strict-aliasing > -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv6-unknown-freebsd10.0\" > -DLLVM_HOSTTRIPLE=3D\"armv6-unknown-freebsd10.0\" > -DDEFAULT_SYSROOT=3D\"\" -fno-exceptions -fno-rtti > -c /usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/= Sema/SemaTemplateInstantiateDecl.cpp > -o SemaTemplateInstantiateDecl.o {standard input}: Assembler > messages: {standard input}:48382: Warning: end of file not at end of > a line; newline inserted {standard input}:49458: Error: ARM register > expected -- `mov' c++: Internal error: Killed (program cc1plus) > Please submit a full bug report. See > for instructions. *** > [SemaTemplate.o] Error code 1 1 error *** [all] Error code 2 1 error > *** [all] Error code 2 >=20 Greeting- I have built 2 kernels from head as of the small hours of this morning, and several ports with no problems. =20 One kernel was built on the BeagleBone, one kernel was built on the PI and the ports were built on the PI. Here is some of my info: wynkoop@beaglebone:~ % cc -v Using built-in specs. Target: armv6-undermydesk-freebsd Configured with: FreeBSD/armv6 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] wynkoop@beaglebone:~ % uname -a FreeBSD beaglebone 10.0-CURRENT FreeBSD 10.0-CURRENT #2: Mon Feb 11 02:15:36 EST 2013 root@beaglebone:/sys/arm/compile/BEAGLEBONE-DEBUG arm wynkoop@beaglebone:~ % cc -v Using built-in specs. Target: armv6-undermydesk-freebsd Configured with: FreeBSD/armv6 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] wynkoop@beaglebone:~ %=20 root@fbsd-pi:/sys/arm/compile/RPI-B-TMPFS # uname -a FreeBSD fbsd-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Mon Feb 11 09:48:01 EST 2013 root@fbsd-pi:/sys/arm/compile/RPI-B arm root@fbsd-pi:/sys/arm/compile/RPI-B-TMPFS # cc -v Using built-in specs. Target: armv6-undermydesk-freebsd Configured with: FreeBSD/armv6 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] root@fbsd-pi:/sys/arm/compile/RPI-B-TMPFS #=20 I hope this helps. -Brett --=20 wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 April 19, 1775 An English attempt to confiscate guns from Americans triggered a successful revolution...... Dear Congress, that's a hint. --Sig_/8q4h03d6CiVnXPSyAlkpJ/. Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iQEcBAEBAgAGBQJRGTOWAAoJEK6K3yrc+RuDAcwH/RZaSQp81KcjXsfadyUF/l6A CnoOIo92+LL6GG625GekwNS0swQ0lO1vSpHIBu4QlNgAfDwGtUkcCeZ4CSExFIUW v/JvBBa2KVY/uGZ7R+2cCkAEpVuEVDvdf6BL+HfZVxZlS0sMTnbJDOGqN4ublaoo kG701GuLKnjhcDI5EnxcY+DqMrB3hR38+3VdXqFuPd91f/D4f5kI+oRx5pKIdrU7 vC/cjQtaX8CDWadwqptY4zzC+XZOLHq4uba5MsKpmgW4B5JC1J0gtMfwSzrUMEuM /MPNNf8wVdqWDQaefTOb5Y7xoR5Akl6Gb0KZyr6uBWYXlANvtOuiN+r96b5Qjsc= =LTUt -----END PGP SIGNATURE----- --Sig_/8q4h03d6CiVnXPSyAlkpJ/.-- From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 18:19:33 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 0F3D1FE6; Mon, 11 Feb 2013 18:19:33 +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 86D1A2EA; Mon, 11 Feb 2013 18:19:32 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.2.132]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1U4xyJ-000LES-KA; Mon, 11 Feb 2013 10:19:25 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Raspberry Pi No Login From: Oleksandr Tymoshenko In-Reply-To: <1360597905.4545.89.camel@revolution.hippie.lan> Date: Mon, 11 Feb 2013 10:19:00 -0800 Content-Transfer-Encoding: 7bit Message-Id: <62DF1CE7-6F3E-4233-9657-244B73D5EBE5@bluezbox.com> References: <09931DEF-C90A-4E72-B5EE-02BB0C6A8588@kobudo.homeunix.net> <5109A3F2.7010508@bluezbox.com> <5116F226.7010204@bluezbox.com> <1360597905.4545.89.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1499) 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 2013-02-11, at 7:51 AM, Ian Lepore wrote: > On Sat, 2013-02-09 at 17:04 -0800, Oleksandr Tymoshenko wrote: >> On 1/30/2013 2:51 PM, Oleksandr Tymoshenko wrote: >>> On 1/30/2013 2:25 PM, hiren panchasara wrote: >>>> On Wed, Jan 30, 2013 at 9:15 AM, Tim Kientzle wrote: >>>>> On Jan 30, 2013, at 7:42 AM, Neal Nelson wrote: >>>>> >>>>>> HI. >>>>>> >>>>>> I'm able to build a bootable FreeBSD image using the beaglebone >>>>>> scripts, which I understand is the accepted way at the moment. >>>>>> >>>>>> The problem I have is that everything seems to be going nicely, but >>>>>> I never get a login prompt. The last thing I see, after the ssh key >>>>>> generation stuff, is a line showing the date, then nothing. This is >>>>>> true using Current as of today (2012-01-30). >>>>>> >>>>>> I've had this problem for some time now as every image I build >>>>>> using this process has the same problem. If anyone has an idea as >>>>>> to what I'm doing wrong, I'd be very grateful. >>>>> Look at the kernel boot messages for the SD card >>>>> check. >>>>> >>>>> Is it probing at 25MHz or 50MHz? >>>>> >>>>> I haven't tried RPi in a little while, but last time I did >>>>> there was an erratic bug which caused the SD card >>>>> to sometimes get probed at 50MHz and be non-functional. >>>>> >>>>> I believe some people worked around this by trying >>>>> different cards or maybe it's been fixed in the >>>>> SD driver by now? >>>> Not sure if its fixed in the driver now but I got around the frequency >>>> problem by the patch available at: >>>> http://www.peach.ne.jp/archives/rpi/patch/ >>>> >>>> Basically its setting freq to 25MHz instead of default 50MHz in >>>> bcm2835_sdhci.c >>> >>> The patch works around the issue although it does address several >>> issues with FreeBSD's >>> generic mmc driver. Namely: driver does not check for return value for >>> functions that read >>> card's CSD, SCR or the result of switch command. CSD and SCR register >>> contain card-specific >>> information drivers uses to tune its operations. So when register read >>> command silently [...] 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] Cc: Tim Kientzle , 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, 11 Feb 2013 18:19:33 -0000 On 2013-02-11, at 7:51 AM, Ian Lepore wrote: > On Sat, 2013-02-09 at 17:04 -0800, Oleksandr Tymoshenko wrote: >> On 1/30/2013 2:51 PM, Oleksandr Tymoshenko wrote: >>> On 1/30/2013 2:25 PM, hiren panchasara wrote: >>>> On Wed, Jan 30, 2013 at 9:15 AM, Tim Kientzle wrote: >>>>> On Jan 30, 2013, at 7:42 AM, Neal Nelson wrote: >>>>> >>>>>> HI. >>>>>> >>>>>> I'm able to build a bootable FreeBSD image using the beaglebone >>>>>> scripts, which I understand is the accepted way at the moment. >>>>>> >>>>>> The problem I have is that everything seems to be going nicely, but >>>>>> I never get a login prompt. The last thing I see, after the ssh key >>>>>> generation stuff, is a line showing the date, then nothing. This is >>>>>> true using Current as of today (2012-01-30). >>>>>> >>>>>> I've had this problem for some time now as every image I build >>>>>> using this process has the same problem. If anyone has an idea as >>>>>> to what I'm doing wrong, I'd be very grateful. >>>>> Look at the kernel boot messages for the SD card >>>>> check. >>>>> >>>>> Is it probing at 25MHz or 50MHz? >>>>> >>>>> I haven't tried RPi in a little while, but last time I did >>>>> there was an erratic bug which caused the SD card >>>>> to sometimes get probed at 50MHz and be non-functional. >>>>> >>>>> I believe some people worked around this by trying >>>>> different cards or maybe it's been fixed in the >>>>> SD driver by now? >>>> Not sure if its fixed in the driver now but I got around the frequency >>>> problem by the patch available at: >>>> http://www.peach.ne.jp/archives/rpi/patch/ >>>> >>>> Basically its setting freq to 25MHz instead of default 50MHz in >>>> bcm2835_sdhci.c >>> >>> The patch works around the issue although it does address several >>> issues with FreeBSD's >>> generic mmc driver. Namely: driver does not check for return value for >>> functions that read >>> card's CSD, SCR or the result of switch command. CSD and SCR register >>> contain card-specific >>> information drivers uses to tune its operations. So when register read >>> command silently >>> fails driver uses partially valid data and hence its behavior might or >>> might not manifest >>> problems. >>> >>> Now the interesting part is why these commands fail. SDHCI controller >>> returns Data CRC >>> errors when executing them. It happens fairly early in initialization >>> sequence so at that point >>> card operates at 400KHz and should not have problem like this. >> >> Today I went all scientific on this issue and plugged logic analyzer >> to SD card using SparkFun's SD Sniffer[1]. What I found was that on >> power up SDHCI controller starts operating at frequency of 190KHz but >> shortly after it, before any data is read via DATA line, it switches to >> 8MHz. So I capped minimum frequency for SDHCI driver at 8MHz and got >> RPi into endless reboot cycle. Lo and behold: it's been almost two >> hours and so far no Data CRC Error interrupts. >> >> Patch: http://people.freebsd.org/~gonzo/arm/patches/rpi-sdhci.diff >> >> Description: >> - Do not silently ignore failure of "Read CSD" and "Read SCR" >> commands since data returned by them is essential for further >> initialization >> - Properly calculate minimum frequency for SDHCI 3.00 and higher >> - Add new method to SDHCI interface for setting driver-specific >> minimum frequency. Provide default implementation. >> - Cap minimum frequency at 8MHz for Raspberry Pi's SDHC >> >> I'd appreciate reviews and testing. There is one debug printf that >> will be removed from final version. >> >> [1] https://www.sparkfun.com/products/11468 >> > > I may not be understanding what you mean about the 8mhz clock, but if > that refers to the speed on the sd/mmc bus itself, that sounds like a > violation of the protocol. The bus is supposed to be run at no more > than 400khz until the card identification procedure is completed. (I > suspect most modern card can run the ID sequence at full speed.) > > I wonder if the real problem is a violation of a rule about switching > speed after the ID sequence... I vaguely remember there are some rules > about that, like after sending commands that change the bus config you > have to wait a certain number of cycles for the card to adjust. Yes, I was talking about SD/MMC bus speed. I understand that it's violation of ID sequence but Data CRC errors at low frequencies looks like silicon quirk. I failed to find any errata for chip so it's guesswork but I do not think it's our SDHCI/MMC driver bug. The Linux driver struggles from the same issues. Our options here are: - Increase retry attempts number in generic SDHCI and MMC drivers. for Read CSD and Read SCR commands. It will only increase chances but will not guarantee success. - Cap minimum frequency which seems to help but leaves out older MMC cards. From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 19:30:47 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 A8666A8B for ; Mon, 11 Feb 2013 19:30:47 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2C387935 for ; Mon, 11 Feb 2013 19:30:46 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 900F53ACD0; Tue, 12 Feb 2013 04:22:49 +0900 (JST) Received: from artemis (unknown [172.18.0.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id 797273ACCC; Tue, 12 Feb 2013 04:22:49 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: "Mats Mellstrand" References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> <20130131001553.GC67562@cicely7.cicely.de> <9E78813F3BF946A4A2FCEA2C363A847E@ad.peach.ne.jp> <016DDBBF-D502-4C76-96B5-BEE2D46FC6CC@exmandato.se> In-Reply-To: <016DDBBF-D502-4C76-96B5-BEE2D46FC6CC@exmandato.se> Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Date: Tue, 12 Feb 2013 04:22:44 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-arm@freebsd.org, ticso@cicely.de 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, 11 Feb 2013 19:30:47 -0000 > In trying to install the ports collection on my RPi, the following happens: > > kmem_malloc(4096): kmem_map too small: 12582912 total allocated > KDB: enter: panic > [ thread pid 27505 tid 100053 ] > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > > Suggestions? (more than not installing the ports collection) This is known problem of old kernel. You can update the kernel to http://www.peach.ne.jp/archives/rpi/kernel/kernel-20130209.gz or use new image based on SVN r246603: http://www.peach.ne.jp/archives/rpi/freebsd-pi-clang-20130210.img.gz This image contain both complete source tree and portsnap fetch/extracted tree. Also, some packages making under freebsd-pi-clang-20130210.img are uploaded to: http://www.peach.ne.jp/archives/rpi/ports/packages/All/ (compiled by clang/clang++ with bundled make.conf) ---------------------------------------------------------------------- How to use package: First, install pkg manually: # fetch http://www.peach.ne.jp/archives/rpi/pkg-static # fetch http://www.peach.ne.jp/archives/rpi/ports/packages/All/pkg-1.0.7.txz # chmod 755 pkg-static # ./pkg-static add pkg-1.0.7.txz # echo 'PACKAGESITE : http://www.peach.ne.jp/archives/rpi/ports/packages/All' > /usr/local/etc/pkg.conf For example, install bash and subversion: # pkg install bash # pkg install subversion ---------------------------------------------------------------------- Thank you. -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 00:06:08 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 64200BF5 for ; Tue, 12 Feb 2013 00:06:08 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0EBB7858 for ; Tue, 12 Feb 2013 00:06:07 +0000 (UTC) Received: from ivory.local (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1C066w6018117; Mon, 11 Feb 2013 19:06:06 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Mon, 11 Feb 2013 19:06:06 -0500 From: Brett Wynkoop To: Tim Kientzle Subject: BeagleBone locked up Message-ID: <20130211190606.1c985baf@ivory.local> In-Reply-To: References: <20130210231709.26f122dc@ivory.local> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 12 Feb 2013 00:06:08 -0000 Greeting- While building a kernel the Bone stopped responding on the net and this is what I found on the console: ti_mmchs0: Error: current cmd NULL, already done? swap_pager: indefinite wait buffer: bufobj: 0, blkno: 5534, size: 8192 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 60, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 543, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2720, size: 16384 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 543, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2720, size: 16384 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 543, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2720, size: 16384 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 543, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2720, size: 16384 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 543, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2720, size: 16384 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 543, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2720, size: 16384 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 543, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2720, size: 16384 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 543, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2720, size: 16384 ti_mmchs0: Error: current cmd NULL, already done? ifaddr cache = 0xc1fbd700 is deleted ti_mmchs0: Error: current cmd NULL, already done? ti_mmchs0: Error: current cmd NULL, already done? The interesting thing is I have seen this same swap_pager error message on my 32 bit x86 FreeBSD 9 box when it drops it's IDE disks and goes off the net as well. The last I saw of the kernel recompile it was at linking just before it locked up. Ideas? -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 Gun Control: The theory that a woman found dead in an alley, raped and strangled with her own pantyhose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 00:16:10 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 7F0CBCB1 for ; Tue, 12 Feb 2013 00:16:10 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 214418A1 for ; Tue, 12 Feb 2013 00:16:09 +0000 (UTC) Received: from ivory.local (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1C0G8j0018222 for ; Mon, 11 Feb 2013 19:16:09 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Mon, 11 Feb 2013 19:16:08 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: sshd dying on BeagleBone Message-ID: <20130211191608.06a3b3e5@ivory.local> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 12 Feb 2013 00:16:10 -0000 Greeting- While looking at the console I saw that sshd died on signal 11! So now we have a clue. If I recall correctly signal 11 is a seg fault. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 Gun Control: The theory that a woman found dead in an alley, raped and strangled with her own pantyhose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 00:27:08 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 B3C03E5A; Tue, 12 Feb 2013 00:27:08 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 4B8D38F9; Tue, 12 Feb 2013 00:27:07 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.5/8.14.5/ALCHEMY.FRANKEN.DE) with ESMTP id r1C0Qxj1022864; Tue, 12 Feb 2013 01:27:00 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r1C0QxHi022863; Tue, 12 Feb 2013 01:26:59 +0100 (CET) (envelope-from marius) Date: Tue, 12 Feb 2013 01:26:59 +0100 From: Marius Strobl To: Konstantin Belousov Subject: Re: Physbio changes final call for tests and reviews Message-ID: <20130212002659.GA22851@alchemy.franken.de> References: <20130202163322.GA2522@kib.kiev.ua> <20130202214709.GA99418@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130202214709.GA99418@alchemy.franken.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: powerpc@freebsd.org, mips@freebsd.org, current@freebsd.org, jeff@freebsd.org, ia64@freebsd.org, arch@freebsd.org, sparc64@freebsd.org, 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, 12 Feb 2013 00:27:08 -0000 On Sat, Feb 02, 2013 at 10:47:09PM +0100, Marius Strobl wrote: > On Sat, Feb 02, 2013 at 06:33:22PM +0200, Konstantin Belousov wrote: > > Hi, > > I finished the last (insignificant) missed bits in the Jeff' physbio > > work. Now I am asking for the last round of testing and review, esp. for > > the !x86 architectures. Another testing focus are the SCSI HBAs and RAID > > controllers which drivers are changed by the patchset. Please do test > > this before the patchset is committed into HEAD ! > > > > The plan is to commit the patch somewhere in two weeks from this moment. > > The patch is required for the finalizing of the unmapped I/O work for UFS > > I did in parallel, which I hope to finish shortly after the commit. > > > > Patch is available at http://people.freebsd.org/~kib/misc/physbio.5.diff > > > > First tests on sparc64 with ata(4), mpt(4) and sym(4) look good (to > be sure I still need to test with a machine using a streaming buffer > in addition to the IOMMU, though). FYI, the latter case is also fine. Marius From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 00:45:40 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 64C4A30A for ; Tue, 12 Feb 2013 00:45:40 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 485699AB for ; Tue, 12 Feb 2013 00:45:35 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1C0jYvf072288 for ; Mon, 11 Feb 2013 17:45:35 -0700 (MST) (envelope-from ian@FreeBSD.org) 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 r1C0jWxN040287; Mon, 11 Feb 2013 17:45:32 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: BeagleBone locked up From: Ian Lepore To: Brett Wynkoop In-Reply-To: <20130211190606.1c985baf@ivory.local> References: <20130210231709.26f122dc@ivory.local> <20130211190606.1c985baf@ivory.local> Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Feb 2013 17:45:32 -0700 Message-ID: <1360629932.4545.150.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , 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, 12 Feb 2013 00:45:40 -0000 On Mon, 2013-02-11 at 19:06 -0500, Brett Wynkoop wrote: > Greeting- > > While building a kernel the Bone stopped responding on the net and this > is what I found on the console: > > ti_mmchs0: Error: current cmd NULL, already done? > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 5534, size: 8192 [...] > ti_mmchs0: Error: current cmd NULL, already done? > ifaddr cache = 0xc1fbd700 is deleted > ti_mmchs0: Error: current cmd NULL, already done? > ti_mmchs0: Error: current cmd NULL, already done? > > The interesting thing is I have seen this same swap_pager error message > on my 32 bit x86 FreeBSD 9 box when it drops it's IDE disks and goes > off the net as well. > > The last I saw of the kernel recompile it was at linking just before it > locked up. > > Ideas? That's the second report recently of indefinite wait buffer. What it really means is that it has been waiting more than 20 seconds to pull a page (or block of pages) in from swap. That plus the cmd NULL errors tend to point in the direction of the mmchs driver. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 01:06:24 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 A701A77D for ; Tue, 12 Feb 2013 01:06:24 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6D275A92 for ; Tue, 12 Feb 2013 01:06:24 +0000 (UTC) Received: from ivory.local (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1C16Npb018758 for ; Mon, 11 Feb 2013 20:06:23 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Mon, 11 Feb 2013 20:06:22 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: Re: BeagleBone locked up Message-ID: <20130211200622.2b18990b@ivory.local> In-Reply-To: <20130211190606.1c985baf@ivory.local> References: <20130210231709.26f122dc@ivory.local> <20130211190606.1c985baf@ivory.local> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 12 Feb 2013 01:06:24 -0000 On Mon, 11 Feb 2013 19:06:06 -0500 Brett Wynkoop wrote: > Greeting- > > While building a kernel the Bone stopped responding on the net and > this is what I found on the console: > > ti_mmchs0: Error: current cmd NULL, already done? > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 5534, size: 8192 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 60, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 543, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2720, size: > 16384 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 543, > size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: > 2720, size: 16384 swap_pager: indefinite wait buffer: bufobj: 0, > blkno: 543, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, > blkno: 2720, size: 16384 swap_pager: indefinite wait buffer: bufobj: > 0, blkno: 543, size: 4096 swap_pager: indefinite wait buffer: bufobj: > 0, blkno: 2720, size: 16384 swap_pager: indefinite wait buffer: > bufobj: 0, blkno: 543, size: 4096 swap_pager: indefinite wait buffer: > bufobj: 0, blkno: 2720, size: 16384 swap_pager: indefinite wait > buffer: bufobj: 0, blkno: 543, size: 4096 swap_pager: indefinite wait > buffer: bufobj: 0, blkno: 2720, size: 16384 swap_pager: indefinite > wait buffer: bufobj: 0, blkno: 543, size: 4096 swap_pager: indefinite > wait buffer: bufobj: 0, blkno: 2720, size: 16384 swap_pager: > indefinite wait buffer: bufobj: 0, blkno: 543, size: 4096 swap_pager: > indefinite wait buffer: bufobj: 0, blkno: 2720, size: 16384 > ti_mmchs0: Error: current cmd NULL, already done? ifaddr cache = > 0xc1fbd700 is deleted ti_mmchs0: Error: current cmd NULL, already > done? ti_mmchs0: Error: current cmd NULL, already done? Well just after I sent this email the console got live again, so here is more info: dev.cpsw.0.%desc: 3-port Switch Ethernet Subsystem dev.cpsw.0.%driver: cpsw dev.cpsw.0.%parent: simplebus0 dev.cpsw.0.attachedSecs: 57153 dev.cpsw.0.uptime: 57107 dev.cpsw.0.stats.GoodRxFrames: 1495428 dev.cpsw.0.stats.BroadcastRxFrames: 90017 dev.cpsw.0.stats.MulticastRxFrames: 33663 dev.cpsw.0.stats.PauseRxFrames: 0 dev.cpsw.0.stats.RxCrcErrors: 1014 dev.cpsw.0.stats.RxAlignErrors: 1027 dev.cpsw.0.stats.OversizeRxFrames: 0 dev.cpsw.0.stats.RxJabbers: 0 dev.cpsw.0.stats.ShortRxFrames: 0 dev.cpsw.0.stats.RxFragments: 126 dev.cpsw.0.stats.RxOctets: 582760354 dev.cpsw.0.stats.GoodTxFrames: 20212 dev.cpsw.0.stats.BroadcastTxFrames: 184 dev.cpsw.0.stats.MulticastTxFrames: 0 dev.cpsw.0.stats.PauseTxFrames: 0 dev.cpsw.0.stats.DeferredTxFrames: 0 dev.cpsw.0.stats.CollisionsTxFrames: 0 dev.cpsw.0.stats.SingleCollisionTxFrames: 0 dev.cpsw.0.stats.MultipleCollisionTxFrames: 0 dev.cpsw.0.stats.ExcessiveCollisions: 0 dev.cpsw.0.stats.LateCollisions: 0 dev.cpsw.0.stats.TxUnderrun: 0 dev.cpsw.0.stats.CarrierSenseErrors: 0 dev.cpsw.0.stats.TxOctets: 14001704 dev.cpsw.0.stats.RxTx64OctetFrames: 205862 dev.cpsw.0.stats.RxTx65to127OctetFrames: 872583 dev.cpsw.0.stats.RxTx128to255OctetFrames: 73451 dev.cpsw.0.stats.RxTx256to511OctetFrames: 21383 dev.cpsw.0.stats.RxTx512to1024OctetFrames: 32661 dev.cpsw.0.stats.RxTx1024upOctetFrames: 311741 dev.cpsw.0.stats.NetOctets: 597289074 dev.cpsw.0.stats.RxStartOfFrameOverruns: 502 dev.cpsw.0.stats.RxMiddleOfFrameOverruns: 0 dev.cpsw.0.stats.RxDmaOverruns: 1 dev.cpsw.0.queue.tx.totalBuffers: 128 dev.cpsw.0.queue.tx.activeBuffers: 0 dev.cpsw.0.queue.tx.maxActiveBuffers: 11 dev.cpsw.0.queue.tx.availBuffers: 128 dev.cpsw.0.queue.tx.maxAvailBuffers: 128 dev.cpsw.0.queue.tx.totalEnqueued: 34491 dev.cpsw.0.queue.tx.totalDequeued: 34491 dev.cpsw.0.queue.tx.longestChain: 8 dev.cpsw.0.queue.rx.totalBuffers: 384 dev.cpsw.0.queue.rx.activeBuffers: 384 dev.cpsw.0.queue.rx.maxActiveBuffers: 384 dev.cpsw.0.queue.rx.availBuffers: 0 dev.cpsw.0.queue.rx.maxAvailBuffers: 12 dev.cpsw.0.queue.rx.totalEnqueued: 1495811 dev.cpsw.0.queue.rx.totalDequeued: 1495427 dev.cpsw.0.queue.rx.longestChain: 0 dev.cpsw.0.watchdog.resets: 0 Then sshd died on signal 11. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 "The strongest reason for the people to retain the right to keep and bear arms is, as a last resort, to protect themselves against tyranny in government" - Thomas Jefferson. From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 01:48:58 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 EBE69CA8; Tue, 12 Feb 2013 01:48:58 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 95BF2B71; Tue, 12 Feb 2013 01:48:58 +0000 (UTC) Received: from ivory.local (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1C1mvdN019178; Mon, 11 Feb 2013 20:48:57 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Mon, 11 Feb 2013 20:48:56 -0500 From: Brett Wynkoop To: Ian Lepore Subject: Re: BeagleBone locked up Message-ID: <20130211204856.713c9ee2@ivory.local> In-Reply-To: <1360629932.4545.150.camel@revolution.hippie.lan> References: <20130210231709.26f122dc@ivory.local> <20130211190606.1c985baf@ivory.local> <1360629932.4545.150.camel@revolution.hippie.lan> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , 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, 12 Feb 2013 01:48:59 -0000 On Mon, 11 Feb 2013 17:45:32 -0700 Ian Lepore wrote: > On Mon, 2013-02-11 at 19:06 -0500, Brett Wynkoop wrote: > > Greeting- > > > > While building a kernel the Bone stopped responding on the net and > > this is what I found on the console: > > > > ti_mmchs0: Error: current cmd NULL, already done? > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 5534, size: > > 8192 > [...] > > ti_mmchs0: Error: current cmd NULL, already done? > > ifaddr cache = 0xc1fbd700 is deleted > > ti_mmchs0: Error: current cmd NULL, already done? > > ti_mmchs0: Error: current cmd NULL, already done? snip > > That's the second report recently of indefinite wait buffer. What it > really means is that it has been waiting more than 20 seconds to pull > a page (or block of pages) in from swap. That plus the cmd NULL > errors tend to point in the direction of the mmchs driver. > > -- Ian Greeting- I am glad that I am passing on needed feedback. I did not have to reboot the box, just waited and the console eventually responded again and I restarted sshd. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 I would never invade the United States. There would be a gun behind every blade of grass. --Isoroku Yamamoto From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 06:17:32 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 90CCE3E1; Tue, 12 Feb 2013 06:17:32 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp3.clear.net.nz (smtp3.clear.net.nz [203.97.33.64]) by mx1.freebsd.org (Postfix) with ESMTP id 6244D6BD; Tue, 12 Feb 2013 06:17:32 +0000 (UTC) Received: from mxin2-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MI3002ALG508K70@smtp3.clear.net.nz>; Tue, 12 Feb 2013 19:17:25 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO bender) ([202.0.48.19]) by smtpin2.paradise.net.nz with ESMTP; Tue, 12 Feb 2013 19:17:24 +1300 Date: Tue, 12 Feb 2013 19:17:24 +1300 From: Andrew Turner Subject: Re: Build failure in libclang for ARM. In-reply-to: <53ED3A94-E4DD-441D-9E2C-46E23C21F8D1@freebsd.org> To: Tim Kientzle Message-id: <20130212191724.498aa979@bender> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit References: <53ED3A94-E4DD-441D-9E2C-46E23C21F8D1@freebsd.org> 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, 12 Feb 2013 06:17:32 -0000 On Mon, 11 Feb 2013 09:18:40 -0800 Tim Kientzle wrote: > Been seeing this for a couple of days now. First with > native ARM-on-ARM builds, and now with cross ARM-on-x86 builds. > FWIW, my /etc/make.conf and /etc/src.conf are both empty. I haven't seen this error but I normally do ARM-on-amd64 builds. Is it possible you are running out of memory? It looks like gcc is only generating some of the required assembly code. Andrew From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 06:28:02 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 37A784A6; Tue, 12 Feb 2013 06:28:02 +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 E9638708; Tue, 12 Feb 2013 06:28:01 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1C6Rq9O018953; Tue, 12 Feb 2013 06:27:52 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id fh5tqhfq77xd6mzqd66m2skhxe; Tue, 12 Feb 2013 06:27:52 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <1360604561.4545.115.camel@revolution.hippie.lan> Date: Mon, 11 Feb 2013 22:27:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> <1360604561.4545.115.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org, Brett Wynkoop 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, 12 Feb 2013 06:28:02 -0000 On Feb 11, 2013, at 9:42 AM, Ian Lepore wrote: > =85 I still find it much more cumbersome to work with > than the old hints system. The very fact that you need > a special compiler to change the fdt data is part of that. This is my single biggest complaint about fdt as well. >> 2) We're still debating the role of the FDT vis a vis >> end user customization. Personally, I would like >> to find some more dynamic approach to handling >> pinmux at runtime. (E.g., if you want to use a pin >> for gpio, you do this: >> $ gpioctl 1 7 out # Set gpio 1 7 for output, including pinmux = change >> $ gpioctl 1 7 on >> Similarly, I think that enabling uart2 should automatically >> adjust the pinmux appropriately. >=20 > I whole-heartedly agree with that last sentence, but it's about a > zillion miles from where our code is now. I'm not even sure it's = fully > possible, it just seems like a nice generic ideal "I asked for a uart, > so the uart driver should enable power, enable clocks, and assign pins > to make that happen." At least for BeagleBone, I think I see a way to make the pinmux code work this way. That code is all table-driven, so with some creative reworking of the tables, it should be feasible to define groups of pins and a mechanism to manage them. Tedious work, to be sure, simply because of the sheer number of definitions involved, but nothing particularly complicated. Another approach I've considered is to have the necessary pinmux assignments be part of the device entry in the DTS. (BeagleBone DTS, at least, defines a single list of pinmux settings for the board, which I don't like at all.) This would be similar to the way interrupts and memory regions are assigned today. That would at least move the problem down to the level of enabling/disabling particular entries in the DTS. Unfortunately, I don't yet understand the inner workings of simplebus and the FDT management in the kernel well enough to be able to tackle this just yet. Having pinmux settings be part of the associated device node in the DTS would also make your next issue a little easier to manage, I think. (For example, the DTS in SVN could have several versions of a single device with most of them disabled.) > The problem crops up when "assign pins" has > several sets of pins to choose from for a given device, and I know at > least the Atmel SoCs do this a lot. Tim From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 06:38:42 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 94A4E5F9; Tue, 12 Feb 2013 06:38:42 +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 578F9756; Tue, 12 Feb 2013 06:38:41 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1C6cfx5019009; Tue, 12 Feb 2013 06:38:41 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id argxk73qfpmuwiwx5n22hjj6n2; Tue, 12 Feb 2013 06:38:41 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: BeagleBone locked up Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <1360629932.4545.150.camel@revolution.hippie.lan> Date: Mon, 11 Feb 2013 22:38:38 -0800 Content-Transfer-Encoding: 7bit Message-Id: <4AF15BB9-4174-4564-A770-BF9EB9D447F5@kientzle.com> References: <20130210231709.26f122dc@ivory.local> <20130211190606.1c985baf@ivory.local> <1360629932.4545.150.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org, Brett Wynkoop 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, 12 Feb 2013 06:38:42 -0000 On Feb 11, 2013, at 4:45 PM, Ian Lepore wrote: > On Mon, 2013-02-11 at 19:06 -0500, Brett Wynkoop wrote: >> Greeting- >> >> While building a kernel the Bone stopped responding on the net and this >> is what I found on the console: >> >> ti_mmchs0: Error: current cmd NULL, already done? >> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 5534, size: 8192 > [...] >> ti_mmchs0: Error: current cmd NULL, already done? >> ifaddr cache = 0xc1fbd700 is deleted >> ti_mmchs0: Error: current cmd NULL, already done? >> ti_mmchs0: Error: current cmd NULL, already done? >> >> The interesting thing is I have seen this same swap_pager error message >> on my 32 bit x86 FreeBSD 9 box when it drops it's IDE disks and goes >> off the net as well. >> >> The last I saw of the kernel recompile it was at linking just before it >> locked up. >> >> Ideas? > > That's the second report recently of indefinite wait buffer. What it > really means is that it has been waiting more than 20 seconds to pull a > page (or block of pages) in from swap. That plus the cmd NULL errors > tend to point in the direction of the mmchs driver. This is something that's degraded fairly recently. I only started seeing these in the last week or so. And the BeagleBone MMCHS driver has not been touched in a very long time. Tim From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 06:42:34 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 6037265E for ; Tue, 12 Feb 2013 06:42:34 +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 417C977C for ; Tue, 12 Feb 2013 06:42:33 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1C6gX6g019027; Tue, 12 Feb 2013 06:42:33 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id g665iaeihyswkqeyr97qfk5ar2; Tue, 12 Feb 2013 06:42:33 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: Build failure in libclang for ARM. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20130212191724.498aa979@bender> Date: Mon, 11 Feb 2013 22:42:32 -0800 Content-Transfer-Encoding: 7bit Message-Id: <73C03291-BBA9-4773-8C35-FC7336F93368@freebsd.org> References: <53ED3A94-E4DD-441D-9E2C-46E23C21F8D1@freebsd.org> <20130212191724.498aa979@bender> To: Andrew Turner 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: Tue, 12 Feb 2013 06:42:34 -0000 On Feb 11, 2013, at 10:17 PM, Andrew Turner wrote: > On Mon, 11 Feb 2013 09:18:40 -0800 > Tim Kientzle wrote: > >> Been seeing this for a couple of days now. First with >> native ARM-on-ARM builds, and now with cross ARM-on-x86 builds. >> FWIW, my /etc/make.conf and /etc/src.conf are both empty. > > I haven't seen this error but I normally do ARM-on-amd64 builds. Is it > possible you are running out of memory? It looks like gcc is only > generating some of the required assembly code. Thanks, Andrew. That seems to be exactly it. (One drawback of doing everything over SSH is not noticing the "out of memory" errors on the console.) Tim From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 06:59: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 578BC985; Tue, 12 Feb 2013 06:59:29 +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 15D39810; Tue, 12 Feb 2013 06:59:28 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1C6xS9D019091; Tue, 12 Feb 2013 06:59:28 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 4iyym6qi3q9e4gxb93cwixeyke; Tue, 12 Feb 2013 06:59:27 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: BeagleBone locked up Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <4AF15BB9-4174-4564-A770-BF9EB9D447F5@kientzle.com> Date: Mon, 11 Feb 2013 22:59:26 -0800 Content-Transfer-Encoding: 7bit Message-Id: <71E78969-89F2-42B1-9E3C-6F0A8D83D9FC@kientzle.com> References: <20130210231709.26f122dc@ivory.local> <20130211190606.1c985baf@ivory.local> <1360629932.4545.150.camel@revolution.hippie.lan> <4AF15BB9-4174-4564-A770-BF9EB9D447F5@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org, Brett Wynkoop , Ian Lepore 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, 12 Feb 2013 06:59:29 -0000 On Feb 11, 2013, at 10:38 PM, Tim Kientzle wrote: > > On Feb 11, 2013, at 4:45 PM, Ian Lepore wrote: > >> On Mon, 2013-02-11 at 19:06 -0500, Brett Wynkoop wrote: >>> Greeting- >>> >>> While building a kernel the Bone stopped responding on the net and this >>> is what I found on the console: >>> >>> ti_mmchs0: Error: current cmd NULL, already done? >>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 5534, size: 8192 >> [...] >>> ti_mmchs0: Error: current cmd NULL, already done? >>> ifaddr cache = 0xc1fbd700 is deleted >>> ti_mmchs0: Error: current cmd NULL, already done? >>> ti_mmchs0: Error: current cmd NULL, already done? >>> >>> The interesting thing is I have seen this same swap_pager error message >>> on my 32 bit x86 FreeBSD 9 box when it drops it's IDE disks and goes >>> off the net as well. >>> >>> The last I saw of the kernel recompile it was at linking just before it >>> locked up. >>> >>> Ideas? >> >> That's the second report recently of indefinite wait buffer. What it >> really means is that it has been waiting more than 20 seconds to pull a >> page (or block of pages) in from swap. That plus the cmd NULL errors >> tend to point in the direction of the mmchs driver. > > This is something that's degraded fairly recently. > I only started seeing these in the last week or so. > > And the BeagleBone MMCHS driver has not been > touched in a very long time. Although it seems that there has recently been a big bump in memory requirements for compiling, so maybe this is just a side-effect of hammering the swap harder than before. Tim From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 14:57:08 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 5E342CFF for ; Tue, 12 Feb 2013 14:57:08 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id C1085988 for ; Tue, 12 Feb 2013 14:57:07 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1CEv6w1082433 for ; Tue, 12 Feb 2013 07:57:07 -0700 (MST) (envelope-from ian@FreeBSD.org) 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 r1CEujre041017; Tue, 12 Feb 2013 07:56:45 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: building RaspPi Images From: Ian Lepore To: Tim Kientzle In-Reply-To: <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> <1360604561.4545.115.camel@revolution.hippie.lan> <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Feb 2013 07:56:44 -0700 Message-ID: <1360681004.4545.160.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, Brett Wynkoop 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, 12 Feb 2013 14:57:08 -0000 On Mon, 2013-02-11 at 22:27 -0800, Tim Kientzle wrote: > On Feb 11, 2013, at 9:42 AM, Ian Lepore wrote: > [snip] > > At least for BeagleBone, I think I see a way to > make the pinmux code work this way. That code is > all table-driven, so with some creative reworking of > the tables, it should be feasible to define groups of > pins and a mechanism to manage them. Tedious > work, to be sure, simply because of the sheer number > of definitions involved, but nothing particularly complicated. > > Another approach I've considered is to have the > necessary pinmux assignments be part of the > device entry in the DTS. (BeagleBone DTS, at > least, defines a single list of pinmux settings for > the board, which I don't like at all.) This would > be similar to the way interrupts and memory > regions are assigned today. That would at > least move the problem down to the level of > enabling/disabling particular entries in the DTS. > Unfortunately, I don't yet understand the inner workings > of simplebus and the FDT management in the kernel > well enough to be able to tackle this just yet. > > Having pinmux settings be part of the associated > device node in the DTS would also make your next > issue a little easier to manage, I think. (For example, > the DTS in SVN could have several versions of a single > device with most of them disabled.) I've seen a block at the bottom of some dts source named "choices" or something like that. That seems to hint at the possibility of describing a variety of stock configurations for various devices and then the choosing of configurations might be little more than manipulating some strings in that section. That's the sort of thing that might be easy to handle within ubldr. Doing more than that in ubldr might set us on the path of turning it into a dts compiler. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 14:58:51 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 25163D59 for ; Tue, 12 Feb 2013 14:58:51 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id ECB289A4 for ; Tue, 12 Feb 2013 14:58:50 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1CEpISd082387 for ; Tue, 12 Feb 2013 07:51:24 -0700 (MST) (envelope-from ian@FreeBSD.org) 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 r1CEoeqc041008; Tue, 12 Feb 2013 07:50:55 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: BeagleBone locked up From: Ian Lepore To: Brett Wynkoop In-Reply-To: <20130211204856.713c9ee2@ivory.local> References: <20130210231709.26f122dc@ivory.local> <20130211190606.1c985baf@ivory.local> <1360629932.4545.150.camel@revolution.hippie.lan> <20130211204856.713c9ee2@ivory.local> Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Feb 2013 07:50:40 -0700 Message-ID: <1360680640.4545.157.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , 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, 12 Feb 2013 14:58:51 -0000 On Mon, 2013-02-11 at 20:48 -0500, Brett Wynkoop wrote: > On Mon, 11 Feb 2013 17:45:32 -0700 > Ian Lepore wrote: > > > On Mon, 2013-02-11 at 19:06 -0500, Brett Wynkoop wrote: > > > Greeting- > > > > > > While building a kernel the Bone stopped responding on the net and > > > this is what I found on the console: > > > > > > ti_mmchs0: Error: current cmd NULL, already done? > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 5534, size: > > > 8192 > > [...] > > > ti_mmchs0: Error: current cmd NULL, already done? > > > ifaddr cache = 0xc1fbd700 is deleted > > > ti_mmchs0: Error: current cmd NULL, already done? > > > ti_mmchs0: Error: current cmd NULL, already done? > > snip > > > > > That's the second report recently of indefinite wait buffer. What it > > really means is that it has been waiting more than 20 seconds to pull > > a page (or block of pages) in from swap. That plus the cmd NULL > > errors tend to point in the direction of the mmchs driver. > > > > -- Ian > > Greeting- > > I am glad that I am passing on needed feedback. I did not have to > reboot the box, just waited and the console eventually responded again > and I restarted sshd. When it gets into that sort of state, can you get a response by hitting ^T on the console (or any open ssh terminal session)? If so, the line it prints may have a clue about what it's blocked on. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 15:02: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 8C511ED2 for ; Tue, 12 Feb 2013 15:02:05 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 258879D6 for ; Tue, 12 Feb 2013 15:02:04 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1CF1vLV082563 for ; Tue, 12 Feb 2013 08:01:57 -0700 (MST) (envelope-from ian@FreeBSD.org) 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 r1CF1Z5r041033; Tue, 12 Feb 2013 08:01:35 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: BeagleBone locked up From: Ian Lepore To: Tim Kientzle In-Reply-To: <4AF15BB9-4174-4564-A770-BF9EB9D447F5@kientzle.com> References: <20130210231709.26f122dc@ivory.local> <20130211190606.1c985baf@ivory.local> <1360629932.4545.150.camel@revolution.hippie.lan> <4AF15BB9-4174-4564-A770-BF9EB9D447F5@kientzle.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Feb 2013 08:01:35 -0700 Message-ID: <1360681295.4545.165.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, Brett Wynkoop 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, 12 Feb 2013 15:02:05 -0000 On Mon, 2013-02-11 at 22:38 -0800, Tim Kientzle wrote: > On Feb 11, 2013, at 4:45 PM, Ian Lepore wrote: > > > On Mon, 2013-02-11 at 19:06 -0500, Brett Wynkoop wrote: > >> Greeting- > >> > >> While building a kernel the Bone stopped responding on the net and this > >> is what I found on the console: > >> > >> ti_mmchs0: Error: current cmd NULL, already done? > >> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 5534, size: 8192 > > [...] > >> ti_mmchs0: Error: current cmd NULL, already done? > >> ifaddr cache = 0xc1fbd700 is deleted > >> ti_mmchs0: Error: current cmd NULL, already done? > >> ti_mmchs0: Error: current cmd NULL, already done? > >> > >> The interesting thing is I have seen this same swap_pager error message > >> on my 32 bit x86 FreeBSD 9 box when it drops it's IDE disks and goes > >> off the net as well. > >> > >> The last I saw of the kernel recompile it was at linking just before it > >> locked up. > >> > >> Ideas? > > > > That's the second report recently of indefinite wait buffer. What it > > really means is that it has been waiting more than 20 seconds to pull a > > page (or block of pages) in from swap. That plus the cmd NULL errors > > tend to point in the direction of the mmchs driver. > > This is something that's degraded fairly recently. > I only started seeing these in the last week or so. > > And the BeagleBone MMCHS driver has not been > touched in a very long time. Hrm, good point. What has been touched recently that might be related to this? This first thing that comes to mind is the recent change for allocating kmem map space proportional to the available ram. I wonder if that has led to some unexpected under- or over-allocation of buffer resources, which, when combined with slow IO, leads to unusually long waits for swapping? (Purely guessing here, but I have found in the past that playing with tuning NBUF in kernel config can lead to some odd lockups and panics.) -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 15:32:32 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 BFCF19A0 for ; Tue, 12 Feb 2013 15:32:32 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews10.kpnxchange.com (cpsmtpb-ews10.kpnxchange.com [213.75.39.15]) by mx1.freebsd.org (Postfix) with ESMTP id 56156B6B for ; Tue, 12 Feb 2013 15:32:32 +0000 (UTC) Received: from cpsps-ews16.kpnxchange.com ([10.94.84.197]) by cpsmtpb-ews10.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Tue, 12 Feb 2013 16:31:06 +0100 Received: from CPSMTPM-TLF104.kpnxchange.com ([195.121.3.7]) by cpsps-ews16.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Tue, 12 Feb 2013 16:31:06 +0100 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF104.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Tue, 12 Feb 2013 16:32:24 +0100 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 24B6D5C95 for ; Tue, 12 Feb 2013 16:32:24 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: sshd dying on BeagleBone References: <20130211191608.06a3b3e5@ivory.local> Date: Tue, 12 Feb 2013 16:32:23 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <20130211191608.06a3b3e5@ivory.local> User-Agent: Opera Mail/12.14 (FreeBSD) X-OriginalArrivalTime: 12 Feb 2013 15:32:24.0404 (UTC) FILETIME=[27FC1940:01CE0936] X-RcptDomain: 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, 12 Feb 2013 15:32:32 -0000 On Tue, 12 Feb 2013 01:16:08 +0100, Brett Wynkoop wrote: > Greeting- > > While looking at the console I saw that sshd died on signal 11! So now > we have a clue. If I recall correctly signal 11 is a seg fault. > > -Brett > You recall correctly. But a seg fault can have multiple reasons like a programming error in ssh or corrupted memory (like errors in the kernel which shuffle pages or whatever) or faulty memory chips so a pointer is flipped or .... Do you have a core dump from ssh? If not you should configure the machine to make them. You can instruct where core files are dumped. My ARM computer says: $ sysctl kern | grep core kern.corefile: %N.core kern.nodump_coredump: 0 kern.coredump: 1 kern.sugid_coredump: 0 But my amd64 desktop has this: kern.corefile: /var/tmp/%U.%N.core See 'man core' for more information. Regards, Ronald. From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 16:40:15 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 95F95218 for ; Tue, 12 Feb 2013 16:40:15 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by mx1.freebsd.org (Postfix) with ESMTP id 5D333F8 for ; Tue, 12 Feb 2013 16:40:15 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id ni5so272406obc.26 for ; Tue, 12 Feb 2013 08:40:09 -0800 (PST) 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=UKUgwil6aKXOUsptpnpucta84q3Q47vdRe8MWsuciaI=; b=FzF3Ch+RzrK1jXUOF4Xdo3GHVi2Th57SOwmS3FQMosibj5hK+Bz2KjN1PBxJu9BRWb z0SWbqPsuipBpmGe1+xoLLvkjXfSSyGChz78ZzWL/Rq58UnepOPh668Bc3JKGI23NCBF u+XTXGZ66bTDmMoHGGrmBBXuK/NaZFWWw3EcEfZ4QJprN27BZjmQADZmVj8hLYbXRK3s H90cqxNDiZwtiuSYHHup45qAF3O2uEdUckx7osiXXIRWDoE888q5xSvO9FEwyN5lxinf fE3m+NJMz2t9inA9coVDVDNH1YMr2eMzlt+DAMkTGKBrXmmkcSEhOaKL5QSq8MzM/H3y vFdQ== X-Received: by 10.182.118.105 with SMTP id kl9mr14052799obb.52.1360687209241; Tue, 12 Feb 2013 08:40:09 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id jd1sm53469627obb.8.2013.02.12.08.40.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 08:40:08 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.com> Date: Tue, 12 Feb 2013 09:40:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> <1360604561.4545.115.camel@revolution.hippie.lan> <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlT000iSoPaiQlLHbQ3c7o0J/2CLRE5Xm6EKKSR3QNKdk1GkXXNlm+TdIcFt5P6bUOiwmsj Cc: freebsd-arm@freebsd.org, Brett Wynkoop , Ian Lepore 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, 12 Feb 2013 16:40:15 -0000 On Feb 11, 2013, at 11:27 PM, Tim Kientzle wrote: > On Feb 11, 2013, at 9:42 AM, Ian Lepore wrote: >=20 >> =85 I still find it much more cumbersome to work with >> than the old hints system. The very fact that you need >> a special compiler to change the fdt data is part of that. >=20 > This is my single biggest complaint about fdt as well. And the better solution is? We have nothing that's better... >>> 2) We're still debating the role of the FDT vis a vis >>> end user customization. Personally, I would like >>> to find some more dynamic approach to handling >>> pinmux at runtime. (E.g., if you want to use a pin >>> for gpio, you do this: >>> $ gpioctl 1 7 out # Set gpio 1 7 for output, including pinmux = change >>> $ gpioctl 1 7 on >>> Similarly, I think that enabling uart2 should automatically >>> adjust the pinmux appropriately. >>=20 >> I whole-heartedly agree with that last sentence, but it's about a >> zillion miles from where our code is now. I'm not even sure it's = fully >> possible, it just seems like a nice generic ideal "I asked for a = uart, >> so the uart driver should enable power, enable clocks, and assign = pins >> to make that happen." >=20 > At least for BeagleBone, I think I see a way to > make the pinmux code work this way. That code is > all table-driven, so with some creative reworking of > the tables, it should be feasible to define groups of > pins and a mechanism to manage them. Tedious > work, to be sure, simply because of the sheer number > of definitions involved, but nothing particularly complicated. The tables should come in from the FDT. I know that's a pain, but it = makes it so that when the next rev of the silicon comes out that has = slightly different swizzled pins easier to integrate. > Another approach I've considered is to have the > necessary pinmux assignments be part of the > device entry in the DTS. (BeagleBone DTS, at > least, defines a single list of pinmux settings for > the board, which I don't like at all.) This would > be similar to the way interrupts and memory > regions are assigned today. That would at > least move the problem down to the level of > enabling/disabling particular entries in the DTS. > Unfortunately, I don't yet understand the inner workings > of simplebus and the FDT management in the kernel > well enough to be able to tackle this just yet. This is the approach that's favored by those driving the FDT = definitions. I've seen it work well in the Atmel case where they have = the same basic core that they remix with different devices to produce = the different SoCs optimized for different market segments. They have = gotten tot he point where a new SoC with old IP just needs a new FDT to = be supported by the kernel. > Having pinmux settings be part of the associated > device node in the DTS would also make your next > issue a little easier to manage, I think. (For example, > the DTS in SVN could have several versions of a single > device with most of them disabled.) The typical approach taken over in linux-land is to have a base config, = then have customizations done with a file that just includes the base, = and enables some of the disabled devices. You don't need several = versions of the DTS at all, just one base one and several smallish files = that describe different board configs. Think of this as: include "GENERIC" nodevice foo device bar option FRED nooption WILMA FDT is powerful enough to cope with those things today, with the version = we have in the tree. Warner >> The problem crops up when "assign pins" has >> several sets of pins to choose from for a given device, and I know at >> least the Atmel SoCs do this a lot. >=20 >=20 > Tim >=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 Tue Feb 12 16:44:48 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 DDDC1344 for ; Tue, 12 Feb 2013 16:44:48 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by mx1.freebsd.org (Postfix) with ESMTP id A243D12D for ; Tue, 12 Feb 2013 16:44:47 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id wc20so283233obb.1 for ; Tue, 12 Feb 2013 08:44:47 -0800 (PST) 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=gqDq6rb01H0LuC9oAv/pO3WvMVQRRbQuJa29qa5Hodw=; b=Q/kwi1266JHj1B0gfPkpBRhEoproKtoxwE5HVXUFNKm8WWDsHgDEpJ2wu3Svb29FU/ KqQdKUOBGeViZP+LmbRiR4o6NGNSiXUhLUlzkt9qB7ez2bL+XV8fvxpVkSxgxFsONKXv vWOK4snh+LbdNrP5JcTDl9PzkK87zPxiQXnFTEaSCMwiYqjR0fpLQaAGm9NfT1lMStIi PauOJWsQtidLiUtcXAvojsuZHGcjdzF/MVS8QS1C88DmiEmR7WzSTEzsj41iQLe4y4i5 TMRO1Bf3/vCSTIBa6DSzdP3y6p3ArY0kBUERe7FTpY34KExYRG7me2DvniSkSEUHOHs4 8r1Q== X-Received: by 10.60.170.232 with SMTP id ap8mr13992980oec.29.1360687487538; Tue, 12 Feb 2013 08:44:47 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id p2sm53488066obb.6.2013.02.12.08.44.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 08:44:46 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1360681004.4545.160.camel@revolution.hippie.lan> Date: Tue, 12 Feb 2013 09:44:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0F135283-ACDB-4126-A74F-04FF9321399C@bsdimp.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> <1360604561.4545.115.camel@revolution.hippie.lan> <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.com> <1360681004.4545.160.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlDREJckeN29sxmbbthIdu4bEbXHrRwMeBRwzXdotBJm6xg+edFqnFa8qAXGVTgfvO1k4K8 Cc: Tim Kientzle , freebsd-arm@FreeBSD.org, Brett Wynkoop 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, 12 Feb 2013 16:44:48 -0000 On Feb 12, 2013, at 7:56 AM, Ian Lepore wrote: > On Mon, 2013-02-11 at 22:27 -0800, Tim Kientzle wrote: >> On Feb 11, 2013, at 9:42 AM, Ian Lepore wrote: >>=20 > [snip] >>=20 >> At least for BeagleBone, I think I see a way to >> make the pinmux code work this way. That code is >> all table-driven, so with some creative reworking of >> the tables, it should be feasible to define groups of >> pins and a mechanism to manage them. Tedious >> work, to be sure, simply because of the sheer number >> of definitions involved, but nothing particularly complicated. >>=20 >> Another approach I've considered is to have the >> necessary pinmux assignments be part of the >> device entry in the DTS. (BeagleBone DTS, at >> least, defines a single list of pinmux settings for >> the board, which I don't like at all.) This would >> be similar to the way interrupts and memory >> regions are assigned today. That would at >> least move the problem down to the level of >> enabling/disabling particular entries in the DTS. >> Unfortunately, I don't yet understand the inner workings >> of simplebus and the FDT management in the kernel >> well enough to be able to tackle this just yet. >>=20 >> Having pinmux settings be part of the associated >> device node in the DTS would also make your next >> issue a little easier to manage, I think. (For example, >> the DTS in SVN could have several versions of a single >> device with most of them disabled.) >=20 > I've seen a block at the bottom of some dts source named "choices" or > something like that. That seems to hint at the possibility of > describing a variety of stock configurations for various devices and > then the choosing of configurations might be little more than > manipulating some strings in that section. That's the sort of thing > that might be easy to handle within ubldr. Doing more than that in > ubldr might set us on the path of turning it into a dts compiler. "chosen" is what you are talking about. It isn't quite what you think it is for. This section is for = communicating some settings to the kernel, but it isn't supposed to = enable/disable devices. What you are describing sounds cool, but I have = grave doubts it would work. It also goes against the main tenants of = FDT, which is that you have a simple binary blob that describes how = you've configured/wired your hardware together and the kernel can = completely rely on that to do configuration. Adding weird settings in = the chosen setting gets us back to the days of having some things = compiled in, and some things selected with hints. btw, what's wrong with optionally turning ubldr into a dts compiler? = Assuming, that is, that the BSD dts compiler project makes progress = enough to keep up with the GPL'd one? Warner= From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 17:15:30 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 0396CCA1; Tue, 12 Feb 2013 17:15:30 +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 B2F872D7; Tue, 12 Feb 2013 17:15:27 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1CHFK5O021812; Tue, 12 Feb 2013 17:15:20 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id aci7arjippbktu4gwbpdqxgdsn; Tue, 12 Feb 2013 17:15:20 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: Date: Tue, 12 Feb 2013 09:15:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <25EAEA1F-876A-4189-BCD4-A7D438332C11@kientzle.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> <1360604561.4545.115.camel@revolution.hippie.lan> <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.com> To: Warner Losh X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org, Ian Lepore , Brett Wynkoop 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, 12 Feb 2013 17:15:30 -0000 On Feb 12, 2013, at 8:40 AM, Warner Losh wrote: > The typical approach taken over in linux-land is to have a base = config, then have customizations done with a file that just includes the = base, and enables some of the disabled devices. You don't need several = versions of the DTS at all, just one base one and several smallish files = that describe different board configs. Think of this as: >=20 > include "GENERIC" > nodevice foo > device bar > option FRED > nooption WILMA >=20 > FDT is powerful enough to cope with those things today, with the = version we have in the tree. Warner, Could you point me to a good example of this? I've dug around a little bit in the Linux DTS files but I'm not sure I yet understand what I'm looking at well enough to tell which ones are good examples of this technique in action. I also have a question about FDT device probe ordering: I found in tinkering with BeagleBone that our current FDT implementation probes each device in the order it appears in the FDT. This caused me some confusion when I accidentally had some device (I don't remember which one; call it FOO) before the SCM controller (which handles pinmux). The FOO attach blew up because it couldn't get access to the SCM controller. (Yes, the FOO driver did explicitly list SCM as a requirement.) I wonder if simple bus shouldn't somehow accommodate this; otherwise, it seems like it could be a problem for doing DTS inclusion correctly. Tim From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 18:45: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 49DDD7D for ; Tue, 12 Feb 2013 18:45:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by mx1.freebsd.org (Postfix) with ESMTP id ED42A9EA for ; Tue, 12 Feb 2013 18:45:35 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id uz6so418170obc.34 for ; Tue, 12 Feb 2013 10:45:35 -0800 (PST) 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=UI49bIT2vE2qThO0/g0svTWNYrPnWnJKkU/zz3QogJo=; b=T2fKOz5mhl7IuqaXmWoel4o+P/mEb/LzxpwfP/twtQn0YqZyG8/MKA/YBIUhc2V/DQ u4aiPI/EnngXuVocLxqSMvGlnfJLQZvuf+biQs7SZjtBuG3AG5ekzvJup9WpvP0qrIxj I5EWFnbPMByIpGEwscQECgHzfPFUs5theAgA9/CNu1XJCX2ZOEUb2Mg/adFg5KLZ4Qvy nybB+/r6d7gQ3Qo6pMEh70SSEWnwdw0fChCCaZWTTYTwEJVuM4L2viF0nCIE3qCSI6YV coCEbVQL1qVyKw84iVaefzKD1ZNcHRu4XhTfsOkUCzXETxEwlBQr8Iw8aUna/XFPInhe yEgg== X-Received: by 10.60.6.199 with SMTP id d7mr14005587oea.137.1360694735367; Tue, 12 Feb 2013 10:45:35 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id yn8sm53859401obb.12.2013.02.12.10.45.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 10:45:34 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <25EAEA1F-876A-4189-BCD4-A7D438332C11@kientzle.com> Date: Tue, 12 Feb 2013 11:45:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5F763292-2EA4-426A-B84A-8DE533BA6308@bsdimp.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> <1360604561.4545.115.camel@revolution.hippie.lan> <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.com> <25EAEA1F-876A-4189-BCD4-A7D438332C11@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkXWCVv9AHif0mMyxyXFGHGn/zk7fnDt32z15fqoW+G6lYoM/MKCjTANnrPT6+QWUnpoqle Cc: freebsd-arm@freebsd.org, Ian Lepore , Brett Wynkoop 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, 12 Feb 2013 18:45:37 -0000 On Feb 12, 2013, at 10:15 AM, Tim Kientzle wrote: >=20 > On Feb 12, 2013, at 8:40 AM, Warner Losh wrote: >=20 >> The typical approach taken over in linux-land is to have a base = config, then have customizations done with a file that just includes the = base, and enables some of the disabled devices. You don't need several = versions of the DTS at all, just one base one and several smallish files = that describe different board configs. Think of this as: >>=20 >> include "GENERIC" >> nodevice foo >> device bar >> option FRED >> nooption WILMA >>=20 >> FDT is powerful enough to cope with those things today, with the = version we have in the tree. >=20 > Warner, >=20 > Could you point me to a good example of this? Yes. http://lxr.linux.no/linux+v3.7.7/arch/arm/boot/dts/at91sam9n12ek.dts is = the dts for the Atmel AT91SAM9N12-EK evaluation board. It just includes = the base Atmel AT91SAM9N dts at the top, then adds its model string, = boot args, memory size, clocks and devices (by changing their status to = "okay". It also wires up different GPIOs to the linux-speciifc triggers = like sd card or nand activity, and finally says that certain GPIO is = connected to the wakeup key. But it doesn't have all the pin group stuff in yet, so I'll have to = chase that down and see what happened to that part of the early patches = I was reviewing... > I've dug around a little bit in the Linux DTS files > but I'm not sure I yet understand what I'm looking > at well enough to tell which ones are good examples > of this technique in action. >=20 > I also have a question about FDT device probe > ordering: I found in tinkering with BeagleBone that > our current FDT implementation probes each > device in the order it appears in the FDT. > This caused me some confusion when I accidentally > had some device (I don't remember which one; call > it FOO) before the SCM controller (which handles pinmux). > The FOO attach blew up because it couldn't > get access to the SCM controller. (Yes, the FOO > driver did explicitly list SCM as a requirement.) This I'm less sure about. Warner > I wonder if simple bus shouldn't somehow > accommodate this; otherwise, it seems like > it could be a problem for doing DTS inclusion > correctly. From owner-freebsd-arm@FreeBSD.ORG Tue Feb 12 18:54: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 45B6E464 for ; Tue, 12 Feb 2013 18:54:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by mx1.freebsd.org (Postfix) with ESMTP id 0D460A63 for ; Tue, 12 Feb 2013 18:54:06 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id l10so437974oag.30 for ; Tue, 12 Feb 2013 10:54:06 -0800 (PST) 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=FMDQ7US+3APq9/1LNNlOLqZ0Fjc7CAu5IJEZMEYCyzo=; b=Ch7KbMtb2gcYaIn97S4Yn7McJJL/OJy5PwIN3TKVlZwakxtkB9siCOk3W1fBOrcqkW 2q3ZC+4KCF7zJO18xQzk+3+lPXUBcqo276DCTZKzEUt3vnDgkZG19yMWXQsCwAWuAXtg evLPzMLLIahgjyAhpTyyDQHVG0xXMP9c7hZkV8yYwK4wuuKPTclGKt8sqZhqEiimdfs1 Pqr4J948LmTw6RC2cif7IyIdUhBZyVr72WqYw/y7GYFPhzgTMhTtSo/AyOGZEqNi1es4 3iLj5DfQbk3FBU02m1JsqpnXjr1brEsDuFFA88fPQ15co8didU/G59hXy69FeFgQnD9L CHww== X-Received: by 10.182.154.4 with SMTP id vk4mr14075967obb.70.1360695246180; Tue, 12 Feb 2013 10:54:06 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id p2sm53896315obb.6.2013.02.12.10.54.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 10:54:05 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <25EAEA1F-876A-4189-BCD4-A7D438332C11@kientzle.com> Date: Tue, 12 Feb 2013 11:54:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <27A7F65F-C61D-424F-AD2C-65B29B49B700@bsdimp.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> <1360604561.4545.115.camel@revolution.hippie.lan> <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.com> <25EAEA1F-876A-4189-BCD4-A7D438332C11@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkI7NbRQEFJofXGb5H7RPKdMLp019A1RH4ERRBn9BzLbNgCT3ANCh2MLW95nAov27+RDpQN Cc: freebsd-arm@freebsd.org, Ian Lepore , Brett Wynkoop 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, 12 Feb 2013 18:54:07 -0000 On Feb 12, 2013, at 10:15 AM, Tim Kientzle wrote: >=20 > On Feb 12, 2013, at 8:40 AM, Warner Losh wrote: >=20 >> The typical approach taken over in linux-land is to have a base = config, then have customizations done with a file that just includes the = base, and enables some of the disabled devices. You don't need several = versions of the DTS at all, just one base one and several smallish files = that describe different board configs. Think of this as: >>=20 >> include "GENERIC" >> nodevice foo >> device bar >> option FRED >> nooption WILMA >>=20 >> FDT is powerful enough to cope with those things today, with the = version we have in the tree. >=20 > Warner, >=20 > Could you point me to a good example of this? Or a second example: = http://lxr.linux.no/linux+v3.7.7/arch/arm/boot/dts/at91sam9g20ek_2mmc.dts This is the 2 mmc version of the 9g20ek evaluation board. This includes = the common 9g20ek definitions, then refines them. The 9g20ek common = includes the SoC definitions. Others that include the SoC definition are = things like kizbox.dts. But again, the pinmux/pin group stuff doesn't seem to be in the 3.7 = kernel :( Warner > I've dug around a little bit in the Linux DTS files > but I'm not sure I yet understand what I'm looking > at well enough to tell which ones are good examples > of this technique in action. >=20 > I also have a question about FDT device probe > ordering: I found in tinkering with BeagleBone that > our current FDT implementation probes each > device in the order it appears in the FDT. > This caused me some confusion when I accidentally > had some device (I don't remember which one; call > it FOO) before the SCM controller (which handles pinmux). > The FOO attach blew up because it couldn't > get access to the SCM controller. (Yes, the FOO > driver did explicitly list SCM as a requirement.) >=20 > I wonder if simple bus shouldn't somehow > accommodate this; otherwise, it seems like > it could be a problem for doing DTS inclusion > correctly. >=20 > Tim >=20 From owner-freebsd-arm@FreeBSD.ORG Wed Feb 13 05:30:47 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 0805BF11 for ; Wed, 13 Feb 2013 05:30:47 +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 D7580B2F for ; Wed, 13 Feb 2013 05:30:46 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1D5UhaY025843; Wed, 13 Feb 2013 05:30:43 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id mi87h3zxx2ezhyifw9ax6yzc2s; Wed, 13 Feb 2013 05:30:43 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <5F763292-2EA4-426A-B84A-8DE533BA6308@bsdimp.com> Date: Tue, 12 Feb 2013 21:30:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> <1360604561.4545.115.camel@revolution.hippie.lan> <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.com> <25EAEA1F-876A-4189-BCD4-A7D438332C11@kientzle.com> <5F763292-2EA4-426A-B84A-8DE533BA6308@bsdimp.com> To: Warner Losh 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: Wed, 13 Feb 2013 05:30:47 -0000 On Feb 12, 2013, at 10:45 AM, Warner Losh wrote: > But it doesn't have all the pin group stuff in yet, so I'll have to = chase that down and see what happened to that part of the early patches = I was reviewing=85 I would be interested in seeing those early patches. I agree that it would be best to bundle pinmux info with the related device in the FDT. Seeing some prior art would help a lot. Tim From owner-freebsd-arm@FreeBSD.ORG Wed Feb 13 05:45:58 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 5FD584E0 for ; Wed, 13 Feb 2013 05:45:58 +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 0BFFDBED for ; Wed, 13 Feb 2013 05:45:57 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1D5jqS3025970; Wed, 13 Feb 2013 05:45:52 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id yyik7izqu6ydkqcwi73v2ssgen; Wed, 13 Feb 2013 05:45:52 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: add versatilepb support to tim's script Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-2022-jp From: Tim Kientzle In-Reply-To: <5118ECD8.1040107@ff.iij4u.or.jp> Date: Tue, 12 Feb 2013 21:45:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3CA080CC-7CC7-4E88-B337-B8F2792310A9@kientzle.com> References: <511790F3.7070806@ff.iij4u.or.jp> <5118ECD8.1040107@ff.iij4u.or.jp> To: Takeshi Taguchi 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: Wed, 13 Feb 2013 05:45:58 -0000 Thank you very much! I've committed this to the project on github. Tim On Feb 11, 2013, at 5:06 AM, Takeshi Taguchi wrote: > Hi, Tim >=20 > Thanks for your suggestion. > Here is a update patch. > I'd test using qemu on windows. > it was seem work fine. >=20 > Thanks. > -- > T.T >=20 > 2013/02/11 10:00), Tim Kientzle wrote: >>=20 >> On Feb 10, 2013, at 4:22 AM, Takeshi Taguchi wrote: >>=20 >>> Hi, all >>> Attached patch add support versatilepb to tim's script: >>> https://github.com/kientzle/freebsd-beaglebone >>>=20 >>> use: >>> board_setup VersatilePB >>> in config.sh. and try to run: >>> sh beaglebine/sh >>> then you will get following images: >>> FreeBSD-VERSATILEPB.flash : kernel image >>> FreeBSD-VERSATILEPB.img : userland image >>>=20 >>> and then try to exec: >>> qemu-system-arm -M versatilepb -m 128M \ >>> -kernel FreeBSD-VERSATILEPB.flash \ >>> -cpu arm1176 \ >>> -hda FreeBSD-VERSATILEPB.img >>>=20 >>> Thanks. >>> - >>> T.T >>=20 >> Thank you! This is wonderful! >> I've merged this to the code on Github. >>=20 >> I only have one suggestion for improving it: >>=20 >> You use this code to get the kernel object file: >>=20 >> KERNELBIN=3D${WORKDIR}/obj/arm.armv6`realpath = ${FREEBSD_SRC}`/sys/${KERNCONF}/kernel.bin >>=20 >> then >>=20 >> dd of=3D$FLASH =1B$B!D=1B(B. if=3D$KERNELBIN >>=20 >> This approach is a little brittle. Elsewhere, >> I've used something similar to the following: >>=20 >> mkdir ${WORKDIR}/kernel >> freebsd_kernel_install ${WORKDIR}/kernel >> dd .... if=3D${WORKDIR}/kernel/.../kernel.bin >>=20 >> If this doesn't work, please consider adding a new >> function to lib/freebsd.sh to copy kernel.bin; that way, >> there will be only one place that knows about this >> kind of detail. (Rather than having copies of your >> code for every board.) >>=20 >> Tim >>=20 >>=20 >>=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" From owner-freebsd-arm@FreeBSD.ORG Wed Feb 13 06:17:16 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 77397BF8 for ; Wed, 13 Feb 2013 06:17:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x234.google.com (ia-in-x0234.1e100.net [IPv6:2607:f8b0:4001:c02::234]) by mx1.freebsd.org (Postfix) with ESMTP id 3B8A1D24 for ; Wed, 13 Feb 2013 06:17:16 +0000 (UTC) Received: by mail-ia0-f180.google.com with SMTP id f27so872963iae.39 for ; Tue, 12 Feb 2013 22:17:15 -0800 (PST) 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=/4J/S/KuhgtVFPwli+2N6zZYBG5hcLTvV5ArSy53yO8=; b=Km2PlQmruanIhSIIpjRg/shTnuk9lCf8zT/A9hsz9NATdESfI+r1KmrNWAXqFIcawz 0DkNjUHpxk+vxXzrYytTuDjzoUdqspwp3lmjGWC4JHoCn8pp7FJD0ckWCj82NJpZOMTo zHm+oopuz8lwZYOz1lur0s2aM4Cy3dOLZItXr9CG3ygA57wjtbM02HC5mbVUlIX0xVQi ElPzCFyrGx8oxousTqfLqz1DJpJinkXZhHl/7+4ly5OpDkk570dAdiFKVp7gXS0sYIdP TaQUmEx+HvG85E0NuFZLrV3A7dX3zPaniSS+LHGUcCo2VzYCHuvieevbK9o/jD5zGF3w tEgg== X-Received: by 10.43.65.145 with SMTP id xm17mr28594286icb.35.1360736235417; Tue, 12 Feb 2013 22:17:15 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id z1sm6163968igc.1.2013.02.12.22.17.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 22:17:14 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: Date: Tue, 12 Feb 2013 23:17:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <20ABD94C-206C-4936-BAE7-88D379F27B74@bsdimp.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> <1360604561.4545.115.camel@revolution.hippie.lan> <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.com> <25EAEA1F-876A-4189-BCD4-A7D438332C11@kientzle.com> <5F763292-2EA4-426A-B84A-8DE533BA6308@bsdimp.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQk88DbhJUgwyRFbJTyIb+ttla/emJehTNw8d6noUfsIBVdermePQYuDE0vJSFyuMYRyNAS8 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, 13 Feb 2013 06:17:16 -0000 On Feb 12, 2013, at 10:30 PM, Tim Kientzle wrote: > On Feb 12, 2013, at 10:45 AM, Warner Losh wrote: >=20 >> But it doesn't have all the pin group stuff in yet, so I'll have to = chase that down and see what happened to that part of the early patches = I was reviewing=85 >=20 > I would be interested in seeing those early patches. >=20 > I agree that it would be best to bundle pinmux info > with the related device in the FDT. Seeing some > prior art would help a lot. They were posted to the device-tree mailing list a while ago, but I = don't have a pointer to the archives :(... They were from somebody at = Atmel.com, so if you find it, it will be easy to search for. Warner From owner-freebsd-arm@FreeBSD.ORG Wed Feb 13 06:18:31 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 03D9DD51 for ; Wed, 13 Feb 2013 06:18:31 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x235.google.com (mail-ia0-x235.google.com [IPv6:2607:f8b0:4001:c02::235]) by mx1.freebsd.org (Postfix) with ESMTP id B6F64D2E for ; Wed, 13 Feb 2013 06:18:30 +0000 (UTC) Received: by mail-ia0-f181.google.com with SMTP id e16so601140iaa.40 for ; Tue, 12 Feb 2013 22:18:30 -0800 (PST) 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=cL5V0L7n17dT9aayXoqNjHLuqtqk21UqIUnl14kYBcU=; b=pHRKiUGPmhnUEqefFy7lcR3py9TR1Q/OLa8WeWznEeVuBzy0VU4ifTu0svBDA/C0z9 oIom4hQbMCukofxwSz+GDAP6F9T81wk4Z1snn8pJ8+CMegtIq8/ioRwTjs2ekKrwJB85 Qm9r80jr6iGqsuXf6RRcHk9b+K17ruvtDSwftRf/3GBRDe+N/ryA4ce5o9ZePXxfk3An fR/9RSl0ndPNqB0iaIghe+0Ht9Clj8Gou/orH1naGGbkLwEsy3+P8X+mhsNGpu9S/yAs +U40jijDVRw+KhDn4mJtjn4wFmleBBPBu6ewJSQYzRevnwv5tHjYMWlE6T6DrshtSFdJ TelQ== X-Received: by 10.50.57.168 with SMTP id j8mr9010605igq.51.1360736310356; Tue, 12 Feb 2013 22:18:30 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id fa6sm38745163igb.2.2013.02.12.22.18.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 22:18:29 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: Date: Tue, 12 Feb 2013 23:18:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <07B04C5F-EE7F-4516-A292-C275FA24FB54@bsdimp.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> <1360604561.4545.115.camel@revolution.hippie.lan> <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.com> <25EAEA1F-876A-4189-BCD4-A7D438332C11@kientzle.com> <5F763292-2EA4-426A-B84A-8DE533BA6308@bsdimp.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkkEUJ6zxKYRWjpsrrUlOR+jQOpkr7V4Es+NYt+mgLyktCPd/87QiPZbAyt67zPros7UOhB 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, 13 Feb 2013 06:18:31 -0000 On Feb 12, 2013, at 10:30 PM, Tim Kientzle wrote: > On Feb 12, 2013, at 10:45 AM, Warner Losh wrote: >=20 >> But it doesn't have all the pin group stuff in yet, so I'll have to = chase that down and see what happened to that part of the early patches = I was reviewing=85 >=20 > I would be interested in seeing those early patches. I'm off to bed, but I'll search tomorrow. In the mean time, you can = look for yourself at = https://lists.ozlabs.org/pipermail/devicetree-discuss/ Warner > I agree that it would be best to bundle pinmux info > with the related device in the FDT. Seeing some > prior art would help a lot. >=20 > Tim >=20 From owner-freebsd-arm@FreeBSD.ORG Wed Feb 13 08:20: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 DA59A331 for ; Wed, 13 Feb 2013 08:20:37 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id A09FA1C7 for ; Wed, 13 Feb 2013 08:20:37 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1D8KU40046893 for ; Wed, 13 Feb 2013 03:20:30 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 13 Feb 2013 03:20:30 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: Re: named kills raspberry pi Message-ID: <20130213032030.3da8fcb2@ivory.wynn.com> In-Reply-To: <20130207223038.ec308967273d6a16c41be97b@sohara.org> References: <20130207223038.ec308967273d6a16c41be97b@sohara.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 13 Feb 2013 08:20:37 -0000 On Thu, 7 Feb 2013 22:30:38 +0000 "Steve O'Hara-Smith" wrote: > Hi, > > As soon as I start named either by rc.d script or directly, > whether in an ssh session or directly on the video console, with or > without chroot, my early model 256MB model B pi locks up solid, no > response on console, all ssh sessions freeze, no response to ping, > nothing until power cycle. I can build ports all day long, but if I > start named everything stops dead. > > I'm using about a two day old head tree currently but it's > been happening for several days now since I first tried it. The uboot > (20130201) and script I use are from > http://people.freebsd.org/~gonzo/arm/rpi/ with minor changes to the > script (-j 4 and no pi user) and a kernel config that includes pf and > altq. I earlier used the older script and uboot with the same results. > > Any ideas on how I can coax some more useful detail out of > this ? > Steve- I built and installed bind 9.92 from ports to install in base on my Pi with 512M of memory a few days ago. It has been running as a caching name server ever since with no lockups. I did not try the bind included in base because the Pi image I started with did not have bind. It might be something not related to bind causing the lockup and bind is just pushing it over the edge. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 April 19, 1775 An English attempt to confiscate guns from Americans triggered a successful revolution...... Dear Congress, that's a hint. From owner-freebsd-arm@FreeBSD.ORG Wed Feb 13 10:29:48 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 E811EBF8 for ; Wed, 13 Feb 2013 10:29:48 +0000 (UTC) (envelope-from steve@sohara.org) Received: from uk1rly2283.eechost.net (relay01a.mail.uk1.eechost.net [217.69.40.75]) by mx1.freebsd.org (Postfix) with ESMTP id B22BD96F for ; Wed, 13 Feb 2013 10:29:48 +0000 (UTC) Received: from [31.186.37.179] (helo=smtp.marelmo.com) by uk1rly2283.eechost.net with esmtpa (Exim 4.72) (envelope-from ) id 1U5ZbB-00007y-B6; Wed, 13 Feb 2013 10:29:57 +0000 Received: from [192.168.63.1] (helo=steve.marelmo.com) by smtp.marelmo.com with smtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U5Zas-000FWD-Lf; Wed, 13 Feb 2013 10:29:38 +0000 Date: Wed, 13 Feb 2013 10:29:07 +0000 From: Steve O'Hara-Smith To: Brett Wynkoop Subject: Re: FIXED named kills raspberry pi Message-Id: <20130213102907.f96b0db61fc6fb7acd2ff5bc@sohara.org> In-Reply-To: <20130213032030.3da8fcb2@ivory.wynn.com> References: <20130207223038.ec308967273d6a16c41be97b@sohara.org> <20130213032030.3da8fcb2@ivory.wynn.com> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Auth-Info: 15567@permanet.ie (plain) 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, 13 Feb 2013 10:29:49 -0000 On Wed, 13 Feb 2013 03:20:30 -0500 Brett Wynkoop wrote: > Steve- > > I built and installed bind 9.92 from ports to install in base on my Pi > with 512M of memory a few days ago. It has been running as a caching > name server ever since with no lockups. > > I did not try the bind included in base because the Pi image I started > with did not have bind. > > It might be something not related to bind causing the lockup and bind > is just pushing it over the edge. You could well be right - at any rate with r246710 and Andrew Turner's patch named is now working fine. It took a while to verify because I made the mistake of trying a native buildworld with NFS mounted /usr/src and /usr/obj. -- Steve O'Hara-Smith From owner-freebsd-arm@FreeBSD.ORG Wed Feb 13 20:57: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 98A485F6 for ; Wed, 13 Feb 2013 20:57:36 +0000 (UTC) (envelope-from roel@bouwman.net) Received: from smtp01.qsp.nl (smtp01.qsp.nl [193.254.214.162]) by mx1.freebsd.org (Postfix) with ESMTP id 5C90AEDE for ; Wed, 13 Feb 2013 20:57:35 +0000 (UTC) Received: from smtp01.qsp.nl (localhost [127.0.0.1]) by smtp01.qsp.nl (Postfix) with ESMTP id 3F2F62A0C5D; Wed, 13 Feb 2013 21:51:39 +0100 (CET) Received: from nwg.bouwman.net (berl.bouwman.net [80.101.149.113]) by smtp01.qsp.nl (Postfix) with ESMTP; Wed, 13 Feb 2013 21:51:39 +0100 (CET) Received: from shuttle.bouwman.net (localhost [127.0.0.1]) by nwg.bouwman.net (Postfix) with ESMTP id 6B9ED45038; Wed, 13 Feb 2013 21:51:31 +0100 (CET) Received: (from roel@localhost) by shuttle.bouwman.net (8.14.6/8.14.6/Submit) id r1DKpUOn035214; Wed, 13 Feb 2013 21:51:30 +0100 (CET) (envelope-from roel@bouwman.net) X-Authentication-Warning: shuttle.bouwman.net: roel set sender to roel@bouwman.net using -f Date: Wed, 13 Feb 2013 21:51:30 +0100 From: Roel Bouwman To: Daisuke Aoyama Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Message-ID: <20130213205130.GK1485@shuttle.bouwman.net> References: <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> <20130131001553.GC67562@cicely7.cicely.de> <9E78813F3BF946A4A2FCEA2C363A847E@ad.peach.ne.jp> <016DDBBF-D502-4C76-96B5-BEE2D46FC6CC@exmandato.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i 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, 13 Feb 2013 20:57:36 -0000 Hi Daisuke, Haven't had time to do something with the Pi in the last month, but wanted to try your latest image today. However, it seems that you have switched from 4 to 8GB images for 20130130 and 20130215. This 8GB file from the newer images however is too large for my 8GB SD cards. They only have 15122432 512 byte sectors on them ("8GB" kingston micro SD card). Your image contains 153600000 512 byte sectors. Something else: I just came across a post on the Raspberry Pi news archive: http://www.raspberrypi.org/archives/3094 It seems that Alie Tan has also created a FreeBSD image and offered it to the Raspberry Pi foundation. It is downloadable from downloads.raspberrypi.org. It might however be a good idea to bundle efforts. Creating numerous different "distros" is not a good thing IMHO :-). To my surpise, I've seen posts from Alie on this list, but no announcement or remarks about this whatsoever. Regards, Roel. From owner-freebsd-arm@FreeBSD.ORG Wed Feb 13 21:05: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 02C73964 for ; Wed, 13 Feb 2013 21:05:42 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) by mx1.freebsd.org (Postfix) with ESMTP id 8EDC0F41 for ; Wed, 13 Feb 2013 21:05:41 +0000 (UTC) Received: from [192.168.1.102] (pool-173-77-66-237.nycmny.east.verizon.net [173.77.66.237]) (authenticated bits=0) by feynman.konjz.org (8.14.6/8.14.4) with ESMTP id r1DL5P8f040499 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 13 Feb 2013 16:05:31 -0500 (EST) (envelope-from george@ceetonetechnology.com) Message-ID: <511C0011.8040802@ceetonetechnology.com> Date: Wed, 13 Feb 2013 16:05:21 -0500 From: George Rosamond MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) References: <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> <20130131001553.GC67562@cicely7.cicely.de> <9E78813F3BF946A4A2FCEA2C363A847E@ad.peach.ne.jp> <016DDBBF-D502-4C76-96B5-BEE2D46FC6CC@exmandato.se> <20130213205130.GK1485@shuttle.bouwman.net> In-Reply-To: <20130213205130.GK1485@shuttle.bouwman.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 5.32 (*****) FH_HOST_EQ_VERIZON_P,RDNS_DYNAMIC X-Spam-Hits: 5320 X-Spam-Names: FH_HOST_EQ_VERIZON_P,RDNS_DYNAMIC X-Spam-Flag: YES X-Mail-Provider: KonjZ X-Scanned-By: MIMEDefang 2.73 on 64.147.119.39 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: george@ceetonetechnology.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 21:05:42 -0000 On 02/13/13 15:51, Roel Bouwman wrote: > Hi Daisuke, > > Haven't had time to do something with the Pi in the last month, but wanted > to try your latest image today. However, it seems that you have switched from > 4 to 8GB images for 20130130 and 20130215. > > This 8GB file from the newer images however is too large for my 8GB > SD cards. They only have 15122432 512 byte sectors on them ("8GB" kingston > micro SD card). Your image contains 153600000 512 byte sectors. A wonderful game in finding wide variations in SD cards... I know. > > Something else: I just came across a post on the Raspberry Pi news archive: > > http://www.raspberrypi.org/archives/3094 > > It seems that Alie Tan has also created a FreeBSD image and offered > it to the Raspberry Pi foundation. It is downloadable from > downloads.raspberrypi.org. It might however be a good idea to bundle > efforts. Creating numerous different "distros" is not a good thing > IMHO :-). To my surpise, I've seen posts from Alie on this list, but > no announcement or remarks about this whatsoever. Ah, the more the merrier IMHO. I am using Alie's image on a Pi now. I actually think it's a nice idea for some people to create custom images with specific functions, which we've discussed in NYC*BUG. Cleanly setup DNS, some sip-like functions, monitoring (like with sysmon), www with Hiawatha and what I'm doing with Tor on the BeagleBone and Raspberry Pi. Some people are going to hack away on the builds, and there are others who want it just to work and say, try a BSD on it. However, 'official' projects images would be nice at some point. g From owner-freebsd-arm@FreeBSD.ORG Thu Feb 14 03:37:24 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 35622DAA for ; Thu, 14 Feb 2013 03:37:24 +0000 (UTC) (envelope-from gregor@veverca.si) Received: from mail-bk0-f41.google.com (mail-bk0-f41.google.com [209.85.214.41]) by mx1.freebsd.org (Postfix) with ESMTP id C48D71B6 for ; Thu, 14 Feb 2013 03:37:23 +0000 (UTC) Received: by mail-bk0-f41.google.com with SMTP id q16so864825bkw.14 for ; Wed, 13 Feb 2013 19:37:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=0pP1eGrOaeep31NHdjOIIuxRev6liRK9IoLEDQ7LvIY=; b=WJ30EgcrFy69eV9i/ScRGYNE/pjT/FGQ2VFRZluWaWJsvzaPse4q/4cmYdQLWcGvyb Gu5vF0d07OSyCRSzkyWepMI3n5cLU47AjtSO4fSgxoYIJn9qLJ+gZgy3Qk4khCilCF0H AG2IOKIcVGxPaFLHKe6EzR0QcoXQQsGgBxRYmWKNY7sw4t6f6AUvMEBJjWjtvHgnMzJG 84Pj+12APAQt3JszNWaYauSBI0Xwodm7Fo77+qnz8/7Y2gDmoQ70atEQLCbY0n1TuULs MsFQVOzQVqEbO4si8ivC1Hq+eCdSLGHe4e3zTeLIMGbRdewt8wfX4y7sN+fhTMe+Alft Qf0A== MIME-Version: 1.0 X-Received: by 10.204.146.10 with SMTP id f10mr7254131bkv.116.1360813037416; Wed, 13 Feb 2013 19:37:17 -0800 (PST) Received: by 10.205.114.198 with HTTP; Wed, 13 Feb 2013 19:37:17 -0800 (PST) Date: Thu, 14 Feb 2013 04:37:17 +0100 Message-ID: Subject: GCC 4.2.2 or latest for ARM platform From: Gregor To: freebsd-arm@freebsd.org X-Gm-Message-State: ALoCoQlmhKfvr446AEI5eBYy1ulFUr5QraFUu3WQVNcnG3gm/mvHsYR1QT9PBGYntoPxwGv60VxG 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: Thu, 14 Feb 2013 03:37:24 -0000 Hello, im having a problem installing gcc on arm platform (raspberry). I tried to install gcc thru ports but it says that my platform isnt supported. Also i cant compile it together with kernel. Thanks for any help. Regards Gregor From owner-freebsd-arm@FreeBSD.ORG Thu Feb 14 05:35: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 9F825D0B for ; Thu, 14 Feb 2013 05:35:50 +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 74E35706 for ; Thu, 14 Feb 2013 05:35:49 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1E5Zdji033407; Thu, 14 Feb 2013 05:35:39 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id cpdm7ubwctpd4fm2n6d8sb2e5i; Thu, 14 Feb 2013 05:35:39 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <20ABD94C-206C-4936-BAE7-88D379F27B74@bsdimp.com> Date: Wed, 13 Feb 2013 21:35:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8FD7D8A3-A1FB-4499-A411-7CEF91387FF8@freebsd.org> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> <1360604561.4545.115.camel@revolution.hippie.lan> <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.com> <25EAEA1F-876A-4189-BCD4-A7D438332C11@kientzle.com> <5F763292-2EA4-426A-B84A-8DE533BA6308@bsdimp.com> <20ABD94C-206C-4936-BAE7-88D379F27B74@bsdimp.com> To: Warner Losh 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: Thu, 14 Feb 2013 05:35:50 -0000 On Feb 12, 2013, at 10:17 PM, Warner Losh wrote: >=20 > On Feb 12, 2013, at 10:30 PM, Tim Kientzle wrote: >=20 >> On Feb 12, 2013, at 10:45 AM, Warner Losh wrote: >>=20 >>> But it doesn't have all the pin group stuff in yet, so I'll have to = chase that down and see what happened to that part of the early patches = I was reviewing=85 >>=20 >> I would be interested in seeing those early patches. >>=20 >> I agree that it would be best to bundle pinmux info >> with the related device in the FDT. Seeing some >> prior art would help a lot. >=20 > They were posted to the device-tree mailing list a while ago, but I = don't have a pointer to the archives :(... They were from somebody at = Atmel.com, so if you find it, it will be easy to search for. >=20 > Warner >=20 I finally found the thread I think you're referring to, from January 2012. This looks like an interesting post because it gives some concrete ideas for what the device tree might look like (and the author gives some thoughtful critiques that I'll have to think about further): = https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-January/012015.= html Skimming some other discussions, it looks like the general idea a lot of folks are considering is: Having a pinmux node for whatever hardware controls pinmuxing. For the TI chip I'm working with, that would be the scm (System Control Module). Within that node, have a collection of named pinmux settings. E.g., pmx_ethernet01 or pmx_uart02 Within other hardware nodes, refer to those named settings, so you might have (very roughly; I still don't understand FDT syntax): uart02: uart@40800000 { compatible =3D "=85."; =85. pinmux =3D "pmx_uart02"; pinmuxc =3D "scm01"; } (That is, the uart02 should use scm01 to enable pmx_uart02 pinmux settings.) In particular, for hardware with multiple states, you could refer to multiple pinmux settings (e.g., an idle setting that tristated the outputs vs. an active setting that powered them). A lot of the debate seems to revolve around the details of whether the pinmux details should be lists of hardware numeric codes (advantage: eliminates tables from the pinmux driver source and eliminates lots of text from the DTS) or should be more verbose textual descriptions (advantage: easier to read and update). Is this generally what you had in mind? Tim From owner-freebsd-arm@FreeBSD.ORG Thu Feb 14 06:53:45 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 7F24C841 for ; Thu, 14 Feb 2013 06:53:45 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) by mx1.freebsd.org (Postfix) with ESMTP id 0E62395A for ; Thu, 14 Feb 2013 06:53:44 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id ef5so2070218obb.25 for ; Wed, 13 Feb 2013 22:53:44 -0800 (PST) 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=hnE//LUpQve8fTjis5LRLNE71Ey53AE4GRHD0iFaw3s=; b=aao18XIaq+ETc0RC/DgyyDaCQoBfOZAtnXQ5BfpqbcFvGFLXs+SSce4NWYaNn5l+u3 0Zb3w46WUz4dUWi7rFJP6AHIu/d4UUhzCxBJFFnECMq9rkmz+BsJB4wegmE0cA7+3W7v 4HlYvYyzllnWe9YgaKT9AWttpTOl32W3s8kzZ0cZoO4vpwiwvorXI2XQTQkRachGkbe5 0nZSlPjXL9n9qpwZA7JI95tzXohLqA8JOqXUj72sCGsrnbJ3jeYRnowYf3l/69/0xeLq i5l/E+tQ/5IRMKSHcEeJJv84CC7xPJHOgm7sHJux50l9WWFsB9sHLoNZd6Vr4pnq75nk eMiA== X-Received: by 10.182.167.70 with SMTP id zm6mr18904711obb.93.1360824823974; Wed, 13 Feb 2013 22:53:43 -0800 (PST) Received: from 53.imp.bsdimp.com ([209.117.142.2]) by mx.google.com with ESMTPS id v2sm59934398obl.10.2013.02.13.22.53.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 22:53:43 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: <8FD7D8A3-A1FB-4499-A411-7CEF91387FF8@freebsd.org> Date: Wed, 13 Feb 2013 23:53:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4EC0D89B-3B17-4650-BCCF-8CA0B83E746E@bsdimp.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> <1360604561.4545.115.camel@revolution.hippie.lan> <72554169-D2DD-48DD-8C2F-6C411DBFCE4D@kientzle.com> <25EAEA1F-876A-4189-BCD4-A7D438332C11@kientzle.com> <5F763292-2EA4-426A-B84A-8DE533BA6308@bsdimp.com> <20ABD94C-206C-4936-BAE7-88D379F27B74@bsdimp.com> <8FD7D8A3-A1FB-4499-A411-7CEF91387FF8@freebsd.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQl8MKNQkOtDgVFCuwj17VQQwN9fadsaqBWxY5ux/21ftaioeA3Bq2M4V1xeyDkK1570Pzmo 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, 14 Feb 2013 06:53:45 -0000 On Feb 13, 2013, at 10:35 PM, Tim Kientzle wrote: >=20 > On Feb 12, 2013, at 10:17 PM, Warner Losh wrote: >=20 >>=20 >> On Feb 12, 2013, at 10:30 PM, Tim Kientzle wrote: >>=20 >>> On Feb 12, 2013, at 10:45 AM, Warner Losh wrote: >>>=20 >>>> But it doesn't have all the pin group stuff in yet, so I'll have to = chase that down and see what happened to that part of the early patches = I was reviewing=85 >>>=20 >>> I would be interested in seeing those early patches. >>>=20 >>> I agree that it would be best to bundle pinmux info >>> with the related device in the FDT. Seeing some >>> prior art would help a lot. >>=20 >> They were posted to the device-tree mailing list a while ago, but I = don't have a pointer to the archives :(... They were from somebody at = Atmel.com, so if you find it, it will be easy to search for. >>=20 >> Warner >>=20 >=20 >=20 > I finally found the thread I think you're referring to, from > January 2012. This looks like an interesting post > because it gives some concrete ideas for what the > device tree might look like (and the author gives > some thoughtful critiques that I'll have to think about > further): >=20 > = https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-January/012015.= html >=20 > Skimming some other discussions, it looks like the general > idea a lot of folks are considering is: >=20 > Having a pinmux node for whatever hardware controls > pinmuxing. For the TI chip I'm working with, that would be > the scm (System Control Module). >=20 > Within that node, have a collection of named pinmux settings. > E.g., pmx_ethernet01 or pmx_uart02 >=20 > Within other hardware nodes, refer to those named > settings, so you might have (very roughly; I still don't > understand FDT syntax): >=20 > uart02: uart@40800000 { > compatible =3D "=85."; > =85. > pinmux =3D "pmx_uart02"; > pinmuxc =3D "scm01"; > } >=20 > (That is, the uart02 should use scm01 to enable > pmx_uart02 pinmux settings.) In particular, for > hardware with multiple states, you could refer > to multiple pinmux settings (e.g., an idle setting > that tristated the outputs vs. an active setting > that powered them). >=20 > A lot of the debate seems to revolve around the details > of whether the pinmux details should be lists of hardware > numeric codes (advantage: eliminates tables from > the pinmux driver source and eliminates lots of text > from the DTS) or should be more verbose textual > descriptions (advantage: easier to read and update). >=20 > Is this generally what you had in mind? Generally, yes. The thread I had seen was a different one, but one quite = similar in tone.... Warner From owner-freebsd-arm@FreeBSD.ORG Fri Feb 15 03:19:53 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 8BDA4F5A; Fri, 15 Feb 2013 03:19:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 517FFE9C; Fri, 15 Feb 2013 03:19:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1F3JkOt017906; Thu, 14 Feb 2013 22:19:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1F3Jk8L017905; Fri, 15 Feb 2013 03:19:46 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 15 Feb 2013 03:19:46 GMT Message-Id: <201302150319.r1F3Jk8L017905@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 03:19:53 -0000 TB --- 2013-02-15 01:40:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-15 01:40:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-15 01:40:19 - starting HEAD tinderbox run for arm/arm TB --- 2013-02-15 01:40:19 - cleaning the object tree TB --- 2013-02-15 01:40:19 - /usr/local/bin/svn stat /src TB --- 2013-02-15 01:40:23 - At svn revision 246816 TB --- 2013-02-15 01:40:24 - building world TB --- 2013-02-15 01:40:24 - CROSS_BUILD_TESTING=YES TB --- 2013-02-15 01:40:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-15 01:40:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-15 01:40:24 - SRCCONF=/dev/null TB --- 2013-02-15 01:40:24 - TARGET=arm TB --- 2013-02-15 01:40:24 - TARGET_ARCH=arm TB --- 2013-02-15 01:40:24 - TZ=UTC TB --- 2013-02-15 01:40:24 - __MAKE_CONF=/dev/null TB --- 2013-02-15 01:40:24 - cd /src TB --- 2013-02-15 01:40:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 15 01:40:29 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 /src/sbin/fsdb/fsdb.c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/../fsck_ffs/dir.c /src/sbin/fsdb/../fsck_ffs/ea.c /src/sbin/fsdb/../fsck_ffs/fsutil.c /src/sbin/fsdb/../fsck_ffs/inode.c /src/sbin/fsdb/../fsck_ffs/pass1.c /src/sbin/fsdb/../fsck_ffs/pass1b.c /src/sbin/fsdb/../fsck_ffs/pass2.c /src/sbin/fsdb/../fsck_ffs/pass3.c /src/sbin/fsdb/../fsck_ffs/pass4.c /src/sbin/fsdb/../fsck_ffs/pass5.c /src/sbin/fsdb/../fsck_ffs/setup.c /src/sbin/fsdb/../fsck_ffs/utilities.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_subr.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_tables.c echo fsdb: /obj/arm.arm/src/tmp/usr/lib/libc.a /obj/arm.arm/src/tmp/usr/lib/libedit.a /obj/arm.arm/src/tmp/usr/lib/libtermcap.a >> .depend cc -O -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdb.c cc -O -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/fsdbutil.c: In function 'printindir': /src/sbin/fsdb/fsdbutil.c:242: error: 'struct bufarea' has no member named 'b_prev' /src/sbin/fsdb/fsdbutil.c:242: error: 'struct bufarea' has no member named 'b_next' *** [fsdbutil.o] Error code 1 Stop in /src/sbin/fsdb. *** [fsdb_make] Error code 1 Stop in /obj/arm.arm/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-15 03:19:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-15 03:19:46 - ERROR: failed to build world TB --- 2013-02-15 03:19:46 - 4878.12 user 845.40 system 5966.59 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Fri Feb 15 05:04:17 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 9B0E61E3; Fri, 15 Feb 2013 05:04:17 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4AE411FD; Fri, 15 Feb 2013 05:04:16 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1F54FxU079714; Fri, 15 Feb 2013 00:04:15 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Fri, 15 Feb 2013 00:04:15 -0500 From: Brett Wynkoop To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Can not build world Message-ID: <20130215000415.7dea3055@ivory.wynn.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 15 Feb 2013 05:04:17 -0000 Greeting- For the past week I have been unable to build world for arm on my Raspberry Pi. The process broke just after I updated /usr/src. Several updates in the intervening week have done nothing to change the results. It always bombs trying to build kerberos. Please no suggestions to cross build world. If that is the answer you must be thinking of the wrong question. At the moment consider my only working FreeBSD boxes are a Raspberry Pi with 512Meg of ram and 16 G of disk and a BeagleBone with 256 M of ram and 8G of disk. Needless to say I have not updated /usr/src on the BeagleBone, and will not until the issue on the Pi is resolved. FYI I am not subscribed to freebsd-current, only freebsd-arm, so if you reply to current please keep freebsd-arm in the cc list as well. I always do a make clean before trying the make buildworld. I am really stuck here. I also know others in the arm world had this problem in the recent past, but it started to work for them after another update to /usr/src. That has not happened for me. root@fbsd-pi:~ # uname -a FreeBSD fbsd-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #1: Mon Feb 11 18:03:38 EST 2013 root@fbsd-pi:/sys/arm/compile/RPI-B-TMPFS arm ===> include/rpc (installincludes) sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 /usr/src/include/rpc/auth.h /usr/src/include/rpc/auth_unix.h /usr/src/include/rpc/clnt.h /usr/src/include/rpc/clnt_soc.h /usr/src/include/rpc/clnt_stat.h /usr/src/include/rpc/nettype.h /usr/src/include/rpc/pmap_clnt.h /usr/src/include/rpc/pmap_prot.h /usr/src/include/rpc/pmap_rmt.h /usr/src/include/rpc/raw.h /usr/src/include/rpc/rpc.h /usr/src/include/rpc/rpc_msg.h /usr/src/include/rpc/rpcb_clnt.h /usr/src/include/rpc/rpcent.h /usr/src/include/rpc/rpc_com.h /usr/src/include/rpc/rpcsec_gss.h /usr/src/include/rpc/svc.h /usr/src/include/rpc/svc_auth.h /usr/src/include/rpc/svc_soc.h /usr/src/include/rpc/svc_dg.h /usr/src/include/rpc/xdr.h /usr/src/include/rpc/auth_des.h /usr/src/include/rpc/des.h /usr/src/include/rpc/des_crypt.h /usr/src/include/rpc/auth_kerb.h /usr/src/include/rpc/rpcb_prot.x rpcb_prot.h /usr/obj/usr/src/tmp/usr/include/rpc ===> include/xlocale (installincludes) sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 _ctype.h _inttypes.h _langinfo.h _locale.h _monetary.h _stdio.h _stdlib.h _string.h _time.h _wchar.h /usr/obj/usr/src/tmp/usr/include/xlocale ===> kerberos5 (includes) set -e; cd /usr/src/kerberos5; /usr/obj/usr/src/make.arm/make buildincludes; /usr/obj/usr/src/make.arm/make installincludes ===> kerberos5/doc (buildincludes) ===> kerberos5/lib (buildincludes) ===> kerberos5/lib/libasn1 (buildincludes) compile_et /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/asn1_err.et compile_et: No such file or directory *** [asn1_err.h] Error code 1 Stop in /usr/src/kerberos5/lib/libasn1. *** [buildincludes] Error code 1 Stop in /usr/src/kerberos5/lib. *** [buildincludes] Error code 1 Stop in /usr/src/kerberos5. *** [includes] Error code 1 Stop in /usr/src/kerberos5. *** [kerberos5.includes__D] Error code 1 Stop in /usr/src. *** [_includes] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. Help! Thanks! -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 "The strongest reason for the people to retain the right to keep and bear arms is, as a last resort, to protect themselves against tyranny in government" - Thomas Jefferson. From owner-freebsd-arm@FreeBSD.ORG Fri Feb 15 05:39: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 5103F9C0 for ; Fri, 15 Feb 2013 05:39:47 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id C986631A for ; Fri, 15 Feb 2013 05:39:46 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1F5djQN080088; Fri, 15 Feb 2013 00:39:45 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Fri, 15 Feb 2013 00:39:45 -0500 From: Brett Wynkoop To: talk@lists.nycbug.org, freebsd-arm@freebsd.org Subject: Fw: BIND 10 - 1.0.0 Release Candidate Message-ID: <20130215003945.4a8920f8@ivory.wynn.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 15 Feb 2013 05:39:47 -0000 Begin forwarded message: Date: Thu, 14 Feb 2013 21:25:44 -0600 (CST) From: "Jeremy C. Reed" Subject: BIND 10 - 1.0.0 Release Candidate -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 BIND 10 - 1.0.0 Release Candidate Welcome to the first release candidate toward the first production BIND 10 1.0.0 release. BIND 10 provides a C++ library for DNS (with python wrappers) and several cooperating daemons for providing authoritative DNS service (with in-memory and SQLite3 backends and DNSSEC support), dynamic DNS, zone transfers, and experimental forwarding and recursive name service. Supplementary components are included for statistics collection and reporting and remote configuration and control. This version of BIND 10 also includes the latest snapshot of the BIND 10 DHCP development. The snapshot includes a C++ library for DHCP and two DHCP servers, one for IPv4 and one for IPv6. Features of these servers are: * Able to allocate and renew addresses, and handle lease expiration and releases. * Supports a subset of clients: - DHCPv4 clients connected to the server via a relay. - DHCPv6 clients on the same LAN as the server. * Able to configure values for standard options returned to a client, either globally or on a per-subnet basis. * Able to define new options and configure them in the same way as standard options. * Leases are stored in a MySQL database. * Configuration, logging and process control uses the same mechanisms as the BIND 10 DNS server. Note: The default testing account and password for bindctl/b10-cmdctl is now removed; a new account for remote configuration and control can be created with b10-cmdctl-usermgr, for example: b10-cmdctl-usermgr --file /usr/local/etc/bind10/cmdctl-accounts.csv We are looking for testers to provide feedback about using this release candidate. For more information about BIND 10, the release schedule, and the community testing plans, please see: http://bind10.isc.org/wiki/ProductionRelease Documentation is included and also available via the BIND 10 website at http://bind10.isc.org/ The bind10-1.0.0-rc source may be downloaded from: ftp://ftp.isc.org/isc/bind10/1.0.0-rc/bind10-1.0.0-rc.tar.gz A PGP signature of the distribution is at ftp://ftp.isc.org/isc/bind10/1.0.0-rc/bind10-1.0.0-rc.tar.gz.sha512.asc The signature was generated with the ISC code signing key which is available at https://www.isc.org/about/openpgp A summary of the significant changes since the previous release include (from the ChangeLog): 580. [func]* muks There is no longer a default user account. The old default account with username 'root' has been removed. In a fresh installation of BIND 10, the administrator has to configure a user account using the b10-cmdctl-usermgr program. (Trac #2641, git 54e8f4061f92c2f9e5b8564240937515efa6d934) 579. [bug] jinmei libdatasrc/b10-auth: corrected some corner cases in query handling of in-memory data source that led to the following invalid/odd responses from b10-auth: - duplicate RRs in answer and additional for type ANY query - incorrect NSEC for no error, no data (NXRRSET) response that matches a wildcard (Trac #2585, git abe78fae4ba3aca5eb01806dd4e05607b1241745) 578. [bug] jinmei b10-auth now returns closest encloser NSEC3 proof to queries for an empty non terminal derived from an Opt-Out NSEC RR, as clarified in errata 3441 for RFC5155. Previously it regarded such case as broken zone and returned SERVFAIL. (Trac #2659, git 24c235cb1b379c6472772d340e21577c3460b742) 577. [func] muks Added an SQLite3 index on records(rname, rdtype). This decreases insert performance by ~28% and adds about ~20% to the file size, but increases zone iteration performance. As it introduces a new index, a database upgrade would be required. (Trac #1756, git 9b3c959af13111af1fa248c5010aa33ee7e307ee) 576. [bug] tmark, tomek b10-dhcp6: Fixed bug when the server aborts operation when receiving renew and there are no IPv6 subnets configured. (Trac #2719, git 3132b8b19495470bbfd0f2ba0fe7da443926034b) 575. [bug] marcin b10-dhcp6: Fixed the bug whereby the subnet for the incoming packet was selected using only its source address. The subnet is now selected using either source address or the name of the server's interface on which the packet has been received. (Trac #2704, git 1cbacf19a28bdae50bb9bd3767bca0147fde37ed) 574. [func] tmark b10-dhcp4, b10-dhcp6: Composite key indexes were added to the lease tables to reduce lease search time. The lease4 table now has two additional indexes: a) hwaddr/subnet_id and b) client_id/subnet_id. The lease6 now has the one additional index: iaid/subnet_id/duid. Adding these indexes significantly improves lease acquisition performance. (Trac #2699,#2703, git 54bbed5fcbe237c5a49b515ae4c55148723406ce) 573. [bug] stephen Fixed problem whereby the DHCP server crashed if it ran out of addresses. Such a condition now causes a packet to be returned to the client refusing the allocation of an address. (Trac #2681, git 87ce14cdb121b37afb5b1931af51bed7f6323dd6) 572. [bug] marcin perfdhcp: Fixed bug where the command line switches used to run the perfdhcp where printed as ASCII codes. (Trac #2700, git b8d6b949eb7f4705e32fbdfd7694ca2e6a6a5cdc) 571. [build] jinmei The ./configure script can now handle output from python-config --ldflags that contains a space after -L switches. This fixes failure reported on some Solaris environments. (Trac #2661, git e6f86f2f5eec8e6003c13d36804a767a840d96d6) 570. [bug] tmark, marcin, tomek b10-dhcp4: Address renewal now works properly for DHCPv4 clients that do not send client ID. (Trac #2702, git daf2abe68ce9c111334a15c14e440730f3a085e2) 569. [bug] tomek b10-dhcp4: Fix bug whereby a DHCP packet without a client ID could crash the MySQL lease database backend. (Trac #2697, git b5e2be95d21ed750ad7cf5e15de2058aa8bc45f4) 568. [func] muks Various message IDs have been renamed to remove the word 'ERROR' from them when they are not logged at ERROR severity level. (Trac #2672, git 660a0d164feaf055677f375977f7ed327ead893e) 567. [doc] marcin, stephen, tomek Update DHCP sections of the BIND 10 guide. (Trac #2657, git 1d0c2004865d1bf322bf78d13630d992e39179fd) 566. [func]* jinmei libdns++/Python isc.dns: In Python isc.dns, function style constants for RRType, RRClass, Rcode and Opcode were deprecated and replaced with straightforward object constants, e.g., from RRType.AAAA() to RRType.AAAA. This is a backward incompatible change (see the Trac ticket for a conversion script if needed). Also, these constants are now more consistent between C++ and Python, and RRType constants for all currently standardized types are now supported (even if Rdata for these are not yet available). (Trac #1866 and #2409, git e5005185351cf73d4a611407c2cfcd163f80e428) 565. [func]* jelte The main initializer script (formerly known as either 'bind10', 'boss', or 'bob'), has been renamed to b10-init (and Init in configuration). Configuring which components are run is henceforth done through '/Init/components', and the sbin/bind10 script is now simply a shellscript that runs b10-init. Existing configuration is automatically updated. NOTE: once configuration with this update has been saved (by committing any new change with bindctl), you cannot run older versions of BIND 10 anymore with this configuration. (Trac #1901, git bae3798603affdb276f370c1ac6b33b011a5ed4f) 564. [func] muks libdns++: the CNAME, DNAME, MX, NS, PTR and SRV Rdata classes now use the generic lexer in constructors from text. This means that the name fields in such RRs in a zone file can now be non-absolute (the origin name in that context will be used), e.g., when loaded by b10-loadzone. One additional change to the libdns++ API is that the existing string constructors for these Rdata classes also use the generic lexer, and they now expect an absolute name (with the trailing '.') in the name fields. (Trac #2390, git a01569277cda3f78b1171bbf79f15ecf502e81e2) (Trac #2656, git 5a0d055137287f81e23fbeedd35236fee274596d) 563. [build] jinmei Added --disable-rpath configure option to avoid embedding library paths to binaries. Patch from Adam Tkac. (Trac #2667, git 1c50c5a6ee7e9675e3ab154f2c7f975ef519fca2) 562. [func]* vorner The b10-xfrin now performs basic sanity check on just received zone. It'll reject severely broken zones (such as missing NS records). (Trac #2439, git 44699b4b18162581cd1dd39be5fb76ca536012e6) 561. [bug] kambe, jelte b10-stats-httpd no longer dumps request information to the console, but uses the bind10 logging system. Additionally, the logging identifiers have been changed from STATHTTPD_* to STATSHTTPD_* (Trac #1897, git 93716b025a4755a8a2cbf250a9e4187741dbc9bb) 560. [bug] jinmei b10-auth now sets the TTL of SOA RR for negative responses to the minimum of the RR TTL and the minimum TTL of the SOA RDATA as specified in RFC2308; previously the RR TTL was always used. The ZoneFinder class was extended partly for implementing this and partly for allowing further optimization. (Trac #2309 and #2635, git ee17e979fcde48b59d91c74ac368244169065f3b) 559. [bug] jelte b10-cmdctl no longer aborts on basic file issues with its https certificate or private key file. It performs additional checks, and provides better error logs if these fail. Additionally, bindctl provides a better error report if it is unable to connect over https connection. This issue could occur if BIND 10 was installed with root privileges but then started as a normal user. (Trac #2595, git 09b1a2f927483b407d70e98f5982f424cc872149) 558. [func] marcin b10-dhcp4: server now adds configured options to its responses to a client when client requests them. A few basic options: Routers, Domain Name, Domain Name Servers and Subnet Mask are added regardless if client requested them or not. (Trac #2591, git aeec2dc1b9c511d17971ac63138576c37e7c5164) 557. [doc] stephen Update DHCP sections of the BIND 10 guide. (Trac #2642, git e5faeb5fa84b7218fde486347359504cf692510e) 556. [bug] marcin Fixed DHCP servers configuration whereby the servers did not receive a configuration stored in the database on their startup. Also, the configuration handler function now uses full configuration instead of partial to configure the server. This guarantees that dependencies between various configuration parameters are fulfilled. (Trac #2637, git 91aa998226f1f91a232f2be59a53c9568c4ece77) 555. [func] marcin The encapsulated option space name can be specified for a DHCP option. It comprises sub-options being sent within an option that encapsulates this option space. (Trac #2314, git 27e6119093723a1e46a239ec245a8b4b10677635) 554. [func] jinmei b10-loadzone: improved completion log message and intermediate reports: It now logs the precise number of loaded RRs on completion, and intermediate reports show additional information such as the estimated progress in percentage and estimated time to complete. (Trac #2574, git 5b8a824054313bdecb8988b46e55cb2e94cb2d6c) 553. [func] stephen Values of the parameters to access the DHCP server lease database can now be set through the BIND 10 configuration mechanism. (Trac #2559, git 6c6f405188cc02d2358e114c33daff58edabd52a) 552. [bug] shane Build on Raspberry PI. The main issue was use of char for reading from input streams, which is incorrect, as EOF is returned as an int -1, which would then get cast into a char -1. A number of other minor issues were also fixed. (Trac #2571, git 525333e187cc4bbbbde288105c9582c1024caa4a) 551. [bug] shane Kill msgq if we cannot connect to it on startup. When the boss process was unable to connect to the msgq, it would exit. However, it would leave the msgq process running. This has been fixed, and the msgq is now stopped in this case. (Trac #2608, git 016925ef2437e0396127e135c937d3a55539d224) 550. [func] tomek b10-dhcp4: The DHCPv4 server now generates a server identifier the first time it is run. The identifier is preserved in a file across server restarts. b10-dhcp6: The server identifier is now preserved in a file across server restarts. (Trac #2597, git fa342a994de5dbefe32996be7eebe58f6304cff7) 549. [func] tomek b10-dhcp6: It is now possible to specify that a configured subnet is reachable locally over specified interface (see "interface" parameter in Subnet6 configuration). (Trac #2596, git a70f6172194a976b514cd7d67ce097bbca3c2798) 548. [func] vorner The message queue daemon now appears on the bus. This has two effects, one is it obeys logging configuration and logs to the correct place like the rest of the modules. The other is it appears in bindctl as module (but it doesn't have any commands or configuration yet). (Trac #2582, git ced31d8c5a0f2ca930b976d3caecfc24fc04634e) 547. [func]* vorner The b10-loadzone now performs more thorough sanity check on the loaded data. Some of the checks are now fatal and zone failing them will be rejected. (Trac #2436, git 48d999f1cb59f308f9f30ba2639521d2a5a85baa) 546. [func] marcin DHCP option definitions can be now created using the Configuration Manager. The option definition specifies the option code, name and the types of the data being carried by the option. The Configuration Manager reports an error on attempt to override standard DHCP option definition. (Trac #2317, git 71e25eb81e58a695cf3bad465c4254b13a50696e) 545. [func] jinmei libdns++: the SOA Rdata class now uses the generic lexer in constructors from text. This means that the MNAME and RNAME of an SOA RR in a zone file can now be non absolute (the origin name in that context will be used), e.g., when loaded by b10-loadzone. (Trac #2500, git 019ca218027a218921519f205139b96025df2bb5) 544. [func] tomek b10-dhcp4: Allocation engine support for IPv4 added. Currently supported operations are server selection (Discover/Offer), address assignment (Request/Ack), address renewal (Request/Ack), and address release (Release). Expired leases can be reused. Some options (e.g. Router Option) are still hardcoded, so the DHCPv4 server is not yet usable, although its address allocation is operational. (Trac #2320, git 60606cabb1c9584700b1f642bf2af21a35c64573) 543. [func]* jelte When calling getFullConfig() as a module, , the configuration is now returned as properly-structured JSON. Previously, the structure had been flattened, with all data being labelled by fully-qualified element names. (Trac #2619, git bed3c88c25ea8f7e951317775e99ebce3340ca22) 542. [func] marcin Created OptionSpace and OptionSpace6 classes to represent DHCP option spaces. The option spaces are used to group instances and definitions of options having uniqe codes. A special type of option space is the so-called "vendor specific option space" which groups sub-options sent within Vendor Encapsulated Options. The new classes are not used yet but they will be used once the creation of option spaces by configuration manager is implemented. (Trac #2313, git 37a27e19be874725ea3d560065e5591a845daa89) 541. [func] marcin Added routines to search for configured DHCP options and their definitions using name of the option space they belong to. New routines are called internally from the DHCPv4 and DHCPv6 servers code. (Trac #2315, git 741fe7bc96c70df35d9a79016b0aa1488e9b3ac8) 540. [func] marcin DHCP Option values can be now specified using a string of tokens separated with comma sign. Subsequent tokens are used to set values for corresponding data fields in a particular DHCP option. The format of the token matches the data type of the corresponding option field: e.g. "192.168.2.1" for IPv4 address, "5" for integer value etc. (Trac #2545, git 792c129a0785c73dd28fd96a8f1439fe6534a3f1) 539. [func] stephen Add logging to the DHCP server library. (Trac #2524, git b55b8b6686cc80eed41793c53d1779f4de3e9e3c) 538. [bug] muks Added escaping of special characters (double-quotes, semicolon, backslash, etc.) in text-like RRType's toText() implementation. Without this change, some TXT and SPF RDATA were incorrectly stored in SQLite3 datasource as they were not escaped. (Trac #2535, git f516fc484544b7e08475947d6945bc87636d4115) 537. [func] tomek b10-dhcp6: Support for RELEASE message has been added. Clients are now able to release their non-temporary IPv6 addresses. (Trac #2326, git 0974318566abe08d0702ddd185156842c6642424) 536. [build] jinmei Detect a build issue on FreeBSD with g++ 4.2 and Boost installed via FreeBSD ports at ./configure time. This seems to be a bug of FreeBSD ports setup and has been reported to the maintainer: http://www.freebsd.org/cgi/query-pr.cgi?pr=174753 Until it's fixed, you need to build BIND 10 for FreeBSD that has this problem with specifying --without-werror, with clang++ (development version), or with manually extracted Boost header files (no compiled Boost library is necessary). (Trac #1991, git 6b045bcd1f9613e3835551cdebd2616ea8319a36) 535. [bug] jelte The log4cplus internal logging mechanism has been disabled, and no output from the log4cplus library itself should be printed to stderr anymore. This output can be enabled by using the compile-time option --enable-debug. (Trac #1081, git db55f102b30e76b72b134cbd77bd183cd01f95c0) 534. [func]* vorner The b10-msgq now uses the same logging format as the rest of the system. However, it still doesn't obey the common configuration, as due to technical issues it is not able to read it yet. (git 9e6e821c0a33aab0cd0e70e51059d9a2761f76bb) Thanks again to those who contributed bug reports, code, and reviews. Bugs may be reported as tickets via the developers website (after logging into Trac) at: http://bind10.isc.org/ Please feel free to participate and share your feedback on the BIND 10 mailing lists: https://lists.isc.org/mailman/listinfo/bind10-users https://lists.isc.org/mailman/listinfo/bind10-dev Jeremy C. Reed ISC Release Engineering -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (NetBSD) iEYEARECAAYFAlEdqlYACgkQs9Bv5D4YwC3t9QCdFmHE9bVZq0WRa4E1pq5t1JtK CMgAoNTXHYMMlvMU6bzARXBOsgYq2ZW5 =JulM -----END PGP SIGNATURE----- -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 I would never invade the United States. There would be a gun behind every blade of grass. --Isoroku Yamamoto From owner-freebsd-arm@FreeBSD.ORG Fri Feb 15 06:03:22 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 AC0C7E3B; Fri, 15 Feb 2013 06:03:22 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA353FB; Fri, 15 Feb 2013 06:03:22 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r1F63GG7099607; Thu, 14 Feb 2013 22:03:16 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r1F63GfB099606; Thu, 14 Feb 2013 22:03:16 -0800 (PST) (envelope-from sgk) Date: Thu, 14 Feb 2013 22:03:16 -0800 From: Steve Kargl To: Brett Wynkoop Subject: Re: Can not build world Message-ID: <20130215060316.GA99547@troutmask.apl.washington.edu> References: <20130215000415.7dea3055@ivory.wynn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130215000415.7dea3055@ivory.wynn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm@freebsd.org, freebsd-current@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, 15 Feb 2013 06:03:22 -0000 On Fri, Feb 15, 2013 at 12:04:15AM -0500, Brett Wynkoop wrote: > (installincludes) sh /usr/src/tools/install.sh -C -o root -g wheel -m > 444 _ctype.h _inttypes.h _langinfo.h _locale.h _monetary.h _stdio.h > _stdlib.h _string.h _time.h > _wchar.h /usr/obj/usr/src/tmp/usr/include/xlocale ===> kerberos5 > (includes) set -e; > cd /usr/src/kerberos5; /usr/obj/usr/src/make.arm/make > buildincludes; /usr/obj/usr/src/make.arm/make installincludes ===> > kerberos5/doc (buildincludes) ===> kerberos5/lib (buildincludes) ===> > kerberos5/lib/libasn1 (buildincludes) > compile_et /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/asn1_err.et > compile_et: No such file or directory *** [asn1_err.h] Error code 1 > > Stop in /usr/src/kerberos5/lib/libasn1. > *** [buildincludes] Error code 1 > Easy button: Add WITHOUT_KERBEROS to /etc/make.conf. See email archive for long story. The short story. You did not have kerberos on your system, which means that compile_et is not present in /usr/bin. Now, you want kerberos and kerberos does not build compile_et as a bootstrap tool. So, now you need to manually install compile_et. The fun really begins because you need some header/library from kerberos to build compile_et. So, once you figure out which header/library you need, you build and install it. Then build and install compile_et. And, finally, you can make world. -- Steve From owner-freebsd-arm@FreeBSD.ORG Fri Feb 15 07:00:58 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 B5F8877C; Fri, 15 Feb 2013 07:00:58 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 789D97A4; Fri, 15 Feb 2013 07:00:57 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1F70twG081066; Fri, 15 Feb 2013 02:00:55 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Fri, 15 Feb 2013 02:00:55 -0500 From: Brett Wynkoop To: Steve Kargl Subject: Re: Can not build world Message-ID: <20130215020055.3d242ed0@ivory.wynn.com> In-Reply-To: <20130215060316.GA99547@troutmask.apl.washington.edu> References: <20130215000415.7dea3055@ivory.wynn.com> <20130215060316.GA99547@troutmask.apl.washington.edu> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, freebsd-current@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, 15 Feb 2013 07:00:58 -0000 Greeting- Thanks to both you and gonzo for the fast informed responses! On Thu, 14 Feb 2013 22:03:16 -0800 Steve Kargl wrote: SNIIP > > compile_et /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/asn1_err.et > > compile_et: No such file or directory *** [asn1_err.h] Error code 1 > > > > Stop in /usr/src/kerberos5/lib/libasn1. > > *** [buildincludes] Error code 1 > > > > Easy button: Add WITHOUT_KERBEROS to /etc/make.conf. After this past week I appreciate the easy button! > > See email archive for long story. > > The short story. You did not have kerberos on your > system, which means that compile_et is not present > in /usr/bin. Now, you want kerberos and kerberos > does not build compile_et as a bootstrap tool. So, > now you need to manually install compile_et. The > fun really begins because you need some header/library > from kerberos to build compile_et. So, once you figure > out which header/library you need, you build and install > it. Then build and install compile_et. And, finally, > you can make world. > > I appreciate the short story. I like to understand the how/why of things. I am giving this a try, but it still begs the question that since I never changed make.conf before and never made any choices about building or not building kerberos why it broke all of the sudden. What changed? I am also going to test Gonzo's solution. I will report back what I find. -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 April 19, 1775 An English attempt to confiscate guns from Americans triggered a successful revolution...... Dear Congress, that's a hint. From owner-freebsd-arm@FreeBSD.ORG Fri Feb 15 09:03:48 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 031662A0; Fri, 15 Feb 2013 09:03:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B954EB2F; Fri, 15 Feb 2013 09:03:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1F93kmC003716; Fri, 15 Feb 2013 04:03:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1F93kIo003712; Fri, 15 Feb 2013 09:03:46 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 15 Feb 2013 09:03:46 GMT Message-Id: <201302150903.r1F93kIo003712@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 09:03:48 -0000 TB --- 2013-02-15 07:20:16 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-15 07:20:16 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-15 07:20:16 - starting HEAD tinderbox run for arm/arm TB --- 2013-02-15 07:20:16 - cleaning the object tree TB --- 2013-02-15 07:24:05 - /usr/local/bin/svn stat /src TB --- 2013-02-15 07:24:09 - At svn revision 246820 TB --- 2013-02-15 07:24:10 - building world TB --- 2013-02-15 07:24:10 - CROSS_BUILD_TESTING=YES TB --- 2013-02-15 07:24:10 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-15 07:24:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-15 07:24:10 - SRCCONF=/dev/null TB --- 2013-02-15 07:24:10 - TARGET=arm TB --- 2013-02-15 07:24:10 - TARGET_ARCH=arm TB --- 2013-02-15 07:24:10 - TZ=UTC TB --- 2013-02-15 07:24:10 - __MAKE_CONF=/dev/null TB --- 2013-02-15 07:24:10 - cd /src TB --- 2013-02-15 07:24:10 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 15 07:24:14 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 /src/sbin/fsdb/fsdb.c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/../fsck_ffs/dir.c /src/sbin/fsdb/../fsck_ffs/ea.c /src/sbin/fsdb/../fsck_ffs/fsutil.c /src/sbin/fsdb/../fsck_ffs/inode.c /src/sbin/fsdb/../fsck_ffs/pass1.c /src/sbin/fsdb/../fsck_ffs/pass1b.c /src/sbin/fsdb/../fsck_ffs/pass2.c /src/sbin/fsdb/../fsck_ffs/pass3.c /src/sbin/fsdb/../fsck_ffs/pass4.c /src/sbin/fsdb/../fsck_ffs/pass5.c /src/sbin/fsdb/../fsck_ffs/setup.c /src/sbin/fsdb/../fsck_ffs/utilities.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_subr.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_tables.c echo fsdb: /obj/arm.arm/src/tmp/usr/lib/libc.a /obj/arm.arm/src/tmp/usr/lib/libedit.a /obj/arm.arm/src/tmp/usr/lib/libtermcap.a >> .depend cc -O -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdb.c cc -O -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/fsdbutil.c: In function 'printindir': /src/sbin/fsdb/fsdbutil.c:242: error: 'struct bufarea' has no member named 'b_prev' /src/sbin/fsdb/fsdbutil.c:242: error: 'struct bufarea' has no member named 'b_next' *** [fsdbutil.o] Error code 1 Stop in /src/sbin/fsdb. *** [fsdb_make] Error code 1 Stop in /obj/arm.arm/src/rescue/rescue. *** [objs] Error code 1 Stop in /src/rescue/rescue. *** [all] Error code 1 Stop in /src/rescue. *** [rescue.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-15 09:03:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-15 09:03:46 - ERROR: failed to build world TB --- 2013-02-15 09:03:46 - 4781.02 user 849.91 system 6210.14 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Fri Feb 15 11:20:43 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 32FB3967 for ; Fri, 15 Feb 2013 11:20:43 +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 12F76228 for ; Fri, 15 Feb 2013 11:20:42 +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 9BEC1208F5 for ; Fri, 15 Feb 2013 11:20:41 +0000 (UTC) Message-ID: <511E1A08.4020105@g7iii.net> Date: Fri, 15 Feb 2013 11:20:40 +0000 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: Beaglebone Serial Ports Progress Content-Type: multipart/mixed; boundary="------------020507070308010604080403" 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, 15 Feb 2013 11:20:43 -0000 This is a multi-part message in MIME format. --------------020507070308010604080403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Folks, After waiting for deliveries, and a few false starts, I have made -some- progress on adding support for the Beaglebone's serial ports (UARTS1-5) to FreeBSD First thing I did was add the pinmux stuff, having worked out exactly what I needed to add to the DTS, and recompile. This seems to have worked out well, and on a reboot I see: setting internal 28 for uart1_rxd setting internal 0 for uart1_txd This is good. kernel comes up,curiously though, I don't see lines output for the RTS and CTS lines (which I do set to the correct mode, yet I do for UART3 CTS and UART4 CTS, which I added as a test. I then proceeded to add the uart1 device itself to the DTS, and added the following: uart1: serial@48022000 { compatible = "ns16550"; reg = <0x48022000 0x1000>; reg-shift = <2>; interrupts = < 73 >; interrupt-parent = <&AINTC>; clock-frequency = < 48000000 >; }; This caused the kernel to dump me in db (debugger I guess). I figured out that 't' gave me a trace, and it looked like it was in the middle of probing for UARTS. (This is about as much knowledge I have about the kernel debugger) I tried changing 0x1000 for 0x2000, as it seems the next reg is also reserved for UART1. No more luck. So, thinking I needed to add it as an alias (as UART0 is), I added that, but it still dumped me at the debugger on boot. The only other thing is reg-shift. I must confess, I am a bit blind here. Not knowing what it actually did I left it as with UART0. I'm hoping it essentially includes the next register up for UART1, as while that's listed as "Reserved" in the memory map [Yes, I consulted SPRUH73G :)] , it seems to be reserved for UART1, but I am just guessing (Yes, I know, not good practice when kernel hacking...) I've attached the latest version of my patch, the output from the kernel until it blows up, as well as the trace. Patch is based on r246610 Anyone able to point me in the right direction ? I can't be too far away, and I can then add UART2-5, and submit an actual working patch! All the Best Iain --------------020507070308010604080403 Content-Type: text/x-patch; name="beaglebone.uart1.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="beaglebone.uart1.patch" 41a42 > uart1 = &uart1; 129a131,132 > "LCD_DATA10", "uart3_ctsn", "input_pulldown", > "LCD_DATA12", "uart4_ctsn", "input_pulldown", 145c148,152 < "GPMC_AD9", "ehrpwm2B", "output"; --- > "GPMC_AD9", "ehrpwm2B", "output", > "UART1_RXD","uart1_rxd","input", > "UART1_TXD","uart1_txd","output", > "I2C2_SCL","uart1_rtsn","output", > "I2C2_SDA","uart1_ctsn","input_pulldown"; 192c199,208 < --- > > uart1: serial@48022000 { > compatible = "ns16550"; > reg = <0x48022000 0x1000>; > reg-shift = <2>; > interrupts = < 73 >; > interrupt-parent = <&AINTC>; > clock-frequency = < 48000000 >; > }; > --------------020507070308010604080403 Content-Type: text/plain; charset=UTF-8; name="boot_msgs_uart1" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="boot_msgs_uart1" FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@fci386.localdomain, Sat Feb 2 23:58:42 PST 2013) DRAM: 256MB Device: disk - /boot/kernel/kernel data=0x3f2ab8+0x21e28 syms=[0x4+0x8a5f0+0x4+0x6abc6] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... fdt_start: 0x005C8A90 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 #7 r246610M: Fri Feb 15 10:46:57 UTC 2013 root@beaglebone:/usr/obj/usr/src/sys/BEAGLEBONE arm gcc version 4.2.1 20070831 patched [FreeBSD] 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 = 268435456 (256 MB) avail memory = 255156224 (243 MB) Texas Instruments AM3358 Processor, Revision ES1.0 random device not loaded; using insecure entropy simplebus0: on fdtbus0 aintc0: mem 0xcf160000-0xcf160fff on simplebus0 aintc0: Revision 5.0 ti_scm0: mem 0xe4e10000-0xe4e11fff on simplebus0 setting internal 70 for I2C0_SDA setting internal 70 for I2C0_SCL setting internal 20 for gmii1_rxerr setting internal 0 for gmii1_txen setting internal 20 for gmii1_rxdv setting internal 0 for gmii1_txd3 setting internal 0 for gmii1_txd2 setting internal 0 for gmii1_txd1 setting internal 0 for gmii1_txd0 setting internal 20 for gmii1_txclk setting internal 20 for gmii1_rxclk setting internal 20 for gmii1_rxd3 setting internal 20 for gmii1_rxd2 setting internal 20 for gmii1_rxd1 setting internal 20 for gmii1_rxd0 setting internal 30 for mdio_data setting internal 10 for mdio_clk setting internal 30 for mmc0_cmd setting internal 30 for mmc0_clk setting internal 30 for mmc0_dat0 setting internal 30 for mmc0_dat1 setting internal 30 for mmc0_dat2 setting internal 30 for mmc0_dat3 setting internal 27 for gpio0_7 setting internal 27 for gpio0_26 setting internal 27 for gpio0_27 setting internal 27 for gpio1_0 setting internal 27 for gpio1_1 setting internal 27 for gpio1_2 setting internal 27 for gpio1_3 setting internal 27 for gpio1_4 setting internal 27 for gpio1_5 setting internal 27 for gpio1_6 setting internal 27 for gpio1_7 setting internal 27 for gpio1_12 setting internal 27 for gpio1_13 setting internal 27 for gpio1_14 setting internal 27 for gpio1_15 setting internal 27 for gpio1_16 setting internal 27 for gpio1_17 setting internal 7 for gpio1_21 setting internal 7 for gpio1_22 setting internal 7 for gpio1_23 setting internal 7 for gpio1_24 setting internal 27 for gpio1_28 setting internal 27 for gpio1_29 setting internal 27 for gpio1_30 setting internal 27 for gpio1_31 setting internal 27 for gpio2_1 setting internal 27 for gpio2_6 setting internal 27 for gpio2_7 setting internal 27 for gpio2_8 setting internal 27 for gpio2_9 setting internal 27 for gpio2_10 setting internal 27 for gpio2_11 setting internal 27 for gpio2_12 setting internal 27 for gpio2_13 setting internal 26 for uart3_ctsn setting internal 26 for uart4_ctsn setting internal 27 for gpio2_22 setting internal 27 for gpio2_23 setting internal 27 for gpio2_24 setting internal 27 for gpio2_25 setting internal 27 for gpio3_19 setting internal 27 for gpio3_21 setting internal 2 for timer4 setting internal 2 for timer5 setting internal 2 for timer6 setting internal 2 for timer7 setting internal 6 for ehrpwm1A setting internal 6 for ehrpwm1B setting internal 4 for ehrpwm2A setting internal 4 for ehrpwm2B setting internal 28 for uart1_rxd setting internal 0 for uart1_txd am335x_prcm0: mem 0xe4e00000-0xe4e012ff on simplebus0 am335x_prcm0: Clocks: System 24.0 MHz, CPU 500 MHz am335x_dmtimer0: mem 0xe4e05000-0xe4e05fff,0xe4e31000-0xe4e31fff,0xcf161000-0xcf161fff,0xcf162000-0xcf162fff,0xcf163000-0xcf163fff,0xcf164000-0xcf164fff,0xcf165000-0xcf165fff,0xcf166000-0xcf166fff irq 66,67,68,69,92,93,94,95 on simplebus0 Timecounter "AM335x Timecounter" frequency 24000000 Hz quality 1000 Event timer "AM335x Eventtimer0" frequency 24000000 Hz quality 1000 gpio0: mem 0xe4e07000-0xe4e07fff,0xcf167000-0xcf167fff,0xcf168000-0xcf168fff,0xcf169000-0xcf169fff irq 96,97,98,99,32,33,62,63 on simplebus0 gpioc0: on gpio0 gpiobus0: on gpio0 uart0: <16750 or compatible> mem 0xe4e09000-0xe4e09fff irq 72 on simplebus0 uart0: console (115384,n,8,1) Fatal kernel mode data abort: 'External Non-Linefetch Abort (S)' trapframe: 0xc071db3c FSR=00001008, FAR=cf16a008, spsr=60000093 r0 =00000000, r1 =cf16a000, r2 =00000008, r3 =c05f0b94 r4 =c1bd3608, r5 =c1bd3600, r6 =00000000, r7 =c1c56200 r8 =c1bd3608, r9 =00000002, r10=00000000, r11=c071db98 r12=00000002, ssp=c071db88, slr=c025792c, pc =c04f52ac [ thread pid 0 tid 100000 ] Stopped at generic_bs_r_1: ldrb r0, [r1, r2] db> t Tracing pid 0 tid 100000 td 0xc05f9800 db_trace_self() at db_trace_self+0xc scp=0xc04f90a4 rlv=0xc04f90f0 (db_trace_thread+0x38) rsp=0xc071d82c rfp=0xc071d838 db_trace_thread() at db_trace_thread+0xc scp=0xc04f90c4 rlv=0xc022a1b0 (db_stack_trace+0xe4) rsp=0xc071d83c rfp=0xc071d858 db_stack_trace() at db_stack_trace+0xc scp=0xc022a0d8 rlv=0xc0229858 (db_command+0x2d8) rsp=0xc071d85c rfp=0xc071d900 r5=0x00000000 r4=0xc05c8350 db_command() at db_command+0xc scp=0xc022958c rlv=0xc02299c4 (db_command_loop+0x60) rsp=0xc071d904 rfp=0xc071d910 r10=0x60000193 r8=0x00001008 r7=0x00000000 r6=0xcf16a008 r5=0xc05c8660 r4=0xc071d91c db_command_loop() at db_command_loop+0xc scp=0xc0229970 rlv=0xc022be88 (db_trap+0xec) rsp=0xc071d914 rfp=0xc071da30 db_trap() at db_trap+0xc scp=0xc022bda8 rlv=0xc0380c70 (kdb_trap+0xa4) rsp=0xc071da34 rfp=0xc071da58 r4=0xc071db3c kdb_trap() at kdb_trap+0xc scp=0xc0380bd8 rlv=0xc0507734 (dab_fatal+0x194) rsp=0xc071da5c rfp=0xc071da78 r10=0xc071db3c r8=0xc1bd3608 r7=0xc05f9800 r6=0xcf16a008 r5=0x00001008 r4=0xc071db3c dab_fatal() at dab_fatal+0xc scp=0xc05075ac rlv=0xc0507aa8 (dab_buserr+0x64) rsp=0xc071da7c rfp=0xc071da94 r6=0x00000000 r5=0xc05f9800 r4=0xc071db3c dab_buserr() at dab_buserr+0xc scp=0xc0507a50 rlv=0xc0507c78 (data_abort_handler+0x120) rsp=0xc071da98 rfp=0xc071db38 r5=0xc1bd3600 r4=0xc06111e8 data_abort_handler() at data_abort_handler+0xc scp=0xc0507b64 rlv=0xc04fa8a8 (exception_exit) rsp=0xc071db3c rfp=0xc071db98 r10=0x00000000 r9=0x00000002 r8=0xc1bd3608 r7=0xc1c56200 r6=0x00000000 r5=0xc1bd3600 r4=0xc1bd3608 ns8250_probe() at ns8250_probe+0xc scp=0xc0257908 rlv=0xc0257dd0 (ns8250_bus_probe+0x20) rsp=0xc071db9c rfp=0xc071dbcc r4=0x00000000 ns8250_bus_probe() at ns8250_bus_probe+0xc scp=0xc0257dbc rlv=0xc025663c (uart_bus_probe+0x1b8) rsp=0xc071dbd0 rfp=0xc071dc10 r10=0x00000000 r9=0x00000002 r8=0xc1bd363c r7=0xc1c56200 r6=0x00000000 r5=0xc1bd3600 r4=0x00000000 uart_bus_probe() at uart_bus_probe+0xc scp=0xc0256490 rlv=0xc0255fcc (uart_fdt_probe+0xf8) rsp=0xc071dc14 rfp=0xc071dc38 r10=0x00000000 r9=0x00000000 r8=0xc1c43d80 r7=0x00000000 r6=0xc1c56200 r5=0x00000000 r4=0x00000e80 uart_fdt_probe() at uart_fdt_probe+0xc scp=0xc0255ee0 rlv=0xc037c1ac (device_probe_child+0x1a0) rsp=0xc071dc3c rfp=0xc071dc68 r6=0x00000000 r5=0xc1c56200 r4=0xc1bd8000 device_probe_child() at device_probe_child+0xc scp=0xc037c018 rlv=0xc037c444 (device_probe+0x8c) rsp=0xc071dc6c rfp=0xc071dc84 r10=0xc1bfd780 r9=0xc1bfd780 r8=0xc1c20d80 r7=0xc1c20d94 r6=0xc1bfd780 r5=0xc1c20d80 r4=0xc1c56200 device_probe() at device_probe+0xc scp=0xc037c3c4 rlv=0xc037c518 (device_probe_and_attach+0x2c) rsp=0xc071dc88 rfp=0xc071dc98 r6=0xc1bfd780 r5=0xc1c20d80 r4=0xc1c56200 device_probe_and_attach() at device_probe_and_attach+0xc scp=0xc037c4f8 rlv=0xc037c5f8 (bus_generic_attach+0x20) rsp=0xc071dc9c rfp=0xc071dcac r4=0xc1c56200 bus_generic_attach() at bus_generic_attach+0xc scp=0xc037c5e4 rlv=0xc02321a8 (simplebus_attach+0x1cc) rsp=0xc071dcb0 rfp=0xc071dcd0 r4=0x00000000 simplebus_attach() at simplebus_attach+0xc scp=0xc0231fe8 rlv=0xc037b800 (device_attach+0x320) rsp=0xc071dcd4 rfp=0xc071dd10 r8=0xffffffff r7=0xc052be4c r6=0xc1bfd7d0 r5=0x80000003 r4=0xc1bfd880 device_attach() at device_attach+0xc scp=0xc037b4ec rlv=0xc037c534 (device_probe_and_attach+0x48) rsp=0xc071dd14 rfp=0xc071dd24 r10=0xc1bd7080 r8=0xc1bfd880 r7=0x00000000 r6=0x00000000 r5=0xc1bfd710 r4=0xc1bfd780 device_probe_and_attach() at device_probe_and_attach+0xc scp=0xc037c4f8 rlv=0xc037c5f8 (bus_generic_attach+0x20) rsp=0xc071dd28 rfp=0xc071dd38 r4=0xc1bfd780 bus_generic_attach() at bus_generic_attach+0xc scp=0xc037c5e4 rlv=0xc0231c24 (fdtbus_attach+0x564) rsp=0xc071dd3c rfp=0xc071ddb0 r4=0xc051f5ec fdtbus_attach() at fdtbus_attach+0xc scp=0xc02316cc rlv=0xc037b800 (device_attach+0x320) rsp=0xc071ddb4 rfp=0xc071ddf0 r10=0xc1bfd880 r9=0xc070d000 r8=0xffffffff r7=0xc052be4c r6=0xc1bfd8d0 r5=0x80000003 r4=0xc0379320 device_attach() at device_attach+0xc scp=0xc037b4ec rlv=0xc037c534 (device_probe_and_attach+0x48) rsp=0xc071ddf4 rfp=0xc071de04 r10=0xc1c20080 r8=0xffffffff r7=0xc052be4c r6=0xc1c20080 r5=0xffffffff r4=0xc1bfd880 device_probe_and_attach() at device_probe_and_attach+0xc scp=0xc037c4f8 rlv=0xc037c5f8 (bus_generic_attach+0x20) rsp=0xc071de08 rfp=0xc071de18 r4=0xc1bfd880 bus_generic_attach() at bus_generic_attach+0xc scp=0xc037c5e4 rlv=0xc04fe620 (nexus_attach+0x70) rsp=0xc071de1c rfp=0xc071de34 r4=0xc06132fc nexus_attach() at nexus_attach+0xc scp=0xc04fe5bc rlv=0xc037b800 (device_attach+0x320) rsp=0xc071de38 rfp=0xc071de74 r6=0xc1c200d0 r5=0x80000003 r4=0xc0379320 device_attach() at device_attach+0xc scp=0xc037b4ec rlv=0xc037c534 (device_probe_and_attach+0x48) rsp=0xc071de78 rfp=0xc071de88 r10=0x88048970 r8=0x880466c8 r7=0x8020014c r6=0xc1bfc380 r5=0xc05ef268 r4=0xc1c20080 device_probe_and_attach() at device_probe_and_attach+0xc scp=0xc037c4f8 rlv=0xc037c8b4 (bus_generic_new_pass+0xec) rsp=0xc071de8c rfp=0xc071dea4 r4=0xc1c20080 bus_generic_new_pass() at bus_generic_new_pass+0xc scp=0xc037c7d4 rlv=0xc037a6a4 (bus_set_pass+0x9c) rsp=0xc071dea8 rfp=0xc071dec0 r6=0x7fffffff r5=0xc1bfc380 r4=0xc1bd86c0 bus_set_pass() at bus_set_pass+0xc scp=0xc037a614 rlv=0xc037a704 (root_bus_configure+0x14) rsp=0xc071dec4 rfp=0xc071ded0 r6=0x8ff84cfc r5=0x80200158 r4=0xc05808ac root_bus_configure() at root_bus_configure+0xc scp=0xc037a6fc rlv=0xc04f40bc (configure+0x10) rsp=0xc071ded4 rfp=0xc071dee0 configure() at configure+0xc scp=0xc04f40b8 rlv=0xc030516c (mi_startup+0xf8) rsp=0xc071dee4 rfp=0xc071def4 mi_startup() at mi_startup+0xc scp=0xc0305080 rlv=0xc0200218 (virt_done+0x30) rsp=0xc071def8 rfp=0x00000000 r4=0x80200258 --------------020507070308010604080403-- From owner-freebsd-arm@FreeBSD.ORG Fri Feb 15 16:46: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 54CD97A0 for ; Fri, 15 Feb 2013 16:46:55 +0000 (UTC) (envelope-from dmarion.freebsd@gmail.com) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by mx1.freebsd.org (Postfix) with ESMTP id DEA8E885 for ; Fri, 15 Feb 2013 16:46:54 +0000 (UTC) Received: by mail-bk0-f44.google.com with SMTP id j4so1633491bkw.3 for ; Fri, 15 Feb 2013 08:46:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=Z0UIDR5Wx37rWSxKJztXdVLsAdP+ag2C/bGt/+b0mF4=; b=DyZAUim/kkus9sMQ1KExrR7OmpvIaiWBVi46MSmaU0qIKIP2UYgU968UVe/iyLPdIw G/CSlyNJUrO/2TaGMhf3oIhhf4NeCMX1zCaBQuXO03FeXybIRSEsD7p6pG7WR3rwSXT+ H+f2Uvfh0AX5HwZBfAwUba4ZuWLjLHLi8l38hof4HxRtMX7+P0iGoq0ZSrqRzudxIy1A A2Sxlxi6loS1XT3fQZdao/dXSbfnXvKkuD2aCdt/7qQDOV0cQv2wHfh/zP6BciYwxvB1 PMnVdQ3Tgor9y0If1D4xL5iUWSg6uE7lZNVaXYPpfZEqyJRYIsVGS3ODdBNZJvI2qmhe rv4Q== X-Received: by 10.204.7.144 with SMTP id d16mr1097100bkd.48.1360946808058; Fri, 15 Feb 2013 08:46:48 -0800 (PST) Received: from damarion-mac.home (cpe-109-60-68-159.zg3.cable.xnet.hr. [109.60.68.159]) by mx.google.com with ESMTPS id g28sm17953252bkv.17.2013.02.15.08.46.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 08:46:46 -0800 (PST) Sender: Damjan Marion Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Beaglebone Serial Ports Progress From: Damjan Marion In-Reply-To: <511E1A08.4020105@g7iii.net> Date: Fri, 15 Feb 2013 17:46:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <511E1A08.4020105@g7iii.net> To: Iain Young X-Mailer: Apple Mail (2.1499) 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, 15 Feb 2013 16:46:55 -0000 On Feb 15, 2013, at 12:20 PM, Iain Young wrote: > Hi Folks, >=20 > After waiting for deliveries, and a few false starts, I have made > -some- progress on adding support for the Beaglebone's serial ports > (UARTS1-5) to FreeBSD >=20 > First thing I did was add the pinmux stuff, having worked out exactly > what I needed to add to the DTS, and recompile. This seems to have > worked out well, and on a reboot I see: >=20 > setting internal 28 for uart1_rxd > setting internal 0 for uart1_txd >=20 >=20 > This is good. kernel comes up,curiously though, I don't see lines > output for the RTS and CTS lines (which I do set to the correct mode, > yet I do for UART3 CTS and UART4 CTS, which I added as a test. >=20 > I then proceeded to add the uart1 device itself to the DTS, and > added the following: >=20 > uart1: serial@48022000 { > compatible =3D "ns16550"; > reg =3D <0x48022000 0x1000>; > reg-shift =3D <2>; > interrupts =3D < 73 >; > interrupt-parent =3D <&AINTC>; > clock-frequency =3D < 48000000 >; > }; >=20 > This caused the kernel to dump me in db (debugger I guess). I figured > out that 't' gave me a trace, and it looked like it was in the middle > of probing for UARTS. (This is about as much knowledge I have about = the > kernel debugger) >=20 > I tried changing 0x1000 for 0x2000, as it seems the next reg is also > reserved for UART1. No more luck. So, thinking I needed to add it as = an > alias (as UART0 is), I added that, but it still dumped me at the > debugger on boot. >=20 > The only other thing is reg-shift. I must confess, I am a bit blind > here. Not knowing what it actually did I left it as with UART0. I'm > hoping it essentially includes the next register up for UART1, as > while that's listed as "Reserved" in the memory map [Yes, I consulted > SPRUH73G :)] , it seems to be reserved for UART1, but I am just > guessing (Yes, I know, not good practice when kernel hacking...) >=20 > I've attached the latest version of my patch, the output from the > kernel until it blows up, as well as the trace. Patch is based on > r246610 >=20 > Anyone able to point me in the right direction ? I can't be too far > away, and I can then add UART2-5, and submit an actual working patch! >=20 It is very likely that clock is disabled for USART1. Problem is that = usart uses standard serial driver which is not requesting clock to be enabled = during the attach by invoking ti_prcm_clk_enable(). Can you try to put following at the end of am335x_prcm_attach()? prcm_write_4(6c, 2); This should be register CM_PER_UART1_CLKCTRL. Damjan From owner-freebsd-arm@FreeBSD.ORG Fri Feb 15 22:29: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 C91B8640 for ; Fri, 15 Feb 2013 22:29:12 +0000 (UTC) (envelope-from ThomasSkibo@sbcglobal.net) Received: from nm27-vm0.access.bullet.mail.sp2.yahoo.com (nm27-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.188]) by mx1.freebsd.org (Postfix) with ESMTP id AAAF09A9 for ; Fri, 15 Feb 2013 22:29:12 +0000 (UTC) Received: from [98.139.44.101] by nm27.access.bullet.mail.sp2.yahoo.com with NNFMP; 15 Feb 2013 22:29:12 -0000 Received: from [67.195.22.113] by tm6.access.bullet.mail.sp2.yahoo.com with NNFMP; 15 Feb 2013 22:29:11 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.gq1.yahoo.com with NNFMP; 15 Feb 2013 22:29:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1360967351; bh=+6OyZ8OuG66aEMDlhuLfuLP+XQ43SjgyCXHxkKIMbLA=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=wR2bTr8XK0RTyKj7CJm3PNXiBhdE+HgPfYfLpNLz27YcaBuK2f4Hs+sQRkkhLo//hW62t8iB5dNaKRYoJd3/ta4sbFIjX56Plz3O4L566hqJoIHEyc63/8nXdr4jy6hrQfm2vdSJ2nq6Z/QBa/n8gDxKt5XNwdJuacVjZdJBBJU= X-Yahoo-Newman-Id: 875714.15361.bm@smtp115.sbc.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: pZTU0UYVM1l7O2haQoQhz4kK7fkH8vd0I6lXlXm3n5l6ghb 7Ul4UmtLqiC6O5ac78FazUN9hwSOWNehwJPggpKhRyBiGCgJLn88kMpFiqQz kctEbsCit.xZztiMmGVKcq0UP1L0hTcJd9OcmmB6vYHFpyETOJgJ37rewUyu rWFPgEwHZOYtJ1wsz1mo90TBaOTU8n3HMVW9DY4A9bQu1pfgI3Ggsznx1Aoz wOl7Js6SyWEvFDIUP3_z2RS2jml4Xf4MSwTeCBB5ZKLZwY3qh5EJbAAfPC3_ OLEZ6SK6_wpngXYRlr8r5PO.efVDkF1hHxPZcKVu9DRP1HLL6xycara5CMk_ h2WoL3wbcseZvnf__.IvYtmGffdld1ZFrGdckBMnPsLTanPP.981cZGmjZUm Qwq8oY4qXb1.tl0wDHxSKHHD0xPxQ4CBVIxW.KuJx03czAkNaKddS_yb.cwH x8hYdUj5qO0GHWcwM_qNOBV9.Am00mHr_SQt6udc- X-Yahoo-SMTP: tUxoRneswBA21azLM.3ybMESf0mC2bFhTbmt0VU5ervH0kqi5lo- Received: from [192.168.1.9] (ThomasSkibo@71.139.168.220 with plain) by smtp115.sbc.mail.gq1.yahoo.com with SMTP; 15 Feb 2013 14:29:11 -0800 PST Message-ID: <511EB6B9.3020902@sbcglobal.net> Date: Fri, 15 Feb 2013 14:29:13 -0800 From: Thomas Skibo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Panic when calling _bus_dmamap_load_buffer() with BUS_DMA_COULD_BOUNCE (armv6) 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, 15 Feb 2013 22:29:12 -0000 Hello: This is the Zedboard port which is the armv6 architecture. I integrated to my project branch late Wednesday which included some big changes to busdma stuff. Now my kernel panics early in boot-up. I'm getting the a vm_fault when a certain driver calls bus_dmamap_load() with a dma tag with BUS_DMA_COULD_BOUNCE set. What appears to be happening is that the code at lines 971-980 in sys/arm/arm/busdma_machdep-v6.c is calling _bus_dmamap_count_pages() before map->pmap is set (it's NULL). _bus_dmamap_count_pages() in turn calls pmap_extract() with a NULL pointer. (_bus_dmamap_count_pages() is inlined by the compiler so doesn't show up in the following back-trace.) I patched busdma_machdep-v6.c to get moving again by moving the "map->pmap = pmap" statement before the BUS_DMA_COULD_BOUNCE check. I'm not suggesting that's the right fix at all. ==== //depot/user/skibo/skibo_zynq/sys/arm/arm/busdma_machdep-v6.c#2 - /home/skibo/p4/skibo_zynq/sys/arm/arm/busdma_machdep-v6.c ==== 970a971,972 > map->pmap = pmap; > 982d983 < map->pmap = pmap; --Thomas vm_fault(0xc04fae94, 0, 1, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xc0526ab8 FSR=00000005, FAR=00000010, spsr=000000d3 r0 =c04fabb0, r1 =00000004, r2 =00000004, r3 =00000010 r4 =00000000, r5 =c2dd9000, r6 =c2dda000, r7 =c2dd9000 r8 =c2dd5580, r9 =c2dd55cc, r10=00001000, r11=c0526b1c r12=c04fabb0, ssp=c0526b04, slr=c041c41c, pc =c0424b90 [ thread pid 0 tid 100000 ] Stopped at pmap_extract+0x30: ldrex r14, [r3] db> bt Tracing pid 0 tid 100000 td 0xc04fabb0 db_trace_self() at db_trace_self+0xc scp=0xc041e6d8 rlv=0xc041e724 (db_trace_thread+0x38) rsp=0xc05267cc rfp=0xc05267d8 db_trace_thread() at db_trace_thread+0xc scp=0xc041e6f8 rlv=0xc012b6f8 (db_command_init+0x354) rsp=0xc05267dc rfp=0xc05267f8 db_command_init() at db_command_init+0x27c scp=0xc012b620 rlv=0xc012b0fc (db_skip_to_eol+0x4a0) rsp=0xc05267fc rfp=0xc05268a0 r5=0x00000000 r4=0xc04cc258 db_skip_to_eol() at db_skip_to_eol+0x1d4 scp=0xc012ae30 rlv=0xc012b268 (db_command_loop+0x60) rsp=0xc05268a4 rfp=0xc05268b0 r10=0x600001d3 r8=0x00000005 r7=0x00000000 r6=0x00000010 r5=0xc04cc520 r4=0xc05268bc db_command_loop() at db_command_loop+0xc scp=0xc012b214 rlv=0xc012d748 (X_db_sym_numargs+0xf4) rsp=0xc05268b4 rfp=0xc05269d0 X_db_sym_numargs() at X_db_sym_numargs+0x14 scp=0xc012d668 rlv=0xc0285a80 (kdb_trap+0xa4) rsp=0xc05269d4 rfp=0xc05269f8 r4=0xc0526ab8 kdb_trap() at kdb_trap+0xc scp=0xc02859e8 rlv=0xc042d934 (badaddr_read+0x284) rsp=0xc05269fc rfp=0xc0526a18 r10=0x00000000 r8=0xc0526ab8 r7=0xc04fabb0 r6=0x00000010 r5=0x00000005 r4=0xc0526ab8 badaddr_read() at badaddr_read+0xfc scp=0xc042d7ac rlv=0xc042de70 (data_abort_handler+0x4e4) rsp=0xc0526a1c rfp=0xc0526ab4 r6=0xc0526ef8 r5=0xc04fa8c8 r4=0x00000000 data_abort_handler() at data_abort_handler+0xc scp=0xc042d998 rlv=0xc041fedc (address_exception_entry+0x50) rsp=0xc0526ab8 rfp=0xc0526b1c r10=0x00001000 r9=0xc2dd55cc r8=0xc2dd5580 r7=0xc2dd9000 r6=0xc2dda000 r5=0xc2dd9000 r4=0x00000000 pmap_extract() at pmap_extract+0xc scp=0xc0424b6c rlv=0xc041c41c (_bus_dmamap_load_buffer+0x7c) rsp=0xc0526b20 rfp=0xc0526b50 r5=0xc2dd5480 r4=0xc2dd9000 _bus_dmamap_load_buffer() at _bus_dmamap_load_buffer+0xc scp=0xc041c3ac rlv=0xc0281ca8 (bus_dmamap_load+0xac) rsp=0xc0526b54 rfp=0xc0526bb4 r10=0xc2dad040 r9=0xc0146108 r8=0x00001000 r7=0x00000000 r6=0xc2dd5580 r5=0xc2dd5480 r4=0xc2dd9000 bus_dmamap_load() at bus_dmamap_load+0xc scp=0xc0281c08 rlv=0xc0149354 (sdhci_init_slot+0x100) rsp=0xc0526bb8 rfp=0xc0526c08 r10=0x00000001 r9=0xc2d58700 r8=0x00000000 r7=0xc2d89580 r6=0xc2dad0d4 r5=0xc2dad018 r4=0x00000000 sdhci_init_slot() at sdhci_init_slot+0xc scp=0xc0149260 rlv=0xc0439670 (zy7_slcr_init_postload_pl+0x3ce8) rsp=0xc0526c0c rfp=0xc0526c44 r10=0x00000001 r9=0xc2d58700 r8=0x00000000 r7=0xc2d89580 r6=0x00000000 r5=0xc2dad000 r4=0xc2dad000 db> -- -------- Thomas Skibo ThomasSkibo@sbcglobal.net From owner-freebsd-arm@FreeBSD.ORG Fri Feb 15 22:48: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 4845F10B for ; Fri, 15 Feb 2013 22:48:46 +0000 (UTC) (envelope-from werner@thieprojects.ch) Received: from newton.metanet.ch (newton.metanet.ch [80.74.158.130]) by mx1.freebsd.org (Postfix) with ESMTP id 857C0B1A for ; Fri, 15 Feb 2013 22:48:45 +0000 (UTC) Received: (qmail 14396 invoked from network); 15 Feb 2013 23:48:37 +0100 Received: from 217-071-083-008.ip-tech.ch (HELO ?192.168.11.88?) (217.71.83.8) by newton.metanet.ch with (DHE-RSA-AES256-SHA encrypted) SMTP; 15 Feb 2013 23:48:37 +0100 Message-ID: <511EBB47.9030206@thieprojects.ch> Date: Fri, 15 Feb 2013 23:48:39 +0100 From: Werner Thie User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: Beaglebone latest image observations - lock order reversal from ufs 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, 15 Feb 2013 22:48:46 -0000 Hi today, after several failed attempts (build world failing), I managed to build a new kernel with Tim's script for the Bone. From what I see it started spewing the 'ti_mmchs0: Error: current cmd null' again. ti_mmchs0: Error: current cmd NULL, already done? I'm now also getting the occasional lock order reversal: 1st 0xc2c8ad84 ufs (ufs) @ /usr/local/src/sys/kern/vfs_subr.c:2176 2nd 0xc97a2378 bufwait (bufwait) @ /usr/local/src/sys/ufs/ffs/ffs_vnops.c:261 3rd 0xc2d807f8 ufs (ufs) @ /usr/local/src/sys/kern/vfs_subr.c:2176 KDB: stack backtrace: : : Anybody out there being able to enlighten me about this? Does the first error relate or is triggered by second one? Seeping through dmesg I see : cpsw0: <3-port Switch Ethernet Subsystem> mem 0xcf619000-0xcf61cfff irq 40,41,42,43 on simplebus0 cpsw0: CPSW SS Version 1.12 (0) _bus_dmamap_sync: wrong user map: 0 4 cpsw0: Initial queue size TX=128 RX=384 cpsw0: Ethernet address: 00:18:31:8e:0e:1d : I also observed that Python27 built fresh from ports aborts on importing ctypes. I keep on building and reporting, the progress is still amazing! If there's anything specific to try, please let me know Thxs, Werner From owner-freebsd-arm@FreeBSD.ORG Fri Feb 15 23:32:31 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 07B32EE6; Fri, 15 Feb 2013 23:32:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D20E4D99; Fri, 15 Feb 2013 23:32:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1FNWTuG029773; Fri, 15 Feb 2013 18:32:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1FNWTLc029769; Fri, 15 Feb 2013 23:32:29 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 15 Feb 2013 23:32:29 GMT Message-Id: <201302152332.r1FNWTLc029769@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 23:32:31 -0000 TB --- 2013-02-15 23:00:23 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-15 23:00:23 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-15 23:00:23 - starting HEAD tinderbox run for arm/arm TB --- 2013-02-15 23:00:23 - cleaning the object tree TB --- 2013-02-15 23:00:23 - /usr/local/bin/svn stat /src TB --- 2013-02-15 23:00:27 - At svn revision 246856 TB --- 2013-02-15 23:00:28 - building world TB --- 2013-02-15 23:00:28 - CROSS_BUILD_TESTING=YES TB --- 2013-02-15 23:00:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-15 23:00:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-15 23:00:28 - SRCCONF=/dev/null TB --- 2013-02-15 23:00:28 - TARGET=arm TB --- 2013-02-15 23:00:28 - TARGET_ARCH=arm TB --- 2013-02-15 23:00:28 - TZ=UTC TB --- 2013-02-15 23:00:28 - __MAKE_CONF=/dev/null TB --- 2013-02-15 23:00:28 - cd /src TB --- 2013-02-15 23:00:28 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Feb 15 23:00:33 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/buffer.c -o buffer.o cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dane.c -o dane.o cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dname.c -o dname.o cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dnssec.c -o dnssec.o cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dnssec_sign.c -o dnssec_sign.o cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dnssec_verify.c -o dnssec_verify.o cc1: warnings being treated as errors /src/lib/libldns/../../contrib/ldns/dnssec_verify.c:638: warning: 'ldns_dnssec_trust_tree_print_sm' defined but not used *** [dnssec_verify.o] Error code 1 Stop in /src/lib/libldns. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-15 23:32:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-15 23:32:29 - ERROR: failed to build world TB --- 2013-02-15 23:32:29 - 1476.80 user 317.26 system 1925.89 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Fri Feb 15 23:43:34 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 4558B4DE for ; Fri, 15 Feb 2013 23:43:34 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id E5CE9E21 for ; Fri, 15 Feb 2013 23:43:15 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1FNh8fK041788 for ; Fri, 15 Feb 2013 16:43:09 -0700 (MST) (envelope-from ian@FreeBSD.org) 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 r1FNgka7045686; Fri, 15 Feb 2013 16:42:46 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Panic when calling _bus_dmamap_load_buffer() with BUS_DMA_COULD_BOUNCE (armv6) From: Ian Lepore To: Thomas Skibo In-Reply-To: <511EB6B9.3020902@sbcglobal.net> References: <511EB6B9.3020902@sbcglobal.net> Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Feb 2013 16:42:46 -0700 Message-ID: <1360971766.1164.0.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: Fri, 15 Feb 2013 23:43:34 -0000 On Fri, 2013-02-15 at 14:29 -0800, Thomas Skibo wrote: > Hello: > > This is the Zedboard port which is the armv6 architecture. I integrated > to my project branch late Wednesday which included some big changes to > busdma stuff. Now my kernel panics early in boot-up. > > I'm getting the a vm_fault when a certain driver calls bus_dmamap_load() > with a dma tag with BUS_DMA_COULD_BOUNCE set. > > What appears to be happening is that the code at lines 971-980 in > sys/arm/arm/busdma_machdep-v6.c is calling _bus_dmamap_count_pages() > before map->pmap is set (it's NULL). _bus_dmamap_count_pages() in turn > calls pmap_extract() with a NULL pointer. > > (_bus_dmamap_count_pages() is inlined by the compiler so doesn't show up > in the following back-trace.) > > I patched busdma_machdep-v6.c to get moving again by moving the > "map->pmap = pmap" statement before the BUS_DMA_COULD_BOUNCE check. I'm > not suggesting that's the right fix at all. > > ==== //depot/user/skibo/skibo_zynq/sys/arm/arm/busdma_machdep-v6.c#2 - > /home/skibo/p4/skibo_zynq/sys/arm/arm/busdma_machdep-v6.c ==== > 970a971,972 > > map->pmap = pmap; > > > 982d983 > < map->pmap = pmap; Yep, that was exactly the right fix, commited as r246859. Thanks! -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Feb 15 23:50: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 112A5550 for ; Fri, 15 Feb 2013 23:50:46 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 13284E46 for ; Fri, 15 Feb 2013 23:50:32 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1FNoWjq041894 for ; Fri, 15 Feb 2013 16:50:32 -0700 (MST) (envelope-from ian@FreeBSD.org) 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 r1FNoADj045693; Fri, 15 Feb 2013 16:50:10 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Beaglebone latest image observations - lock order reversal from ufs From: Ian Lepore To: Werner Thie In-Reply-To: <511EBB47.9030206@thieprojects.ch> References: <511EBB47.9030206@thieprojects.ch> Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Feb 2013 16:50:10 -0700 Message-ID: <1360972210.1164.4.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 15 Feb 2013 23:50:46 -0000 On Fri, 2013-02-15 at 23:48 +0100, Werner Thie wrote: > Hi > > today, after several failed attempts (build world failing), I managed > to build a new kernel with Tim's script for the Bone. > > From what I see it started spewing the 'ti_mmchs0: Error: current > cmd > null' again. > > ti_mmchs0: Error: current cmd NULL, already done? > > I'm now also getting the occasional > > lock order reversal: > 1st 0xc2c8ad84 ufs (ufs) @ /usr/local/src/sys/kern/vfs_subr.c:2176 > 2nd 0xc97a2378 bufwait (bufwait) @ > /usr/local/src/sys/ufs/ffs/ffs_vnops.c:261 > 3rd 0xc2d807f8 ufs (ufs) @ /usr/local/src/sys/kern/vfs_subr.c:2176 > KDB: stack backtrace: > : > : > Anybody out there being able to enlighten me about this? Does the > first > error relate or is triggered by second one? > This shouldn't be at all related to the "current cmd NULL" (that's a form of unexpected-interrupt error; it shouldn't be happening, but it should be fairly harmless). This LOR probably does need to be looked at more closely, though. > Seeping through dmesg I see > : > cpsw0: <3-port Switch Ethernet Subsystem> mem 0xcf619000-0xcf61cfff > irq > 40,41,42,43 on simplebus0 > cpsw0: CPSW SS Version 1.12 (0) > _bus_dmamap_sync: wrong user map: 0 4 This is most likely the same problem Thomas Skibo just submitted a fix for. If so, it's committed as r246859. -- Ian > cpsw0: Initial queue size TX=128 RX=384 > cpsw0: Ethernet address: 00:18:31:8e:0e:1d > : > > I also observed that Python27 built fresh from ports aborts on > importing > ctypes. > > I keep on building and reporting, the progress is still amazing! > > If there's anything specific to try, please let me know > > Thxs, Werner > > From owner-freebsd-arm@FreeBSD.ORG Sat Feb 16 05:54:21 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 3700B1CE; Sat, 16 Feb 2013 05:54:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0FAF5AAC; Sat, 16 Feb 2013 05:54:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1G5sEYi033028; Sat, 16 Feb 2013 00:54:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1G5sDM5033027; Sat, 16 Feb 2013 05:54:13 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 16 Feb 2013 05:54:13 GMT Message-Id: <201302160554.r1G5sDM5033027@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 05:54:21 -0000 TB --- 2013-02-16 05:20:36 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-16 05:20:36 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-16 05:20:36 - starting HEAD tinderbox run for arm/arm TB --- 2013-02-16 05:20:36 - cleaning the object tree TB --- 2013-02-16 05:21:46 - /usr/local/bin/svn stat /src TB --- 2013-02-16 05:21:49 - At svn revision 246870 TB --- 2013-02-16 05:21:50 - building world TB --- 2013-02-16 05:21:50 - CROSS_BUILD_TESTING=YES TB --- 2013-02-16 05:21:50 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-16 05:21:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-16 05:21:50 - SRCCONF=/dev/null TB --- 2013-02-16 05:21:50 - TARGET=arm TB --- 2013-02-16 05:21:50 - TARGET_ARCH=arm TB --- 2013-02-16 05:21:50 - TZ=UTC TB --- 2013-02-16 05:21:50 - __MAKE_CONF=/dev/null TB --- 2013-02-16 05:21:50 - cd /src TB --- 2013-02-16 05:21:50 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Feb 16 05:21:54 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/buffer.c -o buffer.o cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dane.c -o dane.o cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dname.c -o dname.o cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dnssec.c -o dnssec.o cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dnssec_sign.c -o dnssec_sign.o cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dnssec_verify.c -o dnssec_verify.o cc1: warnings being treated as errors /src/lib/libldns/../../contrib/ldns/dnssec_verify.c:638: warning: 'ldns_dnssec_trust_tree_print_sm' defined but not used *** [dnssec_verify.o] Error code 1 Stop in /src/lib/libldns. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-16 05:54:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-16 05:54:13 - ERROR: failed to build world TB --- 2013-02-16 05:54:13 - 1480.55 user 317.95 system 2017.29 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Feb 16 12:24:15 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 5B035104; Sat, 16 Feb 2013 12:24:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2C42686C; Sat, 16 Feb 2013 12:24:15 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1GCOErP036539; Sat, 16 Feb 2013 07:24:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1GCOEJS036538; Sat, 16 Feb 2013 12:24:14 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 16 Feb 2013 12:24:14 GMT Message-Id: <201302161224.r1GCOEJS036538@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 12:24:15 -0000 TB --- 2013-02-16 11:50:26 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-16 11:50:26 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-16 11:50:26 - starting HEAD tinderbox run for arm/arm TB --- 2013-02-16 11:50:26 - cleaning the object tree TB --- 2013-02-16 11:51:44 - /usr/local/bin/svn stat /src TB --- 2013-02-16 11:51:47 - At svn revision 246872 TB --- 2013-02-16 11:51:48 - building world TB --- 2013-02-16 11:51:48 - CROSS_BUILD_TESTING=YES TB --- 2013-02-16 11:51:48 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-16 11:51:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-16 11:51:48 - SRCCONF=/dev/null TB --- 2013-02-16 11:51:48 - TARGET=arm TB --- 2013-02-16 11:51:48 - TARGET_ARCH=arm TB --- 2013-02-16 11:51:48 - TZ=UTC TB --- 2013-02-16 11:51:48 - __MAKE_CONF=/dev/null TB --- 2013-02-16 11:51:48 - cd /src TB --- 2013-02-16 11:51:48 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Feb 16 11:51:53 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/buffer.c -o buffer.o cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dane.c -o dane.o cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dname.c -o dname.o cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dnssec.c -o dnssec.o cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dnssec_sign.c -o dnssec_sign.o cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dnssec_verify.c -o dnssec_verify.o cc1: warnings being treated as errors /src/lib/libldns/../../contrib/ldns/dnssec_verify.c:638: warning: 'ldns_dnssec_trust_tree_print_sm' defined but not used *** [dnssec_verify.o] Error code 1 Stop in /src/lib/libldns. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-16 12:24:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-16 12:24:14 - ERROR: failed to build world TB --- 2013-02-16 12:24:14 - 1478.26 user 319.11 system 2028.06 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Feb 16 18:31:55 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 282B95B9 for ; Sat, 16 Feb 2013 18:31:55 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id B53E8840 for ; Sat, 16 Feb 2013 18:31:54 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1GIVrQP056054 for ; Sat, 16 Feb 2013 11:31:53 -0700 (MST) (envelope-from ian@FreeBSD.org) 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 r1GIVUXk046559; Sat, 16 Feb 2013 11:31:30 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: kernel address space & auto-tuning From: Ian Lepore To: Alan Cox In-Reply-To: <51192C44.1060204@rice.edu> References: <51192C44.1060204@rice.edu> Content-Type: text/plain; charset="us-ascii" Date: Sat, 16 Feb 2013 11:31:30 -0700 Message-ID: <1361039490.1164.36.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "arm@freebsd.org" , Kostik Belousov 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, 16 Feb 2013 18:31:55 -0000 On Mon, 2013-02-11 at 11:37 -0600, Alan Cox wrote: > Ian and others here, > > Could you please test the attached patch? However, before you apply > this patch, can you run > > sysctl vm.max_kernel_address > > and record the output. I'd like to know how this output changes after > the patch is applied. > > Here is an explanation of what the patch does: > > 1. Recently, a #define for VM_KMEM_SIZE_SCALE was added to > arm/include/vmparam.h. This is good. However, it will create a problem > as soon as someone gets arm hardware with more than ~1.5GB of RAM. This > patch introduces a cap on the size of the kmem submap so that booting on > future larger-memory systems won't fail. > > 2. It appears that arm is more like sparc64 than x86 in the respect that > the ending address of the kernel address space can vary from machine to > machine. To be more precise, I'm talking about the kernel address space > into which we can dynamically map and unmap code/data and I'm not > including regions for device access or direct maps. Thus, the current > #define for VM_MAX_KERNEL_ADDRESS on arm is really incorrect or at least > inconsistent with how this is defined on other architectures. This > patch borrows from sparc64 in defining a global variable, > vm_max_kernel_address, rather than a constant #define to represent the > end of the kernel address space. > > Thanks, > Alan > Took me a while to get to this, here's the results... DreamPlug (armv5) real memory = 536870912 (512 MB) avail memory = 516612096 (492 MB) before: vm.max_kernel_address: 4294967295 0xFFFFFFFF after: vm.max_kernel_address: 4026531840 0xF0000000 rpi (armv6) real memory = 536870912 (512 MB) avail memory = 386789376 (368 MB) before: vm.max_kernel_address: 4294967295 0xFFFFFFFF after: vm.max_kernel_address: 3741319168 0xDF000000 Beaglebone (armv7) real memory = 268435456 (256 MB) avail memory = 254808064 (243 MB) before: vm.max_kernel_address: 4294967295 0xFFFFFFFF after: vm.max_kernel_address: 3741319168 0xDF000000 It appears that the values that go into making the max kernel address on various arm platforms may be choosen somewhat arbitrarily. Most SoCs map the on-chip register space "somewhere" way up near the end of the 32-bit virtual address space, and set the max kernel address to that point. 0xD0000000, 0xE0000000, and 0xF0000000 all seem to be popular choices. I just changed the value for DreamPlug, which only needs 1MB of register mappings, from 0xF0000000 to 0xFE000000 and it seems to be working fine. So, given that the variable ending address may be arbitrary and not much different than the current 0xFFFFFFFF constant, I wonder if your changes are going to have the intended effect? It may be that the important part of the change would come next: pick better arbitrary ending addresses. Or do what sparc seems to be doing, and choose a size then set the address accordingly. Speaking of what sparc is doing, this sparc code looks suspicious: virtsz = roundup(5 / 3 * physsz, PAGE_SIZE_4M << (PAGE_SHIFT - TTE_SHIFT)); I wonder if the intent there was "3 * physsz / 5"? -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Feb 16 18:44:25 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 527A6715; Sat, 16 Feb 2013 18:44:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 29B87889; Sat, 16 Feb 2013 18:44:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r1GIiOY0039616; Sat, 16 Feb 2013 13:44:24 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r1GIiO7C039615; Sat, 16 Feb 2013 18:44:24 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 16 Feb 2013 18:44:24 GMT Message-Id: <201302161844.r1GIiO7C039615@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 18:44:25 -0000 TB --- 2013-02-16 18:10:37 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-02-16 18:10:37 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-02-16 18:10:37 - starting HEAD tinderbox run for arm/arm TB --- 2013-02-16 18:10:37 - cleaning the object tree TB --- 2013-02-16 18:11:55 - /usr/local/bin/svn stat /src TB --- 2013-02-16 18:11:58 - At svn revision 246878 TB --- 2013-02-16 18:11:59 - building world TB --- 2013-02-16 18:11:59 - CROSS_BUILD_TESTING=YES TB --- 2013-02-16 18:11:59 - MAKEOBJDIRPREFIX=/obj TB --- 2013-02-16 18:11:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-02-16 18:11:59 - SRCCONF=/dev/null TB --- 2013-02-16 18:11:59 - TARGET=arm TB --- 2013-02-16 18:11:59 - TARGET_ARCH=arm TB --- 2013-02-16 18:11:59 - TZ=UTC TB --- 2013-02-16 18:11:59 - __MAKE_CONF=/dev/null TB --- 2013-02-16 18:11:59 - cd /src TB --- 2013-02-16 18:11:59 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Feb 16 18:12:04 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/buffer.c -o buffer.o cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dane.c -o dane.o cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dname.c -o dname.o cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dnssec.c -o dnssec.o cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dnssec_sign.c -o dnssec_sign.o cc -O -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dnssec_verify.c -o dnssec_verify.o cc1: warnings being treated as errors /src/lib/libldns/../../contrib/ldns/dnssec_verify.c:638: warning: 'ldns_dnssec_trust_tree_print_sm' defined but not used *** [dnssec_verify.o] Error code 1 Stop in /src/lib/libldns. *** [all] Error code 1 Stop in /src/lib. *** [lib__L] Error code 1 Stop in /src. *** [libraries] Error code 1 Stop in /src. *** [_libraries] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-02-16 18:44:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-02-16 18:44:24 - ERROR: failed to build world TB --- 2013-02-16 18:44:24 - 1479.85 user 318.39 system 2026.97 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Feb 16 19:05:54 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 46D3AB76; Sat, 16 Feb 2013 19:05:54 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by mx1.freebsd.org (Postfix) with ESMTP id 2400E926; Sat, 16 Feb 2013 19:05:53 +0000 (UTC) Received: from mh2.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh2.mail.rice.edu (Postfix) with ESMTP id 569F9500129; Sat, 16 Feb 2013 13:05:53 -0600 (CST) Received: from mh2.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh2.mail.rice.edu (Postfix) with ESMTP id 5314550012F; Sat, 16 Feb 2013 13:05:53 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel Received: from mh2.mail.rice.edu ([127.0.0.1]) by mh2.mail.rice.edu (mh2.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id t1Sy1t_KzHqx; Sat, 16 Feb 2013 13:05:53 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id BA577500129; Sat, 16 Feb 2013 13:05:52 -0600 (CST) Message-ID: <511FD88E.2020403@rice.edu> Date: Sat, 16 Feb 2013 13:05:50 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130127 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ian Lepore Subject: Re: kernel address space & auto-tuning References: <51192C44.1060204@rice.edu> <1361039490.1164.36.camel@revolution.hippie.lan> In-Reply-To: <1361039490.1164.36.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "arm@freebsd.org" , Kostik Belousov 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, 16 Feb 2013 19:05:54 -0000 On 02/16/2013 12:31, Ian Lepore wrote: > On Mon, 2013-02-11 at 11:37 -0600, Alan Cox wrote: >> Ian and others here, >> >> Could you please test the attached patch? However, before you apply >> this patch, can you run >> >> sysctl vm.max_kernel_address >> >> and record the output. I'd like to know how this output changes after >> the patch is applied. >> >> Here is an explanation of what the patch does: >> >> 1. Recently, a #define for VM_KMEM_SIZE_SCALE was added to >> arm/include/vmparam.h. This is good. However, it will create a problem >> as soon as someone gets arm hardware with more than ~1.5GB of RAM. This >> patch introduces a cap on the size of the kmem submap so that booting on >> future larger-memory systems won't fail. >> >> 2. It appears that arm is more like sparc64 than x86 in the respect that >> the ending address of the kernel address space can vary from machine to >> machine. To be more precise, I'm talking about the kernel address space >> into which we can dynamically map and unmap code/data and I'm not >> including regions for device access or direct maps. Thus, the current >> #define for VM_MAX_KERNEL_ADDRESS on arm is really incorrect or at least >> inconsistent with how this is defined on other architectures. This >> patch borrows from sparc64 in defining a global variable, >> vm_max_kernel_address, rather than a constant #define to represent the >> end of the kernel address space. >> >> Thanks, >> Alan >> > Took me a while to get to this, here's the results... > > DreamPlug (armv5) > > real memory = 536870912 (512 MB) > avail memory = 516612096 (492 MB) > > before: vm.max_kernel_address: 4294967295 0xFFFFFFFF > after: vm.max_kernel_address: 4026531840 0xF0000000 > > rpi (armv6) > > real memory = 536870912 (512 MB) > avail memory = 386789376 (368 MB) > > before: vm.max_kernel_address: 4294967295 0xFFFFFFFF > after: vm.max_kernel_address: 3741319168 0xDF000000 > > Beaglebone (armv7) > > real memory = 268435456 (256 MB) > avail memory = 254808064 (243 MB) > > before: vm.max_kernel_address: 4294967295 0xFFFFFFFF > after: vm.max_kernel_address: 3741319168 0xDF000000 > > It appears that the values that go into making the max kernel address on > various arm platforms may be choosen somewhat arbitrarily. Most SoCs > map the on-chip register space "somewhere" way up near the end of the > 32-bit virtual address space, and set the max kernel address to that > point. 0xD0000000, 0xE0000000, and 0xF0000000 all seem to be popular > choices. I just changed the value for DreamPlug, which only needs 1MB > of register mappings, from 0xF0000000 to 0xFE000000 and it seems to be > working fine. > > So, given that the variable ending address may be arbitrary and not much > different than the current 0xFFFFFFFF constant, I wonder if your changes > are going to have the intended effect? There are two parts to my change. One is making VM_MAX_KERNEL_ADDRESS accurately reflect the end of the kernel's address space by making it a variable. The other is placing a cap on the size of the kernel's heap, i.e., the kmem submap. Without that cap, machines with larger physical memories won't boot. In fact, I just saw an e-mail a few hours ago from Oleksandr Tymoshenko saying that his 1GB Beaglebone won't boot anymore. > ... It may be that the important > part of the change would come next: pick better arbitrary ending > addresses. Is the location of the register mapping something that the kernel chooses? Or is it something that is passed to the kernel at boot-time? > Or do what sparc seems to be doing, and choose a size then > set the address accordingly. > > Speaking of what sparc is doing, this sparc code looks suspicious: > > virtsz = roundup(5 / 3 * physsz, PAGE_SIZE_4M << > (PAGE_SHIFT - TTE_SHIFT)); > > I wonder if the intent there was "3 * physsz / 5"? > > -- Ian > > > From owner-freebsd-arm@FreeBSD.ORG Sat Feb 16 19:35:21 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 6A6624F1 for ; Sat, 16 Feb 2013 19:35:21 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 251609E6 for ; Sat, 16 Feb 2013 19:35:20 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1GJZK58057024 for ; Sat, 16 Feb 2013 12:35:20 -0700 (MST) (envelope-from ian@FreeBSD.org) 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 r1GJYvBX046635; Sat, 16 Feb 2013 12:34:57 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: kernel address space & auto-tuning From: Ian Lepore To: Alan Cox In-Reply-To: <511FD88E.2020403@rice.edu> References: <51192C44.1060204@rice.edu> <1361039490.1164.36.camel@revolution.hippie.lan> <511FD88E.2020403@rice.edu> Content-Type: text/plain; charset="us-ascii" Date: Sat, 16 Feb 2013 12:34:57 -0700 Message-ID: <1361043297.1164.43.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "arm@freebsd.org" , Kostik Belousov 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, 16 Feb 2013 19:35:21 -0000 On Sat, 2013-02-16 at 13:05 -0600, Alan Cox wrote: > On 02/16/2013 12:31, Ian Lepore wrote: > > On Mon, 2013-02-11 at 11:37 -0600, Alan Cox wrote: > >> Ian and others here, > >> > >> Could you please test the attached patch? However, before you apply > >> this patch, can you run > >> > >> sysctl vm.max_kernel_address > >> > >> and record the output. I'd like to know how this output changes after > >> the patch is applied. > >> > >> Here is an explanation of what the patch does: > >> > >> 1. Recently, a #define for VM_KMEM_SIZE_SCALE was added to > >> arm/include/vmparam.h. This is good. However, it will create a problem > >> as soon as someone gets arm hardware with more than ~1.5GB of RAM. This > >> patch introduces a cap on the size of the kmem submap so that booting on > >> future larger-memory systems won't fail. > >> > >> 2. It appears that arm is more like sparc64 than x86 in the respect that > >> the ending address of the kernel address space can vary from machine to > >> machine. To be more precise, I'm talking about the kernel address space > >> into which we can dynamically map and unmap code/data and I'm not > >> including regions for device access or direct maps. Thus, the current > >> #define for VM_MAX_KERNEL_ADDRESS on arm is really incorrect or at least > >> inconsistent with how this is defined on other architectures. This > >> patch borrows from sparc64 in defining a global variable, > >> vm_max_kernel_address, rather than a constant #define to represent the > >> end of the kernel address space. > >> > >> Thanks, > >> Alan > >> > > Took me a while to get to this, here's the results... > > > > DreamPlug (armv5) > > > > real memory = 536870912 (512 MB) > > avail memory = 516612096 (492 MB) > > > > before: vm.max_kernel_address: 4294967295 0xFFFFFFFF > > after: vm.max_kernel_address: 4026531840 0xF0000000 > > > > rpi (armv6) > > > > real memory = 536870912 (512 MB) > > avail memory = 386789376 (368 MB) > > > > before: vm.max_kernel_address: 4294967295 0xFFFFFFFF > > after: vm.max_kernel_address: 3741319168 0xDF000000 > > > > Beaglebone (armv7) > > > > real memory = 268435456 (256 MB) > > avail memory = 254808064 (243 MB) > > > > before: vm.max_kernel_address: 4294967295 0xFFFFFFFF > > after: vm.max_kernel_address: 3741319168 0xDF000000 > > > > It appears that the values that go into making the max kernel address on > > various arm platforms may be choosen somewhat arbitrarily. Most SoCs > > map the on-chip register space "somewhere" way up near the end of the > > 32-bit virtual address space, and set the max kernel address to that > > point. 0xD0000000, 0xE0000000, and 0xF0000000 all seem to be popular > > choices. I just changed the value for DreamPlug, which only needs 1MB > > of register mappings, from 0xF0000000 to 0xFE000000 and it seems to be > > working fine. > > > > So, given that the variable ending address may be arbitrary and not much > > different than the current 0xFFFFFFFF constant, I wonder if your changes > > are going to have the intended effect? > > There are two parts to my change. One is making VM_MAX_KERNEL_ADDRESS > accurately reflect the end of the kernel's address space by making it a > variable. The other is placing a cap on the size of the kernel's heap, > i.e., the kmem submap. Without that cap, machines with larger physical > memories won't boot. In fact, I just saw an e-mail a few hours ago from > Oleksandr Tymoshenko saying that his 1GB Beaglebone won't boot anymore. > > > ... It may be that the important > > part of the change would come next: pick better arbitrary ending > > addresses. > > Is the location of the register mapping something that the kernel > chooses? Or is it something that is passed to the kernel at boot-time? > As near as I can tell, it's a pretty much arbitrary choice on a per-SoC basis, always hard-coded with a named constant of some sort in kernel source code. 0xE0000000 seems to be a popular choice, with comments about it being the address used to bootstrap the initial devmap. That appears to be true for only one SoC. I think maybe there's been some cut and paste propagation here. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Feb 16 19:51:23 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 5CB1385E; Sat, 16 Feb 2013 19:51:23 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by mx1.freebsd.org (Postfix) with ESMTP id 0BFF3A5C; Sat, 16 Feb 2013 19:51:22 +0000 (UTC) Received: from mh2.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh2.mail.rice.edu (Postfix) with ESMTP id BD07450012F; Sat, 16 Feb 2013 13:51:22 -0600 (CST) Received: from mh2.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh2.mail.rice.edu (Postfix) with ESMTP id BBA57500129; Sat, 16 Feb 2013 13:51:22 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel Received: from mh2.mail.rice.edu ([127.0.0.1]) by mh2.mail.rice.edu (mh2.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id HUTS3RkPuuW4; Sat, 16 Feb 2013 13:51:22 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id 4E39750011D; Sat, 16 Feb 2013 13:51:22 -0600 (CST) Message-ID: <511FE339.1010703@rice.edu> Date: Sat, 16 Feb 2013 13:51:21 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130127 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ian Lepore Subject: Re: kernel address space & auto-tuning References: <51192C44.1060204@rice.edu> <1361039490.1164.36.camel@revolution.hippie.lan> <511FD88E.2020403@rice.edu> <1361043297.1164.43.camel@revolution.hippie.lan> In-Reply-To: <1361043297.1164.43.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "arm@freebsd.org" , Kostik Belousov 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, 16 Feb 2013 19:51:23 -0000 On 02/16/2013 13:34, Ian Lepore wrote: > On Sat, 2013-02-16 at 13:05 -0600, Alan Cox wrote: >> On 02/16/2013 12:31, Ian Lepore wrote: >>> On Mon, 2013-02-11 at 11:37 -0600, Alan Cox wrote: >>>> Ian and others here, >>>> >>>> Could you please test the attached patch? However, before you apply >>>> this patch, can you run >>>> >>>> sysctl vm.max_kernel_address >>>> >>>> and record the output. I'd like to know how this output changes after >>>> the patch is applied. >>>> >>>> Here is an explanation of what the patch does: >>>> >>>> 1. Recently, a #define for VM_KMEM_SIZE_SCALE was added to >>>> arm/include/vmparam.h. This is good. However, it will create a problem >>>> as soon as someone gets arm hardware with more than ~1.5GB of RAM. This >>>> patch introduces a cap on the size of the kmem submap so that booting on >>>> future larger-memory systems won't fail. >>>> >>>> 2. It appears that arm is more like sparc64 than x86 in the respect that >>>> the ending address of the kernel address space can vary from machine to >>>> machine. To be more precise, I'm talking about the kernel address space >>>> into which we can dynamically map and unmap code/data and I'm not >>>> including regions for device access or direct maps. Thus, the current >>>> #define for VM_MAX_KERNEL_ADDRESS on arm is really incorrect or at least >>>> inconsistent with how this is defined on other architectures. This >>>> patch borrows from sparc64 in defining a global variable, >>>> vm_max_kernel_address, rather than a constant #define to represent the >>>> end of the kernel address space. >>>> >>>> Thanks, >>>> Alan >>>> >>> Took me a while to get to this, here's the results... >>> >>> DreamPlug (armv5) >>> >>> real memory = 536870912 (512 MB) >>> avail memory = 516612096 (492 MB) >>> >>> before: vm.max_kernel_address: 4294967295 0xFFFFFFFF >>> after: vm.max_kernel_address: 4026531840 0xF0000000 >>> >>> rpi (armv6) >>> >>> real memory = 536870912 (512 MB) >>> avail memory = 386789376 (368 MB) >>> >>> before: vm.max_kernel_address: 4294967295 0xFFFFFFFF >>> after: vm.max_kernel_address: 3741319168 0xDF000000 >>> >>> Beaglebone (armv7) >>> >>> real memory = 268435456 (256 MB) >>> avail memory = 254808064 (243 MB) >>> >>> before: vm.max_kernel_address: 4294967295 0xFFFFFFFF >>> after: vm.max_kernel_address: 3741319168 0xDF000000 >>> >>> It appears that the values that go into making the max kernel address on >>> various arm platforms may be choosen somewhat arbitrarily. Most SoCs >>> map the on-chip register space "somewhere" way up near the end of the >>> 32-bit virtual address space, and set the max kernel address to that >>> point. 0xD0000000, 0xE0000000, and 0xF0000000 all seem to be popular >>> choices. I just changed the value for DreamPlug, which only needs 1MB >>> of register mappings, from 0xF0000000 to 0xFE000000 and it seems to be >>> working fine. >>> >>> So, given that the variable ending address may be arbitrary and not much >>> different than the current 0xFFFFFFFF constant, I wonder if your changes >>> are going to have the intended effect? >> There are two parts to my change. One is making VM_MAX_KERNEL_ADDRESS >> accurately reflect the end of the kernel's address space by making it a >> variable. The other is placing a cap on the size of the kernel's heap, >> i.e., the kmem submap. Without that cap, machines with larger physical >> memories won't boot. In fact, I just saw an e-mail a few hours ago from >> Oleksandr Tymoshenko saying that his 1GB Beaglebone won't boot anymore. >> >>> ... It may be that the important >>> part of the change would come next: pick better arbitrary ending >>> addresses. >> Is the location of the register mapping something that the kernel >> chooses? Or is it something that is passed to the kernel at boot-time? >> > As near as I can tell, it's a pretty much arbitrary choice on a per-SoC > basis, always hard-coded with a named constant of some sort in kernel > source code. 0xE0000000 seems to be a popular choice, with comments > about it being the address used to bootstrap the initial devmap. That > appears to be true for only one SoC. I think maybe there's been some > cut and paste propagation here. > Then, it sounds like VM_MAX_KERNEL_ADDRESS doesn't need to be defined as a variable (as it is on sparc64). It just needs to be correctly defined by each SoC configuration. From owner-freebsd-arm@FreeBSD.ORG Sat Feb 16 19:59:49 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 3D43DA60; Sat, 16 Feb 2013 19:59: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 F240EA84; Sat, 16 Feb 2013 19:59:48 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1GJxgRC051334; Sat, 16 Feb 2013 19:59:42 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id iw4i5ps4trivhjmsv2z4nnfn46; Sat, 16 Feb 2013 19:59:42 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: kernel address space & auto-tuning Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <1361043297.1164.43.camel@revolution.hippie.lan> Date: Sat, 16 Feb 2013 11:59:40 -0800 Content-Transfer-Encoding: 7bit Message-Id: <343AF6FE-05D9-48FB-9385-7EC1A532D057@kientzle.com> References: <51192C44.1060204@rice.edu> <1361039490.1164.36.camel@revolution.hippie.lan> <511FD88E.2020403@rice.edu> <1361043297.1164.43.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: "arm@freebsd.org" , Kostik Belousov , Alan Cox 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, 16 Feb 2013 19:59:49 -0000 >> >>> ... It may be that the important >>> part of the change would come next: pick better arbitrary ending >>> addresses. >> >> Is the location of the register mapping something that the kernel >> chooses? Or is it something that is passed to the kernel at boot-time? >> > > As near as I can tell, it's a pretty much arbitrary choice on a per-SoC > basis, always hard-coded with a named constant of some sort in kernel > source code. 0xE0000000 seems to be a popular choice, with comments > about it being the address used to bootstrap the initial devmap. That > appears to be true for only one SoC. I think maybe there's been some > cut and paste propagation here. Related to another thread, it would be nice to find ways to get more of these per-SoC values out of hardcoded constants. In this case, the FDT should give the size and physical address of the register map. Can we use that to determine the virtual mapping dynamically at runtime? Tim From owner-freebsd-arm@FreeBSD.ORG Sat Feb 16 20:09:00 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 36BABB04 for ; Sat, 16 Feb 2013 20:09:00 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 9017CAB1 for ; Sat, 16 Feb 2013 20:08:59 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1GK8wfH057391 for ; Sat, 16 Feb 2013 13:08:58 -0700 (MST) (envelope-from ian@FreeBSD.org) 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 r1GK8arc046668; Sat, 16 Feb 2013 13:08:36 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: kernel address space & auto-tuning From: Ian Lepore To: Tim Kientzle In-Reply-To: <343AF6FE-05D9-48FB-9385-7EC1A532D057@kientzle.com> References: <51192C44.1060204@rice.edu> <1361039490.1164.36.camel@revolution.hippie.lan> <511FD88E.2020403@rice.edu> <1361043297.1164.43.camel@revolution.hippie.lan> <343AF6FE-05D9-48FB-9385-7EC1A532D057@kientzle.com> Content-Type: text/plain; charset="us-ascii" Date: Sat, 16 Feb 2013 13:08:36 -0700 Message-ID: <1361045316.1164.48.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "arm@freebsd.org" , Kostik Belousov , Alan Cox 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, 16 Feb 2013 20:09:00 -0000 On Sat, 2013-02-16 at 11:59 -0800, Tim Kientzle wrote: > >> > >>> ... It may be that the important > >>> part of the change would come next: pick better arbitrary ending > >>> addresses. > >> > >> Is the location of the register mapping something that the kernel > >> chooses? Or is it something that is passed to the kernel at boot-time? > >> > > > > As near as I can tell, it's a pretty much arbitrary choice on a per-SoC > > basis, always hard-coded with a named constant of some sort in kernel > > source code. 0xE0000000 seems to be a popular choice, with comments > > about it being the address used to bootstrap the initial devmap. That > > appears to be true for only one SoC. I think maybe there's been some > > cut and paste propagation here. > > Related to another thread, it would be nice to find > ways to get more of these per-SoC values out > of hardcoded constants. > > In this case, the FDT should give the size and physical > address of the register map. Can we use that to > determine the virtual mapping dynamically at runtime? > > Tim Conceptually, yeah, it'd just be something like 0xffffff00 - size, but the fdt_immr_addr() routine that finds the PA and size and sets things up based on them takes the desired VA as an argument. Maybe a special value could request that it calculate a VA based on the size it finds in the data. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Feb 16 22:55:34 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 9883BAB9 for ; Sat, 16 Feb 2013 22:55:34 +0000 (UTC) (envelope-from wynkoop@wynn.com) Received: from mail.wynn.com (wa3yre.wynn.com [199.89.147.3]) by mx1.freebsd.org (Postfix) with ESMTP id 425E6EDD for ; Sat, 16 Feb 2013 22:55:33 +0000 (UTC) Received: from ivory.wynn.com (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r1GMtPNv015311 for ; Sat, 16 Feb 2013 17:55:25 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Sat, 16 Feb 2013 17:55:25 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: Just built world on Pi Message-ID: <20130216175525.283d1b13@ivory.wynn.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 16 Feb 2013 22:55:34 -0000 Greeting- Building world just completed on my Pi. The time was about 37 hours. Not bad for a $35 computer! -Brett -- wynkoop@wynn.com http://prd4.wynn.com/wynkoop/pgp-keys.txt 917-642-6925 718-717-5435 April 19, 1775 An English attempt to confiscate guns from Americans triggered a successful revolution...... Dear Congress, that's a hint.