From owner-freebsd-arm@FreeBSD.ORG Sun Mar 31 17:09: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 20ABDBA for ; Sun, 31 Mar 2013 17:09:02 +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 03F436A4 for ; Sun, 31 Mar 2013 17:09:01 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r2VH8tdH030766 for freebsd-arm@freebsd.org; Sun, 31 Mar 2013 17:08:55 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id gb2t5cuq2t4mp5b9q6fpqmz9gs; for freebsd-arm@freebsd.org; Sun, 31 Mar 2013 17:08:55 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Missing eabi symbols when building kernel? Date: Sun, 31 Mar 2013 10:08:54 -0700 Message-Id: <7A2CDCFE-841E-4A0D-8C73-39CE29CCADBF@freebsd.org> To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 17:09:02 -0000 Does anyone recognize this? $ cat make.conf WITH_CLANG_IS_CC=3Dyes $make TARGET_ARCH=3Darmv6 -j 4 buildworld ... $make TARGET_ARCH=3Darmv6 KERNCONF=3DBEAGLEBONE -DWITH_ARM_EABI -j 1 = buildkernel =85... cc -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline = -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions = -Wmissing-include-dirs -fdiagnostics-show-option = -Wno-error-tautological-compare -Wno-error-empty-body = -Wno-error-parentheses-equality -nostdinc -I. = -I/usr/home/tim/projects/crochet-rpi/src/sys = -I/usr/home/tim/projects/crochet-rpi/src/sys/contrib/altq = -I/usr/home/tim/projects/crochet-rpi/src/sys/contrib/libfdt -D_KERNEL = -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -funwind-tables = -mllvm -arm-enable-ehabi -ffreestanding -Werror vers.c linking kernel.debug cam.o:(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' cam.o:(.ARM.exidx+0x10): undefined reference to `__aeabi_unwind_cpp_pr1' cam_periph.o:(.ARM.exidx+0x0): undefined reference to = `__aeabi_unwind_cpp_pr1' cam_periph.o:(.ARM.exidx+0x10): undefined reference to = `__aeabi_unwind_cpp_pr0' cam_queue.o:(.ARM.exidx+0x0): undefined reference to = `__aeabi_unwind_cpp_pr1' cam_queue.o:(.ARM.exidx+0x18): undefined reference to = `__aeabi_unwind_cpp_pr0' cam_sim.o:(.ARM.exidx+0x0): undefined reference to = `__aeabi_unwind_cpp_pr0' cam_sim.o:(.ARM.exidx+0x18): undefined reference to = `__aeabi_unwind_cpp_pr1' cam_xpt.o:(.ARM.exidx+0x0): undefined reference to = `__aeabi_unwind_cpp_pr1' cam_xpt.o:(.ARM.exidx+0x18): undefined reference to = `__aeabi_unwind_cpp_pr0' From owner-freebsd-arm@FreeBSD.ORG Sun Mar 31 20:15: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 AA238972; Sun, 31 Mar 2013 20:15:27 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from mta01.xtra.co.nz (mta04.xtra.co.nz [210.54.141.251]) by mx1.freebsd.org (Postfix) with ESMTP id 2940CDA9; Sun, 31 Mar 2013 20:15:26 +0000 (UTC) Received: from bender ([222.154.134.108]) by mta01.xtra.co.nz with ESMTP id <20130331201518.KZH22569.mta01.xtra.co.nz@bender>; Mon, 1 Apr 2013 09:15:18 +1300 Date: Mon, 1 Apr 2013 09:15:03 +1300 From: Andrew Turner To: Tim Kientzle Subject: Re: Missing eabi symbols when building kernel? Message-ID: <20130401091503.462d9caf@bender> In-Reply-To: <7A2CDCFE-841E-4A0D-8C73-39CE29CCADBF@freebsd.org> References: <7A2CDCFE-841E-4A0D-8C73-39CE29CCADBF@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 31 Mar 2013 20:15:27 -0000 On Sun, 31 Mar 2013 10:08:54 -0700 Tim Kientzle wrote: > Does anyone recognize this? I have managed to reproduce this with a toolchain built for OABI and having -DWITH_ARM_EABI when building the kernel. The solution is to either remove -DWITH_ARM_EABI or rebuild the toolchain with -DWITH_ARM_EABI. Andrew From owner-freebsd-arm@FreeBSD.ORG Mon Apr 1 08:40:01 2013 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 52E46B72 for ; Mon, 1 Apr 2013 08:40: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 362CA950 for ; Mon, 1 Apr 2013 08:40: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 r318e1lY005667 for ; Mon, 1 Apr 2013 08:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r318e1Mx005666; Mon, 1 Apr 2013 08:40:01 GMT (envelope-from gnats) Resent-Date: Mon, 1 Apr 2013 08:40:01 GMT Resent-Message-Id: <201304010840.r318e1Mx005666@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-arm@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, "Ralf Wenk <" Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 884A3B27 for ; Mon, 1 Apr 2013 08:38:35 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 79D2D934 for ; Mon, 1 Apr 2013 08:38:35 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.5/8.14.5) with ESMTP id r318cX85024431 for ; Mon, 1 Apr 2013 08:38:33 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.5/8.14.5/Submit) id r318cXsQ024430; Mon, 1 Apr 2013 08:38:33 GMT (envelope-from nobody) Message-Id: <201304010838.r318cXsQ024430@red.freebsd.org> Date: Mon, 1 Apr 2013 08:38:33 GMT From: "Ralf Wenk <" To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: arm/177538: tunefs(8) and mount(8) can not access a newfs(8)'d filesystem (clang, EABI). 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, 01 Apr 2013 08:40:01 -0000 >Number: 177538 >Category: arm >Synopsis: tunefs(8) and mount(8) can not access a newfs(8)'d filesystem (clang, EABI). >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Apr 01 08:40:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Ralf Wenk >Release: FreeBSD 10.0-CURRENT arm >Organization: Hochschule Karlsruhe, University of Applied Sciences >Environment: FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r248943: Sun Mar 31 15:30:18 CEST 2013 root@home:/usr/obj/arm.armv6/home/rpi/src/sys/RPI-Bsc arm >Description: It looks like there is a reproduceable problem with geom when creating/accessing a ufs using clang and EABI. newfs(8) creates a filesystem, but tunefs(8) and mount(8) can not use it. The problem shows up as: # tunefs -n enable /dev/mmcsd0s3a tunefs: /dev/mmcsd0s3a: could not read superblock to fill out disk # mount /dev/mmcsd0s3a /mnt mount: /dev/mmcsd0s3a: Invalid argument Kernel and world are at the same revision. >How-To-Repeat: Kernel and world are build on a i386 9.1-STABLE revision 248678 with: make -C $SRCROOT -DWITH_ARM_EABI kernel-toolchain make -C $SRCROOT KERNCONF=$KERNCONF WITH_FDT=yes -DWITH_ARM_EABI buildkernel make -C $SRCROOT MALLOC_PRODUCTION=yes -DWITH_ARM_EABI buildworld KERNCONF is RPI-B with serial console enabled (RPI-Bsc). Initial SD-card layout: # gpart show => 1 7788543 mmcsd0 MBR (3.7G) 1 62 - free - (31k) 63 65520 1 !12 [active] (32M) 65583 2031561 2 freebsd (992M) 2097144 5691400 - free - (2.7G) => 0 2031561 mmcsd0s2 BSD (992M) 0 2031561 1 freebsd-ufs (992M) Now I add a new MBR slice, create a BSD disklabel on it and add a partition on that. After that I create a new ufs filesystem and try tunefs(8) and mount(8) on it. # gpart add -t freebsd mmcsd0 mmcsd0s3 added, but partition is not aligned on 65536 bytes The alignment warning is caused by the stripesize[1]. # gpart create -s BSD mmcsd0s3 mmcsd0s3 created # gpart add -t freebsd-ufs mmcsd0s3 mmcsd0s3a added # newfs /dev/mmcsd0s3a /dev/mmcsd0s3a: 2778.8MB (5691008 sectors) block size 32768, fragment size 4096 using 5 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. super-block backups (for fsck -b #) at: 192, 1282432, 2564672, 3846912, 5129152 # tunefs -n enable /dev/mmcsd0s3a tunefs: /dev/mmcsd0s3a: could not read superblock to fill out disk # mount /dev/mmcsd0s3a /mnt mount: /dev/mmcsd0s3a: Invalid argument Resulting SD-card layout: # gpart show => 1 7788543 mmcsd0 MBR (3.7G) 1 62 - free - (31k) 63 65520 1 !12 [active] (32M) 65583 2031561 2 freebsd (992M) 2097144 63 - free - (31k) 2097207 5691168 3 freebsd (2.7G) 7788375 169 - free - (84k) => 0 2031561 mmcsd0s2 BSD (992M) 0 2031561 1 freebsd-ufs (992M) => 0 5691168 mmcsd0s3 BSD (2.7G) 0 73 - free - (36k) 73 5691008 1 freebsd-ufs (2.7G) 5691081 87 - free - (43k) Creating the ufs on the i386 system results in a mountable filesystem on the pi. [1] # diskinfo -v mmcsd0 mmcsd0 512 # sectorsize 3987734528 # mediasize in bytes (3.7G) 7788544 # mediasize in sectors 65536 # stripesize 0 # stripeoffset # Disk ident. >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Mon Apr 1 11:06: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 01D5D839 for ; Mon, 1 Apr 2013 11:06:40 +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 E768D320 for ; Mon, 1 Apr 2013 11:06:39 +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 r31B6dVZ033570 for ; Mon, 1 Apr 2013 11:06:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r31B6doo033568 for freebsd-arm@FreeBSD.org; Mon, 1 Apr 2013 11:06:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Apr 2013 11:06:39 GMT Message-Id: <201304011106.r31B6doo033568@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, 01 Apr 2013 11:06:40 -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/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o arm/176424 arm Compiler warning, TARGET_ARCH=armv6, make MALLOC_PRODU o arm/175803 arm building xdev for arm failing o arm/175605 arm please fix build binutils-2.23.1 in raspberry pi o arm/174461 arm [patch] Fix off-by-one in arm9/arm10 cache maintenance o arm/173617 arm Dreamplug exhibits eSATA file corruption using network o kern/171096 arm [arm][xscale][ixp]Allow 16bit access on PCI bus o arm/166256 arm build fail in pmap.c o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) p arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on p arm/134338 arm [patch] Lock GPIO accesses on ixp425 20 problems total. From owner-freebsd-arm@FreeBSD.ORG Tue Apr 2 11:31: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 86C86846; Tue, 2 Apr 2013 11:31:54 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from mta02.xtra.co.nz (mta05.xtra.co.nz [210.54.141.250]) by mx1.freebsd.org (Postfix) with ESMTP id 062BBBDE; Tue, 2 Apr 2013 11:31:53 +0000 (UTC) Received: from bender ([222.154.134.108]) by mta02.xtra.co.nz with ESMTP id <20130402113145.ZSRB7887.mta02.xtra.co.nz@bender>; Wed, 3 Apr 2013 00:31:45 +1300 Date: Wed, 3 Apr 2013 00:31:25 +1300 From: Andrew Turner To: Andrew Turner Subject: Re: make universe fails on ARM Message-ID: <20130403003125.0942364c@bender> In-Reply-To: <20130329171129.0506945e@bender> References: <20130329171129.0506945e@bender> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 11:31:54 -0000 On Fri, 29 Mar 2013 17:11:29 +1300 Andrew Turner wrote: > On Tue, 26 Mar 2013 13:07:34 -0700 > Adrian Chadd wrote: > > > Hi,, > > > > make universe on -HEAD is failing on ARM: > ... > > I have a patch I'm testing to fix this. This should be fixed in r248937. Andrew From owner-freebsd-arm@FreeBSD.ORG Tue Apr 2 13:22:11 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B3068148; Tue, 2 Apr 2013 13:22:11 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id 88C9F23E; Tue, 2 Apr 2013 13:22:11 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0MKM00A00Q7J2B00@smtpauth1.wiscmail.wisc.edu>; Tue, 02 Apr 2013 08:22:11 -0500 (CDT) X-Spam-PmxInfo: Server=avs-1, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.4.2.130951, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (adsl-76-208-67-228.dsl.mdsnwi.sbcglobal.net [76.208.67.228]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0MKM007XUQGXFW00@smtpauth1.wiscmail.wisc.edu>; Tue, 02 Apr 2013 08:22:10 -0500 (CDT) X-Wisc-Sender: whitehorn@wisc.edu Message-id: <515ADB81.7090908@freebsd.org> Date: Tue, 02 Apr 2013 08:22:09 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130317 Thunderbird/17.0.4 To: Adrian Chadd Subject: Re: RFC: "Crochet" build tool References: <5DFA61DB-70E4-4C3D-ACA0-995A175706C8@neville-neil.com> <5151B454.9090402@ceetonetechnology.com> <1CBF1416-3237-4DCE-8D61-7E998265C887@neville-neil.com> <1364311809.36972.27.camel@revolution.hippie.lan> <5151D045.80305@thieprojects.ch> <5151D9DB.7050001@thieprojects.ch> <167CF57D-01E3-4857-BF0E-C40B00FED226@netgate.com> In-reply-to: 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, 02 Apr 2013 13:22:11 -0000 On 03/26/13 14:38, Adrian Chadd wrote: > NanoBSD isn't specifically x86 only. > > The startup script stuff is x86 only. > > The build/installworld part of nanobsd can be refactored out and made > platform portable. > > The UFS image building part can be refactored out and made platform portable. > > The startup script stuff can be refactored out and made platform portable. > > The disk image stuff can be refactored out and made platform portable. > > These aren't unsolvable problems. :-) > > > It's probably worth noting here that release(7) can do cross-builds, including disk image generation, with no problem. If that's the part you're looking at, it's already solved. -Nathan From owner-freebsd-arm@FreeBSD.ORG Wed Apr 3 18:41: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 A0D94B56 for ; Wed, 3 Apr 2013 18:41:12 +0000 (UTC) (envelope-from jeff@jrpenn.demon.co.uk) Received: from smtp.demon.co.uk (mdfmta005.mxout.tbr.inty.net [91.221.168.46]) by mx1.freebsd.org (Postfix) with ESMTP id 33014738 for ; Wed, 3 Apr 2013 18:41:11 +0000 (UTC) Received: from smtp.demon.co.uk (unknown [127.0.0.1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta005.tbr.inty.net (Postfix) with ESMTP id E338DA64313 for ; Wed, 3 Apr 2013 19:34:36 +0100 (BST) Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id 44138384080 for ; Wed, 3 Apr 2013 19:34:30 +0100 (BST) Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id 05DFF38407C for ; Wed, 3 Apr 2013 19:34:30 +0100 (BST) Received: from beastie.jrpenn.demon.co.uk (unknown [80.176.77.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta009.tbr.inty.net (Postfix) with ESMTP for ; Wed, 3 Apr 2013 19:34:29 +0100 (BST) Received: from beastie.jrpenn.demon.co.uk (localhost [127.0.0.1]) by beastie.jrpenn.demon.co.uk (8.14.5/8.14.5) with ESMTP id r33IYT0U081600 for ; Wed, 3 Apr 2013 19:34:29 +0100 (BST) (envelope-from jeff@beastie.jrpenn.demon.co.uk) Received: (from jeff@localhost) by beastie.jrpenn.demon.co.uk (8.14.5/8.14.5/Submit) id r33IYSa2081599 for freebsd-arm@freebsd.org; Wed, 3 Apr 2013 19:34:28 +0100 (BST) (envelope-from jeff) Date: Wed, 3 Apr 2013 19:34:28 +0100 From: Jeff Penn To: freebsd-arm@freebsd.org Subject: Re: Net booting current snapshot on openrd and sheevaplug Message-ID: <20130403183428.GA81559@jrpenn.demon.co.uk> References: <20130323183037.GA39897@beastie.jrpenn.demon.co.uk> <1364067518.1157.163.camel@revolution.hippie.lan> <20130323231302.GA60043@jrpenn.demon.co.uk> <1364092848.1157.165.camel@revolution.hippie.lan> <20130325222845.GA27893@jrpenn.demon.co.uk> <20130330214014.GA1503@jrpenn.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130330214014.GA1503@jrpenn.demon.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-MDF-HostID: 4 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, 03 Apr 2013 18:41:12 -0000 Configuring the kernels for the openrd and sheevaplug with a root path, e.g.: make buildkernel TARGET_ARCH=arm KERNCONF=DB-88F6XXX ROOTDEVNAME=\"nfs:192.168.0.10:/mnt/ST340014A/diskless/arm-8-le/\" does not fix the diskless boot problem; openrd: Sending DHCP Request packet from interface mge0 (f0:ad:4e:00:61:58) Received DHCP Ack packet on mge0 from 192.168.0.10 (accepted) (got root path) uhub2: 4 ports with 4 removable, self powered mge0 at 192.168.0.16 server 192.168.0.10 subnet mask 255.255.255.0 router 192.168.0.1 rootfs 192.168.0.10:/mnt/ST340014A/diskless/arm-8-le hostname openrd Adjusted interface mge0 krpc_call: sosend: 64 krpc_call: sosend: 64 panic: nfs_boot: mountd root, error=64 KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at kdb_enter+0x48: ldrb r15, [r15, r15, ror r15]! db> sheevaplug: Sending DHCP Discover packet from interface mge0 (f0:ad:4e:00:68:9c) Received DHCP Offer packet on mge0 from 192.168.0.10 (accepted) (no root path) mge0: link state changed to UP uhub0: 1 port with 1 removable, self powered Sending DHCP Request packet from interface mge0 (f0:ad:4e:00:68:9c) Received DHCP Ack packet on mge0 from 192.168.0.10 (accepted) (got root path) mge0 at 192.168.0.15 server 192.168.0.10 subnet mask 255.255.255.0 router 192.168.0.1 rootfs 192.168.0.10:/mnt/ST340014A/diskless/arm-8-le hostname sheeva Adjusted interface mge0 RPC timeout for server 192.168.0.10 RPC timeout for server 192.168.0.10 ... The compile problems I had with the i386 was a lack of disk space. I have not yet started testing diskless booting since fixing this. Jeff From owner-freebsd-arm@FreeBSD.ORG Thu Apr 4 04:21: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 29393512; Thu, 4 Apr 2013 04:21:00 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 05266372; Thu, 4 Apr 2013 04:20:59 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r344KqKl061350; Thu, 4 Apr 2013 04:20:52 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id cq34rmtpbgxmq52bqr99pzgtjw; Thu, 04 Apr 2013 04:20:52 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: RFC: "Crochet" build tool Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <515ADB81.7090908@freebsd.org> Date: Wed, 3 Apr 2013 21:20:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5DFA61DB-70E4-4C3D-ACA0-995A175706C8@neville-neil.com> <5151B454.9090402@ceetonetechnology.com> <1CBF1416-3237-4DCE-8D61-7E998265C887@neville-neil.com> <1364311809.36972.27.camel@revolution.hippie.lan> <5151D045.80305@thieprojects.ch> <5151D9DB.7050001@thieprojects.ch> <167CF57D-01E3-4857-BF0E-C40B00FED226@netgate.com> <515ADB81.7090908@freebsd.org> To: Nathan Whitehorn 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, 04 Apr 2013 04:21:00 -0000 On Apr 2, 2013, at 6:22 AM, Nathan Whitehorn wrote: > On 03/26/13 14:38, Adrian Chadd wrote: >> NanoBSD isn't specifically x86 only. >>=20 >> The startup script stuff is x86 only. >>=20 >> The build/installworld part of nanobsd can be refactored out and made >> platform portable. >>=20 >> The UFS image building part can be refactored out and made platform = portable. >>=20 >> The startup script stuff can be refactored out and made platform = portable. >>=20 >> The disk image stuff can be refactored out and made platform = portable. >>=20 >> These aren't unsolvable problems. :-) >>=20 >>=20 >>=20 >=20 > It's probably worth noting here that release(7) can do cross-builds, > including disk image generation, with no problem. If that's the part > you're looking at, it's already solved. > -Nathan What boot support does it install? Tim From owner-freebsd-arm@FreeBSD.ORG Thu Apr 4 13:20:15 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A769B60D; Thu, 4 Apr 2013 13:20:15 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id E112DFE5; Thu, 4 Apr 2013 13:20:14 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id e51so1054436eek.41 for ; Thu, 04 Apr 2013 06:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=2s80tbwUS6oJ3r33gIsPoAS5+7fx12f0pQd2As+AyTE=; b=BuH+VLlva+FLfxLtl/JLc3dIRZvLR3ukN28ftxfDiZmpFoW5x0yyAAWttfbMJXo6tz XdBjZNs7CLxj2HN9VhIMBDJreRWE+n/kNECUkPRbiWgTfFfJjXuZyzgqlIk0VRlcmYlG Ec3d+k/q542l4Piu7TDA+kzmNRbnO1xJh+tlp+oev8tN9x7dMjhZci5s4qjHXurVySkI sCCYH8O109poTJOffcR/gQZV5MG14l5D9ux709drMYLP/nqR9sbXPiu6SWoti48pMz+2 ACDqGkI10PVYwYM0VVQmso89Tg2bBeGGo8JCmFcQerzTu13SiKe5QHG1n9P/XiWP2eoF C3Sw== X-Received: by 10.14.183.67 with SMTP id p43mr10980049eem.10.1365081613766; Thu, 04 Apr 2013 06:20:13 -0700 (PDT) Received: from ?IPv6:2001:980:d7ed:1:8ee:b906:943e:e71d? ([2001:980:d7ed:1:8ee:b906:943e:e71d]) by mx.google.com with ESMTPS id s3sm11215843eem.4.2013.04.04.06.20.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 06:20:12 -0700 (PDT) Sender: =?UTF-8?Q?Ren=C3=A9_Ladan?= Message-ID: <515D7E0A.6010504@freebsd.org> Date: Thu, 04 Apr 2013 15:20:10 +0200 From: =?ISO-8859-1?Q?Ren=E9_Ladan?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130403 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: signal 11 after kernel update r247742 -> r248706 References: <51545932.9050901@freebsd.org> <1364484652.36972.81.camel@revolution.hippie.lan> <515466B5.4020403@freebsd.org> <5155BC1C.2000104@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: 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: Thu, 04 Apr 2013 13:20:15 -0000 On 29-03-2013 18:58, Adrian Chadd wrote: > On 29 March 2013 09:06, René Ladan > wrote: > > > >> I'm at r248509 on my rpi and everything is good; maybe that'll help > >> narrow the binary search. > > Ok, I'll start looking from there. > > The 'skeleton' unmapped IO commit was r248508, so that one is OK. > There seem to be some unmapped IO changes between r248509 and r248706, > (e.g. r248510-r248512, r248514-r248522, r248550, r248568-r248569, > r248596) but I think it is more related to something closer to > userland? > > But the other commits between r248508 and r248706 look OK to me > (including r248534 (jilles, SOCK_CLOEXEC, SOCK_NONLBOCK, > MSG_CMSG_CLOEXEC)) > > > Are you able to continue bisecting those changes? > > Thanks for your help so far! > Checkpoint: r248509 boots fine (including init), but running e.g. python built under r247742 dumps core during startup. kdump output: ftp://rene-ladan.nl/pub/freebsd/python2.7.ktrace I'm building r248706 now to check if the boot/init is still OK I guess upgrading to today's CURRENT would also be informative? w René From owner-freebsd-arm@FreeBSD.ORG Thu Apr 4 14:46:27 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9EB0BFE2; Thu, 4 Apr 2013 14:46:27 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by mx1.freebsd.org (Postfix) with ESMTP id D490E78E; Thu, 4 Apr 2013 14:46:26 +0000 (UTC) Received: by mail-ee0-f45.google.com with SMTP id c50so315123eek.32 for ; Thu, 04 Apr 2013 07:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=3QK2umin0cCOco8kX5L96x3oydSJbMVnFV3C+fXyPgM=; b=ToQDoo0z4Ldlger/PCP5zkin+p8kUXGvho4LX1u9b5piF2iu2pWRwyV5JQfQiJTOwi LxYo7f+YUOtdBfLTKv9qJbL2IGb3P5tq4hoDAqF/O64ADWcvIbuyqs1KAaaaxztxIt7i YaVXDnSWtuiTqMZMEvAn8L4PeCHoo2uYnFEvDEBSh2eoV0TzL/z7tHwOicjKJXkClDQ1 e3Q0P10t5A2fNKtioGHnCdFFi+rQkHEiCYCi/Xt2K8uDdBOKlijuyftDDl/dN77VfxS2 qbk7P05Yt9AwwngGZ5C8agBRmgVY9HjePOhCSDVJLrMYKlpZg++CxTpJBEABPP8oKNOn OVuA== X-Received: by 10.14.183.67 with SMTP id p43mr11495390eem.10.1365086779851; Thu, 04 Apr 2013 07:46:19 -0700 (PDT) Received: from ?IPv6:2001:980:d7ed:1:8ee:b906:943e:e71d? ([2001:980:d7ed:1:8ee:b906:943e:e71d]) by mx.google.com with ESMTPS id h5sm11507634eem.1.2013.04.04.07.46.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 07:46:18 -0700 (PDT) Sender: =?UTF-8?Q?Ren=C3=A9_Ladan?= Message-ID: <515D9239.40606@freebsd.org> Date: Thu, 04 Apr 2013 16:46:17 +0200 From: =?ISO-8859-1?Q?Ren=E9_Ladan?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130403 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: signal 11 after kernel update r247742 -> r248706 References: <51545932.9050901@freebsd.org> <1364484652.36972.81.camel@revolution.hippie.lan> <515466B5.4020403@freebsd.org> <5155BC1C.2000104@freebsd.org> <515D7E0A.6010504@freebsd.org> In-Reply-To: <515D7E0A.6010504@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: 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: Thu, 04 Apr 2013 14:46:27 -0000 On 04-04-2013 15:20, René Ladan wrote: > On 29-03-2013 18:58, Adrian Chadd wrote: >> On 29 March 2013 09:06, René Ladan > > wrote: >> >> >> >> I'm at r248509 on my rpi and everything is good; maybe that'll help >> >> narrow the binary search. >> > Ok, I'll start looking from there. >> >> The 'skeleton' unmapped IO commit was r248508, so that one is OK. >> There seem to be some unmapped IO changes between r248509 and r248706, >> (e.g. r248510-r248512, r248514-r248522, r248550, r248568-r248569, >> r248596) but I think it is more related to something closer to >> userland? >> >> But the other commits between r248508 and r248706 look OK to me >> (including r248534 (jilles, SOCK_CLOEXEC, SOCK_NONLBOCK, >> MSG_CMSG_CLOEXEC)) >> >> >> Are you able to continue bisecting those changes? >> >> Thanks for your help so far! >> > Checkpoint: r248509 boots fine (including init), but running e.g. python > built under r247742 dumps core during startup. > kdump output: ftp://rene-ladan.nl/pub/freebsd/python2.7.ktrace > Maybe it has to do with the fix applied to libsupc++ in r248624 to get this program working: % cat testcpp.cc #include using namespace std; int main(void) { try { throw "throwme"; } catch (const char* msg) { cout << msg << endl; } return 0; } With an older libsupc++ , one gets: % /home/pi/testcpp /usr/lib/libsupc++.so.1: Undefined symbol "_Unwind_RaiseException" % René From owner-freebsd-arm@FreeBSD.ORG Thu Apr 4 19:38: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 38B348B4 for ; Thu, 4 Apr 2013 19:38:14 +0000 (UTC) (envelope-from jeff@jrpenn.demon.co.uk) Received: from smtp.demon.co.uk (mdfmta010.mxout.tch.inty.net [91.221.169.51]) by mx1.freebsd.org (Postfix) with ESMTP id C1A399B6 for ; Thu, 4 Apr 2013 19:38:12 +0000 (UTC) Received: from smtp.demon.co.uk (unknown [127.0.0.1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta010.tch.inty.net (Postfix) with ESMTP id F0F4B400285 for ; Thu, 4 Apr 2013 20:31:12 +0100 (BST) Received: from mdfmta004.tch.inty.net (unknown [127.0.0.1]) by mdfmta004.tch.inty.net (Postfix) with ESMTP id 750B6AC41E2 for ; Thu, 4 Apr 2013 20:31:06 +0100 (BST) Received: from mdfmta004.tch.inty.net (unknown [127.0.0.1]) by mdfmta004.tch.inty.net (Postfix) with ESMTP id 0CDCAAC41DB for ; Thu, 4 Apr 2013 20:31:06 +0100 (BST) Received: from beastie.jrpenn.demon.co.uk (unknown [80.176.77.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta004.tch.inty.net (Postfix) with ESMTP for ; Thu, 4 Apr 2013 20:31:05 +0100 (BST) Received: from beastie.jrpenn.demon.co.uk (localhost [127.0.0.1]) by beastie.jrpenn.demon.co.uk (8.14.5/8.14.5) with ESMTP id r34JV5u1091884 for ; Thu, 4 Apr 2013 20:31:05 +0100 (BST) (envelope-from jeff@beastie.jrpenn.demon.co.uk) Received: (from jeff@localhost) by beastie.jrpenn.demon.co.uk (8.14.5/8.14.5/Submit) id r34JV423091883 for freebsd-arm@freebsd.org; Thu, 4 Apr 2013 20:31:04 +0100 (BST) (envelope-from jeff) Date: Thu, 4 Apr 2013 20:31:04 +0100 From: Jeff Penn To: freebsd-arm@freebsd.org Subject: Re: Net booting current snapshot on openrd and sheevaplug Message-ID: <20130404193104.GA91842@jrpenn.demon.co.uk> References: <20130323183037.GA39897@beastie.jrpenn.demon.co.uk> <1364067518.1157.163.camel@revolution.hippie.lan> <20130323231302.GA60043@jrpenn.demon.co.uk> <1364092848.1157.165.camel@revolution.hippie.lan> <20130325222845.GA27893@jrpenn.demon.co.uk> <20130330214014.GA1503@jrpenn.demon.co.uk> <20130403183428.GA81559@jrpenn.demon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130403183428.GA81559@jrpenn.demon.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-MDF-HostID: 17 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, 04 Apr 2013 19:38:14 -0000 Using net/etherboot (default options) I tried booting a diskless kernel compiled from the same snapshot of current with the following changes: --- GENERIC 2013-03-05 01:06:41.000000000 +0000 +++ MYCURRENT 2013-04-04 18:02:05.000000000 +0100 @@ -25,6 +25,7 @@ makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support +hints "GENERIC.hints" options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption @@ -43,6 +44,10 @@ options NFSD # New Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCL +options BOOTP # Use BOOTP to obtain IP address/hostname +options BOOTP_NFSROOT # NFS mount root filesystem using BOOTP info +#options BOOTP_NFSV3 # Use NFS v3 to NFS mount root +options BOOTP_COMPAT # Workaround for broken bootp daemons. options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) The kernel was loaded using tftp, but failed to get as far as the arm systems (dmesg copied by hand): ... sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 smist0: on cpu0 device_attach: smist0 attach returned 6 panic: et_start: period not specified for periodic-only timer cpuid = 0 KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at kbd_enter+0x3d: movl $0,kbd_why db> The same procedure was followed for 9.1-RELEASE and the boot was a success (note the old hardware - not sure if this could account for the failure with current): Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-RELEASE-p2 #0: Thu Apr 4 19:18:35 BST 2013 root@beastie.jrpenn.demon.co.uk:/usr/obj/usr/src/sys/DISKLESS i386 CPU: Intel Pentium III (698.41-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Family = 6 Model = 8 Stepping = 3 Features=0x383f9ff real memory = 402653184 (384 MB) avail memory = 370495488 (353 MB) kbd1 at kbdmux0 ctl: CAM Target Layer loaded acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pcib0: Length mismatch for 3 range: 80000 vs 7ffff pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1460-0x146f at device 7.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 uhci0: port 0x1440-0x145f irq 9 at device 7.2 on pci0 usbus0 on uhci0 pci0: at device 7.3 (no driver attached) vgapci0: mem 0xf5000000-0xf5ffffff irq 11 at device 13.0 on pci0 pci0: at device 15.0 (no driver attached) rl0: port 0x1000-0x10ff mem 0xf4000000-0xf40000ff irq 3 at device 17.0 on pci0 miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:06:4f:80:94:ba fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ppc0: port 0x378-0x37b irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model MouseMan+, device ID 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xe0000-0xe3fff,0xe4000-0xeffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 smist0: on cpu0 device_attach: smist0 attach returned 6 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 2 ports with 2 removable, self powered cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present Sending DHCP Discover packet from interface rl0 (00:06:4f:80:94:ba) Received DHCP Offer packet on rl0 from 192.168.0.10 (accepted) (no root path) Received DHCP Offer packet on rl0 from 192.168.0.10 (ignored) (no root path) Received DHCP Offer packet on rl0 from 192.168.0.10 (ignored) (no root path) Sending DHCP Request packet from interface rl0 (00:06:4f:80:94:ba) Received DHCP Ack packet on rl0 from 192.168.0.10 (accepted) (got root path) rl0 at 192.168.0.12 server 192.168.0.10 boot file i386/kernel subnet mask 255.255.255.0 router 192.168.0.1 rootfs 192.168.0.10:/ hostname debian Adjusted interface rl0 Timecounter "TSC" frequency 698407512 Hz quality 800 Trying to mount root from nfs: []... NFS ROOT: 192.168.0.10:/ Jeff From owner-freebsd-arm@FreeBSD.ORG Thu Apr 4 22:32: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 28BAB366; Thu, 4 Apr 2013 22:32:47 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) by mx1.freebsd.org (Postfix) with ESMTP id F238614C; Thu, 4 Apr 2013 22:32:46 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MKR00J002GZFI00@smtpauth3.wiscmail.wisc.edu>; Thu, 04 Apr 2013 16:32:40 -0500 (CDT) X-Spam-PmxInfo: Server=avs-3, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.4.4.212123, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from terminus.icecube.wisc.edu (i3-user-nat.icecube.wisc.edu [128.104.255.12]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MKR0054A2IF9Y30@smtpauth3.wiscmail.wisc.edu>; Thu, 04 Apr 2013 16:32:40 -0500 (CDT) Message-id: <515DF177.9060907@freebsd.org> Date: Thu, 04 Apr 2013 16:32:39 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 To: Tim Kientzle Subject: Re: RFC: "Crochet" build tool References: <5DFA61DB-70E4-4C3D-ACA0-995A175706C8@neville-neil.com> <5151B454.9090402@ceetonetechnology.com> <1CBF1416-3237-4DCE-8D61-7E998265C887@neville-neil.com> <1364311809.36972.27.camel@revolution.hippie.lan> <5151D045.80305@thieprojects.ch> <5151D9DB.7050001@thieprojects.ch> <167CF57D-01E3-4857-BF0E-C40B00FED226@netgate.com> <515ADB81.7090908@freebsd.org> In-reply-to: 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, 04 Apr 2013 22:32:47 -0000 On 04/03/13 23:20, Tim Kientzle wrote: > On Apr 2, 2013, at 6:22 AM, Nathan Whitehorn wrote: > >> On 03/26/13 14:38, Adrian Chadd wrote: >>> NanoBSD isn't specifically x86 only. >>> >>> The startup script stuff is x86 only. >>> >>> The build/installworld part of nanobsd can be refactored out and made >>> platform portable. >>> >>> The UFS image building part can be refactored out and made platform portable. >>> >>> The startup script stuff can be refactored out and made platform portable. >>> >>> The disk image stuff can be refactored out and made platform portable. >>> >>> These aren't unsolvable problems. :-) >>> >>> >>> >> It's probably worth noting here that release(7) can do cross-builds, >> including disk image generation, with no problem. If that's the part >> you're looking at, it's already solved. >> -Nathan > What boot support does it install? > > Tim > > Something platform specific. There are scripts in the various architecture subdirectories in /usr/src/release, although they are mostly focused on building CD media. -Nathan From owner-freebsd-arm@FreeBSD.ORG Fri Apr 5 04:40: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 52C96F03; Fri, 5 Apr 2013 04:40:20 +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 162ECF80; Fri, 5 Apr 2013 04:40:19 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r354eDeX069743; Fri, 5 Apr 2013 04:40:13 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id qdf4sfhgfrigxjj3i8zxqncjne; Fri, 05 Apr 2013 04:40:13 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: RFC: "Crochet" build tool Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <515DF177.9060907@freebsd.org> Date: Thu, 4 Apr 2013 21:40:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4DC4C47C-D503-4155-8FAF-6D5C88D8F67C@freebsd.org> References: <5DFA61DB-70E4-4C3D-ACA0-995A175706C8@neville-neil.com> <5151B454.9090402@ceetonetechnology.com> <1CBF1416-3237-4DCE-8D61-7E998265C887@neville-neil.com> <1364311809.36972.27.camel@revolution.hippie.lan> <5151D045.80305@thieprojects.ch> <5151D9DB.7050001@thieprojects.ch> <167CF57D-01E3-4857-BF0E-C40B00FED226@netgate.com> <515ADB81.7090908@freebsd.org> <515DF177.9060907@freebsd.org> To: Nathan Whitehorn 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: Fri, 05 Apr 2013 04:40:20 -0000 On Apr 4, 2013, at 2:32 PM, Nathan Whitehorn wrote: > On 04/03/13 23:20, Tim Kientzle wrote: >> On Apr 2, 2013, at 6:22 AM, Nathan Whitehorn wrote: >>=20 >>> On 03/26/13 14:38, Adrian Chadd wrote: >>>> NanoBSD isn't specifically x86 only. >>>>=20 >>>> The startup script stuff is x86 only. >>>>=20 >>>> The build/installworld part of nanobsd can be refactored out and = made >>>> platform portable. >>>>=20 >>>> The UFS image building part can be refactored out and made platform = portable. >>>>=20 >>>> The startup script stuff can be refactored out and made platform = portable. >>>>=20 >>>> The disk image stuff can be refactored out and made platform = portable. >>>>=20 >>>> These aren't unsolvable problems. :-) >>>>=20 >>>>=20 >>>>=20 >>> It's probably worth noting here that release(7) can do cross-builds, >>> including disk image generation, with no problem. If that's the part >>> you're looking at, it's already solved. >>> -Nathan >> What boot support does it install? >>=20 >=20 > Something platform specific. There are scripts in the various = architecture subdirectories in /usr/src/release, although they are = mostly focused on building CD media. > -Nathan This is where ARM gets icky: There is literally a different boot loader chain for almost every separate board. One motivation for building Crochet was to experiment with ideas for managing that diversity. I'll try to find time to tinker with the release(7) stuff and see if there's any way the ideas I've been using for Crochet might fit in here.=20 Thanks for the pointer=85 Tim P.S. Will you be at BSDCan? GNN is trying to put together a session at the DevSummit to talk about image building. From owner-freebsd-arm@FreeBSD.ORG Fri Apr 5 05:40: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 90EA2948; Fri, 5 Apr 2013 05:40:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by mx1.freebsd.org (Postfix) with ESMTP id CE0F81B0; Fri, 5 Apr 2013 05:40:39 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id c10so221249wiw.1 for ; Thu, 04 Apr 2013 22:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ef2vAV5aGgNi0pr4yX9pQqh7bSwSmKE3Jzbbk/Zsfo0=; b=GfhxvqZXDM/fO+uG7//w75efkfS/hGk6XMTexOGcaWKaKlaD89dZJea9ZK1BLfgD08 J1n7Brfhv2Po0c8l0o7Im2lIkefrGkjGfJUzTssUyBMAYysfWBd0prIb/23vKRGIdaGL 5atzRPNM4YBlTDt4CYuldPtU+U1L69AW6wqO/GaqFrT1SOZ7DFuZ5UORorfD9lXqx+0u wzhxK1j+nW6dLvb1v+n8OXNS85xecgG9WMzqC65pJTbqCiQMdEQaxDZ206b32zx2d3nr 6elhO/Kq913wZi8BRKMYMboBaXFrTikRS9An3MU6muIMe3kvdbBwjOTHeOBwgnDlaoAm hEVg== MIME-Version: 1.0 X-Received: by 10.180.188.3 with SMTP id fw3mr1542969wic.33.1365140439053; Thu, 04 Apr 2013 22:40:39 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.212.73 with HTTP; Thu, 4 Apr 2013 22:40:38 -0700 (PDT) In-Reply-To: <4DC4C47C-D503-4155-8FAF-6D5C88D8F67C@freebsd.org> References: <5DFA61DB-70E4-4C3D-ACA0-995A175706C8@neville-neil.com> <5151B454.9090402@ceetonetechnology.com> <1CBF1416-3237-4DCE-8D61-7E998265C887@neville-neil.com> <1364311809.36972.27.camel@revolution.hippie.lan> <5151D045.80305@thieprojects.ch> <5151D9DB.7050001@thieprojects.ch> <167CF57D-01E3-4857-BF0E-C40B00FED226@netgate.com> <515ADB81.7090908@freebsd.org> <515DF177.9060907@freebsd.org> <4DC4C47C-D503-4155-8FAF-6D5C88D8F67C@freebsd.org> Date: Thu, 4 Apr 2013 22:40:38 -0700 X-Google-Sender-Auth: -W35w7sPzpmgwDDxriWlwIpXkss Message-ID: Subject: Re: RFC: "Crochet" build tool From: Adrian Chadd To: Tim Kientzle Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 05:40:40 -0000 Hm, how about something a bit more modular? As in, adding hooks to make release / nanobsd / tinybsd to let us tie in the embedded platform requirements, like building bootloaders and such; Adrian From owner-freebsd-arm@FreeBSD.ORG Fri Apr 5 11:20:05 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 3BE70950; Fri, 5 Apr 2013 11:20:05 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 79850FAA; Fri, 5 Apr 2013 11:20:04 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id u12so2788444wey.5 for ; Fri, 05 Apr 2013 04:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=ICStAGpqmZEWTSuM3ZyF1QwEsWl7RnTMgCd78hiKY3s=; b=wqdKrULIXRHxRvN0+cNeWB4LHqLK3QS25LsterR2QPlpcR/9XFB4eiiCiPsbrxFEZF PvSGc7Sc78qt2nwXDWWylEz8U3PS9me0cdkV09JRTzaIp5stlz89kOnpKG/aGKeeaG8K k6wb0uDcGkZMwV9yFYm16SkTP8YNOtnvYcD+UPIuGQywwNT7hbzMhbWyGtTwhZwfH41T DyfJcAmrglOsfpHtWP5JeNmxLSm1BRcVb6MIYapD4/84gVkzSZfmMdCI+2iC+ktwoP/Q UNJC49JVXWWAhwNH0SvcsC+yu+AmmlDxvVAeMO0peR/+vK8aTL0fwLuWUlLTD3J6OdVb AHjg== X-Received: by 10.194.92.231 with SMTP id cp7mr15600100wjb.19.1365160394955; Fri, 05 Apr 2013 04:13:14 -0700 (PDT) Received: from ?IPv6:2001:980:d7ed:1:8ee:b906:943e:e71d? ([2001:980:d7ed:1:8ee:b906:943e:e71d]) by mx.google.com with ESMTPS id fg6sm3442134wib.10.2013.04.05.04.13.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Apr 2013 04:13:13 -0700 (PDT) Sender: =?UTF-8?Q?Ren=C3=A9_Ladan?= Message-ID: <515EB1C8.3050708@freebsd.org> Date: Fri, 05 Apr 2013 13:13:12 +0200 From: =?ISO-8859-1?Q?Ren=E9_Ladan?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130403 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: signal 11 after kernel update r247742 -> r248706 References: <51545932.9050901@freebsd.org> <1364484652.36972.81.camel@revolution.hippie.lan> <515466B5.4020403@freebsd.org> <5155BC1C.2000104@freebsd.org> <515D7E0A.6010504@freebsd.org> <515D9239.40606@freebsd.org> In-Reply-To: <515D9239.40606@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: 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, 05 Apr 2013 11:20:05 -0000 On 04-04-2013 16:46, René Ladan wrote: > On 04-04-2013 15:20, René Ladan wrote: >> On 29-03-2013 18:58, Adrian Chadd wrote: >>> On 29 March 2013 09:06, René Ladan >> > wrote: >>> >>> >>> >> I'm at r248509 on my rpi and everything is good; maybe that'll help >>> >> narrow the binary search. >>> > Ok, I'll start looking from there. >>> >>> The 'skeleton' unmapped IO commit was r248508, so that one is OK. >>> There seem to be some unmapped IO changes between r248509 and r248706, >>> (e.g. r248510-r248512, r248514-r248522, r248550, r248568-r248569, >>> r248596) but I think it is more related to something closer to >>> userland? >>> >>> But the other commits between r248508 and r248706 look OK to me >>> (including r248534 (jilles, SOCK_CLOEXEC, SOCK_NONLBOCK, >>> MSG_CMSG_CLOEXEC)) >>> >>> >>> Are you able to continue bisecting those changes? >>> >>> Thanks for your help so far! >>> >> Checkpoint: r248509 boots fine (including init), but running e.g. python >> built under r247742 dumps core during startup. >> kdump output: ftp://rene-ladan.nl/pub/freebsd/python2.7.ktrace >> > Maybe it has to do with the fix applied to libsupc++ in r248624 to get > this program working: > > % cat testcpp.cc > #include > > using namespace std; > > int main(void) { > try { > throw "throwme"; > } > catch (const char* msg) { > cout << msg << endl; > } > > return 0; > } > > With an older libsupc++ , one gets: > % /home/pi/testcpp > /usr/lib/libsupc++.so.1: Undefined symbol "_Unwind_RaiseException" > % > I just upgraded to r248706 again and it boots fine. The difference with the earlier upgrade is that I now cross-install kernel and world so that the architecture is compatible with the cross-build architecture. I used a native 'make installkernel' / 'make installworld' upgrade earlier which required some ad-hoc install hacks. testcpp runs fine again with the libsupc++ fix: % /home/pi/testcpp throwme % python still dumps core, maybe it needs to be forcibly rebuilt? I'll upgrade to todays CURRENT to see how that behaves. René From owner-freebsd-arm@FreeBSD.ORG Sat Apr 6 03:26:13 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 7FA7D436; Sat, 6 Apr 2013 03:26:13 +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 5E2408DD; Sat, 6 Apr 2013 03:26:13 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r363QC61077397; Sat, 6 Apr 2013 03:26:12 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id y9mz4iwv6c7zxvmp8nb5zaznme; Sat, 06 Apr 2013 03:26:12 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: signal 11 after kernel update r247742 -> r248706 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <515EB1C8.3050708@freebsd.org> Date: Fri, 5 Apr 2013 20:26:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3AD39992-DE53-4A5C-B168-A146ABC4FDDE@freebsd.org> References: <51545932.9050901@freebsd.org> <1364484652.36972.81.camel@revolution.hippie.lan> <515466B5.4020403@freebsd.org> <5155BC1C.2000104@freebsd.org> <515D7E0A.6010504@freebsd.org> <515D9239.40606@freebsd.org> <515EB1C8.3050708@freebsd.org> To: =?iso-8859-1?Q?Ren=E9_Ladan?= X-Mailer: Apple Mail (2.1283) Cc: 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: Sat, 06 Apr 2013 03:26:13 -0000 On Apr 5, 2013, at 4:13 AM, Ren=E9 Ladan wrote: > I just upgraded to r248706 again and it boots fine. The difference = with > the earlier upgrade is that I now cross-install kernel and world =85 > I used a native 'make installkernel' / 'make installworld' upgrade = earlier > which required some ad-hoc install hacks. Details? Native builds should Just Work. If they don't, let's fix them. We don't have nearly enough people testing native builds. Tim From owner-freebsd-arm@FreeBSD.ORG Sat Apr 6 17:45:44 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F3545EF2; Sat, 6 Apr 2013 17:45:43 +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 B28F88CB; Sat, 6 Apr 2013 17:45:43 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r36Hjg0O081867; Sat, 6 Apr 2013 17:45:43 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id ci2eqyuqpiaw7zcmauqaibixai; Sat, 06 Apr 2013 17:45:42 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: "Beyond Buildworld" (was Re: RFC: "Crochet" build tool) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Tim Kientzle In-Reply-To: Date: Sat, 6 Apr 2013 10:45:42 -0700 Content-Transfer-Encoding: 7bit Message-Id: <8FCD7391-B9E3-478A-86E8-4414F750804D@freebsd.org> References: <5DFA61DB-70E4-4C3D-ACA0-995A175706C8@neville-neil.com> <5151B454.9090402@ceetonetechnology.com> <1CBF1416-3237-4DCE-8D61-7E998265C887@neville-neil.com> <1364311809.36972.27.camel@revolution.hippie.lan> <5151D045.80305@thieprojects.ch> <5151D9DB.7050001@thieprojects.ch> <167CF57D-01E3-4857-BF0E-C40B00FED226@netgate.com> <515ADB81.7090908@freebsd.org> <515DF177.9060907@freebsd.org> <4DC4C47C-D503-4155-8FAF-6D5C88D8F67C@freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1283) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 17:45:44 -0000 On Apr 4, 2013, at 10:40 PM, Adrian Chadd wrote: > Hm, how about something a bit more modular? > > As in, adding hooks to make release / nanobsd / tinybsd to let us tie > in the embedded platform requirements, like building bootloaders and > such; George is setting up a DevSummit track for BSDCan (the "Beyond Buildworld" WG) about this exact issue. Will you be there? I'll be there and here are a few of the issues I'd like to discuss: * What hooks are appropriate? In part, Crochet is an experiment to explore ways of factoring these issues, but I don't know release or nanobsd well enough to judge whether the ideas I'm coming up with would fit well into those. * How do boot loaders get managed? Crochet has been downloading, patching, and building directly from upstream sources, but that's getting tedious fast. Can we maintain boot loaders as ports?[1] * What policy should FreeBSD project use to determine which specific boards to release official images for? For that matter, should the project release "official images" at all? Or should we leave that in the hands of other parties? I'm not expecting to come up with final answers to these at BSDCan, but I'm hoping to get enough people involved to at least enumerate some of the avenues to explore. Tim [1] If someone wants to try creating a port of some boot loader as an experiment, I'm happy to collaborate on integrating it into Crochet to see how well that works. I would suggest trying to build a port for RPi U-Boot as a first proof-of-concept. From owner-freebsd-arm@FreeBSD.ORG Sat Apr 6 20:50:56 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 7DC06D76; Sat, 6 Apr 2013 20:50:56 +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 3B8EEFBE; Sat, 6 Apr 2013 20:50:55 +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 1UOa4V-000H5c-FV; Sat, 06 Apr 2013 13:50:49 -0700 Message-ID: <51608AA4.2020804@bluezbox.com> Date: Sat, 06 Apr 2013 13:50:44 -0700 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: arm@freebsd.org, usb@freebsd.org Subject: Beaglebone USB driver (Mentor Graphics OTG) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Hello, This is first iteration of Host Mode support for Mentor Graphics OTG USB controller. I tested it by building kernel with USB memory stick mounted as /usr/obj, resulting kernel was bootable and worked fine. I reused some ideas (mostly for channel-management) from DWT OTG driver. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 20:50:56 -0000 Hello, This is first iteration of Host Mode support for Mentor Graphics OTG USB controller. I tested it by building kernel with USB memory stick mounted as /usr/obj, resulting kernel was bootable and worked fine. I reused some ideas (mostly for channel-management) from DWT OTG driver. Some pieces are still missing: - Support for SPLIT transactions, I don not have high speed hub right now to test it, but implementing it should be really straighforward. - Isochronous transfers. I do not have hardware to test this. Does anybody have any suggestion about simple use case? - Control Data OUT transaction - Wrapper for atmel HW has not ben synced with new core logic requirements yet Please review and test. I tested it only with gcc-built kernel/world. Now when first iteration is finished I'm going to update all my boards to new world order (clang/EABI) and re-test this stuff. Patch: http://people.freebsd.org/~gonzo/arm/patches/beaglebone-musb.diff From owner-freebsd-arm@FreeBSD.ORG Sat Apr 6 21:03: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 1D7A725D for ; Sat, 6 Apr 2013 21:03:34 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id DC4CA117 for ; Sat, 6 Apr 2013 21:03:33 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id bn7so5451053ieb.23 for ; Sat, 06 Apr 2013 14:03:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=182Kxar1KIJ1Ly6Lzsjl8bn3A6eXg2m51Tu6n6wv6jQ=; b=UpE7+n2N86rbJEsXSCdyz7M9SHjhHrFhTjYYi+DjdJ03R9VfHIsk4cu0h8gojfqX20 JNake51U2Aga1BID48rSILYohR3ZqMg9YtBfwbGeA8Vhcm+2rW53H/tbbmOYZpdV40sw +Q+gVpde7tvo3YUo1dOKd1EI3V5TzASoOT0tf+TKlDM5iTSkh14wVLsDzmLGnqP3VurH Z+9ZNfwkCKAvnweJHK6MltBVjKdLfD2zThNbx/xpodmFYVdkYjhK+JZNoNywDmYcuKzq P/8caA8xNd/RQszct2//m/NzPIqREJ6xZcrqfT1p+WwkRachMae+yij3vrh/3dPhv033 RSTg== X-Received: by 10.50.209.4 with SMTP id mi4mr2853492igc.40.1365282213590; Sat, 06 Apr 2013 14:03:33 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id xf4sm8068211igb.8.2013.04.06.14.03.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Apr 2013 14:03:32 -0700 (PDT) Sender: Warner Losh Subject: Re: "Beyond Buildworld" (was Re: RFC: "Crochet" build tool) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <8FCD7391-B9E3-478A-86E8-4414F750804D@freebsd.org> Date: Sat, 6 Apr 2013 15:03:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <50CC112D-2B90-4E66-9D5F-829274D041D7@bsdimp.com> References: <5DFA61DB-70E4-4C3D-ACA0-995A175706C8@neville-neil.com> <5151B454.9090402@ceetonetechnology.com> <1CBF1416-3237-4DCE-8D61-7E998265C887@neville-neil.com> <1364311809.36972.27.camel@revolution.hippie.lan> <5151D045.80305@thieprojects.ch> <5151D9DB.7050001@thieprojects.ch> <167CF57D-01E3-4857-BF0E-C40B00FED226@netgate.com> <515ADB81.7090908@freebsd.org> <515DF177.9060907@freebsd.org> <4DC4C47C-D503-4155-8FAF-6D5C88D8F67C@freebsd.org> <8FCD7391-B9E3-478A-86E8-4414F750804D@freebsd.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkl5NAeAk5eJzRlaRuqQgs5ljgOu19agRZyOtG3MnbIiUfQTA1uDFKpXvKUv7YUJtJ9FlvG 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, 06 Apr 2013 21:03:34 -0000 On Apr 6, 2013, at 11:45 AM, Tim Kientzle wrote: >=20 > On Apr 4, 2013, at 10:40 PM, Adrian Chadd wrote: >=20 >> Hm, how about something a bit more modular? >>=20 >> As in, adding hooks to make release / nanobsd / tinybsd to let us tie >> in the embedded platform requirements, like building bootloaders and >> such; >=20 > George is setting up a DevSummit track for BSDCan (the > "Beyond Buildworld" WG) about this exact issue. > Will you be there? I'll be there. > I'll be there and here are a few of the issues I'd like to discuss: >=20 > * What hooks are appropriate? In part, Crochet is an experiment > to explore ways of factoring these issues, but I don't know > release or nanobsd well enough to judge whether the > ideas I'm coming up with would fit well into those. Most of the ones that NanoBSD has are quite useful... I'm sure there are = many others that would be good in addition, since NanoBSD hasn't kept = pace. > * How do boot loaders get managed? Crochet has been > downloading, patching, and building directly from upstream > sources, but that's getting tedious fast. Can we maintain boot > loaders as ports?[1] I think that we can and should, to the extent we need to do so. Most = boards have a perfectly good boot loader already, but some like the = popular RPi don't. Thankfully, the images for the boot loaders tend to = be separable from the main image that people load on them and run/boot. > * What policy should FreeBSD project use to determine which > specific boards to release official images for? For that matter, > should the project release "official images" at all? Or should > we leave that in the hands of other parties? In general, we shouldn't be aiming to release a general loader / kernel = that runs everywhere. To release lots of other images will get difficult = quickly. Alas, the current kernel infrastructure is a little weak to do = this (actually it is impossible at the moment). We should have clear = goals here, though, otherwise we'll quickly get bogged down. If we = require multiple images, then we should automate the snot out of that, = or if a popular board requires custom hacks. To this end, I think we should examine making ubldr position independent = code. Once we have this, it can relocate itself and load the actual = kernel at a board specific location it can determine from the FDT... > I'm not expecting to come up with final answers to these > at BSDCan, but I'm hoping to get enough people involved to > at least enumerate some of the avenues to explore. Yea, if we can get a good consensus on a direction, we can all pull in = that direction, rather in the somewhat fractured different directions we = have been pulling in to doate. > [1] If someone wants to try creating a port of some boot loader > as an experiment, I'm happy to collaborate on integrating it into > Crochet to see how well that works. I would suggest trying > to build a port for RPi U-Boot as a first proof-of-concept. That would be cool... Again, I worry about getting in the business of = too many board support, but we may want to do that for the most popular = ones. Warner= From owner-freebsd-arm@FreeBSD.ORG Sat Apr 6 21:09: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 E90FC2E4; Sat, 6 Apr 2013 21:09:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by mx1.freebsd.org (Postfix) with ESMTP id 5454413E; Sat, 6 Apr 2013 21:09:34 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id f12so4798156wgh.10 for ; Sat, 06 Apr 2013 14:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=BjAmG1UOAf5gULCosuUvYbGt5iROhaOO02uVHTYBJIo=; b=PAudfpucXVRXMgDjyLwn3na6zSrmuPizaO6+vAeyOoSnWxPG6aI65tx5wshmsPl5ld QCxsoBKEHa8QOIb4Pk3BDcc/xACnH1j6Sj93iIaEzz9qv3LHhcD7BYcIdAIeSApssNNa zAB73+SO1EjVDSz4nZCh6XZU7e3pvIWSfcXk42+JogAuKJCTwvb6EHZLhKoazyB2tQPL uQLmel5/2yCqLmujfpcZLZZmzePN6p6wsOPgV3KL/j5WK/4G/bE4WGDCfEBYrcxgQ2VX VJ/QLdO6l3NLelrO/qL3YydUq8fSrf6c5C1GZ9X7RP1D/vTqhijOkQfxGGSg+DTPJU0L +p+Q== MIME-Version: 1.0 X-Received: by 10.181.11.164 with SMTP id ej4mr5537336wid.29.1365282567703; Sat, 06 Apr 2013 14:09:27 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.121.136 with HTTP; Sat, 6 Apr 2013 14:09:27 -0700 (PDT) In-Reply-To: <50CC112D-2B90-4E66-9D5F-829274D041D7@bsdimp.com> References: <5DFA61DB-70E4-4C3D-ACA0-995A175706C8@neville-neil.com> <5151B454.9090402@ceetonetechnology.com> <1CBF1416-3237-4DCE-8D61-7E998265C887@neville-neil.com> <1364311809.36972.27.camel@revolution.hippie.lan> <5151D045.80305@thieprojects.ch> <5151D9DB.7050001@thieprojects.ch> <167CF57D-01E3-4857-BF0E-C40B00FED226@netgate.com> <515ADB81.7090908@freebsd.org> <515DF177.9060907@freebsd.org> <4DC4C47C-D503-4155-8FAF-6D5C88D8F67C@freebsd.org> <8FCD7391-B9E3-478A-86E8-4414F750804D@freebsd.org> <50CC112D-2B90-4E66-9D5F-829274D041D7@bsdimp.com> Date: Sat, 6 Apr 2013 14:09:27 -0700 X-Google-Sender-Auth: TaurbV5cdS7TbOuCVsdtjQ6bDPM Message-ID: Subject: Re: "Beyond Buildworld" (was Re: RFC: "Crochet" build tool) From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 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, 06 Apr 2013 21:09:36 -0000 FreeBSD doesn't necessarily need to support all of that, at least just yet. I think we'd be in a good position if we had build scripts and base support to build a variety of target system filesystem configurations and images; then leave it up to an external project (which may or may not _be_ at freebsd.org, but it doesn't have to be in /usr/src) that builds the platform specific stuff. That way we don't get bogged down with bootloaders and such at this stage. Ideally i'd like to see all of those bootloaders and tools in /usr/src, just like we do for booting i386/amd64/etc systems. That way we _do_ have a nice, tightly integrated system. But I think that's a stretch goal. Adrian From owner-freebsd-arm@FreeBSD.ORG Sat Apr 6 21:18:51 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AD5003B0 for ; Sat, 6 Apr 2013 21:18:51 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x22a.google.com (mail-ia0-x22a.google.com [IPv6:2607:f8b0:4001:c02::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 76FA517C for ; Sat, 6 Apr 2013 21:18:51 +0000 (UTC) Received: by mail-ia0-f170.google.com with SMTP id h8so4209662iaa.29 for ; Sat, 06 Apr 2013 14:18:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=pyDnMqj0l8zT4dO5X/ch0U4vHJJ4wnYdGIxj+Kw3BU0=; b=R+xo7hdJVZGEugAkbkWlZ1ADOnw6BjSUi2GfdoJLcoOyOumq74kpqy4XEs22w6bCyf 3kORKExLtaokenFnbEmGPG31m8XKkTxKcF6iFheTyCso3El+WF2C6/GBC8NrlisrLtXO l2AgpNK9Sz2/XWQYFvl3pFH06pjRZIB0rJTvBVUoDmTrDqLAFc81jDhcV0eZZ4uwHvF+ wtF+Qxbb4FXrgw+eiONSQ57tpX0m9Eb0v51UXVJoWarSEQbdG9Wfi1b/I8kEzVRZMP0N Vcc0H3WM5YLSkXD/2+dsB3WnhAVWagDWywQxWOBEkyUzD+HU1jGntC4fG2AaIDRnkFGL PbxA== X-Received: by 10.50.136.138 with SMTP id qa10mr2864066igb.74.1365283131157; Sat, 06 Apr 2013 14:18:51 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ie7sm8146674igb.1.2013.04.06.14.18.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Apr 2013 14:18:50 -0700 (PDT) Sender: Warner Losh Subject: Re: "Beyond Buildworld" (was Re: RFC: "Crochet" build tool) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 6 Apr 2013 15:18:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5DFA61DB-70E4-4C3D-ACA0-995A175706C8@neville-neil.com> <5151B454.9090402@ceetonetechnology.com> <1CBF1416-3237-4DCE-8D61-7E998265C887@neville-neil.com> <1364311809.36972.27.camel@revolution.hippie.lan> <5151D045.80305@thieprojects.ch> <5151D9DB.7050001@thieprojects.ch> <167CF57D-01E3-4857-BF0E-C40B00FED226@netgate.com> <515ADB81.7090908@freebsd.org> <515DF177.9060907@freebsd.org> <4DC4C47C-D503-4155-8FAF-6D5C88D8F67C@freebsd.org> <8FCD7391-B9E3-478A-86E8-4414F750804D@freebsd.org> <50CC112D-2B90-4E66-9D5F-829274D041D7@bsdimp.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlIoghxmsps/HZMThTk4coR5fU5a5gQB8FRe3iMP6Frw5rAI0T4Ivs4XzJqCP+VhQZT/hzx 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, 06 Apr 2013 21:18:51 -0000 On Apr 6, 2013, at 3:09 PM, Adrian Chadd wrote: > FreeBSD doesn't necessarily need to support all of that, at least just = yet. I tend to agree, but only to a point. We should have a long-range plan = in mind, as well as a long term destination. We need not hit that with = the first iteration, but each iteration should get us closer. > I think we'd be in a good position if we had build scripts and base > support to build a variety of target system filesystem configurations > and images; then leave it up to an external project (which may or may > not _be_ at freebsd.org, but it doesn't have to be in /usr/src) that > builds the platform specific stuff. That way we don't get bogged down > with bootloaders and such at this stage. Yes. We don't want to be in the boot loader business. The board should = provide. Unfortunately, most board providers don't yet support the = callback API that we need to support the ubldr. We should accept that = there will be a wide range of versions and possibly even different = loaders like barebox. Linux is able to cope by having a very = standardized interface. We don't have that now, and we should adopt one. = We're currently not likely large enough to do anything other than the = Linux interface. > Ideally i'd like to see all of those bootloaders and tools in > /usr/src, just like we do for booting i386/amd64/etc systems. That way > we _do_ have a nice, tightly integrated system. But I think that's a > stretch goal. I'd opt for a ports solution to the bare-metal loader. The experience = that we had with AT91 suggests supporting a wide range of boards with = the bare-metal loaders is very hard, and we don't have the bandwidth to = do this. Warner From owner-freebsd-arm@FreeBSD.ORG Sat Apr 6 22:16:59 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 B0864F41; Sat, 6 Apr 2013 22:16:59 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 6DCFF354; Sat, 6 Apr 2013 22:16:59 +0000 (UTC) Received: from rnote.ddteam.net (7-127-135-95.pool.ukrtel.net [95.135.127.7]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 46EDFC493C; Sun, 7 Apr 2013 01:16:56 +0300 (EEST) Date: Sun, 7 Apr 2013 01:16:50 +0300 From: Aleksandr Rybalko To: Oleksandr Tymoshenko Subject: Re: Beaglebone USB driver (Mentor Graphics OTG) Message-Id: <20130407011650.f2cb547a.ray@freebsd.org> In-Reply-To: <51608AA4.2020804@bluezbox.com> References: <51608AA4.2020804@bluezbox.com> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, usb@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, 06 Apr 2013 22:16:59 -0000 On Sat, 06 Apr 2013 13:50:44 -0700 Oleksandr Tymoshenko wrote: > Hello, > > This is first iteration of Host Mode support for Mentor Graphics > OTG USB controller. I tested it by building kernel with USB memory > stick mounted as /usr/obj, resulting kernel was bootable and worked > fine. I reused some ideas (mostly for channel-management) from > DWT OTG driver. > > Some pieces are still missing: > - Support for SPLIT transactions, I don not have high speed hub > right now to test it, but implementing it should be really > straighforward. > - Isochronous transfers. I do not have hardware to test this. Does > anybody have any suggestion about simple use case? Any USB camera (a.k.a. Web Cam) > - Control Data OUT transaction > - Wrapper for atmel HW has not ben synced with new core logic > requirements yet > > Please review and test. I tested it only with gcc-built kernel/world. > Now when > first iteration is finished I'm going to update all my boards to new > world order > (clang/EABI) and re-test this stuff. > > Patch: > http://people.freebsd.org/~gonzo/arm/patches/beaglebone-musb.diff > _______________________________________________ > 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" WBW -- Aleksandr Rybalko