From owner-freebsd-arm@FreeBSD.ORG Sun Jan 27 02:19:57 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 E76D2F5 for ; Sun, 27 Jan 2013 02:19:57 +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 AFD6BA47 for ; Sun, 27 Jan 2013 02:19:57 +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 <0MH900DLLHS1FU10@smtp5.clear.net.nz> for freebsd-arm@freebsd.org; Sun, 27 Jan 2013 15:04:49 +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, 27 Jan 2013 15:04:49 +1300 Date: Sun, 27 Jan 2013 15:04:29 +1300 From: Andrew Turner Subject: FreeBSD ARM EABI in head To: freebsd-arm@FreeBSD.org Message-id: <20130127150429.5a232f66@bender> 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, 27 Jan 2013 02:19:58 -0000 I have finished merging in my changes from the ARM EABI project branch into head. I would appreciate it if people would be able to test it. To build it you will need a checkout of head no earlier than r245942. You can then run the normal build procedure with WITH_ARM_EABI set, for example: make TARGET_ARCH=armv6 -DWITH_ARM_EABI buildworld make TARGET_ARCH=armv6 -DWITH_ARM_EABI buildkernel TARGET=RPI-B If your kernel config includes DDB you will need to set WITH_ARM_EABI when building your kernel to get backtrace support. I have tested the ARM EABI branch on arm and armv6 and the head merge on armv6 and expect these two to mostly work. As I have no access to any big-endian ARM hardware I have been unable to test there. There are currently three known issues: * No clang support - this should be fixed soon, I'm waiting on another patch to go into head first. * No gdb - I'm testing a fix for this. * No bind utils - for some reason the bind tools, e.g. dig, segfault in the sig_wait syscall. Andrew From owner-freebsd-arm@FreeBSD.ORG Sun Jan 27 11:06: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 D2819E7D; Sun, 27 Jan 2013 11:06:54 +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 A4930AF2; Sun, 27 Jan 2013 11:06:54 +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 r0RB6mRI094749; Sun, 27 Jan 2013 06:06:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0RB6lLb094734; Sun, 27 Jan 2013 11:06:47 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 27 Jan 2013 11:06:47 GMT Message-Id: <201301271106.r0RB6lLb094734@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: Sun, 27 Jan 2013 11:06:54 -0000 TB --- 2013-01-27 10:10:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-27 10:10:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-27 10:10:20 - starting HEAD tinderbox run for arm/arm TB --- 2013-01-27 10:10:20 - cleaning the object tree TB --- 2013-01-27 10:10:20 - /usr/local/bin/svn stat /src TB --- 2013-01-27 10:10:24 - At svn revision 245977 TB --- 2013-01-27 10:10:25 - building world TB --- 2013-01-27 10:10:25 - CROSS_BUILD_TESTING=YES TB --- 2013-01-27 10:10:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-27 10:10:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-27 10:10:25 - SRCCONF=/dev/null TB --- 2013-01-27 10:10:25 - TARGET=arm TB --- 2013-01-27 10:10:25 - TARGET_ARCH=arm TB --- 2013-01-27 10:10:25 - TZ=UTC TB --- 2013-01-27 10:10:25 - __MAKE_CONF=/dev/null TB --- 2013-01-27 10:10:25 - cd /src TB --- 2013-01-27 10:10:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Jan 27 10:10:30 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 >>> World build completed on Sun Jan 27 11:06:47 UTC 2013 TB --- 2013-01-27 11:06:47 - generating LINT kernel config TB --- 2013-01-27 11:06:47 - cd /src/sys/arm/conf TB --- 2013-01-27 11:06:47 - /usr/bin/make -B LINT TB --- 2013-01-27 11:06:47 - cd /src/sys/arm/conf TB --- 2013-01-27 11:06:47 - /usr/sbin/config -m LINT TB --- 2013-01-27 11:06:47 - building LINT kernel TB --- 2013-01-27 11:06:47 - CROSS_BUILD_TESTING=YES TB --- 2013-01-27 11:06:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-27 11:06:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-27 11:06:47 - SRCCONF=/dev/null TB --- 2013-01-27 11:06:47 - TARGET=arm TB --- 2013-01-27 11:06:47 - TARGET_ARCH=arm TB --- 2013-01-27 11:06:47 - TZ=UTC TB --- 2013-01-27 11:06:47 - __MAKE_CONF=/dev/null TB --- 2013-01-27 11:06:47 - cd /src TB --- 2013-01-27 11:06:47 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jan 27 11:06:47 UTC 2013 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /src/sys/arm/conf; PATH=/obj/arm.arm/src/tmp/legacy/usr/sbin:/obj/arm.arm/src/tmp/legacy/usr/bin:/obj/arm.arm/src/tmp/legacy/usr/games:/obj/arm.arm/src/tmp/usr/sbin:/obj/arm.arm/src/tmp/usr/bin:/obj/arm.arm/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /obj/arm.arm/src/sys/LINT /src/sys/arm/conf/LINT WARNING: duplicate option `GEOM_PART_BSD' encountered. WARNING: duplicate option `GEOM_PART_MBR' encountered. WARNING: duplicate option `DEV_MEM' encountered. WARNING: duplicate device `mem' encountered. WARNING: duplicate option `CAM_DEBUG_DELAY' encountered. config: ../mv/kirkwood/files.sheevaplug: No such file or directory *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-27 11:06:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-27 11:06:47 - ERROR: failed to build LINT kernel TB --- 2013-01-27 11:06:47 - 2534.13 user 577.03 system 3387.27 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Jan 27 13:42:04 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 C1A0E687 for ; Sun, 27 Jan 2013 13:42:04 +0000 (UTC) (envelope-from olli@grabthar.secnetix.de) Received: from grabthar.secnetix.de (grabthar.secnetix.de [212.17.241.225]) by mx1.freebsd.org (Postfix) with ESMTP id 535539F for ; Sun, 27 Jan 2013 13:42:00 +0000 (UTC) Received: from grabthar.secnetix.de (localhost [127.0.0.1]) by grabthar.secnetix.de (8.14.5/8.14.5) with ESMTP id r0RDfwlY009398; Sun, 27 Jan 2013 14:41:58 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by grabthar.secnetix.de (8.14.5/8.14.5/Submit) id r0RDfwTp009397; Sun, 27 Jan 2013 14:41:58 +0100 (CET) (envelope-from olli) Date: Sun, 27 Jan 2013 14:41:58 +0100 (CET) Message-Id: <201301271341.r0RDfwTp009397@grabthar.secnetix.de> From: Oliver Fromme To: freebsd-arm@FreeBSD.ORG, george+freebsd@m5p.com Subject: Re: FreeBSD ARM with swap partition and tmpfs In-Reply-To: <50FB2316.4060300@m5p.com> X-Newsgroups: list.freebsd-arm User-Agent: tin/2.0.1-20111224 ("Achenvoir") (UNIX) (FreeBSD/9.1-PRERELEASE-20120811 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 13:42:04 -0000 George Mitchell wrote: > On 01/15/13 04:02, Alie Tan wrote: > > Hi, > > > > I just built new 4G FreeBSD image for Raspberry Pi (username/password: > > root/freebsdarm): > > http://www.snakeorladder.com/bsd-pi-r245446.img.gz Thank you very much, Alie! > Thanks very much! I've been running this image continuously for three > and a half days. I've compiled ghostscript and cups-base (and also perl > and python). Do you by any chance have the ulpt.ko module that goes > with this kernel available? The Pi is the only place I could try > compiling it right now, and that would take quite a while, so I would be > very grateful if it's already built somewhere. > > Perhaps someone might be interested in my compiled packages? Definitely ... I'm particularly interested in the Python package. Is it available for download somewehere? By the way, does anybody know whether the Python GPIO module for the RPi works with FreeBSD/arm? I guess it doesn't ... http://pypi.python.org/pypi/RPi.GPIO Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Handelsregister: Amtsgericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsreg.: Amtsgericht München, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen/-Produkte + mehr: http://www.secnetix.de/bsd The whole world is a comedy to those that think, a tragedy to those that feel. -- Horace Walpole From owner-freebsd-arm@FreeBSD.ORG Sun Jan 27 14: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 7D38AA82 for ; Sun, 27 Jan 2013 14:03:23 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2FD06159 for ; Sun, 27 Jan 2013 14:03:22 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id l8so507780qaq.20 for ; Sun, 27 Jan 2013 06:03:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=mPAZi6h8ashZTtHDZ34bDgrwuQ3Ncy0tluLOHPiAJkg=; b=CtWxD3mQb45fblF7kGFzyF3YLtO8e5s00gXcp0cHZ9ds4wSRwHMRTR+SR0STluDkif kXs50iqIY6pHxRZQi/enuB2lj1XmOcZ9OThgaFStBCPHKGptoQY+j1arHAGPKiCrp1fh J73AeSWvwCMMV2rLYsJYUczWTDgqKIu1Y6EYc3KTJEPOdWocnbY9QOahSWWgKQE8F0bV OWfK3i0mz1IRAiQu1PxxtfdeuCn5wVgpkoexeXSocs4h7O4IqhavrTuTKHOR1fkBIQ2A b2xKS0O+rHuAPTRAhsF2zpiiQVaUgIpYwgU8ki7lb5AzaR874HtQXuuWxStcgsg0aneg WO8g== MIME-Version: 1.0 X-Received: by 10.224.185.148 with SMTP id co20mr12370118qab.94.1359294941792; Sun, 27 Jan 2013 05:55:41 -0800 (PST) Received: by 10.49.2.72 with HTTP; Sun, 27 Jan 2013 05:55:41 -0800 (PST) In-Reply-To: <201301271341.r0RDfwTp009397@grabthar.secnetix.de> References: <50FB2316.4060300@m5p.com> <201301271341.r0RDfwTp009397@grabthar.secnetix.de> Date: Sun, 27 Jan 2013 21:55:41 +0800 Message-ID: Subject: Re: FreeBSD ARM with swap partition and tmpfs From: Alie Tan To: Oliver Fromme X-Gm-Message-State: ALoCoQkZBZyzQV+ucIVcDHFM1VoKmklF2D9EmRsAukkhId0BhF2D2ocZdOCX3Pbjz9HFSALPBb4B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 14:03:23 -0000 On Sunday, January 27, 2013, Oliver Fromme wrote: > George Mitchell wrote: > > On 01/15/13 04:02, Alie Tan wrote: > > > Hi, > > > > > > I just built new 4G FreeBSD image for Raspberry Pi (username/password: > > > root/freebsdarm): > > > http://www.snakeorladder.com/bsd-pi-r245446.img.gz > > Thank you very much, Alie! > > > Thanks very much! I've been running this image continuously for three > > and a half days. I've compiled ghostscript and cups-base (and also perl > > and python). Do you by any chance have the ulpt.ko module that goes > > with this kernel available? The Pi is the only place I could try > > compiling it right now, and that would take quite a while, so I would be > > very grateful if it's already built somewhere. > > > > Perhaps someone might be interested in my compiled packages? > > Definitely ... I'm particularly interested in the Python > package. Is it available for download somewehere? Grab it here: http://people.freebsd.org/~gonzo/arm/pkg/ > > By the way, does anybody know whether the Python GPIO module > for the RPi works with FreeBSD/arm? I guess it doesn't ... > > http://pypi.python.org/pypi/RPi.GPIO > > Best regards > Oliver > > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing > Handelsregister: Amtsgericht Muenchen, HRA 74606, Gesch=E4ftsfuehrung: > secnetix Verwaltungsgesellsch. mbH, Handelsreg.: Amtsgericht M=FCnchen, > HRB 125758, Gesch=E4ftsf=FChrer: Maik Bachmann, Olaf Erb, Ralf Gebhart > > FreeBSD-Dienstleistungen/-Produkte + mehr: http://www.secnetix.de/bsd > > The whole world is a comedy to those that think, a tragedy to those that feel. > -- Horace Walpole > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Sun Jan 27 17: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 EE4A6C44 for ; Sun, 27 Jan 2013 17: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 BDAC8B52 for ; Sun, 27 Jan 2013 17:02:01 +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 r0RH205K030899 for ; Sun, 27 Jan 2013 10:02: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 r0RH1vF0019637 for ; Sun, 27 Jan 2013 10:01:57 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: DreamPlug support committed From: Ian Lepore To: freebsd-arm Content-Type: text/plain; charset="us-ascii" Date: Sun, 27 Jan 2013 10:01:57 -0700 Message-ID: <1359306117.93359.29.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port 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, 27 Jan 2013 17:02:02 -0000 FYI, I've committed the last missing bits of support for the DreamPlug, so as of r245955 it's now possible to build for dreamplug without needing any extra patches, using stock kernel config DREAMPLUG-1001. I also included the .dts file for the rare model 1001N (contains nand flash rather than nor flash). The kernel config file has a little comment block at the end that says what to change to build for the 1001N model (of which there are probably only a few dozen in the wild). As the name implies, the kernel and dts config files are for a model 1001 dreamplug, but I think the same config will work properly on an 0901 model as well, at least until we have wifi drivers for both. (As I understand it, different wifi chips are the primary difference between the 0901 and 1001 models.) There's a good chance this config would also work properly for a GuruPlug, or need only minor changes. If anyone has a GuruPlug and wants to try it, I'd be happy to work without you to figure out if there are any changes needed and get them committed too. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Jan 27 20:30:01 2013 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 510878A7 for ; Sun, 27 Jan 2013 20:30:01 +0000 (UTC) (envelope-from gnats@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 433B26A3 for ; Sun, 27 Jan 2013 20:30:01 +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 r0RKU0fY052264 for ; Sun, 27 Jan 2013 20:30:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0RKU0cb052263; Sun, 27 Jan 2013 20:30:00 GMT (envelope-from gnats) Date: Sun, 27 Jan 2013 20:30:00 GMT Message-Id: <201301272030.r0RKU0cb052263@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: arm/174461: commit references a PR X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dfilter service List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 20:30:01 -0000 The following reply was made to PR arm/174461; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: arm/174461: commit references a PR Date: Sun, 27 Jan 2013 20:28:23 +0000 (UTC) Author: ian Date: Sun Jan 27 20:28:14 2013 New Revision: 246001 URL: http://svnweb.freebsd.org/changeset/base/246001 Log: Fix off-by-one errors in low-level arm9 and arm10 cache maintenance routines. In all the routines that loop through a range of virtual addresses, the loop is controlled by subtracting the cache line size from the total length of the request. After the subtract, a 'bpl' instruction was used, which branches if the result of the subtraction is zero or greater, but we need to exit the loop when the count hits zero. Thus, all the bpl instructions in those loops have been changed to 'bhi' (branch if greater than zero). In addition, the two routines that walk through the cache using set-and-index were correct, but confusing. The loop control for those has been simplified, just so that it's easier to see by examination that the code is correct. Routines for other arm architectures and generations still have the bpl instruction, but compensate for the off-by-one situation by decrementing the count register by one before entering the loop. PR: arm/174461 Approved by: cognet (mentor) Modified: head/sys/arm/arm/cpufunc_asm_arm10.S head/sys/arm/arm/cpufunc_asm_arm9.S Modified: head/sys/arm/arm/cpufunc_asm_arm10.S ============================================================================== --- head/sys/arm/arm/cpufunc_asm_arm10.S Sun Jan 27 20:16:50 2013 (r246000) +++ head/sys/arm/arm/cpufunc_asm_arm10.S Sun Jan 27 20:28:14 2013 (r246001) @@ -87,7 +87,7 @@ ENTRY_NP(arm10_icache_sync_range) mcr p15, 0, r0, c7, c10, 1 /* Clean D cache SE with VA */ add r0, r0, ip subs r1, r1, ip - bpl .Larm10_sync_next + bhi .Larm10_sync_next mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ bx lr @@ -108,12 +108,10 @@ ENTRY_NP(arm10_icache_sync_all) orr ip, s_max, i_max .Lnext_index: mcr p15, 0, ip, c7, c10, 2 /* Clean D cache SE with Set/Index */ - sub ip, ip, i_inc - tst ip, i_max /* Index 0 is last one */ - bne .Lnext_index /* Next index */ - mcr p15, 0, ip, c7, c10, 2 /* Clean D cache SE with Set/Index */ + subs ip, ip, i_inc + bhs .Lnext_index /* Next index */ subs s_max, s_max, s_inc - bpl .Lnext_set /* Next set */ + bhs .Lnext_set /* Next set */ mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ bx lr @@ -133,7 +131,7 @@ ENTRY(arm10_dcache_wb_range) mcr p15, 0, r0, c7, c10, 1 /* Clean D cache SE with VA */ add r0, r0, ip subs r1, r1, ip - bpl .Larm10_wb_next + bhi .Larm10_wb_next mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ bx lr @@ -150,7 +148,7 @@ ENTRY(arm10_dcache_wbinv_range) mcr p15, 0, r0, c7, c14, 1 /* Purge D cache SE with VA */ add r0, r0, ip subs r1, r1, ip - bpl .Larm10_wbinv_next + bhi .Larm10_wbinv_next mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ bx lr @@ -171,7 +169,7 @@ ENTRY(arm10_dcache_inv_range) mcr p15, 0, r0, c7, c6, 1 /* Invalidate D cache SE with VA */ add r0, r0, ip subs r1, r1, ip - bpl .Larm10_inv_next + bhi .Larm10_inv_next mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ bx lr @@ -189,7 +187,7 @@ ENTRY(arm10_idcache_wbinv_range) mcr p15, 0, r0, c7, c14, 1 /* Purge D cache SE with VA */ add r0, r0, ip subs r1, r1, ip - bpl .Larm10_id_wbinv_next + bhi .Larm10_id_wbinv_next mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ bx lr @@ -211,12 +209,10 @@ ENTRY(arm10_dcache_wbinv_all) orr ip, s_max, i_max .Lnext_index_inv: mcr p15, 0, ip, c7, c14, 2 /* Purge D cache SE with Set/Index */ - sub ip, ip, i_inc - tst ip, i_max /* Index 0 is last one */ - bne .Lnext_index_inv /* Next index */ - mcr p15, 0, ip, c7, c14, 2 /* Purge D cache SE with Set/Index */ + subs ip, ip, i_inc + bhs .Lnext_index_inv /* Next index */ subs s_max, s_max, s_inc - bpl .Lnext_set_inv /* Next set */ + bhs .Lnext_set_inv /* Next set */ mcr p15, 0, r0, c7, c10, 4 /* drain the write buffer */ bx lr Modified: head/sys/arm/arm/cpufunc_asm_arm9.S ============================================================================== --- head/sys/arm/arm/cpufunc_asm_arm9.S Sun Jan 27 20:16:50 2013 (r246000) +++ head/sys/arm/arm/cpufunc_asm_arm9.S Sun Jan 27 20:28:14 2013 (r246001) @@ -81,7 +81,7 @@ ENTRY_NP(arm9_icache_sync_range) mcr p15, 0, r0, c7, c10, 1 /* Clean D cache SE with VA */ add r0, r0, ip subs r1, r1, ip - bpl .Larm9_sync_next + bhi .Larm9_sync_next mov pc, lr ENTRY_NP(arm9_icache_sync_all) @@ -101,12 +101,10 @@ ENTRY_NP(arm9_icache_sync_all) orr ip, s_max, i_max .Lnext_index: mcr p15, 0, ip, c7, c10, 2 /* Clean D cache SE with Set/Index */ - sub ip, ip, i_inc - tst ip, i_max /* Index 0 is last one */ - bne .Lnext_index /* Next index */ - mcr p15, 0, ip, c7, c10, 2 /* Clean D cache SE with Set/Index */ + subs ip, ip, i_inc + bhs .Lnext_index /* Next index */ subs s_max, s_max, s_inc - bpl .Lnext_set /* Next set */ + bhs .Lnext_set /* Next set */ mov pc, lr .Larm9_line_size: @@ -125,7 +123,7 @@ ENTRY(arm9_dcache_wb_range) mcr p15, 0, r0, c7, c10, 1 /* Clean D cache SE with VA */ add r0, r0, ip subs r1, r1, ip - bpl .Larm9_wb_next + bhi .Larm9_wb_next mov pc, lr ENTRY(arm9_dcache_wbinv_range) @@ -141,7 +139,7 @@ ENTRY(arm9_dcache_wbinv_range) mcr p15, 0, r0, c7, c14, 1 /* Purge D cache SE with VA */ add r0, r0, ip subs r1, r1, ip - bpl .Larm9_wbinv_next + bhi .Larm9_wbinv_next mov pc, lr /* @@ -161,7 +159,7 @@ ENTRY(arm9_dcache_inv_range) mcr p15, 0, r0, c7, c6, 1 /* Invalidate D cache SE with VA */ add r0, r0, ip subs r1, r1, ip - bpl .Larm9_inv_next + bhi .Larm9_inv_next mov pc, lr ENTRY(arm9_idcache_wbinv_range) @@ -178,7 +176,7 @@ ENTRY(arm9_idcache_wbinv_range) mcr p15, 0, r0, c7, c14, 1 /* Purge D cache SE with VA */ add r0, r0, ip subs r1, r1, ip - bpl .Larm9_id_wbinv_next + bhi .Larm9_id_wbinv_next mov pc, lr ENTRY_NP(arm9_idcache_wbinv_all) @@ -199,12 +197,10 @@ ENTRY(arm9_dcache_wbinv_all) orr ip, s_max, i_max .Lnext_index_inv: mcr p15, 0, ip, c7, c14, 2 /* Purge D cache SE with Set/Index */ - sub ip, ip, i_inc - tst ip, i_max /* Index 0 is last one */ - bne .Lnext_index_inv /* Next index */ - mcr p15, 0, ip, c7, c14, 2 /* Purge D cache SE with Set/Index */ + subs ip, ip, i_inc + bhs .Lnext_index_inv /* Next index */ subs s_max, s_max, s_inc - bpl .Lnext_set_inv /* Next set */ + bhs .Lnext_set_inv /* Next set */ mov pc, lr .Larm9_cache_data: _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sun Jan 27 20:36:41 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 E7B43AE3; Sun, 27 Jan 2013 20:36:41 +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 B739E6E0; Sun, 27 Jan 2013 20:36:41 +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 r0RKaeme056073; Sun, 27 Jan 2013 15:36:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r0RKaegX056069; Sun, 27 Jan 2013 20:36:40 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 27 Jan 2013 20:36:40 GMT Message-Id: <201301272036.r0RKaegX056069@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: Sun, 27 Jan 2013 20:36:42 -0000 TB --- 2013-01-27 19:40:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-27 19:40:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-27 19:40:17 - starting HEAD tinderbox run for arm/arm TB --- 2013-01-27 19:40:17 - cleaning the object tree TB --- 2013-01-27 19:41:07 - /usr/local/bin/svn stat /src TB --- 2013-01-27 19:41:11 - At svn revision 245995 TB --- 2013-01-27 19:41:12 - building world TB --- 2013-01-27 19:41:12 - CROSS_BUILD_TESTING=YES TB --- 2013-01-27 19:41:12 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-27 19:41:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-27 19:41:12 - SRCCONF=/dev/null TB --- 2013-01-27 19:41:12 - TARGET=arm TB --- 2013-01-27 19:41:12 - TARGET_ARCH=arm TB --- 2013-01-27 19:41:12 - TZ=UTC TB --- 2013-01-27 19:41:12 - __MAKE_CONF=/dev/null TB --- 2013-01-27 19:41:12 - cd /src TB --- 2013-01-27 19:41:12 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Jan 27 19:41:16 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 >>> World build completed on Sun Jan 27 20:36:39 UTC 2013 TB --- 2013-01-27 20:36:39 - generating LINT kernel config TB --- 2013-01-27 20:36:39 - cd /src/sys/arm/conf TB --- 2013-01-27 20:36:39 - /usr/bin/make -B LINT TB --- 2013-01-27 20:36:39 - cd /src/sys/arm/conf TB --- 2013-01-27 20:36:39 - /usr/sbin/config -m LINT TB --- 2013-01-27 20:36:39 - building LINT kernel TB --- 2013-01-27 20:36:39 - CROSS_BUILD_TESTING=YES TB --- 2013-01-27 20:36:39 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-27 20:36:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-27 20:36:39 - SRCCONF=/dev/null TB --- 2013-01-27 20:36:39 - TARGET=arm TB --- 2013-01-27 20:36:39 - TARGET_ARCH=arm TB --- 2013-01-27 20:36:39 - TZ=UTC TB --- 2013-01-27 20:36:39 - __MAKE_CONF=/dev/null TB --- 2013-01-27 20:36:39 - cd /src TB --- 2013-01-27 20:36:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jan 27 20:36:39 UTC 2013 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /src/sys/arm/conf; PATH=/obj/arm.arm/src/tmp/legacy/usr/sbin:/obj/arm.arm/src/tmp/legacy/usr/bin:/obj/arm.arm/src/tmp/legacy/usr/games:/obj/arm.arm/src/tmp/usr/sbin:/obj/arm.arm/src/tmp/usr/bin:/obj/arm.arm/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /obj/arm.arm/src/sys/LINT /src/sys/arm/conf/LINT WARNING: duplicate option `GEOM_PART_BSD' encountered. WARNING: duplicate option `GEOM_PART_MBR' encountered. WARNING: duplicate option `DEV_MEM' encountered. WARNING: duplicate device `mem' encountered. WARNING: duplicate option `CAM_DEBUG_DELAY' encountered. config: ../mv/kirkwood/files.sheevaplug: No such file or directory *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-27 20:36:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-27 20:36:40 - ERROR: failed to build LINT kernel TB --- 2013-01-27 20:36:40 - 2531.33 user 565.02 system 3382.85 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Mon Jan 28 03:54:57 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 7ED1F8DF for ; Mon, 28 Jan 2013 03:54:57 +0000 (UTC) (envelope-from elbarto@megadrive.org) Received: from mail.megadrive.org (elbarto.org [88.190.215.31]) by mx1.freebsd.org (Postfix) with ESMTP id CFC0C7A4 for ; Mon, 28 Jan 2013 03:54:56 +0000 (UTC) Received: from emeraldas.megadrive.org (cro34-4-82-240-120-88.fbx.proxad.net [82.240.120.88]) (Authenticated sender: elbarto) by mail.megadrive.org (Postfix) with ESMTPA id 4D2EA1A6462B for ; Mon, 28 Jan 2013 04:45:12 +0100 (CET) Date: Mon, 28 Jan 2013 04:45:11 +0100 From: Emmanuel Vadot To: freebsd-arm@freebsd.org Subject: Beaglebone and GPIO Message-Id: <20130128044511.86a3d715b11c3346884a7056@megadrive.org> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Mon__28_Jan_2013_04_45_11_+0100_WnntjMH_pxkZQ3Jw" 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, 28 Jan 2013 03:54:57 -0000 This is a multi-part message in MIME format. --Multipart=_Mon__28_Jan_2013_04_45_11_+0100_WnntjMH_pxkZQ3Jw Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello, I've filled the missings pads on am335x_scm_padconf.c so every GPIO pin is now accessible (if, of course, they are in GPIO mode). I've also corrected/enhanced an error on ti_gpio.c, in the ti_gpio_pin_get function then code was testing if the pin was in output mode and if it was return EINVAL but in fact it was returning EINVAL if the pin was in input mode. Now the function return the value of the pin despite of it's an input or output. (seems more logical to me but I'm open to discuss this). I've also patched gpioctl(1), it now test if the pin is in GPIO mode (according to the pin mux setting) and print either the value or "Not in GPIO mode". Cheers, -- Emmanuel Vadot --Multipart=_Mon__28_Jan_2013_04_45_11_+0100_WnntjMH_pxkZQ3Jw Content-Type: text/x-diff; name="am335x_scm_padconf.c.patch" Content-Disposition: attachment; filename="am335x_scm_padconf.c.patch" Content-Transfer-Encoding: 7bit Index: sys/arm/ti/am335x/am335x_scm_padconf.c =================================================================== --- sys/arm/ti/am335x/am335x_scm_padconf.c (revision 245942) +++ sys/arm/ti/am335x/am335x_scm_padconf.c (working copy) @@ -86,127 +86,117 @@ }; const struct ti_scm_padconf ti_padconf_devmap[] = { - _PIN(0x800, "GPMC_AD0", 32, 7,"gpmc_ad0", "mmc1_dat0", NULL, NULL, NULL, NULL, NULL, "gpio1_0"), - _PIN(0x804, "GPMC_AD1", 33, 7,"gpmc_ad1", "mmc1_dat1", NULL, NULL, NULL, NULL, NULL, "gpio1_1"), - _PIN(0x808, "GPMC_AD2", 34, 7,"gpmc_ad2", "mmc1_dat2", NULL, NULL, NULL, NULL, NULL, "gpio1_2"), - _PIN(0x80C, "GPMC_AD3", 35, 7,"gpmc_ad3", "mmc1_dat3", NULL, NULL, NULL, NULL, NULL, "gpio1_3"), - _PIN(0x810, "GPMC_AD4", 36, 7,"gpmc_ad4", "mmc1_dat4", NULL, NULL, NULL, NULL, NULL, "gpio1_4"), - _PIN(0x814, "GPMC_AD5", 37, 7,"gpmc_ad5", "mmc1_dat5", NULL, NULL, NULL, NULL, NULL, "gpio1_5"), - _PIN(0x818, "GPMC_AD6", 38, 7,"gpmc_ad6", "mmc1_dat6", NULL, NULL, NULL, NULL, NULL, "gpio1_6"), - _PIN(0x81C, "GPMC_AD7", 39, 7,"gpmc_ad7", "mmc1_dat7", NULL, NULL, NULL, NULL, NULL, "gpio1_7"), -#if 0 /* Incomplete Entries - fill with data from table 2-7 in datasheet */ - _PIN(0x820, "gpmc_ad8", 0, 0, "gpmc_ad8", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x824, "gpmc_ad9", 0, 0, "gpmc_ad9", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x828, "gpmc_ad10", 0, 0, "gpmc_ad10", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x82C, "gpmc_ad11", 0, 0, "gpmc_ad11", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x830, "gpmc_ad12", 0, 0, "gpmc_ad12", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x834, "gpmc_ad13", 0, 0, "gpmc_ad13", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x838, "gpmc_ad14", 0, 0, "gpmc_ad14", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x83C, "gpmc_ad15", 0, 0, "gpmc_ad15", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x840, "gpmc_a0", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x844, "gpmc_a1", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x848, "gpmc_a2", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x84C, "gpmc_a3", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x850, "gpmc_a4", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), -#endif - _PIN(0x854, "GPMC_A5", 53, 7, "gpmc_a5", "gmii2_txd0", "rgmii2_td0", "rmii2_txd0", "gpmc_a21", "pr1_mii1_rxd3", "eQEP1B_in", "gpio1_21"), - _PIN(0x858, "GPMC_A6", 54, 7, "gpmc_a6", "gmii2_txclk", "rgmii2_tclk", "mmc2_dat4", "gpmc_a22", "pr1_mii1_rxd2", "eQEP1_index", "gpio1_22"), - _PIN(0x85C, "GPMC_A7", 55, 7, "gpmc_a7", "gmii2_rxclk", "rgmii2_rclk", "mmc2_dat5", "gpmc_a23", "pr1_mii1_rxd1", "eQEP1_strobe", "gpio1_23"), - _PIN(0x860, "GPMC_A8", 56, 7, "gpmc_a8", "gmii2_rxd3", "rgmii2_rd3", "mmc2_dat6", "gpmc_a24", "pr1_mii1_rxd0", "mcasp0_aclkx", "gpio1_24"), -#if 0 - _PIN(0x864, "gpmc_a9", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x868, "gpmc_a10", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x86C, "gpmc_a11", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x870, "gpmc_wait0", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x874, "gpmc_wpn", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x878, "gpmc_be1n", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x87c, "gpmc_csn0", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x880, "gpmc_csn1", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x884, "gpmc_csn2", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x888, "gpmc_csn3", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x88c, "gpmc_clk", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x890, "gpmc_advn_ale", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x894, "gpmc_oen_ren", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x898, "gpmc_wen", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x89c, "gpmc_be0n_cle", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8a0, "lcd_data0", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8a4, "lcd_data1", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8a8, "lcd_data2", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8ac, "lcd_data3", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8b0, "lcd_data4", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8b4, "lcd_data5", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8b8, "lcd_data6", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8bc, "lcd_data7", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8c0, "lcd_data8", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8c4, "lcd_data9", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8c8, "lcd_data10", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8cc, "lcd_data11", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8d0, "lcd_data12", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8d4, "lcd_data13", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8d8, "lcd_data14", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8dc, "lcd_data15", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8e0, "lcd_vsync", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8e4, "lcd_hsync", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8e8, "lcd_pclk", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8ec, "lcd_ac_bias_en", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), -#endif - _PIN(0x8f0, "MMC0_DAT3", 90, 7, "mmc0_dat3", "gpmc_a20", "uart4_ctsn", "timer5", "uart1_dcdn", "pr1_pru0_pru_r30_8", "pr1_pru0_pru_r31_8", "gpio2_26"), - _PIN(0x8f4, "MMC0_DAT2", 91, 7, "mmc0_dat2", "gpmc_a21", "uart4_rtsn", "timer6", "uart1_dsrn", "pr1_pru0_pru_r30_9", "pr1_pru0_pru_r31_9", "gpio2_27"), - _PIN(0x8f8, "MMC0_DAT1", 92, 7, "mmc0_dat1", "gpmc_a22", "uart5_ctsn", "uart3_rxd", "uart1_dtrn", "pr1_pru0_pru_r30_10", "pr1_pru0_pru_r31_10", "gpio2_28"), - _PIN(0x8fc, "MMC0_DAT0", 93, 7, "mmc0_dat0", "gpmc_a23", "uart5_rtsn", "uart3_txd", "uart1_rin", "pr1_pru0_pru_r30_11", "pr1_pru0_pru_r31_11", "gpio2_29"), - _PIN(0x900, "MMC0_CLK", 94, 7, "mmc0_clk", "gpmc_a24", "uart3_ctsn", "uart2_rxd", "dcan1_tx", "pr1_pru0_pru_r30_12", "pr1_pru0_pru_r31_12", "gpio2_30"), - _PIN(0x904, "MMC0_CMD", 95, 7, "mmc0_cmd", "gpmc_a25", "uart3_rtsn", "uart2_txd", "dcan1_rx", "pr1_pru0_pru_r30_13", "pr1_pru0_pru_r31_13", "gpio2_31"), - _PIN(0x908, "MII1_COL", 96, 7, "gmii1_col", "rmii2_refclk", "spi1_sclk", "uart5_rxd", "mcasp1_axr2", "mmc2_dat3", "mcasp0_axr2", "gpio3_0"), - _PIN(0x90c, "MII1_CRS", 97, 7, "gmii1_crs", "rmii1_crs_dv", "spi1_d0", "I2C1_SDA", "mcasp1_aclkx", "uart5_ctsn", "uart2_rxd", "gpio3_1"), - _PIN(0x910, "MII1_RX_ER", 98, 7, "gmii1_rxerr", "rmii1_rxerr", "spi1_d1", "I2C1_SCL", "mcasp1_fsx", "uart5_rtsn", "uart2_txd", "gpio3_2"), - _PIN(0x914, "MII1_TX_EN", 99, 7, "gmii1_txen", "rmii1_txen", "rgmii1_tctl", "timer4", "mcasp1_axr0", "eQEP0_index", "mmc2_cmd", "gpio3_3"), + _PIN(0x800, "GPMC_AD0", 32, 7,"gpmc_ad0", "mmc1_dat0", NULL, NULL, NULL, NULL, NULL, "gpio1_0"), + _PIN(0x804, "GPMC_AD1", 33, 7,"gpmc_ad1", "mmc1_dat1", NULL, NULL, NULL, NULL, NULL, "gpio1_1"), + _PIN(0x808, "GPMC_AD2", 34, 7,"gpmc_ad2", "mmc1_dat2", NULL, NULL, NULL, NULL, NULL, "gpio1_2"), + _PIN(0x80C, "GPMC_AD3", 35, 7,"gpmc_ad3", "mmc1_dat3", NULL, NULL, NULL, NULL, NULL, "gpio1_3"), + _PIN(0x810, "GPMC_AD4", 36, 7,"gpmc_ad4", "mmc1_dat4", NULL, NULL, NULL, NULL, NULL, "gpio1_4"), + _PIN(0x814, "GPMC_AD5", 37, 7,"gpmc_ad5", "mmc1_dat5", NULL, NULL, NULL, NULL, NULL, "gpio1_5"), + _PIN(0x818, "GPMC_AD6", 38, 7,"gpmc_ad6", "mmc1_dat6", NULL, NULL, NULL, NULL, NULL, "gpio1_6"), + _PIN(0x81C, "GPMC_AD7", 39, 7,"gpmc_ad7", "mmc1_dat7", NULL, NULL, NULL, NULL, NULL, "gpio1_7"), + _PIN(0x820, "GPMC_AD8", 22, 7, "gpmc_ad8", "lcd_data23", "mmc1_dat0", "mmc2_dat4", "ehrpwm2A", NULL, NULL, "gpio0_22"), + _PIN(0x824, "GPMC_AD9", 23, 7, "gpmc_ad9", "lcd_data22", "mmc1_dat1", "mmc2_dat5", "ehrpwm2B", NULL, NULL, "gpio0_23"), + _PIN(0x828, "GPMC_AD10", 26, 7, "gpmc_ad10", "lcd_data21", "mmc1_dat2", "mmc2_dat6", "ehrpwm2_tripzone_in", NULL, NULL, "gpio0_26"), + _PIN(0x82C, "GPMC_AD11", 27, 7, "gpmc_ad11", "lcd_data20", "mmc1_dat3", "mmc2_dat7", "ehrpwm0_synco", NULL, NULL, "gpio0_27"), + _PIN(0x830, "GPMC_AD12", 44, 7, "gpmc_ad12", "lcd_data19", "mmc1_dat4", "mmc2_dat0", "eqep2a_in", "pr1_mii0_txd2", "pr1_pru0_pru_r30_14", "gpio1_12"), + _PIN(0x834, "GPMC_AD13", 45, 7, "gpmc_ad13", "lcd_data18", "mmc1_dat5", "mmc2_dat1", "eqep2b_in", "pr1_mii0_txd1", "pr1_pru0_pru_r30_15", "gpio1_13"), + _PIN(0x838, "GPMC_AD14", 46, 7, "gpmc_ad14", "lcd_data17", "mmc1_dat6", "mmc2_dat2", "eqep2b_index", "pr1_mii0_txd0", "pr1_pru0_pru_r31_14", "gpio1_14"), + _PIN(0x83C, "GPMC_AD15", 47, 7, "gpmc_ad15", "lcd_data16", "mmc1_dat7", "mmc2_dat3", "eqep2b_strobe", "pr1_ecap0_ecap_capin_apwm_o", "pr1_pru0_pru_r31_15", "gpio1_15"), + _PIN(0x840, "GPMC_A0", 48, 7, "gpmc_a0", "gmii2_txen", "rgmii2_tctl", "rmii2_txen", "gpmc_a16", "pr1_mii_mt1_clk", "ehrpwm1_tripzone_input", "gpio1_16"), + _PIN(0x844, "GPMC_A1", 49, 7, "gpmc_a1", "gmii2_rxdv", "rgmii2_rctl", "mmc2_dat0", "gpmc_a17", "pr1_mii1_txd3", "ehrpwm0_synco", "gpio1_17"), + _PIN(0x848, "GPMC_A2", 50, 7, "gpmc_a2", "gmii2_txd3", "rgmii2_td3", "mmc2_dat1", "gpmc_a18", "pr1_mii1_txd2", "ehrpwm1a", "gpio1_18"), + _PIN(0x84C, "GPMC_A3", 51, 7, "gpmc_a3", "gmii2_txd2", "rgmii2_td2", "mmc2_dat2", "gpmc_a19", "pr1_mii1_txd1", "ehrpwm1b", "gpio1_19"), + _PIN(0x850, "GPMC_A4", 52, 7, "gpmc_a4", "gmii2_txd1", "rgmii2_td1", "rmii2_tdx1", "gpmc_a20", "pr1_mii1_txd0", "eqep1a_in", "gpio1_20"), + _PIN(0x854, "GPMC_A5", 53, 7, "gpmc_a5", "gmii2_txd0", "rgmii2_td0", "rmii2_txd0", "gpmc_a21", "pr1_mii1_rxd3", "eQEP1B_in", "gpio1_21"), + _PIN(0x858, "GPMC_A6", 54, 7, "gpmc_a6", "gmii2_txclk", "rgmii2_tclk", "mmc2_dat4", "gpmc_a22", "pr1_mii1_rxd2", "eQEP1_index", "gpio1_22"), + _PIN(0x85C, "GPMC_A7", 55, 7, "gpmc_a7", "gmii2_rxclk", "rgmii2_rclk", "mmc2_dat5", "gpmc_a23", "pr1_mii1_rxd1", "eQEP1_strobe", "gpio1_23"), + _PIN(0x860, "GPMC_A8", 56, 7, "gpmc_a8", "gmii2_rxd3", "rgmii2_rd3", "mmc2_dat6", "gpmc_a24", "pr1_mii1_rxd0", "mcasp0_aclkx", "gpio1_24"), + _PIN(0x864, "GPMC_A9", 57, 7, "gmpc_a9", "gmii2_rxd2", "rgmii2_rd2", "mmc2_dat7 / rmii2_crs_dv", "gpmc_a25", "pr1_mii_mr1_clk", "mcasp0_fsx", "gpio1_25"), + _PIN(0x868, "GPMC_A10", 58, 7, "gmpc_a10", "gmii2_rxd1", "rgmii2_rd1", "rmii2_rxd1", "gpmc_a26", "pr1_mii1_rxdv", "mcasp0_arx0", "gpio1_26"), + _PIN(0x86C, "GPMC_A11", 59, 7, "gmpc_a11", "gmii2_rxd0", "rgmii2_rd0", "rmii2_rxd0", "gpmc_a27", "pr1_mii1_rxer", "mcasp0_axr1", "gpio1_27"), + _PIN(0x870, "GPMC_WAIT0", 30, 7, "gpmc_wait0", "gmii2_crs", "gpmc_csn4", "rmii2_crs_dv", "mmc1_sdcd", "pr1_mii1_col", "uart4_rxd", "gpio0_30"), + _PIN(0x874, "GPMC_WPn", 31, 7, "gpmc_wpn", "gmii2_rxerr", "gpmc_csn5", "rmii2_rxerr", "mmc2_sdcd", "pr1_mii1_txen", "uart4_txd", "gpio0_31"), + _PIN(0x878, "GPMC_BEn1", 60, 7, "gpmc_be1n", "gmii2_col", "gmpc_csn6","mmc2_dat3", "gpmc_dir", "pr1_mii1_rxlink", "mcasp0_aclkr", "gpio1_28"), + _PIN(0x87c, "GPMC_CSn0", 61, 7, "gpmc_csn0", NULL, NULL, NULL, NULL, NULL, NULL, "gpio1_29"), + _PIN(0x880, "GPMC_CSn1", 62, 7, "gpmc_csn1", "gpmc_clk", "mmc1_clk", "pr1_edio_data_in6", "pr1_edio_data_out6", "pr1_pru1_pru_r30_12", "pr1_pru1_pru_r31_12", "gpio1_30"), + _PIN(0x884, "GPMC_CSn2", 63, 7, "gpmc_csn2", "gpmc_be1n", "mmc1_cmd", "pr1_edio_data_in7", "pr1_edio_data_out7", "pr1_pru1_pru_r30_13", "pr1_pru1_pru_r31_13", "gpio1_31"), + _PIN(0x888, "GPMC_CSn3", 64, 7, "gpmc_csn3", "gpmc_a3", "rmii2_crs_dv", "mmc2_cmd", "pr1_mii0_crs", "pr1_mdio_data", "emu4", "gpio2_0"), + _PIN(0x88c, "GPMC_CLK", 65, 7, "gpmc_clk", "lcd_memory_clk", "gpmc_wait1", "mmc2_clk", "pr1_mii1_crs", "pr1_mdio_mdclk", "mcasp0_fsr", "gpio2_1"), + _PIN(0x890, "GPMC_ADVn_ALE", 66, 7, "gpmc_advn_ale", NULL, "timer4", NULL, NULL, NULL, NULL, "gpio2_2"), + _PIN(0x894, "GPMC_OEn_REn", 67, 7, "gpmc_oen_ren", NULL, "timer7", NULL, NULL, NULL, NULL, "gpio2_3"), + _PIN(0x898, "GPMC_WEn", 68, 7, "gpmc_wen", NULL, "timer6", NULL, NULL, NULL, NULL, "gpio2_4"), + _PIN(0x89c, "GPMC_BEn0_CLE", 67, 7, "gpmc_ben0_cle", NULL, "timer5", NULL, NULL, NULL, NULL, "gpio2_5"), + _PIN(0x8a0, "LCD_DATA0", 68, 7, "lcd_data0", "gpmc_a0", "pr1_mii_mt0_clk", "ehrpwm2a", NULL, "pr1_pru1_pru_r30_0", "pr1_pru1_pru_r31_0", "gpio2_6"), + _PIN(0x8a4, "LCD_DATA1", 69, 7, "lcd_data1", "gpmc_a1", "pr1_mii0_txen", "ehrpwm2b", NULL, "pr1_pru1_pru_r30_1", "pr1_pru1_pru_r31_1", "gpio2_7"), + _PIN(0x8a8, "LCD_DATA2", 70, 7, "lcd_data2", "gpmc_a2", "pr1_mii0_txd3", "ehrpwm2_tripzone_input", NULL, "pr1_pru1_pru_r30_2", "pr1_pru1_pru_r31_2", "gpio2_8"), + _PIN(0x8ac, "LCD_DATA3", 71, 7, "lcd_data3", "gpmc_a3", "pr1_mii0_txd2", "ehrpwm0_synco", NULL, "pr1_pru1_pru_r30_3", "pr1_pru1_pru_r31_3", "gpio2_9"), + _PIN(0x8b0, "LCD_DATA4", 72, 7, "lcd_data4", "gpmc_a4", "pr1_mii0_txd1", "eqep2a_in", NULL, "pr1_pru1_pru_r30_4", "pr1_pru1_pru_r31_4", "gpio2_10"), + _PIN(0x8b4, "LCD_DATA5", 73, 7, "lcd_data5", "gpmc_a5", "pr1_mii0_txd0", "eqep2b_in", NULL, "pr1_pru1_pru_r30_5", "pr1_pru1_pru_r31_5", "gpio2_11"), + _PIN(0x8b8, "LCD_DATA6", 74, 7, "lcd_data6", "gpmc_a6", "pr1_edio_data_in6", "eqep2_index", "pr1_edio_data_out6", "pr1_pru1_pru_r30_6", "pr1_pru1_pru_r31_6", "gpio2_12"), + _PIN(0x8bc, "LCD_DATA7", 75, 7, "lcd_data7", "gpmc_a7", "pr1_edio_data_in7", "eqep2_strobe", "pr1_edio_data_out7", "pr1_pru1_pru_r30_7", "pr1_pru1_pru_r31_7", "gpio2_13"), + _PIN(0x8c0, "LCD_DATA8", 76, 7, "lcd_data8", "gpmc_a12", "ehrpwm1_tripzone_input", "mcasp0_aclkx", "uart5_txd", "pr1_mii0_rxd3", "uart2_ctsn", "gpio2_14"), + _PIN(0x8c4, "LCD_DATA9", 76, 7, "lcd_data9", "gpmc_a13", "ehrpwm0_synco", "mcasp0_fsx", "uart5_rxd", "pr1_mii0_rxd2", "uart2_rtsn", "gpio2_15"), + _PIN(0x8c8, "LCD_DATA10", 77, 7, "lcd_data10", "gpmc_a14", "ehrpwm1a", "mcasp0_axr0", NULL, "pr1_mii0_rxd1", "uart3_ctsn", "gpio2_16"), + _PIN(0x8cc, "LCD_DATA11", 78, 7, "lcd_data11", "gpmc_a15", "ehrpwm1b", "mcasp0_ahclkr", "mcasp0_axr2", "pr1_mii0_rxd0", "uart3_rtsn", "gpio2_17"), + _PIN(0x8d0, "LCD_DATA12", 8, 7, "lcd_data12", "gpmc_a16", "eqep1a_in", "mcasp0_aclkr", "mcasp0_axr2", "pr1_mii0_rxlink", "uart4_ctsn", "gpio0_8"), + _PIN(0x8d4, "LCD_DATA13", 9, 7, "lcd_data13", "gpmc_a17", "eqep1b_in", "mcasp0_fsr", "mcasp0_axr3", "pr1_mii0_rxer", "uart4_rtsn", "gpio0_9"), + _PIN(0x8d8, "LCD_DATA14", 10, 7, "lcd_data14", "gpmc_a18", "eqep1_index", "mcasp0_axr1", "uart5_rxd", "pr1_mii_mr0_clk", "uart5_ctsn", "gpio0_10"), + _PIN(0x8dc, "LCD_DATA15", 11, 7, "lcd_data15", "gpmc_a19", "eqep1_strobe", "mcasp0_ahclkx", "mcasp0_axr3", "pr1_mii0_rxdv", "uart5_rtsn", "gpio0_11"), + _PIN(0x8e0, "LCD_VSYNC", 86, 7, "lcd_vsync", "gpmc_a8", "gpmc_a1", "pr1_edio_data_in2", "pr1_edio_data_out2", "pr1_pru1_pru_r30_8", "pr1_pru1_pru_r31_8", "gpio2_22"), + _PIN(0x8e4, "LCD_HSYNC", 87, 7, "lcd_hsync", "gmpc_a9", "gpmc_a2", "pr1_edio_data_in3", "pr1_edio_data_out3", "pr1_pru1_pru_r30_9", "pr1_pru1_pru_r31_9", "gpio2_23"), + _PIN(0x8e8, "LCD_PCLK", 88, 7, "lcd_pclk", "gpmc_a10", "pr1_mii0_crs", "pr1_edio_data_in4", "pr1_edio_data_out4", "pr1_pru1_pru_r30_10", "pr1_pru1_pru_r31_10", "gpio2_24"), + _PIN(0x8ec, "LCD_AC_BIAS_EN", 89, 7, "lcd_ac_bias_en", "gpmc_a11", "pr1_mii1_crs", "pr1_edio_data_in5", "pr1_edio_data_out5", "pr1_pru1_pru_r30_11", "pr1_pru1_pru_r31_11", "gpio2_25"), + _PIN(0x8f0, "MMC0_DAT3", 90, 7, "mmc0_dat3", "gpmc_a20", "uart4_ctsn", "timer5", "uart1_dcdn", "pr1_pru0_pru_r30_8", "pr1_pru0_pru_r31_8", "gpio2_26"), + _PIN(0x8f4, "MMC0_DAT2", 91, 7, "mmc0_dat2", "gpmc_a21", "uart4_rtsn", "timer6", "uart1_dsrn", "pr1_pru0_pru_r30_9", "pr1_pru0_pru_r31_9", "gpio2_27"), + _PIN(0x8f8, "MMC0_DAT1", 92, 7, "mmc0_dat1", "gpmc_a22", "uart5_ctsn", "uart3_rxd", "uart1_dtrn", "pr1_pru0_pru_r30_10", "pr1_pru0_pru_r31_10", "gpio2_28"), + _PIN(0x8fc, "MMC0_DAT0", 93, 7, "mmc0_dat0", "gpmc_a23", "uart5_rtsn", "uart3_txd", "uart1_rin", "pr1_pru0_pru_r30_11", "pr1_pru0_pru_r31_11", "gpio2_29"), + _PIN(0x900, "MMC0_CLK", 94, 7, "mmc0_clk", "gpmc_a24", "uart3_ctsn", "uart2_rxd", "dcan1_tx", "pr1_pru0_pru_r30_12", "pr1_pru0_pru_r31_12", "gpio2_30"), + _PIN(0x904, "MMC0_CMD", 95, 7, "mmc0_cmd", "gpmc_a25", "uart3_rtsn", "uart2_txd", "dcan1_rx", "pr1_pru0_pru_r30_13", "pr1_pru0_pru_r31_13", "gpio2_31"), + _PIN(0x908, "MII1_COL", 96, 7, "gmii1_col", "rmii2_refclk", "spi1_sclk", "uart5_rxd", "mcasp1_axr2", "mmc2_dat3", "mcasp0_axr2", "gpio3_0"), + _PIN(0x90c, "MII1_CRS", 97, 7, "gmii1_crs", "rmii1_crs_dv", "spi1_d0", "I2C1_SDA", "mcasp1_aclkx", "uart5_ctsn", "uart2_rxd", "gpio3_1"), + _PIN(0x910, "MII1_RX_ER", 98, 7, "gmii1_rxerr", "rmii1_rxerr", "spi1_d1", "I2C1_SCL", "mcasp1_fsx", "uart5_rtsn", "uart2_txd", "gpio3_2"), + _PIN(0x914, "MII1_TX_EN", 99, 7, "gmii1_txen", "rmii1_txen", "rgmii1_tctl", "timer4", "mcasp1_axr0", "eQEP0_index", "mmc2_cmd", "gpio3_3"), _PIN(0x918, "MII1_RX_DV", 100, 7, "gmii1_rxdv", "cd_memory_clk", "rgmii1_rctl", "uart5_txd", "mcasp1_aclkx", "mmc2_dat0", "mcasp0_aclkr", "gpio3_4"), - _PIN(0x91c, "MII1_TXD3", 16, 7, "gmii1_txd3", "dcan0_tx", "rgmii1_td3", "uart4_rxd", "mcasp1_fsx", "mmc2_dat1", "mcasp0_fsr", "gpio0_16"), - _PIN(0x920, "MII1_TXD2", 17, 7, "gmii1_txd2", "dcan0_rx", "rgmii1_td2", "uart4_txd", "mcasp1_axr0", "mmc2_dat2", "mcasp0_ahclkx", "gpio0_17"), - _PIN(0x924, "MII1_TXD1", 21, 7, "gmii1_txd1", "rmii1_txd1", "rgmii1_td1", "mcasp1_fsr", "mcasp1_axr1", "eQEP0A_in", "mmc1_cmd", "gpio0_21"), - _PIN(0x928, "MII1_TXD0", 28, 7, "gmii1_txd0", "rmii1_txd0", "rgmii1_td0", "mcasp1_axr2", "mcasp1_aclkr", "eQEP0B_in", "mmc1_clk", "gpio0_28"), + _PIN(0x91c, "MII1_TXD3", 16, 7, "gmii1_txd3", "dcan0_tx", "rgmii1_td3", "uart4_rxd", "mcasp1_fsx", "mmc2_dat1", "mcasp0_fsr", "gpio0_16"), + _PIN(0x920, "MII1_TXD2", 17, 7, "gmii1_txd2", "dcan0_rx", "rgmii1_td2", "uart4_txd", "mcasp1_axr0", "mmc2_dat2", "mcasp0_ahclkx", "gpio0_17"), + _PIN(0x924, "MII1_TXD1", 21, 7, "gmii1_txd1", "rmii1_txd1", "rgmii1_td1", "mcasp1_fsr", "mcasp1_axr1", "eQEP0A_in", "mmc1_cmd", "gpio0_21"), + _PIN(0x928, "MII1_TXD0", 28, 7, "gmii1_txd0", "rmii1_txd0", "rgmii1_td0", "mcasp1_axr2", "mcasp1_aclkr", "eQEP0B_in", "mmc1_clk", "gpio0_28"), _PIN(0x92c, "MII1_TX_CLK", 105, 7, "gmii1_txclk", "uart2_rxd", "rgmii1_tclk", "mmc0_dat7", "mmc1_dat0", "uart1_dcdn", "mcasp0_aclkx", "gpio3_9"), _PIN(0x930, "MII1_RX_CLK", 106, 7, "gmii1_rxclk", "uart2_txd", "rgmii1_rclk", "mmc0_dat6", "mmc1_dat1", "uart1_dsrn", "mcasp0_fsx", "gpio3_10"), - _PIN(0x934, "MII1_RXD3", 82, 7, "gmii1_rxd3", "uart3_rxd", "rgmii1_rd3", "mmc0_dat5", "mmc1_dat2", "uart1_dtrn", "mcasp0_axr0", "gpio2_18"), - _PIN(0x938, "MII1_RXD2", 83, 7, "gmii1_rxd2", "uart3_txd", "rgmii1_rd2", "mmc0_dat4", "mmc1_dat3", "uart1_rin", "mcasp0_axr1", "gpio2_19"), - _PIN(0x93c, "MII1_RXD1", 84, 7, "gmii1_rxd1", "rmii1_rxd1", "rgmii1_rd1", "mcasp1_axr3", "mcasp1_fsr", "eQEP0_strobe", "mmc2_clk", "gpio2_20"), - _PIN(0x940, "MII1_RXD0", 85, 7, "gmii1_rxd0", "rmii1_rxd0", "rgmii1_rd0", "mcasp1_ahclkx", "mcasp1_ahclkr", "mcasp1_aclkr", "mcasp0_axr3", "gpio2_21"), - _PIN(0x944, "RMII1_REF_CLK", 29, 7, "rmii1_refclk", "xdma_event_intr2", "spi1_cs0", "uart5_txd", "mcasp1_axr3", "mmc0_pow", "mcasp1_ahclkx", "gpio0_29"), - _PIN(0x948, "MDIO", 0, 7, "mdio_data", "timer6", "uart5_rxd", "uart3_ctsn", "mmc0_sdcd","mmc1_cmd", "mmc2_cmd","gpio0_0"), - _PIN(0x94c, "MDC", 1, 7, "mdio_clk", "timer5", "uart5_txd", "uart3_rtsn", "mmc0_sdwp", "mmc1_clk", "mmc2_clk", "gpio0_1"), -#if 0 /* Incomplete Entries - fill with data from table 2-7 in datasheet */ - _PIN(0x950, "spi0_sclk", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x954, "spi0_d0", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), -#endif - _PIN(0x958, "spi0_d1", 4, 7, "spi0_d1", "mmc1_sdwp", "I2C1_SDA", "ehrpwm0_tripzone_input", "pr1_uart0_rxd", "pr1_edio_data_in0", "pr1_edio_data_out0", "gpio0_4"), - _PIN(0x95c, "spi0_cs0", 5, 7, "spi0_cs0", "mmc2_sdwp", "I2C1_SCL", "ehrpwm0_synci", "pr1_uart0_txd", "pr1_edio_data_in1", "pr1_edio_data_out1", "gpio0_5"), + _PIN(0x934, "MII1_RXD3", 82, 7, "gmii1_rxd3", "uart3_rxd", "rgmii1_rd3", "mmc0_dat5", "mmc1_dat2", "uart1_dtrn", "mcasp0_axr0", "gpio2_18"), + _PIN(0x938, "MII1_RXD2", 83, 7, "gmii1_rxd2", "uart3_txd", "rgmii1_rd2", "mmc0_dat4", "mmc1_dat3", "uart1_rin", "mcasp0_axr1", "gpio2_19"), + _PIN(0x93c, "MII1_RXD1", 84, 7, "gmii1_rxd1", "rmii1_rxd1", "rgmii1_rd1", "mcasp1_axr3", "mcasp1_fsr", "eQEP0_strobe", "mmc2_clk", "gpio2_20"), + _PIN(0x940, "MII1_RXD0", 85, 7, "gmii1_rxd0", "rmii1_rxd0", "rgmii1_rd0", "mcasp1_ahclkx", "mcasp1_ahclkr", "mcasp1_aclkr", "mcasp0_axr3", "gpio2_21"), + _PIN(0x944, "RMII1_REF_CLK", 29, 7, "rmii1_refclk", "xdma_event_intr2", "spi1_cs0", "uart5_txd", "mcasp1_axr3", "mmc0_pow", "mcasp1_ahclkx", "gpio0_29"), + _PIN(0x948, "MDIO", 0, 7, "mdio_data", "timer6", "uart5_rxd", "uart3_ctsn", "mmc0_sdcd","mmc1_cmd", "mmc2_cmd","gpio0_0"), + _PIN(0x94c, "MDC", 1, 7, "mdio_clk", "timer5", "uart5_txd", "uart3_rtsn", "mmc0_sdwp", "mmc1_clk", "mmc2_clk", "gpio0_1"), + _PIN(0x950, "SPI0_SCLK", 2, 7, "spi0_sclk", "uart2_rxd", "i2c2_sda", "ehrpwm0a", "pr1_uart0_cts_n", "pr1_edio_sof", "emu2", "gpio0_2"), + _PIN(0x954, "SPI0_D0", 3, 7, "spi0_d0", "uart2_txd", "i2c2_scl", "ehrpwm0b", "pr1_uart0_rts_n", "pr1_edio_latch_in", "emu3", "gpio0_3"), + _PIN(0x958, "SPIO_D1", 4, 7, "spi0_d1", "mmc1_sdwp", "I2C1_SDA", "ehrpwm0_tripzone_input", "pr1_uart0_rxd", "pr1_edio_data_in0", "pr1_edio_data_out0", "gpio0_4"), + _PIN(0x95c, "SPI0_CS0", 5, 7, "spi0_cs0", "mmc2_sdwp", "I2C1_SCL", "ehrpwm0_synci", "pr1_uart0_txd", "pr1_edio_data_in1", "pr1_edio_data_out1", "gpio0_5"), + _PIN(0x960, "SPI0_CS1", 6, 7, "spi0_cs1", "uart3_rxd", "ecap1_in_pwm1_out", "mcc0_pow", "xdm_event_intr2", "mmc0_sdcd", "emu4", "gpio0_6"), + _PIN(0x964, "ECAP0_IN_PWM0_OUT",7, 7, "ecap0_in_pwm0_out", "uart3_txd", "spi1_cs1", "pr1_ecap0_ecap_capin_apwm_o", "spi1_sclk", "mmc0_sdwp", "xdma_event_intr2", "gpio0_7"), + _PIN(0x968, "UART0_CTSn", 40, 7, "uart0_ctsn", "uart4_rxd", "dcan1_tx", "i2c1_sda", "spi1_d0", "timer7", "pr1_edc_sync0_out", "gpio1_8"), + _PIN(0x96c, "UART0_RTSn", 41, 7, "uart0_rtsn", "uart4_txd", "dcan1_rx", "i2c1_scl", "spi1_d1", "spi1_cs0", "pr1_edc_sync1_out", "gpio1_9"), + _PIN(0x970, "UART0_rxd", 42, 7, "uart0_rxd", "spi1_cs0", "dcan0_tx", "i2c2_sda", "ecap2_in_pwm2_out", "pr1_pru1_pru_r30_14", "pr1_pru1_pru_r31_14", "gpio1_10"), + _PIN(0x974, "UART0_txd", 43, 7, "uart0_txd", "spi1_cs1", "dcan0_rx", "i2c2_scl", "ecap1_in_pwm1_out", "pr1_pru1_pru_r30_15", "pr1_pru1_pru_r31_15", "gpio1_11"), + _PIN(0x978, "UART1_CTSn", 12, 7, "uart1_ctsn", "timer6_mux1", "dcan0_tx", "I2C2_SDA", "spi1_cs0", "pr1_uart0_cts_n", "pr1_edc_latch0_in", "gpio0_12"), + _PIN(0x97c, "UART1_RTSn", 13, 7, "uart1_rtsn", "timer5_mux1", "dcan0_rx", "I2C2_SCL", "spi1_cs1", "pr1_uart0_rts_n ", "pr1_edc_latch1_in", "gpio0_13"), + _PIN(0x980, "UART1_RXD", 14, 7, "uart1_rxd", "mmc1_sdwp", "dcan1_tx", "i2c1_sda", NULL, "pr1_uart0_rxd", "pr1_pru1_pru_r31_16", "gpio0_14"), + _PIN(0x984, "UART1_TXD", 15, 7, "uart1_txd", "mmc2_sdwp", "dcan1_rx", "i2c1_scl", NULL, "pr1_uart0_txd", "pr1_pru0_pru_r31_16", "gpio0_15"), + _PIN(0x988, "I2C0_SDA", 101, 7, "i2c0_sda", "timer4", "uart2_ctsn", "eCAP2_in_pwm2_out", NULL, NULL, NULL, "gpio3_5"), + _PIN(0x98c, "I2C0_SCL", 102, 7, "i2c0_scl", "timer7", "uart2_rtsn", "eCAP1_in_pwm1_out", NULL, NULL, NULL, "gpio3_6"), + _PIN(0x990, "MCASP0_ACLKX", 110, 7, "mcasp0_aclkx", "ehrpwm0a", NULL, "spi1_sclk", "mmc0_sdcd", "pr1_pru0_pru_r30_0", "pr1_pru0_pru_r31_0", "gpio3_14"), + _PIN(0x994, "MCASP0_FSX", 111, 7, "mcasp0_fsx", "ehrpwm0b", NULL, "spi1_d0", "mmc1_sdcd", "pr1_pru0_pru_r30_1", "pr1_pru0_pru_r31_1", "gpio3_15"), + _PIN(0x998, "MCASP0_AXR0", 112, 7, "mcasp0_axr0", "ehrpwm0_tripzone_input", NULL, "spi1_d1", "mmc2_sdcd", "pr1_pru0_pru_r30_2", "pr1_pru0_pru_r31_2", "gpio3_16"), + _PIN(0x99c, "MCASP0_AHCLKR", 113, 7, "mcasp0_ahclkr", "ehrpwm0_synci", "mcasp0_axr2", "spi1_cs0", "ecap2_in_pwm2_out", "pr1_pru0_pru_r30_3", "pr1_pru0_pru_r31_3", "gpio3_17"), + _PIN(0x9a0, "MCASP0_ACLKR", 114, 7, "mcasp0_aclkr", "eqep0a_in", "mcasp0_axr2", "mcasp1_aclkx", "mmc0_sdwp", "pr1_pru0_pru_r30_4", "pr1_pru0_pru_r31_4", "gpio3_18"), + _PIN(0x9a4, "MCASP0_FSR", 115, 7, "mcasp0_fsr", "eqep0b_in", "mcasp0_axr3", "mcasp1_fsx", "emu2", "pr1_pru0_pru_r30_5", "pr1_pru0_pru_r31_5", "gpio3_19"), + _PIN(0x9a8, "MCASP0_AXR1", 116, 7, "mcasp0_axr1", "eqep0_index", NULL, "mcasp1_axr0", "emu3", "pr1_pru0_pru_r30_6", "pr1_pru0_pru_r31_6", "gpio3_20"), + _PIN(0x9ac, "MCASP0_AHCLKX", 117, 7, "mcasp0_ahclkx", "eqep0_strobe", "mcasp0_axr3", "mcasp1_axr1", "emu4", "pr1_pru0_pru_r30_7", "pr1_pru0_pru_r31_7", "gpio3_21"), + _PIN(0x9b0, "XDMA_EVENT_INTR0", 19, 7, "xdma_event_intr0", NULL, "timer4", "clkout1", "spi1_cs1", "pr1_pru1_pru_r31_16", "emu2", "gpio0_19"), + _PIN(0x9b4, "XDMA_EVENT_INTR1", 20, 7, "xdma_event_intr1", NULL, "tclkin", "clkout2", "timer7", "pr1_pru0_pru_r31_16", "emu3", "gpio0_20"), #if 0 - _PIN(0x960, "spi0_cs1", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x964, "ecap0_in_pwm0_out",0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x968, "uart0_ctsn", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x96c, "uart0_rtsn", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x970, "uart0_rxd", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x974, "uart0_txd", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), -#endif - _PIN(0x978, "uart1_ctsn", 12, 7, "uart1_ctsn", "timer6_mux1", "dcan0_tx", "I2C2_SDA", "spi1_cs0", "pr1_uart0_cts_n", "pr1_edc_latch0_in", "gpio0_12"), - _PIN(0x97c, "uart1_rtsn", 13, 7, "uart1_rtsn", "timer5_mux1", "dcan0_rx", "I2C2_SCL", "spi1_cs1", "pr1_uart0_rts_n ", "pr1_edc_latch1_in", "gpio0_13"), -#if 0 - _PIN(0x980, "uart1_rxd", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x984, "uart1_txd", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), -#endif - _PIN(0x988, "I2C0_SDA", 101, 7, "I2C0_SDA", "timer4", "uart2_ctsn", "eCAP2_in_PWM2_out", NULL, NULL, NULL, "gpio3_5"), - _PIN(0x98c, "I2C0_SCL", 102, 7, "I2C0_SCL", "timer7", "uart2_rtsn", "eCAP1_in_PWM1_out", NULL, NULL, NULL, "gpio3_6"), -#if 0 - _PIN(0x990, "mcasp0_aclkx", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x994, "mcasp0_fsx", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x998, "mcasp0_axr0", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x99c, "mcasp0_ahclkr", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x9a0, "mcasp0_aclkr", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x9a4, "mcasp0_fsr", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x9a8, "mcasp0_axr1", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x9ac, "mcasp0_ahclkx", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x9b0, "xdma_event_intr0", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x9b4, "xdma_event_intr1", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), _PIN(0x9b8, "nresetin_out", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), _PIN(0x9bc, "porz", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), _PIN(0x9c0, "nnmi", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), @@ -218,8 +208,10 @@ _PIN(0x9d8, "tdo", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), _PIN(0x9dc, "tck", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), _PIN(0x9e0, "ntrst", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x9e4, "emu0", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x9e8, "emu1", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), +#endif + _PIN(0x9e4, "EMU0", 103, 7, "emu0", NULL, NULL, NULL, NULL, NULL, NULL, "gpio3_7"), + _PIN(0x9e8, "EMU1", 104, 0, "emu1", NULL, NULL, NULL, NULL, NULL, NULL, "gpio3_8"), +#if 0 _PIN(0x9ec, "osc1_in", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), _PIN(0x9f0, "osc1_out", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), _PIN(0x9f4, "osc1_vss", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), @@ -228,17 +220,17 @@ _PIN(0xa00, "ext_wakeup", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), _PIN(0xa04, "enz_kaldo_1p8v", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), #endif - _PIN(0xa08, "USB0_DM", 0, 0, "USB0_DM", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0xa0c, "USB0_DP", 0, 0, "USB0_DP", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0xa10, "USB0_CE", 0, 0, "USB0_CE", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0xa14, "USB0_ID", 0, 0, "USB0_ID", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0xa18, "USB0_VBUS", 0, 0, "USB0_VBUS", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0xa1c, "USB0_DRVVBUS", 18, 7, "USB0_DRVVBUS", NULL, NULL, NULL, NULL, NULL, NULL, "gpio0_18"), - _PIN(0xa20, "USB1_DM", 0, 0, "USB1_DM", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0xa24, "USB1_DP", 0, 0, "USB1_DP", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0xa28, "USB1_CE", 0, 0, "USB1_CE", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0xa2c, "USB1_ID", 0, 0, "USB1_ID", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0xa30, "USB1_VBUS", 0, 0, "USB1_VBUS", NULL, NULL, NULL, NULL, NULL, NULL, NULL), + _PIN(0xa08, "USB0_DM", 0, 0, "USB0_DM", NULL, NULL, NULL, NULL, NULL, NULL, NULL), + _PIN(0xa0c, "USB0_DP", 0, 0, "USB0_DP", NULL, NULL, NULL, NULL, NULL, NULL, NULL), + _PIN(0xa10, "USB0_CE", 0, 0, "USB0_CE", NULL, NULL, NULL, NULL, NULL, NULL, NULL), + _PIN(0xa14, "USB0_ID", 0, 0, "USB0_ID", NULL, NULL, NULL, NULL, NULL, NULL, NULL), + _PIN(0xa18, "USB0_VBUS", 0, 0, "USB0_VBUS", NULL, NULL, NULL, NULL, NULL, NULL, NULL), + _PIN(0xa1c, "USB0_DRVVBUS", 18, 7, "USB0_DRVVBUS", NULL, NULL, NULL, NULL, NULL, NULL, "gpio0_18"), + _PIN(0xa20, "USB1_DM", 0, 0, "USB1_DM", NULL, NULL, NULL, NULL, NULL, NULL, NULL), + _PIN(0xa24, "USB1_DP", 0, 0, "USB1_DP", NULL, NULL, NULL, NULL, NULL, NULL, NULL), + _PIN(0xa28, "USB1_CE", 0, 0, "USB1_CE", NULL, NULL, NULL, NULL, NULL, NULL, NULL), + _PIN(0xa2c, "USB1_ID", 0, 0, "USB1_ID", NULL, NULL, NULL, NULL, NULL, NULL, NULL), + _PIN(0xa30, "USB1_VBUS", 0, 0, "USB1_VBUS", NULL, NULL, NULL, NULL, NULL, NULL, NULL), _PIN(0xa34, "USB1_DRVVBUS", 109, 7, "USB1_DRVVBUS", NULL, NULL, NULL, NULL, NULL, NULL, "gpio3_13"), #if 0 _PIN(0xa38, "ddr_resetn", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), --Multipart=_Mon__28_Jan_2013_04_45_11_+0100_WnntjMH_pxkZQ3Jw Content-Type: text/x-diff; name="gpio.patch" Content-Disposition: attachment; filename="gpio.patch" Content-Transfer-Encoding: 7bit Index: sys/arm/ti/ti_gpio.c =================================================================== --- sys/arm/ti/ti_gpio.c (revision 245942) +++ sys/arm/ti/ti_gpio.c (working copy) @@ -513,9 +513,6 @@ * @pin: the number of the pin * @value: pointer to a value that upond return will contain the pin value * - * The pin must be configured as an input pin beforehand, otherwise this - * function will fail. - * * LOCKING: * Internally locks the context * @@ -541,13 +538,12 @@ /* Sanity check the pin is not configured as an output */ val = ti_gpio_read_4(sc, bank, TI_GPIO_OE); - if ((val & mask) == mask) { - TI_GPIO_UNLOCK(sc); - return (EINVAL); - } + if ((val & mask) == mask) + *value = (ti_gpio_read_4(sc, bank, TI_GPIO_DATAIN) & mask) ? 1 : 0; + else + *value = (ti_gpio_read_4(sc, bank, TI_GPIO_DATAOUT) & mask) ? 1 : 0; /* Read the value on the pin */ - *value = (ti_gpio_read_4(sc, bank, TI_GPIO_DATAIN) & mask) ? 1 : 0; TI_GPIO_UNLOCK(sc); Index: usr.sbin/gpioctl/gpioctl.c =================================================================== --- usr.sbin/gpioctl/gpioctl.c (revision 245942) +++ usr.sbin/gpioctl/gpioctl.c (working copy) @@ -148,22 +148,26 @@ /* For some reason this pin is inaccessible */ continue; - req.gp_pin = i; - if (ioctl(fd, GPIOGET, &req) < 0) { - /* Now, that's wrong */ - perror("ioctl(GPIOGET)"); - exit(1); + printf("pin %02d:\t", pin.gp_pin); + if (pin.gp_flags != 0) { + /* Pin is in GPIO mode */ + req.gp_pin = i; + if (ioctl(fd, GPIOGET, &req) < 0) { + /* Now, that's wrong */ + perror("ioctl(GPIOGET)"); + exit(1); + } + printf("%d\t%s", req.gp_value, pin.gp_name); + print_caps(pin.gp_flags); + + if (verbose) { + printf(", caps:"); + print_caps(pin.gp_caps); + } } + else + printf("\tNot in GPIO mode"); - printf("pin %02d:\t%d\t%s", pin.gp_pin, req.gp_value, - pin.gp_name); - - print_caps(pin.gp_flags); - - if (verbose) { - printf(", caps:"); - print_caps(pin.gp_caps); - } printf("\n"); } } --Multipart=_Mon__28_Jan_2013_04_45_11_+0100_WnntjMH_pxkZQ3Jw-- From owner-freebsd-arm@FreeBSD.ORG Mon Jan 28 05:34:40 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7EC32589 for ; Mon, 28 Jan 2013 05:34:40 +0000 (UTC) (envelope-from elbarto@megadrive.org) Received: from mail.megadrive.org (elbarto.org [88.190.215.31]) by mx1.freebsd.org (Postfix) with ESMTP id A743CA22 for ; Mon, 28 Jan 2013 05:34:38 +0000 (UTC) Received: from emeraldas.megadrive.org (cro34-4-82-240-120-88.fbx.proxad.net [82.240.120.88]) (Authenticated sender: elbarto) by mail.megadrive.org (Postfix) with ESMTPA id 6A2F41A6462B for ; Mon, 28 Jan 2013 06:34:37 +0100 (CET) Date: Mon, 28 Jan 2013 06:34:36 +0100 From: Emmanuel Vadot To: freebsd-arm@freebsd.org Subject: Re: Beaglebone and GPIO Message-Id: <20130128063436.707fb62d79767d2d8ce0542a@megadrive.org> In-Reply-To: <20130128044511.86a3d715b11c3346884a7056@megadrive.org> References: <20130128044511.86a3d715b11c3346884a7056@megadrive.org> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Mon__28_Jan_2013_06_34_36_+0100_rO6BRDMkQZyt4x0Q" 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, 28 Jan 2013 05:34:40 -0000 This is a multi-part message in MIME format. --Multipart=_Mon__28_Jan_2013_06_34_36_+0100_rO6BRDMkQZyt4x0Q Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 28 Jan 2013 04:45:11 +0100 Emmanuel Vadot wrote: > > Hello, > > I've filled the missings pads on am335x_scm_padconf.c so every GPIO pin is now accessible (if, of course, they are in GPIO mode). > > I've also corrected/enhanced an error on ti_gpio.c, in the ti_gpio_pin_get function then code was testing if the pin was in output mode and if it was return EINVAL but in fact it was returning EINVAL if the pin was in input mode. > Now the function return the value of the pin despite of it's an input or output. (seems more logical to me but I'm open to discuss this). > > I've also patched gpioctl(1), it now test if the pin is in GPIO mode (according to the pin mux setting) and print either the value or "Not in GPIO mode". > > Cheers, Attached is the coorect patch with the correct case for some signals names. -- Emmanuel Vadot --Multipart=_Mon__28_Jan_2013_06_34_36_+0100_rO6BRDMkQZyt4x0Q Content-Type: text/x-diff; name="am335x_scm_padconf.c.patch" Content-Disposition: attachment; filename="am335x_scm_padconf.c.patch" Content-Transfer-Encoding: 7bit Index: sys/arm/ti/am335x/am335x_scm_padconf.c =================================================================== --- sys/arm/ti/am335x/am335x_scm_padconf.c (revision 245942) +++ sys/arm/ti/am335x/am335x_scm_padconf.c (working copy) @@ -86,127 +86,117 @@ }; const struct ti_scm_padconf ti_padconf_devmap[] = { - _PIN(0x800, "GPMC_AD0", 32, 7,"gpmc_ad0", "mmc1_dat0", NULL, NULL, NULL, NULL, NULL, "gpio1_0"), - _PIN(0x804, "GPMC_AD1", 33, 7,"gpmc_ad1", "mmc1_dat1", NULL, NULL, NULL, NULL, NULL, "gpio1_1"), - _PIN(0x808, "GPMC_AD2", 34, 7,"gpmc_ad2", "mmc1_dat2", NULL, NULL, NULL, NULL, NULL, "gpio1_2"), - _PIN(0x80C, "GPMC_AD3", 35, 7,"gpmc_ad3", "mmc1_dat3", NULL, NULL, NULL, NULL, NULL, "gpio1_3"), - _PIN(0x810, "GPMC_AD4", 36, 7,"gpmc_ad4", "mmc1_dat4", NULL, NULL, NULL, NULL, NULL, "gpio1_4"), - _PIN(0x814, "GPMC_AD5", 37, 7,"gpmc_ad5", "mmc1_dat5", NULL, NULL, NULL, NULL, NULL, "gpio1_5"), - _PIN(0x818, "GPMC_AD6", 38, 7,"gpmc_ad6", "mmc1_dat6", NULL, NULL, NULL, NULL, NULL, "gpio1_6"), - _PIN(0x81C, "GPMC_AD7", 39, 7,"gpmc_ad7", "mmc1_dat7", NULL, NULL, NULL, NULL, NULL, "gpio1_7"), -#if 0 /* Incomplete Entries - fill with data from table 2-7 in datasheet */ - _PIN(0x820, "gpmc_ad8", 0, 0, "gpmc_ad8", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x824, "gpmc_ad9", 0, 0, "gpmc_ad9", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x828, "gpmc_ad10", 0, 0, "gpmc_ad10", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x82C, "gpmc_ad11", 0, 0, "gpmc_ad11", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x830, "gpmc_ad12", 0, 0, "gpmc_ad12", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x834, "gpmc_ad13", 0, 0, "gpmc_ad13", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x838, "gpmc_ad14", 0, 0, "gpmc_ad14", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x83C, "gpmc_ad15", 0, 0, "gpmc_ad15", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x840, "gpmc_a0", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x844, "gpmc_a1", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x848, "gpmc_a2", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x84C, "gpmc_a3", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x850, "gpmc_a4", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), -#endif - _PIN(0x854, "GPMC_A5", 53, 7, "gpmc_a5", "gmii2_txd0", "rgmii2_td0", "rmii2_txd0", "gpmc_a21", "pr1_mii1_rxd3", "eQEP1B_in", "gpio1_21"), - _PIN(0x858, "GPMC_A6", 54, 7, "gpmc_a6", "gmii2_txclk", "rgmii2_tclk", "mmc2_dat4", "gpmc_a22", "pr1_mii1_rxd2", "eQEP1_index", "gpio1_22"), - _PIN(0x85C, "GPMC_A7", 55, 7, "gpmc_a7", "gmii2_rxclk", "rgmii2_rclk", "mmc2_dat5", "gpmc_a23", "pr1_mii1_rxd1", "eQEP1_strobe", "gpio1_23"), - _PIN(0x860, "GPMC_A8", 56, 7, "gpmc_a8", "gmii2_rxd3", "rgmii2_rd3", "mmc2_dat6", "gpmc_a24", "pr1_mii1_rxd0", "mcasp0_aclkx", "gpio1_24"), -#if 0 - _PIN(0x864, "gpmc_a9", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x868, "gpmc_a10", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x86C, "gpmc_a11", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x870, "gpmc_wait0", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x874, "gpmc_wpn", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x878, "gpmc_be1n", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x87c, "gpmc_csn0", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x880, "gpmc_csn1", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x884, "gpmc_csn2", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x888, "gpmc_csn3", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x88c, "gpmc_clk", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x890, "gpmc_advn_ale", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x894, "gpmc_oen_ren", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x898, "gpmc_wen", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x89c, "gpmc_be0n_cle", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8a0, "lcd_data0", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8a4, "lcd_data1", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8a8, "lcd_data2", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8ac, "lcd_data3", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8b0, "lcd_data4", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8b4, "lcd_data5", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8b8, "lcd_data6", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8bc, "lcd_data7", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8c0, "lcd_data8", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8c4, "lcd_data9", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8c8, "lcd_data10", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8cc, "lcd_data11", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8d0, "lcd_data12", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8d4, "lcd_data13", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8d8, "lcd_data14", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8dc, "lcd_data15", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8e0, "lcd_vsync", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8e4, "lcd_hsync", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8e8, "lcd_pclk", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x8ec, "lcd_ac_bias_en", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), -#endif - _PIN(0x8f0, "MMC0_DAT3", 90, 7, "mmc0_dat3", "gpmc_a20", "uart4_ctsn", "timer5", "uart1_dcdn", "pr1_pru0_pru_r30_8", "pr1_pru0_pru_r31_8", "gpio2_26"), - _PIN(0x8f4, "MMC0_DAT2", 91, 7, "mmc0_dat2", "gpmc_a21", "uart4_rtsn", "timer6", "uart1_dsrn", "pr1_pru0_pru_r30_9", "pr1_pru0_pru_r31_9", "gpio2_27"), - _PIN(0x8f8, "MMC0_DAT1", 92, 7, "mmc0_dat1", "gpmc_a22", "uart5_ctsn", "uart3_rxd", "uart1_dtrn", "pr1_pru0_pru_r30_10", "pr1_pru0_pru_r31_10", "gpio2_28"), - _PIN(0x8fc, "MMC0_DAT0", 93, 7, "mmc0_dat0", "gpmc_a23", "uart5_rtsn", "uart3_txd", "uart1_rin", "pr1_pru0_pru_r30_11", "pr1_pru0_pru_r31_11", "gpio2_29"), - _PIN(0x900, "MMC0_CLK", 94, 7, "mmc0_clk", "gpmc_a24", "uart3_ctsn", "uart2_rxd", "dcan1_tx", "pr1_pru0_pru_r30_12", "pr1_pru0_pru_r31_12", "gpio2_30"), - _PIN(0x904, "MMC0_CMD", 95, 7, "mmc0_cmd", "gpmc_a25", "uart3_rtsn", "uart2_txd", "dcan1_rx", "pr1_pru0_pru_r30_13", "pr1_pru0_pru_r31_13", "gpio2_31"), - _PIN(0x908, "MII1_COL", 96, 7, "gmii1_col", "rmii2_refclk", "spi1_sclk", "uart5_rxd", "mcasp1_axr2", "mmc2_dat3", "mcasp0_axr2", "gpio3_0"), - _PIN(0x90c, "MII1_CRS", 97, 7, "gmii1_crs", "rmii1_crs_dv", "spi1_d0", "I2C1_SDA", "mcasp1_aclkx", "uart5_ctsn", "uart2_rxd", "gpio3_1"), - _PIN(0x910, "MII1_RX_ER", 98, 7, "gmii1_rxerr", "rmii1_rxerr", "spi1_d1", "I2C1_SCL", "mcasp1_fsx", "uart5_rtsn", "uart2_txd", "gpio3_2"), - _PIN(0x914, "MII1_TX_EN", 99, 7, "gmii1_txen", "rmii1_txen", "rgmii1_tctl", "timer4", "mcasp1_axr0", "eQEP0_index", "mmc2_cmd", "gpio3_3"), + _PIN(0x800, "GPMC_AD0", 32, 7,"gpmc_ad0", "mmc1_dat0", NULL, NULL, NULL, NULL, NULL, "gpio1_0"), + _PIN(0x804, "GPMC_AD1", 33, 7,"gpmc_ad1", "mmc1_dat1", NULL, NULL, NULL, NULL, NULL, "gpio1_1"), + _PIN(0x808, "GPMC_AD2", 34, 7,"gpmc_ad2", "mmc1_dat2", NULL, NULL, NULL, NULL, NULL, "gpio1_2"), + _PIN(0x80C, "GPMC_AD3", 35, 7,"gpmc_ad3", "mmc1_dat3", NULL, NULL, NULL, NULL, NULL, "gpio1_3"), + _PIN(0x810, "GPMC_AD4", 36, 7,"gpmc_ad4", "mmc1_dat4", NULL, NULL, NULL, NULL, NULL, "gpio1_4"), + _PIN(0x814, "GPMC_AD5", 37, 7,"gpmc_ad5", "mmc1_dat5", NULL, NULL, NULL, NULL, NULL, "gpio1_5"), + _PIN(0x818, "GPMC_AD6", 38, 7,"gpmc_ad6", "mmc1_dat6", NULL, NULL, NULL, NULL, NULL, "gpio1_6"), + _PIN(0x81C, "GPMC_AD7", 39, 7,"gpmc_ad7", "mmc1_dat7", NULL, NULL, NULL, NULL, NULL, "gpio1_7"), + _PIN(0x820, "GPMC_AD8", 22, 7, "gpmc_ad8", "lcd_data23", "mmc1_dat0", "mmc2_dat4", "ehrpwm2A", NULL, NULL, "gpio0_22"), + _PIN(0x824, "GPMC_AD9", 23, 7, "gpmc_ad9", "lcd_data22", "mmc1_dat1", "mmc2_dat5", "ehrpwm2B", NULL, NULL, "gpio0_23"), + _PIN(0x828, "GPMC_AD10", 26, 7, "gpmc_ad10", "lcd_data21", "mmc1_dat2", "mmc2_dat6", "ehrpwm2_tripzone_in", NULL, NULL, "gpio0_26"), + _PIN(0x82C, "GPMC_AD11", 27, 7, "gpmc_ad11", "lcd_data20", "mmc1_dat3", "mmc2_dat7", "ehrpwm0_synco", NULL, NULL, "gpio0_27"), + _PIN(0x830, "GPMC_AD12", 44, 7, "gpmc_ad12", "lcd_data19", "mmc1_dat4", "mmc2_dat0", "eQEP2A_in", "pr1_mii0_txd2", "pr1_pru0_pru_r30_14", "gpio1_12"), + _PIN(0x834, "GPMC_AD13", 45, 7, "gpmc_ad13", "lcd_data18", "mmc1_dat5", "mmc2_dat1", "eQEP2B_in", "pr1_mii0_txd1", "pr1_pru0_pru_r30_15", "gpio1_13"), + _PIN(0x838, "GPMC_AD14", 46, 7, "gpmc_ad14", "lcd_data17", "mmc1_dat6", "mmc2_dat2", "eQEP2_index", "pr1_mii0_txd0", "pr1_pru0_pru_r31_14", "gpio1_14"), + _PIN(0x83C, "GPMC_AD15", 47, 7, "gpmc_ad15", "lcd_data16", "mmc1_dat7", "mmc2_dat3", "eQEP2_strobe", "pr1_ecap0_ecap_capin_apwm_o", "pr1_pru0_pru_r31_15", "gpio1_15"), + _PIN(0x840, "GPMC_A0", 48, 7, "gpmc_a0", "gmii2_txen", "rgmii2_tctl", "rmii2_txen", "gpmc_a16", "pr1_mii_mt1_clk", "ehrpwm1_tripzone_input", "gpio1_16"), + _PIN(0x844, "GPMC_A1", 49, 7, "gpmc_a1", "gmii2_rxdv", "rgmii2_rctl", "mmc2_dat0", "gpmc_a17", "pr1_mii1_txd3", "ehrpwm0_synco", "gpio1_17"), + _PIN(0x848, "GPMC_A2", 50, 7, "gpmc_a2", "gmii2_txd3", "rgmii2_td3", "mmc2_dat1", "gpmc_a18", "pr1_mii1_txd2", "ehrpwm1A", "gpio1_18"), + _PIN(0x84C, "GPMC_A3", 51, 7, "gpmc_a3", "gmii2_txd2", "rgmii2_td2", "mmc2_dat2", "gpmc_a19", "pr1_mii1_txd1", "ehrpwm1B", "gpio1_19"), + _PIN(0x850, "GPMC_A4", 52, 7, "gpmc_a4", "gmii2_txd1", "rgmii2_td1", "rmii2_tdx1", "gpmc_a20", "pr1_mii1_txd0", "eQEP1A_in", "gpio1_20"), + _PIN(0x854, "GPMC_A5", 53, 7, "gpmc_a5", "gmii2_txd0", "rgmii2_td0", "rmii2_txd0", "gpmc_a21", "pr1_mii1_rxd3", "eQEP1B_in", "gpio1_21"), + _PIN(0x858, "GPMC_A6", 54, 7, "gpmc_a6", "gmii2_txclk", "rgmii2_tclk", "mmc2_dat4", "gpmc_a22", "pr1_mii1_rxd2", "eQEP1_index", "gpio1_22"), + _PIN(0x85C, "GPMC_A7", 55, 7, "gpmc_a7", "gmii2_rxclk", "rgmii2_rclk", "mmc2_dat5", "gpmc_a23", "pr1_mii1_rxd1", "eQEP1_strobe", "gpio1_23"), + _PIN(0x860, "GPMC_A8", 56, 7, "gpmc_a8", "gmii2_rxd3", "rgmii2_rd3", "mmc2_dat6", "gpmc_a24", "pr1_mii1_rxd0", "mcasp0_aclkx", "gpio1_24"), + _PIN(0x864, "GPMC_A9", 57, 7, "gmpc_a9", "gmii2_rxd2", "rgmii2_rd2", "mmc2_dat7 / rmii2_crs_dv", "gpmc_a25", "pr1_mii_mr1_clk", "mcasp0_fsx", "gpio1_25"), + _PIN(0x868, "GPMC_A10", 58, 7, "gmpc_a10", "gmii2_rxd1", "rgmii2_rd1", "rmii2_rxd1", "gpmc_a26", "pr1_mii1_rxdv", "mcasp0_arx0", "gpio1_26"), + _PIN(0x86C, "GPMC_A11", 59, 7, "gmpc_a11", "gmii2_rxd0", "rgmii2_rd0", "rmii2_rxd0", "gpmc_a27", "pr1_mii1_rxer", "mcasp0_axr1", "gpio1_27"), + _PIN(0x870, "GPMC_WAIT0", 30, 7, "gpmc_wait0", "gmii2_crs", "gpmc_csn4", "rmii2_crs_dv", "mmc1_sdcd", "pr1_mii1_col", "uart4_rxd", "gpio0_30"), + _PIN(0x874, "GPMC_WPn", 31, 7, "gpmc_wpn", "gmii2_rxerr", "gpmc_csn5", "rmii2_rxerr", "mmc2_sdcd", "pr1_mii1_txen", "uart4_txd", "gpio0_31"), + _PIN(0x878, "GPMC_BEn1", 60, 7, "gpmc_be1n", "gmii2_col", "gmpc_csn6","mmc2_dat3", "gpmc_dir", "pr1_mii1_rxlink", "mcasp0_aclkr", "gpio1_28"), + _PIN(0x87c, "GPMC_CSn0", 61, 7, "gpmc_csn0", NULL, NULL, NULL, NULL, NULL, NULL, "gpio1_29"), + _PIN(0x880, "GPMC_CSn1", 62, 7, "gpmc_csn1", "gpmc_clk", "mmc1_clk", "pr1_edio_data_in6", "pr1_edio_data_out6", "pr1_pru1_pru_r30_12", "pr1_pru1_pru_r31_12", "gpio1_30"), + _PIN(0x884, "GPMC_CSn2", 63, 7, "gpmc_csn2", "gpmc_be1n", "mmc1_cmd", "pr1_edio_data_in7", "pr1_edio_data_out7", "pr1_pru1_pru_r30_13", "pr1_pru1_pru_r31_13", "gpio1_31"), + _PIN(0x888, "GPMC_CSn3", 64, 7, "gpmc_csn3", "gpmc_a3", "rmii2_crs_dv", "mmc2_cmd", "pr1_mii0_crs", "pr1_mdio_data", "EMU4", "gpio2_0"), + _PIN(0x88c, "GPMC_CLK", 65, 7, "gpmc_clk", "lcd_memory_clk", "gpmc_wait1", "mmc2_clk", "pr1_mii1_crs", "pr1_mdio_mdclk", "mcasp0_fsr", "gpio2_1"), + _PIN(0x890, "GPMC_ADVn_ALE", 66, 7, "gpmc_advn_ale", NULL, "timer4", NULL, NULL, NULL, NULL, "gpio2_2"), + _PIN(0x894, "GPMC_OEn_REn", 67, 7, "gpmc_oen_ren", NULL, "timer7", NULL, NULL, NULL, NULL, "gpio2_3"), + _PIN(0x898, "GPMC_WEn", 68, 7, "gpmc_wen", NULL, "timer6", NULL, NULL, NULL, NULL, "gpio2_4"), + _PIN(0x89c, "GPMC_BEn0_CLE", 67, 7, "gpmc_ben0_cle", NULL, "timer5", NULL, NULL, NULL, NULL, "gpio2_5"), + _PIN(0x8a0, "LCD_DATA0", 68, 7, "lcd_data0", "gpmc_a0", "pr1_mii_mt0_clk", "ehrpwm2A", NULL, "pr1_pru1_pru_r30_0", "pr1_pru1_pru_r31_0", "gpio2_6"), + _PIN(0x8a4, "LCD_DATA1", 69, 7, "lcd_data1", "gpmc_a1", "pr1_mii0_txen", "ehrpwm2B", NULL, "pr1_pru1_pru_r30_1", "pr1_pru1_pru_r31_1", "gpio2_7"), + _PIN(0x8a8, "LCD_DATA2", 70, 7, "lcd_data2", "gpmc_a2", "pr1_mii0_txd3", "ehrpwm2_tripzone_input", NULL, "pr1_pru1_pru_r30_2", "pr1_pru1_pru_r31_2", "gpio2_8"), + _PIN(0x8ac, "LCD_DATA3", 71, 7, "lcd_data3", "gpmc_a3", "pr1_mii0_txd2", "ehrpwm0_synco", NULL, "pr1_pru1_pru_r30_3", "pr1_pru1_pru_r31_3", "gpio2_9"), + _PIN(0x8b0, "LCD_DATA4", 72, 7, "lcd_data4", "gpmc_a4", "pr1_mii0_txd1", "eQEP2A_in", NULL, "pr1_pru1_pru_r30_4", "pr1_pru1_pru_r31_4", "gpio2_10"), + _PIN(0x8b4, "LCD_DATA5", 73, 7, "lcd_data5", "gpmc_a5", "pr1_mii0_txd0", "eQEP2B_in", NULL, "pr1_pru1_pru_r30_5", "pr1_pru1_pru_r31_5", "gpio2_11"), + _PIN(0x8b8, "LCD_DATA6", 74, 7, "lcd_data6", "gpmc_a6", "pr1_edio_data_in6", "eQEP2_index", "pr1_edio_data_out6", "pr1_pru1_pru_r30_6", "pr1_pru1_pru_r31_6", "gpio2_12"), + _PIN(0x8bc, "LCD_DATA7", 75, 7, "lcd_data7", "gpmc_a7", "pr1_edio_data_in7", "eQEP2_strobe", "pr1_edio_data_out7", "pr1_pru1_pru_r30_7", "pr1_pru1_pru_r31_7", "gpio2_13"), + _PIN(0x8c0, "LCD_DATA8", 76, 7, "lcd_data8", "gpmc_a12", "ehrpwm1_tripzone_input", "mcasp0_aclkx", "uart5_txd", "pr1_mii0_rxd3", "uart2_ctsn", "gpio2_14"), + _PIN(0x8c4, "LCD_DATA9", 76, 7, "lcd_data9", "gpmc_a13", "ehrpwm0_synco", "mcasp0_fsx", "uart5_rxd", "pr1_mii0_rxd2", "uart2_rtsn", "gpio2_15"), + _PIN(0x8c8, "LCD_DATA10", 77, 7, "lcd_data10", "gpmc_a14", "ehrpwm1A", "mcasp0_axr0", NULL, "pr1_mii0_rxd1", "uart3_ctsn", "gpio2_16"), + _PIN(0x8cc, "LCD_DATA11", 78, 7, "lcd_data11", "gpmc_a15", "ehrpwm1B", "mcasp0_ahclkr", "mcasp0_axr2", "pr1_mii0_rxd0", "uart3_rtsn", "gpio2_17"), + _PIN(0x8d0, "LCD_DATA12", 8, 7, "lcd_data12", "gpmc_a16", "eQEP1A_in", "mcasp0_aclkr", "mcasp0_axr2", "pr1_mii0_rxlink", "uart4_ctsn", "gpio0_8"), + _PIN(0x8d4, "LCD_DATA13", 9, 7, "lcd_data13", "gpmc_a17", "eQEP1B_in", "mcasp0_fsr", "mcasp0_axr3", "pr1_mii0_rxer", "uart4_rtsn", "gpio0_9"), + _PIN(0x8d8, "LCD_DATA14", 10, 7, "lcd_data14", "gpmc_a18", "eQEP1_index", "mcasp0_axr1", "uart5_rxd", "pr1_mii_mr0_clk", "uart5_ctsn", "gpio0_10"), + _PIN(0x8dc, "LCD_DATA15", 11, 7, "lcd_data15", "gpmc_a19", "eQEP1_strobe", "mcasp0_ahclkx", "mcasp0_axr3", "pr1_mii0_rxdv", "uart5_rtsn", "gpio0_11"), + _PIN(0x8e0, "LCD_VSYNC", 86, 7, "lcd_vsync", "gpmc_a8", "gpmc_a1", "pr1_edio_data_in2", "pr1_edio_data_out2", "pr1_pru1_pru_r30_8", "pr1_pru1_pru_r31_8", "gpio2_22"), + _PIN(0x8e4, "LCD_HSYNC", 87, 7, "lcd_hsync", "gmpc_a9", "gpmc_a2", "pr1_edio_data_in3", "pr1_edio_data_out3", "pr1_pru1_pru_r30_9", "pr1_pru1_pru_r31_9", "gpio2_23"), + _PIN(0x8e8, "LCD_PCLK", 88, 7, "lcd_pclk", "gpmc_a10", "pr1_mii0_crs", "pr1_edio_data_in4", "pr1_edio_data_out4", "pr1_pru1_pru_r30_10", "pr1_pru1_pru_r31_10", "gpio2_24"), + _PIN(0x8ec, "LCD_AC_BIAS_EN", 89, 7, "lcd_ac_bias_en", "gpmc_a11", "pr1_mii1_crs", "pr1_edio_data_in5", "pr1_edio_data_out5", "pr1_pru1_pru_r30_11", "pr1_pru1_pru_r31_11", "gpio2_25"), + _PIN(0x8f0, "MMC0_DAT3", 90, 7, "mmc0_dat3", "gpmc_a20", "uart4_ctsn", "timer5", "uart1_dcdn", "pr1_pru0_pru_r30_8", "pr1_pru0_pru_r31_8", "gpio2_26"), + _PIN(0x8f4, "MMC0_DAT2", 91, 7, "mmc0_dat2", "gpmc_a21", "uart4_rtsn", "timer6", "uart1_dsrn", "pr1_pru0_pru_r30_9", "pr1_pru0_pru_r31_9", "gpio2_27"), + _PIN(0x8f8, "MMC0_DAT1", 92, 7, "mmc0_dat1", "gpmc_a22", "uart5_ctsn", "uart3_rxd", "uart1_dtrn", "pr1_pru0_pru_r30_10", "pr1_pru0_pru_r31_10", "gpio2_28"), + _PIN(0x8fc, "MMC0_DAT0", 93, 7, "mmc0_dat0", "gpmc_a23", "uart5_rtsn", "uart3_txd", "uart1_rin", "pr1_pru0_pru_r30_11", "pr1_pru0_pru_r31_11", "gpio2_29"), + _PIN(0x900, "MMC0_CLK", 94, 7, "mmc0_clk", "gpmc_a24", "uart3_ctsn", "uart2_rxd", "dcan1_tx", "pr1_pru0_pru_r30_12", "pr1_pru0_pru_r31_12", "gpio2_30"), + _PIN(0x904, "MMC0_CMD", 95, 7, "mmc0_cmd", "gpmc_a25", "uart3_rtsn", "uart2_txd", "dcan1_rx", "pr1_pru0_pru_r30_13", "pr1_pru0_pru_r31_13", "gpio2_31"), + _PIN(0x908, "MII1_COL", 96, 7, "gmii1_col", "rmii2_refclk", "spi1_sclk", "uart5_rxd", "mcasp1_axr2", "mmc2_dat3", "mcasp0_axr2", "gpio3_0"), + _PIN(0x90c, "MII1_CRS", 97, 7, "gmii1_crs", "rmii1_crs_dv", "spi1_d0", "I2C1_SDA", "mcasp1_aclkx", "uart5_ctsn", "uart2_rxd", "gpio3_1"), + _PIN(0x910, "MII1_RX_ER", 98, 7, "gmii1_rxerr", "rmii1_rxerr", "spi1_d1", "I2C1_SCL", "mcasp1_fsx", "uart5_rtsn", "uart2_txd", "gpio3_2"), + _PIN(0x914, "MII1_TX_EN", 99, 7, "gmii1_txen", "rmii1_txen", "rgmii1_tctl", "timer4", "mcasp1_axr0", "eQEP0_index", "mmc2_cmd", "gpio3_3"), _PIN(0x918, "MII1_RX_DV", 100, 7, "gmii1_rxdv", "cd_memory_clk", "rgmii1_rctl", "uart5_txd", "mcasp1_aclkx", "mmc2_dat0", "mcasp0_aclkr", "gpio3_4"), - _PIN(0x91c, "MII1_TXD3", 16, 7, "gmii1_txd3", "dcan0_tx", "rgmii1_td3", "uart4_rxd", "mcasp1_fsx", "mmc2_dat1", "mcasp0_fsr", "gpio0_16"), - _PIN(0x920, "MII1_TXD2", 17, 7, "gmii1_txd2", "dcan0_rx", "rgmii1_td2", "uart4_txd", "mcasp1_axr0", "mmc2_dat2", "mcasp0_ahclkx", "gpio0_17"), - _PIN(0x924, "MII1_TXD1", 21, 7, "gmii1_txd1", "rmii1_txd1", "rgmii1_td1", "mcasp1_fsr", "mcasp1_axr1", "eQEP0A_in", "mmc1_cmd", "gpio0_21"), - _PIN(0x928, "MII1_TXD0", 28, 7, "gmii1_txd0", "rmii1_txd0", "rgmii1_td0", "mcasp1_axr2", "mcasp1_aclkr", "eQEP0B_in", "mmc1_clk", "gpio0_28"), + _PIN(0x91c, "MII1_TXD3", 16, 7, "gmii1_txd3", "dcan0_tx", "rgmii1_td3", "uart4_rxd", "mcasp1_fsx", "mmc2_dat1", "mcasp0_fsr", "gpio0_16"), + _PIN(0x920, "MII1_TXD2", 17, 7, "gmii1_txd2", "dcan0_rx", "rgmii1_td2", "uart4_txd", "mcasp1_axr0", "mmc2_dat2", "mcasp0_ahclkx", "gpio0_17"), + _PIN(0x924, "MII1_TXD1", 21, 7, "gmii1_txd1", "rmii1_txd1", "rgmii1_td1", "mcasp1_fsr", "mcasp1_axr1", "eQEP0A_in", "mmc1_cmd", "gpio0_21"), + _PIN(0x928, "MII1_TXD0", 28, 7, "gmii1_txd0", "rmii1_txd0", "rgmii1_td0", "mcasp1_axr2", "mcasp1_aclkr", "eQEP0B_in", "mmc1_clk", "gpio0_28"), _PIN(0x92c, "MII1_TX_CLK", 105, 7, "gmii1_txclk", "uart2_rxd", "rgmii1_tclk", "mmc0_dat7", "mmc1_dat0", "uart1_dcdn", "mcasp0_aclkx", "gpio3_9"), _PIN(0x930, "MII1_RX_CLK", 106, 7, "gmii1_rxclk", "uart2_txd", "rgmii1_rclk", "mmc0_dat6", "mmc1_dat1", "uart1_dsrn", "mcasp0_fsx", "gpio3_10"), - _PIN(0x934, "MII1_RXD3", 82, 7, "gmii1_rxd3", "uart3_rxd", "rgmii1_rd3", "mmc0_dat5", "mmc1_dat2", "uart1_dtrn", "mcasp0_axr0", "gpio2_18"), - _PIN(0x938, "MII1_RXD2", 83, 7, "gmii1_rxd2", "uart3_txd", "rgmii1_rd2", "mmc0_dat4", "mmc1_dat3", "uart1_rin", "mcasp0_axr1", "gpio2_19"), - _PIN(0x93c, "MII1_RXD1", 84, 7, "gmii1_rxd1", "rmii1_rxd1", "rgmii1_rd1", "mcasp1_axr3", "mcasp1_fsr", "eQEP0_strobe", "mmc2_clk", "gpio2_20"), - _PIN(0x940, "MII1_RXD0", 85, 7, "gmii1_rxd0", "rmii1_rxd0", "rgmii1_rd0", "mcasp1_ahclkx", "mcasp1_ahclkr", "mcasp1_aclkr", "mcasp0_axr3", "gpio2_21"), - _PIN(0x944, "RMII1_REF_CLK", 29, 7, "rmii1_refclk", "xdma_event_intr2", "spi1_cs0", "uart5_txd", "mcasp1_axr3", "mmc0_pow", "mcasp1_ahclkx", "gpio0_29"), - _PIN(0x948, "MDIO", 0, 7, "mdio_data", "timer6", "uart5_rxd", "uart3_ctsn", "mmc0_sdcd","mmc1_cmd", "mmc2_cmd","gpio0_0"), - _PIN(0x94c, "MDC", 1, 7, "mdio_clk", "timer5", "uart5_txd", "uart3_rtsn", "mmc0_sdwp", "mmc1_clk", "mmc2_clk", "gpio0_1"), -#if 0 /* Incomplete Entries - fill with data from table 2-7 in datasheet */ - _PIN(0x950, "spi0_sclk", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x954, "spi0_d0", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), -#endif - _PIN(0x958, "spi0_d1", 4, 7, "spi0_d1", "mmc1_sdwp", "I2C1_SDA", "ehrpwm0_tripzone_input", "pr1_uart0_rxd", "pr1_edio_data_in0", "pr1_edio_data_out0", "gpio0_4"), - _PIN(0x95c, "spi0_cs0", 5, 7, "spi0_cs0", "mmc2_sdwp", "I2C1_SCL", "ehrpwm0_synci", "pr1_uart0_txd", "pr1_edio_data_in1", "pr1_edio_data_out1", "gpio0_5"), -#if 0 - _PIN(0x960, "spi0_cs1", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x964, "ecap0_in_pwm0_out",0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x968, "uart0_ctsn", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x96c, "uart0_rtsn", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x970, "uart0_rxd", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x974, "uart0_txd", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), -#endif - _PIN(0x978, "uart1_ctsn", 12, 7, "uart1_ctsn", "timer6_mux1", "dcan0_tx", "I2C2_SDA", "spi1_cs0", "pr1_uart0_cts_n", "pr1_edc_latch0_in", "gpio0_12"), - _PIN(0x97c, "uart1_rtsn", 13, 7, "uart1_rtsn", "timer5_mux1", "dcan0_rx", "I2C2_SCL", "spi1_cs1", "pr1_uart0_rts_n ", "pr1_edc_latch1_in", "gpio0_13"), -#if 0 - _PIN(0x980, "uart1_rxd", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x984, "uart1_txd", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), -#endif + _PIN(0x934, "MII1_RXD3", 82, 7, "gmii1_rxd3", "uart3_rxd", "rgmii1_rd3", "mmc0_dat5", "mmc1_dat2", "uart1_dtrn", "mcasp0_axr0", "gpio2_18"), + _PIN(0x938, "MII1_RXD2", 83, 7, "gmii1_rxd2", "uart3_txd", "rgmii1_rd2", "mmc0_dat4", "mmc1_dat3", "uart1_rin", "mcasp0_axr1", "gpio2_19"), + _PIN(0x93c, "MII1_RXD1", 84, 7, "gmii1_rxd1", "rmii1_rxd1", "rgmii1_rd1", "mcasp1_axr3", "mcasp1_fsr", "eQEP0_strobe", "mmc2_clk", "gpio2_20"), + _PIN(0x940, "MII1_RXD0", 85, 7, "gmii1_rxd0", "rmii1_rxd0", "rgmii1_rd0", "mcasp1_ahclkx", "mcasp1_ahclkr", "mcasp1_aclkr", "mcasp0_axr3", "gpio2_21"), + _PIN(0x944, "RMII1_REF_CLK", 29, 7, "rmii1_refclk", "xdma_event_intr2", "spi1_cs0", "uart5_txd", "mcasp1_axr3", "mmc0_pow", "mcasp1_ahclkx", "gpio0_29"), + _PIN(0x948, "MDIO", 0, 7, "mdio_data", "timer6", "uart5_rxd", "uart3_ctsn", "mmc0_sdcd","mmc1_cmd", "mmc2_cmd","gpio0_0"), + _PIN(0x94c, "MDC", 1, 7, "mdio_clk", "timer5", "uart5_txd", "uart3_rtsn", "mmc0_sdwp", "mmc1_clk", "mmc2_clk", "gpio0_1"), + _PIN(0x950, "SPI0_SCLK", 2, 7, "spi0_sclk", "uart2_rxd", "I2C2_SDA", "ehrpwm0A", "pr1_uart0_cts_n", "pr1_edio_sof", "EMU2", "gpio0_2"), + _PIN(0x954, "SPI0_D0", 3, 7, "spi0_d0", "uart2_txd", "i2C2_SCL", "ehrpwm0B", "pr1_uart0_rts_n", "pr1_edio_latch_in", "EMU3", "gpio0_3"), + _PIN(0x958, "SPIO_D1", 4, 7, "spi0_d1", "mmc1_sdwp", "I2C1_SDA", "ehrpwm0_tripzone_input", "pr1_uart0_rxd", "pr1_edio_data_in0", "pr1_edio_data_out0", "gpio0_4"), + _PIN(0x95c, "SPI0_CS0", 5, 7, "spi0_cs0", "mmc2_sdwp", "I2C1_SCL", "ehrpwm0_synci", "pr1_uart0_txd", "pr1_edio_data_in1", "pr1_edio_data_out1", "gpio0_5"), + _PIN(0x960, "SPI0_CS1", 6, 7, "spi0_cs1", "uart3_rxd", "eCAP1_in_PWM1_out", "mcc0_pow", "xdm_event_intr2", "mmc0_sdcd", "EMU4", "gpio0_6"), + _PIN(0x964, "ECAP0_IN_PWM0_OUT",7, 7, "eCAP0_in_PWM0_out", "uart3_txd", "spi1_cs1", "pr1_ecap0_ecap_capin_apwm_o", "spi1_sclk", "mmc0_sdwp", "xdma_event_intr2", "gpio0_7"), + _PIN(0x968, "UART0_CTSn", 40, 7, "uart0_ctsn", "uart4_rxd", "dcan1_tx", "I2C1_SDA", "spi1_d0", "timer7", "pr1_edc_sync0_out", "gpio1_8"), + _PIN(0x96c, "UART0_RTSn", 41, 7, "uart0_rtsn", "uart4_txd", "dcan1_rx", "I2C1_SCL", "spi1_d1", "spi1_cs0", "pr1_edc_sync1_out", "gpio1_9"), + _PIN(0x970, "UART0_rxd", 42, 7, "uart0_rxd", "spi1_cs0", "dcan0_tx", "I2C2_SDA", "eCAP2_in_PWM2_out", "pr1_pru1_pru_r30_14", "pr1_pru1_pru_r31_14", "gpio1_10"), + _PIN(0x974, "UART0_txd", 43, 7, "uart0_txd", "spi1_cs1", "dcan0_rx", "I2C2_SCL", "eCAP1_in_PWM1_out", "pr1_pru1_pru_r30_15", "pr1_pru1_pru_r31_15", "gpio1_11"), + _PIN(0x978, "UART1_CTSn", 12, 7, "uart1_ctsn", "timer6_mux1", "dcan0_tx", "I2C2_SDA", "spi1_cs0", "pr1_uart0_cts_n", "pr1_edc_latch0_in", "gpio0_12"), + _PIN(0x97c, "UART1_RTSn", 13, 7, "uart1_rtsn", "timer5_mux1", "dcan0_rx", "I2C2_SCL", "spi1_cs1", "pr1_uart0_rts_n ", "pr1_edc_latch1_in", "gpio0_13"), + _PIN(0x980, "UART1_RXD", 14, 7, "uart1_rxd", "mmc1_sdwp", "dcan1_tx", "I2C1_SDA", NULL, "pr1_uart0_rxd", "pr1_pru1_pru_r31_16", "gpio0_14"), + _PIN(0x984, "UART1_TXD", 15, 7, "uart1_txd", "mmc2_sdwp", "dcan1_rx", "I2C1_SCL", NULL, "pr1_uart0_txd", "pr1_pru0_pru_r31_16", "gpio0_15"), _PIN(0x988, "I2C0_SDA", 101, 7, "I2C0_SDA", "timer4", "uart2_ctsn", "eCAP2_in_PWM2_out", NULL, NULL, NULL, "gpio3_5"), _PIN(0x98c, "I2C0_SCL", 102, 7, "I2C0_SCL", "timer7", "uart2_rtsn", "eCAP1_in_PWM1_out", NULL, NULL, NULL, "gpio3_6"), + _PIN(0x990, "MCASP0_ACLKX", 110, 7, "mcasp0_aclkx", "ehrpwm0A", NULL, "spi1_sclk", "mmc0_sdcd", "pr1_pru0_pru_r30_0", "pr1_pru0_pru_r31_0", "gpio3_14"), + _PIN(0x994, "MCASP0_FSX", 111, 7, "mcasp0_fsx", "ehrpwm0B", NULL, "spi1_d0", "mmc1_sdcd", "pr1_pru0_pru_r30_1", "pr1_pru0_pru_r31_1", "gpio3_15"), + _PIN(0x998, "MCASP0_AXR0", 112, 7, "mcasp0_axr0", "ehrpwm0_tripzone_input", NULL, "spi1_d1", "mmc2_sdcd", "pr1_pru0_pru_r30_2", "pr1_pru0_pru_r31_2", "gpio3_16"), + _PIN(0x99c, "MCASP0_AHCLKR", 113, 7, "mcasp0_ahclkr", "ehrpwm0_synci", "mcasp0_axr2", "spi1_cs0", "eCAP2_in_PWM2_out", "pr1_pru0_pru_r30_3", "pr1_pru0_pru_r31_3", "gpio3_17"), + _PIN(0x9a0, "MCASP0_ACLKR", 114, 7, "mcasp0_aclkr", "eQEP0A_in", "mcasp0_axr2", "mcasp1_aclkx", "mmc0_sdwp", "pr1_pru0_pru_r30_4", "pr1_pru0_pru_r31_4", "gpio3_18"), + _PIN(0x9a4, "MCASP0_FSR", 115, 7, "mcasp0_fsr", "eQEP0B_in", "mcasp0_axr3", "mcasp1_fsx", "EMU2", "pr1_pru0_pru_r30_5", "pr1_pru0_pru_r31_5", "gpio3_19"), + _PIN(0x9a8, "MCASP0_AXR1", 116, 7, "mcasp0_axr1", "eQEP0_index", NULL, "mcasp1_axr0", "EMU3", "pr1_pru0_pru_r30_6", "pr1_pru0_pru_r31_6", "gpio3_20"), + _PIN(0x9ac, "MCASP0_AHCLKX", 117, 7, "mcasp0_ahclkx", "eQEP0_strobe", "mcasp0_axr3", "mcasp1_axr1", "EMU4", "pr1_pru0_pru_r30_7", "pr1_pru0_pru_r31_7", "gpio3_21"), + _PIN(0x9b0, "XDMA_EVENT_INTR0", 19, 7, "xdma_event_intr0", NULL, "timer4", "clkout1", "spi1_cs1", "pr1_pru1_pru_r31_16", "EMU2", "gpio0_19"), + _PIN(0x9b4, "XDMA_EVENT_INTR1", 20, 7, "xdma_event_intr1", NULL, "tclkin", "clkout2", "timer7", "pr1_pru0_pru_r31_16", "EMU3", "gpio0_20"), #if 0 - _PIN(0x990, "mcasp0_aclkx", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x994, "mcasp0_fsx", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x998, "mcasp0_axr0", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x99c, "mcasp0_ahclkr", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x9a0, "mcasp0_aclkr", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x9a4, "mcasp0_fsr", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x9a8, "mcasp0_axr1", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x9ac, "mcasp0_ahclkx", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x9b0, "xdma_event_intr0", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x9b4, "xdma_event_intr1", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), _PIN(0x9b8, "nresetin_out", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), _PIN(0x9bc, "porz", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), _PIN(0x9c0, "nnmi", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), @@ -218,8 +208,10 @@ _PIN(0x9d8, "tdo", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), _PIN(0x9dc, "tck", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), _PIN(0x9e0, "ntrst", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x9e4, "emu0", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0x9e8, "emu1", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), +#endif + _PIN(0x9e4, "EMU0", 103, 7, "EMU0", NULL, NULL, NULL, NULL, NULL, NULL, "gpio3_7"), + _PIN(0x9e8, "EMU1", 104, 0, "EMU1", NULL, NULL, NULL, NULL, NULL, NULL, "gpio3_8"), +#if 0 _PIN(0x9ec, "osc1_in", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), _PIN(0x9f0, "osc1_out", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), _PIN(0x9f4, "osc1_vss", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), @@ -228,17 +220,17 @@ _PIN(0xa00, "ext_wakeup", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), _PIN(0xa04, "enz_kaldo_1p8v", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), #endif - _PIN(0xa08, "USB0_DM", 0, 0, "USB0_DM", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0xa0c, "USB0_DP", 0, 0, "USB0_DP", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0xa10, "USB0_CE", 0, 0, "USB0_CE", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0xa14, "USB0_ID", 0, 0, "USB0_ID", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0xa18, "USB0_VBUS", 0, 0, "USB0_VBUS", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0xa1c, "USB0_DRVVBUS", 18, 7, "USB0_DRVVBUS", NULL, NULL, NULL, NULL, NULL, NULL, "gpio0_18"), - _PIN(0xa20, "USB1_DM", 0, 0, "USB1_DM", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0xa24, "USB1_DP", 0, 0, "USB1_DP", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0xa28, "USB1_CE", 0, 0, "USB1_CE", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0xa2c, "USB1_ID", 0, 0, "USB1_ID", NULL, NULL, NULL, NULL, NULL, NULL, NULL), - _PIN(0xa30, "USB1_VBUS", 0, 0, "USB1_VBUS", NULL, NULL, NULL, NULL, NULL, NULL, NULL), + _PIN(0xa08, "USB0_DM", 0, 0, "USB0_DM", NULL, NULL, NULL, NULL, NULL, NULL, NULL), + _PIN(0xa0c, "USB0_DP", 0, 0, "USB0_DP", NULL, NULL, NULL, NULL, NULL, NULL, NULL), + _PIN(0xa10, "USB0_CE", 0, 0, "USB0_CE", NULL, NULL, NULL, NULL, NULL, NULL, NULL), + _PIN(0xa14, "USB0_ID", 0, 0, "USB0_ID", NULL, NULL, NULL, NULL, NULL, NULL, NULL), + _PIN(0xa18, "USB0_VBUS", 0, 0, "USB0_VBUS", NULL, NULL, NULL, NULL, NULL, NULL, NULL), + _PIN(0xa1c, "USB0_DRVVBUS", 18, 7, "USB0_DRVVBUS", NULL, NULL, NULL, NULL, NULL, NULL, "gpio0_18"), + _PIN(0xa20, "USB1_DM", 0, 0, "USB1_DM", NULL, NULL, NULL, NULL, NULL, NULL, NULL), + _PIN(0xa24, "USB1_DP", 0, 0, "USB1_DP", NULL, NULL, NULL, NULL, NULL, NULL, NULL), + _PIN(0xa28, "USB1_CE", 0, 0, "USB1_CE", NULL, NULL, NULL, NULL, NULL, NULL, NULL), + _PIN(0xa2c, "USB1_ID", 0, 0, "USB1_ID", NULL, NULL, NULL, NULL, NULL, NULL, NULL), + _PIN(0xa30, "USB1_VBUS", 0, 0, "USB1_VBUS", NULL, NULL, NULL, NULL, NULL, NULL, NULL), _PIN(0xa34, "USB1_DRVVBUS", 109, 7, "USB1_DRVVBUS", NULL, NULL, NULL, NULL, NULL, NULL, "gpio3_13"), #if 0 _PIN(0xa38, "ddr_resetn", 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL), --Multipart=_Mon__28_Jan_2013_06_34_36_+0100_rO6BRDMkQZyt4x0Q-- From owner-freebsd-arm@FreeBSD.ORG Mon Jan 28 08:35: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 B65AF76F for ; Mon, 28 Jan 2013 08:35:13 +0000 (UTC) (envelope-from johan@netsense.nl) Received: from mail.netsense.nl (pretsense.xs4all.nl [82.161.36.79]) by mx1.freebsd.org (Postfix) with ESMTP id 2421B149 for ; Mon, 28 Jan 2013 08:35:12 +0000 (UTC) Received: (qmail 21497 invoked from network); 28 Jan 2013 09:28:28 +0100 Received: from dhcp47.nest.nl (johan@172.16.79.47) by mail.netsense.nl with AES128-SHA encrypted SMTP; 28 Jan 2013 09:28:28 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: DreamPlug support committed From: Johan Henselmans In-Reply-To: <1359306117.93359.29.camel@revolution.hippie.lan> Date: Mon, 28 Jan 2013 09:28:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <13FCC2A8-A394-491A-815B-CDEE6DA95237@netsense.nl> References: <1359306117.93359.29.camel@revolution.hippie.lan> To: freebsd-arm X-Mailer: Apple Mail (2.1499) Cc: 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, 28 Jan 2013 08:35:13 -0000 On 27 jan. 2013, at 18:01, Ian Lepore wrote: > FYI, I've committed the last missing bits of support for the = DreamPlug, > so as of r245955 it's now possible to build for dreamplug without > needing any extra patches, using stock kernel config DREAMPLUG-1001. = I > also included the .dts file for the rare model 1001N (contains nand > flash rather than nor flash). The kernel config file has a little > comment block at the end that says what to change to build for the = 1001N > model (of which there are probably only a few dozen in the wild). >=20 > As the name implies, the kernel and dts config files are for a model > 1001 dreamplug, but I think the same config will work properly on an > 0901 model as well, at least until we have wifi drivers for both. (As = I > understand it, different wifi chips are the primary difference between > the 0901 and 1001 models.) >=20 > There's a good chance this config would also work properly for a > GuruPlug, or need only minor changes. If anyone has a GuruPlug and > wants to try it, I'd be happy to work without you to figure out if = there > are any changes needed and get them committed too. >=20 > -- Ian >=20 Thanks Ian. I compiled an earlier FreeBSD version for the dreamplug, = that did not support the wireless chip on the dreamplug.=20 According to Linux code that should be a Marvell 8787. Do the current patches take care of the wireless driver? >=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" Johan Henselmans johan@netsense.nl From owner-freebsd-arm@FreeBSD.ORG Mon Jan 28 09:28: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 823132FD for ; Mon, 28 Jan 2013 09:28:24 +0000 (UTC) (envelope-from damjan.marion@gmail.com) Received: from mail-ea0-f169.google.com (mail-ea0-f169.google.com [209.85.215.169]) by mx1.freebsd.org (Postfix) with ESMTP id 0886C3FE for ; Mon, 28 Jan 2013 09:28:23 +0000 (UTC) Received: by mail-ea0-f169.google.com with SMTP id d13so1085206eaa.0 for ; Mon, 28 Jan 2013 01:28:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=DH938XElERl1UKBER16FHpUUwoFH4TE27iRWTRg+6Yo=; b=0zo1t5AcLV4rTZrg9hJyWFnMBCawqbJ1mc5gYS3gvJPMgPfWGuR6IPM2qRA7clPgOv MckO5887D7HhZFMpnrMdeH+vbipwT9aWKMF8fUNRd4XB1WouunuT5TLnW0U49ExW9rH6 oo9BDTxpK4odPtEbR3LkMleRmOBEQZAq48Si/yHmOGK3vQ0tNgKWPRsmAh7TNoq202jc rNBQkJQekoV2Y/CmNgDrbYmgsJJBOyCJYRHaReFugktLBj8fEZ2h+/2Ypb2Uw6cA97h/ S/K6JtGrATH3t2Pb3P78rkoY/5cmvgd5EpkyjgKcAlFvW6WkfP+Wz4q8f9FZB/gqQTlf mtdw== X-Received: by 10.14.225.201 with SMTP id z49mr49624026eep.16.1359365297161; Mon, 28 Jan 2013 01:28:17 -0800 (PST) Received: from ?IPv6:2001:470:72bb::12c? ([2001:470:72bb::12c]) by mx.google.com with ESMTPS id o3sm11418234eem.15.2013.01.28.01.28.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 01:28:16 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Beaglebone and GPIO From: Damjan Marion In-Reply-To: <20130128063436.707fb62d79767d2d8ce0542a@megadrive.org> Date: Mon, 28 Jan 2013 10:28:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <22039243-8515-4245-97D1-48C29CB04F00@gmail.com> References: <20130128044511.86a3d715b11c3346884a7056@megadrive.org> <20130128063436.707fb62d79767d2d8ce0542a@megadrive.org> To: Emmanuel Vadot , Oleksandr Tymoshenko 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: Mon, 28 Jan 2013 09:28:24 -0000 On Jan 28, 2013, at 6:34 AM, Emmanuel Vadot = wrote: > On Mon, 28 Jan 2013 04:45:11 +0100 > Emmanuel Vadot wrote: >=20 >>=20 >> Hello, >>=20 >> I've filled the missings pads on am335x_scm_padconf.c so every GPIO = pin is now accessible (if, of course, they are in GPIO mode). >>=20 >> I've also corrected/enhanced an error on ti_gpio.c, in the = ti_gpio_pin_get function then code was testing if the pin was in output = mode and if it was return EINVAL but in fact it was returning EINVAL if = the pin was in input mode. >> Now the function return the value of the pin despite of it's an input = or output. (seems more logical to me but I'm open to discuss this). >>=20 >> I've also patched gpioctl(1), it now test if the pin is in GPIO mode = (according to the pin mux setting) and print either the value or "Not in = GPIO mode". >>=20 >> Cheers, >=20 > Attached is the coorect patch with the correct case for some signals = names. Hell, Thanks for diffs. padconf stuff is committed. For gpio changes would like to have blessing = from gonzo. Gonzo, are you fine with gpio changes? Damjan From owner-freebsd-arm@FreeBSD.ORG Mon Jan 28 09:36: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 0E02742F for ; Mon, 28 Jan 2013 09:36:24 +0000 (UTC) (envelope-from elbarto@megadrive.org) Received: from mail.megadrive.org (elbarto.org [88.190.215.31]) by mx1.freebsd.org (Postfix) with ESMTP id AF34E666 for ; Mon, 28 Jan 2013 09:36:22 +0000 (UTC) Received: from emeraldas.megadrive.org (cro34-4-82-240-120-88.fbx.proxad.net [82.240.120.88]) (Authenticated sender: elbarto) by mail.megadrive.org (Postfix) with ESMTPA id 342941A6462B; Mon, 28 Jan 2013 10:36:21 +0100 (CET) Date: Mon, 28 Jan 2013 10:36:20 +0100 From: Emmanuel Vadot To: Damjan Marion Subject: Re: Beaglebone and GPIO Message-Id: <20130128103620.1a84ccb548c2dcd21345335d@megadrive.org> In-Reply-To: <22039243-8515-4245-97D1-48C29CB04F00@gmail.com> References: <20130128044511.86a3d715b11c3346884a7056@megadrive.org> <20130128063436.707fb62d79767d2d8ce0542a@megadrive.org> <22039243-8515-4245-97D1-48C29CB04F00@gmail.com> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Mon__28_Jan_2013_10_36_20_+0100_Z+l1JuVatNnCbLvC" 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, 28 Jan 2013 09:36:24 -0000 This is a multi-part message in MIME format. --Multipart=_Mon__28_Jan_2013_10_36_20_+0100_Z+l1JuVatNnCbLvC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 28 Jan 2013 10:28:14 +0100 Damjan Marion wrote: > > On Jan 28, 2013, at 6:34 AM, Emmanuel Vadot wrote: > > > On Mon, 28 Jan 2013 04:45:11 +0100 > > Emmanuel Vadot wrote: > > > >> > >> Hello, > >> > >> I've filled the missings pads on am335x_scm_padconf.c so every GPIO pin is now accessible (if, of course, they are in GPIO mode). > >> > >> I've also corrected/enhanced an error on ti_gpio.c, in the ti_gpio_pin_get function then code was testing if the pin was in output mode and if it was return EINVAL but in fact it was returning EINVAL if the pin was in input mode. > >> Now the function return the value of the pin despite of it's an input or output. (seems more logical to me but I'm open to discuss this). > >> > >> I've also patched gpioctl(1), it now test if the pin is in GPIO mode (according to the pin mux setting) and print either the value or "Not in GPIO mode". > >> > >> Cheers, > > > > Attached is the coorect patch with the correct case for some signals names. > > Hell, Thanks for diffs. > > padconf stuff is committed. For gpio changes would like to have blessing from gonzo. > > Gonzo, are you fine with gpio changes? > > Damjan > Thanks, Attached is the patch for the DTS of the beaglebone so every pins of the headers are setup like the beaglebone SRM said. -- Emmanuel Vadot --Multipart=_Mon__28_Jan_2013_10_36_20_+0100_Z+l1JuVatNnCbLvC Content-Type: text/x-diff; name="beaglebone.dts.patch" Content-Disposition: attachment; filename="beaglebone.dts.patch" Content-Transfer-Encoding: 7bit Index: sys/boot/fdt/dts/beaglebone.dts =================================================================== --- sys/boot/fdt/dts/beaglebone.dts (revision 245942) +++ sys/boot/fdt/dts/beaglebone.dts (working copy) @@ -91,7 +91,58 @@ "MMC0_DAT0", "mmc0_dat0", "input_pullup", "MMC0_DAT1", "mmc0_dat1", "input_pullup", "MMC0_DAT2", "mmc0_dat2", "input_pullup", - "MMC0_DAT3", "mmc0_dat3", "input_pullup"; + "MMC0_DAT3", "mmc0_dat3", "input_pullup", + /* GPIO */ + "ECAP0_IN_PWM0_OUT", "gpio0_7", "input_pulldown", + "GPMC_AD10", "gpio0_26", "input_pulldown", + "GPMC_AD11", "gpio0_27", "input_pulldown", + "GPMC_AD0", "gpio1_0", "input_pulldown", + "GPMC_AD1", "gpio1_1", "input_pulldown", + "GPMC_AD2", "gpio1_2", "input_pulldown", + "GPMC_AD3", "gpio1_3", "input_pulldown", + "GPMC_AD4", "gpio1_4", "input_pulldown", + "GPMC_AD5", "gpio1_5", "input_pulldown", + "GPMC_AD6", "gpio1_6", "input_pulldown", + "GPMC_AD7", "gpio1_7", "input_pulldown", + "GPMC_AD12", "gpio1_12", "input_pulldown", + "GPMC_AD13", "gpio1_13", "input_pulldown", + "GPMC_AD14", "gpio1_14", "input_pulldown", + "GPMC_AD15", "gpio1_15", "input_pulldown", + "GPMC_A0", "gpio1_16", "input_pulldown", + "GPMC_A1", "gpio1_17", "input_pulldown", + "GPMC_A5", "gpio1_21", "output", /* User LED 1 */ + "GPMC_A6", "gpio1_22", "output", /* User LED 2 */ + "GPMC_A7", "gpio1_23", "output", /* User LED 3 */ + "GPMC_A8", "gpio1_24", "output", /* User LED 4 */ + "GPMC_BEn1", "gpio1_28", "input_pulldown", + "GPMC_CSn0", "gpio1_29", "input_pulldown", + "GPMC_CSn1", "gpio1_30", "input_pulldown", + "GPMC_CSn2", "gpio1_31", "input_pulldown", + "GPMC_CLK", "gpio2_1", "input_pulldown", + "LCD_DATA0", "gpio2_6", "input_pulldown", + "LCD_DATA1", "gpio2_7", "input_pulldown", + "LCD_DATA2", "gpio2_8", "input_pulldown", + "LCD_DATA3", "gpio2_9", "input_pulldown", + "LCD_DATA4", "gpio2_10", "input_pulldown", + "LCD_DATA5", "gpio2_11", "input_pulldown", + "LCD_DATA6", "gpio2_12", "input_pulldown", + "LCD_DATA7", "gpio2_13", "input_pulldown", + "LCD_VSYNC", "gpio2_22", "input_pulldown", + "LCD_HSYNC", "gpio2_23", "input_pulldown", + "LCD_PCLK", "gpio2_24", "input_pulldown", + "LCD_AC_BIAS_EN", "gpio2_25", "input_pulldown", + "MCASP0_FSR", "gpio3_19", "input_pulldown", + "MCASP0_AHCLKX", "gpio3_21", "input_pulldown", + /* TIMERs */ + "GPMC_ADVn_ALE", "timer4", "output", + "GPMC_BEn0_CLE", "timer5", "output", + "GPMC_WEn", "timer6", "output", + "GPMC_OEn_REn", "timer7", "output", + /* PWM */ + "GPMC_A2", "ehrpwm1A", "output", + "GPMC_A3", "ehrpwm1B", "output", + "GPMC_AD8", "ehrpwm2A", "output", + "GPMC_AD9", "ehrpwm2B", "output"; }; prcm@44E00000 { --Multipart=_Mon__28_Jan_2013_10_36_20_+0100_Z+l1JuVatNnCbLvC-- From owner-freebsd-arm@FreeBSD.ORG Mon Jan 28 09:49: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 334B3B82 for ; Mon, 28 Jan 2013 09:49:08 +0000 (UTC) (envelope-from damjan.marion@gmail.com) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by mx1.freebsd.org (Postfix) with ESMTP id BF8CC77C for ; Mon, 28 Jan 2013 09:49:07 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id e49so1219382eek.33 for ; Mon, 28 Jan 2013 01:49:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=xqIXfQoqb6DGJpMMBiaAZJ/wIXWO3VZ2nsL1XVDdiSU=; b=XmFZG1AGcztQ5xx7hNY8xDyAJyLkCRO5fpuogx/rbLONVZGZjZmXwap9HK2MtUfsVl CHxPad4S2CNvP8F6onBSyuOYPCnOY1l7jziQalitFIuGSBoSgEfhhcMfvsnBVnUpwytG PNVYtA7whbfeQSTbslgwSJKPVDFcQutpa2GReacmTnypSifsmgrm8LIbPjSZ7ZqBkZxe yEwkdXCqkZDmPcCE0RPkWHOAFUmhrZYiw96VR0VpROXe8l7BwDfCjstAAbBHnLPv+/48 UOooHRl6ZPEOcMIc1VWe9dsKLKmDZ9olHjRIrIrc7OjphuTARPgLfwJ+d1AccjKC43xt AHmQ== X-Received: by 10.14.204.198 with SMTP id h46mr50400997eeo.1.1359366541113; Mon, 28 Jan 2013 01:49:01 -0800 (PST) Received: from ?IPv6:2001:470:72bb::12c? ([2001:470:72bb::12c]) by mx.google.com with ESMTPS id q5sm15236355eep.11.2013.01.28.01.48.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 01:49:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Beaglebone and GPIO From: Damjan Marion In-Reply-To: <20130128103620.1a84ccb548c2dcd21345335d@megadrive.org> Date: Mon, 28 Jan 2013 10:48:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1ECB35BA-5D67-4F95-9E1D-2380002F1C26@gmail.com> References: <20130128044511.86a3d715b11c3346884a7056@megadrive.org> <20130128063436.707fb62d79767d2d8ce0542a@megadrive.org> <22039243-8515-4245-97D1-48C29CB04F00@gmail.com> <20130128103620.1a84ccb548c2dcd21345335d@megadrive.org> To: Emmanuel Vadot 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: Mon, 28 Jan 2013 09:49:08 -0000 On Jan 28, 2013, at 10:36 AM, Emmanuel Vadot = wrote: >=20 > Thanks, >=20 > Attached is the patch for the DTS of the beaglebone so every pins of = the headers are setup like the beaglebone SRM said. Committed. Thanks.= From owner-freebsd-arm@FreeBSD.ORG Mon Jan 28 10:32:40 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 53D3272B for ; Mon, 28 Jan 2013 10:32:40 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by mx1.freebsd.org (Postfix) with ESMTP id 1AC4F9D8 for ; Mon, 28 Jan 2013 10:32:39 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id v28so1217148qcm.11 for ; Mon, 28 Jan 2013 02:32:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=nOnyQ28YIWNSACJz+wjIDEqJAkAXKeT8vmUqyIRF5e8=; b=BD1Iy3XZG2oprO0fFzCNakbgEXBgWUsFdJmzkwActfV9Gk+C6PDtVB7LGsI9YtYDgr q2N0Kb0uqn/iwr0GzXZexUsHwqSmYqQe5kEcpKewmvbL0GlG+axXr8GzluYMWVPjQT/z jBSON82uREVgFw7njhnQomPfdLR1a92S0GedV63bJxK8xqdAqgv7XTlAxKCNgTALOuFv eoUEWa9tROFReP/L1APxaK+VHPNHQXT7oEXkkkDgq80Dj/zDQlzSjtl0w7CG4m0S20ru NwoY1W2XMEhDTXKRGczOg5sPd7rJAjdmRVcEux5tR0yNgla/MZQYeNdqywktrwMu9Dex yx0w== MIME-Version: 1.0 X-Received: by 10.49.106.71 with SMTP id gs7mr17930747qeb.21.1359369153548; Mon, 28 Jan 2013 02:32:33 -0800 (PST) Received: by 10.49.2.72 with HTTP; Mon, 28 Jan 2013 02:32:33 -0800 (PST) In-Reply-To: <20130127150429.5a232f66@bender> References: <20130127150429.5a232f66@bender> Date: Mon, 28 Jan 2013 18:32:33 +0800 Message-ID: Subject: Re: FreeBSD ARM EABI in head From: Alie Tan To: Andrew Turner X-Gm-Message-State: ALoCoQmsa9dj0CHUkFO3b2p77k3s0oD8Jh020yWQfyhGPOEsC9pr1BwmddnVebLVYoOsU5CGdXhs Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 10:32:40 -0000 Tried building kernel-toolchain, world and kernel with -DWITH_ARM_EABI and gcc4.2 my Pi keeps rebooting after uboot, strange... hardly for rme to debug it since it happens really fast. Regards, Alie T On Sun, Jan 27, 2013 at 10:04 AM, Andrew Turner wrote: > I have finished merging in my changes from the ARM EABI project branch > into head. I would appreciate it if people would be able to test it. > > To build it you will need a checkout of head no earlier than r245942. > You can then run the normal build procedure with WITH_ARM_EABI set, for > example: > make TARGET_ARCH=armv6 -DWITH_ARM_EABI buildworld > make TARGET_ARCH=armv6 -DWITH_ARM_EABI buildkernel TARGET=RPI-B > > If your kernel config includes DDB you will need to set WITH_ARM_EABI > when building your kernel to get backtrace support. > > I have tested the ARM EABI branch on arm and armv6 and the head merge on > armv6 and expect these two to mostly work. As I have no access to any > big-endian ARM hardware I have been unable to test there. > > There are currently three known issues: > * No clang support - this should be fixed soon, I'm waiting on another > patch to go into head first. > * No gdb - I'm testing a fix for this. > * No bind utils - for some reason the bind tools, e.g. dig, segfault in > the sig_wait syscall. > > Andrew > _______________________________________________ > 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 Jan 28 11:06:41 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4599A8E5 for ; Mon, 28 Jan 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 37E7ECCA for ; Mon, 28 Jan 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 r0SB6fMf034491 for ; Mon, 28 Jan 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 r0SB6eTl034489 for freebsd-arm@FreeBSD.org; Mon, 28 Jan 2013 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 Jan 2013 11:06:40 GMT Message-Id: <201301281106.r0SB6eTl034489@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, 28 Jan 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/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 17 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Jan 28 11:15: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 992EC886; Mon, 28 Jan 2013 11:15:13 +0000 (UTC) (envelope-from george@m5p.com) Received: from mailhost.m5p.com (ip-2-1-0-2.r03.asbnva02.us.ce.gin.ntt.net [IPv6:2001:418:0:5000::16]) by mx1.freebsd.org (Postfix) with ESMTP id D8000F50; Mon, 28 Jan 2013 11:15:12 +0000 (UTC) Received: from wonderland.m5p.com (localhost [IPv6:::1]) by mailhost.m5p.com (8.14.5/8.14.5) with ESMTP id r0SBF5Hw011995; Mon, 28 Jan 2013 06:15:10 -0500 (EST) (envelope-from george@m5p.com) Message-ID: <51065DB9.4090406@m5p.com> Date: Mon, 28 Jan 2013 06:15:05 -0500 From: George Mitchell User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120908 Thunderbird/15.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org Subject: Thanks for the Raspberry Pi! Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 10.100.0.3 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (mailhost.m5p.com [IPv6:::1]); Mon, 28 Jan 2013 06:15:10 -0500 (EST) 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, 28 Jan 2013 11:15:13 -0000 Today is my birthday, and the best present I have is that my Raspberry Pi is running FreeBSD plus CUPS and acting as a print server for the FreeBSD machines (and one Windoze machine) on my home network. My sincere thanks go to everybody who helped bring FreeBSD to the ARM and specifically to the Pi. It would be awesome if we could get ARM promoted to Tier 1 support this year. I'm interested in working on a driver for the pulse-width modulation audio output on the Pi, and I have the Broadcom document describing how it works. What are the chances I could base such a driver on some existing FreeBSD audio driver? -- George Mitchell From owner-freebsd-arm@FreeBSD.ORG Mon Jan 28 13:26:50 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 A4D484EB for ; Mon, 28 Jan 2013 13:26:50 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 6434AA8D for ; Mon, 28 Jan 2013 13:26:50 +0000 (UTC) Received: from terran (unknown [192.168.99.1]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id C1CA1C4936; Mon, 28 Jan 2013 15:26:42 +0200 (EET) Date: Mon, 28 Jan 2013 15:28:28 +0200 From: Aleksandr Rybalko To: Damjan Marion Subject: Re: Beaglebone and GPIO Message-Id: <20130128152828.f21d71e76634fda6aa059325@ddteam.net> In-Reply-To: <22039243-8515-4245-97D1-48C29CB04F00@gmail.com> References: <20130128044511.86a3d715b11c3346884a7056@megadrive.org> <20130128063436.707fb62d79767d2d8ce0542a@megadrive.org> <22039243-8515-4245-97D1-48C29CB04F00@gmail.com> X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.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, 28 Jan 2013 13:26:50 -0000 On Mon, 28 Jan 2013 10:28:14 +0100 Damjan Marion wrote: > > On Jan 28, 2013, at 6:34 AM, Emmanuel Vadot wrote: > > > On Mon, 28 Jan 2013 04:45:11 +0100 > > Emmanuel Vadot wrote: > > > >> > >> Hello, > >> > >> I've filled the missings pads on am335x_scm_padconf.c so every GPIO pin is now accessible (if, of course, they are in GPIO mode). > >> > >> I've also corrected/enhanced an error on ti_gpio.c, in the ti_gpio_pin_get function then code was testing if the pin was in output mode and if it was return EINVAL but in fact it was returning EINVAL if the pin was in input mode. > >> Now the function return the value of the pin despite of it's an input or output. (seems more logical to me but I'm open to discuss this). > >> > >> I've also patched gpioctl(1), it now test if the pin is in GPIO mode (according to the pin mux setting) and print either the value or "Not in GPIO mode". > >> > >> Cheers, > > > > Attached is the coorect patch with the correct case for some signals names. > > Hell, Thanks for diffs. > > padconf stuff is committed. For gpio changes would like to have blessing from gonzo. > > Gonzo, are you fine with gpio changes? > > Damjan > > _______________________________________________ > 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" Hi! No-no-no, guys, please don't do that. I'm working on Freescale i.MX5 support, and it have way to read pin input even if another controller drives that pin (If I understand doc correct :) ). Thanks! WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Mon Jan 28 13:36: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 5DB546A4; Mon, 28 Jan 2013 13:36:02 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 1E542AE2; Mon, 28 Jan 2013 13:36:01 +0000 (UTC) Received: from terran (unknown [192.168.99.1]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 1763BC493C; Mon, 28 Jan 2013 15:36:01 +0200 (EET) Date: Mon, 28 Jan 2013 15:37:47 +0200 From: Aleksandr Rybalko To: George Mitchell Subject: Re: Thanks for the Raspberry Pi! Message-Id: <20130128153747.cf3516ee1977538268584e48@ddteam.net> In-Reply-To: <51065DB9.4090406@m5p.com> References: <51065DB9.4090406@m5p.com> X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, freebsd-embedded@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, 28 Jan 2013 13:36:02 -0000 On Mon, 28 Jan 2013 06:15:05 -0500 George Mitchell wrote: > Today is my birthday, and the best present I have is that my Raspberry > Pi is running FreeBSD plus CUPS and acting as a print server for the > FreeBSD machines (and one Windoze machine) on my home network. My > sincere thanks go to everybody who helped bring FreeBSD to the ARM and > specifically to the Pi. It would be awesome if we could get ARM > promoted to Tier 1 support this year. > > I'm interested in working on a driver for the pulse-width modulation > audio output on the Pi, and I have the Broadcom document describing how > it works. What are the chances I could base such a driver on some > existing FreeBSD audio driver? -- George Mitchell > _______________________________________________ > 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" Hi George, Think you can base it on any simplest one. Main difference in the clock, so if you want 8bit resolution at 44100Hz, you will need to set pwm clock to 2^8 * 44100 = 11289600, and then just at freq 44100Hz program duty cycle for current sample. Problem only in clocks, because for 16bits you must set 2^16 * 44100 = 2890137600, so it is almost 3GHz :-D Good luck! WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Mon Jan 28 14:01:39 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 83834FE for ; Mon, 28 Jan 2013 14:01:39 +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 4259ED18 for ; Mon, 28 Jan 2013 14:01:19 +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 r0SE1CrU045846 for ; Mon, 28 Jan 2013 07:01:18 -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 r0SE0n1u020850; Mon, 28 Jan 2013 07:00:49 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: DreamPlug support committed From: Ian Lepore To: Johan Henselmans In-Reply-To: <13FCC2A8-A394-491A-815B-CDEE6DA95237@netsense.nl> References: <1359306117.93359.29.camel@revolution.hippie.lan> <13FCC2A8-A394-491A-815B-CDEE6DA95237@netsense.nl> Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Jan 2013 07:00:48 -0700 Message-ID: <1359381648.93359.63.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 28 Jan 2013 14:01:39 -0000 On Mon, 2013-01-28 at 09:28 +0100, Johan Henselmans wrote: > On 27 jan. 2013, at 18:01, Ian Lepore wrote: > > > FYI, I've committed the last missing bits of support for the DreamPlug, > > so as of r245955 it's now possible to build for dreamplug without > > needing any extra patches, using stock kernel config DREAMPLUG-1001. I > > also included the .dts file for the rare model 1001N (contains nand > > flash rather than nor flash). The kernel config file has a little > > comment block at the end that says what to change to build for the 1001N > > model (of which there are probably only a few dozen in the wild). > > > > As the name implies, the kernel and dts config files are for a model > > 1001 dreamplug, but I think the same config will work properly on an > > 0901 model as well, at least until we have wifi drivers for both. (As I > > understand it, different wifi chips are the primary difference between > > the 0901 and 1001 models.) > > > > There's a good chance this config would also work properly for a > > GuruPlug, or need only minor changes. If anyone has a GuruPlug and > > wants to try it, I'd be happy to work without you to figure out if there > > are any changes needed and get them committed too. > > > > -- Ian > > > > Thanks Ian. I compiled an earlier FreeBSD version for the dreamplug, that did not support the wireless chip on the dreamplug. > > According to Linux code that should be a Marvell 8787. > > Do the current patches take care of the wireless driver? Unfortunately, they don't. I'm not really set up to work on a wifi driver; I don't have the gear or the knowledge. I'd be happy to work with someone else who wants to work on it though, to make sure the results get committed. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Jan 28 14:21:27 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 796A856B for ; Mon, 28 Jan 2013 14:21:27 +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 88CA2DF9 for ; Mon, 28 Jan 2013 14:20: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 r0SEKr58046041 for ; Mon, 28 Jan 2013 07:20:54 -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 r0SEKVvh020866; Mon, 28 Jan 2013 07:20:31 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Beaglebone and GPIO From: Ian Lepore To: Aleksandr Rybalko In-Reply-To: <20130128152828.f21d71e76634fda6aa059325@ddteam.net> References: <20130128044511.86a3d715b11c3346884a7056@megadrive.org> <20130128063436.707fb62d79767d2d8ce0542a@megadrive.org> <22039243-8515-4245-97D1-48C29CB04F00@gmail.com> <20130128152828.f21d71e76634fda6aa059325@ddteam.net> Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Jan 2013 07:20:31 -0700 Message-ID: <1359382831.93359.65.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: Mon, 28 Jan 2013 14:21:27 -0000 On Mon, 2013-01-28 at 15:28 +0200, Aleksandr Rybalko wrote: > On Mon, 28 Jan 2013 10:28:14 +0100 > Damjan Marion wrote: > > > > > On Jan 28, 2013, at 6:34 AM, Emmanuel Vadot wrote: > > > > > On Mon, 28 Jan 2013 04:45:11 +0100 > > > Emmanuel Vadot wrote: > > > > > >> > > >> Hello, > > >> > > >> I've filled the missings pads on am335x_scm_padconf.c so every GPIO pin is now accessible (if, of course, they are in GPIO mode). > > >> > > >> I've also corrected/enhanced an error on ti_gpio.c, in the ti_gpio_pin_get function then code was testing if the pin was in output mode and if it was return EINVAL but in fact it was returning EINVAL if the pin was in input mode. > > >> Now the function return the value of the pin despite of it's an input or output. (seems more logical to me but I'm open to discuss this). > > >> > > >> I've also patched gpioctl(1), it now test if the pin is in GPIO mode (according to the pin mux setting) and print either the value or "Not in GPIO mode". > > >> > > >> Cheers, > > > > > > Attached is the coorect patch with the correct case for some signals names. > > > > Hell, Thanks for diffs. > > > > padconf stuff is committed. For gpio changes would like to have blessing from gonzo. > > > > Gonzo, are you fine with gpio changes? > > > > Damjan > > > > _______________________________________________ > > 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" > > Hi! > > No-no-no, guys, please don't do that. I'm working on Freescale i.MX5 > support, and it have way to read pin input even if another controller > drives that pin (If I understand doc correct :) ). > > Thanks! > > WBW The Atmel gpio/mpp pins are like that too, you can always read and trigger interrupts on a pin even when it's assigned to peripherals. It's important sometimes for working around broken peripherals. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Jan 28 19:50: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 156D0D6C for ; Mon, 28 Jan 2013 19:50:42 +0000 (UTC) (envelope-from torfinn.ingolfsen@getmail.no) Received: from smtp.getmail.no (smtp.getmail.no [84.208.15.66]) by mx1.freebsd.org (Postfix) with ESMTP id AF40C7BB for ; Mon, 28 Jan 2013 19:50:41 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from get-mta-scan01.get.basefarm.net ([10.5.16.4]) by get-mta-out01.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0MHC00EN5PSG3E50@get-mta-out01.get.basefarm.net> for freebsd-arm@FreeBSD.org; Mon, 28 Jan 2013 20:50:40 +0100 (MET) Received: from get-mta-scan01.get.basefarm.net (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 130A9179BBD3_106D690B for ; Mon, 28 Jan 2013 19:50:40 +0000 (GMT) Received: from kg-v2.kg4.no (cm-84.215.134.159.getinternet.no [84.215.134.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by get-mta-scan01.get.basefarm.net (Sophos Email Appliance) with ESMTPSA id E57DD17A0A62_106D68FF for ; Mon, 28 Jan 2013 19:50:39 +0000 (GMT) Date: Mon, 28 Jan 2013 20:50:38 +0100 From: Torfinn Ingolfsen To: freebsd-arm@FreeBSD.org Subject: DockStar status? Message-id: <20130128205038.0e4eb52ba9c06c4de22f8cef@getmail.no> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.3) 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, 28 Jan 2013 19:50:42 -0000 Hello, Nice with so many good things happening on the ARM front in FreeBSD. Thanks! What is the status of DockStar when it comes to FreeBSD 9.0 or 9.1? I see that arm/162159[1] is still open, does it apply to FreeBSD 9.1 too? References: 1) http://www.freebsd.org/cgi/query-pr.cgi?pr=arm/162159 -- Torfinn Ingolfsen From owner-freebsd-arm@FreeBSD.ORG Mon Jan 28 23:54: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 645831BA for ; Mon, 28 Jan 2013 23:54:04 +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 09808813 for ; Mon, 28 Jan 2013 23:54:03 +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 1Tzy0J-0001bc-6W; Mon, 28 Jan 2013 15:20:45 -0800 Message-ID: <510707C5.1020905@bluezbox.com> Date: Mon, 28 Jan 2013 15:20:37 -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: George Mitchell Subject: Re: Thanks for the Raspberry Pi! References: <51065DB9.4090406@m5p.com> In-Reply-To: <51065DB9.4090406@m5p.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/28/2013 3:15 AM, George Mitchell wrote: > Today is my birthday, and the best present I have is that my Raspberry > Pi is running FreeBSD plus CUPS and acting as a print server for the > FreeBSD machines (and one Windoze machine) on my home network. My > sincere thanks go to everybody who helped bring FreeBSD to the ARM and > specifically to the Pi. It would be awesome if we could get ARM > promoted to Tier 1 support this year Happy birthday. George! :) [...] 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: 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, 28 Jan 2013 23:54:04 -0000 On 1/28/2013 3:15 AM, George Mitchell wrote: > Today is my birthday, and the best present I have is that my Raspberry > Pi is running FreeBSD plus CUPS and acting as a print server for the > FreeBSD machines (and one Windoze machine) on my home network. My > sincere thanks go to everybody who helped bring FreeBSD to the ARM and > specifically to the Pi. It would be awesome if we could get ARM > promoted to Tier 1 support this year Happy birthday. George! :) > I'm interested in working on a driver for the pulse-width modulation > audio output on the Pi, and I have the Broadcom document describing how > it works. What are the chances I could base such a driver on some > existing FreeBSD audio driver? I do not think there is PWM-based audio driver. I was trying to implement VCHIQ-based audio driver[1] but ran into some locking issues with VCHIQ driver and put the project on hold. You can use it as a skeleton for your audio driver though. Also as far as I can see from spec PWM utilizes DMA so you might want to give a try this driver[2]. It's reworked version of Daisuke Aoyama's patch. Usage pattern would be something like code below. In real driver you'd want to use bus_dma operations though, not direct calls to cache ops. [1] http://people.freebsd.org/~gonzo/arm/rpi/vchiq_audio.tar.gz [2] http://people.freebsd.org/~gonzo/arm/patches/rpi_dma.diff int dma_started = 0; int dma_set = 0; int dma = 0; void *page1 = NULL; void *page2 = NULL; vm_paddr_t pa1; vm_paddr_t pa2; static uint8_t pattern = 0xa5; static void dma_intr(int ch, void *arg) { uint32_t *p1, *p2; printf("dma_intr: %d, %p\n", ch, arg); cpu_dcache_inv_range((vm_offset_t)page2, PAGE_SIZE); cpu_l2cache_inv_range((vm_offset_t)page2, PAGE_SIZE); p1 = (void*)page1; p2 = (void*)page2; printf("%08x vs %08x\n", *p1, *p2); for (int i = 0; i < PAGE_SIZE/4; i++) { if (p1[i] != p2[i]) { printf("diff at %d\n", i); break; } } dma_started = 0; } static int start_dma_test() { return (0); if (!dma_set) { printf("Setting DMA\n"); dma_set = 1; page1 = contigmalloc(PAGE_SIZE, M_DEVBUF, M_NOWAIT, 0ul, 0xfffffffful, PAGE_SIZE, 0); page2 = contigmalloc(PAGE_SIZE, M_DEVBUF, M_NOWAIT, 0ul, 0xfffffffful, PAGE_SIZE, 0); pa1 = vtophys(page1); pa2 = vtophys(page2); printf("page1 = %p -> %p\n", page1, (void*)pa1); printf("page2 = %p -> %p\n", page2, (void*)pa1); dma = bcm_dma_allocate(BCM_DMA_CH_ANY); printf("Allocated channel: %d\n", dma); bcm_dma_setup_intr(dma, dma_intr, NULL); bcm_dma_setup_src(dma, 0, 1); bcm_dma_setup_dst(dma, 0, 1); } if (!dma_started) { memset(page1, pattern, PAGE_SIZE); memset(page2, 0x00, PAGE_SIZE); pattern++; cpu_dcache_wbinv_range((vm_offset_t)page1, PAGE_SIZE); cpu_l2cache_wbinv_range((vm_offset_t)page1, PAGE_SIZE); cpu_dcache_wbinv_range((vm_offset_t)page2, PAGE_SIZE); cpu_l2cache_wbinv_range((vm_offset_t)page2, PAGE_SIZE); printf("DMA started!\n"); bcm_dma_start(dma, pa1, pa2, PAGE_SIZE); } dma_started = 1; return (0); } From owner-freebsd-arm@FreeBSD.ORG Tue Jan 29 03:31: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 AA9643AA for ; Tue, 29 Jan 2013 03:31:00 +0000 (UTC) (envelope-from jesse@tummy.com) Received: from mail2.tummy.com (mail.tummy.com [198.49.126.6]) by mx1.freebsd.org (Postfix) with ESMTP id 89ACA23E for ; Tue, 29 Jan 2013 03:31:00 +0000 (UTC) Received: by mail2.tummy.com (Postfix, from userid 10) id BBA501BA4C2; Mon, 28 Jan 2013 20:21:56 -0700 (MST) Received: from jesse.tummy.com (localhost.localdomain [127.0.0.1]) by jesse.tummy.com (Postfix) with ESMTP id 7336A139AB; Mon, 28 Jan 2013 20:21:32 -0700 (MST) Message-ID: <5107403C.5070206@tummy.com> Date: Mon, 28 Jan 2013 20:21:32 -0700 From: Jesse Griffin Organization: tummy.com, ltd. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12 MIME-Version: 1.0 To: Oleksandr Tymoshenko Subject: Re: Nginx Build Fails on Compiling pcre References: <50F74150.1080600@tummy.com> <0C39E32B-32D2-4FE6-A8D4-168C83F18AF0@bluezbox.com> In-Reply-To: <0C39E32B-32D2-4FE6-A8D4-168C83F18AF0@bluezbox.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Hashcash: 1:26:130129:freebsd-arm@freebsd.org::a1f+zsTK2ogFEODj:00000000000000 000000000000000000000001NauR 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, 29 Jan 2013 03:31:00 -0000 On 01/16/2013 10:24 PM, Oleksandr Tymoshenko wrote: > > On 2013-01-16, at 4:09 PM, Jesse Griffin wrote: > >> Hello, >> >> I'm not sure if this is the correct list, but the only reason why I did the >> following was to test FreeBSD on the Pi. >> >> I setup http://www.peach.ne.jp/archives/rpi/freebsd-pi-clang-20130115.img.gz on >> my Pi and I tried building several ports to see what I got. Most of them >> completed okay, but the Nginx build fails when it tries to compile >> /usr/ports/devel/pcre. >> >> Building Nginx on an i386 FreeBSD 10 CURRENT works. >> >> Below is the output: >> >> root@raspberry-pi:/usr/ports/www/nginx # make install clean >> ===> nginx-1.2.6,1 depends on shared library: pcre - not found >> ===> Verifying install for pcre in /usr/ports/devel/pcre >> ===> Building for pcre-8.32 >> make all-am >> CCLD pcretest >> ./.libs/libpcre.so: undefined reference to `__clear_cache' >> cc: error: linker command failed with exit code 1 (use -v to see invocation) > > I believe it might be clang/ARM issue. gcc compiles test application with > __clear_cache just fine on my ARM. Both clang and gcc compile the same > application on x86_64. So some bits might be missing in clang's std library > for ARM. This was my suspicion as well. I just tested building Nginx on freebsd-pi-r245446.img and it worked as expected. Thank you, Jesse Griffin tummy.com, ltd. From owner-freebsd-arm@FreeBSD.ORG Tue Jan 29 06:49:27 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 16CD3C87 for ; Tue, 29 Jan 2013 06:49:27 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 7F81BABF for ; Tue, 29 Jan 2013 06:49:25 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id r0T6nICw015772 for ; Tue, 29 Jan 2013 15:49:18 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili17) with ESMTP id r0T6nJ323173 for ; Tue, 29 Jan 2013 15:49:19 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi16) id r0T6nJmJ019794 for arm@freebsd.org; Tue, 29 Jan 2013 15:49:19 +0900 Received: from localhost by lomi16.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id r0T6nIYP019754 for ; Tue, 29 Jan 2013 15:49:18 +0900 Date: Tue, 29 Jan 2013 15:49:17 +0900 (JST) Message-Id: <20130129.154917.323234014148633556.okuno.kohji@jp.panasonic.com> To: arm@freebsd.org Subject: I-cache maintenance fault in armv6 and armv7. From: Kohji Okuno Organization: Panasonic Corporation X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) 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, 29 Jan 2013 06:49:27 -0000 Hi, I think that we need following linux fix. Would you check this? Regards, Kohji Okuno << src/sys/arm/arm/trap.c >> +#if defined(CPU_ARMV6) || defined(CPU_ARMV7) || defined(CPU_CORTEXA) + {NULL, "I-cache maintenance fault"}, +#else {dab_buserr, "External Linefetch Abort (S)"}, +#endif << linux commit >> >From 8c0b742ca7a7d21de0ddc87eda6ef0b282e4de18 Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov" Date: Sat, 15 May 2010 09:57:06 +0100 Subject: [PATCH] ARM: 6134/1: Handle instruction cache maintenance fault properly Between "clean D line..." and "invalidate I line" operations in v7_coherent_user_range(), the memory page may get swapped out. And the fault on "invalidate I line" could not be properly handled causing the oops. In ARMv6 "external abort on linefetch" replaced by "instruction cache maintenance fault". Let's handle it as translation fault. It fixes the issue. I'm not sure if it's reasonable to check arch version in run-time. Let's do it in compile time for now. Reviewed-by: Catalin Marinas Signed-off-by: Siarhei Siamashka Signed-off-by: Kirill A. Shutemov Signed-off-by: Russell King --- arch/arm/mm/fault.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c index 9d40c34..92f5801 100644 --- a/arch/arm/mm/fault.c +++ b/arch/arm/mm/fault.c @@ -463,7 +463,12 @@ static struct fsr_info { { do_bad, SIGILL, BUS_ADRALN, "alignment exception" }, { do_bad, SIGKILL, 0, "terminal exception" }, { do_bad, SIGILL, BUS_ADRALN, "alignment exception" }, +/* Do we need runtime check ? */ +#if __LINUX_ARM_ARCH__ < 6 { do_bad, SIGBUS, 0, "external abort on linefetch" }, +#else + { do_translation_fault, SIGSEGV, SEGV_MAPERR, "I-cache maintenance fault" }, +#endif { do_translation_fault, SIGSEGV, SEGV_MAPERR, "section translation fault" }, { do_bad, SIGBUS, 0, "external abort on linefetch" }, { do_page_fault, SIGSEGV, SEGV_MAPERR, "page translation fault" }, -- 1.7.7.6 From owner-freebsd-arm@FreeBSD.ORG Tue Jan 29 06:52: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 0D52ED45 for ; Tue, 29 Jan 2013 06:52: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 CC36CAE3 for ; Tue, 29 Jan 2013 06:52:41 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r0T6qZ1D038671 for freebsd-arm@freebsd.org; Tue, 29 Jan 2013 06:52:35 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 3dnf4vitmsd7gsn2itpvy8rhys; for freebsd-arm@freebsd.org; Tue, 29 Jan 2013 06:52:35 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: CfT: Revised CPSW driver for BeagleBone Date: Mon, 28 Jan 2013 22:52:33 -0800 Message-Id: <3F0C7436-3CC5-4B57-A4CB-431D83AFCAFE@freebsd.org> To: freebsd-arm 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: Tue, 29 Jan 2013 06:52:42 -0000 I have another iteration of the BeagleBone network driver almost ready to commit and would appreciate any feedback. The code is on github; you can browse it at https://github.com/kientzle/cpsw or download a snapshot from: https://github.com/kientzle/cpsw/archive/master.zip Just copy the three if_cpsw* files to sys/arm/ti/cpsw/ and rebuild. Here are the improvements since my last update: * Finally (!!) fixed the regular watchdog timeouts (turned out to be misconfigured Ethernet flow control) * TX performance improvements: = Eliminated TX interrupt = queue fragmented packets directly without defragmenting * Debugging: Connected up the "Host Error" interrupt to print detailed traces whenever the controller gets confused. * Debugging: "sysctl dev.cpsw" gives a variety of statistics, including packet error counters, queue and watchdog statistics Unless something shows up, I expect to commit it to FreeBSD-CURRENT this coming weekend. Tim From owner-freebsd-arm@FreeBSD.ORG Tue Jan 29 10:29:39 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 C2168165 for ; Tue, 29 Jan 2013 10:29:39 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by mx1.freebsd.org (Postfix) with ESMTP id 8897DE04 for ; Tue, 29 Jan 2013 10:29:39 +0000 (UTC) Received: by mail-qe0-f53.google.com with SMTP id 1so93921qee.26 for ; Tue, 29 Jan 2013 02:29:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=wxaZcV5mYJVXlaIBgKIXeiuGB9yyO30rajklo2Rk7MY=; b=JUTJ/hGKwaeNCqpsateOXdDz968RjDMxWXNy74AcQeB5TkWeNZYwJKFnVZ00yEeVrI TBCNcE/Etov0rNJIbcfh2XV50UQw+p73AAe7i+UXW9f7z4u4B9TEvGUvn3hpWYudPzvd IVa8pxGZgI6w5TltoaZIofVDuZ4ra3yrmWtXgNJFZU009DMDFKGnl4HatA5VugAD31ww 2spdoH7sCsf7XffOzdO+tI813pxSHu7vee3Sc+fzOfPxbHuNmWzvJiTFF4GCXooejnIz AF6qdlxrMYemwvX0q1+FOXtSntQQattTE5scOO3f48sNgL1M5FtimJ5B9aNArr3QSXmI Jo0A== MIME-Version: 1.0 X-Received: by 10.49.106.71 with SMTP id gs7mr580344qeb.21.1359455378246; Tue, 29 Jan 2013 02:29:38 -0800 (PST) Received: by 10.49.2.72 with HTTP; Tue, 29 Jan 2013 02:29:38 -0800 (PST) In-Reply-To: <20130129232528.4636d91e@bender> References: <20130127150429.5a232f66@bender> <20130129232528.4636d91e@bender> Date: Tue, 29 Jan 2013 18:29:38 +0800 Message-ID: Subject: Re: FreeBSD ARM EABI in head From: Alie Tan To: Andrew Turner X-Gm-Message-State: ALoCoQktZ6u/AoL0Fvjt1wEABZA3W8JkEnWesKA5LEJyHUqYIxRsfX+aJXdiU8b+C8d6zOeN2Cyg Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 10:29:39 -0000 Fyi, I just tried my new image a minute ago but without -DWITH_ARM_EABI while building kernel-toolchain and it works!!! Regards, Alie T On Tue, Jan 29, 2013 at 6:25 PM, Andrew Turner wrote: > On Mon, 28 Jan 2013 18:32:33 +0800 > Alie Tan wrote: > > > Tried building kernel-toolchain, world and kernel with > > -DWITH_ARM_EABI and gcc4.2 > > > > my Pi keeps rebooting after uboot, strange... hardly for rme to debug > > it since it happens really fast. > > I'll have a look into it. For now you can replace the EABI ubldr with > a known good version as it is only used to load the kernel. > > Andrew > From owner-freebsd-arm@FreeBSD.ORG Tue Jan 29 10:37:35 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 BC45C3CA for ; Tue, 29 Jan 2013 10:37:35 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by mx1.freebsd.org (Postfix) with ESMTP id 703FEE80 for ; Tue, 29 Jan 2013 10:37:35 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id v28so110296qcm.25 for ; Tue, 29 Jan 2013 02:37:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=nYZ/472SIkuv3HNaahIFJJM2lcOpz1aTZYU9puR7Hew=; b=aqHBzpcyC4F+o2r+UdKn5DusPJ/jEZorJhXrBj+/x95LoQj3tl2F1ONhFyJxdMW+iO vBRSqQKNBtp/pX5TBncMZlfzdJ32GJmDjvgF2Q4dkfldInjoFmQiSxSq8h9cWNtzUtfC WR3s2z5KTgCqwcEkgXQfHiLl/lTRK0Zrlkj1jBpd2W62U8IbiX65DRRs1rJDCS8aufik WJci3DPUwZImoqZBRtZNht6QTRn007uh1BXUjclqkTgrfgLXUIgm7+L6XQCdqkqUX89b /kOr5i6Mq6mYgYF94Gwl2d8SUbLxAvH985BZvtZ+PAs57fIIP2H7RMzL9DVfQ6YOVjPH mP7g== MIME-Version: 1.0 X-Received: by 10.229.252.208 with SMTP id mx16mr120347qcb.37.1359455849302; Tue, 29 Jan 2013 02:37:29 -0800 (PST) Received: by 10.49.2.72 with HTTP; Tue, 29 Jan 2013 02:37:29 -0800 (PST) In-Reply-To: References: <20130127150429.5a232f66@bender> <20130129232528.4636d91e@bender> Date: Tue, 29 Jan 2013 18:37:29 +0800 Message-ID: Subject: Re: FreeBSD ARM EABI in head From: Alie Tan To: Andrew Turner X-Gm-Message-State: ALoCoQmsv7Vm8VYfAl9CqVFw0dslIHg7ob57KJeCM053ztmNf1Fpr4BxzkvlButtd+mYFAHbAgq+ Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 10:37:35 -0000 Btw here is the kernel tar ball: http://snakeorladder.com/rpi-kernel-armeabi.tar.gz On Tue, Jan 29, 2013 at 6:29 PM, Alie Tan wrote: > Fyi, I just tried my new image a minute ago but without -DWITH_ARM_EABI > while building kernel-toolchain and it works!!! > > Regards, > Alie T > > > On Tue, Jan 29, 2013 at 6:25 PM, Andrew Turner wrote: > >> On Mon, 28 Jan 2013 18:32:33 +0800 >> Alie Tan wrote: >> >> > Tried building kernel-toolchain, world and kernel with >> > -DWITH_ARM_EABI and gcc4.2 >> > >> > my Pi keeps rebooting after uboot, strange... hardly for rme to debug >> > it since it happens really fast. >> >> I'll have a look into it. For now you can replace the EABI ubldr with >> a known good version as it is only used to load the kernel. >> >> Andrew >> > > From owner-freebsd-arm@FreeBSD.ORG Tue Jan 29 10:41: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 9D399459 for ; Tue, 29 Jan 2013 10:41:02 +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 66B80EAE for ; Tue, 29 Jan 2013 10:41:02 +0000 (UTC) Received: from mxin3-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MHD008RNUB0L540@smtp3.clear.net.nz> for freebsd-arm@freebsd.org; Tue, 29 Jan 2013 23:25:55 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO bender) ([202.0.48.19]) by smtpin32.paradise.net.nz with ESMTP; Tue, 29 Jan 2013 23:25:55 +1300 Date: Tue, 29 Jan 2013 23:25:28 +1300 From: Andrew Turner Subject: Re: FreeBSD ARM EABI in head In-reply-to: To: Alie Tan Message-id: <20130129232528.4636d91e@bender> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit References: <20130127150429.5a232f66@bender> 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, 29 Jan 2013 10:41:02 -0000 On Mon, 28 Jan 2013 18:32:33 +0800 Alie Tan wrote: > Tried building kernel-toolchain, world and kernel with > -DWITH_ARM_EABI and gcc4.2 > > my Pi keeps rebooting after uboot, strange... hardly for rme to debug > it since it happens really fast. I'll have a look into it. For now you can replace the EABI ubldr with a known good version as it is only used to load the kernel. Andrew From owner-freebsd-arm@FreeBSD.ORG Tue Jan 29 16:27: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 4B2E5531 for ; Tue, 29 Jan 2013 16:27:04 +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 EB27879D for ; Tue, 29 Jan 2013 16:27:03 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0TGQuMa070563 for ; Tue, 29 Jan 2013 11:26:56 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Tue, 29 Jan 2013 11:26:56 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: Re: CfT: Revised CPSW driver for BeagleBone Message-ID: <20130129112656.49c3b274@ivory.lan> In-Reply-To: <3F0C7436-3CC5-4B57-A4CB-431D83AFCAFE@freebsd.org> References: <3F0C7436-3CC5-4B57-A4CB-431D83AFCAFE@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: 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, 29 Jan 2013 16:27:04 -0000 Greeting- Grabbing and rebuilding now. I will let you know results when I have them. -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 Jan 29 18:15: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 E1897318 for ; Tue, 29 Jan 2013 18:15:46 +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 72D95E5F for ; Tue, 29 Jan 2013 18:15:46 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 89A1E39E09 for ; Wed, 30 Jan 2013 03:09:58 +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 7567739D62 for ; Wed, 30 Jan 2013 03:09:58 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> In-Reply-To: Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Date: Wed, 30 Jan 2013 03:10:15 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response 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 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, 29 Jan 2013 18:15:46 -0000 I've updated clang RPI code based on SVN r246066. This is OABI version. I plan to try EABI next if possible. major change: o update base tree to SVN r246066. o implement -mload-store-multiple/-mno-load-store-multiple option in clang/llvm. (workaround only) o re-enable __clear_cache() in libgcc. o bugfix bcm2835_dma inline asm code, etc. o use bcm2835_dma_wb/wbinv in SDHCI. o add USB LAN and wireless LAN driver module. (loaded by devd automatically) o move swap to head of partition. o use label mount instead of /dev/mmcsd0s2a,/dev/mmcsd0s2b. o add wireless lan, quota, ipfw and IPv6 to kernel config. o change default HS mode is enabled. To prevent a fault on ldm/stm generated by clang, all files are complied with: CFLAGS=-O2 -mno-global-merge -mno-load-store-multiple -fno-strict-aliasing -pipe -mabi=apcs-gnu -march=armv6z -mtune=arm1176jzf-s -mfloat-abi=soft To reduce time in DMA intr, it uses bcm2835_dma_wb/wbinv directly. Now it gets 20.7MB/s DMA transfer rate on class 10 SD card. (depend on card spec) It's 30% faster than bus_space_XXX/bus_dmamap_XXX. >root@raspberry-pi:~ # dd if=/dev/mmcsd0 of=/dev/null bs=1m count=32 >32+0 records in >32+0 records out >33554432 bytes transferred in 1.617316 secs (20746986 bytes/sec) Known issue: DMA intr might be delayed by slow interrupt handler. (arm/intr.c:arm_handler_execute specific, should be remapped DMA IRQ to low number) You can get the pre-build image from my archives: http://www.peach.ne.jp/archives/rpi/ Download and decompress it, then write it to SD. This image requires SD 8GB or more. I'm using it as headless server. So, you need a serial console for seeing full boot log. If you want the video out, please remove the line of "set console=comconsole" in /boot/loader.rc. Using config is here: http://www.peach.ne.jp/archives/rpi/config/RPI-B-test15 The source/patch is here: http://www.peach.ne.jp/archives/rpi/patch/ For more info, please read old ML or Japanese blog: http://lists.freebsd.org/pipermail/freebsd-arm/2013-January/004555.html http://lists.freebsd.org/pipermail/freebsd-arm/2013-January/004541.html http://lists.freebsd.org/pipermail/freebsd-arm/2013-January/004507.html http://lists.freebsd.org/pipermail/freebsd-arm/2012-December/004421.html http://lists.freebsd.org/pipermail/freebsd-arm/2012-December/004331.html http://shell.peach.ne.jp/aoyama/ ---------------------------------------------------------------------- How to build/install the kernel: # fetch -o /usr http://www.peach.ne.jp/archives/rpi/patch/src-246066-20130130.patch.gz # fetch -o /usr/src/sys/arm/conf http://www.peach.ne.jp/archives/rpi/config/RPI-B-test15 # fetch -o /usr/src/sys/arm/broadcom/bcm2835 http://www.peach.ne.jp/archives/rpi/patch/bcm2835_asm.S # fetch -o /usr/src/sys/arm/broadcom/bcm2835 http://www.peach.ne.jp/archives/rpi/patch/bcm2835_asm.h # fetch -o /usr/src/sys/arm/broadcom/bcm2835 http://www.peach.ne.jp/archives/rpi/patch/bcm2835_dma.c # fetch -o /usr/src/sys/arm/broadcom/bcm2835 http://www.peach.ne.jp/archives/rpi/patch/bcm2835_dma.h # cd /usr/src # gzcat /usr/src-246066-20130130.patch.gz | patch # make buildkernel KERNCONF=RPI-B-test15 WITH_FDT=yes (wait about 50 minutes) # make installkernel KERNCONF=RPI-B-test15 ---------------------------------------------------------------------- Enjoy clang world in Raspberry Pi! Thank you. -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Tue Jan 29 19:30:37 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 1B724764 for ; Tue, 29 Jan 2013 19:30: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 AE1C91C8 for ; Tue, 29 Jan 2013 19:30:36 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0TJUZlr072444 for ; Tue, 29 Jan 2013 14:30:35 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Tue, 29 Jan 2013 14:30:35 -0500 From: Brett Wynkoop To: freebsd-arm Subject: BeagleBone USB anyone Message-ID: <20130129143035.5cc20b75@ivory.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 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, 29 Jan 2013 19:30:37 -0000 Greeting- I am in the process of building a new kernel with Tim's most recent cpsw patches. Does anyone have any Beagle Bone USB patches for me to try? I would love to have a fully functional Beagle Bone that I could use for development in userland. Yes I prefer to build on the bone and not do cross dev. -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 Jan 29 19:32: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 3B7787BB for ; Tue, 29 Jan 2013 19:32:42 +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 DDC271DD for ; Tue, 29 Jan 2013 19:32:41 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0TJWeJT072455 for ; Tue, 29 Jan 2013 14:32:40 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Tue, 29 Jan 2013 14:32:40 -0500 From: Brett Wynkoop To: freebsd-arm Subject: arm sshd dies Message-ID: <20130129143240.61bab059@ivory.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 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, 29 Jan 2013 19:32:42 -0000 Greeting- I spent about a week too tied up with my work to look at my Beagle Bone. Today I tried to ssh into the Bone and got no response. In jumping onto the console I discovered that sshd had died, so I guess we still have that issue. -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 Jan 29 19:54: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 4733AF26 for ; Tue, 29 Jan 2013 19:54:24 +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 5218E2AC for ; Tue, 29 Jan 2013 19:54:19 +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 r0TJsJkb070699 for ; Tue, 29 Jan 2013 12:54:19 -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 r0TJsGRH022702; Tue, 29 Jan 2013 12:54:17 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: arm sshd dies From: Ian Lepore To: Brett Wynkoop In-Reply-To: <20130129143240.61bab059@ivory.lan> References: <20130129143240.61bab059@ivory.lan> Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Jan 2013 12:54:16 -0700 Message-ID: <1359489256.93359.162.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 29 Jan 2013 19:54:24 -0000 On Tue, 2013-01-29 at 14:32 -0500, Brett Wynkoop wrote: > Greeting- > > I spent about a week too tied up with my work to look at my Beagle > Bone. Today I tried to ssh into the Bone and got no response. > > In jumping onto the console I discovered that sshd had died, so I guess > we still have that issue. > > -Brett > Can you grep sshd in /var/log/messages and see if there are any clues about why it died? -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Jan 29 20:02: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 403A658C; Tue, 29 Jan 2013 20:02:25 +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 E3BC7315; Tue, 29 Jan 2013 20:02:24 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0TK2NjD072989; Tue, 29 Jan 2013 15:02:24 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Tue, 29 Jan 2013 15:02:23 -0500 From: Brett Wynkoop To: Ian Lepore Subject: Re: arm sshd dies Message-ID: <20130129150223.4e095c83@ivory.lan> In-Reply-To: <1359489256.93359.162.camel@revolution.hippie.lan> References: <20130129143240.61bab059@ivory.lan> <1359489256.93359.162.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: 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: Tue, 29 Jan 2013 20:02:25 -0000 On Tue, 29 Jan 2013 12:54:16 -0700 Ian Lepore wrote: > Can you grep sshd in /var/log/messages and see if there are any clues > about why it died? > > -- Ian Nothing at all in /var/log/messages about sshd! Odd! -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 Wed Jan 30 01:02: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 E7623406; Wed, 30 Jan 2013 01:02: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 841A9319; Wed, 30 Jan 2013 01:02:34 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0U12UWT076285; Tue, 29 Jan 2013 20:02:33 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Tue, 29 Jan 2013 20:02:30 -0500 From: Brett Wynkoop To: Ian Lepore Subject: Re: arm sshd dies Message-ID: <20130129200230.7848f010@ivory.lan> In-Reply-To: <1359489256.93359.162.camel@revolution.hippie.lan> References: <20130129143240.61bab059@ivory.lan> <1359489256.93359.162.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: 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: Wed, 30 Jan 2013 01:02:35 -0000 On Tue, 29 Jan 2013 12:54:16 -0700 Ian Lepore wrote: > Can you grep sshd in /var/log/messages and see if there are any clues > about why it died? > > -- Ian Nothing in /var/log/messages about sshd! Odd. I should look for core dumps I suppose. -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 Wed Jan 30 01:06:29 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 77760594 for ; Wed, 30 Jan 2013 01:06:29 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-ie0-x234.google.com (ie-in-x0234.1e100.net [IPv6:2607:f8b0:4001:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 49B18343 for ; Wed, 30 Jan 2013 01:06:29 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id k11so893427iea.11 for ; Tue, 29 Jan 2013 17:06:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-rim-org-msg-ref-id:message-id :content-transfer-encoding:reply-to:x-priority:sensitivity :importance:subject:to:cc:from:date:content-type:mime-version :x-gm-message-state; bh=4sXe7HekA6aiQV+zInn2pU8zXj5qFaU55bSj0UQhurA=; b=jlJKYDQUsl/oeHUyF6XYJSmaU6SfkRvsjwatw4OlJDy5R7y8wpLT1TzzrK/QL1UGAC 8CH1D00WZp1DDXmJc6vSwslrIGCeYd7rdHxWHjJe/EbYTI+da8an5fPm3JfiorSHBA7b DI+Cb/4SlgjR1Cxt6R+SWnh2Qz9lEF2CPjOPjbN8PyM4dW24Q2DDCYaJbBD5racsCOnz 8S1xSSxnucCxTsJ+iAECrpRtF9KyRrjrG2lH9t3SRDvze4vi2qa0IL4NgA/Nz4z7cV+Z FC0uMMUUnodhLvaVIKV4fyD6fGWSTk8/TK77oGzXXSL0x23EhHfKItqjDv3xEQfNVXgv YneA== X-Received: by 10.42.81.148 with SMTP id z20mr2039460ick.5.1359507988906; Tue, 29 Jan 2013 17:06:28 -0800 (PST) Received: from 172.22.81.188 (bda-216-9-250-138.bis3.ap.blackberry.com. [216.9.250.138]) by mx.google.com with ESMTPS id mj6sm3147701igc.9.2013.01.29.17.06.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 29 Jan 2013 17:06:28 -0800 (PST) X-rim-org-msg-ref-id: 1322678150 Message-ID: <1322678150-1359507986-cardhu_decombobulator_blackberry.rim.net-2019402583-@b17.c6.bise3.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal Sensitivity: Normal Importance: Normal Subject: Re: arm sshd dies To: "Brett Wynkoop" , owner-freebsd-arm@freebsd.org, "Ian Lepore" From: "Alie Tan" Date: Wed, 30 Jan 2013 01:06:24 +0000 Content-Type: text/plain; charset="big5-hkscs" MIME-Version: 1.0 X-Gm-Message-State: ALoCoQk4ALe5IOaFVfDhg9ZMSDzHqAdGak90M6VPqQoUCCiXmlyE1l5DheqR6iOchAyMfepDB0rt Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: alie@affle.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 01:06:29 -0000 SSBjYW4gcmVwcm9kdWNlIHRoaXMgaXNzdWUgcXVpdGUgZWFzeSg3NSUpIGJ5IHBvcnRzbmFwLWlu ZyBvciBjb21waWxpbmcgYmlnIHBvcnQuIEl0IHNlZW1zIG5vdCBkdWUgdG8gc3NoLCBwbGVhc2Ug ZG8gY2hlY2sgY29yZSBkdW1wDQoNCi0tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLS0NCkZyb206 IEJyZXR0IFd5bmtvb3ANClNlbmRlcjogb3duZXItZnJlZWJzZC1hcm1AZnJlZWJzZC5vcmcNClRv OiBJYW4gTGVwb3JlDQpDYzogZnJlZWJzZC1hcm0NClN1YmplY3Q6IFJlOiBhcm0gc3NoZCBkaWVz DQpTZW50OiBKYW4gMzAsIDIwMTMgOTowMiBBTQ0KDQpPbiBUdWUsIDI5IEphbiAyMDEzIDEyOjU0 OjE2IC0wNzAwDQpJYW4gTGVwb3JlIDxpYW5AZnJlZWJzZC5vcmc+IHdyb3RlOg0KIA0KPiBDYW4g eW91IGdyZXAgc3NoZCBpbiAvdmFyL2xvZy9tZXNzYWdlcyBhbmQgc2VlIGlmIHRoZXJlIGFyZSBh bnkgY2x1ZXMNCj4gYWJvdXQgd2h5IGl0IGRpZWQ/DQo+IA0KPiAtLSBJYW4NCg0KTm90aGluZyBp biAvdmFyL2xvZy9tZXNzYWdlcyBhYm91dCBzc2hkIQ0KDQpPZGQuDQoNCkkgc2hvdWxkIGxvb2sg Zm9yIGNvcmUgZHVtcHMgSSBzdXBwb3NlLg0KDQotQnJldHQNCi0tIA0KDQp3eW5rb29wQHd5bm4u Y29tICAgICAgICAgICAgICAgaHR0cDovL3ByZDQud3lubi5jb20vd3lua29vcC9wZ3Ata2V5cy50 eHQNCjkxNy02NDItNjkyNQ0KNzE4LTcxNy01NDM1DQoNCiJUaGUgc3Ryb25nZXN0IHJlYXNvbiBm b3IgdGhlIHBlb3BsZSB0byByZXRhaW4gdGhlIHJpZ2h0IHRvIGtlZXAgDQphbmQgYmVhciBhcm1z IGlzLCBhcyBhIGxhc3QgcmVzb3J0LCB0byBwcm90ZWN0IHRoZW1zZWx2ZXMgYWdhaW5zdCANCnR5 cmFubnkgaW4gZ292ZXJubWVudCIgLSBUaG9tYXMgSmVmZmVyc29uLiANCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpmcmVlYnNkLWFybUBmcmVlYnNkLm9y ZyBtYWlsaW5nIGxpc3QNCmh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2ZyZWVic2QtYXJtDQpUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1h cm0tdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmciDQoNClNlbnQgdmlhIEJsYWNrQmVycnkgZnJvbSBT aW5nVGVsIQ== From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 05:06: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 F01FD8DB; Wed, 30 Jan 2013 05:06: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 9C305DB8; Wed, 30 Jan 2013 05:06:02 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0U561he078809; Wed, 30 Jan 2013 00:06:01 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 30 Jan 2013 00:06:00 -0500 From: Brett Wynkoop To: Tim Kientzle Subject: Re: CfT: Revised CPSW driver for BeagleBone Message-ID: <20130130000600.1d10732f@ivory.lan> In-Reply-To: <3F0C7436-3CC5-4B57-A4CB-431D83AFCAFE@freebsd.org> References: <3F0C7436-3CC5-4B57-A4CB-431D83AFCAFE@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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 05:06:03 -0000 Greeting- I just booted on a kernel with the test driver installed. So the good news is that the box boots and networking seems to work. Here are the very initial findings: wynkoop@beaglebone:~ % ping www.wynn.com PING www.wynn.com (199.89.147.3): 56 data bytes 64 bytes from 199.89.147.3: icmp_seq=5 ttl=64 time=0.534 ms 64 bytes from 199.89.147.3: icmp_seq=6 ttl=64 time=0.542 ms 64 bytes from 199.89.147.3: icmp_seq=7 ttl=64 time=0.582 ms 64 bytes from 199.89.147.3: icmp_seq=8 ttl=64 time=0.579 ms 64 bytes from 199.89.147.3: icmp_seq=9 ttl=64 time=0.500 ms 64 bytes from 199.89.147.3: icmp_seq=10 ttl=64 time=0.553 ms 64 bytes from 199.89.147.3: icmp_seq=11 ttl=64 time=0.545 ms 64 bytes from 199.89.147.3: icmp_seq=12 ttl=64 time=0.572 ms 64 bytes from 199.89.147.3: icmp_seq=13 ttl=64 time=0.565 ms 64 bytes from 199.89.147.3: icmp_seq=14 ttl=64 time=0.514 ms 64 bytes from 199.89.147.3: icmp_seq=15 ttl=64 time=0.532 ms 64 bytes from 199.89.147.3: icmp_seq=16 ttl=64 time=0.553 ms 64 bytes from 199.89.147.3: icmp_seq=17 ttl=64 time=0.545 ms 64 bytes from 199.89.147.3: icmp_seq=18 ttl=64 time=0.539 ms ^C --- www.wynn.com ping statistics --- 19 packets transmitted, 14 packets received, 26.3% packet loss round-trip min/avg/max/stddev = 0.500/0.547/0.582/0.022 ms wynkoop@beaglebone:~ % Meanwhile on the console: login: cpsw0: watchdog timeout ifaddr cache = 0xc1f52400 is deleted cpsw0: watchdog timeout I have no idea what this means to the freebsd using world. I just report what I find. I will report more if there is anything that seems of note. If you would like me to run specific tests please 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 Wed Jan 30 05:18: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 15528A43 for ; Wed, 30 Jan 2013 05:18:51 +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 CFE51DF0 for ; Wed, 30 Jan 2013 05:18:50 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0U5InG3078927 for ; Wed, 30 Jan 2013 00:18:49 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 30 Jan 2013 00:18:49 -0500 From: Brett Wynkoop To: freebsd-arm Subject: disk wait mystery Message-ID: <20130130001849.7669e033@ivory.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 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, 30 Jan 2013 05:18:51 -0000 Greeting- Can anyone figure out why a mainly idle bone with only 2 user shells via ssh running would have so much in disk wait? wynkoop@beaglebone:~ % !ps ps ax PID TT STAT TIME COMMAND 0 - DLs 0:00.02 [kernel] 1 - ILs 0:00.20 /sbin/init -- 2 - DL 0:00.00 [xpt_thrd] 3 - DL 0:01.92 [task: mmc/sd card] 4 - DL 0:00.01 [pagedaemon] 5 - DL 0:00.00 [vmdaemon] 6 - DL 0:00.00 [pagezero] 7 - DL 0:00.02 [bufdaemon] 8 - DL 0:00.02 [vnlru] 9 - DL 0:00.10 [syncer] 10 - RL 17:15.90 [idle] 11 - WL 0:07.91 [intr] 12 - DL 0:00.17 [geom] 13 - DL 0:00.21 [yarrow] 14 - DL 0:00.06 [softdepflush] 15 - DL 0:00.15 [schedcpu] 106 - DL 0:00.00 [md0] 410 - Is 0:00.06 dhclient: cpsw0 [priv] (dhclient) 448 - Is 0:00.07 dhclient: cpsw0 (dhclient) 449 - Is 0:00.01 /sbin/devd 634 - Is 0:00.04 /usr/sbin/sshd 638 - Is 0:00.55 /usr/sbin/cron -s 682 - Is 0:00.64 sshd: wynkoop [priv] (sshd) 685 - S 0:00.29 sshd: wynkoop@pts/0 (sshd) 678 u0 Is+ 0:00.19 /usr/libexec/getty std.9600 ttyu0 686 0 Ss 0:00.74 -csh (csh) 831 0 R+ 0:00.16 ps ax wynkoop@beaglebone:~ % -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 Wed Jan 30 09:24: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 20CCFEB2 for ; Wed, 30 Jan 2013 09:24:50 +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 4B6EF9CC for ; Wed, 30 Jan 2013 09:24:48 +0000 (UTC) Received: by ext.mellstrand.net Wed, 30 Jan 2013 09:24:42 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: Wed, 30 Jan 2013 10:24:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> To: Daisuke Aoyama 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, 30 Jan 2013 09:24:50 -0000 Hi 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. The sshd listen to the IPv6 port root# netstat -an Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address = (state) tcp4 0 0 *.22 *.* LISTEN tcp6 0 0 *.22 *.* LISTEN .. I have disabled the ipfw firewall and "allow all" in /etc/hosts.allow /mm =20 On 29 jan 2013, at 19:10, Daisuke Aoyama wrote: > I've updated clang RPI code based on SVN r246066. > This is OABI version. I plan to try EABI next if possible. >=20 > major change: > o update base tree to SVN r246066. > o implement -mload-store-multiple/-mno-load-store-multiple option in = clang/llvm. (workaround only) > o re-enable __clear_cache() in libgcc. > o bugfix bcm2835_dma inline asm code, etc. > o use bcm2835_dma_wb/wbinv in SDHCI. > o add USB LAN and wireless LAN driver module. (loaded by devd = automatically) > o move swap to head of partition. > o use label mount instead of /dev/mmcsd0s2a,/dev/mmcsd0s2b. > o add wireless lan, quota, ipfw and IPv6 to kernel config. > o change default HS mode is enabled. >=20 > To prevent a fault on ldm/stm generated by clang, all files are = complied with: > CFLAGS=3D-O2 -mno-global-merge -mno-load-store-multiple = -fno-strict-aliasing -pipe -mabi=3Dapcs-gnu -march=3Darmv6z = -mtune=3Darm1176jzf-s -mfloat-abi=3Dsoft >=20 > To reduce time in DMA intr, it uses bcm2835_dma_wb/wbinv directly. > Now it gets 20.7MB/s DMA transfer rate on class 10 SD card. (depend on = card spec) > It's 30% faster than bus_space_XXX/bus_dmamap_XXX. >=20 >> root@raspberry-pi:~ # dd if=3D/dev/mmcsd0 of=3D/dev/null bs=3D1m = count=3D32 >> 32+0 records in >> 32+0 records out >> 33554432 bytes transferred in 1.617316 secs (20746986 bytes/sec) >=20 > Known issue: > DMA intr might be delayed by slow interrupt handler. > (arm/intr.c:arm_handler_execute specific, should be remapped DMA IRQ = to low number) >=20 >=20 > You can get the pre-build image from my archives: > http://www.peach.ne.jp/archives/rpi/ >=20 > Download and decompress it, then write it to SD. This image requires = SD 8GB or more. > I'm using it as headless server. So, you need a serial console for = seeing full boot log. > If you want the video out, please remove the line of "set = console=3Dcomconsole" in /boot/loader.rc. >=20 > Using config is here: > http://www.peach.ne.jp/archives/rpi/config/RPI-B-test15 >=20 > The source/patch is here: > http://www.peach.ne.jp/archives/rpi/patch/ >=20 > For more info, please read old ML or Japanese blog: > = http://lists.freebsd.org/pipermail/freebsd-arm/2013-January/004555.html > = http://lists.freebsd.org/pipermail/freebsd-arm/2013-January/004541.html > = http://lists.freebsd.org/pipermail/freebsd-arm/2013-January/004507.html > = http://lists.freebsd.org/pipermail/freebsd-arm/2012-December/004421.html > = http://lists.freebsd.org/pipermail/freebsd-arm/2012-December/004331.html > http://shell.peach.ne.jp/aoyama/ >=20 > ---------------------------------------------------------------------- > How to build/install the kernel: >=20 > # fetch -o /usr = http://www.peach.ne.jp/archives/rpi/patch/src-246066-20130130.patch.gz > # fetch -o /usr/src/sys/arm/conf = http://www.peach.ne.jp/archives/rpi/config/RPI-B-test15 > # fetch -o /usr/src/sys/arm/broadcom/bcm2835 = http://www.peach.ne.jp/archives/rpi/patch/bcm2835_asm.S > # fetch -o /usr/src/sys/arm/broadcom/bcm2835 = http://www.peach.ne.jp/archives/rpi/patch/bcm2835_asm.h > # fetch -o /usr/src/sys/arm/broadcom/bcm2835 = http://www.peach.ne.jp/archives/rpi/patch/bcm2835_dma.c > # fetch -o /usr/src/sys/arm/broadcom/bcm2835 = http://www.peach.ne.jp/archives/rpi/patch/bcm2835_dma.h >=20 > # cd /usr/src > # gzcat /usr/src-246066-20130130.patch.gz | patch > # make buildkernel KERNCONF=3DRPI-B-test15 WITH_FDT=3Dyes > (wait about 50 minutes) > # make installkernel KERNCONF=3DRPI-B-test15 > ---------------------------------------------------------------------- >=20 >=20 > Enjoy clang world in Raspberry Pi! > Thank you. > --=20 > Daisuke Aoyama >=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 Jan 30 09:39:39 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 C5CE2527 for ; Wed, 30 Jan 2013 09:39:39 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 89E64AA0 for ; Wed, 30 Jan 2013 09:39:38 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1U0U8m-00059W-H3 for freebsd-arm@freebsd.org; Wed, 30 Jan 2013 10:39:37 +0100 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U0U8m-0004mO-Jh for freebsd-arm@freebsd.org; Wed, 30 Jan 2013 10:39:36 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: disk wait mystery References: <20130130001849.7669e033@ivory.lan> Date: Wed, 30 Jan 2013 10:39:37 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <20130130001849.7669e033@ivory.lan> User-Agent: Opera Mail/12.13 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: c09395f469c52153b963e4ff2d10f427 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, 30 Jan 2013 09:39:39 -0000 On Wed, 30 Jan 2013 06:18:49 +0100, Brett Wynkoop wrote: > Greeting- > > Can anyone figure out why a mainly idle bone with only 2 user shells via > ssh running would have so much in disk wait? > > wynkoop@beaglebone:~ % !ps > ps ax > PID TT STAT TIME COMMAND > 0 - DLs 0:00.02 [kernel] > 1 - ILs 0:00.20 /sbin/init -- > 2 - DL 0:00.00 [xpt_thrd] > 3 - DL 0:01.92 [task: mmc/sd card] > 4 - DL 0:00.01 [pagedaemon] > 5 - DL 0:00.00 [vmdaemon] > 6 - DL 0:00.00 [pagezero] > 7 - DL 0:00.02 [bufdaemon] > 8 - DL 0:00.02 [vnlru] > 9 - DL 0:00.10 [syncer] > 10 - RL 17:15.90 [idle] > 11 - WL 0:07.91 [intr] > 12 - DL 0:00.17 [geom] > 13 - DL 0:00.21 [yarrow] > 14 - DL 0:00.06 [softdepflush] > 15 - DL 0:00.15 [schedcpu] > 106 - DL 0:00.00 [md0] > 410 - Is 0:00.06 dhclient: cpsw0 [priv] (dhclient) > 448 - Is 0:00.07 dhclient: cpsw0 (dhclient) > 449 - Is 0:00.01 /sbin/devd > 634 - Is 0:00.04 /usr/sbin/sshd > 638 - Is 0:00.55 /usr/sbin/cron -s > 682 - Is 0:00.64 sshd: wynkoop [priv] (sshd) > 685 - S 0:00.29 sshd: wynkoop@pts/0 (sshd) > 678 u0 Is+ 0:00.19 /usr/libexec/getty std.9600 ttyu0 > 686 0 Ss 0:00.74 -csh (csh) > 831 0 R+ 0:00.16 ps ax > wynkoop@beaglebone:~ % > > -Brett > Hi, Maybe I missed a previous email, but you don't provide much information for people to think about. As a start you might show the 'disk wait' output. Ronald. From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 09:40: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 1B2EB593 for ; Wed, 30 Jan 2013 09:40:25 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id CBB8CAAD for ; Wed, 30 Jan 2013 09:40:24 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1U0U3n-0004lO-5H for freebsd-arm@freebsd.org; Wed, 30 Jan 2013 10:34:28 +0100 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U0U3n-0004RQ-8F for freebsd-arm@freebsd.org; Wed, 30 Jan 2013 10:34:27 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: arm sshd dies References: <20130129143240.61bab059@ivory.lan> <1359489256.93359.162.camel@revolution.hippie.lan> <20130129150223.4e095c83@ivory.lan> Date: Wed, 30 Jan 2013 10:34:28 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <20130129150223.4e095c83@ivory.lan> User-Agent: Opera Mail/12.13 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 739ba1b2be5fabc1cc6069058737919f 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, 30 Jan 2013 09:40:25 -0000 On Tue, 29 Jan 2013 21:02:23 +0100, Brett Wynkoop wrote: > On Tue, 29 Jan 2013 12:54:16 -0700 > Ian Lepore wrote: > > >> Can you grep sshd in /var/log/messages and see if there are any clues >> about why it died? >> >> -- Ian > > Nothing at all in /var/log/messages about sshd! Odd! > > -Brett > > Did you check the rotated logfiles? /var/log/messages.0.bz2, etc. You can use bzgrep for those. Ronald. From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 10:37: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 BFCB63DB for ; Wed, 30 Jan 2013 10:37:32 +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 69301E00 for ; Wed, 30 Jan 2013 10:37:32 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0UAbTNL084697; Wed, 30 Jan 2013 05:37:30 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 30 Jan 2013 05:37:29 -0500 From: Brett Wynkoop To: "Ronald Klop" Subject: Re: disk wait mystery Message-ID: <20130130053729.0c9e018f@ivory.lan> In-Reply-To: References: <20130130001849.7669e033@ivory.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: quoted-printable 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, 30 Jan 2013 10:37:32 -0000 On Wed, 30 Jan 2013 10:39:37 +0100 "Ronald Klop" wrote: > On Wed, 30 Jan 2013 06:18:49 +0100, Brett Wynkoop > wrote: >=20 > > Greeting- > > > > Can anyone figure out why a mainly idle bone with only 2 user > > shells via ssh running would have so much in disk wait? > > > > wynkoop@beaglebone:~ % !ps > > ps ax > > PID TT STAT TIME COMMAND > > 0 - DLs 0:00.02 [kernel] > > 1 - ILs 0:00.20 /sbin/init -- > > 2 - DL 0:00.00 [xpt_thrd] > > 3 - DL 0:01.92 [task: mmc/sd card] > > 4 - DL 0:00.01 [pagedaemon] > > 5 - DL 0:00.00 [vmdaemon] > > 6 - DL 0:00.00 [pagezero] > > 7 - DL 0:00.02 [bufdaemon] > > 8 - DL 0:00.02 [vnlru] > > 9 - DL 0:00.10 [syncer] > > 10 - RL 17:15.90 [idle] > > 11 - WL 0:07.91 [intr] > > 12 - DL 0:00.17 [geom] > > 13 - DL 0:00.21 [yarrow] > > 14 - DL 0:00.06 [softdepflush] > > 15 - DL 0:00.15 [schedcpu] > > 106 - DL 0:00.00 [md0] > > 410 - Is 0:00.06 dhclient: cpsw0 [priv] (dhclient) > > 448 - Is 0:00.07 dhclient: cpsw0 (dhclient) > > 449 - Is 0:00.01 /sbin/devd > > 634 - Is 0:00.04 /usr/sbin/sshd > > 638 - Is 0:00.55 /usr/sbin/cron -s > > 682 - Is 0:00.64 sshd: wynkoop [priv] (sshd) > > 685 - S 0:00.29 sshd: wynkoop@pts/0 (sshd) > > 678 u0 Is+ 0:00.19 /usr/libexec/getty std.9600 ttyu0 > > 686 0 Ss 0:00.74 -csh (csh) > > 831 0 R+ 0:00.16 ps ax > > wynkoop@beaglebone:~ % > > > > -Brett > > >=20 > Hi, >=20 > Maybe I missed a previous email, but you don't provide much > information for people to think about. > As a start you might show the 'disk wait' output. >=20 > Ronald. >=20 Ronald- =46rom the ps man page: D Marks a process in disk (or other short term, uninterruptible) wait. Note all the D entries in the above ps output. -Brett _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --=20 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=20 and bear arms is, as a last resort, to protect themselves against=20 tyranny in government" - Thomas Jefferson.=20 From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 10:39:20 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 6071742C for ; Wed, 30 Jan 2013 10:39:20 +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 20ABFE17 for ; Wed, 30 Jan 2013 10:39:19 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0UAdIqT084708; Wed, 30 Jan 2013 05:39:18 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 30 Jan 2013 05:39:18 -0500 From: Brett Wynkoop To: "Ronald Klop" Subject: Re: arm sshd dies Message-ID: <20130130053918.7fe366cb@ivory.lan> In-Reply-To: References: <20130129143240.61bab059@ivory.lan> <1359489256.93359.162.camel@revolution.hippie.lan> <20130129150223.4e095c83@ivory.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: 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, 30 Jan 2013 10:39:20 -0000 On Wed, 30 Jan 2013 10:34:28 +0100 "Ronald Klop" wrote: > Did you check the rotated logfiles? /var/log/messages.0.bz2, etc. > You can use bzgrep for those. > > Ronald. No rotated /var/log/messages. So the mystery remains as I also found no core dumps. -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 Wed Jan 30 10:52:43 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 E945F538 for ; Wed, 30 Jan 2013 10:52:43 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) by mx1.freebsd.org (Postfix) with ESMTP id C238BE8C for ; Wed, 30 Jan 2013 10:52:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=RQmi4CPNLJUVM1nQEgqRZkZwTiueWCluGQLI69LfK/k=; b=Xe6U/7PCR4jL7i0wS57O14FhblGP/WUwTd+dddIU3ayZAskdIL89iwDXKtlB9jgtaRjFyOGbNCgHjxLf05xbf2ogMrh5NEs85H3bKZiJNq9gdsed3YNbbg6MOKS4NlNx; Received: from [122.129.203.50] (port=26890 helo=X220.ovitrap.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U0VHU-003Cz4-IF; Wed, 30 Jan 2013 03:52:41 -0700 Date: Wed, 30 Jan 2013 17:52:36 +0700 From: Erich Dollansky To: Brett Wynkoop Subject: Re: disk wait mystery Message-ID: <20130130175236.402435ce@X220.ovitrap.com> In-Reply-To: <20130130053729.0c9e018f@ivory.lan> References: <20130130001849.7669e033@ivory.lan> <20130130053729.0c9e018f@ivory.lan> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-arm@freebsd.org, Ronald Klop 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, 30 Jan 2013 10:52:44 -0000 Hi, On Wed, 30 Jan 2013 05:37:29 -0500 Brett Wynkoop wrote: > On Wed, 30 Jan 2013 10:39:37 +0100 > "Ronald Klop" wrote: > > > On Wed, 30 Jan 2013 06:18:49 +0100, Brett Wynkoop > > wrote: > > > > > Greeting- > > > > > > Can anyone figure out why a mainly idle bone with only 2 user > > > shells via ssh running would have so much in disk wait? > > > > > > wynkoop@beaglebone:~ % !ps > > > ps ax > > > PID TT STAT TIME COMMAND > > > 0 - DLs 0:00.02 [kernel] > > > 1 - ILs 0:00.20 /sbin/init -- > > > 2 - DL 0:00.00 [xpt_thrd] > > > 3 - DL 0:01.92 [task: mmc/sd card] > > > 4 - DL 0:00.01 [pagedaemon] > > > 5 - DL 0:00.00 [vmdaemon] > > > 6 - DL 0:00.00 [pagezero] > > > 7 - DL 0:00.02 [bufdaemon] > > > 8 - DL 0:00.02 [vnlru] > > > 9 - DL 0:00.10 [syncer] > > > 10 - RL 17:15.90 [idle] > > > 11 - WL 0:07.91 [intr] > > > 12 - DL 0:00.17 [geom] > > > 13 - DL 0:00.21 [yarrow] > > > 14 - DL 0:00.06 [softdepflush] > > > 15 - DL 0:00.15 [schedcpu] > > > 106 - DL 0:00.00 [md0] > > > 410 - Is 0:00.06 dhclient: cpsw0 [priv] (dhclient) > > > 448 - Is 0:00.07 dhclient: cpsw0 (dhclient) > > > 449 - Is 0:00.01 /sbin/devd > > > 634 - Is 0:00.04 /usr/sbin/sshd > > > 638 - Is 0:00.55 /usr/sbin/cron -s > > > 682 - Is 0:00.64 sshd: wynkoop [priv] (sshd) > > > 685 - S 0:00.29 sshd: wynkoop@pts/0 (sshd) > > > 678 u0 Is+ 0:00.19 /usr/libexec/getty std.9600 ttyu0 > > > 686 0 Ss 0:00.74 -csh (csh) > > > 831 0 R+ 0:00.16 ps ax > > > wynkoop@beaglebone:~ % > > > > > > -Brett > > > > > > > Hi, > > > > Maybe I missed a previous email, but you don't provide much > > information for people to think about. > > As a start you might show the 'disk wait' output. > > > > Ronald. > > > > Ronald- > > From the ps man page: > D Marks a process in disk (or other short term, > uninterruptible) wait. > > > Note all the D entries in the above ps output. > how I understand the system, I would say that these tasks are all swapped out to disk. Erich From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 11:01:45 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C415A806 for ; Wed, 30 Jan 2013 11:01:45 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 5FFA3EF1 for ; Wed, 30 Jan 2013 11:01:45 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1U0VQE-0004Dh-Ec for freebsd-arm@freebsd.org; Wed, 30 Jan 2013 12:01:43 +0100 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U0VQE-0001mv-2C for freebsd-arm@freebsd.org; Wed, 30 Jan 2013 12:01:42 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: disk wait mystery References: <20130130001849.7669e033@ivory.lan> <20130130053729.0c9e018f@ivory.lan> Date: Wed, 30 Jan 2013 12:01:42 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <20130130053729.0c9e018f@ivory.lan> User-Agent: Opera Mail/12.13 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: d3d6c6694e059b137bd8e4e2c0542d46 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, 30 Jan 2013 11:01:45 -0000 On Wed, 30 Jan 2013 11:37:29 +0100, Brett Wynkoop wrote: > On Wed, 30 Jan 2013 10:39:37 +0100 > "Ronald Klop" wrote: > >> On Wed, 30 Jan 2013 06:18:49 +0100, Brett Wynkoop >> wrote: >> >> > Greeting- >> > >> > Can anyone figure out why a mainly idle bone with only 2 user >> > shells via ssh running would have so much in disk wait? >> > >> > wynkoop@beaglebone:~ % !ps >> > ps ax >> > PID TT STAT TIME COMMAND >> > 0 - DLs 0:00.02 [kernel] >> > 1 - ILs 0:00.20 /sbin/init -- >> > 2 - DL 0:00.00 [xpt_thrd] >> > 3 - DL 0:01.92 [task: mmc/sd card] >> > 4 - DL 0:00.01 [pagedaemon] >> > 5 - DL 0:00.00 [vmdaemon] >> > 6 - DL 0:00.00 [pagezero] >> > 7 - DL 0:00.02 [bufdaemon] >> > 8 - DL 0:00.02 [vnlru] >> > 9 - DL 0:00.10 [syncer] >> > 10 - RL 17:15.90 [idle] >> > 11 - WL 0:07.91 [intr] >> > 12 - DL 0:00.17 [geom] >> > 13 - DL 0:00.21 [yarrow] >> > 14 - DL 0:00.06 [softdepflush] >> > 15 - DL 0:00.15 [schedcpu] >> > 106 - DL 0:00.00 [md0] >> > 410 - Is 0:00.06 dhclient: cpsw0 [priv] (dhclient) >> > 448 - Is 0:00.07 dhclient: cpsw0 (dhclient) >> > 449 - Is 0:00.01 /sbin/devd >> > 634 - Is 0:00.04 /usr/sbin/sshd >> > 638 - Is 0:00.55 /usr/sbin/cron -s >> > 682 - Is 0:00.64 sshd: wynkoop [priv] (sshd) >> > 685 - S 0:00.29 sshd: wynkoop@pts/0 (sshd) >> > 678 u0 Is+ 0:00.19 /usr/libexec/getty std.9600 ttyu0 >> > 686 0 Ss 0:00.74 -csh (csh) >> > 831 0 R+ 0:00.16 ps ax >> > wynkoop@beaglebone:~ % >> > >> > -Brett >> > >> >> Hi, >> >> Maybe I missed a previous email, but you don't provide much >> information for people to think about. >> As a start you might show the 'disk wait' output. >> >> Ronald. >> > > Ronald- > > From the ps man page: > D Marks a process in disk (or other short term, > uninterruptible) wait. > > > Note all the D entries in the above ps output. > > -Brett Aha. My amd64 has the same. I think the ps man page is not very clear. The code src/bin/ps/print.c says this. case SSLEEP: if (tdflags & TDF_SINTR) /* interruptable (long) */ *cp = k->ki_p->ki_slptime >= MAXSLP ? 'I' : 'S'; else *cp = 'D'; break; No mention about disks. Just an uninterruptible sleep (which can be a wait for a disk, but also for other type of alarms/interrupts/locks/etc.). So you have waiting kernel threads/processes. Which is called 'idle'. Ronald. From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 11:05:24 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 2574E8E6 for ; Wed, 30 Jan 2013 11:05:24 +0000 (UTC) (envelope-from olli@grabthar.secnetix.de) Received: from grabthar.secnetix.de (grabthar.secnetix.de [212.17.241.225]) by mx1.freebsd.org (Postfix) with ESMTP id 85702F47 for ; Wed, 30 Jan 2013 11:05:23 +0000 (UTC) Received: from grabthar.secnetix.de (localhost [127.0.0.1]) by grabthar.secnetix.de (8.14.5/8.14.5) with ESMTP id r0UB5Fdw018150; Wed, 30 Jan 2013 12:05:16 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by grabthar.secnetix.de (8.14.5/8.14.5/Submit) id r0UB5F5Y018149; Wed, 30 Jan 2013 12:05:15 +0100 (CET) (envelope-from olli) Date: Wed, 30 Jan 2013 12:05:15 +0100 (CET) Message-Id: <201301301105.r0UB5F5Y018149@grabthar.secnetix.de> From: Oliver Fromme To: freebsd-arm@FreeBSD.ORG, ronald-freebsd8@klop.yi.org, wynkoop@wynn.com Subject: Re: disk wait mystery In-Reply-To: <20130130053729.0c9e018f@ivory.lan> X-Newsgroups: list.freebsd-arm User-Agent: tin/2.0.1-20111224 ("Achenvoir") (UNIX) (FreeBSD/9.1-PRERELEASE-20120811 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: freebsd-arm@FreeBSD.ORG, ronald-freebsd8@klop.yi.org, wynkoop@wynn.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 11:05:24 -0000 Brett Wynkoop wrote: > > > wynkoop@beaglebone:~ % !ps > > > ps ax > > > PID TT STAT TIME COMMAND > > > 0 - DLs 0:00.02 [kernel] > > > 1 - ILs 0:00.20 /sbin/init -- > > > 2 - DL 0:00.00 [xpt_thrd] > > > 3 - DL 0:01.92 [task: mmc/sd card] > > > 4 - DL 0:00.01 [pagedaemon] > > > 5 - DL 0:00.00 [vmdaemon] > > > 6 - DL 0:00.00 [pagezero] > > > 7 - DL 0:00.02 [bufdaemon] > > > 8 - DL 0:00.02 [vnlru] > > > 9 - DL 0:00.10 [syncer] > > > 10 - RL 17:15.90 [idle] > > > 11 - WL 0:07.91 [intr] > > > 12 - DL 0:00.17 [geom] > > > 13 - DL 0:00.21 [yarrow] > > > 14 - DL 0:00.06 [softdepflush] > > > 15 - DL 0:00.15 [schedcpu] > > > 106 - DL 0:00.00 [md0] > [...] > From the ps man page: > D Marks a process in disk (or other short term, > uninterruptible) wait. > > Note all the D entries in the above ps output. That's normal (on all architectures, not just arm). Those "processes" in square brackets are kernel threads which are uninterruptible (well, for some definition of uninterruptible). So they always have the "D" flag set, even if they don't wait for the disk. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Handelsregister: Amtsgericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsreg.: Amtsgericht München, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen/-Produkte + mehr: http://www.secnetix.de/bsd One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 11:09: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 B1A5F9BE for ; Wed, 30 Jan 2013 11:09:49 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 4B708F94 for ; Wed, 30 Jan 2013 11:09:49 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1U0VY2-000579-Sb for freebsd-arm@freebsd.org; Wed, 30 Jan 2013 12:09:47 +0100 Received: from [81.21.138.17] (helo=ronaldradial.versatec.local) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U0VY2-0002Fk-Rq for freebsd-arm@freebsd.org; Wed, 30 Jan 2013 12:09:46 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: disk wait mystery References: <20130130001849.7669e033@ivory.lan> <20130130053729.0c9e018f@ivory.lan> <20130130175236.402435ce@X220.ovitrap.com> Date: Wed, 30 Jan 2013 12:09:47 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <20130130175236.402435ce@X220.ovitrap.com> User-Agent: Opera Mail/12.13 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: aaa3b708a984912a81ea67a52d88c378 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, 30 Jan 2013 11:09:49 -0000 On Wed, 30 Jan 2013 11:52:36 +0100, Erich Dollansky wrote: > Hi, > > On Wed, 30 Jan 2013 05:37:29 -0500 > Brett Wynkoop wrote: > >> On Wed, 30 Jan 2013 10:39:37 +0100 >> "Ronald Klop" wrote: >> >> > On Wed, 30 Jan 2013 06:18:49 +0100, Brett Wynkoop >> > wrote: >> > >> > > Greeting- >> > > >> > > Can anyone figure out why a mainly idle bone with only 2 user >> > > shells via ssh running would have so much in disk wait? >> > > >> > > wynkoop@beaglebone:~ % !ps >> > > ps ax >> > > PID TT STAT TIME COMMAND >> > > 0 - DLs 0:00.02 [kernel] >> > > 1 - ILs 0:00.20 /sbin/init -- >> > > 2 - DL 0:00.00 [xpt_thrd] >> > > 3 - DL 0:01.92 [task: mmc/sd card] >> > > 4 - DL 0:00.01 [pagedaemon] >> > > 5 - DL 0:00.00 [vmdaemon] >> > > 6 - DL 0:00.00 [pagezero] >> > > 7 - DL 0:00.02 [bufdaemon] >> > > 8 - DL 0:00.02 [vnlru] >> > > 9 - DL 0:00.10 [syncer] >> > > 10 - RL 17:15.90 [idle] >> > > 11 - WL 0:07.91 [intr] >> > > 12 - DL 0:00.17 [geom] >> > > 13 - DL 0:00.21 [yarrow] >> > > 14 - DL 0:00.06 [softdepflush] >> > > 15 - DL 0:00.15 [schedcpu] >> > > 106 - DL 0:00.00 [md0] >> > > 410 - Is 0:00.06 dhclient: cpsw0 [priv] (dhclient) >> > > 448 - Is 0:00.07 dhclient: cpsw0 (dhclient) >> > > 449 - Is 0:00.01 /sbin/devd >> > > 634 - Is 0:00.04 /usr/sbin/sshd >> > > 638 - Is 0:00.55 /usr/sbin/cron -s >> > > 682 - Is 0:00.64 sshd: wynkoop [priv] (sshd) >> > > 685 - S 0:00.29 sshd: wynkoop@pts/0 (sshd) >> > > 678 u0 Is+ 0:00.19 /usr/libexec/getty std.9600 ttyu0 >> > > 686 0 Ss 0:00.74 -csh (csh) >> > > 831 0 R+ 0:00.16 ps ax >> > > wynkoop@beaglebone:~ % >> > > >> > > -Brett >> > > >> > >> > Hi, >> > >> > Maybe I missed a previous email, but you don't provide much >> > information for people to think about. >> > As a start you might show the 'disk wait' output. >> > >> > Ronald. >> > >> >> Ronald- >> >> From the ps man page: >> D Marks a process in disk (or other short term, >> uninterruptible) wait. >> >> >> Note all the D entries in the above ps output. >> > how I understand the system, I would say that these tasks are all > swapped out to disk. > > Erich From the ps man page: If the arguments cannot be located (usually because it has not been set, as is the case of system processes and/or kernel threads) the command name is printed within square brackets. These are system processes. Would not be very nice to have for example the pagedaemon swapped out. Ronald. From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 14:00: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 49B85997 for ; Wed, 30 Jan 2013 14:00:45 +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 14730B4F for ; Wed, 30 Jan 2013 14:00:44 +0000 (UTC) Received: from [192.168.1.102] (pool-173-77-66-239.nycmny.east.verizon.net [173.77.66.239]) (authenticated bits=0) by feynman.konjz.org (8.14.6/8.14.4) with ESMTP id r0UE0bLq015658 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 30 Jan 2013 09:00:43 -0500 (EST) (envelope-from george@ceetonetechnology.com) Message-ID: <51092781.5020806@ceetonetechnology.com> Date: Wed, 30 Jan 2013 09:00:33 -0500 From: George Rosamond MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: arm sshd dies References: <20130129143240.61bab059@ivory.lan> <1359489256.93359.162.camel@revolution.hippie.lan> <20130129150223.4e095c83@ivory.lan> <20130130053918.7fe366cb@ivory.lan> In-Reply-To: <20130130053918.7fe366cb@ivory.lan> 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, 30 Jan 2013 14:00:45 -0000 On 01/30/13 05:39, Brett Wynkoop wrote: > On Wed, 30 Jan 2013 10:34:28 +0100 > "Ronald Klop" wrote: > > >> Did you check the rotated logfiles? /var/log/messages.0.bz2, etc. >> You can use bzgrep for those. >> >> Ronald. > > No rotated /var/log/messages. So the mystery remains as I also found > no core dumps. > More details on this would be useful. Is it dying with sshd not running, or a dropped connection? sshd_config or ssh_config changes? Anything else, besides patching cpsw. (btw, a driver without a man page? ;) Does it manually restart? My BBone hasn't run for more than a few hours at a time, and I've had no issues with sshd dying, and I've run a bunch of revisions along the way on CURRENT. I'll keep an ssh session connected to the BBones sshd as a test, and see if I can replicate. g From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 14:17: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 521C2D6C for ; Wed, 30 Jan 2013 14:17:31 +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 8678BCCD for ; Wed, 30 Jan 2013 14:17:30 +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 r0UEHToZ090966 for ; Wed, 30 Jan 2013 07:17:30 -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 r0UEHRET023744; Wed, 30 Jan 2013 07:17:28 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: DockStar status? From: Ian Lepore To: Torfinn Ingolfsen In-Reply-To: <20130128205038.0e4eb52ba9c06c4de22f8cef@getmail.no> References: <20130128205038.0e4eb52ba9c06c4de22f8cef@getmail.no> Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Jan 2013 07:17:27 -0700 Message-ID: <1359555447.93359.230.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 14:17:31 -0000 On Mon, 2013-01-28 at 20:50 +0100, Torfinn Ingolfsen wrote: > Hello, > Nice with so many good things happening on the ARM front in FreeBSD. Thanks! > > What is the status of DockStar when it comes to FreeBSD 9.0 or 9.1? > I see that arm/162159[1] is still open, does it apply to FreeBSD 9.1 too? > > References: > 1) http://www.freebsd.org/cgi/query-pr.cgi?pr=arm/162159 I can't say for sure whether that problem is fixed in 9.x yet or not, but I'm working towards that. I suspect that some of the changes that might fix that problem haven't been merged back to 9-stable yet. My DreamPlug, which is pretty similar to a DockStar, is running well on -current these days. At work our ARM products are currently using 8.2, but we need to move forward to 9.1 very soon, so I'll be working to strengthen arm v4/v5 stability in 9-stable. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 14:25: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 EF59F1F2 for ; Wed, 30 Jan 2013 14:25:10 +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 A54D9D32 for ; Wed, 30 Jan 2013 14:25:10 +0000 (UTC) Received: from [192.168.1.102] (pool-173-77-66-239.nycmny.east.verizon.net [173.77.66.239]) (authenticated bits=0) by feynman.konjz.org (8.14.6/8.14.4) with ESMTP id r0UEP28c016682 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 30 Jan 2013 09:25:08 -0500 (EST) (envelope-from george@ceetonetechnology.com) Message-ID: <51092D3A.4060608@ceetonetechnology.com> Date: Wed, 30 Jan 2013 09:24:58 -0500 From: George Rosamond MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Some ideas on Tim's script 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, 30 Jan 2013 14:25:11 -0000 I mentioned this to Tim offline a while back, but I have some quick thoughts on options for the scripts. A bunch of us in NYC*BUG have been hacking on Soekris and Alix boards with i386 for a long while, which lays the basis for some of these thoughts. But first, with 8G images, I had to adjust the config.sh's SD_SIZE below 7900 for Kingston SD Cards to fit. I can give more specifics if desired. Anyone else experience that? In terms of /etc/fstab, I think adding tmpfs to the kernel would be useful. Without it, using md(4) for /var/log, /tmp and /var/tmp is certainly a nice way to minimize disk writes. It might also make sense to add rc_debug="YES" and rc_info="YES" to the default /etc/rc.conf. Most users are testing right now, and it's only logical for the pool of people hacking on them. And maybe to add the relevant ntpdate(8) settings to /etc/rc.conf. Once there is a consistent and official ARM pkgng repo, it would be useful to have that set in /usr/local/etc/pkg.conf On that note: in the absence of USB and the ability to use it to do ports stuff on the BBone itself, any decent ARM package repositories out there? I've seen some moving through this list. pkgbeta.freebsd.org no longer contains ARM, only i386/amd64. Any ideas why? And again, thanks enormously for the work everyone has done. It's appreciated wider and further than I think anyone realizes. As some of you may know, we established contacts with CircuitCo who offered their software engineer's ear. Ping me offlist if you want to contact him. George From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 14:37: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 09756556 for ; Wed, 30 Jan 2013 14:37:08 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by mx1.freebsd.org (Postfix) with ESMTP id C2AACDB0 for ; Wed, 30 Jan 2013 14:37:07 +0000 (UTC) Received: by mail-qe0-f52.google.com with SMTP id 6so724652qeb.25 for ; Wed, 30 Jan 2013 06:37:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=+N4ml71haEVMcDF1us2n3Cu272gwGobfzZiHd6b4hTg=; b=cA4MvFRgOhl2mGbnoCddxcMSpDqv+xqnnmq2/Y0vasgZRz7aT1H2A/fBQk/lOT2OMA PA2zWo/sPPv7piDQnuabmN7CUbmvZ7KhV8i+3qm5ZBiuq8VfmfvKMQqqfyGosdMJT8bm zRyze3rfQu643sz61sGq50ZZPoeLKyeoArqTszsjXrQiAOIKpd00iWwWtadWfxBvMCCu n90bq6CjbjTfYB5mO2rwbE9yYsOEjB/zuUIOkaTJgiw2VIofWQutrAfovMUJEUp4ttAi J/JABp9Rf81ZWhf3Dma3O/BpbExtesiBs2iKGfntpGy887pqomGRcZGODa/3FlZeKkX/ fsEA== MIME-Version: 1.0 X-Received: by 10.224.39.210 with SMTP id h18mr5218702qae.15.1359556621291; Wed, 30 Jan 2013 06:37:01 -0800 (PST) Received: by 10.49.2.72 with HTTP; Wed, 30 Jan 2013 06:37:01 -0800 (PST) In-Reply-To: <51092781.5020806@ceetonetechnology.com> References: <20130129143240.61bab059@ivory.lan> <1359489256.93359.162.camel@revolution.hippie.lan> <20130129150223.4e095c83@ivory.lan> <20130130053918.7fe366cb@ivory.lan> <51092781.5020806@ceetonetechnology.com> Date: Wed, 30 Jan 2013 22:37:01 +0800 Message-ID: Subject: Re: arm sshd dies From: Alie Tan To: "george@ceetonetechnology.com" X-Gm-Message-State: ALoCoQm3xXTZeNWhIPIvy+WcQ9L/0nhNV/ZCoLTi99Fh1Ll9mthC6SPMob57W5GrheyOMQOP0jN9 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 14:37:08 -0000 Hi On Wednesday, January 30, 2013, George Rosamond < george@ceetonetechnology.com> wrote: > On 01/30/13 05:39, Brett Wynkoop wrote: >> >> On Wed, 30 Jan 2013 10:34:28 +0100 >> "Ronald Klop" wrote: >> >> >>> Did you check the rotated logfiles? /var/log/messages.0.bz2, etc. >>> You can use bzgrep for those. >>> >>> Ronald. >> >> No rotated /var/log/messages. So the mystery remains as I also found >> no core dumps. >> > > More details on this would be useful. > > Is it dying with sshd not running, or a dropped connection? > > sshd_config or ssh_config changes? Anything else, besides patching cpsw. > > (btw, a driver without a man page? ;) > > Does it manually restart? > > My BBone hasn't run for more than a few hours at a time, and I've had no issues with sshd dying, and I've run a bunch of revisions along the way on CURRENT. > > I'll keep an ssh session connected to the BBones sshd as a test, and see if I can replicate. > Not sure if sshd is dying. Have you tried ping to your BBone @brett? I cant ping my bbone for my case after compiling big port like lang/php5. I will check again on Thursday with the latest HEAD and new cpsw driver from Tim. > g > _______________________________________________ > 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 Jan 30 14:39:03 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 949115D3 for ; Wed, 30 Jan 2013 14:39:03 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by mx1.freebsd.org (Postfix) with ESMTP id 47B91DC6 for ; Wed, 30 Jan 2013 14:39:03 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id z4so967485qan.19 for ; Wed, 30 Jan 2013 06:38:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=Zn3lH7lFWSrXNRnxykjgPWKRyX7mAhPl0rs7zQME2y0=; b=ltST5pZRhd7uY9GxcGgf13KVDMBMC+7q3Xgvkc7xngSMHQPFtcrHLgbMU3GlctD4q+ kLt3fpqEmdhbOIBtPVe2luNyjtL6hSKAjK/fvcnXauZcPsIHF7aZNbST3XspVibM+7Te xx5y983POgaabPSO2NhF7ksjcRvkjXlRmiMyHgNEwxELOeP+MHZ+iSK/FiwfhmiJHF86 +2eD6/41VAVy1bRJaIT6OrfrUyXcGvGEBOk1B1lgq/QpKlpTZLSJx8nXOHqDI1Yt9W/X kb8m2z1vAeho7me/GInPZi0vBVbFMtnQ/pLh6WV4VUKt66T7BwZUOUUxN+KYO12+YpA/ b4wQ== MIME-Version: 1.0 X-Received: by 10.49.105.73 with SMTP id gk9mr5992383qeb.40.1359556319484; Wed, 30 Jan 2013 06:31:59 -0800 (PST) Received: by 10.49.2.72 with HTTP; Wed, 30 Jan 2013 06:31:59 -0800 (PST) In-Reply-To: <51092D3A.4060608@ceetonetechnology.com> References: <51092D3A.4060608@ceetonetechnology.com> Date: Wed, 30 Jan 2013 22:31:59 +0800 Message-ID: Subject: Re: Some ideas on Tim's script From: Alie Tan To: "george@ceetonetechnology.com" X-Gm-Message-State: ALoCoQkHCRZX/DY3q5z0qR0EfzwTa1EEKx63Vm3a+xe0YXXamInx5VcfAQ3hPnutkVoegYz0XnNO Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 14:39:03 -0000 Hi On Wednesday, January 30, 2013, George Rosamond < george@ceetonetechnology.com> wrote: > I mentioned this to Tim offline a while back, but I have some quick thoughts on options for the scripts. > > A bunch of us in NYC*BUG have been hacking on Soekris and Alix boards with i386 for a long while, which lays the basis for some of these thoughts. > > But first, with 8G images, I had to adjust the config.sh's SD_SIZE below 7900 for Kingston SD Cards to fit. I can give more specifics if desired. Anyone else experience that? You can use diskinfo to get sector size and disk size in sector. I would like to recommed to use sector for SD_SIZE. So you can automate SD_SIZE value. > > In terms of /etc/fstab, I think adding tmpfs to the kernel would be useful. Without it, using md(4) for /var/log, /tmp and /var/tmp is certainly a nice way to minimize disk writes. > > It might also make sense to add rc_debug="YES" and rc_info="YES" to the default /etc/rc.conf. Most users are testing right now, and it's only logical for the pool of people hacking on them. > > And maybe to add the relevant ntpdate(8) settings to /etc/rc.conf. > > Once there is a consistent and official ARM pkgng repo, it would be useful to have that set in /usr/local/etc/pkg.conf > > On that note: in the absence of USB and the ability to use it to do ports stuff on the BBone itself, any decent ARM package repositories out there? I've seen some moving through this list. > > pkgbeta.freebsd.org no longer contains ARM, only i386/amd64. Any ideas why? > > And again, thanks enormously for the work everyone has done. It's appreciated wider and further than I think anyone realizes. As some of you may know, we established contacts with CircuitCo who offered their software engineer's ear. Ping me offlist if you want to contact him. > > George > > _______________________________________________ > 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 Jan 30 15:47:52 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 92A1C29A for ; Wed, 30 Jan 2013 15:47:52 +0000 (UTC) (envelope-from nealie@kobudo.homeunix.net) Received: from nicandneal.net (nicandneal.net [194.231.42.198]) by mx1.freebsd.org (Postfix) with ESMTP id E3B35229 for ; Wed, 30 Jan 2013 15:47:51 +0000 (UTC) Received: from [10.0.0.10] ([194.231.42.198]) (AUTH: PLAIN nealie, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by nicandneal.net with ESMTPSA; Wed, 30 Jan 2013 16:40:48 +0100 id 00045027.0000000051093F00.00011970 From: Neal Nelson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Raspberry Pi No Login Date: Wed, 30 Jan 2013 16:42:40 +0100 Message-Id: <09931DEF-C90A-4E72-B5EE-02BB0C6A8588@kobudo.homeunix.net> 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: Wed, 30 Jan 2013 15:47:52 -0000 HI. I'm able to build a bootable FreeBSD image using the beaglebone scripts, = which I understand is the accepted way at the moment.=20 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. Regards, Neal.= From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 15:56:05 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 956F969B for ; Wed, 30 Jan 2013 15:56:05 +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 586082C4 for ; Wed, 30 Jan 2013 15:56:05 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0UFu1PA087964; Wed, 30 Jan 2013 10:56:01 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 30 Jan 2013 10:56:01 -0500 From: Brett Wynkoop To: Erich Dollansky Subject: Re: disk wait mystery Message-ID: <20130130105601.3413fd92@ivory.lan> In-Reply-To: <20130130175236.402435ce@X220.ovitrap.com> References: <20130130001849.7669e033@ivory.lan> <20130130053729.0c9e018f@ivory.lan> <20130130175236.402435ce@X220.ovitrap.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 Cc: freebsd-arm@freebsd.org, Ronald Klop 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, 30 Jan 2013 15:56:05 -0000 On Wed, 30 Jan 2013 17:52:36 +0700 Erich Dollansky wrote: > how I understand the system, I would say that these tasks are all > swapped out to disk. > > Erich Probably not swapped out: wynkoop@beaglebone:~ % pstat -s Device 1K-blocks Used Avail Capacity /dev/md0 788480 184 788296 0% wynkoop@beaglebone:~ % I think Oliver must have hit upon the right answer, as I do see similar results on my other FreeBSD boxes. I just never really paid attention to it as my other boxes are running many more things and are swapping. Thanks Oliver. Too bad kernel threads that are busy show up as disk wait when no disk i/o is involved. Well in that fantasy land where I am a kernel hacker (LOL) I guess I can code in a different code for non-disk based waits! -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 Wed Jan 30 16:01: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 7B8648C4 for ; Wed, 30 Jan 2013 16:01:41 +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 1D568305 for ; Wed, 30 Jan 2013 16:01:40 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0UG1cZ8088052; Wed, 30 Jan 2013 11:01:38 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 30 Jan 2013 11:01:38 -0500 From: Brett Wynkoop To: george@ceetonetechnology.com Subject: Re: Some ideas on Tim's script Message-ID: <20130130110138.62b4570e@ivory.lan> In-Reply-To: <51092D3A.4060608@ceetonetechnology.com> References: <51092D3A.4060608@ceetonetechnology.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 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, 30 Jan 2013 16:01:41 -0000 On Wed, 30 Jan 2013 09:24:58 -0500 George Rosamond wrote: > I mentioned this to Tim offline a while back, but I have some quick > thoughts on options for the scripts. > > A bunch of us in NYC*BUG have been hacking on Soekris and Alix boards > with i386 for a long while, which lays the basis for some of these > thoughts. > > But first, with 8G images, I had to adjust the config.sh's SD_SIZE > below 7900 for Kingston SD Cards to fit. I can give more specifics > if desired. Anyone else experience that? > No problem with my microsd card, but I do not recall what brand it is and I do not want to shut down the board to check. > In terms of /etc/fstab, I think adding tmpfs to the kernel would be > useful. Without it, using md(4) for /var/log, /tmp and /var/tmp is > certainly a nice way to minimize disk writes. > I agree that tmpfs in the kernel would be good for the above. > It might also make sense to add rc_debug="YES" and rc_info="YES" to > the default /etc/rc.conf. Most users are testing right now, and it's > only logical for the pool of people hacking on them. > > And maybe to add the relevant ntpdate(8) settings to /etc/rc.conf. One of the first things I did was put ntpdate into startup, but for boards not connected to the net that will create a several second hang. -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 Wed Jan 30 16:05: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 E63BE9AD for ; Wed, 30 Jan 2013 16:05:30 +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 91B43339 for ; Wed, 30 Jan 2013 16:05:30 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0UG5Tbu088094; Wed, 30 Jan 2013 11:05:29 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 30 Jan 2013 11:05:29 -0500 From: Brett Wynkoop To: "Ronald Klop" Subject: Re: disk wait mystery Message-ID: <20130130110529.5c5df516@ivory.lan> In-Reply-To: References: <20130130001849.7669e033@ivory.lan> <20130130053729.0c9e018f@ivory.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: 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, 30 Jan 2013 16:05:31 -0000 On Wed, 30 Jan 2013 12:01:42 +0100 "Ronald Klop" wrote: > Aha. My amd64 has the same. I think the ps man page is not very > clear. The code src/bin/ps/print.c says this. > > case SSLEEP: > if (tdflags & TDF_SINTR) /* interruptable > (long) */ *cp = k->ki_p->ki_slptime >= MAXSLP ? 'I' : 'S'; > else > *cp = 'D'; > break; > > No mention about disks. Just an uninterruptible sleep (which can be a > wait for a disk, but also for other type of > alarms/interrupts/locks/etc.). So you have waiting kernel > threads/processes. Which is called 'idle'. > > Ronald. Ronald- Thanks for the code snippit. I should have thought to look at the sources for ps! When the documentation fails look at the source. Silly me! I appreciate the education on this point! I wonder if this should be considered a man page bug? -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 Wed Jan 30 16:11:53 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 A3EFFB7 for ; Wed, 30 Jan 2013 16:11:53 +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 665B7388 for ; Wed, 30 Jan 2013 16:11:52 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0UGBpOM088172; Wed, 30 Jan 2013 11:11:51 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 30 Jan 2013 11:11:51 -0500 From: Brett Wynkoop To: george@ceetonetechnology.com Subject: Re: arm sshd dies Message-ID: <20130130111151.3fd5e464@ivory.lan> In-Reply-To: <51092781.5020806@ceetonetechnology.com> References: <20130129143240.61bab059@ivory.lan> <1359489256.93359.162.camel@revolution.hippie.lan> <20130129150223.4e095c83@ivory.lan> <20130130053918.7fe366cb@ivory.lan> <51092781.5020806@ceetonetechnology.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 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, 30 Jan 2013 16:11:53 -0000 On Wed, 30 Jan 2013 09:00:33 -0500 George Rosamond wrote: > > More details on this would be useful. > > Is it dying with sshd not running, or a dropped connection? The master sshd process dies. Sshd processes that are part of active connections do not seem to die. I have kept ssh connections to the bone for days after applying the first round of patches to the cpsw driver (now part of head). > > sshd_config or ssh_config changes? Anything else, besides patching > cpsw. Nope no other changes. > > (btw, a driver without a man page? ;) > > Does it manually restart? Yep I can jump on the console and /etc/rc.d/sshd start with no problem. > > My BBone hasn't run for more than a few hours at a time, and I've had > no issues with sshd dying, and I've run a bunch of revisions along > the way on CURRENT. > Mine runs 24/7 at this point and is really hungry for usb so it can be building the various ports it wants installed! Please no comments on using nfs. I do not have the ability to do that at the moment. > I'll keep an ssh session connected to the BBones sshd as a test, and > see if I can replicate. No need to keep a session open. Just let your bone stay up and running and then check back at a later time to see if sshd is still running. -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 Wed Jan 30 16:14:38 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 D947C113 for ; Wed, 30 Jan 2013 16:14:38 +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 97ADE3C8 for ; Wed, 30 Jan 2013 16:14:38 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0UGEZIt088184; Wed, 30 Jan 2013 11:14:35 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 30 Jan 2013 11:14:35 -0500 From: Brett Wynkoop To: Alie Tan Subject: Re: arm sshd dies Message-ID: <20130130111435.521cf8ac@ivory.lan> In-Reply-To: References: <20130129143240.61bab059@ivory.lan> <1359489256.93359.162.camel@revolution.hippie.lan> <20130129150223.4e095c83@ivory.lan> <20130130053918.7fe366cb@ivory.lan> <51092781.5020806@ceetonetechnology.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 Cc: "george@ceetonetechnology.com" , "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, 30 Jan 2013 16:14:38 -0000 On Wed, 30 Jan 2013 22:37:01 +0800 Alie Tan wrote: > Not sure if sshd is dying. Have you tried ping to your BBone @brett? > > I cant ping my bbone for my case after compiling big port like > lang/php5. I will check again on Thursday with the latest HEAD and > new cpsw driver from Tim. Alie- Yep I am sure that sshd is dying. ps ax shows no sshd running when this happens, and the box can be pinged. Beyond that /etc/rc.d/sshd start does not complain about a running sshd. -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 Wed Jan 30 16:16: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 4F14F1FF; Wed, 30 Jan 2013 16:16:36 +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 101033EC; Wed, 30 Jan 2013 16:16:35 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0UGGYZu088218; Wed, 30 Jan 2013 11:16:34 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 30 Jan 2013 11:16:34 -0500 From: Brett Wynkoop To: Ian Lepore Subject: Re: DockStar status? Message-ID: <20130130111634.5d248443@ivory.lan> In-Reply-To: <1359555447.93359.230.camel@revolution.hippie.lan> References: <20130128205038.0e4eb52ba9c06c4de22f8cef@getmail.no> <1359555447.93359.230.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: 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, 30 Jan 2013 16:16:36 -0000 On Wed, 30 Jan 2013 07:17:27 -0700 Ian Lepore wrote: > At work our ARM products are currently using 8.2, but we need to move > forward to 9.1 very soon, so I'll be working to strengthen arm v4/v5 > stability in 9-stable. > > -- Ian > Greeting- What cool toys do you build using FreeBSD/ARM at work? Is it anything any of us might use either at home or on our jobs? -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 Wed Jan 30 16:28: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 39995C05 for ; Wed, 30 Jan 2013 16:28:40 +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 ADE156E0 for ; Wed, 30 Jan 2013 16:28:39 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 4E81F39E56; Thu, 31 Jan 2013 01:28:38 +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 39F2639D62; Thu, 31 Jan 2013 01:28:38 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: "Mats Mellstrand" References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> In-Reply-To: <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Date: Thu, 31 Jan 2013 01:28:50 +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 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, 30 Jan 2013 16:28:40 -0000 > 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, -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 16:30:04 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 2BC7CD40 for ; Wed, 30 Jan 2013 16:30:04 +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 E7962700 for ; Wed, 30 Jan 2013 16:30:03 +0000 (UTC) Received: from [192.168.1.102] (pool-173-77-66-239.nycmny.east.verizon.net [173.77.66.239]) (authenticated bits=0) by feynman.konjz.org (8.14.6/8.14.4) with ESMTP id r0UGTrut039934 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 30 Jan 2013 11:29:58 -0500 (EST) (envelope-from george@ceetonetechnology.com) Message-ID: <51094A7A.4010705@ceetonetechnology.com> Date: Wed, 30 Jan 2013 11:29:46 -0500 From: George Rosamond MIME-Version: 1.0 To: Brett Wynkoop Subject: Re: Some ideas on Tim's script References: <51092D3A.4060608@ceetonetechnology.com> <20130130110138.62b4570e@ivory.lan> In-Reply-To: <20130130110138.62b4570e@ivory.lan> 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 Cc: freebsd-arm@freebsd.org 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, 30 Jan 2013 16:30:04 -0000 On 01/30/13 11:01, Brett Wynkoop wrote: > On Wed, 30 Jan 2013 09:24:58 -0500 > George Rosamond wrote: > >> I mentioned this to Tim offline a while back, but I have some quick >> thoughts on options for the scripts. >> >> A bunch of us in NYC*BUG have been hacking on Soekris and Alix boards >> with i386 for a long while, which lays the basis for some of these >> thoughts. >> >> But first, with 8G images, I had to adjust the config.sh's SD_SIZE >> below 7900 for Kingston SD Cards to fit. I can give more specifics >> if desired. Anyone else experience that? >> > > No problem with my microsd card, but I do not recall what brand it is > and I do not want to shut down the board to check. > >> In terms of /etc/fstab, I think adding tmpfs to the kernel would be >> useful. Without it, using md(4) for /var/log, /tmp and /var/tmp is >> certainly a nice way to minimize disk writes. >> > > I agree that tmpfs in the kernel would be good for the above. I haven't had issues with tmpfs even on 7.4, so I assume it's fine on CURRENT > >> It might also make sense to add rc_debug="YES" and rc_info="YES" to >> the default /etc/rc.conf. Most users are testing right now, and it's >> only logical for the pool of people hacking on them. >> >> And maybe to add the relevant ntpdate(8) settings to /etc/rc.conf. > > One of the first things I did was put ntpdate into startup, but for > boards not connected to the net that will create a several second hang. As bad as dhclient in rc? ;o My angle is making troubleshooting easier (as above with rc_debug and rc_info) and also easing the adoption of the script as a tool for newer users. g From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 16:34: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 93992245 for ; Wed, 30 Jan 2013 16:34:05 +0000 (UTC) (envelope-from andrew@ugh.net.au) Received: from starbug.ugh.net.au (starbug.ugh.net.au [202.3.36.37]) by mx1.freebsd.org (Postfix) with ESMTP id 37B8176C for ; Wed, 30 Jan 2013 16:34:04 +0000 (UTC) Received: from [10.0.0.16] (77-64-237-200.dynamic.primacom.net [77.64.237.200]) by starbug.ugh.net.au (Postfix) with ESMTPSA id 9B863386C57; Thu, 31 Jan 2013 04:56:07 +1100 (EST) Subject: Re: disk wait mystery Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Andrew In-Reply-To: <20130130110529.5c5df516@ivory.lan> Date: Wed, 30 Jan 2013 17:24:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8EF6F73D-05AF-4E04-968B-84F35CD0FD85@ugh.net.au> References: <20130130001849.7669e033@ivory.lan> <20130130053729.0c9e018f@ivory.lan> <20130130110529.5c5df516@ivory.lan> To: Brett Wynkoop X-Mailer: Apple Mail (2.1085) Cc: freebsd-arm@freebsd.org, Ronald Klop 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, 30 Jan 2013 16:34:05 -0000 On 30 Jan 2013, at 17:05, Brett Wynkoop wrote: > I appreciate the education on this point! I wonder if this should be > considered a man page bug? The man page does say "(or other short term, uninterruptible) wait". I = don't know what sort of wait the kernel threads may or may not be in but = if they are in one, and its short-term then the man page is correct. = Maybe an FAQ entry though. Andrew= From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 16:57: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 2E8EDC70 for ; Wed, 30 Jan 2013 16:57: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 CFF868BB for ; Wed, 30 Jan 2013 16:57:46 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0UGvdlv088688; Wed, 30 Jan 2013 11:57:39 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 30 Jan 2013 11:57:39 -0500 From: Brett Wynkoop To: Neal Nelson Subject: Re: Raspberry Pi No Login Message-ID: <20130130115739.193f306d@ivory.lan> In-Reply-To: <09931DEF-C90A-4E72-B5EE-02BB0C6A8588@kobudo.homeunix.net> References: <09931DEF-C90A-4E72-B5EE-02BB0C6A8588@kobudo.homeunix.net> 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: Wed, 30 Jan 2013 16:57:47 -0000 On Wed, 30 Jan 2013 16:42:40 +0100 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). Greeting- It sounds like you do not have a getty running on the port you are connecting to for the console. I found out the hard way that it may not be known as /dev/console. Try to boot single user. If that works then do a tty to get the name of the port and edit /etc/ttys to start a getty on that port when the system goes multiuser. -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 Wed Jan 30 17:15:35 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 2AFE230D for ; Wed, 30 Jan 2013 17:15:35 +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 082D19C5 for ; Wed, 30 Jan 2013 17:15:34 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r0UHFPVx048113; Wed, 30 Jan 2013 17:15:25 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 9k5db5iinh57mqaneeftr9kq2e; Wed, 30 Jan 2013 17:15:25 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Raspberry Pi No Login Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <09931DEF-C90A-4E72-B5EE-02BB0C6A8588@kobudo.homeunix.net> Date: Wed, 30 Jan 2013 09:15:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <09931DEF-C90A-4E72-B5EE-02BB0C6A8588@kobudo.homeunix.net> To: Neal Nelson 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, 30 Jan 2013 17:15:35 -0000 On Jan 30, 2013, at 7:42 AM, Neal Nelson wrote: > HI. >=20 > I'm able to build a bootable FreeBSD image using the beaglebone = scripts, which I understand is the accepted way at the moment.=20 >=20 > 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). >=20 > 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? Tim From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 17:28:21 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 6A6134CC for ; Wed, 30 Jan 2013 17:28:21 +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 CC6DFA50 for ; Wed, 30 Jan 2013 17:28:20 +0000 (UTC) Received: by ext.mellstrand.net Wed, 30 Jan 2013 17:28:13 GMT Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 From: Mats Mellstrand X-Priority: 3 In-Reply-To: Date: Wed, 30 Jan 2013 18:28:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> To: Daisuke Aoyama 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, 30 Jan 2013 17:28:21 -0000 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. >=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). Thanks! The interface run0/wlan0 works fine with IPv6 /mm >=20 > Thanks, > --=20 > Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 17:39:23 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 A67D687A for ; Wed, 30 Jan 2013 17:39:23 +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 340B3ACB for ; Wed, 30 Jan 2013 17:39:18 +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 r0UHdIWY093279 for ; Wed, 30 Jan 2013 10:39:18 -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 r0UHdFnu023965; Wed, 30 Jan 2013 10:39:15 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Some ideas on Tim's script From: Ian Lepore To: Brett Wynkoop In-Reply-To: <20130130110138.62b4570e@ivory.lan> References: <51092D3A.4060608@ceetonetechnology.com> <20130130110138.62b4570e@ivory.lan> Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Jan 2013 10:39:15 -0700 Message-ID: <1359567555.93359.250.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: george@ceetonetechnology.com, 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, 30 Jan 2013 17:39:23 -0000 On Wed, 2013-01-30 at 11:01 -0500, Brett Wynkoop wrote: > On Wed, 30 Jan 2013 09:24:58 -0500 > George Rosamond wrote: > > > I mentioned this to Tim offline a while back, but I have some quick > > thoughts on options for the scripts. > > > > A bunch of us in NYC*BUG have been hacking on Soekris and Alix boards > > with i386 for a long while, which lays the basis for some of these > > thoughts. > > > > But first, with 8G images, I had to adjust the config.sh's SD_SIZE > > below 7900 for Kingston SD Cards to fit. I can give more specifics > > if desired. Anyone else experience that? > > > > No problem with my microsd card, but I do not recall what brand it is > and I do not want to shut down the board to check. > Look in /var/run/dmesg.boot for this line: mmcsd0: 1876MB That's the manufacturer info (SD = sandisk in this case). The number (48, its base-10) is the manufacturer ID, which you can look up on websites when you don't recognize the initials. > > In terms of /etc/fstab, I think adding tmpfs to the kernel would be > > useful. Without it, using md(4) for /var/log, /tmp and /var/tmp is > > certainly a nice way to minimize disk writes. > > > > I agree that tmpfs in the kernel would be good for the above. > > > It might also make sense to add rc_debug="YES" and rc_info="YES" to > > the default /etc/rc.conf. Most users are testing right now, and it's > > only logical for the pool of people hacking on them. > > > > And maybe to add the relevant ntpdate(8) settings to /etc/rc.conf. > > One of the first things I did was put ntpdate into startup, but for > boards not connected to the net that will create a several second hang. Better than ntpdate is to set ntpd_enable and ntpd_sync_on_start to YES. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 17:47: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 7BDB6B85 for ; Wed, 30 Jan 2013 17:47:30 +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 55AE6B24 for ; Wed, 30 Jan 2013 17:47:30 +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 r0UHlTwU093379 for ; Wed, 30 Jan 2013 10:47:29 -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 r0UHlRdm023975; Wed, 30 Jan 2013 10:47:27 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: DockStar status? From: Ian Lepore To: Brett Wynkoop In-Reply-To: <20130130111634.5d248443@ivory.lan> References: <20130128205038.0e4eb52ba9c06c4de22f8cef@getmail.no> <1359555447.93359.230.camel@revolution.hippie.lan> <20130130111634.5d248443@ivory.lan> Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Jan 2013 10:47:27 -0700 Message-ID: <1359568047.93359.256.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 17:47:30 -0000 On Wed, 2013-01-30 at 11:16 -0500, Brett Wynkoop wrote: > On Wed, 30 Jan 2013 07:17:27 -0700 > Ian Lepore wrote: > > > > At work our ARM products are currently using 8.2, but we need to move > > forward to 9.1 very soon, so I'll be working to strengthen arm v4/v5 > > stability in 9-stable. > > > > -- Ian > > > Greeting- > > What cool toys do you build using FreeBSD/ARM at work? Is it anything > any of us might use either at home or on our jobs? Nothing designed for consumers / end-users. We make precision timing gear that shows up in server rooms at ISPs, in cell towers, flying on satellites, in the metrology laboratories of various nations, that sort of thing. If you need a stable time source that drifts no more than a few nanoseconds within a 24 hour period, or need to serve hundreds of thousands of NTP and PTP packets per second, we've got you covered. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 17:56:38 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 A117AEC1; Wed, 30 Jan 2013 17:56:38 +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 54FAABE4; Wed, 30 Jan 2013 17:56:37 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0UHuYkJ089332; Wed, 30 Jan 2013 12:56:34 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 30 Jan 2013 12:56:34 -0500 From: Brett Wynkoop To: Ian Lepore Subject: Re: Some ideas on Tim's script Message-ID: <20130130125634.362da893@ivory.lan> In-Reply-To: <1359567555.93359.250.camel@revolution.hippie.lan> References: <51092D3A.4060608@ceetonetechnology.com> <20130130110138.62b4570e@ivory.lan> <1359567555.93359.250.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: george@ceetonetechnology.com, 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, 30 Jan 2013 17:56:38 -0000 On Wed, 30 Jan 2013 10:39:15 -0700 Ian Lepore wrote: > Look in /var/run/dmesg.boot for this line: > > mmcsd0: 1876MB Good tip, which my sleep deprived brain did not think of when I wrote my reply! Thanks for the reminder. > > That's the manufacturer info (SD = sandisk in this case). The number > (48, its base-10) is the manufacturer ID, which you can look up on > websites when you don't recognize the initials. This part I did not know and I find very cool! > Better than ntpdate is to set ntpd_enable and ntpd_sync_on_start to > YES. > I made a conscious choice to not run ntpd and instead run ntpdate out of cron. Why? I wanted cron for other reasons anyway, so doing ntpdate once an hour seemed lighter weight than running cron and ntpd both all the time. I might be wrong, but that was the thought process. The discussions on this list seem to always exercise my brain! It is great interacting with all of you on these matters! -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 Wed Jan 30 18:03: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 C2382125; Wed, 30 Jan 2013 18:03:45 +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 85211C18; Wed, 30 Jan 2013 18:03:45 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0UI3iwb089425; Wed, 30 Jan 2013 13:03:44 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Wed, 30 Jan 2013 13:03:42 -0500 From: Brett Wynkoop To: Ian Lepore Subject: Re: DockStar status? Message-ID: <20130130130342.082ddf42@ivory.lan> In-Reply-To: <1359568047.93359.256.camel@revolution.hippie.lan> References: <20130128205038.0e4eb52ba9c06c4de22f8cef@getmail.no> <1359555447.93359.230.camel@revolution.hippie.lan> <20130130111634.5d248443@ivory.lan> <1359568047.93359.256.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: 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, 30 Jan 2013 18:03:45 -0000 On Wed, 30 Jan 2013 10:47:27 -0700 Ian Lepore wrote: > Nothing designed for consumers / end-users. We make precision timing > gear that shows up in server rooms at ISPs, in cell towers, flying on > satellites, in the metrology laboratories of various nations, that > sort of thing. If you need a stable time source that drifts no more > than a few nanoseconds within a 24 hour period, or need to serve > hundreds of thousands of NTP and PTP packets per second, we've got > you covered. > Clock-in-a-box! Way cool. Do some of these devices have wwvb or gps receivers? In the past I have been tasked with getting clock sources for clients, and you never know when that might be the case again. -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 Wed Jan 30 18:16: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 767AB900 for ; Wed, 30 Jan 2013 18:16: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 477C8D36 for ; Wed, 30 Jan 2013 18:15: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 r0UIFx0R093745 for ; Wed, 30 Jan 2013 11:15:59 -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 r0UIFvuG024012; Wed, 30 Jan 2013 11:15:57 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: DockStar status? From: Ian Lepore To: Brett Wynkoop In-Reply-To: <20130130130342.082ddf42@ivory.lan> References: <20130128205038.0e4eb52ba9c06c4de22f8cef@getmail.no> <1359555447.93359.230.camel@revolution.hippie.lan> <20130130111634.5d248443@ivory.lan> <1359568047.93359.256.camel@revolution.hippie.lan> <20130130130342.082ddf42@ivory.lan> Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Jan 2013 11:15:56 -0700 Message-ID: <1359569756.93359.260.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 18:16:00 -0000 On Wed, 2013-01-30 at 13:03 -0500, Brett Wynkoop wrote: > On Wed, 30 Jan 2013 10:47:27 -0700 > Ian Lepore wrote: > > > Nothing designed for consumers / end-users. We make precision timing > > gear that shows up in server rooms at ISPs, in cell towers, flying on > > satellites, in the metrology laboratories of various nations, that > > sort of thing. If you need a stable time source that drifts no more > > than a few nanoseconds within a 24 hour period, or need to serve > > hundreds of thousands of NTP and PTP packets per second, we've got > > you covered. > > > > Clock-in-a-box! Way cool. Do some of these devices have wwvb or gps > receivers? > > In the past I have been tasked with getting clock sources for clients, > and you never know when that might be the case again. > > -Brett > They virtually all have gps/gnss receivers. A few of them are at the other end of that pipeline -- they have an ensemble of atomic clocks and act as the ground stations generating the timing signals that eventually propagate over RF. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 22:25:27 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 18FB7AA5 for ; Wed, 30 Jan 2013 22:25:27 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by mx1.freebsd.org (Postfix) with ESMTP id AB50BA6B for ; Wed, 30 Jan 2013 22:25:26 +0000 (UTC) Received: by mail-ee0-f42.google.com with SMTP id b47so1111112eek.15 for ; Wed, 30 Jan 2013 14:25:25 -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=W7IDrXb4Q78ApFVWVsYwNq3QEHwBbyMm9oF49oPgr3w=; b=kTXB8NNegnPh8gzBMruB7JZo0/PSKHXO98ss7/k4EN/iw0qLQ/5fUwmU7E7Om9LuNo 5Ipk/m2qxiAoGAJCN7RgNK8LUHG0PAtNVC49GH6dLd7vb4ZfDGogIlW+/5Z2x76q3Fz3 zBegkZi+uNWlZM9QPpd9vZbyyjFMqCsIL3XOz8xER8escehhsrLkhxWK6Xr1vEjtLXEp L8VLTZ+4Cd0lJJhEwXHL3lwVX/IHUTgdbKbFv9Iiv8vkJW/n33xcGN1pDC1nBsyXmWN2 nBfa6yNTcEWSuN9devfzLw0pIDxe0aULVFby4wfqh6oYNi+1f+cN6dCzL8gwgNgAKdFM KOag== MIME-Version: 1.0 X-Received: by 10.14.177.1 with SMTP id c1mr19683974eem.8.1359584725385; Wed, 30 Jan 2013 14:25:25 -0800 (PST) Received: by 10.14.133.204 with HTTP; Wed, 30 Jan 2013 14:25:25 -0800 (PST) In-Reply-To: References: <09931DEF-C90A-4E72-B5EE-02BB0C6A8588@kobudo.homeunix.net> Date: Wed, 30 Jan 2013 14:25:25 -0800 Message-ID: Subject: Re: Raspberry Pi No Login From: hiren panchasara To: Tim Kientzle Content-Type: text/plain; charset=UTF-8 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, 30 Jan 2013 22:25:27 -0000 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 Hiren > > Tim > > _______________________________________________ > 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 Jan 30 22:51:44 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 19CD6ED5 for ; Wed, 30 Jan 2013 22:51:44 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id B3813B53 for ; Wed, 30 Jan 2013 22:51:43 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1U0gVB-0009E9-3s; Wed, 30 Jan 2013 14:51:35 -0800 Message-ID: <5109A3F2.7010508@bluezbox.com> Date: Wed, 30 Jan 2013 14:51:30 -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> In-Reply-To: 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: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 [...] 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: Wed, 30 Jan 2013 22:51:44 -0000 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. Linux developers assume that the problem i "lazy" CRC module and their fix is to retry these operation several times until they succeed. Daisuke's patch uses same approach. I am reluctant to commit special quirk handler for one controller, moreover I believe that it just masks symptoms and does not address root cause. Unfortunately I do not have access to Arasan's hardware specs or errata so can't confirm my assumptions. I'll try to spend some time identifying the actual source of the problem and if it yields nothing - we'll try to come up with least intrusive workaround. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 00:42:14 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9726E7F7 for ; Thu, 31 Jan 2013 00:42:14 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 40F36F86 for ; Thu, 31 Jan 2013 00:42:13 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id r0V0FuQ7095264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Jan 2013 01:15:57 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id r0V0FsE7011600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2013 01:15:54 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id r0V0Fs9f068031; Thu, 31 Jan 2013 01:15:54 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id r0V0FrBZ068030; Thu, 31 Jan 2013 01:15:53 +0100 (CET) (envelope-from ticso) Date: Thu, 31 Jan 2013 01:15:53 +0100 From: Bernd Walter To: Mats Mellstrand Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Message-ID: <20130131001553.GC67562@cicely7.cicely.de> References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 00:42:14 -0000 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. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 01:33:46 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1EE8D2D4 for ; Thu, 31 Jan 2013 01:33:46 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by mx1.freebsd.org (Postfix) with ESMTP id C86C916F for ; Thu, 31 Jan 2013 01:33:45 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id b12so1044432qca.18 for ; Wed, 30 Jan 2013 17:33:44 -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=h7Iby8Z5KH7WZ4mI7r+yl/9Akv85QuWA0zYRnPgpQsw=; b=bbHHOI97c7mQ/tj7HNrC6W+ebkqp3/DA8bPCNlXSEdYeuFfcQhBimGVFa6SPYZ75rG 3jVHHNWb2MQI5ULJI9Z4fMBTOzpc0i61IJCcOILAZ+saBmy+cvQo7uZdUxWvnMEtQu6i 32niSW28oAvb83vTEvSdTl6offoBAMzYfV3VpsVXpO03qAfhYzGfgLfnk2aOM/FVJLBl 9gHWRGwmAjgcf7bW9gpi9U1N2211tU+YnNdpDbptrSrxfVMVgunbqEl8dNXgS6+jEZOj 9xcYLQTyfL2VhPKNY00EisIkwzKwNzUMWU55839g+07x+wnxDXgoFK29yFxIPCjJNJw5 zs5A== MIME-Version: 1.0 X-Received: by 10.49.128.37 with SMTP id nl5mr8335655qeb.59.1359596024014; Wed, 30 Jan 2013 17:33:44 -0800 (PST) Received: by 10.49.51.138 with HTTP; Wed, 30 Jan 2013 17:33:43 -0800 (PST) Date: Thu, 31 Jan 2013 09:33:43 +0800 Message-ID: Subject: Error while building with man pages From: Alie Tan To: "freebsd-arm@freebsd.org" X-Gm-Message-State: ALoCoQmldGbRgI6UYSNZBXlkDSk660MiuZj3Lg+oRe2QMFHFUY2EK9C8O84M8G7fxgBnsxJlyseS 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, 31 Jan 2013 01:33:46 -0000 Hi, I got this error while build FreeBSD ARMv6 for R-PI gzip -cn /usr/src/sys/boot/arm/uboot/../../forth/beastie.4th.8 > beastie.4th.8.gz gzip -cn /usr/src/sys/boot/arm/uboot/../../forth/brand.4th.8 > brand.4th.8.gz gzip -cn /usr/src/sys/boot/arm/uboot/../../forth/check-password.4th.8 > check-password.4th.8.gz gzip -cn /usr/src/sys/boot/arm/uboot/../../forth/color.4th.8 > color.4th.8.gz gzip -cn /usr/src/sys/boot/arm/uboot/../../forth/delay.4th.8 > delay.4th.8.gz gzip -cn /usr/src/sys/boot/arm/uboot/../../forth/loader.conf.5 > loader.conf.5.gz gzip -cn /usr/src/sys/boot/arm/uboot/../../forth/loader.4th.8 > loader.4th.8.gz gzip -cn /usr/src/sys/boot/arm/uboot/../../forth/menu.4th.8 > menu.4th.8.gz gzip -cn /usr/src/sys/boot/arm/uboot/../../forth/menusets.4th.8 > menusets.4th.8.gz gzip -cn /usr/src/sys/boot/arm/uboot/../../forth/version.4th.8 > version.4th.8.gz gzip -cn /usr/src/sys/boot/arm/uboot/../../common/loader.8 > loader.8.gz cat /usr/src/sys/boot/arm/uboot/../../common/help.common /usr/src/sys/boot/arm/uboot/help.uboot | awk -f /usr/src/sys/boot/arm/uboot/../../common/merge_help.awk > loader.help tar: Error opening archive: Unrecognized archive format From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 05:14: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 A42C838C for ; Thu, 31 Jan 2013 05:14:56 +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 81CB5B09 for ; Thu, 31 Jan 2013 05:14:55 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r0V5EklH052069; Thu, 31 Jan 2013 05:14:47 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id ac4u63ryyna8hyhbd4qezfg9di; Thu, 31 Jan 2013 05:14:46 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Some ideas on Tim's script Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <51092D3A.4060608@ceetonetechnology.com> Date: Wed, 30 Jan 2013 21:14:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51092D3A.4060608@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: Thu, 31 Jan 2013 05:14:56 -0000 On Jan 30, 2013, at 6:24 AM, George Rosamond wrote: >=20 > But first, with 8G images, I had to adjust the config.sh's SD_SIZE = below 7900 for Kingston SD Cards to fit. I can give more specifics if = desired. Anyone else experience that? I have a bunch of different SD cards around here -- different sizes, different manufacturers -- and I think every one is 50MB-100MB smaller than the advertised size. > In terms of /etc/fstab, I think adding tmpfs to the kernel would be = useful. Without it, using md(4) for /var/log, /tmp and /var/tmp is = certainly a nice way to minimize disk writes. How well does this work on a machine with only 256MB RAM? > It might also make sense to add rc_debug=3D"YES" and rc_info=3D"YES" = to the default /etc/rc.conf. Most users are testing right now, and it's = only logical for the pool of people hacking on them. I wasn't aware of those options; I'll add them. One of my wish-list items is to figure out how to buildkernel with a config file stored outside of /usr/src. Then it would be possible to have a kernel config as part of the beaglebsd setup files, separate from the config in /usr/src that seems to be optimized for kernel debugging. > And maybe to add the relevant ntpdate(8) settings to /etc/rc.conf. Has anyone tried running ntpdate from devd? So that when/if the network interface initializes, ntpdate gets run at that point. That would avoid the tedious delay if there's no network at boot time. Tim From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 05:30:57 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 E5DD15A5 for ; Thu, 31 Jan 2013 05:30:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-da0-f41.google.com (mail-da0-f41.google.com [209.85.210.41]) by mx1.freebsd.org (Postfix) with ESMTP id 8D1F5B6E for ; Thu, 31 Jan 2013 05:30:57 +0000 (UTC) Received: by mail-da0-f41.google.com with SMTP id e20so1135018dak.28 for ; Wed, 30 Jan 2013 21:30:51 -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=diLR5PC9x7449P2GUptYNZObvJ9TSoTRTQ6v2Bton7I=; b=QwH8O+0oKn1sPzYlkWBObp+bkGaw+NZlTqd8TihzrcK7lNthFyK7cFNsRY+DoTD/GP C0DMYO+2KslaXCQXHg8B9AhwTlPzA+pKzdn3epm4RBpNhk/DSQ8TrcnIhdQU2AVfKNrL /RBtC32YUa4pVv8ksYX/Yi7M1vEPZ/2pfFizW+k4EpkoGe5IM71QrVEr2bAu0Z2MgwAh BURJiBHQqLZgDqx5s9kgrotqhX40L1FZWjoXvwX2Tv8jgFpuripUvoOVNwjc1WoYCNA/ aV2ZXq7Kzb3XFHx0uewh6c0huQZyMRH/2kPZZnhRjaugXsZxygksW62iyDyXAZJ+Bjb7 JEfg== X-Received: by 10.68.234.36 with SMTP id ub4mr19039603pbc.68.1359610251087; Wed, 30 Jan 2013 21:30:51 -0800 (PST) Received: from [10.0.0.53] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id sg7sm3872460pbb.3.2013.01.30.21.30.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jan 2013 21:30:50 -0800 (PST) Sender: Warner Losh Subject: Re: Some ideas on Tim's script Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 30 Jan 2013 22:30:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51092D3A.4060608@ceetonetechnology.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlehuOHr+ANAhKLJ0qH9Bu+qZj1bkyiaCMYsBA6n4yJvzAPGnNfh+94CuqpI8WcREvqrxBv Cc: george@ceetonetechnology.com, 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, 31 Jan 2013 05:30:58 -0000 On Jan 30, 2013, at 10:14 PM, Tim Kientzle wrote: > On Jan 30, 2013, at 6:24 AM, George Rosamond wrote: >>=20 >> But first, with 8G images, I had to adjust the config.sh's SD_SIZE = below 7900 for Kingston SD Cards to fit. I can give more specifics if = desired. Anyone else experience that? >=20 > I have a bunch of different SD cards around here -- different > sizes, different manufacturers -- and I think every one is > 50MB-100MB smaller than the advertised size. 8GB is 8,000,000,000 bytes. This 7812500kb or 7630MB. >=20 >> And maybe to add the relevant ntpdate(8) settings to /etc/rc.conf. >=20 > Has anyone tried running ntpdate from devd? So that when/if > the network interface initializes, ntpdate gets run at that point. > That would avoid the tedious delay if there's no network at > boot time. I've never tried it... Interesting idea... Warner From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 08:46:52 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 434DD46F for ; Thu, 31 Jan 2013 08:46:52 +0000 (UTC) (envelope-from nealie@kobudo.homeunix.net) Received: from nicandneal.net (nicandneal.net [194.231.42.198]) by mx1.freebsd.org (Postfix) with ESMTP id A16AA32E for ; Thu, 31 Jan 2013 08:46:51 +0000 (UTC) Received: from nealmac.makalumedia.loc ([80.152.243.225]) (AUTH: LOGIN nealie, TLS: TLSv1/SSLv3,256bits,CAMELLIA256-SHA) by nicandneal.net with ESMTPSA; Thu, 31 Jan 2013 09:44:53 +0100 id 00045027.00000000510A2F06.00012F71 Message-ID: <510A2F78.6070107@kobudo.homeunix.net> Date: Thu, 31 Jan 2013 09:46:48 +0100 From: Neal Nelson 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: Brett Wynkoop Subject: Re: Raspberry Pi No Login References: <09931DEF-C90A-4E72-B5EE-02BB0C6A8588@kobudo.homeunix.net> <20130130115739.193f306d@ivory.lan> In-Reply-To: <20130130115739.193f306d@ivory.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 08:46:52 -0000 On 2013-01-30 17:57 , Brett Wynkoop wrote: > On Wed, 30 Jan 2013 16:42:40 +0100 > 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). > > Greeting- > > It sounds like you do not have a getty running on the port you are > connecting to for the console. I found out the hard way that it may > not be known as /dev/console. > > Try to boot single user. If that works then do a tty to get the name > of the port and edit /etc/ttys to start a getty on that port when the > system goes multiuser. > > -Brett > I have no idea how to boot into single user mode on this thing as the boot process doesn't even pause and of course it's completely different to the usual process. I found the problem in the end: for some reason only one serial console was enabled in /etc/ttys. This seems pretty odd for the RPI since it has a nice shiny HDMI port and not easily accessible serial port, but there you go. Easily fixed. I just have to find a way to convince the build script to not do it next time. I have encountered three problems with the now nicely functional RPI: - Even though the ethernet is configured for DHCP, it is not correctly configured at boot time. I can later manually start it. - Sometimes keys are missed when I type them and sometimes they are repeated until I type something else. I haven't dared try any other USB peripherals yet. - Installing pkgng was entertaining, as of course the bootstrap failed since there is no package for this architecture, but building it from ports did work. The speed of this thing compiling takes me back to my VAX days in the 80's. I think I'll have to try and cross compile some packages. All in all I'm impressed that it's working at all on such a tiny computer. I could never have got very excited about it if I had to run Linux on it. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 09:04: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 628E3974 for ; Thu, 31 Jan 2013 09:04:12 +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 DC25B62E for ; Thu, 31 Jan 2013 09:04:11 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.1.67]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1U0q40-000E2y-B2; Thu, 31 Jan 2013 01:04:10 -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: <510A2F78.6070107@kobudo.homeunix.net> Date: Thu, 31 Jan 2013 01:03:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <09931DEF-C90A-4E72-B5EE-02BB0C6A8588@kobudo.homeunix.net> <20130130115739.193f306d@ivory.lan> <510A2F78.6070107@kobudo.homeunix.net> To: Neal Nelson 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-01-31, at 12:46 AM, Neal Nelson wrote: > On 2013-01-30 17:57 , Brett Wynkoop wrote: >> On Wed, 30 Jan 2013 16:42:40 +0100 >> 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). >> >> Greeting- >> >> It sounds like you do not have a getty running on the port you are >> connecting to for the console. I found out the hard way that it may >> not be known as /dev/console. >> >> Try to boot single user. If that works then do a tty to get the name >> of the port and edit /etc/ttys to start a getty on that port when the >> system goes multiuser. >> >> -Brett >> > > I have no idea how to boot into single user mode on this thing as the boot process doesn't even pause and of course it's completely different to the usual process. > > I found the problem in the end: for some reason only one serial console was enabled in /etc/ttys. This seems pretty odd for the RPI since it has a nice shiny HDMI port and not easily accessible serial port, but there you go. Easily fixed. I just have to find a way to convince the build script to not do it next time. > > I have encountered three problems with the now nicely functional RPI: > > - Even though the ethernet is configured for DHCP, it is not correctly configured at boot time. I can later manually start it. [...] 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: 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, 31 Jan 2013 09:04:12 -0000 On 2013-01-31, at 12:46 AM, Neal Nelson = wrote: > On 2013-01-30 17:57 , Brett Wynkoop wrote: >> On Wed, 30 Jan 2013 16:42:40 +0100 >> Neal Nelson wrote: >>=20 >>> HI. >>>=20 >>> I'm able to build a bootable FreeBSD image using the beaglebone >>> scripts, which I understand is the accepted way at the moment. >>>=20 >>> 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). >>=20 >> Greeting- >>=20 >> It sounds like you do not have a getty running on the port you are >> connecting to for the console. I found out the hard way that it may >> not be known as /dev/console. >>=20 >> Try to boot single user. If that works then do a tty to get the name >> of the port and edit /etc/ttys to start a getty on that port when the >> system goes multiuser. >>=20 >> -Brett >>=20 >=20 > I have no idea how to boot into single user mode on this thing as the = boot process doesn't even pause and of course it's completely different = to the usual process. >=20 > I found the problem in the end: for some reason only one serial = console was enabled in /etc/ttys. This seems pretty odd for the RPI = since it has a nice shiny HDMI port and not easily accessible serial = port, but there you go. Easily fixed. I just have to find a way to = convince the build script to not do it next time. >=20 > I have encountered three problems with the now nicely functional RPI: >=20 > - Even though the ethernet is configured for DHCP, it is not correctly = configured at boot time. I can later manually start it. Make sure you have either devd_enable=3D"YES" and ifconfig_ue0=3D"DHCP" = or just ifconfig_ue0=3D"SYNCDHCP" >=20 > - Sometimes keys are missed when I type them and sometimes they are = repeated until I type something else. I haven't dared try any other USB = peripherals yet. >=20 > - Installing pkgng was entertaining, as of course the bootstrap failed = since there is no package for this architecture, but building it from = ports did work. The speed of this thing compiling takes me back to my = VAX days in the 80's. I think I'll have to try and cross compile some = packages. There are some prebuilt packages you can reuse them: = http://kernelnomicon.org/?p=3D261 >=20 > All in all I'm impressed that it's working at all on such a tiny = computer. I could never have got very excited about it if I had to run = Linux on it. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 11:02:53 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 2726E1DD for ; Thu, 31 Jan 2013 11:02:53 +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 0C485B41 for ; Thu, 31 Jan 2013 11:02:53 +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 052E417F401 for ; Thu, 31 Jan 2013 11:02:51 +0000 (UTC) Message-ID: <510A4F5B.7000407@g7iii.net> Date: Thu, 31 Jan 2013 11:02:51 +0000 From: Iain Young User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: SD card -image- for the beaglebone 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: Thu, 31 Jan 2013 11:02:53 -0000 Hi Folks, I have just taken delivery of a few Beaglebones that I am intending to do some NTP Work. With FreeBSD having one of the better reputations with regards to Time and PPS etc, I thought I would install FreeBSD on at least one of them. Unfortunately, all of the guides I've found all assume you have a FreeBSD box already running. Unfortunately, I don't, and nor do I have a spare x86 box to do so. Does anyone have an *image* of a base install for a 4 Gig microSD card that I can download ? Preferably with ssh and dhcp installed (yes, I know about blowing away the keys), as that would avoid having to rely on the console. Quite happy to rebuild the kernel and world afterwards (yes, I know I need an 8 Gig SD card), but it's just this bootstrapping problem thats an issue... Best Regards Iain From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 12:33: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 DCDC2863 for ; Thu, 31 Jan 2013 12:33:20 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-ia0-x236.google.com (ia-in-x0236.1e100.net [IPv6:2607:f8b0:4001:c02::236]) by mx1.freebsd.org (Postfix) with ESMTP id AAD2014B for ; Thu, 31 Jan 2013 12:33:20 +0000 (UTC) Received: by mail-ia0-f182.google.com with SMTP id w33so3827915iag.13 for ; Thu, 31 Jan 2013 04:33:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-rim-org-msg-ref-id:message-id :content-transfer-encoding:reply-to:x-priority:sensitivity :importance:subject:to:from:date:content-type:mime-version :x-gm-message-state; bh=ffpxMggEqUsYuM46WBK9FyPed3nvpwGlkwi0b4g76uw=; b=iqyJzT3evFyyy+KxF4ct1Jz7Uf9Puwemi4g+5EaRG+KDX2ZiemYskntrf8HUx5Y0+W f2JoJnMlCem3CPstMVf5SVk1xim8osCvqhi/5gyXyRec37TvFPIxEo4+Zsal01gmnhg1 I/9wwnjM/xtqKSZi8dZjGUepWeBSl8KLoGv+SugCN4/FHo5i/LJ90tFu4mSrQXQa59Sq qWStxjHBH4U2J8r47hTuX3eP3p7ZdJJylJzVmeY7H5eCZxQVwTOeu/NPwUIkd3Dobgyp 6XyR/mpwhJlPlz744+UQPBSduQevOIitbn1S4GLL6DSo6FnaO9YbFceAJtHBELeL6HQz 6zQw== X-Received: by 10.50.180.168 with SMTP id dp8mr565443igc.32.1359635600255; Thu, 31 Jan 2013 04:33:20 -0800 (PST) Received: from 172.22.81.188 (bda-216-9-250-138.bis3.ap.blackberry.com. [216.9.250.138]) by mx.google.com with ESMTPS id xd4sm2537354igb.3.2013.01.31.04.33.18 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 31 Jan 2013 04:33:19 -0800 (PST) X-rim-org-msg-ref-id: 713802181 Message-ID: <713802181-1359635597-cardhu_decombobulator_blackberry.rim.net-495684687-@b17.c6.bise3.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal Sensitivity: Normal Importance: Normal Subject: Re: SD card -image- for the beaglebone To: "Iain Young" , owner-freebsd-arm@freebsd.org, freebsd-arm@freebsd.org From: "Alie Tan" Date: Thu, 31 Jan 2013 12:33:15 +0000 Content-Type: text/plain; charset="big5-hkscs" MIME-Version: 1.0 X-Gm-Message-State: ALoCoQk2jlCwIIkgCMTUl3INsZXN07f3MQZ1vR9PypvTwzkAP3oZk8sVo8uW2XP+WR7VgbMzVYas X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: alie@affle.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 12:33:20 -0000 SG93IGFib3V0IGhvc3RpbmcgRnJlZUJTRCBvbiBWaXJ0dWFsQm94IG9yIFZNV2FyZT8NCg0KSSBj YW4gaGVscCB0byBidWlsZCBCZWFnbGVCb25lIGltYWdlIGFuZCBzZW5kIGl0IHRvIHlvdSBvbiBG cmlkYXkgNXBtIFNTVA0KDQotLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0tDQpGcm9tOiBJYWlu IFlvdW5nDQpTZW5kZXI6IG93bmVyLWZyZWVic2QtYXJtQGZyZWVic2Qub3JnDQpUbzogZnJlZWJz ZC1hcm1AZnJlZWJzZC5vcmcNClN1YmplY3Q6IFNEIGNhcmQgLWltYWdlLSBmb3IgdGhlIGJlYWds ZWJvbmUNClNlbnQ6IEphbiAzMSwgMjAxMyA3OjAyIFBNDQoNCkhpIEZvbGtzLA0KDQpJIGhhdmUg anVzdCB0YWtlbiBkZWxpdmVyeSBvZiBhIGZldyBCZWFnbGVib25lcyB0aGF0IEkgYW0gaW50ZW5k aW5nIHRvDQpkbyBzb21lIE5UUCBXb3JrLiBXaXRoIEZyZWVCU0QgaGF2aW5nIG9uZSBvZiB0aGUg YmV0dGVyIHJlcHV0YXRpb25zDQp3aXRoIHJlZ2FyZHMgdG8gVGltZSBhbmQgUFBTIGV0YywgSSB0 aG91Z2h0IEkgd291bGQgaW5zdGFsbCBGcmVlQlNEIG9uDQphdCBsZWFzdCBvbmUgb2YgdGhlbS4N Cg0KVW5mb3J0dW5hdGVseSwgYWxsIG9mIHRoZSBndWlkZXMgSSd2ZSBmb3VuZCBhbGwgYXNzdW1l IHlvdSBoYXZlIGENCkZyZWVCU0QgYm94IGFscmVhZHkgcnVubmluZy4gVW5mb3J0dW5hdGVseSwg SSBkb24ndCwgYW5kIG5vciBkbyBJIGhhdmUNCmEgc3BhcmUgeDg2IGJveCB0byBkbyBzby4NCg0K RG9lcyBhbnlvbmUgaGF2ZSBhbiAqaW1hZ2UqIG9mIGEgYmFzZSBpbnN0YWxsIGZvciBhIDQgR2ln IG1pY3JvU0QNCmNhcmQgdGhhdCBJIGNhbiBkb3dubG9hZCA/IFByZWZlcmFibHkgd2l0aCBzc2gg YW5kIGRoY3AgaW5zdGFsbGVkDQooeWVzLCBJIGtub3cgYWJvdXQgYmxvd2luZyBhd2F5IHRoZSBr ZXlzKSwgYXMgdGhhdCB3b3VsZCBhdm9pZCBoYXZpbmcNCnRvIHJlbHkgb24gdGhlIGNvbnNvbGUu DQoNClF1aXRlIGhhcHB5IHRvIHJlYnVpbGQgdGhlIGtlcm5lbCBhbmQgd29ybGQgYWZ0ZXJ3YXJk cyAoeWVzLCBJIGtub3cgSQ0KbmVlZCBhbiA4IEdpZyBTRCBjYXJkKSwgYnV0IGl0J3MganVzdCB0 aGlzIGJvb3RzdHJhcHBpbmcgcHJvYmxlbSB0aGF0cw0KYW4gaXNzdWUuLi4NCg0KDQpCZXN0IFJl Z2FyZHMNCg0KSWFpbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCmZyZWVic2QtYXJtQGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdA0KaHR0cDovL2xpc3Rz LmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1hcm0NClRvIHVuc3Vic2NyaWJl LCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLWFybS11bnN1YnNjcmliZUBmcmVlYnNkLm9yZyIN Cg0KU2VudCB2aWEgQmxhY2tCZXJyeSBmcm9tIFNpbmdUZWwh From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 13:38:37 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 4ABEEE57 for ; Thu, 31 Jan 2013 13:38:37 +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 EDFE07EA for ; Thu, 31 Jan 2013 13:38:36 +0000 (UTC) Received: from [192.168.1.102] (pool-173-77-66-239.nycmny.east.verizon.net [173.77.66.239]) (authenticated bits=0) by feynman.konjz.org (8.14.6/8.14.4) with ESMTP id r0VDcJuG029855 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 31 Jan 2013 08:38:24 -0500 (EST) (envelope-from george@ceetonetechnology.com) Message-ID: <510A73C6.40206@ceetonetechnology.com> Date: Thu, 31 Jan 2013 08:38:14 -0500 From: George Rosamond MIME-Version: 1.0 To: Tim Kientzle Subject: Re: Some ideas on Tim's script References: <51092D3A.4060608@ceetonetechnology.com> In-Reply-To: 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 Cc: freebsd-arm@freebsd.org 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: Thu, 31 Jan 2013 13:38:37 -0000 On 01/31/13 00:14, Tim Kientzle wrote: > On Jan 30, 2013, at 6:24 AM, George Rosamond wrote: >> >> But first, with 8G images, I had to adjust the config.sh's SD_SIZE >> below 7900 for Kingston SD Cards to fit. I can give more specifics >> if desired. Anyone else experience that? > > I have a bunch of different SD cards around here -- different sizes, > different manufacturers -- and I think every one is 50MB-100MB > smaller than the advertised size. Yes. My point was only to remove potential errors for newer users running into this (easily resolvable) issue. > >> In terms of /etc/fstab, I think adding tmpfs to the kernel would be >> useful. Without it, using md(4) for /var/log, /tmp and /var/tmp is >> certainly a nice way to minimize disk writes. > > How well does this work on a machine with only 256MB RAM? Been using md for years with Soekris/Alix boards. We're not talking about huge partitions here, so it shouldn't be an issue. I'm being more than generous here with space, but: /tmp -s30m /var/log -s15m /var/tmp -s5m I haven't done port building or any make on the BeagleBone, though. But it all seems fine with pfSense and their nanoBSD setup. I have only played around with tmpfs, but I'd imagine that in CURRENT it should be in good shape. > >> It might also make sense to add rc_debug="YES" and rc_info="YES" to >> the default /etc/rc.conf. Most users are testing right now, and >> it's only logical for the pool of people hacking on them. > > I wasn't aware of those options; I'll add them. > > One of my wish-list items is to figure out how to buildkernel with a > config file stored outside of /usr/src. Then it would be possible to > have a kernel config as part of the beaglebsd setup files, separate > from the config in /usr/src that seems to be optimized for kernel > debugging. That would be nice. > >> And maybe to add the relevant ntpdate(8) settings to /etc/rc.conf. > > Has anyone tried running ntpdate from devd? So that when/if the > network interface initializes, ntpdate gets run at that point. That > would avoid the tedious delay if there's no network at boot time. not I. g From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 14:12: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 11E62972 for ; Thu, 31 Jan 2013 14:12:47 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id A4501988 for ; Thu, 31 Jan 2013 14:12:46 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r0VECjtk047933; Thu, 31 Jan 2013 07:12:45 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r0VECiXN047930; Thu, 31 Jan 2013 07:12:45 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 31 Jan 2013 07:12:44 -0700 (MST) From: Warren Block To: Andrew Subject: Re: disk wait mystery In-Reply-To: <8EF6F73D-05AF-4E04-968B-84F35CD0FD85@ugh.net.au> Message-ID: References: <20130130001849.7669e033@ivory.lan> <20130130053729.0c9e018f@ivory.lan> <20130130110529.5c5df516@ivory.lan> <8EF6F73D-05AF-4E04-968B-84F35CD0FD85@ugh.net.au> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Thu, 31 Jan 2013 07:12:45 -0700 (MST) Cc: freebsd-arm@freebsd.org, Brett Wynkoop , Ronald Klop 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, 31 Jan 2013 14:12:47 -0000 On Wed, 30 Jan 2013, Andrew wrote: > On 30 Jan 2013, at 17:05, Brett Wynkoop wrote: > >> I appreciate the education on this point! I wonder if this should be >> considered a man page bug? > > The man page does say "(or other short term, uninterruptible) wait". I > don't know what sort of wait the kernel threads may or may not be in > but if they are in one, and its short-term then the man page is > correct. Maybe an FAQ entry though. If the man page is misleading or incomplete, it should be fixed. Based on the source, the mention of disk at the start is misleading. Maybe: D Marks a process in short term, uninterruptible wait. Or D Marks a process in short term, uninterruptible wait (typically, disk wait). Which explains the "D" but may reintroduce the confusion. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 14:27: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 1DCD2C6C for ; Thu, 31 Jan 2013 14:27:01 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id E7B02A0C for ; Thu, 31 Jan 2013 14:27:00 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U0v6Q-000Nqr-7a; Thu, 31 Jan 2013 09:26:58 -0500 Date: Thu, 31 Jan 2013 09:26:58 -0500 From: Gary Palmer To: Warren Block Subject: Re: disk wait mystery Message-ID: <20130131142658.GC74563@in-addr.com> References: <20130130001849.7669e033@ivory.lan> <20130130053729.0c9e018f@ivory.lan> <20130130110529.5c5df516@ivory.lan> <8EF6F73D-05AF-4E04-968B-84F35CD0FD85@ugh.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-arm@freebsd.org, Brett Wynkoop , Ronald Klop 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, 31 Jan 2013 14:27:01 -0000 On Thu, Jan 31, 2013 at 07:12:44AM -0700, Warren Block wrote: > On Wed, 30 Jan 2013, Andrew wrote: > > > On 30 Jan 2013, at 17:05, Brett Wynkoop wrote: > > > >> I appreciate the education on this point! I wonder if this should be > >> considered a man page bug? > > > > The man page does say "(or other short term, uninterruptible) wait". I > > don't know what sort of wait the kernel threads may or may not be in > > but if they are in one, and its short-term then the man page is > > correct. Maybe an FAQ entry though. > > If the man page is misleading or incomplete, it should be fixed. Based > on the source, the mention of disk at the start is misleading. Maybe: > > D Marks a process in short term, uninterruptible wait. > > Or > > D Marks a process in short term, uninterruptible wait (typically, > disk wait). > > Which explains the "D" but may reintroduce the confusion. D Marks a process in short term, uninterruptible wait (In non-kernel processes, this is typically waiting on disk I/O) ? Gary From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 14:50: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 86F9F122 for ; Thu, 31 Jan 2013 14:50:28 +0000 (UTC) (envelope-from andrew@ugh.net.au) Received: from starbug.ugh.net.au (starbug.ugh.net.au [202.3.36.37]) by mx1.freebsd.org (Postfix) with ESMTP id 42E5AB04 for ; Thu, 31 Jan 2013 14:50:27 +0000 (UTC) Received: from [10.0.0.10] (77-64-237-200.dynamic.primacom.net [77.64.237.200]) by starbug.ugh.net.au (Postfix) with ESMTPSA id 7C8EF386C57; Fri, 1 Feb 2013 03:22:20 +1100 (EST) References: <20130130001849.7669e033@ivory.lan> <20130130053729.0c9e018f@ivory.lan> <20130130110529.5c5df516@ivory.lan> <8EF6F73D-05AF-4E04-968B-84F35CD0FD85@ugh.net.au> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3C9D4DB2-33CE-4321-9B82-F0A1713591F0@ugh.net.au> X-Mailer: iPhone Mail (10B144) From: Andrew Stevenson Subject: Re: disk wait mystery Date: Thu, 31 Jan 2013 15:50:18 +0100 To: Warren Block Cc: "freebsd-arm@freebsd.org" , Brett Wynkoop , Ronald Klop 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, 31 Jan 2013 14:50:28 -0000 On 31 Jan 2013, at 15:12, Warren Block wrote: > If the man page is misleading or incomplete, it should be fixed. I agree. I think the discussion is just if it is misleading or incomplete.=20= > Based on the source, the mention of disk at the start is misleading. I'm not sure I follow your reasoning here. Maybe the brackets are unnecessar= y grammatically but I don't think they change the meaning of the sentence. A= s long as the processes in question were indeed in a short term uninterrupti= ble wait the man page seems to be completely correct. I assume you see the s= entence as having a different meaning though I'm afraid despite re-reading I= still can't see an alternative interpretation.=20 Anyway I don't want to get into a bike shed debate. I think the man page has= described the presumed situation quite well but if others want it changed t= o something else I don't mind as long as its no worse than what we have now.= =20 Andrew= From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 15:02: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 2F688456; Thu, 31 Jan 2013 15:02:02 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id AB591BF4; Thu, 31 Jan 2013 15:02:01 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r0VF217V023478; Thu, 31 Jan 2013 08:02:01 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r0VF21I6023475; Thu, 31 Jan 2013 08:02:01 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 31 Jan 2013 08:02:01 -0700 (MST) From: Warren Block To: Gary Palmer Subject: Re: disk wait mystery In-Reply-To: <20130131142658.GC74563@in-addr.com> Message-ID: References: <20130130001849.7669e033@ivory.lan> <20130130053729.0c9e018f@ivory.lan> <20130130110529.5c5df516@ivory.lan> <8EF6F73D-05AF-4E04-968B-84F35CD0FD85@ugh.net.au> <20130131142658.GC74563@in-addr.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Thu, 31 Jan 2013 08:02:01 -0700 (MST) Cc: freebsd-arm@freebsd.org, Brett Wynkoop , Ronald Klop 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, 31 Jan 2013 15:02:02 -0000 On Thu, 31 Jan 2013, Gary Palmer wrote: > On Thu, Jan 31, 2013 at 07:12:44AM -0700, Warren Block wrote: >> On Wed, 30 Jan 2013, Andrew wrote: >> >>> On 30 Jan 2013, at 17:05, Brett Wynkoop wrote: >>> >>>> I appreciate the education on this point! I wonder if this should be >>>> considered a man page bug? >>> >>> The man page does say "(or other short term, uninterruptible) wait". I >>> don't know what sort of wait the kernel threads may or may not be in >>> but if they are in one, and its short-term then the man page is >>> correct. Maybe an FAQ entry though. >> >> If the man page is misleading or incomplete, it should be fixed. Based >> on the source, the mention of disk at the start is misleading. Maybe: >> >> D Marks a process in short term, uninterruptible wait. >> >> Or >> >> D Marks a process in short term, uninterruptible wait (typically, >> disk wait). >> >> Which explains the "D" but may reintroduce the confusion. > > D Marks a process in short term, uninterruptible wait (In non-kernel > processes, this is typically waiting on disk I/O) The followup question that creates is "what are kernel threads waiting on?" Which is covered by the uninterruptable part earlier. I think the "typically" handles it without creating more questions. Leaving out the redundant "Marks a process" wording: D Disk wait, or other short-term, uninterruptable wait. "disk wait" was the original term in that man page. "Also shown for uninterruptable kernel threads." is just repeating. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 15:07: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 8E793A2D for ; Thu, 31 Jan 2013 15:07:06 +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 1AE82CFB for ; Thu, 31 Jan 2013 15:07:05 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id EBD1839E09; Fri, 1 Feb 2013 00:06:57 +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 D709339D62; Fri, 1 Feb 2013 00:06:57 +0900 (JST) Message-ID: <9E78813F3BF946A4A2FCEA2C363A847E@ad.peach.ne.jp> From: "Daisuke Aoyama" To: , "Mats Mellstrand" References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> <20130131001553.GC67562@cicely7.cicely.de> In-Reply-To: <20130131001553.GC67562@cicely7.cicely.de> Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Date: Fri, 1 Feb 2013 00:07:15 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0592_01CE0010.17B1FB60" 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 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, 31 Jan 2013 15:07:06 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0592_01CE0010.17B1FB60 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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. ------=_NextPart_000_0592_01CE0010.17B1FB60 Content-Type: application/octet-stream; name="smsc.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="smsc.patch" Index: if_smsc.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- if_smsc.c (revision 246066)=0A= +++ if_smsc.c (working copy)=0A= @@ -948,6 +948,7 @@=0A= struct usb_ether *ue =3D &sc->sc_ue;=0A= struct ifnet *ifp =3D uether_getifp(ue);=0A= struct mbuf *m;=0A= + struct ether_header *eh;=0A= struct usb_page_cache *pc;=0A= uint32_t rxhdr;=0A= uint16_t pktlen;=0A= @@ -1006,6 +1007,7 @@=0A= }=0A= =0A= usbd_copy_out(pc, off, mtod(m, uint8_t *), pktlen);=0A= + eh =3D mtod(m, struct ether_header *);=0A= =0A= /* Check if RX TCP/UDP checksumming is being offloaded */=0A= if ((ifp->if_capenable & IFCAP_RXCSUM) !=3D 0) {=0A= @@ -1021,7 +1023,7 @@=0A= * ignore the H/W csum on frames less than or equal to=0A= * 64 bytes.=0A= */=0A= - if (pktlen > ETHER_MIN_LEN) {=0A= + if (be16toh(eh->ether_type) =3D=3D ETHERTYPE_IP && pktlen > = ETHER_MIN_LEN) {=0A= =0A= /* Indicate the UDP/TCP csum has been calculated */=0A= m->m_pkthdr.csum_flags |=3D CSUM_DATA_VALID;=0A= ------=_NextPart_000_0592_01CE0010.17B1FB60-- From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 15:17:32 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 AC155C4F for ; Thu, 31 Jan 2013 15:17:32 +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 01CE2D80 for ; Thu, 31 Jan 2013 15:17:31 +0000 (UTC) Received: by ext.mellstrand.net Thu, 31 Jan 2013 15:17:22 GMT Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 From: Mats Mellstrand X-Priority: 3 In-Reply-To: <9E78813F3BF946A4A2FCEA2C363A847E@ad.peach.ne.jp> Date: Thu, 31 Jan 2013 16:17:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: 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: Thu, 31 Jan 2013 15:17:32 -0000 Hi Thanks!=20 Your patch works fine! /mm On 31 jan 2013, at 16:07, Daisuke Aoyama wrote: > 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. >>> > >>> > 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=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 >>> > >>> > 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. > From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 15:30: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 2DD37C0 for ; Thu, 31 Jan 2013 15:30: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 B70BDE0C for ; Thu, 31 Jan 2013 15:30: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 r0VFTsVf009947 for ; Thu, 31 Jan 2013 08:29:54 -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 r0VFTnGo025037; Thu, 31 Jan 2013 08:29:49 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Some ideas on Tim's script From: Ian Lepore To: Tim Kientzle In-Reply-To: References: <51092D3A.4060608@ceetonetechnology.com> Content-Type: multipart/mixed; boundary="=-2T4AvHBEPDaCwLWN6ERc" Date: Thu, 31 Jan 2013 08:29:49 -0700 Message-ID: <1359646189.93359.323.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: george@ceetonetechnology.com, 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, 31 Jan 2013 15:30:01 -0000 --=-2T4AvHBEPDaCwLWN6ERc Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, 2013-01-30 at 21:14 -0800, Tim Kientzle wrote: > On Jan 30, 2013, at 6:24 AM, George Rosamond wrote: > > > > But first, with 8G images, I had to adjust the config.sh's SD_SIZE below 7900 for Kingston SD Cards to fit. I can give more specifics if desired. Anyone else experience that? > > I have a bunch of different SD cards around here -- different > sizes, different manufacturers -- and I think every one is > 50MB-100MB smaller than the advertised size. > > > In terms of /etc/fstab, I think adding tmpfs to the kernel would be useful. Without it, using md(4) for /var/log, /tmp and /var/tmp is certainly a nice way to minimize disk writes. > > How well does this work on a machine with only 256MB RAM? At work we use an md disk for /tmp (and often for /var with /tmp linked to /var/tmp) on units with only 64mb of ram. We typically use 4mb for combined /var and /tmp, but the kind of stuff we run isn't hungry for temp space. > > It might also make sense to add rc_debug="YES" and rc_info="YES" to the default /etc/rc.conf. Most users are testing right now, and it's only logical for the pool of people hacking on them. > > I wasn't aware of those options; I'll add them. > > One of my wish-list items is to figure out how to buildkernel > with a config file stored outside of /usr/src. Then it would > be possible to have a kernel config as part of the > beaglebsd setup files, separate from the config in /usr/src > that seems to be optimized for kernel debugging. > Symlink the config into the arm/conf dir. When I create a sandbox for playing with a given unit (RPi, BeagleBone, etc) the hierarchy is: bsdstaging/ bbone/ ... dplug/ ... rpi/ mk config/ RPI-B-SERIAL make.conf src.conf nfsroot/ obj/ patches/ src/ 'mk' is a script that sets up environment stuff, does a cd into src/ and runs make. The script symlinks $(pwd)/config/RPI-B-SERIAL into src/sys/arm/conf, sets MAKEOBJDIR to $(pwd)/obj, DESTDIR to $(pwd)/nfsroot, and launches make with a command line so that config/make.conf and config/src.conf and KERNCONF= are all set up to use the items in config/. The nfsroot dir is nullfs-mounted at the nfs export mountpoint that's configured as the dhcp-served root dir for that unit. Right now I've got lots of almost-identical copies of this script, one per project I'm working on. Soon enough the commonalities will become clear and I'll standardize it into my ~/bin directory. It's not a big complicated script at all, I'll attach it. > > And maybe to add the relevant ntpdate(8) settings to /etc/rc.conf. > > Has anyone tried running ntpdate from devd? So that when/if > the network interface initializes, ntpdate gets run at that point. > That would avoid the tedious delay if there's no network at > boot time. > I think ntpd may be a better solution. If you set ntpd_enable and ntpd_sync_on_start to YES, ntpd will background itself immediately and set the clock as soon as it reaches a server. The downsides are a bit of syslog spam as it whines periodically about not finding its peers until the network shows up, and of course at some point a minute or two after the network is connected, the clock is going to make a big jump forward, and some apps don't react well to that. -- Ian --=-2T4AvHBEPDaCwLWN6ERc-- From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 15:34: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 34C17151; Thu, 31 Jan 2013 15:34:01 +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 E6028E3D; Thu, 31 Jan 2013 15:34:00 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0VFXxPT005529; Thu, 31 Jan 2013 10:33:59 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Thu, 31 Jan 2013 10:34:01 -0500 From: Brett Wynkoop To: Gary Palmer Subject: Re: disk wait mystery Message-ID: <20130131103401.1a3e0c6c@ivory.lan> In-Reply-To: <20130131142658.GC74563@in-addr.com> References: <20130130001849.7669e033@ivory.lan> <20130130053729.0c9e018f@ivory.lan> <20130130110529.5c5df516@ivory.lan> <8EF6F73D-05AF-4E04-968B-84F35CD0FD85@ugh.net.au> <20130131142658.GC74563@in-addr.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 Cc: freebsd-arm@freebsd.org, Ronald Klop 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, 31 Jan 2013 15:34:01 -0000 On Thu, 31 Jan 2013 09:26:58 -0500 Gary Palmer wrote: > > D Marks a process in short term, uninterruptible wait (In > non-kernel processes, this is typically waiting on disk I/O) > I find the above the most clear version. -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 Thu Jan 31 15:36:23 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 6CAA82B9 for ; Thu, 31 Jan 2013 15:36:23 +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 17F4DE5E for ; Thu, 31 Jan 2013 15:36:17 +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 r0VFaGgM010048 for ; Thu, 31 Jan 2013 08:36:16 -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 r0VFaETM025050; Thu, 31 Jan 2013 08:36:14 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: SD card -image- for the beaglebone From: Ian Lepore To: Iain Young In-Reply-To: <510A4F5B.7000407@g7iii.net> References: <510A4F5B.7000407@g7iii.net> Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Jan 2013 08:36:14 -0700 Message-ID: <1359646574.93359.327.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 15:36:23 -0000 On Thu, 2013-01-31 at 11:02 +0000, Iain Young wrote: > Hi Folks, > > I have just taken delivery of a few Beaglebones that I am intending to > do some NTP Work. With FreeBSD having one of the better reputations > with regards to Time and PPS etc, I thought I would install FreeBSD on > at least one of them. > > Unfortunately, all of the guides I've found all assume you have a > FreeBSD box already running. Unfortunately, I don't, and nor do I have > a spare x86 box to do so. > > Does anyone have an *image* of a base install for a 4 Gig microSD > card that I can download ? Preferably with ssh and dhcp installed > (yes, I know about blowing away the keys), as that would avoid having > to rely on the console. > > Quite happy to rebuild the kernel and world afterwards (yes, I know I > need an 8 Gig SD card), but it's just this bootstrapping problem thats > an issue... > So you're interested in a PPS driver for BeagleBone? That would be fun to play with, I wonder what the BB's timer hardware looks like? It'd be easy enough to do with a gpio interrupt I suspect, but the timing geek in me can't resist going for the nanosecond-accurate measurements when possible, even if it is kind of pointless for millisecond-accurate NTP. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 15:55:54 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 9321484B; Thu, 31 Jan 2013 15:55:54 +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 ACC9AF6E; Thu, 31 Jan 2013 15:55: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 r0VFthGH010276; Thu, 31 Jan 2013 08:55: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 r0VFtfPP025065; Thu, 31 Jan 2013 08:55:41 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: disk wait mystery From: Ian Lepore To: Warren Block In-Reply-To: References: <20130130001849.7669e033@ivory.lan> <20130130053729.0c9e018f@ivory.lan> <20130130110529.5c5df516@ivory.lan> <8EF6F73D-05AF-4E04-968B-84F35CD0FD85@ugh.net.au> <20130131142658.GC74563@in-addr.com> Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Jan 2013 08:55:41 -0700 Message-ID: <1359647741.93359.335.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 , Ronald Klop 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, 31 Jan 2013 15:55:54 -0000 On Thu, 2013-01-31 at 08:02 -0700, Warren Block wrote: > On Thu, 31 Jan 2013, Gary Palmer wrote: > > > On Thu, Jan 31, 2013 at 07:12:44AM -0700, Warren Block wrote: > >> On Wed, 30 Jan 2013, Andrew wrote: > >> > >>> On 30 Jan 2013, at 17:05, Brett Wynkoop wrote: > >>> > >>>> I appreciate the education on this point! I wonder if this should be > >>>> considered a man page bug? > >>> > >>> The man page does say "(or other short term, uninterruptible) wait". I > >>> don't know what sort of wait the kernel threads may or may not be in > >>> but if they are in one, and its short-term then the man page is > >>> correct. Maybe an FAQ entry though. > >> > >> If the man page is misleading or incomplete, it should be fixed. Based > >> on the source, the mention of disk at the start is misleading. Maybe: > >> > >> D Marks a process in short term, uninterruptible wait. > >> > >> Or > >> > >> D Marks a process in short term, uninterruptible wait (typically, > >> disk wait). > >> > >> Which explains the "D" but may reintroduce the confusion. > > > > D Marks a process in short term, uninterruptible wait (In non-kernel > > processes, this is typically waiting on disk I/O) > > The followup question that creates is "what are kernel threads waiting > on?" Which is covered by the uninterruptable part earlier. I think the > "typically" handles it without creating more questions. > > Leaving out the redundant "Marks a process" wording: > > D Disk wait, or other short-term, uninterruptable wait. > > "disk wait" was the original term in that man page. "Also shown for > uninterruptable kernel threads." is just repeating. If there's going to be any attempt to reconcile the use of the letter 'D' I think the term "device" would be more accurate these days than "disk". >From a glance at the code, I think this state would be reported for any userland thread that's sleeping in a driver that called one of the sleep(9) family functions without the PCATCH flag which allows signals to interrput the sleep so they can be delivered to userland. For kernel threads I think the PCATCH part is moot and it's just a thread in a "short" sleep (for some definition of short). -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 15:58:15 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 487BD8B9; Thu, 31 Jan 2013 15:58:15 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 0DA12F8F; Thu, 31 Jan 2013 15:58:14 +0000 (UTC) Received: from [38.105.238.108] (port=64751 helo=[10.7.1.235]) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1U0wWk-0005of-3E; Thu, 31 Jan 2013 10:58:14 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: SD card -image- for the beaglebone From: George Neville-Neil In-Reply-To: <1359646574.93359.327.camel@revolution.hippie.lan> Date: Thu, 31 Jan 2013 10:58:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <510A4F5B.7000407@g7iii.net> <1359646574.93359.327.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com 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, 31 Jan 2013 15:58:15 -0000 On Jan 31, 2013, at 10:36 , Ian Lepore wrote: > On Thu, 2013-01-31 at 11:02 +0000, Iain Young wrote: >> Hi Folks, >>=20 >> I have just taken delivery of a few Beaglebones that I am intending = to >> do some NTP Work. With FreeBSD having one of the better reputations >> with regards to Time and PPS etc, I thought I would install FreeBSD = on >> at least one of them. >>=20 >> Unfortunately, all of the guides I've found all assume you have a >> FreeBSD box already running. Unfortunately, I don't, and nor do I = have >> a spare x86 box to do so. >>=20 >> Does anyone have an *image* of a base install for a 4 Gig microSD >> card that I can download ? Preferably with ssh and dhcp installed >> (yes, I know about blowing away the keys), as that would avoid having >> to rely on the console. >>=20 >> Quite happy to rebuild the kernel and world afterwards (yes, I know I >> need an 8 Gig SD card), but it's just this bootstrapping problem = thats >> an issue... >>=20 >=20 > So you're interested in a PPS driver for BeagleBone? That would be = fun > to play with, I wonder what the BB's timer hardware looks like? It'd = be > easy enough to do with a gpio interrupt I suspect, but the timing geek > in me can't resist going for the nanosecond-accurate measurements when > possible, even if it is kind of pointless for millisecond-accurate = NTP. >=20 Ah, but PTPd would be very happy with nanosecond accuracy. The biggest problem I see in PTPd on something like a BeagleBone is the network interface. We need to get that cleaned up and then see how much jitter = it has. Best, George From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 16:19:27 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 854D9FF8; Thu, 31 Jan 2013 16:19:27 +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 34A21116; Thu, 31 Jan 2013 16:19:26 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0VGJPYD006022; Thu, 31 Jan 2013 11:19:26 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Thu, 31 Jan 2013 11:19:25 -0500 From: Brett Wynkoop To: Ian Lepore Subject: Re: disk wait mystery Message-ID: <20130131111925.60433329@ivory.lan> In-Reply-To: <1359647741.93359.335.camel@revolution.hippie.lan> References: <20130130001849.7669e033@ivory.lan> <20130130053729.0c9e018f@ivory.lan> <20130130110529.5c5df516@ivory.lan> <8EF6F73D-05AF-4E04-968B-84F35CD0FD85@ugh.net.au> <20130131142658.GC74563@in-addr.com> <1359647741.93359.335.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: freebsd-arm@freebsd.org, Ronald Klop 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, 31 Jan 2013 16:19:27 -0000 On Thu, 31 Jan 2013 08:55:41 -0700 Ian Lepore wrote: > >From a glance at the code, I think this state would be reported for > >any > userland thread that's sleeping in a driver that called one of the > sleep(9) family functions without the PCATCH flag which allows signals > to interrput the sleep so they can be delivered to userland. For > kernel threads I think the PCATCH part is moot and it's just a thread > in a "short" sleep (for some definition of short). > Greeting- Reading this makes all clear to a simple sys admin like me. So I now think the man page should read DEVICE WAIT instead of DISK WAIT.......who know all these years diskwait in ps was not diskwait. I can go back to bed now. I already learned something today! -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 Thu Jan 31 16:29: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 1636E33B; Thu, 31 Jan 2013 16:29:41 +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 C335919D; Thu, 31 Jan 2013 16:29:40 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0VGTd2P006142; Thu, 31 Jan 2013 11:29:39 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Thu, 31 Jan 2013 11:29:39 -0500 From: Brett Wynkoop To: Ian Lepore Subject: Re: Some ideas on Tim's script Message-ID: <20130131112939.08738159@ivory.lan> In-Reply-To: <1359646189.93359.323.camel@revolution.hippie.lan> References: <51092D3A.4060608@ceetonetechnology.com> <1359646189.93359.323.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: 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, 31 Jan 2013 16:29:41 -0000 On Thu, 31 Jan 2013 08:29:49 -0700 Ian Lepore wrote: > > I think ntpd may be a better solution. If you set ntpd_enable and > ntpd_sync_on_start to YES, ntpd will background itself immediately and > set the clock as soon as it reaches a server. The downsides are a bit > of syslog spam as it whines periodically about not finding its peers > until the network shows up, and of course at some point a minute or > two after the network is connected, the clock is going to make a big > jump forward, and some apps don't react well to that. > > -- Ian > Or we can forget time setting all together and set time by hand at initial boot, then take the system down every Sunday morning for backup to 9 track tape and reset the clock! I am sorry. I could not resist. I just got to thinking how back in the early 1980s when I was working with PDP 11/70s and Pyramid Super Micros that were as big as refrigerators. They were more than an order of magnitude less powerful than the Bone. So it sort of puts into perspective my personal frustration of a box without a built in RTC. I have to say to myself "What more do you need on a board that fits in your shirt pocket?" What a wonderful problem to have...trying to figure out how to set the time on a BeagleBone! -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 Thu Jan 31 18:04:14 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8761BB35 for ; Thu, 31 Jan 2013 18:04:14 +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 4A5BA895 for ; Thu, 31 Jan 2013 18:04:14 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id l10so3301369oag.30 for ; Thu, 31 Jan 2013 10:04:07 -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=KZB2oYY94UZjJUT4mPYl0nCpNW+utC7yjV5XG4JaGzk=; b=hF2pWrneGLrtY4C6W3g1wpwanvkaxHA4qKxqABlhCV7ROeReYBGs5TM/wS0mfAVt/K fRnuQ9hZsfoiXmwIs6S6vIcpoKuEZvLL9QOAfqTDlaAH6Kz6mY+TVVx+XbFHTgL8ytb7 nqefve9qmbz928X9q3teNlzjs2RGkl1zSSZKl3uWlPEAF6r3C0jQbLfkN7gf+a0opB7G S2vxaaNjMhVvZk1wiM+i3ErYGXi38fa10xq+4/KldzXgStQceO0R3xeS/8iNuc12uhJW tg3NRZoiQ/A09o1FY6N6fHvTcbsfvAG/tewKmkvSj4+x+28wuEZ0PkPWwHp8Kw0NA57h WzRw== X-Received: by 10.60.172.84 with SMTP id ba20mr7192993oec.10.1359655447668; Thu, 31 Jan 2013 10:04:07 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id e1sm6460249oef.4.2013.01.31.10.04.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jan 2013 10:04:06 -0800 (PST) Sender: Warner Losh Subject: Re: SD card -image- for the beaglebone Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1359646574.93359.327.camel@revolution.hippie.lan> Date: Thu, 31 Jan 2013 11:04:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <510A4F5B.7000407@g7iii.net> <1359646574.93359.327.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmnXs8axPxWCv8Y7rJwpMACPWTYtvIcX35TZ56LPt9nSI6zM/6fqJYz6p6ntqykazXawH5I 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, 31 Jan 2013 18:04:14 -0000 On Jan 31, 2013, at 8:36 AM, Ian Lepore wrote: > On Thu, 2013-01-31 at 11:02 +0000, Iain Young wrote: >> Hi Folks, >>=20 >> I have just taken delivery of a few Beaglebones that I am intending = to >> do some NTP Work. With FreeBSD having one of the better reputations >> with regards to Time and PPS etc, I thought I would install FreeBSD = on >> at least one of them. >>=20 >> Unfortunately, all of the guides I've found all assume you have a >> FreeBSD box already running. Unfortunately, I don't, and nor do I = have >> a spare x86 box to do so. >>=20 >> Does anyone have an *image* of a base install for a 4 Gig microSD >> card that I can download ? Preferably with ssh and dhcp installed >> (yes, I know about blowing away the keys), as that would avoid having >> to rely on the console. >>=20 >> Quite happy to rebuild the kernel and world afterwards (yes, I know I >> need an 8 Gig SD card), but it's just this bootstrapping problem = thats >> an issue... >>=20 >=20 > So you're interested in a PPS driver for BeagleBone? That would be = fun > to play with, I wonder what the BB's timer hardware looks like? It'd = be > easy enough to do with a gpio interrupt I suspect, but the timing geek > in me can't resist going for the nanosecond-accurate measurements when > possible, even if it is kind of pointless for millisecond-accurate = NTP. You can drive ntpd's accuracy to microsecond or tens of microseconds = with appropriate hardware. nanosecond accuracy help to steer the = frequency estimate the kernel uses for time keeping, but that only helps = a little since its frequency estimates are computed over hundreds of = seconds. Warner= From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 19:24: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 8A3B5E2A for ; Thu, 31 Jan 2013 19:24:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2DAF2CB3 for ; Thu, 31 Jan 2013 19:24:31 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0VJORrN089446 for ; Thu, 31 Jan 2013 21:24:27 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0VJORrN089446 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0VJORAH089445 for arm@freebsd.org; Thu, 31 Jan 2013 21:24:27 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 31 Jan 2013 21:24:27 +0200 From: Konstantin Belousov To: arm@freebsd.org Subject: bud_dmamap_load_buffer() Message-ID: <20130131192426.GL2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z4nOpqXAzw5l7GJN" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home 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, 31 Jan 2013 19:24:31 -0000 --z4nOpqXAzw5l7GJN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I noted that arm/busdma_machdep.c uses essentially inlined pmap_kextract() to get the physical address from the kernel address. I consulted with gonzo, who said that he does not see a reason for inlining the code. My theory is that before r240983, pmap_kextract() locked the pmap, which caused unneeded and probably wrong locking in the busdma load path. Since this issue is fixed, I see no reason for directly walking the page tables. Could somebody please review and test the patch ? v6 busdma already uses pmap_kextract(). Do not remove me from Cc:. diff --git a/sys/arm/arm/busdma_machdep.c b/sys/arm/arm/busdma_machdep.c index 42566e8..8f49300 100644 --- a/sys/arm/arm/busdma_machdep.c +++ b/sys/arm/arm/busdma_machdep.c @@ -849,9 +849,6 @@ bus_dmamap_load_buffer(bus_dma_tag_t dmat, bus_dma_segm= ent_t *segs, vm_offset_t vaddr =3D (vm_offset_t)buf; int seg; int error =3D 0; - pd_entry_t *pde; - pt_entry_t pte; - pt_entry_t *ptep; =20 lastaddr =3D *lastaddrp; bmask =3D ~(dmat->boundary - 1); @@ -873,29 +870,7 @@ bus_dmamap_load_buffer(bus_dma_tag_t dmat, bus_dma_seg= ment_t *segs, * XXX in user address space. */ if (__predict_true(pmap =3D=3D pmap_kernel())) { - if (pmap_get_pde_pte(pmap, vaddr, &pde, &ptep) =3D=3D FALSE) - return (EFAULT); - - if (__predict_false(pmap_pde_section(pde))) { - if (*pde & L1_S_SUPERSEC) - curaddr =3D (*pde & L1_SUP_FRAME) | - (vaddr & L1_SUP_OFFSET); - else - curaddr =3D (*pde & L1_S_FRAME) | - (vaddr & L1_S_OFFSET); - } else { - pte =3D *ptep; - KASSERT((pte & L2_TYPE_MASK) !=3D L2_TYPE_INV, - ("INV type")); - if (__predict_false((pte & L2_TYPE_MASK) - =3D=3D L2_TYPE_L)) { - curaddr =3D (pte & L2_L_FRAME) | - (vaddr & L2_L_OFFSET); - } else { - curaddr =3D (pte & L2_S_FRAME) | - (vaddr & L2_S_OFFSET); - } - } + curaddr =3D pmap_kextract(vaddr); } else { curaddr =3D pmap_extract(pmap, vaddr); map->flags &=3D ~DMAMAP_COHERENT; --z4nOpqXAzw5l7GJN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRCsTqAAoJEJDCuSvBvK1BTzwQAIPcEMlx85tOGNMkVWIOdEvn nJb2ZJJQ0OP71A/g7K2Clp5aygAnaC+qdGot/dgTf+g84oywwJkwR961esJYDbb0 pBad/klFPlsZBVv4SC8kzBe4+h16u+jXREmGQeoPi3yOuDx3VMm9twV2awjRQTJg GeMO5tsvyJCBKmK4hapxTXTp18UKfPYMyyvblTXGw+wXUYaXWiUrbUC4kZofxA6z 1bwYKcpmNXD6XQ/Lw3zX1/n0R1ku62jvtKzSUbY8nne7lwmRgCNcGRZYOqZq8Tu7 LPc3F70S7cYKHhDfSHFpH7QC1L/7ztflhczYLxCgRLG52LeBX3NhT9HACMZQn50U /MM9Qd097NqC7JNJde/Dwj2nKyHZjieIFOHwGTPxDzV1fnVpIk8QteTk1j+JmU5Q VB/YXe0mul7bE0PDb39F/pFVB0CU9xV/QmQgsQ9YMA7Fc0WBm5Za7TL+u+d3k9O6 yVoNxEbP1gp7z+QQLAk4TxTb8A8ZGYcNkm9+AuDJVOqO9MmAD0Ny6JIi1C89divE l0HI4b2ZXHRmL+ZTHuXn++Dx1lHm676vHU9Tc8IMUughxzioQjSqeoaLoSVmPcHt LCq1GGdqZpl2uTD2D48rnJL/zI3cpigZsHQTlnfXyCIRrl6MR6lOSI49aDcczgE6 qF2WLIXeraiuBEo4TFMs =eoIV -----END PGP SIGNATURE----- --z4nOpqXAzw5l7GJN-- From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 20:16:47 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 E5BEAFC7 for ; Thu, 31 Jan 2013 20:16:47 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:150:ca0a:a9ff:fef1:a4c9]) by mx1.freebsd.org (Postfix) with ESMTP id 888B8F11 for ; Thu, 31 Jan 2013 20:16:47 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.5/8.14.5) with ESMTP id r0VKGNAY058205; Thu, 31 Jan 2013 21:16:23 +0100 (CET) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.5/8.14.5/Submit) id r0VKGN0r058204; Thu, 31 Jan 2013 21:16:23 +0100 (CET) (envelope-from mlfbsd) Date: Thu, 31 Jan 2013 21:16:23 +0100 From: Olivier Houchard To: Konstantin Belousov Subject: Re: bud_dmamap_load_buffer() Message-ID: <20130131201623.GA58163@ci0.org> References: <20130131192426.GL2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130131192426.GL2522@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 20:16:48 -0000 On Thu, Jan 31, 2013 at 09:24:27PM +0200, Konstantin Belousov wrote: > I noted that arm/busdma_machdep.c uses essentially inlined pmap_kextract() > to get the physical address from the kernel address. I consulted with > gonzo, who said that he does not see a reason for inlining the code. > > My theory is that before r240983, pmap_kextract() locked the pmap, which > caused unneeded and probably wrong locking in the busdma load path. Since > this issue is fixed, I see no reason for directly walking the page tables. > > Could somebody please review and test the patch ? v6 busdma already uses > pmap_kextract(). > > Do not remove me from Cc:. Hi Konstantin, It's that way for historical reasons. It used to check the caching attributes of the page, as well as its physical address, to try hard to avoid doing unnecessery cache flush if the page is already mapped as uncache. Now that code is long gone, and there's no reason anymore not to just use pmap_kextract(). Your patch looks fine to me. Regards, Olivier From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 20:32:22 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 C92B1519 for ; Thu, 31 Jan 2013 20:32:22 +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 F068AF9C for ; Thu, 31 Jan 2013 20:32:21 +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 r0VKWKhG013710 for ; Thu, 31 Jan 2013 13:32: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 r0VKWIRi025306; Thu, 31 Jan 2013 13:32:18 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: bud_dmamap_load_buffer() From: Ian Lepore To: Olivier Houchard In-Reply-To: <20130131201623.GA58163@ci0.org> References: <20130131192426.GL2522@kib.kiev.ua> <20130131201623.GA58163@ci0.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Jan 2013 13:32:17 -0700 Message-ID: <1359664337.93359.337.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , 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, 31 Jan 2013 20:32:22 -0000 On Thu, 2013-01-31 at 21:16 +0100, Olivier Houchard wrote: > On Thu, Jan 31, 2013 at 09:24:27PM +0200, Konstantin Belousov wrote: > > I noted that arm/busdma_machdep.c uses essentially inlined pmap_kextract() > > to get the physical address from the kernel address. I consulted with > > gonzo, who said that he does not see a reason for inlining the code. > > > > My theory is that before r240983, pmap_kextract() locked the pmap, which > > caused unneeded and probably wrong locking in the busdma load path. Since > > this issue is fixed, I see no reason for directly walking the page tables. > > > > Could somebody please review and test the patch ? v6 busdma already uses > > pmap_kextract(). > > > > Do not remove me from Cc:. > > Hi Konstantin, > > It's that way for historical reasons. It used to check the caching attributes > of the page, as well as its physical address, to try hard to avoid doing > unnecessery cache flush if the page is already mapped as uncache. Now that > code is long gone, and there's no reason anymore not to just use > pmap_kextract(). Your patch looks fine to me. > > Regards, > > Olivier That would help explain that XXX comment about checking coherent mappings in user maps that never made much sense to me. I think we should delete the comment now as well. I've applied and tested the patch, it's working fine. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 21:27:57 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 F004F8B6 for ; Thu, 31 Jan 2013 21:27:57 +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 D2BDF28F for ; Thu, 31 Jan 2013 21:27:57 +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 BC77E17F402 for ; Thu, 31 Jan 2013 21:27:50 +0000 (UTC) Message-ID: <510AE1D6.8010203@g7iii.net> Date: Thu, 31 Jan 2013 21:27:50 +0000 From: Iain Young User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-arm@FreeBSD.org Subject: Re: SD card -image- for the beaglebone References: <510A4F5B.7000407@g7iii.net> <1359646574.93359.327.camel@revolution.hippie.lan> In-Reply-To: <1359646574.93359.327.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: Thu, 31 Jan 2013 21:27:58 -0000 On 31/01/13 15:36, Ian Lepore wrote: > So you're interested in a PPS driver for BeagleBone? That would be fun > to play with, I wonder what the BB's timer hardware looks like? It'd be > easy enough to do with a gpio interrupt I suspect, but the timing geek > in me can't resist going for the nanosecond-accurate measurements when > possible, even if it is kind of pointless for millisecond-accurate NTP. Yep. Planning on hooking up MSF, DCF, and TDF clocks to GPIO pins, as well as some GPS units. Originally planned for doing this with some Pi, but found the bone had serial ports and things developed from there Planning on abusing UART3's CTS pin for initial basic testing, as radioclkd and radioclkd2 have only support for serial ports, but then it will be working out what if anything I need to patch into the kernel to get the PPS subsystem to listen to particular GPIO pins. Also planning to test PHK's ntpns, which has DCF support, and should be easy to modify for MSF. Anyway, this is heading far too quickly to being on-topic for time-nuts but off-topic here Iain From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 21:44:26 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 6C020AA2 for ; Thu, 31 Jan 2013 21:44:26 +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 161F3321 for ; Thu, 31 Jan 2013 21:44:19 +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 r0VLiIQC014548 for ; Thu, 31 Jan 2013 14:44:19 -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 r0VLiGJO025356; Thu, 31 Jan 2013 14:44:16 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: SD card -image- for the beaglebone From: Ian Lepore To: Iain Young In-Reply-To: <510AE1D6.8010203@g7iii.net> References: <510A4F5B.7000407@g7iii.net> <1359646574.93359.327.camel@revolution.hippie.lan> <510AE1D6.8010203@g7iii.net> Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Jan 2013 14:44:16 -0700 Message-ID: <1359668656.93359.339.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 21:44:26 -0000 On Thu, 2013-01-31 at 21:27 +0000, Iain Young wrote: > On 31/01/13 15:36, Ian Lepore wrote: > > > So you're interested in a PPS driver for BeagleBone? That would be fun > > to play with, I wonder what the BB's timer hardware looks like? It'd be > > easy enough to do with a gpio interrupt I suspect, but the timing geek > > in me can't resist going for the nanosecond-accurate measurements when > > possible, even if it is kind of pointless for millisecond-accurate NTP. > > Yep. Planning on hooking up MSF, DCF, and TDF clocks to GPIO pins, as > well as some GPS units. Originally planned for doing this with some > Pi, but found the bone had serial ports and things developed from there > > Planning on abusing UART3's CTS pin for initial basic testing, as > radioclkd and radioclkd2 have only support for serial ports, but > then it will be working out what if anything I need to patch into the > kernel to get the PPS subsystem to listen to particular GPIO pins. > > Also planning to test PHK's ntpns, which has DCF support, > and should be easy to modify for MSF. Anyway, this is heading far > too quickly to being on-topic for time-nuts but off-topic here You might be surprised how many time nuts read this list, several of us do it for a living. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 21:47: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 63136B08 for ; Thu, 31 Jan 2013 21:47: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 2B19333F for ; Thu, 31 Jan 2013 21:47:09 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r0VLkxhT009469 for ; Thu, 31 Jan 2013 16:46:59 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Thu, 31 Jan 2013 16:46:59 -0500 From: Brett Wynkoop To: freebsd-arm@freebsd.org Subject: off topic EIS (Extreme Ice Survey) Message-ID: <20130131164659.41f47a8e@ivory.lan> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-apple-darwin10.8.0) Importance: high X-Priority: 1 (Highest) 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: Thu, 31 Jan 2013 21:47:12 -0000 Greeting- Since I spent date night last week in a hotel in Belmont California reading the "Pilots Operating Handbook - Zlin Savage Cub". My wife decided last night we had to take a 2 hour break from our toils for some make up time. She took me to a documentary film "Chasing Ice". I was totally engaged through the whole film, which was in large part about the technical and organizational challenges in putting together the EIS (Extreme Ice Survey) project. I think many of you will enjoy the film if you can find some place to see it. It is not showing in major houses. They have some discussion of small computer systems used as controllers for cameras. To find a location near you http://www.chasingice.com/ -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 1 06:39:54 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 8ED354AB; Fri, 1 Feb 2013 06:39:54 +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 4580FDCC; Fri, 1 Feb 2013 06:39:53 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r116drk7059267; Fri, 1 Feb 2013 06:39:53 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id h55yfxai8wb6rhyngzbv63pbn6; Fri, 01 Feb 2013 06:39:53 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: SD card -image- for the beaglebone Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: Date: Thu, 31 Jan 2013 22:39:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <510A4F5B.7000407@g7iii.net> <1359646574.93359.327.camel@revolution.hippie.lan> To: George Neville-Neil X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org, 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: Fri, 01 Feb 2013 06:39:54 -0000 On Jan 31, 2013, at 7:58 AM, George Neville-Neil wrote: >=20 > On Jan 31, 2013, at 10:36 , Ian Lepore wrote: >=20 >> On Thu, 2013-01-31 at 11:02 +0000, Iain Young wrote: >>> Hi Folks, >>>=20 >>> I have just taken delivery of a few Beaglebones that I am intending = to >>> do some NTP Work. With FreeBSD having one of the better reputations >>> with regards to Time and PPS etc, I thought I would install FreeBSD = on >>> at least one of them. >>>=20 >>> Does anyone have an *image* of a base install for a 4 Gig microSD >>> card that I can download ? Preferably with ssh and dhcp installed >>> (yes, I know about blowing away the keys), as that would avoid = having >>> to rely on the console. I plan to build and release a dev snapshot image in a few days, as soon as I finish up my current round of network driver fixes. >> So you're interested in a PPS driver for BeagleBone? That would be = fun >> to play with, I wonder what the BB's timer hardware looks like? It'd = be >> easy enough to do with a gpio interrupt I suspect, but the timing = geek >> in me can't resist going for the nanosecond-accurate measurements = when >> possible, even if it is kind of pointless for millisecond-accurate = NTP. >>=20 >=20 > Ah, but PTPd would be very happy with nanosecond accuracy. The = biggest > problem I see in PTPd on something like a BeagleBone is the network > interface. We need to get that cleaned up and then see how much = jitter it has. I presume you've noticed the reference in the AM335x TRM: 14.3.7 Common Platform Time Sync Module "The CPTS module is used to facilitate host control of time sync operations. It enables compliance with the IEEE 1588-2008(v2) standard for a precision clock synchronization protocol." Looks like it wouldn't be too hard to add to the CPSW network driver. Are there any examples of this being supported by other network drivers? I've also been eyeing the GPS module from Adafruit. Hmmm=85. Tim From owner-freebsd-arm@FreeBSD.ORG Fri Feb 1 06:51: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 E0CE8712 for ; Fri, 1 Feb 2013 06:51:47 +0000 (UTC) (envelope-from johnsstephenelder@gmail.com) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by mx1.freebsd.org (Postfix) with ESMTP id 82EDDE41 for ; Fri, 1 Feb 2013 06:51:47 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id fw7so2286983vcb.34 for ; Thu, 31 Jan 2013 22:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=rwnlpPzcBM809nwMKCGHwHvsclMY1qH9D1oYxGp9298=; b=UYI2NgNu498EGrYvCDKmCBOE9/KsQ0I6zKLO+0bfTQmPIok9XIVW2DLjziv9QlK1OD YezvR3sZ5n/J56m8le3/W5BpWthouDM6qBXLkbe6sdcZANlYfGo/HZMKfWDUNmbTQVLV VeAQm3izpMEkKbqJcZuVO+ZLhvLGcvgV9Vck5v42Qy58O1w0l0vLqxnduYekk8riAbyU hzLZA/loDkECWaMfxSzZFzAlwjSybDxHgngNJevB3+iVa3exvlbZAXAjBAbqUfGK9+xt N0DXlDxibyw+wfX1Eerg5+UB+XTKf3OrohYpkKB1QoS759a1Z1gq1KpxUlmc5APYGgDn 2Ajw== MIME-Version: 1.0 X-Received: by 10.58.32.10 with SMTP id e10mr6240031vei.59.1359701506585; Thu, 31 Jan 2013 22:51:46 -0800 (PST) Received: by 10.58.2.227 with HTTP; Thu, 31 Jan 2013 22:51:46 -0800 (PST) Date: Fri, 1 Feb 2013 14:51:46 +0800 Message-ID: Subject: About the FreeBSD for arm From: John Elder To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 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: Fri, 01 Feb 2013 06:51:47 -0000 Hello, I am want to make a FreeBSD image for cubieboard, but I occur some problems, [image: Inline image 1] I don't know what had happened. could anybody who knows tell me, thank you very much. From owner-freebsd-arm@FreeBSD.ORG Fri Feb 1 07:27: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 BB032B7 for ; Fri, 1 Feb 2013 07:27:47 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id 2F48EF9D for ; Fri, 1 Feb 2013 07:27:46 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 374373535; Fri, 01 Feb 2013 08:27:39 +0100 From: Hans Petter Selasky To: freebsd-arm@freebsd.org Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Date: Fri, 1 Feb 2013 08:28:50 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <9E78813F3BF946A4A2FCEA2C363A847E@ad.peach.ne.jp> In-Reply-To: X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: 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: Fri, 01 Feb 2013 07:27:47 -0000 On Thursday 31 January 2013 16:17:22 Mats Mellstrand wrote: > Hi > > Thanks! > > Your patch works fine! > > /mm Committed to SVN with some modifications: http://svnweb.freebsd.org/changeset/base/246196 --HPS From owner-freebsd-arm@FreeBSD.ORG Fri Feb 1 08:58: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 04FF6877 for ; Fri, 1 Feb 2013 08:58:02 +0000 (UTC) (envelope-from johnsstephenelder@gmail.com) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by mx1.freebsd.org (Postfix) with ESMTP id C13B73FF for ; Fri, 1 Feb 2013 08:58:01 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id fo13so2353468vcb.11 for ; Fri, 01 Feb 2013 00:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=uWLeUzPCRkZF0CrSV8amI0LJKtfRiIVeC7dL452Q+8M=; b=PEy++mIfyIY6AbaRAAR0s/CcKcKNIAI74bXwLajPQCFrJUNX+lBa0+sMd6QSjguUiB mWssx3dgMrJX8EW1bRE7x6GEDsgQ3lsCDMCUyWTiktgONgHZSiokKcURr4x/Nx89hElz Qm8RDuM8CE1lEIGYBbs/viZThVeL7V/dUkXTLS8x9dDkgiYF40OrO6nIBbOTXpcyc6rZ fFPiYCt6+nS5dGnD/xaiu/QJaDmBq3loWuccv4dy4/cxrMLH4d6iyjlnuqc7zWRdpGu0 FIcF7cPTsPAhLvWycL/+4kQwRpxp4Ig4MZhShfUXOnbNTH7CPDkvL+18ELUsx3bvH/ln lRbg== MIME-Version: 1.0 X-Received: by 10.52.89.48 with SMTP id bl16mr9299621vdb.120.1359709075156; Fri, 01 Feb 2013 00:57:55 -0800 (PST) Received: by 10.58.2.227 with HTTP; Fri, 1 Feb 2013 00:57:55 -0800 (PST) Date: Fri, 1 Feb 2013 16:57:55 +0800 Message-ID: Subject: About build the kernel From: John Elder To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 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: Fri, 01 Feb 2013 08:58:02 -0000 Hi, I meet a problem, that i want to build the kernel for arm, but it shows that: make don't know how to make buildkernel, Stop. I just check out the source from svn.freebsd.org/base/head, And I find the kernel I needed in the /usr/src/sys/arm/conf folder. I don't know what can do now, please help me. Thank you. From owner-freebsd-arm@FreeBSD.ORG Fri Feb 1 10:55: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 E34CA601 for ; Fri, 1 Feb 2013 10:55:01 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id A76CFBEF for ; Fri, 1 Feb 2013 10:55:01 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1U1EGj-0003Sj-LT for freebsd-arm@freebsd.org; Fri, 01 Feb 2013 11:54:54 +0100 Received: from 212-182-167-131.ip.telfort.nl ([212.182.167.131] helo=ronaldradial.home) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U1EGj-00048m-Mi for freebsd-arm@freebsd.org; Fri, 01 Feb 2013 11:54:53 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: About build the kernel References: Date: Fri, 01 Feb 2013 11:54:54 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.13 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.0 X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=disabled version=3.3.1 X-Scan-Signature: 645486d610a00fe5591aab0f6aa1616b 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, 01 Feb 2013 10:55:01 -0000 On Fri, 01 Feb 2013 09:57:55 +0100, John Elder wrote: > Hi, > I meet a problem, that i want to build the kernel for arm, but it shows > that: > make don't know how to make buildkernel, Stop. > > I just check out the source from svn.freebsd.org/base/head, And I find > the > kernel I needed in the /usr/src/sys/arm/conf folder. > > I don't know what can do now, please help me. Thank you. In what directory did you type 'make buildkernel'? If you did not do that in /usr/src, please try it in /usr/src. Ronald. From owner-freebsd-arm@FreeBSD.ORG Fri Feb 1 19:06:18 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 EE49737C; Fri, 1 Feb 2013 19:06:18 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 81E769CD; Fri, 1 Feb 2013 19:06:18 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id r11J5uOg045076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Feb 2013 20:05:57 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id r11J4ZdA078698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Feb 2013 20:04:36 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id r11J4ZG4080494; Fri, 1 Feb 2013 20:04:35 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id r11J4Zmi080493; Fri, 1 Feb 2013 20:04:35 +0100 (CET) (envelope-from ticso) Date: Fri, 1 Feb 2013 20:04:35 +0100 From: Bernd Walter To: Ian Lepore Subject: Re: SD card -image- for the beaglebone Message-ID: <20130201190434.GK67562@cicely7.cicely.de> References: <510A4F5B.7000407@g7iii.net> <1359646574.93359.327.camel@revolution.hippie.lan> <510AE1D6.8010203@g7iii.net> <1359668656.93359.339.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1359668656.93359.339.camel@revolution.hippie.lan> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 19:06:19 -0000 On Thu, Jan 31, 2013 at 02:44:16PM -0700, Ian Lepore wrote: > On Thu, 2013-01-31 at 21:27 +0000, Iain Young wrote: > > On 31/01/13 15:36, Ian Lepore wrote: > > > > > So you're interested in a PPS driver for BeagleBone? That would be fun > > > to play with, I wonder what the BB's timer hardware looks like? It'd be > > > easy enough to do with a gpio interrupt I suspect, but the timing geek > > > in me can't resist going for the nanosecond-accurate measurements when > > > possible, even if it is kind of pointless for millisecond-accurate NTP. > > > > Yep. Planning on hooking up MSF, DCF, and TDF clocks to GPIO pins, as > > well as some GPS units. Originally planned for doing this with some > > Pi, but found the bone had serial ports and things developed from there > > > > Planning on abusing UART3's CTS pin for initial basic testing, as > > radioclkd and radioclkd2 have only support for serial ports, but > > then it will be working out what if anything I need to patch into the > > kernel to get the PPS subsystem to listen to particular GPIO pins. > > > > Also planning to test PHK's ntpns, which has DCF support, > > and should be easy to modify for MSF. Anyway, this is heading far > > too quickly to being on-topic for time-nuts but off-topic here > > You might be surprised how many time nuts read this list, several of us > do it for a living. Absolutely - there is a reason why I have a rubidium here. Thought of using it with a zedboard - it's FPGA and gbit/s ethernet sounds as a good combination. The most important thing however is a red LED based 7-Segment microsecond display (without multiplexing) - not that anyone can read. I even thought of doing ntp protocol in FPGA logic. Unfortunately the GPS receiver I bought has no PPS output :-( Getting an accurate time is more difficult then keeping it. And leap seconds won't make it easier. What are MSF and TDF? I'm aware of GPS, DCF77 and LORAN-C to be available in Germany. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sat Feb 2 05:29:19 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 588F0693; Sat, 2 Feb 2013 05:29:19 +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 089F1FFC; Sat, 2 Feb 2013 05:29:18 +0000 (UTC) Received: from ivory.lan (mail.wynn.com [199.89.147.3]) (authenticated bits=0) by mail.wynn.com (8.14.3/8.12.6) with ESMTP id r125T820031312; Sat, 2 Feb 2013 00:29:08 -0500 (EST) (envelope-from wynkoop@wynn.com) Date: Sat, 2 Feb 2013 00:29:08 -0500 From: Brett Wynkoop To: ticso@cicely.de Subject: Re: SD card -image- for the beaglebone Message-ID: <20130202002908.53768a06@ivory.lan> In-Reply-To: <20130201190434.GK67562@cicely7.cicely.de> References: <510A4F5B.7000407@g7iii.net> <1359646574.93359.327.camel@revolution.hippie.lan> <510AE1D6.8010203@g7iii.net> <1359668656.93359.339.camel@revolution.hippie.lan> <20130201190434.GK67562@cicely7.cicely.de> 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, ticso@cicely7.cicely.de, 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: Sat, 02 Feb 2013 05:29:19 -0000 On Fri, 1 Feb 2013 20:04:35 +0100 Bernd Walter wrote: nd leap seconds won't make it easier. > > What are MSF and TDF? > I'm aware of GPS, DCF77 and LORAN-C to be available in Germany. > You still have working Loran-C in Germany? I have a Loran-C receiver on my boat. Do you need to know where you are? I could send it to you cheap! -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 Sat Feb 2 05:54:57 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 B26FD9F0 for ; Sat, 2 Feb 2013 05:54:57 +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 90EF8107 for ; Sat, 2 Feb 2013 05:54:57 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r125smws066252; Sat, 2 Feb 2013 05:54:48 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 7mc2f9zqr4dkshzyp9c7tgd4tn; Sat, 02 Feb 2013 05:54:48 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Some ideas on Tim's script Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <51092D3A.4060608@ceetonetechnology.com> Date: Fri, 1 Feb 2013 21:54:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51092D3A.4060608@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: Sat, 02 Feb 2013 05:54:57 -0000 On Jan 30, 2013, at 6:24 AM, George Rosamond wrote: > I mentioned this to Tim offline a while back, but I have some quick = thoughts on options for the scripts. Here's the change I just made to the /etc/rc.conf used by my scripts for BeagleBone builds. If you have further suggestions, I'm happy to include them. --- a/board/BeagleBone/overlay/etc/rc.conf +++ b/board/BeagleBone/overlay/etc/rc.conf @@ -1,6 +1,14 @@ hostname=3D"beaglebone" ifconfig_cpsw0=3D"DHCP" sshd_enable=3D"YES" +rc_debug=3D"YES" +rc_info=3D"YES" + +tmpmfs=3D"YES" +tmpsize=3D"13m" + +ntpd_enable=3D"YES" +ntpd_sync_on_start=3D"YES" =20 # Turn off a lot of standard stuff # for more free memory. From owner-freebsd-arm@FreeBSD.ORG Sat Feb 2 10:22:27 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 C99439FB for ; Sat, 2 Feb 2013 10:22:27 +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 9B863910 for ; Sat, 2 Feb 2013 10:22:27 +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 5D70B208F5 for ; Sat, 2 Feb 2013 10:22:25 +0000 (UTC) Message-ID: <510CE8E0.9070102@g7iii.net> Date: Sat, 02 Feb 2013 10:22:24 +0000 From: Iain Young User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Beaglebone Serial Ports 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: Sat, 02 Feb 2013 10:22:27 -0000 Hi Folks, Just a quick question with regards to some clarification serial ports on the Beaglbone and FreeBSD. Am I correct in deducing that FreeBSD lacks support for UARTS1 thru 5 at the moment ? I can see what I believe to be UART0 (which is attached to the USB) as /dev/cuau0, but not the others. A few finds and greps through the kernel source didn't show up anything obvious either. Is any one working on them ? Or is there a kernel module or option that I need to enable for them to build ? Best Regards Iain From owner-freebsd-arm@FreeBSD.ORG Sat Feb 2 15:13: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 3FF42369 for ; Sat, 2 Feb 2013 15:13: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 DDA5D79E for ; Sat, 2 Feb 2013 15:13:27 +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 r12FDQd5049908 for ; Sat, 2 Feb 2013 08:13:26 -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 r12FDNRu027351; Sat, 2 Feb 2013 08:13:23 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Beaglebone Serial Ports From: Ian Lepore To: Iain Young In-Reply-To: <510CE8E0.9070102@g7iii.net> References: <510CE8E0.9070102@g7iii.net> Content-Type: text/plain; charset="us-ascii" Date: Sat, 02 Feb 2013 08:13:23 -0700 Message-ID: <1359818003.93359.381.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: Sat, 02 Feb 2013 15:13:34 -0000 On Sat, 2013-02-02 at 10:22 +0000, Iain Young wrote: > Hi Folks, > > Just a quick question with regards to some clarification serial ports > on the Beaglbone and FreeBSD. Am I correct in deducing that FreeBSD > lacks support for UARTS1 thru 5 at the moment ? > > I can see what I believe to be UART0 (which is attached to the USB) as > /dev/cuau0, but not the others. A few finds and greps through the > kernel source didn't show up anything obvious either. > > Is any one working on them ? Or is there a kernel module or option > that I need to enable for them to build ? > According to the datasheet all the onboard uarts should be supported by our standard uart driver (but only uart1 has all the modem-control lines wired). Two things need to be done to enable them: add entries to the .dts file (easy), and configure the multipurpose pins for them at runtime. I have no idea how we handle the latter in the FDT world. In the pre-FDT world it was pretty much ad-hoc and board-support routines that ran at startup configured pins for that board. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Feb 2 16:33:27 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 1C9F34C5; Sat, 2 Feb 2013 16:33:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7D5F6A29; Sat, 2 Feb 2013 16:33:26 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r12GXMsX088485; Sat, 2 Feb 2013 18:33:22 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r12GXMsX088485 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r12GXMVP088484; Sat, 2 Feb 2013 18:33:22 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 2 Feb 2013 18:33:22 +0200 From: Konstantin Belousov To: current@freebsd.org, arch@freebsd.org Subject: Physbio changes final call for tests and reviews Message-ID: <20130202163322.GA2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xIk0xHvQc0Ku+QuL" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: powerpc@freebsd.org, mips@freebsd.org, jeff@freebsd.org, ia64@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: Sat, 02 Feb 2013 16:33:27 -0000 --xIk0xHvQc0Ku+QuL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 Thank you in advance. --xIk0xHvQc0Ku+QuL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRDT/SAAoJEJDCuSvBvK1BmGoP/314FHxSTtWQ22v30ZkLUUHw p/5C3qRV+xjpEWfE80WQtMobuh9XMxaHGLJxz9UvVJQIqx5WUe0bINN4PfwzVbSm r+Zw+LtyVrBdVgMzuq48h4IEFHkcxN1O6VznBKPBBDYcIZTTZ7y/bdljiB7q0HRP G7SHsOfpIN8CSZNXPodVMIeagDPcbVDb3yVtW5zIsHeMyxCtjWIRCczVCwr0vpXQ kfOGqAquLrXlv95e04LB08REJnrymkoPpMmA6mHdxY3a8ggMXcd4wFVP8YjX23iR rEY8idLlW4rLfMwZuCcyR5w4UIcsx2NOhcyouFVRDYs5HxLDoDBUx+GYFu5fOlaL NShrb/pc6AQZHucLjDfLxn+479Z7zgfxFDDiDdnGjUdmcYHZds1v+6WuwwIi+HwD X6Edqfd37h+itGBt2h8LNgNA4urbWW7Xq7amsojjmOBgqdJ2Pe6ML+L0txwtY/cN ICcBuDlJj3qXf81JZqr2zBa7+1DOYB+EFMTtOBwIUQKixAh1PL/+EbarDNLTOKld tiRL9wjkiGKGXgX5fBj06949XMP2Nsi4xyQwc9hhvujsY4zNmBJvvj/ui6w7tRGI P68tmOBeVPwVVHzfFvOm4MgHZpS0gzL9cr04p+knB6IBzjkfBEmUjGXC/85MGmXG TY4uqxb8dCMidsn6TG3D =lu5h -----END PGP SIGNATURE----- --xIk0xHvQc0Ku+QuL-- From owner-freebsd-arm@FreeBSD.ORG Sat Feb 2 17:14:53 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 037A2D93 for ; Sat, 2 Feb 2013 17:14:53 +0000 (UTC) (envelope-from ike@blackskyresearch.net) Received: from rs149.luxsci.com (rs149.luxsci.com [64.49.224.181]) by mx1.freebsd.org (Postfix) with ESMTP id C27A7C10 for ; Sat, 2 Feb 2013 17:14:52 +0000 (UTC) Received: from rs149.luxsci.com (localhost.localdomain [127.0.0.1]) by rs149.luxsci.com (8.14.4/8.13.8) with ESMTP id r12HEjJk002548 for ; Sat, 2 Feb 2013 12:14:45 -0500 Received: (from root@localhost) by rs149.luxsci.com (8.14.4/8.13.8/Submit) id r12HE3kG002204 for freebsd-arm@freebsd.org; Sat, 2 Feb 2013 17:14:03 GMT Received: (from sender 74627) (rs149.luxsci.com [127.0.0.1]) by LuxSci SP; Sat, 02 Feb 2013 17:14:02 +0000 From: "Isaac (.ike) Levy" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: make xdev failing for me Date: Sat, 2 Feb 2013 12:13:33 -0500 To: freebsd-arm@freebsd.org X-Lux-Comment: Message r12HDXlF001972 sent by user #74627 Message-Id: <1359825242-6737780.11277733.fr12HDXlF001972@rs149.luxsci.com> X-Comment: LuxSci SP Message ID - 1359825242-6737780.11277733 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, 02 Feb 2013 17:14:53 -0000 Hi All, Been using Tim's scripts for a few months, I've just rebuilt a 10.x "build-mule" machine, and I'm snagged somewhere = new: # make xdev XDEV=3Darm XDEV_ARCH=3Darm Breaking output below. I pulled the clang bits from /etc/make.conf, but it appears to be using = clang to build the xdev bits? (I don't believe it's relevant, but I built the host using clang, = (amd64), and the boot disk is zfs.) -- Should I file a PR, or am I down a known-silly path? Thanks! Best, .ike -- root@host:/usr/src # svn up Updating '.': At revision 246254. root@host:/usr/src #=20 # make xdev XDEV=3Darm XDEV_ARCH=3Darm ... install -C -o root -g wheel -m 444 libcompiler_rt.a = /usr/arm-freebsd/usr/lib /usr/arm-freebsd/usr/lib/libgcc.a -> libcompiler_rt.a =3D=3D=3D> gnu/lib/csu (obj,depend,all,install) install -o root -g wheel -m 444 crtbegin.o = /usr/arm-freebsd/usr/lib/crtbegin.o install -o root -g wheel -m 444 crtend.o = /usr/arm-freebsd/usr/lib/crtend.o install -o root -g wheel -m 444 crtbeginT.o = /usr/arm-freebsd/usr/lib/crtbeginT.o install -o root -g wheel -m 444 crtbeginS.o = /usr/arm-freebsd/usr/lib/crtbeginS.o install -o root -g wheel -m 444 crtendS.o = /usr/arm-freebsd/usr/lib/crtendS.o =3D=3D=3D> lib/csu/arm (obj,depend,all,install) clang -c -o crt1.o crt1.s crt1.s:10:2: error: unknown use of instruction mnemonic without a size = suffix mov r5, r2 /* cleanup */ =20 ^ crt1.s:11:2: error: unknown use of instruction mnemonic without a size = suffix mov r4, r1 /* obj_main */ =20 ^ crt1.s:12:2: error: unknown use of instruction mnemonic without a size = suffix mov r3, r0 /* ps_strings */ =20 ^ crt1.s:14:13: error: expected ']' in brackets expression ldr r0, [sp, #0x0000] =20 ^ crt1.s:15:14: error: unknown token in expression add r1, sp, #0x0004 =20 ^ crt1.s:16:2: error: unknown use of instruction mnemonic without a size = suffix add r2, r1, r0, lsl #2 =20 ^ crt1.s:17:14: error: unknown token in expression add r2, r2, #0x0004 =20 ^ crt1.s:19:14: error: unknown token in expression bic sp, sp, #7 =20 ^ crt1.s:20:14: error: unknown token in expression sub sp, sp, #8 =20 ^ crt1.s:21:13: error: expected ']' in brackets expression str r5, [sp, #4] =20 ^ crt1.s:22:13: error: expected ']' in brackets expression str r4, [sp, #0] =20 ^ crt1.s:24:2: error: invalid instruction mnemonic 'b' b __start =20 ^ *** [crt1.o] Error code 1 Stop in /usr/src/lib/csu/arm. *** [lib/csu/arm__L] Error code 1 Stop in /usr/src. *** [libraries] Error code 1 Stop in /usr/src. *** [_xi-libraries] Error code 1 Stop in /usr/src. *** [xdev] Error code 1 Stop in /usr/src. root@host:/usr/src #=20 From owner-freebsd-arm@FreeBSD.ORG Sat Feb 2 20:04: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 B4425942; Sat, 2 Feb 2013 20:04: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 71595273; Sat, 2 Feb 2013 20:04:04 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r12K3vDh069100; Sat, 2 Feb 2013 20:03:57 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id fvuwqdeybn75gmahr4yr3hkyhs; Sat, 02 Feb 2013 20:03:57 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Beaglebone Serial Ports Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <1359818003.93359.381.camel@revolution.hippie.lan> Date: Sat, 2 Feb 2013 12:03:56 -0800 Content-Transfer-Encoding: 7bit Message-Id: <66029B5F-2A19-4683-B589-814932E156A2@kientzle.com> References: <510CE8E0.9070102@g7iii.net> <1359818003.93359.381.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 20:04:04 -0000 On Feb 2, 2013, at 7:13 AM, Ian Lepore wrote: > On Sat, 2013-02-02 at 10:22 +0000, Iain Young wrote: >> Hi Folks, >> >> Just a quick question with regards to some clarification serial ports >> on the Beaglbone and FreeBSD. Am I correct in deducing that FreeBSD >> lacks support for UARTS1 thru 5 at the moment ? >> >> I can see what I believe to be UART0 (which is attached to the USB) as >> /dev/cuau0, but not the others. A few finds and greps through the >> kernel source didn't show up anything obvious either. >> >> Is any one working on them ? Or is there a kernel module or option >> that I need to enable for them to build ? It should just be a matter of updating the DTS file with additional UART entries and updated pinmux. Unfortunately, the current BeagleBone builds use a compiled-in device tree, so you'll have to edit the DTS file at sys/boot/fdt/dts/beaglebone.dts and then rebuild the kernel. I'd like to move that out of the kernel; the loader already has logic to load a DTS file and pass it to the kernel, it should just need some tinkering with loader.rc to get it working. That would make it a lot easier to tweak settings on a per-system basis without having to rebuild the kernel. > According to the datasheet all the onboard uarts should be supported by > our standard uart driver (but only uart1 has all the modem-control lines > wired). Two things need to be done to enable them: add entries to > the .dts file (easy), and configure the multipurpose pins for them at > runtime. I have no idea how we handle the latter in the FDT world. In > the pre-FDT world it was pretty much ad-hoc and board-support routines > that ran at startup configured pins for that board. The pinmux for BeagleBone is in the DTS file, specifically, the scm@44e10000 section. The pad-config section is parsed by general code in sys/arm/ti/ti_scm.c driven from an SoC-specific table in sys/arm/ti/am335x/am335x_scm_padconf.c. I don't know offhand if there is currently a mechanism for changing pinmux at runtime. It would certainly be nice to have such a mechanism. Tim From owner-freebsd-arm@FreeBSD.ORG Sat Feb 2 21:20: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 587C3176 for ; Sat, 2 Feb 2013 21:20: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 09BEC708 for ; Sat, 2 Feb 2013 21:20:41 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r12LKehp069408; Sat, 2 Feb 2013 21:20:40 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 6b39xgvwjenecvd2ap49r287h6; Sat, 02 Feb 2013 21:20:40 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: SD card -image- for the beaglebone Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <510A4F5B.7000407@g7iii.net> Date: Sat, 2 Feb 2013 13:20:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <037A538B-434B-4168-9591-99ABA39C6006@kientzle.com> References: <510A4F5B.7000407@g7iii.net> To: Iain Young X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 21:20:42 -0000 On Jan 31, 2013, at 3:02 AM, Iain Young wrote: > Hi Folks, >=20 > I have just taken delivery of a few Beaglebones that I am intending to > do some NTP Work. With FreeBSD having one of the better reputations > with regards to Time and PPS etc, I thought I would install FreeBSD on > at least one of them. >=20 > Unfortunately, all of the guides I've found all assume you have a > FreeBSD box already running. Unfortunately, I don't, and nor do I have > a spare x86 box to do so. >=20 > Does anyone have an *image* of a base install for a 4 Gig microSD > card that I can download ? Preferably with ssh and dhcp installed > (yes, I know about blowing away the keys), as that would avoid having > to rely on the console. >=20 > Quite happy to rebuild the kernel and world afterwards (yes, I know I > need an 8 Gig SD card), but it's just this bootstrapping problem thats > an issue=85 I just uploaded a BeagleBone SD image that people can play with. = http://people.freebsd.org/~kientzle/FreeBSD-BEAGLEBONE-r246229-noWITNESS-8= g-2013-02-02.img.xz This is: * Based on SVN r246229 * Completely vanilla build from SVN except as noted below * Includes my new CPSW driver (not yet committed to SVN) * Sized for an 8G card * WITNESS and INVARIANTS are disabled * NFSCL and NFSLOCKD enabled * Has a user "beagle" with password "beagle" that you can login with = SSH If you'd like to build your own, this image was built with the scripts = I've been maintaining on Github using the following config.sh file: board_setup BeagleBone SD_SIZE=3D$((7900 * MB)) customize_freebsd_partition ( ) { # 768M swap file /usr/swap0 disk_add_swap_file 768 # Home directory for user accounts mkdir -p $1/home # Add a user "beagle:beagle" with password "beagle" pw -V $1/etc groupadd beagle -g 1001 # 'pw' doesn't let you set the Password, but -w makes it same as = username pw -V $1/etc useradd beagle -u 1001 -g beagle -m -k $1/etc/skel -w = yes } If you have ideas for improving this, I'm very interested. Cheers, Tim From owner-freebsd-arm@FreeBSD.ORG Sat Feb 2 21:47:17 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 945863D3; Sat, 2 Feb 2013 21:47:17 +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 2E8377A7; Sat, 2 Feb 2013 21:47:16 +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 r12Ll9JK099456; Sat, 2 Feb 2013 22:47:09 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id r12Ll9dm099455; Sat, 2 Feb 2013 22:47:09 +0100 (CET) (envelope-from marius) Date: Sat, 2 Feb 2013 22:47:09 +0100 From: Marius Strobl To: Konstantin Belousov Subject: Re: Physbio changes final call for tests and reviews Message-ID: <20130202214709.GA99418@alchemy.franken.de> References: <20130202163322.GA2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130202163322.GA2522@kib.kiev.ua> 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: Sat, 02 Feb 2013 21:47:17 -0000 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). However, by accident I noticed that your patch (i.e. stock head is fine) somehow breaks smartd of smartmontools with ata(4): root@b1k2:/root # smartd ata3: timeout waiting for write DRQ The machine just hangs at this point (it's also strange that the above message is from the PIO rather than from the DMA path). One note: mjacob@ probably will be annoyed if you don't wrap the changes to isp(4) in __FreeBSD_version so the same source still compiles on older ones. Marius